Representando a Arquitetura

Livro: Engenharia de Software

Autor: Sommerville
Capítulo 6
Diagramas de Caixa e Linha
 Arquitetura de sistemas podem ser modeladas por meio
de diagramas de blocos simples.

 Diagramas de blocos apresentam uma imagem de alto

nível da estrutura do sistema, de forma que as pessoas de
diferentes disciplinas, envolvidas no processo de
desenvolvimento de sistema, possam compreender
facilmente.
Diagramas de Caixa e Linha
 Muito abstrato – não mostram a natureza dos
relacionamentos dos componente nem as propriedades
externamente visíveis dos subsistemas.

 No entanto, é útil para a comunicação com os

stakeholders ​e para o planejamento do projeto.
Diagramas de Caixa e Linha

 Diagrama de blocos
de um sistema
robotizado de
empacotamento
Uso de modelos de arquitetura
 Como forma de facilitar a discussão sobre o projeto do
sistema

 Uma visão de alto nível da arquitetura de um sistema é útil

para a comunicação com os stakeholders do sistema e
planejamento do projeto, pois essa não é cheio de detalhes.
Os stakeholders podem se relacionar e entender uma visão
abstrata do sistema. E então, discutir o sistema como um todo,
sem a possibilidade de serem confundidos pelos detalhes.
Uso de modelos de arquitetura
 Como uma forma de documentar uma arquitetura
projetada

 O objetivo aqui é produzir um modelo de sistema completo

que mostre os diferentes componentes em um sistema, suas
interfaces e suas conexões.
Decisões de projeto de arquitetura
 O projeto de arquitetura é um processo criativo, assim, o
processo difere de acordo com o tipo de sistema que está
sendo desenvolvido.

 No entanto, uma série de decisões comuns abrangem

todos os processos de projeto e essas decisões afetam as
características não-funcionais do sistema.
Decisões de projeto de arquitetura
 Existe uma arquitetura
genérica de aplicação que
possa ser usada?
 Como o sistema será
distribuído?
 Quais estilos de arquitetura
são apropriados?
 Que abordagem será usada
para estruturar o sistema?
 Como o sistema pode ser
decomposto em módulos?
 Qual estratégia de controle
deve ser usada?
 Como o projeto de
arquitetura será avaliado?
 Como a arquitetura deve ser
documentada?
Reuso de arquitetura
 Muitas vezes os sistemas no mesmo domínio têm
arquiteturas similares que refletem os conceitos do
domínio.

 Linhas de produtos de aplicações são construídas em

torno de uma arquitetura central com variantes que
satisfaçam os requisitos particulares do cliente.
Reuso de arquitetura
 A arquitetura de um sistema pode ser projetada em torno
de um ou mais padrões ou “estilos” de arquitetura.

 Essas capturam a essência de uma arquitetura e podem ser

instanciadas de diferentes maneiras.
Padrões de Arquitetura
 Padrões são um meio de representar, partilhar e reusar
conhecimento.

 Um padrão de arquitetura é uma descrição estilizada das

boas práticas de projeto, que tem sido experimentadas e
testadas em diferentes ambientes.

 Os padrões devem incluir informações sobre quando elas

são úteis ou não.
O padrão do Modelo-Visão-Controlador
(MVC)
 Separa a apresentação e a interação dos dados do
sistema. O sistema é estruturado em três componentes
lógicos que interagem entre si.

 O componente Modelo gerencia os sistemas de dados e as

operações associadas a esses dados.
 O componente Visão define e gerencia como os dados são
apresentados ao usuário.
 O componente Controlador gerencia a interação do usuário
(por exemplo, cliques do mouse, teclas, etc.) e passa as
interações para a Visão e Modelo.
O padrão do Modelo-Visão-Controlador
(MVC)
O padrão do Modelo-Visão-Controlador
(MVC)
O padrão do Modelo-Visão-Controlador
(MVC)
 Vantagens
 Permitem que os dados sejam alterados de forma
independente de sua representação, e vice-e-versa.
 Apoia a apresentação dos dados de maneiras diferentes, com
as alterações feitas em uma representação aparecendo em
todas elas.

 Desvantagens
 Quando o modelo de dados e as interações são simples, pode
envolver código adicional e complexidade de código.
Exemplo MVC
 Você desenvolveu um site, e esse site possui uma tela de
login, onde o usuário digita seu login e sua senha, após a
autenticação, caso ocorra tudo certo, o usuário acessa a
área restrita do site, caso contrário é redirecionado
novamente para a página de login repassando uma
mensagem que a combinação de usuário e senha é
inválida.
Desenvolvendo a aplicação sem o MVC
Arquivo Login

1. Cria o formulário de identificação de

