Finalidade
  • Definir uma sugestão de arquitetura para o sistema, com base na experiência obtida com sistemas semelhantes ou domínios de problema semelhantes.
  • Definir os padrões arquiteturais, os mecanismos principais e as convenções de modelagem para o sistema.
Função:  Arquiteto de Software  
Freqüência:  Opcionalmente, ocorre no início. Deve ocorrer na primeira iteração de elaboração. Pode se repetir em iterações posteriores, se for necessário explorar as inclusões ou alterações substanciais na arquitetura de software.

Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   
Informações Adicionais: 

Detalhes de Detalhamento do Fluxo de Trabalho::   

A análise arquitetural concentra-se em definir uma sugestão de arquitetura e restringir as técnicas arquiteturais a serem utilizadas no sistema. Ela conta com a experiência obtida com sistemas ou domínios de problema semelhantes para restringir e enfocar a arquitetura, de modo que o esforço não seja desperdiçado na redescoberta arquitetural. A análise arquitetural é vantajosa principalmente ao desenvolver sistemas novos, nunca vistos antes; além disso, em sistemas nos quais já exista uma arquitetura bem-definida, ela poderá ser omitida.

Desenvolver a Visão Geral da Arquitetura Para o início da página

Finalidade  Facilitar o planejamento do sistema, explorando e avaliando opções arquiteturais de alto nível. 
Levar ao patrocinador, às equipes de desenvolvimento e a outros envolvidos uma compreensão antecipada da estrutura de alto nível do sistema pretendido.

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 implantaçã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.

Avaliar os Recursos Disponíveis Para o início da página

Finalidade  Identificar os recursos que poderão ser relevantes para o projeto.
Analisar o ajuste e a lacuna entre os recursos e os requisitos do projeto.
Decidir por basear ou não áreas do sistema nos recursos.
Localizar e relacionar os recursos que possivelmente possam ser reaproveitados no projeto.
Executar uma avaliação preliminar para certificar-se de que o suporte necessário esteja potencialmente disponível.

É 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.

Definir a Organização de Nível Superior de Subsistemas Para o início da página

Finalidade Criar uma estrutura inicial para o Modelo de Design.

Quando o foco se encontra na execução da síntese arquitetural durante o início, esta etapa é excluída da atividade.

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 Atividade: 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 Diretrizes: Camadas.

Identificar as Abstrações-chave Para o início da página

Finalidade Preparar a análise, identificando as abstrações-chave (representação dos conceitos identificados durante a as atividades de requisito) que o sistema deve manipular.

Quando o foco se encontra 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 Artefato: Prova de Conceito Arquitetural e fornecer suporte para cenários de uso representativos.

As atividades Requisitos normalmente identificam os principais conceitos que o sistema deve estar apto a tratar; tais conceitos se manifestam como abstrações-chave de design. Por causa do trabalho já realizado, não há necessidade de repetir o trabalho de identificação novamente durante a Atividade: Análise de Caso de Uso.

Para tirar proveito do conhecimento existente, identifique as classes de análise de entidade preliminares que representam essas abstrações-chave, com base no conhecimento geral do sistema, como os Requisitos, o Glossário e, particularmente, o Modelo de Domínio, se você possui um.

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 ../glossary.htm#XE_analysis_pattern__definition_in_glossary -- This hyperlink in not present in this generated websitepadrõ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.

Identificar Interações Estereotipadas Para o início da página

Esta etapa só será incluída ao executar a Análise Arquitetural (esta atividade) como parte de Detalhes de Detalhamento do Fluxo de Trabalho:: Executar Síntese Arquitetural 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.

Desenvolver a Visão Geral da Implementação Para o início da página

Finalidade

Fornecer a base para a avaliação da visibilidade da implementação do sistema.
Entender a distribuição geográfica e a complexidade operacional do sistema.
Fornecer a base para as estimativas iniciais de custo e esforço.

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)
  • 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.

Identificar os Mecanismos de Análise Para o início da página

Finalidade Definir os mecanismos de análise e os serviços utilizados pelos designers para dar "vida" aos seus objetos.

Quando o foco se encontra na execução da síntese arquitetural durante o início, esta etapa é excluída da atividade.

É 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 ../glossary.htm#pattern -- This hyperlink in not present in this generated websitepadrã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 Conceitos: Mecanismos de Análise.

Rever os Resultados Ir para o início da página

Finalidade Assegurar que os resultados da análise arquitetural sejam completos e consistentes.

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 Pontos 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 desta atividade.



Rational Unified Process   2003.06.15