Skip to content Skip to navigation

Connexions

You are here: Home » Content » Mensagens do Livro

Navigation

Recently Viewed

This feature requires Javascript to be enabled.
 

Mensagens do Livro

Module by: Guilherme Germoglio. E-mail the author

Summary: Apresentação das mensagens presentes no livro "Arquitetura de Software".

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.

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 ferramenta de 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.

Content actions

Download module as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Add module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks