Artefato:
| ||||||||||||
|
|
Uma Arquitetura de Referência é, basicamente, um padrão ou conjunto de padrões de arquitetura predefinido, possivelmente parcial ou totalmente instanciado, projetado e testado em determinados contextos de negócios e técnicos com artefatos de suporte que permitam seu uso. Geralmente, esses artefatos são resultantes de projetos anteriores. |
| Papel: | Arquiteto de Software |
| Mais Informações: | |
| Entrada para Atividades: | Saída de Atividades: |
Os artefatos Arquitetura de Referência fazem parte da base de ativos reutilizáveis de uma organização. A finalidade desses artefatos é criar um ponto de partida para o desenvolvimento da arquitetura. Eles podem variar de padrões de arquitetura, mecanismos de arquitetura e frameworks prontos a sistemas completos, com características conhecidas e de uso comprovado. Eles podem ser aplicados de forma geral ou para uma ampla classe de sistemas de domínios, ou ter um enfoque mais limitado, específico de domínio.
O uso de arquiteturas de referência testadas é uma maneira eficaz de lidar com os vários requisitos não-funcionais (particularmente os requisitos de qualidade), selecionando arquiteturas de referência existentes, que são conhecidas através do uso para atender a esses requisitos. As Arquiteturas de Referência podem existir ou ser usadas em diferentes níveis de abstração e a partir de diversos pontos de vista. Esses pontos de vista correspondem às Visões 4+1 (consulte "Um Conjunto Típico de Visões de Arquitetura"). Desse modo, o arquiteto de software pode selecionar a visão que seja mais adequada — apenas um design de arquitetura ou um design e uma implementação, em variados graus de conclusão.
Geralmente, uma Arquitetura de Referência é definida não para incluir instâncias dos componentes que serão usados na construção do sistema — se for assim, ela se tornará uma Arquitetura da Linha do Produto. No entanto, essa não é uma distinção firme e segura. No Rational Unified Process (RUP), aceitamos que a noção de Arquitetura de Referência inclua referências a componentes reutilizáveis existentes (ou seja, implementações).
A organização que possui os ativos da Arquitetura de Referência precisará decidir como eles serão classificados e organizados para facilitar a recuperação por parte do arquiteto de software, atendendo aos critérios de seleção do novo sistema. Embora a criação e o armazenamento de Arquiteturas de Referência estejam no momento fora do escopo do RUP, uma sugestão é que as arquiteturas sejam organizadas em torno da idéia de domínios, onde um domínio é uma área de assunto que define o conhecimento e os conceitos de algum aspecto de um sistema ou de uma família de sistemas. Aqui estamos aceitando o uso do termo 'domínio' em níveis inferiores aos do aplicativo. Esse uso difere um pouco do fornecido em algumas definições — difere, por exemplo, do uso apresentado em [HOF98] — mas está de acordo com o uso apresentado em [LMFS96]:
"Domínio da Linha do Produto: Um grupo restrito de recursos - presente e/ou futuro - definido para facilitar a comunicação, análise e engenharia visando identificar, planejar e gerenciar a freqüência em uma linha de produto. Esses domínios podem incluir grupos intrinsecamente relacionados de sistemas de usuários finais, funções comumente utilizadas em sistemas múltiplos ou agrupamentos amplamente aplicáveis de serviços básicos."
Essa definição inclui a noção de que os elementos usados para compor sistemas podem pertencer a um domínio que é, por si só, digno de estudo. A figura a seguir, extraída de [LMFS96], ilustra esse princípio.
Domínios Horizontais e Verticais para o Exército Americano
Essa figura mostra as principais famílias de sistemas: Sistemas de Informações, Comando e Controle, e Sistemas de Armamentos, cada um com alguns domínios verticais inteiramente contidos e alguns domínios horizontais que interceptam os verticais e as famílias de sistemas. Assim, os conceitos de Programação em Tempo Real são aplicáveis ao Domínio Tático de Comando e Controle e a todos os domínios verticais de Sistemas de Armamentos. Isso provavelmente faz sentido quando é necessário resolver problemas de programação em tempo real para todos esses domínios ao mesmo tempo e tratar o conhecimento e os ativos desenvolvidos como um domínio separado, que tenha uma associação com Conflitos Eletrônicos, por exemplo, mas não com Sistema de Informações Pessoais.
A Arquitetura de Referência tem o mesmo formato de Artefato: Documento de Arquitetura de Software e dos modelos associados, desprovida de referências de projeto específicas ou com referências e características de projeto genéricas, a fim de que a Arquitetura de Referência possa ser classificada corretamente na base de ativos. Os modelos associados ao Documento de Arquitetura de Software (SAD) são o Modelo de Casos de Uso, o Modelo de Design, o Modelo de Implementação e o Modelo de Implantação.
O acesso ao SAD e aos modelos associados fornece vários pontos de entrada para o arquiteto de software, que pode optar por usar somente as partes conceituais ou lógicas da arquitetura (se a política de reutilização da organização permitir isso). Por outro lado, o arquiteto de software pode ser capaz de extrair da base de ativos subsistemas funcionais completos e um Modelo de Implantação no nível físico (ou seja, uma planta de hardware e de rede completa).
Outros artefatos de suporte são necessários para atribuir usabilidade aos ativos da arquitetura.
O Modelo de Casos de Uso descreve o comportamento da arquitetura, mas o arquiteto de software também precisará conhecer suas qualidades não-funcionais. Talvez o Modelo de Casos de Uso e os requisitos não-funcionais tenham sido anteriormente capturados em uma Especificação de Requisitos de Software. A partir dessa especificação, o arquiteto de software será capaz de determinar se a Arquitetura de Referência está atendendo satisfatoriamente ou não aos requisitos atuais.
O uso e, mais especificamente, a modificação da arquitetura precisam ter a mesma orientação do desenvolvimento original. Isso pode ser encontrado no Guia de Design. Por exemplo, o arquiteto de software precisará saber quais regras foram aplicadas na formação da Arquitetura de Referência e o grau de dificuldade que ele experimentará para modificar as interfaces. O acesso ao Guia de Design associado à Arquitetura de Referência pode ajudar a responder a essas perguntas.
(Opcional) A revisão de Planos de Teste relevantes também pode ser útil. Esses Planos de Teste informarão ao arquiteto sobre as estratégias de teste e de avaliação anteriormente usadas para testar arquiteturas similares que, como tal, podem vir a fornecer uma idéia das possíveis deficiências da arquitetura.
(Opcional) A revisão de Arquiteturas para Automatização de Teste e Especificações da Interface de Teste que sejam relevantes pode ser útil. Esses artefatos informam ao arquiteto sobre as solicitações que provavelmente serão feitas com relação à arquitetura para facilitar o teste.
A Arquitetura de Referência é usada na fase de iniciação e no início da fase de elaboração durante a síntese arquitetural e a seleção de uma sugestão de arquitetura. A criação da Arquitetura de Referência é uma questão organizacional e está no momento fora do escopo do RUP. Durante o fechamento do projeto, os artefatos criados durante o projeto serão examinados para verificar se algo pode ser obtido e retido na base de ativos da organização. As atividades e as técnicas empregadas para fazer isso, porém, não são elaboradas aqui.
O arquiteto de software é responsável pela seleção e pelo uso das Arquiteturas de Referência.
A menos que o sistema seja completamente sem precedentes, as Arquiteturas de Referência devem ser examinadas para fins de aplicabilidade (quanto ao domínio e ao tipo de desenvolvimento), caso elas existam e possam ser acessadas pela organização de desenvolvimento. A criação de Arquiteturas de Referência é uma questão a ser abordada no nível da organização. Com certeza, é possível diminuir a lista de conteúdo fornecida anteriormente e, ainda assim, conseguir tirar algum proveito da reutilização arquitetural. Por exemplo, o modelo de teste pode ser omitido, embora os testes tenham de ser escritos novamente caso a arquitetura seja modificada. No mínimo, pode-se esperar um modelo de design e uma descrição comportamental associada (talvez o Modelo de Casos de Uso). É difícil chamar de ativo a Arquitetura de Referência. Poderia ser também algum tipo de padrão válido (análise, design, etc.).
|
Rational Unified Process
|
