O documento discute padrões arquiteturais e o papel do arquiteto de software. Ele define padrões arquiteturais e classifica-os, descreve o padrão de camadas e seu contexto, solução, estrutura e usos conhecidos. Além disso, discute as motivações para o estudo de arquitetura de software e quem é o arquiteto.

1. Profa. Tarciane Andrade

2. Agenda
Quem é o arquiteto?
Padrões Arquiteturais - Motivação
Definição
ClassificaçãoClassificação
Descrevendo Padrões
Padrão Camadas

3. Quem é o Arquiteto?
3
“O Arquiteto” - The Matrix

4. O Arquiteto...
... é um Líder Técnico!
Possui conhecimento técnico e qualidades de um líder
Tem autonomia para tomar decisões técnicas no projeto
Diferente do Gerente de Projetos
4
Diferente do Gerente de Projetos
Gerencia o projeto em termos de alocação de recursos,
cronograma e custos
GP = Produtor garantir que as coisas sejam feitas
Arquiteto = Diretor garantir que as coisas sejam feitas da
maneira correta

5. O Arquiteto...
... é um Líder Técnico!
Contribui ativamente para o planejamento de atividades do
projeto
Interage bastante com os outros membros da equipe
(Analistas, Desenvolvedores, etc.)
5
(Analistas, Desenvolvedores, etc.)
É orientado a pessoas atua como mentor de outros
membros da equipe
É focado na entrega de resultados força motriz do lado
técnico do projeto

6. O Arquiteto...
... conhece o Processo de Desenvolvimento!
O processo assegura que os membros da equipe trabalhem
de forma coordenada
6
O processo define os papéis envolvidos, as atividades a
serem desempenhadas e os produtos de trabalho gerados
Deve conhecer os demais papéis e suas responsabilidades

7. O Arquiteto...
... conhece o Domínio do Negócio!
Ajuda a melhor entender e contribuir para que os
requisitos sejam devidamente capturados
Equilíbrio entre conhecimento Técnico e conhecimento do
7
Equilíbrio entre conhecimento Técnico e conhecimento do
Negócio
O domínio tem impacto na arquitetura
Caso contrário, a solução pode não atender ao problema

8. O Arquiteto...
... tem conhecimento Técnico!
Não é necessariamente um expert
Tende a ser generalista, em vez de especialista
8
Tende a ser generalista, em vez de especialista
Possui certo nível de conhecimento técnico
Conhece muitas tecnologias em um nível superior, em vez
de algumas tecnologias no nível de detalhe

9. O Arquiteto...
... tem conhecimento em Design de sistemas!
Arquitetura envolve decisões importantes de
design
9
Deve ditar os vários tipos de padrões, incluindo
padrões de código, ferramentas e plataformas que
serão utilizadas

10. O Arquiteto...
... tem conhecimento em Programação!
Desenvolvedores é um dos grupos mais
importantes com o qual o arquiteto interage
10
Favorece a comunicação efetiva
Abstrair conceitos em linguagens e aprendê-las na
profundidade necessária

11. O Arquiteto...
... é um Bom Comunicador!
Falar bem e escrever bem
Ser um bom observador e saber ouvir
11
Ser um bom observador e saber ouvir
Comunicar de forma clara e garantir o entendimento
Conquistar o respeito da equipe
Motivar a equipe

12. O Arquiteto...
... toma Decisões!
Toma decisões críticas sob pressão e deve fazer com que
essas decisões sejam cumpridas à risca
É importante ter experiência
12
É importante ter experiência
A inabilidade de tomar decisões vai prejudicando o projeto
O time perde confiança no arquiteto
Decisões passam a ser tomadas por cada um

13. O Arquiteto...
... deve estar ciente da Política Organizacional!
Não deve estar apenas preocupado com
tecnologia
13
Sabe onde o poder reside e busca utilizá-lo em
favor do projeto

