Em termos simples, um mecanismo arquitetural representa uma solução comum para um problema encontrado com freqüência. Mecanismos arquiteturais são utilizados com freqüência para perceber requisitos arquiteturais.
A tabela abaixo mostra três categorias de mecanismos arquiteturais e mostra como esse mecanismos são expressos em cada uma dessas categorias.
| Mecanismo de Análise | Mecanismo de Design | Mecanismo de implementação |
| Persistência | RDBMS | Oracle |
| Ingres | ||
| OODBMS | ObjectStore | |
| Comunicação | Object request broker Objeto pedido corretor | Orbix |
| VisiBroker | ||
| Message queue Mensagem fila | MSMQ | |
| MQSeries |
Um mecanismo de análise representa uma implementação independente de solução.
Um mecanismo de design(projeto) é um refinamento de um mecanismo de análise. E um mecanismo de implementação é um refinamento de um mecanismo de design, e especifica a exata aplicação do mecanismo.
A figura abaixo resume a relação entre os requisitos e mecanismos, mostrando refinamentos do FURPS.
A abordagem proposta para obter requisitos arquiteturais com FURPS é a seguinte:
1. “Mantenha uma lista completa de requisitos arquiteturais, sem levar em
consideração se os itens listados são relevantes ou não para um projeto
particular”;
2. “Para cada requisito arquitetural, formule uma ou mais questões que
possam ajudar no processo de especificação. Tenha certeza de que todos os
envolvidos no projeto possam entender essas questões”;
3. “Ajude os envolvidos no projeto mostrando a eles o impacto potencial
de responder uma questão de uma forma ou de outra”;
4. “Capture as respostas dadas a cada uma das questões”;
5. “Ajude o arquiteto assegurando que os envolvidos no projeto (em adição
às respostas das questões) atribuam uma prioridade ou um peso a cada requisito
arquitetural. Esse peso atribuído ajudará o arquiteto a fazer escolhas entre os
requisitos”.
A tabela abaixo exemplifica um questionário desse tipo, que inclui também exemplos de respostas:
| Requisito | Questões | Impacto | Respostas |
|---|---|---|---|
Licenças (prioridade: Média) | O sistema, ou parte dele será licenciado? Existem muitas restrições no mecanismo utilizado para prover capacidade de licenciamento? | Quanto maior a sofisticação do mecanismo de licenciamento, maior o tempo para realização da comercialização e maior o custo de manutenção. | O módulo de controle de estoque será comercializado como um componente separado do sistema e irá requerer licença. A ferramenta FlexLM é utilizada por toda nossa organização para prover capacidade de licenciamento. |
| Disponibilidade (prioridade: alta) | Existe algum requisito a respeito do tempo médio entre falhas do sistema (MTBF)? | Quanto maior a disponibilidade, maior o grau de comercialização do sistema. | Disponibilidade é uma característica chave do produto. O produto deve ter um MTBF de 60 dias |
| Suporte a plataformas (prioridade: alta) | Que plataformas o sistema deve suportar? | O desenvolvimento para uma única plataforma pode reduzir o potencial de comercialização do produto.Também pode permitir uma integração com as características das plataformas. | O produto deve ser implementado para rodar nas seguintes plataformas UNIX: Sun Solaris IBM AIX HPUX |
Fonte/referencias:
Peter Eeles, Senior TI arquitecto, IBM
