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

Arquitetura de Software, Frameworks e

Padrões

Aline Vasconcelos

APSI III

2

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

C1

• Um Sistema de Software também deve ser decomposto em partes que interagem para formar uma unidade.

• A Arquitetura de Software visa garantir a integridadeconceitual do sistema.

• Ela envolve as principais decisões de projeto, determinandoos componentes maiores do sistema e suas formas de interação.

C2 C3

C4

Componentes

Conexões

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)

Os componentes são filtros e os conectores pipes (tubos). PIPESPIPES

FILTERSFILTERS

AB

C

D

E

9


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


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álisesintática

Análisesemântica

Otimização Geração de código

11


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.

CoreLevel

Base Utility

Useful SystemsAgregados de Elementos Menores

Users

13

Camadas (2/5)

A arquitetura de rede A arquitetura de rede é formada através de é formada através de uma estrutura uma estrutura hierárquica, composta hierárquica, composta de camadas com de camadas com interfaces entre elas.interfaces entre elas.

Aplicação

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)

GUI

Negócio

Persistência

Exemplo: Arquitetura em 3 Camadas para Sistemasde 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.

ComponentesComponentes: Objetos ou Instâncias de TADs. ConectoresConectores: envio de mensagem (traduzida

como uma chamada a procedimento). RegrasRegras: 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 ComponentesComponentes ou ProcessosProcessos: Filtro: transformador de dados. ClienteCliente: processo que inicia alguma atividade. ServidoresServidores: processos que aguardam solicitações

de serviços de clientes a fim de tratá-las. Pares (ou Peers): processos idênticos.

ConectoresConectores: mensagens. RegrasRegras:corretude do roteamento; sincronização das

mensagens. VantagensVantagens: escalabilidade e facilidade de

modificações. DesvantagensDesvantagens: desempenho depende do meio de

comunicação; dificuldade em se definir a distribuição.

19

Outros Estilos Arquiteturais

RepositórioRepositó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ícitaBaseado 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.

InterpretadoresInterpretadores: 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


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

Server

Client

26


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.

Padrões de Software

28

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

Controller

myModelmyView

initialize()handleEvent()update()

View

myModelmyController

initialize()makeController()activate()display()

+creat

Model

coreDatasetOfObservers

attach()detach()notify()getData()service()

+attach call

+attach get

Observer

update()

+ call

+manipulate

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


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


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


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:

state.handle()

Context

request()

State

handle()11

ConcreteStateA

handle()

ConcreteStateB

handle()

.........

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.

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):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, http://www.sei.cmu.edu/ata/ata_init.html. 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: http://www.enteract.com/~bradapp/docs/patterns-intro.html.

BUSCHMANN, F. et al. Pattern-Oriented Software Architecture: a system of patterns. John Wiley & Sons, England, 1996. 467p.

FAYAD, Mohamed et al. Building application frameworks: object-oriented foundations of framework design. John Wiley & Sons, 1999. 664p.

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. 39-43, oct. 1997.

MATTSON, M. et al. Framework Integration: problems, causes, solutions. Communications of the ACM. October 1999. Vol.42.Nro.10. 81-87p

Grupo de Reutilização da COPPE UFRJ: http://reuse.cos.ufrj.br/odyssey

Documents

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