14. O Arquiteto...
... é um Negociador!
Interage com as diversas partes interessadas do projeto
Requistos podem possuir riscos associados
14
Requistos podem possuir riscos associados
Riscos devem ser tratados
Requisitos podem ser diminuidos para eliminar riscos

15. O Arquiteto evita Problemas...
“Uma equipe teve que refazer parte da
implementação de JavaScripts da camada de
apresentação de um sistema ao perceber, já
em produção, que o sistema não atendia o
navegador Firefox.”navegador Firefox.”
“Em um outro projeto descobriu-se, já em
produção, que o tempo médio dos casos de
uso era de 40 segundos.”

16. Motivações para o estudo de
Arquitetura de Software
Sistemas cada vez maiores;
Sistemas cada vez mais complexos;
Mais requisitos em termos de confiabilidade;
Mais requisitos em termos de desempenho;Mais requisitos em termos de desempenho;
Mais requisitos em termos de economia;
Mais requisitos em termos de integração;
Necessidade de manutenibilidade – facilidade de
reparo e evolução;
Tendência à componentização;
Busca pela reusabilidade.

17. Definição
“A arquitetura de um software é a estrutura
do sistema, compreendendo componentes de
software, propriedades desses componentes
que são visíveis externamente e oque são visíveis externamente e o
relacionamento entre eles”. Paul Clements,
SEI.

18. Definição
“A Arquitetura de Software inclui o conjunto
de decisões significantes sobre a organização
de um software tais como a seleção dos
elementos estruturais e suas interfaces; oelementos estruturais e suas interfaces; o
comportamento entre esses elementos; a
composição destes elementos estruturais e de
comportamento em subsistemas maiores e o
estilo arquitetural que guia esta organização.”,
Booch, Kruchten, Reitman, Bittner, and Shaw.

19. Ponte entre os Requisitos e sua Implementação.
Arquitetura de Software

20. Abstração que ajuda a gerenciar a complexidade
Projeto Arquitetural do Software envolve:
Estrutura modular do software
Arquitetura de Software
Componentes
Relacionamento entre componentes

21. Formada por diferentes visões (4 + 1):
Arquitetura de Software
Visão Lógica Visão de Implementação
Visão de Casos de Uso
Visão de ImplantaçãoVisão de Processos

22. Visão de Casos de Uso:
Compreende as situações de uso do sistema que
descrevem o comportamento do sistema conforme é visto
pelo seus usuários finais.
Casos de uso com impacto mais significativo na
arquitetura.
Arquitetura de Software - Visão
Casos de uso com impacto mais significativo na
arquitetura.
Visão Lógica:
Abrange as classes, interfaces e colaborações que formam
o vocabulário do problema e de sua solução.
Preocupação com quantidade de camadas, plataforma a
ser utilizada, tecnologias, componentes, diagrama de
classes

23. Visão de Processos
Abrange os processamentos paralelos, visualizando
cooperação entre componentes e sincronização.
Questões como concorrência, distribuição, integração,
performance e escalabilidade.
Arquitetura de Software - Visão
performance e escalabilidade.

24. Arquitetura de Software - Visão
Visão de Implementação
Cobre os arquivos utilizados para a montagem e fornecimento do
sistema físico.
24
Visão de Implantação
Compreende os nós em que os componentes do sistema são
executados.

25. Questões estruturais da Arquitetura
de Software
Seleção de alternativas de projeto;
Escalabilidade (crescimento) e desempenho;
Organização e estrutura geral do software;
Protocolos de comunicação;
Atribuição de funcionalidade a componentes de
projeto.

26. Principais Padrões Arquiteturais
Padroes do livro:(*) Buschmann, Frank; Meunier Regine;
Rohnert, Hans; Sommerlad, Peter; Stal, Michael. Pattern-
Oriented Software Architecture: A System of Patterns.
Wiley.1998.
Estruturais – padrões nesta categoria ajudam você a evitarEstruturais – padrões nesta categoria ajudam você a evitar
um “mar” de componentes ou objetos. Em particular, eles
suportam uma decomposição controlada de uma tarefa global
do sistema em subtarefas cooperativas.
A categoria inclui os seguintes padrões:
Camadas
Pipes e Filtros

