SlideShare uma empresa Scribd logo
1
Arquitetura de Software
Texto complementar para este assunto:
Len Bass, Paul Clements, Rick Kazman
Software Architecture in Practice, 2nd
Edition
Capítulos 1, 2 e 3
Disponível em:
http://www.tar.hu/softarchpract/index.html
2
Programação Modular
3
Implementação
Programação Modular
4
Implementação
Interface
Programação Modular
5
Implementação
Interface
Provida
Interface
Requerida
Programação Modular
6
Implementação
Interface
Provida
Interface
Requerida
Visível
apenas
dentro do
Módulo
Programação Modular
7
Benefícios Esperados da
Programação Modular [Parnas, 1972]
(1) Tempo de desenvolvimento encurtado, já que
grupos de desenvolvimento separados podem
trabalhar em módulos distintos, com pouca
necessidade de comunicação
(2) Possibilidade de aplicar mudanças drásticas a
um módulo sem a necessidade de mudar outros
(3) Possibilidade de estudar o sistema olhando para
um módulo de cada vez
 Interações entre módulos
8

A estrutura de um sistema de software, que
engloba
• componentes de software
• suas propriedades visíveis externamente
• e os relacionamentos e interações entre eles

As primeiras decisões tomadas no projeto de
um sistema
• As mais importantes!

Uma arquitetura de software é composta por
componentes e conectores
Arquitetura de Software
9
Clientes web
(Mozilla, IE, etc.)
Servidor WEB
Rede
Local
Banco de Dados
Relacional
Internet
Uma Arquitetura em Camadas
10
Componente Componente Componente
Clientes web
(Mozilla, IE, etc.)
Servidor WEB
Internet Rede
Local
Banco de Dados
Relacional
Uma Arquitetura em Camadas
11
Banco de Dados
Relacional
Conector
(Ponte
SQL)
Conector
(HTTP,
RMI)
Clientes web
(Mozilla, IE, etc.)
Servidor WEB
Rede
Local
Internet
Uma Arquitetura em Camadas
12
Projeto Arquitetural

O processo de projeto que estabelece
• Os subsistemas que constituem um sistema
• A maneira como essas componentes interagem

Incluindo algumas decisões tecnológicas
• Ex. Plataforma de componentes, SGBD

A saída desse processo de projeto é uma
descrição da arquitetura de software

A arquitetura de software lida com os requisitos
não-funcionais do sistema
13
Projeto Arquitetural

É o primeiro estágio do projeto do sistema

Representa a ligação entre os processos de
especificação e de projeto

É freqüentemente conduzido em paralelo com
algumas atividades de especificação
• Às vezes junto com a elicitação de requisitos

Envolve a identificação dos componentes
principais do sistema e sua interação
• Componentes => unidades de modularidade
14
Vantagens de uma Arquitetura Explícita

Comunicação com os stakeholders
• A arquitetura pode ser usada como um foco de
discussão pelos stakeholders do sistema.

Análise de sistema
• Se há possibilidade de o sistema atender a seus
requisitos de qualidade (não-funcionais)

Reuso em larga escala
• A arquitetura pode ser reusável em uma variedade
de sistemas
• Suas partes também!
15
Conflitos de arquitetura

O uso de componentes de granularidade grossa
aprimora o desempenho mas diminui a facilidade
de manutenção

A introdução de dados redundantes aprimora a
disponibilidade, mas torna a proteção mais difícil
• E cria dificuldades para tornar o sistema confiável
em outras partes

Localizar as funcionalidades críticas de
segurança em poucos locais pode criar gargalos
de desempenho

Decisões de projeto
16
Decisões de projeto

Projeto de arquitetura é um processo criativo
• Cada sistema envolve diferentes
decisões/requisitos/conflitos/restrições
• Envolve solucionar os problemas representados
pelos requisitos

Decisões de projeto:
• Escolhas feitas durante o projeto de um sistema
• Afetam sua capacidade de fornecer seu serviço
• Normalmente resultam em compromissos
• É importante avaliar as opções existentes
• Não estão restritas ao projeto arquitetural!
17
Exemplos de Decisões de Projeto

