Arquitetura em Camadas

Apresentação em tema: "Arquitetura em Camadas"— Transcrição da apresentação:

1 Arquitetura em Camadas
Disciplina: Engenharia de Software I Professora: Eliane Martins Camila R. Rocha RA: Sílvia C. M. Soares RA:

2 Arquitetura em Camadas
Agenda Introdução Características do Modelo Notação Ferramentas Decomposição Passo a Passo Domínio de Aplicação Variações do Modelo Estudo de Caso Conclusões Bibliografia Junho/2003 Arquitetura em Camadas

3 Sist. Controle de Versões Sist. Controle de Objetos
Introdução Inicialmente proposto por Dijkstra, em 1968 Divisão do sistema hierarquicamente em camadas Exemplos PROTOCOLO OSI SGBD Apresentação Aplicação Físico Enlace Transporte Sessão Sist. Controle de Versões Sistema Operacional Banco de Dados Sist. Controle de Objetos Junho/2003 Arquitetura em Camadas

4 Características do Modelo
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 Controle centralizado Hierárquico (call return) Decomposição modular Suporte a ambos os modelos: orientado a objetos e funcional Modelo Orientado a objetos: Decomposição em objetos que se interrelacionam Modelo Funcional: Decomposição em módulos funcionais que transformam entradas em saídas Junho/2003 Arquitetura em Camadas

5 Arquitetura em Camadas
Notação Pilha Anel A B A UML - Pacotes Como não há uma notação para camadas em UML, são utilizados os pacotes, com o esteriótipo <<layer>> . B Junho/2003 Arquitetura em Camadas

6 Arquitetura em Camadas
Ferramentas Ferramentas para Análise Estruturada Exemplos: Sybase PowerBuilder SmartDraw Ferramentas OO Rational Rose Microsoft Visio Junho/2003 Arquitetura em Camadas

7 Decomposição Passo a Passo
Definir o critério de abstração para o agrupamento de tarefas em uma mesma camada Determinar o número de camadas Nomear e definir as responsabilidades de cada camada Especificar os serviços Refinar as camadas Especificar a interface de cada camada Estruturar internamente as camadas Especificar uma estratégia de tratamento de erros Geralmente é a distância do hw. a distância do hardware pode formar os níveis mais baixos e a complexidade conceitual os níveis mais altos 3. A tarefa da camada mais alta é a percebida pelo cliente. As tarefas das demais camadas visam ajudar a realização da tarefa da camada mais alta 5. Quando uma camada é complexa ela deve ser separada em componentes individuais e cada componente pode seguir um padrão ou estilo diferente 6. Interface única é sempre melhor, pois facilita a manutencao 8. Deve ser na camada mais baixa possível, pra não sobrecarregar a mais alta no tratamento de muitos erros. Junho/2003 Arquitetura em Camadas

8 Arquitetura em Camadas
Domínio de aplicação Aplicações que podem ser decompostas em grupos de sub-tarefas, onde cada grupo pertence a um nível particular de abstração. Protocolos de rede são os melhores exemplos; Máquinas Virtuais; APIs (Application Programming Interface); Sistemas com acesso a banco de dados: Cliente Servidor, Três Camadas, Web. Protocolos de rede são os melhores exemplos de arquiteturas em camadas pois: definem um conjunto de regras e convenções que descrevem como programas de computador, em diferentes máquinas, comunicam-se; o formato, conteúdo e significado das mensagens são definidas. Junho/2003 Arquitetura em Camadas

9 Arquitetura em Camadas
Variações do Modelo Sistema de Camadas Relaxadas Cada camada pode usar os serviços de todas as camadas abaixo dela Camadas Através de Herança Algumas camadas são implementadas como classes base As camadas mais altas herdam a implementação das camadas mais baixas Comum em sistemas orientados a objetos Junho/2003 Arquitetura em Camadas