27. Principais Padrões Arquiteturais
Sistemas Distribuídos – esta categoria
compreende macro soluções para sistemas
baseados em distribuição.
O padrão abaixo se enquadra nessa categoria:
Broker

28. Principais Padrões Arquiteturais
Sistemas Interativos – os padroes desta
categoria suportam a estruturação de sistemas
de software.
O padrão abaixo se enquadra:
Model-View-Controller (MVC)

29. Descrevendo Padrões Arquiteturais
Nome
O nome e um curto resumo do padrão.
Exemplo
Um exemplo do mundo real demonstrando a existência do
problema e a necessidade do padrão.problema e a necessidade do padrão.
Contexto
As situações nas quais o padrão se aplica.
Problema
Descreve o problema que o padrão soluciona, incluindo
uma sobre restrições, imposições e demais questões
associadas ao problema.

30. Descrevendo Padrões Arquiteturais
Solução
O princípio básico da solução associado ao padrão.
Estrutura
Uma especificação detalhada dos aspectosUma especificação detalhada dos aspectos
estruturais do padrão.
Usos conhecidos
Fornece exemplos de aplicação do padrão
encontrados em sistemas reais.

31. Padrão
Camadas
Padrão
Camadas

32. Padrão de Camadas
Contexto
Um grande sistema que requer decomposição.
Problema
Imagine que esteja projetando um sistema cuja
característica principal é uma mistura de assuntos de altocaracterística principal é uma mistura de assuntos de alto
nível com assuntos de baixo nível, em que os assuntos de
alto nível usam os assuntos de baixo nível.
A parte de baixo nível está frequentemente perto do hardware
A parte de mais alto nível está frequentemente perto do usuário
O fluxo de comunicação tipicamente consiste de pedidos fluindo do
alto para o baixo nível
As respostas andam na direção contrária

33. Padrão de Camadas
Problema (cont.)
Portabilidade para outras plataformas é desejada.
O trabalho tem que ser subdividido em equipes
com especificidades distintas.com especificidades distintas.

34. Padrão de Camadas
Solução
Decompor em camadas de abstração de
forma que uma camada não depende da
superior e utiliza serviços apenas da camadasuperior e utiliza serviços apenas da camada
imediatamente inferior.

35. Padrão de Camadas
Solução
De um ponto de vista de alto nível, a solução é
extremamente simples.
O sistema deve ser estruturado em um número apropriado
de camadas, colocadas umas sobre as outras.de camadas, colocadas umas sobre as outras.
Inicie no nível mais baixo de abstração – chame-a de
“Camada 1”. Esta é a base de seu sistema.
Trabalhe seguindo para cima no nível de abstração
colocando a Camada J sobre a Camada J-1 até alcançar o
nível mais elevado de funcionalidade – chame-a de
“Camada N”.
Os serviços da Camada J são usados somente pela Camada
J+1.

36. Padrão de Camadas

37. Padrão de Camadas
Solução
1. Defina o critério de abstração para agrupar tarefas em
camadas
2. Determine o número de níveis de abstração (baseado no
critério acima)critério acima)
Cada nível de abstração corresponde a uma camada
Às vezes não é simples decidir se deve haver uma
quebra de uma camada em subcamadas ou não
Camadas demais podem gerar overhead
Camadas de menos podem comprometer a estrutura

38. Padrão de Camadas
Solução
3. Dê um nome e atribua tarefas a cada camada
Para a camada de cima, a tarefa é a tarefa global do
sistema, do ponto de vista do usuário
4. Especifique os serviços
O princípio básico é de separar as camadas uma das
outras
Nenhum módulo abrange duas camadas
Tente manter mais riqueza acima e menos abaixo
Isso ajuda a prover bons serviços de alto nível para o
programador "em cima"

