6. Tarefas - Disciplina de Arquitetura

A Disciplina de Arquitetura reúne de forma lógica todas as atividades relativas ao processo de elaboração da arquitetura do sistema, preocupando-se com a entrega de uma arquitetura robusta e estável e que atenda aos requisitos especificados, funcionais e não funcionais. Essa disciplina recebe ênfase na fase de Elaboração no Ciclo de Vida de Projeto.

A Disciplina de Arquitetura é composta por duas tarefas:
  • Elaborar Arquitetura
  • Refinar Arquitetura







O objetivo desta Tarefa é desenvolver a arquitetura da solução proposta através da análise dos requisitos relevantes para a arquitetura e identificar as restrições e objetivos da arquitetura. Além disso, essa tarefa busca esboçar a arquitetura por uma abordagem técnica que contemple os requisitos de projeto, considerando as restrições inerentes à solução e as restrições inerentes à equipe de desenvolvimento.
Em relação à equipe de desenvolvimento, a arquitetura também tem um papel fundamental que é o de atuar como um guia das ações da mesma (desenvolvimento e teste).
É importante que as experiências anteriores da equipe de desenvolvimento e dos arquitetos de software sejam levadas em consideração, buscando evitar esforços ao desenvolver componentes que já existam ou que possuam versões similares. É a velha máxima do "não reinventar a roda".
Todos os resultados devem ser devidamente documentados e compartilhados entre os diversos membros da equipe, servindo como futura referência para a compreensão da abordagem técnica utilizada.

O processo de construção da arquitetura não é estático, ou seja, nunca acaba. Da mesma forma que os requisitos são dinâmicos, também o é a arquitetura da solução proposta. Como o Processo Unificado é iterativo, então a arquitetura deve ser constantemente refinada para estar sempre adequada aos requisitos propostos.

A tarefa Elaborar Arquitetura pode ser dividida nos seguintes passos:
 
Identificar as metas arquiteturais - Trabalhar com a equipe para descrever as metas remanescentes da arquitetura e definir quais elementos serão implementados a cada iteração. É importante que a arquitetura esteja devidamente elaborada e que as prioridades da mesma estejam definidas. Lembre-se que as prioridades (ou riscos) definem a sequência de desenvolvimento das funcionalidades. É fundamental relembrar que requisitos são dinâmicos e que os mesmos (bem como as respectivas arquiteturas) devem ser constatemente revisados.

 
Identificar os requisitos significantes arquiteturalmente - É necessário identificar quais são os requisitos que são significantes para a especificação da arquitetura. Explore e refine os requisitos que devem ser implementados para de forma a concretizar as metas arquiteturais para a iteração corrente.

 
Identificar restrições na arquitetura - É função da equipe de desenvolvimento identificar quaisquer restrições na arquitetura e possíveis concorrências sobre recursos diversos em vários requisitos. Decida como a arquitetura irá resolver esses impasses. Justifique cada uma decisão tomadas para solucionar essas contendas. Revise a lista de restrições regularmente para assegurar que as mesmas continuam válidas.

Identificar as abstrações chaves - É fundamental que a equipe de desenvolvimento da arquitetura identifique os principais conceitos e abstrações que o sistema precisará. A especificação dos requisitos é a principal fonte para a identificação dessas abstrações chaves. Num primeiro estágio, não é necessário dedicar muita atenção a especificação dessas abstrações, evitando a definição de uma arquitetura que possa extrapolar o escopo do projeto. Lembre-se que o processo iterativo de desenvolvimento permite o refinamento de seus elementos, inclusive da arquitetura. Esses conceitos iniciais da arquitetura podem ser inicialmente esboçados através de um diagrama de classes, apresentando o relacionamento entre as abstrações.

 
Identificar as oportunidades de reuso - Através da observação das Abstrações Chaves, identifique em sistemas legados desenvolvidos por sua equipe a possibilidade de reuso de componentes diversos. Busque identificar também possíveis componentes da nova aplicação que podem ser reutilizados em outros sistemas que serão desenvolvidos.

 
Definir a abordagem de componentização - Definir como particionar o software em desenvolvimento, tanto de forma física quanto lógica, auxilia no processo de gerência da complexidade do mesmo, na possibilidade de reuso dos componentes, visando tornar assim, mais fácil o processo de desenvolvimento do software. Uma ferramenta interessante para ajudar no processo de definição dos componentes é utilizar o Diagrama de Implantação, da UML. O processo de componentização deve considerar:
  • Como particionar o software para o processo de gerenciamento de desenvolvimento;
  • Como o software será composto em tempo de execução.
Definir a abordagem de implantação do sistema - Esboçar como os componentes e pacotes serão implantados, bem como, esboçar a forma como os componentes serão distribuídos pela rede corporativa.

 
Identificar as interfaces externas ao sistema - Nesse ponto é importante identificar as diversas interfaces externas ao sistema. Por interface podemos entender uma chamada a uma API, uma comunicação via TCP/IP, um equipamento externo, etc. A definição do processo de comunicação com essa interface deve ser feita em alto níve.

Ao término dessa tarefa, é importante que a equipe de desenvolvimento garanta a integridade e coesividade dessa arquitetura. Todas as discussões entre os membros da equipe devem ser anotadas para futuras discussões e refinamentos da arquitetura proposta.









