Identifique as metas arquiteturais

As metas arquiteturais fornecem a motivação e a justificava para a tomada de decisões. Essas metas são muitas vezes direcionadas pelos requisitos de software, particularmente os não-funcionais da Lista de Requisitos, porque nem sempre estão evidentes somente nos casos de uso.

As metas arquiteturais definem como o sistema precisa responder às mudanças ao longo do tempo. Considere estas questões ao escrever suas metas:

• Qual é a vida útil esperada do sistema?
• O sistema terá que responder às mudanças tecnológicas ao longo desse tempo, tais como novas versões de middleware ou outros produtos?
• Qual a freqüência esperada para o sistema se adaptar às mudanças?
• Quais alterações poderemos antecipar no futuro, e como podemos torná-las mais fáceis de tratar?

Estas considerações terão um efeito significante sobre a estrutura do sistema.

Identifique os requisitos arquiteturalmente significantes

Alguns requisitos serão mais significantes do que outros quando considerados a partir de uma perspectiva arquitetural. Sua identificação irá definir o subconjunto de requisitos que geralmente necessitam ser satisfeitos antes que a arquitetura possa ser estabilizada. Além disso, o sistema normalmente será mais sensível às mudanças nos requisitos arquiteturalmente significantes do que nos outros, então, a identificação e a comunicação do subconjunto irá ajudar aos outros a compreender as implicações potenciais da mudança.

Os requisitos podem ser arquiteturalmente significantes de forma explícita ou implícita. Os requisitos implicitamente significantes podem definir a essência do comportamento funcional do sistema (ex. a compra em uma loja on-line). Os requisitos explicitamente significantes são muitas vezes de natureza técnica, tais como metas de desempenho, necessidade de interface com outros sistemas, quantidade de usuários que deve ser suportada ou os requisitos de segurança.

Veja Determinar os Requisitos Arquiteturalmente Significantes para mais informações.

Identifique as restrições na arquitetura

Recolha informações sobre o ambiente existente e identifique quaisquer limitações na solução. Isso irá facilitar a integração com o ambiente, e pode reduzir os riscos, custos e duplicação de elementos da solução.

As restrições arquiteturais podem surgir de vários fatores:

Por exemplo, se a empresa utiliza apenas um tipo de banco de dados, você provavelmente irá tentar usá-lo o máximo possível para aproveitar as competências de administração de base de dados existentes, ao invés de apresentar um banco de dados novo.

Estas restrições arquiteturais, combinadas com os requisitos, irão ajudá-lo a definir uma candidata adequada para a arquitetura do sistema.

Pesquise, avalie e selecione dentre os recursos disponíveis

Para avaliar e selecionar recursos para reutilização em seu projeto, você precisa entender os requisitos do ambiente de sistema. Também é preciso entender o escopo e a funcionalidade geral do sistema que os Analistas de Negócios desejam. Existem vários tipos de recursos a considerar, incluindo (mas não limitado a): arquiteturas de referência; frameworks; padrões; mecanismos de análise; classes e a experiência. Você pode pesquisar nos repositórios de recursos (internos ou externos à sua organização) e na literatura industrial para identificar os recursos ou os projetos similares.

Você precisa avaliar se os recursos disponíveis contribuem para resolver os principais desafios do projeto atual e se são compatíveis com as restrições arquiteturais do projeto. Você também precisa analisar o grau de ajuste necessário entre os recursos e os requisitos, considerando se qualquer um dos requisitos é negociável (para permitir a utilização do recurso). Avalie também se o recurso pode ser alterado ou estendido para satisfazer os requisitos, bem como quais as negociações necessárias para a sua adoção, em termos de custos, riscos e funcionalidade.

Decida finalmente, a princípio, se pretende utilizar um ou mais recursos, e registre a razão para esta decisão.

Defina a abordagem para estruturar o sistema

A estruturação do sistema lhe ajuda a gerenciar a complexidade, utilizando a conhecida estratégia de "dividir para conquistar". Pela divisão do processo em partes menores e mais manejáveis, você torna o desenvolvimento mais fácil.

A divisão em camadas é uma das abordagens mais comumente usadas para estruturar e decompor sistemas. Cada camada agrupa classes ou componentes semelhantes, que comunicam na medida do possível apenas com camadas adjacentes. Veja Guideline: Dividir em camadas para mais informações.

