A visão geral da arquitetura é criada no início do ciclo de vida de um projeto, possivelmente já na fase inicial. Ela reflete as hipóteses de trabalho e as decisões iniciais sobre a implementação da visão, bem como as decisões relacionadas à arquitetura física e lógica e aos requisitos não funcionais do sistema. Produzida pela arquitetura de software, muitas vezes em colaboração com o patrocinador do projeto, a visão geral assume a forma de um gráfico irônico ou de uma seqüência de esboços ilustrativos rica e informal. Conceitualmente, ela ilustra a natureza essencial da solução proposta, transmitindo as idéias dominantes e incluindo os principais componentes. O nível de formalidade da visão geral da arquitetura depende do projeto. Por exemplo, em um projeto grande, com alto grau de formalidade, talvez seja necessário capturar a visão geral da arquitetura nas seções apropriadas do documento de Arquitetura de Software a fim de revisá-lo formalmente.

Nesse ponto, a visão geral da arquitetura é uma condição inicial provisória. Não tome por base as confirmações no diagrama da visão geral da arquitetura até que um protótipo arquitetural executável a tenha validado, incluindo preocupações com design, implementação e implementação.

Tenha por base uma arquitetura de referência, outros padrões arquiteturais ou ainda outros recursos arquiteturais.

Leve em conta seu desejo ou não de refinar e manter o diagrama da visão geral da arquitetura, para que sirva de veículo de comunicação.

Muitos sistemas ficam restritos a serem desenvolvidos e implementados em um ambiente de hardware e software existente; nesses casos, o arquiteto de software reunirá informações sobre o ambiente atual.

Por exemplo, no desenvolvimento de um sistema de e-business, as seguintes informações são pertinentes:

• design físico e lógico da rede existente
• design de banco de dados e dos bancos de dados existentes
• ambiente Web existente (servidores, firewalls, etc.)
• ambiente de servidor existente (configuração, versões de software, upgrades planejados)
• padrões existentes (rede, nomenclatura, protocolos, etc.)

Tais informações podem ser capturadas textualmente ou em um Modelo de Implementação.

É necessário conhecer os requisitos do ambiente para o qual os recursos estão sendo considerados e também o escopo do sistema, bem como a funcionalidade geral exigida. Para identificar recursos ou projetos semelhantes, procure nas bases de recursos organizacionais e em materiais impressos relacionados ao segmento de mercado. Existem vários tipos de recursos a serem considerados, tais como, modelos do segmento de mercado, estruturas, classes e experiência (mas não se limitando a esses recursos). É preciso que você avalie se os recursos disponíveis contribuem para a resposta aos principais desafios do projeto atual e se são compatíveis com as restrições do projeto.

Analise a extensão do ajuste entre o recurso e os requisitos do cliente, considerando se algum dos requisitos pode ser negociado (para permitir o uso do recurso).

Não se esqueça de avaliar se o recurso pode ser modificado ou estendido para satisfazer os requisitos e quais as respostas comuns em termos de custo, risco e funcionalidade provenientes da adoção do recurso.

Por último, decida, em princípio, utilizar ou não um ou mais recursos e documente os fundamentos da decisão.

Quando o foco está na execução da síntese arquitetural durante a iniciação, esta etapa é excluída da tarefa.

Normalmente, o modelo de design é organizado em camadas - um padrão arquitetural comum para restringir aos sistemas de grande porte. O número de camadas não é fixo, mas varia de acordo com a situação.

Durante a análise arquitetural, geralmente você se concentra em duas camadas de nível superior; isto é, as camadas de aplicativos e específicas do negócio. Esse é o significado de organização de nível superior de subsistemas. As demais camadas de nível inferior serão consideradas em Tarefa: Incorporar Elementos de Design Existentes. Se você estiver utilizando padrões arquiteturais específicos, os subsistemas serão definidos por meio do gabarito arquitetural desse padrão.

Para saber mais sobre camadas, consulte Diretriz de Produto de Trabalho: Divisão em Camadas.