usuário;
2. Interpreta as ações do usuário;
3. Armazena em variáveis os dados
digitados pelo usuário;
4. Montam um comando SQL para
selecionar o usuário;
5. Verifica se retornou alguma informação;
Se retornar alguma informação, armazena
o usuário em uma sessão e redireciona
para a área restrita;
Se não retornar nenhuma informação,
redireciona para a página de login com uma
mensagem notificando que a combinação
digitada é inválida;
Desenvolvendo a aplicação com o MVC
Arquivo View Arquivo Controller

1. A controladora (controller) carrega um

modelo (model), e executa um método que
realiza a validação;

Arquivo Model

2. No modelo (model) são executadas as

seguintes tarefas:
Armazena as informações digitadas pelo
usuário;
Realiza a consulta. Caso retornando
verdadeiro (true) em caso de sucesso, ou
falso (false) no caso da combinação das
informações digitadas serem inválidas;
 Desenvolvendo a aplicação com o MVC
Arquivo View Arquivo Controller

3. A controladora (controller) verifica o que

o modelo retornou;
Se retornar verdadeiro (true) armazena as
informações em uma sessão e redireciona
o usuário para visão (view) da área restrita;
Se retornar falso (false) redireciona o
usuário de volta para a tela (view) de login
repassando a mensagem que a combinação
digitada é inválida;

Arquivo Model
O padrão do Modelo-Visão-Controlador
(MVC)

2
3
1

5
Arquitetura em Camadas
 Organiza o sistema em várias camadas com a
funcionalidade relacionada a cada camada.

 Uma camada fornece serviços à camada acima dela;

assim os níveis mais baixos de camadas representam os
principais serviços suscetíveis de serem usados em todos
os sistemas.
Uma arquitetura genérica em camadas
Arquitetura em Camadas
 Cada camada é um subsistema
 Oferece serviços à camada imediatamente superior
 Serve de cliente para a camada imediatamente inferior
 Composta por componentes que tenham o mesmo nível de
abstração

 O acesso aos serviços pode ser realizado de duas

maneiras:
 Direto (componentes chamam componentes de outras
camadas)
 Através de uma interface única para toda a camada
Uma arquitetura genérica em camadas
 Modelo OSI
Aplicação
Apresentação
Sessão
Transporte
Enlace
Físico

 Um protocolo consiste de um conjunto de regras e

convenções que descrevem como programas de
computador se comunicam com outros em diferentes
máquinas.
Notação

 Pilha  Anel
A

 UML - Pacotes
B
Arquitetura em Camadas
 Vantagens:
 Desde que a interface seja mantida, permite a substituição de
camadas inteiras.
 Separação de código relativo a interface com o usuário (UI),
comunicação, negócio e dados.

 Desvantagens:
 Uma camada de alto nível pode ter de interagir diretamente
com camadas de baixo nível, em vez de através da camada
imediatamente abaixo.
 O desempenho pode ser um problema por causa dos múltiplos
níveis de interpretação de uma solicitação de serviço, uma vez
que são processadas em várias camadas.
Arquitetura de Repositório
 Subsistemas devem trocar dados. O que pode ser feito de
duas maneiras:

 Dados compartilhados são guardados em um banco de dados

central ou repositório e podem ser acessados ​por todos os
subsistemas;

 Cada subsistema mantém seu próprio banco de dados e

transmite dados explicitamente para outros subsistemas.
Uma arquitetura de repositório para um
IDE
Arquitetura de Repositório
 Quando grandes quantidades de dados devem ser
compartilhadas, é mais comum o uso do modelo de
repositório compartilhado pois esse é um eficiente
mecanismo de compartilhamento de dados.

 No padrão repositório os componentes não interagem

diretamente, apenas por meio de repositório.
Arquitetura de Repositório
 Vantagens:
 Os componentes podem ser independentes – eles não
precisam saber da existência de outros componentes.
 Todos os dados podem ser gerenciados de forma consistente
pois tudo está em um só lugar.

 Desvantagens:
 O repositório é um ponto único de falhas, assim, problemas no
repositório podem afetar todo o sistema.
 Pode haver ineficiências na organização de toda a
comunicação através do repositório.
Arquitetura Cliente-Servidor
 O padrão cliente servidor está preocupado com sua
organização em tempo de execução.

 Em uma arquitetura cliente-servidor, a funcionalidade do

sistema está organizada em serviço – cada serviço é
prestado por um servidor.

 Os cliente são os usuários desses serviços e acessam os

servidores para fazer uso deles.
A arquitetura cliente-servidor para uma
biblioteca de filmes
A arquitetura cliente-servidor - Exemplo
Arquitetura Cliente-Servidor
 Vantagens:
 A principal vantagem desse modelo é que os servidores podem
ser distribuídos através de uma rede.
 A funcionalidade geral (por exemplo serviços de impressão)
pode estar disponível para todos os clientes e não precisa ser
implementada por todos os serviços.

 Desvantagens:
 Cada serviço é um ponto único de falha suscetível a ataques de
