Mensagens do livro  (Page 2/2)

Cap. 5: stakeholders

Os stakeholders têm grande influência no design da arquitetura porque são eles que impõem os requisitos que o sistema deve atender. Por isso, para entendermos essa influência, devemos estudá-los. Os stakeholders demonstram essa influência porque possuem diversas responsabilidades durante o ciclo de vida do software. Neste capítulo apresentamos quem são os stakeholders do software mais comuns e suas características. As mensagens deste capítulo são:

• Stakeholders influenciam a arquitetura de diversas maneiras e não necessariamente estão de acordo entre si e é por isso que surgem os trade-offs durante o design do software.
• Os seguintes stakeholders devem ser considerados durante o projeto da arquitetura:
  • o próprio arquiteto ou outros futuros arquitetos;
  • os engenheiros de requisitos;
  • os designers;
  • os desenvolvedores;
  • os testadores;
  • os responsáveis pela integração do software com outros sistemas;
  • os mantenedores do software;
  • os designers de outros sistemas;
  • o gerente do desenvolvimento;
  • o time de controle de qualidade do software.
• O arquiteto deve ter pleno conhecimento de todo o ciclo de vida do software, para ser capaz de lidar com os trade-offs que surgirão entre os stakeholders.
• O arquiteto deve enteder a relação entre os stakeholders e os atributos de qualidade do software.

Cap. 6: atributos de qualidade

Uma vez que os atributos de qualidade do software são proporcionados, principalmente, por sua arquitetura e é por meio dos atributos de qualidade que o software atende aos requisitos não-funcionais, devemos estudar esses atributos. Este capítulo trata tanto dos requisitos não-funcionais quanto dos atributos de qualidade, enfatizando suas relações e ferramentas de design úteis para o alcance dos atributos. Usamos o modelo ISO/IEC 9126-1:2001 – mas não nos restringimos a ele – para definir a qualidade de software e os atributos que ele deve exibir para tanto. As mensagens deste capítulo são:

• A arquitetura se preocupa principalmente com os requisitos não-funcionais, não apenas técnicos, mas também relacionados a negócio.
• Não existe a arquitetura correta . Existems arquiteturas que são mais ou menos adequadas aos requisitos.
• A arquitetura permite uma forma de rastreamento entre a implementação do software e seus requisitos.
• A arquitetura de software permite diversos atributos de qualidade, entre eles:
  • desempenho;
  • escalabilidade;
  • confiabilidade;
  • disponibilidade;
  • segurança;
  • manutenibilidade;
  • portabilidade;
  • extensibilidade.

Cap. 7: técnicas de design arquitetural

Ao introduzirmos design de software, citamos alguns princípios e técnicas que são fundamentais ao processo, pois facilitam a representação e a escolha da solução entre as alternativas de design. No entanto, não fomos explícitos sobre como estes princípios e técnicas são fundamentais ao processo de design arquitetural. Já no capítulo sobre atributos de qualidade, mencionamos a existência de táticas arquiteturais que ajudam na implementação de alguns requisitos de qualidade, mas não apresentamos essas táticas a não ser de forma breve e apenas por meio de exemplos.

Este capítulo, por sua vez, tem como objetivo tanto apresentar os princípios de design em nível arquitetural, quanto apresentar algumas táticas arquiteturais que implementam requisitos de qualidade. Neste capítulo, descrevemos os seguintes princípios de design arquitetural:

• uso da abstração ou níveis de complexidade
• separação de preocupações
• uso padrões e estilos arquiteturais

Além disso, apresentamos diversas táticas arquiteturais para alcançarmos os seguintes atributos de qualidade:

• desempenho e escalabilidade
• segurança
• tolerância a faltas
• compreensibilidade e modificabilidade
• operabilidade

Cap. 8: documentação da arquitetura

Depois de entender os conceitos, a importância e ter noções de design de arquitetura, o leitor precisar saber como capturar a informação arquitetura e documentá-la. Conceitos de visões arquiteturais são introduzidos para facilitar a documentação das diferentes dimensões que uma arquitetura apresenta. Este capítulo pretende ser agnóstico a linguagens ou modelos de documentação de arquitetura, mas apresenta um exemplo de como fazê-lo. As mensagens deste capítulo são:

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