Como representar o mapa em um sistema que traça
rotas percorridas por ônibus de modo a minimizar o
trabalho da equipe?

Como garantir a confiabilidade de um servidor a um
baixo custo?

Qual a maneira mais eficiente de se construir uma
grade de horários levando-se em conta as várias
restrições impostas por professores, diretores e regras
departamentais?

Qual a melhor tecnologia para se construir uma
ferramenta de análise de programas?

Como a arquitetura do sistema deve ser documentada?
18
Características de um Sistema que
decorrem de sua Arquitetura

Desempenho
• Localizar operações críticas e minimizar comunicações. Usar
componentes de grossa ao invés de fina granularidade.

Proteção
• Usar uma arquitetura em camadas com itens críticos nas
camadas mais internas.

Segurança
• Localizar características críticas de segurança em um pequeno
número de subsistemas.

Disponibilidade
• Incluir componentes redundantes e mecanismos para tolerância
à falhas.

Facilidade de manutenção
• Usar componentes facilmente trocáveis
19
Representação de Arquiteturas

Arquiteturas são um ativo importante no
desenvolvimento
• Podem ser a diferença entre o sucesso e o
fracasso

Representá-las é importante
• Torna possível “falar” sobre ela
• O projeto de arquitetura é normalmente expresso
como um diagrama de blocos

Modelos mais específicos também podem ser
desenvolvidos
20
Sistema de controle robotizado de
empacotamento
21
Diagramas caixa e linha

Muito abstrato – não mostram a natureza dos
relacionamento de componentes, nem suas
propriedades externamente visíveis

Contudo, são úteis para comunicação com os
stakeholders e para planejamento de projeto

Alternativas:
• Notações formais
• Notações informais mais organizadas
22
Visões Arquiteturais

A arquitetura de um sistema software
normalmente é representada através de várias
visões

Visões são maneiras diversas de se enxergar
uma mesma arquitetura
• Enfocando diferentes aspectos de interesse
• Ex.: as várias plantas de uma casa

Arquiteturas de software são especificadas
através de uma ou mais de suas visões
23
Três principais elementos:
 agentes de usuário (UA).
 servidores de correio.
 simple mail transfer protocol:
SMTP.
caixa de
correio do usuário
fila de
mensagens
de saída
agente
de
usuário
servidor
de correio
SMTP
SMTP
SMTP
agente
de
usuário
agente
de
usuário
agente
de
usuário
agente
de
usuário
servidor
de correio
servidor
de correio
Correio Eletrônico – Visão 1
POP3/IMAP
24
1) Alice usa o UA para compor
uma mensagem “para”
bob@someschool.edu
2) O UA de Alice envia a
mensagem para o seu
servidor de correio; a
mensagem é colocada na
fila de mensagens.
3) O lado cliente do SMTP abre
uma conexão TCP com o
servidor de correio de Bob.
4) O cliente SMTP envia a
mensagem de Alice através da
conexão TCP.
5) O servidor de correio de Bob
coloca a mensagem na caixa de
entrada de Bob.
6) Bob chama o seu UA para ler a
mensagem.
user
agent
mail
server
mail
server user
agent
1
2 3 4 5
6
Correio Eletrônico – Visão 2
25
Fonte: Axigen Mail Server Documentation - Mail Server Architecture.
Consultado em 24 de março de 2008
http://www.axigen.com/docs/en/Mail-Server-Architecture_85.html
Correio Eletrônico – Visão 3
26
Um Exemplo de Sistema de
Controle de Tráfego Aéreo
M&C Console
G.A.M
Local/Group A.M.
ATC Console
A.S.O.U
O/S E. A. S.
Network Operating System
Processor I/O Devices
Attachments
Exceções
Exceções
Exceções
Exceções
Exceções
Fonte: Bass, Clements, and Kazman, Software
Architecture in Practice, 2nd
Edition, 2003.
Exceções
27
Sobre Visões

Algumas são genéricas
• Lógica
• Diagramas de classes e pacotes
• De interação
• Diagrama de sequência
• Física ou de Alocação
• Diagrama de implantação

