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

Note que para servir de ferramenta de comunicação, o documentoarquitetural deve ser construído de forma que respeite o conhecimento eas necessidades dos stakeholders. Para que isto seja possível, deve-se conhecerpara quem o documento está sendo escrito. Portanto, devemos escrever a arquiteturade forma que possua partes que interessem aos usuários, aos clientes, aos desenvolvedores,aos testadores, ao gerente de projeto ou a outros stakeholders envolvidosno processo.

Por exemplo, os usuários buscam pelas funcionalidades, capacidadese comportamento do sistema, não como ele foi dividido em módulos, como osmódulos se comunicam entre si ou se eles foram desenvolvidos do zero outiveram partes reutilizadas de outros sistemas. Clientes e gerentes têm algunsinteresses semelhantes, como custos de desenvolvimento ou cronograma delançamento. No entanto, os clientes também se preocupam com o alinhamentodo software ao seu negócio, enquanto o gerente procura como minimizar oscustos para se adequar ao orçamento, ou como as tarefas de implementaçãoserão divididas entre seu time de desenvolvimento. Finalmente, desenvolvedores e testadoresestão interessados em aspectos técnicos do design, por exemplo, qual a divisãoem módulos do sistema, quais as alternativas de design disponíveis ou como os atributosde qualidade (desempenho, escalabilidade, tolerância a faltas, etc.) devem serimplementados, cada um motivado pelo seu papel no processo de desenvolvimento.

Integridade conceitual

Por outro lado, o documento precisa demonstrar consistência entreos diversos aspectos do design da arquitetura para que haja comunicação e integridadeconceitual. A consistência é necessária porque, apesar da separação de preocupaçõesser uma ferramenta poderosa de design, as soluções para as diferentes preocupaçõestrabalham interligadas durante a implementação, ou seja, quando resolvem o problema.Assim, precisamos de integridade em dois níveis: entre os stakeholderse entre os diversos aspectos do documento de arquitetura.

A integridade conceitual entre stakeholders é a defendida porBrooks, em The Mythical Man-Month , porque facilita o sucesso no desenvolvimento de sistemasde software. Se os stakeholders – e principalmente os desenvolvedores –não têm em mente o mesmo design que se transformará em produto, são poucasas garantias de que o produto implementado será o projetado. Por isso, no processo,o documento de arquitetura serve para restringir eventuais “deslizes conceituais”em relação ao design arquitetural e prevenir futuras discordâncias entrestakeholders, inclusive de interesses similares. O [link] ilustra um caso de restrição aos desenvolvedores,mas que é benéfica por proporcionar a integridade conceitual entre timesde desenvolvimento. Este caso é a definição das interfaces entre dois serviçospresentes no sistema.