A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Arquitetura de Software, Frameworks e Padrões

Apresentações semelhantes


Apresentação em tema: "Arquitetura de Software, Frameworks e Padrões"— Transcrição da apresentação:

1 Arquitetura de Software, Frameworks e Padrões
Aline Vasconcelos APSI III

2 Arquitetura de Software
Agenda Arquitetura de Software Definições, estilos arquiteturais, benefícios Frameworks Definições, taxonomias, dificuldades Padrões de Software Definições, categorias, benefícios, exemplos Comparações

3 Arquitetura Toda obra da humanidade apresenta um projeto arquitetural.
O projeto arquitetural precede a etapa de construção da obra. O projeto arquitetural determina as partes de uma construção e como estas devem interagir. A arquitetura garante a unidade da obra, ou seja, a consistência entre as suas partes.

4 Arquitetura de Software
Componentes C2 C3 C1 Conexões C4 Um Sistema de Software também deve ser decomposto em partes que interagem para formar uma unidade. A Arquitetura de Software visa garantir a integridade conceitual do sistema. Ela envolve as principais decisões de projeto, determinando os componentes maiores do sistema e suas formas de interação.

5 Arquitetura de Software: Definições
“A estrutura de componentes de um programa/ sistema, seus relacionamentos, princípios e guidelines que governam seu projeto e evolução ao longo do tempo.” (SEI, 1994) “Abstratamente, uma arquitetura de software envolve a descrição dos elementos a partir dos quais os sistemas são construídos, interações entre estes elementos, padrões que guiam sua composição e restrições sobre estes padrões.” (SHAW e GARLAN, 1996) “Uma arquitetura deve ser vista e descrita sob diferentes perspectivas e deve identificar seus componentes, relacionamento estático, interações dinâmicas, propriedades, características e restrições.” (PENEDO E RIDLE, 1993)

6 Estilos Arquiteturais: Descrição
Caracterizam famílias de sistemas em termos de seus padrões de organização estruturais. Definem uma topologia para o sistema. Descritos a partir de: Tipos de Componentes Tipos de Conectores Estruturas de Controle Comunicação de Dados Interação entre Dados e Controle Regras e Restrições

7 Estilos Arquiteturais: Taxonomia
Sistemas de Fluxo de Dados Sistemas de Chamada e Retorno Componentes Independentes Máquinas Virtuais Sistemas Centrados em Dados Seqüenciais Batch Programa Principal e Sub-rotinas Processos Comunicantes Interpretador Bancos de Dados Pipes & Filters Sistemas OO Invocação Implícita (ou Sistemas Baseados em Eventos) Sistemas Baseados em Regras Sistemas de Hipertexto Camadas Blackboards (Quadro-Negro) Extraído de (SHAW e GARLAN, 1996)

8 Pipes & Filters (1/4) FILTERS B D A C
Os componentes são filtros e os conectores pipes (tubos). FILTERS B D A C E PIPES

9 Pipes & Filters (2/4) Cada Componente recebe conjuntos de dados (streams) como entrada e gera uma seqüência de dados na saída. Os filtros aplicam transformações locais às streams e realizam seu processamento de maneira incremental, de forma que as saídas começam a ser geradas antes que toda a entrada tenha sido consumida. Regras: Filtros são unidades Independentes Filtros não conhecem a identidade dos outros filtros A corretude da saída de um filtro não depende da ordem dos filtros.

10 Pipes & Filters (3/4) Arquitetura de Compiladores (GARLAN, 1993)
Exemplo da aplicação do estilo Pipes & Filters: Arquitetura de Compiladores (GARLAN, 1993) Outro exemplo: Unix Pipes: canalizam a saída de um programa para a entrada de um outro programa. Exemplo: Who | Sort Análise léxica Análise sintática Análise semântica Geração de código Otimização

11 Pipes & Filters (4/4) Vantagens: Suporte à reutilização
Sistema pode ser facilmente estendido e modificado Desvantagens: Pode levar a uma organização de processamento batch Pode gerar sistemas seqüenciais

