Mensagens do livro

O conteúdo deste livro está dividido em seis capítulos (além dos capítulos de estudos de caso) e cada capítulo serve para transmitir um conjunto específico de mensagens sobre a disciplina de Arquitetura de Software. Além de mensagens, há outros dois tipos de elementos que são essenciais para a composição de livro: definições, que descrevem os conceitos fundamentais, e boas práticas, que são recomendações a serem seguidas pelo leitor ao aplicar o conhecimento presente no livro. As recomendações têm um papel importante, principalmente, nos estudos de caso, quando o lidamos com os diversos trade-offs presentes na prática de Arquitetura de Sotware.

A seguir, apresentamos os capítulos e suas mensagens:

Cap. 2: introdução a design de software

Neste capítulo apresentamos design de software e mostramos que ele é essencial no processo de desenvolvimento de software independentemente do nível de detalhe em que ele é aplicado. No entanto, o design de alto nível é enfatizado, uma vez que projetar arquitetura é fazer design em alto nível. Mostramos também os elementos que compõem os problemas de design. As mensagens do capítulo são:

• O design é a estrutura ou o comportamento de um sistema que resolve ou contribui para a resolução das forças que atuam sobre esse sistema.
• Um design representa apenas um ponto no espaço de decisão.
• Um design pode ser singular, representando apenas uma folha na árvore de decisões,, ou coletivo, representando um conjunto de decisões.
• São cinco os elementos que compõem os problemas de design: objetivos, restrições, alternativas, representações e soluções.
• Design é necessário em todos os níveis de detalhe durante o processo de desenvolvimento do software.

Cap. 3: estudo de caso: sasf

Neste capítulo, ilustramos a necessidade de aplicar os conhecimentos de Arquitetura de Software por meio de um problema de design complexo. Nele, apresentamos tanto os requisitos de um sistema web de locação e transmissão de vídeos quanto seus stakeholders. Uma vez que este capítulo apenas descreve um caso, não há mensagens explícitas a serem transmitidas.

Cap. 4: fundamentos de arquitetura de software

Este capítulo apresenta a definição de Arquitetura de Software usando um padrão ISO/IEEE. Como a definição apenas não é o bastante para entendermos o porquê de se aplicar os conhecimentos de arquitetura durante o ciclo de desenvolvimento, mostramos seus benefícios explicitamente através de exemplos e o estudo de caso. Além da definição ISO/IEEE, mostraremos outras definições que diversos autores fizeram ao longo da história, uma vez que elas expõem características importantes para o entendimento do assunto. As mensagens deste capítulo são:

• Arquitetura é design, mas nem todo design é arquitetural. É o arquiteto quem define a fronteira entre o design arquitetural e o não-arquitetural, definindo quais decisões serão necessárias para atender aos objetivos de desenvolvimento, de comportamento e de qualidade do sistema.
• A arquitetura também é um veículo de comunicação entre stakeholders.
• A arquitetura contém as decisões antecipadas de design, que têm o impacto mais caro (caso seja necessário mudá-las ou caso elas estejam erradas).
• A arquitetura é uma abstração transferível do sistema.
• A arquitetura facilita a construção do sistema.
• A arquitetura facilita o entendimento do sistema.
• A arquitetura facilita o reuso durante o ciclo de vida do sistema.
• A arquitetura facilita a evolução do sistema.
• A arquitetura facilita a análise do sistema.
• A arquitetura facilita a gerência durante o desenvolvimento do sistema.
• Documentar a arquitetura ajuda no controle intelectual do software.
• Documentar a arquitetura ajuda a manter a integridade conceitual do sistema.
• A arquitetura do software restringe o vocabulário de alternativas de design.
• Documentar a arquitetura permite a ligação entre os requisitos e as decisões de design do software.
• Documentar a arquitetura tem impacto negativo na imprecisão da especificação, que é fonte de complexidade do sistema.
• Documentar a arquitetura ajuda na divisão de tarefas entre os times de desenvolvimento.