negação de serviço
 O desempenho, bem como o sistema, pode ser imprevisível,
pois depende da rede.
Arquitetura Pipes and Filters
 Tipicamente divide a tarefa de um sistema em vários
passos de processamento sequencial.

 Componentes:
 São chamados Filtros
 Tem um conjunto de entradas e um conjunto de saídas
 Conectores:
 São chamados Dutos
 Servem como condutores, transmitindo as saídas de um filtro
para as entradas de outro.
Um exemplo da arquitetura duto e filtro
Arquitetura Pipes and Filters
 Vantagens
 Reuso de filtros é de fácil compreensão e suporte.
 Estilo workflow corresponde à estrutura de muitos processos
de negócios.
 Evolução por adição de filtros é simples.

 Desvantagens
 É difícil escrever sistemas interativos usando o modelo pipes
and filters. Embora entradas e saídas de texto simples possam
ser modelados dessa forma, interfaces gráficas complexas são
difíceis de traduzir de forma compatível como o modelo filters.
Visões de Arquitetura

“Diferentes visões que descrevem a

arquitetura do corpo humano”
Visões de Arquitetura
 Que pontos de vista ou perspectivas são úteis ao fazer o
projeto e documentar a arquitetura de um sistema?

 Quais notações devem ser usadas para descrever os

modelos de arquitetura?
Visões de Arquitetura
 Cada modelo de arquitetura mostra apenas um ponto de
vista ou perspectiva do sistema.

 Pode mostrar como um sistema é decomposto em

módulos, como os processos interagem em tempo de
execução ou as diferentes formas em que os
componentes do sistema são distribuídos através de uma
rede.

 Para ambos, projeto e documentação, você geralmente

precisa apresentar múltiplas visões da arquitetura do
software.
Visões segundo o RUP (4+1)
RUP - Visão Lógica
 Apresenta a organização do sistema do ponto de vista
funcional.

 Os principais elementos, como módulos e principais

componentes são especificados.

 As interfaces entre esses elementos também são

especificadas
RUP - Visão Lógica

Como o sistema está estruturado em termos

de unidades de módulos?
RUP – Visão de Processo
 Uma visão de processo, que mostra como, em tempo de
execução, o sistema é composto por processos de
interação.
RUP – Visão de Implementação
 Traz as orientações para o projeto e implementação do
sistema de acordo com a arquitetura estabelecida
 Padrões de Arquitetura e de Projeto
 Padrões de Codificação
 Bibliotecas e Frameworks
 Boas Práticas
 Estrutura de Diretórios
RUP – Visão de Implementação
RUP – Visão de Implantação
 Descreve os elementos de hardware do sistema e o
mapeamento dos elementos de software para os
mesmos.
Como os elementos estão
relacionados aos elementos
do ambiente externo?
Estratégia de atendimento à requisitos não-
funcionais
 Desempenho:

 Se desempenho for um requisito crítico, a arquitetura deve ser

projetada para localizar as operações críticas dentro de um
pequeno número de componentes, com todos esses
componentes implantados no mesmo computador, em vez de
distribuídos pela rede.

 Localize operações críticas e minimize as comunicações. Use

componentes de alta granularidade ao invés de baixa
granularidade
Estratégia de atendimento à requisitos não-
funcionais
 Proteção:

 Se a proteção for um requisito crítico, deve ser usada uma

estrutura em camadas para a arquitetura, com ativos mais
críticos protegidos nas camadas mais internas.
Estratégia de atendimento à requisitos não-
funcionais
 Segurança:

 Se a segurança for um requisito crítico, a arquitetura deve ser

concebida de modo que as operações relacionadas a
segurança estejam localizadas em um único componente ou
em um pequeno número de componentes.
Estratégia de atendimento à requisitos não-
funcionais
 Disponibilidade:

 Se a disponibilidade for um requisito crítico, a arquitetura deve

ser projetada para incluir componentes redundantes, de modo
que seja possível substituir e atualizar componentes sem para
o sistema.
Estratégia de atendimento à requisitos não-
funcionais
 Manutenção:

 Se a manutenção for um requisito crítico, a arquitetura do

sistema deve ser projetada a partir de componentes
autocontidos de baixa granularidade que podem ser
rapidamente alterados.
Exercício 2
1. Quais os objetivos para utilização de modelos de
arquitetura?
2. O que são padrões arquiteturais?
3. Quais os componentes do padrão MVC? Como acontece a
comunicação entre eles? Comente sobre as vantagens e
desvantagens deste modelo.
4. Como funciona as arquiteturas em camadas, repositório,
cliente-servidor e pipes and filters? Fale sobre suas
vantagens e desvantagens.
5. Comente sobre a visão 4+1 do RUP.
6. Quais as estratégias podem ser utilizadas para atender os
requisitos de desempenho, proteção, segurança,
disponibilidade e manutenção?