12 Camadas (1/5) Uma arquitetura em camadas é organizada hierarquicamente, onde as camadas mais internas provêem serviços às camadas mais externas. Useful Systems Agregados de Elementos Menores Base Utility Core Level Users

13 Camadas (2/5) Aplicação A arquitetura de rede é formada através de uma estrutura hierárquica, composta de camadas com interfaces entre elas. Apresentação Sessão Transporte Rede Enlace Física

14 Camadas (3/5) Componentes: Camadas Conectores: protocolos que determinam como as Camadas interagem Regras: limites de interação às Camadas adjacentes. Exemplos: protocolos de comunicação em camadas (OSI), alguns sistemas operacionais, arquitetura em 3 Camadas para sistemas de informação comerciais (Interface, Negócio, Persistência)

15 Camadas (4/5) Exemplo: Arquitetura em 3 Camadas para Sistemas
de Informação requisições retorno

16 Camadas (5/5) Vantagens: Suporte à Evolução dos Sistemas
Flexibilidade e boa Manutenibilidade Desvantagens: Problemas de Desempenho e Comunicação Complexidade na Implementação e Testes do Sistema

17 Orientado a Objetos A representação dos dados e suas operações são encapsuladas em um objeto ou Tipo Abstrato de Dados (TAD). Sistemas Orientados a Objetos (OO) podem ser vistos como uma rede ou grafo de objetos comunicantes. Componentes: Objetos ou Instâncias de TADs. Conectores: envio de mensagem (traduzida como uma chamada a procedimento). Regras: objetos encapsulam seus dados; um objeto é responsável pela manutenção da integridade de sua representação.

18 Processos Distribuídos
Sistemas distribuídos são aqueles caracterizados pela existência de múltiplos processadores. Possui 4 tipos de Componentes ou Processos: Filtro: transformador de dados. Cliente: processo que inicia alguma atividade. Servidores: processos que aguardam solicitações de serviços de clientes a fim de tratá-las. Pares (ou Peers): processos idênticos. Conectores: mensagens. Regras:corretude do roteamento; sincronização das mensagens. Vantagens: escalabilidade e facilidade de modificações. Desvantagens: desempenho depende do meio de comunicação; dificuldade em se definir a distribuição.

19 Outros Estilos Arquiteturais
Repositório: repositório central e componentes que interagem via acesso ao repositório compartilhado. Blackboards – repositórios inteligentes. Baseado em Eventos ou Invocação Implícita: componentes disparam eventos, nos quais outros componentes (listeners) registram interesse. Os anunciantes dos eventos não sabem que componentes serão afetados pelos eventos. Propicia uma facilidade de evolução do esquema, uma vez que os componentes não conhecem a identidade uns dos outros. Interpretadores: produz uma máquina virtual para uma determinada linguagem.

20 Arquitetura de Software: Benefícios
Base para o Projeto Detalhado e Construção do Software. Benefícios: Descreve os sistemas em um nível mais alto de abstração. Gerência da Complexidade do Software. Possibilidades de Reuso. Evolução Controlada dos Sistemas. Oportunidades de análise em relação à conformidade aos Atributos de Qualidade.

21 Representação da Arquitetura
Uma arquitetura deve ser descrita sob diferentes perspectivas. Aspectos estáticos, dinâmicos, de distribuição etc. devem ser considerados em uma descrição arquitetural. Diversos modelos de descrição arquitetural são propostos na literatura. Dentre eles, um dos mais aceitos é o Modelo de Visões Arquiteturais 4+1 de Kruchten (4+1 View Model). Kruhten propõe a Visão Lógica, Visão de Processos, Visão Física, Visão de Desenvolvimento e Visão de Cenários.

22 Modelo de Visões Arquiteturais 4+1 (Kruchten, 1995)
Visão Lógica: descreve a perspectiva estática do sistema, demonstrando seus componentes e conectores. Reflete abstrações-chave do domínio do problema. Visão de Processo: perspectiva dinâmica, demonstrando os diferentes processos do sistema e descrevendo aspectos de concorrência e de sincronização do projeto.