O propósito dessa tarefa é refinar a arquitetura ao nível de detalhes que permita o desenvolvimento das atividades de implementação. Esta tarefa é elaborada sobre o esboço da arquitetura e tem como principal objetivo eliminar possíveis ambiguidades e lapsos de funcionalidades não implementados. São levados em conta quaisquer Produtos de Trabalho que tenham sido desenvolvidos anteriormente.
A arquitetura deve apresentar a estrutura e o comportamento da solução proposta, servindo como subsídio para o processo de implementação. 
A meta final dessa Disciplina é transformar a arquitetura proposta em uma Arquitetura Executável. 
Uma Arquitetura Executável é uma implementação que realiza a Arquitetura de Software. É utilizada para validar se os requisitos especificados estão corretamente implementados. 
Cada versão da Arquitetura Executável deve ser mais completa, robusta e estável que sua versão anterior. A versão final da Arquitetura Executável deve contemplar todos os requisitos especificados.

A Tarefa Refinar Arquitetura pode ser dividida nos seguintes passos:

Refinar as metas e os requisitos relevantes para a arquitetura - É importante que os membros da equipe de Requisitos e de Arquitetura trabalhem em conjunto com os Stakeholders para revisar as metas e os requisitos relevantes para a arquitetura e os refinem quando necessário. É importante lembrar sempre da velha máxima: "Requisitos são dinâmicos". Novos requisitos possam ser introduzidos ou que requisitos já estruturados na arquitetura sejam eliminados, bem como, é possível que as prioridades dos requisitos sejam alteradas.

Identificar os Elementos Relevantes para a Arquitetura - Identificar os elementos de design relevantes para a Arquitetura (componentes, classes, subsistemas, etc.) e identificá-los de forma clara e única é uma das principais metas desse passo. Algumas das principais fontes para identificação desses elementos são:
  • Requisitos relevantes para a arquitetura - Destacar as áreas da arquitetura que atuam na realização dos requisitos;
  • Abstrações chaves;
  • Componentes que encapsulam a interface da solução com sistemas endêmicos;
  • Design Patterns - Aplique Design Patterns de acordo com as necessidades da arquitetura.
Identificar os componentes do sistema auxilia no processo de encapsulamento das diversas partes do sistema e auxilia a equipe de desenvolvimento a manter um alto nível de compreensão da solução proposta. O encapsulamento garante que um componente mantenha uma estrutura coesa, ao mesmo tempo que possui uma interface limitada com os demais componentes, protegendo seus detalhes internos. Dessa forma, a interface deixa de ser apenas uma assinatura mas destaca o que os componentes precisam, quais dados eles podem utilizar e como eles dependem desses dados.

A identificação e definição dos componentes da solução podem ser baseadas em Camadas Arquiteturais, Definições de Deployment (implantação) ou Abstrações Chaves. Para auxiliar nesse processo, faça os seguintes questionamentos:
  • O que está logicamente ou funcionalmente relacionado (casos de uso ou serviços, por exemplo)?
  • Quais classes modelo provêem serviços para outras classes modelos?
  • Quais classes modelo estão forte ou fracamente relacionadas a outras classes modelo?
  • Quais classes modelo podem ser alteradas de forma independente?
  • Quais partes dos componentes podem sofrer restrições por requisitos de performance?
A cada componente identificado, descreva brevemente as suas funcionalidades.

Definir a Arquitetura de Desenvolvimento e a Arquitetura de Teste - O objetivo desse passo é assegurar que as arquiteturas de Desenvolvimento e de Teste estejam definidas. É importante notar qualquer diferença arquitetural significante entre esses ambientes e é função da equipe de desenvolvimento e de testes trabalhar para que essas diferenças sejam eliminadas, bem como, os riscos introduzidos por essas diferenças.


Identifique Oportunidades de Reuso - Esse passo busca assegurar que os arquitetos de software busquem continuadamente por possibilidades de reuso de componentes entre os diversos Produtos de Trabalho gerados pela equipe de desenvolvimento. Sempre que possível, é conveniente para a equipe que os componentes sejam projetados para que possar ser reutilizados.

Validar a Arquitetura - É função do Arquiteto garantir que a arquitetura contemple todos os requisitos e necessidades dos Stakeholders. As atividades de desenvolvimento devem ser executadas de modo a produzir somente o software necessário para confirmar que a arquitetura é viável e atende aos requisitos especificados, além de prover a base definitiva para a validar a adequação da arquitetura. Como o software será desenvolvido iterativamente, diversos incrementos da solução podem ser necessários para validar a arquitetura.
O amadurecimento da arquitetura ocorre com o decorrer das iterações nas duas primeiras fases do Ciclo de Vida de Projeto durante o desenvolvimento da solução, sendo que a estabilidade deve ser atingida (é desejado) ao término da Fase de Elaboração.

Comunicar Decisões - O arquiteto de software deve garantir que todos os membros da equipe de desenvolvimento que dependam da arquitetura devem ter acesso à mesma e, principalmente, compreendê-la e estar capacitado para trabalhar com a mesma. É necessário garantir que a arquitetura transmita não somente a descrição estrutural e comportamental da solução mas também o porque das decisões tomadas em sua elaboração, ou seja, a conformidade com os requisitos.