Outras servem a fins específicos
• Fluxo de exceções
• Qualquer dos diagramas acima mostrando apenas componentes
associados a exceções (ou ao fim específico em questão)
28
Reuso de arquitetura

Sistemas do mesmo domínio freqüentemente
têm arquiteturas similares que refletem os
conceitos de domínio
• Resultam em decisões de projeto similares

Linhas do produto de software são construídas
em torno de um núcleo de arquitetura
• Variantes satisfazem requisitos de cada cliente

Reuso de arquiteturas é capturado através da
noção de padrões ou estilos arquiteturais

Mais conteúdo relacionado

PDF
Corbawebserves
PDF
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
PDF
Clean Architecture
DOC
Relatório geral pi
PPSX
Zachman framework
PDF
Aula 1 - Programação Dinâmica para Web
PPS
Projeto de Software
DOCX
06-engenharia de softwere Análise e Projeto de Software.docx
Corbawebserves
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
Clean Architecture
Relatório geral pi
Zachman framework
Aula 1 - Programação Dinâmica para Web
Projeto de Software
06-engenharia de softwere Análise e Projeto de Software.docx

Semelhante a 06_slide de Arquitetura_de_Software .ppt (20)

PDF
Padrões de Projeto de Software
ODP
Integração de Serviços como requisito fundamental no processo de migração par...
PPS
Arquitetura de Software
PPTX
Frameworks de desenvolvimento web
PDF
Vantagens e desvantagens de uma arquitetura microservices
PPTX
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
PPTX
Eng.ª do Software - 2. Requisitos
PPTX
Engenharia de Software Reuso Engenharia de Software Reuso Engenharia de Softw...
PPTX
Introducao a Clean Architecture
PPTX
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
PPTX
Aula sobre Sistemas Distribuidos Atualizado
PPTX
ArquiteturaSoftware
PPTX
Resumo capítulo 1 livro Engenharia de Software Moderna
PDF
Arquitetura Limpa @ 32º CocoaTalks BH
PDF
Conceito de analise de desenvolvivento de sistemas
PDF
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
PDF
Aula2 caracteristicas da_tecnologia_de_banco_de_dados
PPT
Middleware Reflexivo
DOCX
Este trabalho trata
Padrões de Projeto de Software
Integração de Serviços como requisito fundamental no processo de migração par...
Arquitetura de Software
Frameworks de desenvolvimento web
Vantagens e desvantagens de uma arquitetura microservices
Aula03 Sistemas Distribuídos - Arquiteturas de sistemas distribuídos
Eng.ª do Software - 2. Requisitos
Engenharia de Software Reuso Engenharia de Software Reuso Engenharia de Softw...
Introducao a Clean Architecture
Aula CARACTERIZAÇÁO DE SISTEMAS distribuidos.pptx
Aula sobre Sistemas Distribuidos Atualizado
ArquiteturaSoftware
Resumo capítulo 1 livro Engenharia de Software Moderna
Arquitetura Limpa @ 32º CocoaTalks BH
Conceito de analise de desenvolvivento de sistemas
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Aula2 caracteristicas da_tecnologia_de_banco_de_dados
Middleware Reflexivo
Este trabalho trata
Anúncio

Mais de robertojunio9 (8)

PPT
03_slide de Gerenciamento de Projetos .ppt
PPT
05_slide especificacao de sistemas de software e a uml UML.ppt
PPT
00_Apresentacao sobre o livro do sommerville_ES.ppt
PPT
09_Evolucao de software e_Refatoracao.ppt
PPT
01_slides livro sommerville Introducao_ES.ppt
PPT
07_slides de Estilos_Arquiteturais sommerville.ppt
PPT
04_slide Requisitos de software_capitulo4
PPT
10_ slides de Reuso sommerville cap 10.ppt
03_slide de Gerenciamento de Projetos .ppt
05_slide especificacao de sistemas de software e a uml UML.ppt
00_Apresentacao sobre o livro do sommerville_ES.ppt
09_Evolucao de software e_Refatoracao.ppt
01_slides livro sommerville Introducao_ES.ppt
07_slides de Estilos_Arquiteturais sommerville.ppt
04_slide Requisitos de software_capitulo4
10_ slides de Reuso sommerville cap 10.ppt
Anúncio