23 Visão Lógica e de Processo da Arquitetura

24 Modelo de Visões Arquiteturais 4+1 (Kruchten, 1995)
Visão Física: descreve o mapeamento do software (componentes, processos) para o hardware e reflete a natureza distribuída do sistema. Visão de Desenvolvimento: descreve o software no seu ambiente de implementação. Mostra a utilização de COTS (Commercial off-the-shelf Software Components), bibliotecas etc.

25 Visão Física e de Desenvolvimento da Arquitetura

26 Modelo de Visões Arquiteturais 4+1 (Kruchten, 1995)
Visão de Cenários: ou de casos de uso, utilizada para ilustrar o comportamento do sistema em sua arquitetura, conforme descrita pelas outras quatro visões. Para tal ilustração, alguns cenários de casos de uso devem ser selecionados.

27 Padrões de Software

28 Arquiteto ->Christopher Alexander.
Histórico Arquiteto ->Christopher Alexander. Linguagem de padrões em arquitetura. Christopher Alexander --> catálogo com 253 padrões para edificações ligadas a regiões, cidades, transportes, casas, escritórios, paredes, jardins, etc.

29 Definição “um padrão expressa uma solução reutilizável descrita através de três partes: um contexto, um problema e uma solução”. (GAMMA et al., 1995). Contexto: estende o problema a ser solucionado, apresentando situações de ocorrência desses problemas. Problema:determinado por um sistema de forças, onde estas forças estabelecem os aspectos do problema que devem ser considerados. Solução: mostra como resolver o problema recorrente e como balancear as forças associadas a ele.

30 Padrões em ES padrões em ES permitem que desenvolvedores possam recorrer a soluções já existentes para solucionar problemas que normalmente ocorrem em desenvolvimento de software; Surgimento: início dos anos 90; Padrões capturam experiência existente e comprovada em desenvolvimento de software, ajudando a promover boa prática de projeto.