Quando o foco está na execução da síntese arquitetural, essa etapa é executada até a extensão necessária para orientar o arquiteto de software na seleção dos recursos relativos à construção do Produto de Trabalho: Prova de Conceito Arquitetural e fornecer suporte para cenários de uso representativos.

Tarefas de requisitos e, quando aplicável, tarefas de Modelagem de Negócio normalmente revelam os principais conceitos que o sistema deve estar apto a tratar; tais conceitos se manifestam como abstrações-chave de projeto. Por causa do trabalho já realizado, não há necessidade de repetir o trabalho de identificação novamente durante a Tarefa: Análise de Caso de Uso.

Você pode tirar proveito do conhecimento existente, identificando as classes de análise de entidade preliminares que representam essas abstrações-chave, com base no conhecimento geral do sistema, tais como os Requisitos, o Glossário e, particularmente, o Modelo de Domínio ou o Modelo de Análise de Negócio, se você tiver feito.

Quando você define as abstrações-chave, também são definidas todas as relações existentes entre classes de entidade. Apresente as abstrações-chave em um ou vários diagramas de classes e crie uma descrição resumida para cada uma. Dependendo do domínio e da inovação do sistema, é provável que já existam padrões de análise que capturam muitas das abstrações-chave exigidas para modelar o sistema. O uso de tais padrões (que já deverão ter sido implementados com êxito no domínio) diminuirá consideravelmente a responsabilidade intelectual de identificar os conceitos importantes que devem ser representados.[FOW97a] apresenta alguns padrões de análise bastante úteis para a modelagem de sistemas de negócio, mas que talvez sejam aplicáveis em outros contextos. Outro exemplo seria o OMG (Object Management Group), que também tenta definir interfaces e protocolos para diversos domínios por meio do trabalho de seu Comitê de Tecnologia de Domínio e forças tarefas associadas. É inevitável que esse trabalho leve à identificação de abstrações importantes no domínio.

As classes de análise identificadas neste ponto provavelmente mudarão e se expandirão no decorrer do projeto. A finalidade deste passo não é identificar um conjunto de classes que permanecerão no design, mas sim identificar os conceitos-chave a serem tratados pelo sistema. Não gaste muito tempo descrevendo detalhadamente as classes de entidade nesse estágio inicial, pois você correrá o risco de identificar classes e relações não efetivamente necessárias para os casos de uso. Lembre-se de que você encontrará mais classes de entidade e relacionamentos ao analisar os casos de uso.

Esta etapa é incluída apenas quando se desempenha essa tarefa no início.

A finalidade desta etapa é identificar as interações, entre as abstrações-chave no sistema, que caracterizam ou representam tipos significativos de atividade no sistema. Essas interações são capturadas como Realizações de Casos de Uso.

Desenvolva uma visão geral de nível superior de como o software é implementado. Por exemplo, se o sistema precisa ser acessado remotamente ou se possui requisitos que sugerem distribuição em nós múltiplos. Algumas fontes de informações a serem consideradas são:

• usuários (nos locais), definidos em Perfis de Usuário (na Visão) e casos de uso (no Modelo de Caso de Uso)
• organização de dados de negócio (no Modelo de Análise de Negócio e Modelo de Design, quando disponível)
• requisitos de serviço (nas Especificações Suplementares)
• restrições (nas Especificações Suplementares, tais como requisitos para interface com sistemas legados)

Se um sistema distribuído incomum for necessário, um Modelo de Implementação poderá ser utilizado para capturar a relação entre os nós. Isso deve incluir provisoriamente a designação de componentes e dados para os nós e indicar como os usuários acessarão os componentes que acessam dados. A especificação detalhada de nós e conexões será adiada, exceto quando for importante para o cálculo ou a avaliação da viabilidade. Recursos existentes poderão ser utilizados, se houver recursos apropriados disponíveis. Embora este seja o primeiro modelo de implementação produzido no projeto, de forma rápida e em um alto nível, ele poderá identificar produtos reais de hardware e software, se conhecidos ou se for importante para tomar essas decisões de seleção nesse momento.