06_slide de Arquitetura_de_Software .ppt

  • 1. 1 Arquitetura de Software Texto complementar para este assunto: Len Bass, Paul Clements, Rick Kazman Software Architecture in Practice, 2nd Edition Capítulos 1, 2 e 3 Disponível em: http://www.tar.hu/softarchpract/index.html
  • 7. 7 Benefícios Esperados da Programação Modular [Parnas, 1972] (1) Tempo de desenvolvimento encurtado, já que grupos de desenvolvimento separados podem trabalhar em módulos distintos, com pouca necessidade de comunicação (2) Possibilidade de aplicar mudanças drásticas a um módulo sem a necessidade de mudar outros (3) Possibilidade de estudar o sistema olhando para um módulo de cada vez  Interações entre módulos
  • 8. 8  A estrutura de um sistema de software, que engloba • componentes de software • suas propriedades visíveis externamente • e os relacionamentos e interações entre eles  As primeiras decisões tomadas no projeto de um sistema • As mais importantes!  Uma arquitetura de software é composta por componentes e conectores Arquitetura de Software
  • 9. 9 Clientes web (Mozilla, IE, etc.) Servidor WEB Rede Local Banco de Dados Relacional Internet Uma Arquitetura em Camadas
  • 10. 10 Componente Componente Componente Clientes web (Mozilla, IE, etc.) Servidor WEB Internet Rede Local Banco de Dados Relacional Uma Arquitetura em Camadas
  • 11. 11 Banco de Dados Relacional Conector (Ponte SQL) Conector (HTTP, RMI) Clientes web (Mozilla, IE, etc.) Servidor WEB Rede Local Internet Uma Arquitetura em Camadas
  • 12. 12 Projeto Arquitetural  O processo de projeto que estabelece • Os subsistemas que constituem um sistema • A maneira como essas componentes interagem  Incluindo algumas decisões tecnológicas • Ex. Plataforma de componentes, SGBD  A saída desse processo de projeto é uma descrição da arquitetura de software  A arquitetura de software lida com os requisitos não-funcionais do sistema
  • 13. 13 Projeto Arquitetural  É o primeiro estágio do projeto do sistema  Representa a ligação entre os processos de especificação e de projeto  É freqüentemente conduzido em paralelo com algumas atividades de especificação • Às vezes junto com a elicitação de requisitos  Envolve a identificação dos componentes principais do sistema e sua interação • Componentes => unidades de modularidade
  • 14. 14 Vantagens de uma Arquitetura Explícita  Comunicação com os stakeholders • A arquitetura pode ser usada como um foco de discussão pelos stakeholders do sistema.  Análise de sistema • Se há possibilidade de o sistema atender a seus requisitos de qualidade (não-funcionais)  Reuso em larga escala • A arquitetura pode ser reusável em uma variedade de sistemas • Suas partes também!
  • 15. 15 Conflitos de arquitetura  O uso de componentes de granularidade grossa aprimora o desempenho mas diminui a facilidade de manutenção  A introdução de dados redundantes aprimora a disponibilidade, mas torna a proteção mais difícil • E cria dificuldades para tornar o sistema confiável em outras partes  Localizar as funcionalidades críticas de segurança em poucos locais pode criar gargalos de desempenho  Decisões de projeto
  • 16. 16 Decisões de projeto  Projeto de arquitetura é um processo criativo • Cada sistema envolve diferentes decisões/requisitos/conflitos/restrições • Envolve solucionar os problemas representados pelos requisitos  Decisões de projeto: • Escolhas feitas durante o projeto de um sistema • Afetam sua capacidade de fornecer seu serviço • Normalmente resultam em compromissos • É importante avaliar as opções existentes • Não estão restritas ao projeto arquitetural!
  • 17. 17 Exemplos de Decisões de Projeto  Como representar o mapa em um sistema que traça rotas percorridas por ônibus de modo a minimizar o trabalho da equipe?  Como garantir a confiabilidade de um servidor a um baixo custo?  Qual a maneira mais eficiente de se construir uma grade de horários levando-se em conta as várias restrições impostas por professores, diretores e regras departamentais?  Qual a melhor tecnologia para se construir uma ferramenta de análise de programas?  Como a arquitetura do sistema deve ser documentada?
  • 18. 18 Características de um Sistema que decorrem de sua Arquitetura  Desempenho • Localizar operações críticas e minimizar comunicações. Usar componentes de grossa ao invés de fina granularidade.  Proteção • Usar uma arquitetura em camadas com itens críticos nas camadas mais internas.  Segurança • Localizar características críticas de segurança em um pequeno número de subsistemas.  Disponibilidade • Incluir componentes redundantes e mecanismos para tolerância à falhas.  Facilidade de manutenção • Usar componentes facilmente trocáveis
  • 19. 19 Representação de Arquiteturas  Arquiteturas são um ativo importante no desenvolvimento • Podem ser a diferença entre o sucesso e o fracasso  Representá-las é importante • Torna possível “falar” sobre ela • O projeto de arquitetura é normalmente expresso como um diagrama de blocos  Modelos mais específicos também podem ser desenvolvidos
  • 20. 20 Sistema de controle robotizado de empacotamento
  • 21. 21 Diagramas caixa e linha  Muito abstrato – não mostram a natureza dos relacionamento de componentes, nem suas propriedades externamente visíveis  Contudo, são úteis para comunicação com os stakeholders e para planejamento de projeto  Alternativas: • Notações formais • Notações informais mais organizadas
  • 22. 22 Visões Arquiteturais  A arquitetura de um sistema software normalmente é representada através de várias visões  Visões são maneiras diversas de se enxergar uma mesma arquitetura • Enfocando diferentes aspectos de interesse • Ex.: as várias plantas de uma casa  Arquiteturas de software são especificadas através de uma ou mais de suas visões
  • 23. 23 Três principais elementos:  agentes de usuário (UA).  servidores de correio.  simple mail transfer protocol: SMTP. caixa de correio do usuário fila de mensagens de saída agente de usuário servidor de correio SMTP SMTP SMTP agente de usuário agente de usuário agente de usuário agente de usuário servidor de correio servidor de correio Correio Eletrônico – Visão 1 POP3/IMAP
  • 24. 24 1) Alice usa o UA para compor uma mensagem “para” bob@someschool.edu 2) O UA de Alice envia a mensagem para o seu servidor de correio; a mensagem é colocada na fila de mensagens. 3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio de Bob. 4) O cliente SMTP envia a mensagem de Alice através da conexão TCP. 5) O servidor de correio de Bob coloca a mensagem na caixa de entrada de Bob. 6) Bob chama o seu UA para ler a mensagem. user agent mail server mail server user agent 1 2 3 4 5 6 Correio Eletrônico – Visão 2
  • 25. 25 Fonte: Axigen Mail Server Documentation - Mail Server Architecture. Consultado em 24 de março de 2008 http://www.axigen.com/docs/en/Mail-Server-Architecture_85.html Correio Eletrônico – Visão 3
  • 26. 26 Um Exemplo de Sistema de Controle de Tráfego Aéreo M&C Console G.A.M Local/Group A.M. ATC Console A.S.O.U O/S E. A. S. Network Operating System Processor I/O Devices Attachments Exceções Exceções Exceções Exceções Exceções Fonte: Bass, Clements, and Kazman, Software Architecture in Practice, 2nd Edition, 2003. Exceções
  • 27. 27 Sobre Visões  Algumas são genéricas • Lógica • Diagramas de classes e pacotes • De interação • Diagrama de sequência • Física ou de Alocação • Diagrama de implantação  Outras servem a fins específicos • Fluxo de exceções • Qualquer dos diagramas acima mostrando apenas componentes associados a exceções (ou ao fim específico em questão)
  • 28. 28 Reuso de arquitetura  Sistemas do mesmo domínio freqüentemente têm arquiteturas similares que refletem os conceitos de domínio • Resultam em decisões de projeto similares  Linhas do produto de software são construídas em torno de um núcleo de arquitetura • Variantes satisfazem requisitos de cada cliente  Reuso de arquiteturas é capturado através da noção de padrões ou estilos arquiteturais