31 Categorias de Padrões Padrões Arquiteturais: expressam
um esquema de organização estrutural fundamental para sistemas de software. (BUSCHMANN et al., 1996) Padrões de Projeto: disponibilizam um esquema para refinamento de subsistemas ou componentes de um sistema de software (GAMMA et al., 1995) Idiomas: descrevem como implementar aspectos particulares de componentes ou de Relacionamentos entre eles, usando as Características de uma dada linguagem public void runServer() { ServerSocket server; Socket connection; try { connection = server = new ServerSocket(7000, 100); server.accept(); }

32 Exemplo de Padrão Arquitetural: MVC

33 Model-View-Controller
Motivação: Separação de interesses. Considere o uso deste padrão quando estiver desenvolvendo sistemas com interface de usuário. Interfaces de usuário são propensas a mudanças. Por exemplo, quando as funcionalidades de uma aplicação são estendidas ou adaptadas, menus devem ser modificados. O sistema pode ser executado em diferentes plataformas, com diferentes padrões de interface gráfica. A interface de usuário deve estar o mais independente possível do kernel funcional da aplicação.

34 Model-View-Controller
O padrão propõe a divisão de uma aplicação em 3 áreas (ou tipos de componentes): modelo, controle e apresentação O modelo representa as classes do domínio do problema, sendo independente de uma forma específica de apresentação. Encapsula os dados e funcionalidade do negócio. O modelo deve ser independente de representações de saída específicas e do tratamento das interações dos usuários com a aplicação. A visão apresenta as informações do modelo ao usuário. Podem existir múltiplas visões de um mesmo modelo. Cada Visão tem um controlador.

35 Model-View-Controller
O padrão propõe a divisão de uma aplicação em 3 áreas (ou tipos de componentes): modelo, controle e apresentação Os controladores recebem a entrada, geralmente um evento (i.e. movimentos do mouse, ativação de botões, teclas etc.), que é traduzida em requisições de serviços ao modelo ou visão. Se o usuário altera o modelo através do controlador de uma visão, todas as outras visões dependentes destes dados devem refletir a mudança. As Visões devem refletir o estado atual do modelo. Padrão arquitetural utilizado no Smalltalk.

36 Model-View-Controller
Vantagens: flexibilidade e reutilização. Aplica o padrão de projeto Observer. Pode aplicar o padrão de projeto Composite quando trabalha com objetos Visão complexos. Por exemplo, um Frame pode ser composto por painéis etc. O agrupamento de objetos é tratado como um objeto individual. Outros padrões de projeto podem ser aplicados.

37 Outros Exemplos de Padrões Arquiteturais
Broker: para aplicações distribuídas, onde uma aplicação pode acessar serviços de outras aplicações simplesmente pelo envio de mensagens a objetos mediadores, sem se preocupar com questões específicas relacionadas à comunicação entre processos, como a sua localização. Presentation-Abstraction-Control (PAC): define uma estrutura para sistemas na forma de uma hierarquia de agentes cooperativos. Adequado para sistemas interativos, onde cada agente é responsável por um aspecto específico da funcionalidade da aplicação e é composto por três componentes: apresentação, abstração e controle. Microkernel: propõe a separação de um conjunto de funcionalidades mínimas das funcionalidades estendidas e partes específicas de clientes. O encapsulamento dos serviços fundamentais da aplicação é realizado no componente “microkernel”. As funcionalidades estendidas e específicas devem ser distribuídas entre os componentes restantes da arquitetura.

38 Exemplo de Padrão de Projeto
Nome: State Pattern Problema: o comportamento de um objeto depende do seu estado e ele pode mudar o seu comportamento em tempo de execução, dependendo desse estado. Solução: definir uma classe abstrata que apresenta as operações comuns a todos os estados do objeto. Cada estado será representado através de uma subclasse concreta desta classe. O objeto mantém uma referência para o seu estado atual.

39 State Pattern Estrutura:

40 Outros Padrões de Projeto
Singleton: classe de uma única instância. Padrão de criação. Visa garantir que uma classe tenha somente uma instância e fornece um ponto global de acesso à mesma. Adapter: converte a interface de uma classe em outra interface, esperada pelos clientes. O adaptador (ou wrapper) permite que classes com interfaces incompatíveis trabalhem em conjunto. Padrão estrutural. Observer: define uma dependência de um para muitos entre objetos, de maneira que quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente. Padrão Comportamental.

41 Padrões de Codificação ou Idiomas
Padrões de implementação, específicos para uma linguagem de programação. Exemplo: Reference-couting em C++ para gerenciar recursos alocados dinamicamente. Utilizado para a implementação de Garbage Collection.

42 Sistemas, Catálogos e Linguagens
Sistema de Padrões define uma coleção de padrões que trabalham juntos para resolver um problema complexo Sistemas de padrões ~= linguagens de padrões Catálogo possuem um grau de relacionamento menor, se comparado aos padrões em linguagem de padrões e sistemas de padrões.

43 Paralelo entre Frameworks e Padrões (GAMMA ET AL., 1995)
Padrões são mais abstratos que frameworks: Frameworks podem ser incorporados em código, enquanto apenas exemplos de padrões podem ser incorporados em códigos. Padrões são elementos arquiteturais menores que frameworks: um típico framework contém vários padrões (micro-arquiteturas). Padrões são menos especializados do que frameworks: Frameworks pertencem a domínios particulares, enquanto padrões são genéricos.

44 FRAMEWORKS

45 Definições “Um conjunto de classes cooperantes que constróem um projeto reutilizável para uma específica classe de software” (JOHNSON, 1997) “Um framework é uma coleção de classes abstratas e concretas e de uma interface entre elas, e um projeto para um subsistema” (WIRFS-BROCK E JOHNSON, 1990) “Um framework é um software parcialmente completo (subsistema) que pretende ser instanciado” (BUSCHMANN ET AL. 1996)

46 Classificação de Frameworks quanto ao escopo
Frameworks de Infra-estrutura: frameworks que apóiam a infra-estrutura de qualquer tipo de sistema (ex: SISOP, interfaces de usuário, persistência de objetos, de comunicação e de processamento de linguagens). Frameworks de Integração: estes frameworks são projetados para suportar a modularização, o reuso e a integração de aplicações que apresentam componentes distribuídos. (ex: middleware para sistemas distribuídos) Frameworks de Aplicação: são dirigidos a um domínio específico de aplicações, ou seja, a uma família de aplicações em uma determinada área.

47 Frameworks: Características
Aspectos variáveis - hot-spots Aspectos invariáveis frozen-spots Hot-spot - uma parte do framework onde uma adaptação pode ser feita Frozen-spot – uma parte do framework que não foi projetada para adaptação. Exemplo de Hot-spots: Classes Abstratas, métodos abstratos, métodos hook, etc. Exemplo de Frozen-spots: Classes Concretas, métodos template, etc.

48 Frameworks: Características
Template Method (padrão de projeto do Gamma): Assim como as Classes e métodos abstratos, este padrão está no cerne do projeto de um Framework. A idéia é definir um método gabarito (o Template Method) em uma superclasse, definindo o esqueleto de um algoritmo com suas partes variantes e invariantes. O Template Method invoca outros métodos, alguns dos quais são operações que podem ser redefinidas em subclasses. Assim, as subclasses podem redefinir os métodos que variam, de forma a acrescentar o seu próprio comportamento específico nos pontos de variação.

49 Frozen-Spots e Hot-Spots
Identificar e projetar os hot-spots em um framework é uma das principais dificuldades para desenvolver projetos reutilizáveis. Um framework para ter um alto grau de qualidade deve ter bons hot-spots para permitir futuras adaptações. Frozen-spots definem a arquitetura geral de um sistema, ou seja, seus componentes básicos e os relacionamentos entre eles.

50 Classificação de Frameworks quanto à Adaptação
caixa branca (white box):baseiam-se no conceito de herança e ligação dinâmica que permite uma sub-classe reutilizar a interface e a implementação de sua super-classe. caixa preta (black box): estão baseados no conceito de composição de objetos onde estes não revelam detalhes internos de sua implementação, tendo-se somente acesso à interface do mesmo. caixa cinza (gray box): permite adaptação tanto por herança e ligação dinâmica, quanto por composição de componentes.

51 Dificuldades em Frameworks
Desenvolvimento de frameworks: determinar partes variáveis e semelhantes numa família de aplicações; limitar a porção de código necessária para completar a aplicação, a qual deve ser pequena; testes e liberação para uso de um framework; evolução do framework; custo e esforço de desenvolvimento.

52 Dificuldades em Frameworks
Utilização de frameworks: verificação da aplicabilidade de um framework como solução ao problema em questão; estimativa de esforço na compreensão e uso do framework; confiabilidade.

53 Referências Bibliográficas:
SHAW, M., GARLAN, D., 1996, “Software Architecture: perspectives on an emerging discipline”, 1 ed, Nova Jersey, Prentice-Hall: 1996. SEI, 1994, PENEDO, M. H., RIDDLE, W., 1993, “Process-sensitive SEE Architecture (PSEEA) – Workshop Summary”, Software Engineering Notes, ACM SIGSOFT, vol. 18, nº 3, July, pp.A78 – A94. APPLETON, Brad. Patterns and Software: Essential Concepts and Terminology. Disponível na internet em: BUSCHMANN, F. et al. Pattern-Oriented Software Architecture: a system of patterns. John Wiley & Sons, England, p. FAYAD, Mohamed et al. Building application frameworks: object-oriented foundations of framework design. John Wiley & Sons, p.

54 Referências Bibliográficas:
GAMMA, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995. JOHNSON, Ralph. Frameworks = (Components + Patterns). Communications of the ACM. New York, v.40. n.10, p , oct MATTSON, M. et al. Framework Integration: problems, causes, solutions. Communications of the ACM. October Vol.42.Nro p Grupo de Reutilização da COPPE UFRJ:


Carregar ppt "Arquitetura de Software, Frameworks e Padrões"

Apresentações semelhantes


Anúncios Google