10 Arquitetura em Camadas
Estudo de Caso Chamada em algum andar (sobe/desce) Solicita movimentação para algum andar Botões Controle Central Base de Dados Física Interface com Usuário Aplicação Base de Dados Física Processamento Tomada de decisão: subir, descer, abrir a porta, ... Armazena dados: onde está cada elevador, andares com chamadas, chamadas por elevador Sistema Operacional Movimento elevadores Junho/2003 Arquitetura em Camadas

11 Arquitetura em Camadas
Estudo de Caso Botões Andar Botões Elevador Controle Central Base de Dados Física Botão Andar Elevador Controle Central Local Elev Elev1 ... Elevn I_Física I_BD I_CC Chamada em algum andar (sobe/desce) Solicita movimentação para algum andar Processamento Decisão: subir, descer, abrir a porta, ... Andar(andar, sobe, desce) Local(elev, andar) Elev(elev, chama_andar) Interface única (fachada) Sistema Operacional Movimento elevadores Junho/2003 Arquitetura em Camadas

12 Arquitetura em Camadas
Estudo de Caso Botão Andar Elevador Controle Central Local Elev Elev1 ... Elevn I_Física I_BD I_CC Botão Andar 7: descer Botão Elev. 3: chamada p/ andar 6 Consulta BD: onde está cada elevador, onde está elevador 3. Tomada de decisão (movimentação, atualização BD) Andar(7, 0, 1) Local(3, 4) Elev(3, 6) Andar(7, 0, 1) Local(3, 6) Elev(3, 0) Andar(0, 0, 0) Local(3, 7) Elev(3, 0) Movimentação elev. 3 para o andar 6 Abertura / Fechamento da porta Movimentação elev. 3 para o andar 7 Junho/2003 Arquitetura em Camadas

13 Arquitetura em Camadas
Conclusões Facilidade da divisão do trabalho Suporte ao desenvolvimento e testes incrementais Reutilização de camadas Possibilidade de padronização de interfaces Manutenibilidade Portabilidade Testabilidade Algumas mudanças se propagam para as outras camadas Menor eficiência Nem todos os sistemas são facilmente divididos em camadas Difícil encontrar níveis de abstração corretos As camadas caixa preta são mais fáceis de reutilizar. Com interfaces padronizadas, o cliente pode escolher a implementação que mais lhe servir. Portabilidade: caso seja mudado o SO, só uma camada sofrera, as outras permanecerão intactas. Testabilidade: as camadas podem ser testadas separadamente, facilitando a tarefa de testes. Manu: camadas inteiras podem ter a implementação modificada sem afetar as outras Trabalho: facil dividir entre os membros de uma equipe Propagação: rede tornou-se mais rápida, por exemplo. Vai dar muito trabalho para adaptar todas as camadas pra aproveitar a velocidade nova Difícil encontrar níveis de abstração corretos: tem serviço q parece estar em várias camadas Junho/2003 Arquitetura em Camadas

14 Arquitetura em Camadas
Bibliografia DIJKSTRA, E. The structure of the “the”-multiprogramming system. Proc. ACM symposium on Operating System Principles, January 1967 BUCHSMANN, F. et. al. A System of Patterns – Pattern-Oriented Software Architecture p MARTINS, E. Projeto Arqutitetural. Transparências do curso MO409, IC-Unicamp, 2003. KAZMAN, R., KLEIN, M. Attribute-Based Architectural Styles Disponível em: Acesso em 21 mai CLEMENTS, P., NORTHROP, L. Software Architecture: An Executive Overview. Relatório Técnico CMU/SEI-96-TR-003, fev/1996. Junho/2003 Arquitetura em Camadas

15 Arquitetura em Camadas
Bibliografia BREDEMEYER CONSULTING. Introducion to Software Architecture Disponível em: Acesso em 19 mai BACHMAN, F., et. al. Software Architecture Documentation in Practice: Documenting Architectural Layers. Relatório Especial CMU/SEI-2000-SR-004, mar/2000. SOMMERVILLE, I. Engenharia de Software – 6a Edição – Addison Wesley, p SMARTDRAW. SmartDraw. softdesign.asp?id= Acesso em jun. 2003 Junho/2003 Arquitetura em Camadas