Você não define quais camadas contêm quais classes ou componentes. Ao invés, você define quantas camadas você precisará e que tipos de camadas você irá usar. Por exemplo, se você está desenvolvendo um novo sistema de middleware, você provavelmente não precisará de uma camada de negócio. Mais tarde, durante as atividades de design, você decidirá quais classes e componentes irão popular estas camadas.

Defina a abordagem para implantar o sistema

Desenvolva uma visão geral de alto nível de como o software será implantado. Por exemplo, determine se o sistema necessita ser acessado remotamente, ou tem requisitos que sugerem distribuição em vários nós. Algumas fontes de informação a considerar são:

• usuários em locais geográficos
• organização dos dados do negócio
• requisitos de nível de serviço
• restrições (tais como requisitos de interface com sistemas legados)

Valide se a visão geral da implantação suporta usuários (especialmente os usuários em locais remotos, se for necessário) executando cenários de uso típico e satisfazendo os requisitos não funcionais e as restrições. Valide se os nós e as ligações são suficientes para suportar as interações entre os componentes em diferentes nós, e entre os componentes e seus dados armazenados.

Identifique as principais abstrações

Os requisitos e as tarefas de análise normalmente mostram comportamentos e conceitos fundamentais que o sistema deve ser capaz de lidar.

Os conceitos manifestam-se no design como abstrações importantes. Os principais comportamentos devem se correlacionar com os cenários identificados como parte dos requisitos arquiteturalmente significantes e representar as interações importantes entre as principais abstrações.

Os produtos de trabalho Visão e Glossário são boas fontes para as principais abstrações. Estas abstrações são frequentemente de fácil identificação porque representam coisas que são importantes para o negócio. Por exemplo, Cliente e Conta são principais abstrações típicas do negócio bancário.

As abstrações que estejam identificadas até este ponto também irão provavelmente mudar e evoluir no decurso do projeto. O objetivo desta etapa não é identificar o grupo completo de classes e relacionamentos que irão sobreviver no design. Ao invés, ela serve para identificar os conceitos importantes que o sistema deve tratar. O benefício de elencá-las no início do projeto é que todos na equipe possam compreender a importância destes conceitos e desenvolver um software coerente para lidar com elas de forma consistente.

Não gaste muito tempo descrevendo abstrações detalhadas neste estágio inicial, porque existe o risco disso resultar na identificação de classes e relacionamentos que a solução não necessitará realmente. Quando da identificação das principais abstrações, pode ser útil definir também qualquer relacionamento óbvio que exista entre elas. Elas podem ser capturadas em uma tabela ou em diagramas (em uma ferramenta ou quadro branco), com uma descrição resumida para cada uma. Em geral, não se deve investir na definição de um conjunto de relacionamentos altamente detalhados neste estágio inicial do design. Os relacionamentos irão se tornam mais concretos e detalhados posteriormente e provavelmente irão modificar estes pressupostos precoces.

Capture as decisões arquiteturais

Muitas vezes é útil registrar as principais decisões arquiteturais e trabalhar as suposições em um diagrama de visão geral da arquitetura para tornar mais fácil a comunicação da arquitetura para a equipe do projeto e os Analistas de Negócios. Essa informação deve ser parte da descrição da arquitetura, mas pode variar no formato para satisfazer as necessidades do projeto. Por exemplo, em um projeto ágil e de baixa cerimônia o diagrama de visão geral pode ser uma foto informal do story board ou um gráfico com ícones em um quadro branco ou uma ferramenta de desenho. A ilustração tem que mostrar a natureza da solução proposta, convergir as idéias regentes e representar os principais blocos de construção.

As decisões arquiteturais devem ser capturadas no Artifact: Caderno de Arquitetura.

Se um sistema mais complexo for necessário, então, a arquitetura pode ser representada como um conjunto mais compreensivo de visões que descrevam a arquitetura a partir de uma série de pontos de vista. Veja Visão Arquitetural para mais informações.

Capturar decisões arquiteturais (Modelagem Visual)

Você pode achar útil desenvolver estes três diagramas da Linguagem Unificada de Modelagem (UML) nesta fase:

• Mapa de camadas (representado como um diagrama de classes usando pacotes), que descreve as camadas de nível superior da arquitetura
• Esboço do diagrama de implantação, que descreve a topologia de rede esperada
• Diagrama de classes simples, que mostra as principais abstrações e qualquer relacionamento evidente entre elas