Confirme se o modelo de implementação suporta usuários (especialmente usuários em locais remotos, se isso for necessário), executando casos de uso típicos e ao mesmo tempo cumprindo com as restrições e os requisitos não funcionais. Confirme se os nós e as conexões são adequados para permitir as interações entre os componentes nos diferentes nós e entre os componentes e os respectivos dados armazenados.

Quando o foco está na execução da síntese arquitetural durante a iniciação, esta etapa é excluída da tarefa.

É possível identificar mecanismos de análise de cima para baixo (conhecimento a priori) ou de baixo para cima (descobertos no decorrer no processo). No modo de cima para baixo, a experiência orienta o arquiteto de software a reconhecer determinados problemas no domínio que exigirão tipos de soluções específicos. Mecanismos de persistência, gerenciamento de transações, gerenciamento de falhas, serviço de mensagens e inferência são exemplos de problemas arquiteturais comuns que podem ser expressos como mecanismos durante a análise. O aspecto comum a todos esses mecanismos é que cada um deles representa um recurso geral de uma ampla classe de sistemas e oferece a funcionalidade que interage com ou suporta a funcionalidade básica dos aplicativos. Os mecanismos de análise suportam os recursos contidos nos requisitos funcionais básicos do sistema, independentemente da plataforma em que são implantados ou da linguagem de implementação. Os mecanismos de análise também podem ser projetados e implementados de várias formas; geralmente, haverá mais de um mecanismo de design correspondente a cada mecanismo de análise e talvez mais de uma forma de implementar cada mecanismo de design.

Na abordagem de baixo para cima, os mecanismos de análise são, em última instância, criados - da forma como o arquiteto de software vê, talvez vaga inicialmente, o que costuma ocorrer devido à existência de várias soluções para diversos problemas. É necessário permitir de alguma forma que os elementos dos diferentes encadeamentos sincronizem seus relógios; além disso, deve haver um modo comum de alocar recursos. Os mecanismos de análise, que simplificam a linguagem da análise, se formam a partir desses padrões.

A identificação de um mecanismo de análise consiste em reconhecer a existência de um problema secundário comum e talvez implícito (no sentido daquilo que é implicado pelos requisitos do sistema) e nomeá-lo. Inicialmente, não importa o nome; por exemplo, o arquiteto de software reconhece que o sistema exigirá um mecanismo de persistência. Por fim, esse mecanismo será implementado através da colaboração de uma sociedade de classes (consulte [BOO98]), algumas das quais não oferece funcionalidade de aplicativo diretamente, mas existem apenas como suporte. Muito freqüentemente, essas classes de suporte ficam nas camadas intermediárias ou inferiores de uma arquitetura em camadas, fornecendo, assim, a todas as classes de nível de aplicativo um serviço de suporte comum.

Se o problema secundário identificado for comum o suficiente, talvez exista um padrão a partir do qual o mecanismo possa ser instanciado - ligando as classes existentes e implementando novas classes como exigido pelo padrão. Um mecanismo de análise produzido dessa forma será abstrato e exigirá posteriormente um refinamento por meio do design e da implementação.

Para obter informações adicionais, consulte Conceito: Mecanismos de Análise.

Quando a Análise Arquitetural for concluída, revise os mecanismos arquiteturais, os subsistemas, os pacotes e as classes que foram identificados para certificar-se de que estejam completos e consistentes. Como os resultados da Análise Arquitetural são preliminares e relativamente informais, as revisões devem ser igualmente informais. Cenários ou casos de uso podem ser utilizados para confirmar as opções arquiteturais feitas em diversos níveis, desde a perspectiva do negócio até as interações específicas que ocorrem.

Consulte Lista de Verificação: Documento de Arquitetura de Software - Considerações sobre a Análise Arquitetural para obter informações adicionais sobre como avaliar os resultados dessa tarefa.