0.7 Documentação da arquitetura  (Page 25/25)

Resumo

O objetivo deste livro não é só fazer com que o leitor saiba projetararquiteturas, mas também que tenha noções de como documentar o projeto. Dessa maneira,o objetivo deste capítulo foi fazer com que o leitor conheça a importância e atécnica primordial da documentação da arquitetura, que é representá-la por meio de múltiplasvisões. Assim, esperamos que a partir de agora o leitor, além de conhecer algunsconjuntos de pontos de vista arquiteturais de referência, seja capaz de entender que:

• O documento de arquitetura auxilia no processo de design, é umaferramenta de comunicação entre stakeholders e pode servir de modelo de análisedo software;
• Toda informação presente numa arquitetura é uma decisão arquitetural;
• Decisões arquiteturais podem ser existenciais, descritivasou executivas;
• Decisões arquiteturais se relacionam, podendo restringir,impedir, facilitar, compor, conflitar, ignorar, depender ou ser alternativaa outras decisões arquiteturais; e
• Um único diagrama não é suficiente para conter a quantidadede informação que deve ser mostrada por um arquiteto. Por isso, a necessidadede múltiplas visões arquiteturais;

Referências

Benefícios da documentação

Muitos autores afirmam que a documentação do design arquiteturalé benéfica para o processo de desenvolvimento do software. Além dos trabalhos járeferenciados ao longo do texto, citamos: o livro The Art of Systems Architecting [link] de Maier e Rechtin, que descreve os benefíciosproporcionados quando o documento de arquitetura é consistente entre suasmúltiplas visões; o artigo de Wirfs-Brock, Connecting Design with Code [link] , que cita a importância de documentar as decisõesde design em diversos níveis de detalhe, inclusive o arquitetural; o livro Software Architecture: Foundations, Theory,and Practice [link] , de Taylor et al , que mostra este assunto de forma bemabrangente; e o livro Code Complete [link] , de McConnell, que afirma a arquitetura é uma ferramentapara o controle da complexidade do software.

Arquitetura como conjunto de decisões

O documento de arquitetura descrito como um conjunto de decisõesarquiteturais é o tema de diversos artigos. Entre eles, podemos citar: Building Up and Reasoning About ArchitecturalKnowledge [link] , An Ontology of Architectural Design Decisionsin Software Intensive Systems [link] e The Decision View's Role in Software ArchitecturePractice [link] , de Kruchten et al e que são focados em descrever a arquitetura como decisões arquiteturais e em montarum arcabouço conceitual de como descrever decisões arquiteturais, propondo inclusiveum ponto de vista neste sentido; Architecture Knowledge Management: Challenges,Approaches, and Tools [link] , de Babar e Gorton, que mostram ferramentas paraorganizar e documentar as decisões arquiteturais; e The Decision View of Software Architecture [link] , de Dueñas e Capilla, e Software Architecture as a Set of ArchitecturalDesign Decisions [link] , de Jansen e Bosch, que mostram a importânciadas decisões na arquitetura.

Visões e pontos de vista

Além dos trabalhos que apresentam conjuntos de pontosde vista e que já foram referenciados na Seção "Visões arquiteturais" , podemos citar o livro Software Design [link] , de Budgen, que afirma que diferentes representaçõeslidam com diferentes qualidades e interesses, além de mostrar alguns benefícios dese documentar a arquitetura por meio de visões. Já o artigo Four Metaphors of Architecture in Software Organizations:Finding Out the Meaning of Architecture in Practice [link] , de Smolander, descreve como alguns stakeholders percebema arquitetura na prática e assim justificao uso de visões arquiteturais. Por fim, citamos o livro Applied Software Architecture [link] , de Hofmeister et al , que apresenta mais um conjunto de pontosde vista.

Ferramentas para análise

Em relação a análises baseadas em inspeções, citamos o livroda série do SEI, Evaluating Software Architectures [link] , de Clements et al , que descreve os métodos SAAM, ATAMe ARID, inclusive com estudos de casos.

Já sobre ADLs, citamos dois surveys sobre o assunto: um conduzido por Clements, A Survey of Architecture Description Languages [link] , e outro por Taylor e Medvidovic, A Classification and Comparison Framework for SoftwareArchitecture Description Languages [link] .

E, finalmente, apresentamos alguns trabalhos sobre verificaçãode conformidade: Software Reflexion Models: Bridging TheGap Between Design and Implementation [link] e Software Reflexion Models: Bridging TheGap Between Source and High-Level Models [link] , por Murphy et al ; Bridging the Software Architecture Gap [link] , de Lindvall e Muthig; e Design tests: An approach to programmaticallycheck your code against design rules [link] , de Brunet et al .