39. Padrão de Camadas
Solução
5. Refine as Camadas
6. Especifique uma interface para cada camada
A camada J nada sabe sobre a camada J-1 e usa umaA camada J nada sabe sobre a camada J-1 e usa uma
interface para acessá-la;
O padrão Facade é bastante útil para organizar a
interface da camada;
7. Estruture as camadas individualmente
Quebre a camada em subsistemas (partições) menores
se ela for complexa;

40. Padrão de Camadas
Solução
8. Especifique a comunicação entre camadas
A camada J passa a informação necessária para a
camada J-1 ao chamá-la
9. Desacople camadas adjacentes
Evite situações em que a camada de baixo sabe algo
sobre seus clientes (camadas acima)
Acoplamento unidirecional é preferível

41. Padrão de Camadas
Solução
10. Projete uma estratégia de tratamento de erros
O esforço de programação e overhead podem ser
grandes para tratar erros numa arquitetura em camadas
Um erro pode ser tratado na camada onde foiUm erro pode ser tratado na camada onde foi
descoberto ou numa camada superior
No segundo caso, deve haver mapeamento para
tornar o erro semanticamente reconhecível pela
camada de cima;
Tente tratar erros na camada mais baixa possível
Isso simplifica todas as camadas superiores que
não sabem nem devem saber do erro.

42. Padrão de Camadas
Estrutura

43. Padrão de Camadas
Estrutura (cont.)

44. Padrão de Camadas
Estrutura

45. Padrão de Camadas
Estrutura

46. Padrão de Camadas
Usos Conhecidos
Sistemas de Informação em geral: Apresentação,
Lógica da Aplicação, Camada de Persistência.
Sistemas Operacionais: Serviços de Sistema,Sistemas Operacionais: Serviços de Sistema,
Camada de Gerenciamento de Recursos, Kernel,
Camada de Abstração do Hardware e o próprio
Hardware.

47. Aplicações em duas camadas
Cliente-Servidor
Necessidade de compartilhar a lógica de acesso a dados
entre vários usuários simultâneos
Nesta estrutura a base de dados foi colocada em uma
máquina específica, separada das máquinas que
executam as aplicações.executam as aplicações.
Aplicativos instalados em estações clientes contendo toda
a lógica da aplicação (clientes ricos ou gordos).
Um grande problema neste modelo é o gerenciamento de
versões pois para cada alteração os aplicativos precisam
ser atualizados em todas as máquinas clientes.

48. Aplicações em três camadas
(Modelo em três camadas)
Impulsionadas pela internet.
Movimento no sentido de separar a lógica de negócio da
interface com o usuário.
Usuários da WEB possam acessar as mesmas aplicaçõesUsuários da WEB possam acessar as mesmas aplicações
sem ter que instalar estas aplicações em suas máquinas
locais.
Como a lógica do aplicativo, inicialmente contida no
cliente rico, não reside mais na máquina do usuário, este
tipo de cliente passou a ser chamado de cliente pobre ou
magro (Thin Client).

49. Aplicações em três camadas
(Modelo em três camadas)
Neste modelo o aplicativo é movido para o Servidor e um
navegador Web é usado como um cliente magro.
O aplicativo é executado em servidores Web com os
quais o navegador Web se comunica e gera o códigoquais o navegador Web se comunica e gera o código
HTML para ser exibido no cliente.

50. Aplicações em três camadas
(Modelo em três camadas)
Camada de apresentação
Camada que interage diretamente com o usuário e onde são
feitas as requisições ao sistema.
Camada de negócioCamada de negócio
Camada que contempla as funções e regras de todo o negócio.
Não faz interface com o usuário e seus dados são voláteis.
Camada de persistência
Repositório das informações e as classes que a manipulam.
Recebe as requisições da camada de negócios e executa essas
requisições em um banco de dados.