Saam & arquiteturas_iu_halan

MBA-ENGSOFT Arquitetura de Software 1 © 2005 Halan Ridolphi

P I / UFRJ OLBisrolu

M A Engenharia de Software – Turma 2004 D ciplina: Arquitetura de Software P fessor: Daniel Schneider A no: Halan Ridolphi Alves


Sumário ............................................................................................... 4

........................................................................ 4

........................................................................ 4 1.3 4 1.4 . 5

. 5 6

7 7 0

... 10

2 ura Arch/Slinky .................................................................................... 12

.............................................................................. 13

.............................................................................. 14 2.7

1 Método SAAM ............1.1 Arquitetura de Software .............1.2 Análise Arquitetural ...................

Objetivos do SAAM ............................................................................................ Desenvolvimento de Cenários .............................................................................

1.5 Descrição de Arquitetura ...................................................................................1.6 Avaliação de Cada Cenário ..................................................................................1.7 Determinação da Interação de Cenários ................................................................ 61.8 Avaliação de Cenários e da Interação de Cenários .................................................. 61.9 Métricas e Arquiteturas Candidatas ......................................................................1.10 Arquitetura Serpent ...........................................................................................

2 Arquiteturas de Interface do Usuário .......................................................................... 12.1 Histórico de Evolução ....................................................................................2.2 Arquitetura Seeheim ........................................................................................ 102.3 Arquitetura MVC .............................................................................................. 12.4 Arquitet2.5 Arquitetura PAC ................2.6 Arquitetura PAC-Amodeus ...

Vantagens e Limitações .................................................................................... 15 3 Bibliografia ............................................................................................................. 16


1 Método SAAM

1.1 Arquitetura de Software

O crescimento continuando tanto em termos de tamanho quanto da complexidsistemas de software, aliados há demanda cada vez acentuada por

ade dos sistemas com maior

confiabilidade, bom desempenho e menor custo fazem com que o desafio do desenvolvimento de software extrapole o projeto de algoritmos e estruturas de dados. Para lidar com a complexidade crescente, a especificação da estrutura global, ou seja, a arquitetura de software passa a ser um aspecto técnico de maior relevância no projeto de sistemas de software de grande porte. Neste sentido, torna-se cada vez mais evidente que processos de engenharia de software requeiram projeto arquitetural de software. No projeto de um sistema de software, a arquitetura de software compõe-se de subsistemas ou componentes (responsáveis pelo comportamento do sistema), de conectores (interligando os componentes) e de padrões de conexão (possibilitando vários tipos de interação e compartilhamento de informações entre os componentes).

1.2 Análise Arquitetural

Análise Arquitetural é um processo iterativo de refinamento do modelo arquitetural inicial de um sistema, o qual é derivado a partir de um conjunto de requisitos arquiteturais compostos por atributos de qualidade e de projeto. É muitas vezes difícil associar novas arquiteturas a atributos de qualidade. Mas comumente, observa-se que, os desenvolvedores de software concentram-se nos aspectos funcionais das arquiteturas. Assim, o propósito principal da análise arquitetural é verificar se os requisitos arquiteturais têm sido considerados durante o processo de desenvolvimento de um sistema de software.

1.3 Objetivos do SAAM

O método SAAM (Software Architecture Analysis Method) para análise arquitetural de software foi concebido inicialmente com objetivo de apoiar arquitetos de software a omparem soluções arquiteturais.

A proposta do SAAM consistia dos seguintes propósitos:

de cenários que representem usos importantes do ssistema os pontos de vista de todos aqueles que possuem papéis

tilizar cenários para gerar uma partição funcional do domínio, uma ordenação o dos cenários às várias funções existentes

as

ação

pode usar ra avaliar o potencial do sistema de software em

os não-funcionais. Entretanto, é importante observ

• Definir um conjuntono domínio, envolvendoinfluenciadores no sistema;

• Uparcial das funções e um acoplamentna partição;

• Usar a partição funcional e ordenação parcial juntamente com cenários de uso a fim de realizar a análise das arquiteturas propostas.

Para cada cenário, a análise pelo método SAAM fornece uma pontuação das arquiteturque estão sendo avaliadas, denominadas de arquiteturas candidatas. Recai sobre o avaliador a responsabilidade de determinar os pesos dos cenários considerados bem como a pontuglobal das arquiteturas candidatas.

O método SAAM tem como base o uso de cenários, com os quais um analistauma descrição de arquitetura de software paprover suporte a atributos de qualidade ou requisit

ar que avaliar uma arquitetura de software para determinar se ela oferece suporte à requisitos não-funcionais não é tarefa fácil. Tais requisitos tendem a ser um tanto vagos.


Visando realizar a análise arquitetural, torna-se necessário considerar o contexto no quao sistema de software encontra-se inserido bem como considerar as circunstâncias espeaquele contexto. Uma forma de atingirmos esse objetivo é fazendo uso de cenários a fim dentender e avaliar se uma arquitetura oferece suporte ou não a um específico requisito não-funcional e sob quais circunstâncias.

O método SAAM compreende um conjunto de 5 atividades as quais possuem interdependências entre si, conforme ilustrado na figura a seguir:

l cificas

e

Figura 1: Atividades do SAAM

ividade ilustrada para método

ntar interações, ftware, tais

a.

1.5

ndo

pessoal envolvido na análise tenha um entendimento comum. A especificação arquitetural deve

Nas seções seguintes, desenvolvemos os propósitos de cada at SAAM.

1.4 Desenvolvimento de Cenários

O foco desta etapa é o desenvolvimento de cenários de tarefas que ilustrem os tipos de atividades a que o sistema de software deve prover suporte. O analista deve também considerarpossíveis modificações que o sistema possa sofrer ao longo do tempo. Ao desenvolver esses cenários, o analista deve capturar todos os usos importantes do sistema, os quais irão refletir os requisitos não-funcionais. Além disso, esses cenários deverão apreseconsiderando os principais influenciadores com papéis relevantes ao sistema de socomo: usuário ou cliente, desenvolvedor, mantenedor e administrador de sistem

Descrição de Arquitetura

Nesta etapa, o analista deve possuir uma representação arquitetural do sistema, paracada análise em elaboração, fazendo uso de uma notação arquitetural definida, descrevecomponentes e conectores utilizados na especificação da arquitetura. Isso possibilitará que o


informar os componentes funcionais e de dados do sistema de software bem como as relaçõeexistentes entre eles. Assim, uma representação arquitetural fará uma distinção e

s ntre

) e componentes passivos (que pos de conexões: (a) conexões de

dados (onde se tem passagem de dados entre componentes) e (b) conexões de controle (na qual um

ição do comportamento do sistema ao longo d

, m funções que a arquitetura já possui. O segundo caso compreende

as existentes, para as quais a arquitetura provê suporte. r feita à arquitetura através da adição ou alteração de um

compo

• Se a arquitetura candidata suporta as tarefas contidas no cenário considerado, então o analista pode atribuir uma pontuação +, e não há necessidade de fazer qualquer análise adicional;

• Se a arquitetura candidata não suporta diretamente as tarefas candidatas no cenário, então você precisa continuar a avaliação a fim de determinar a extensão das modificações que devem ser realizadas. Uma forma de determinar isto é conhecendo o número de componentes e conexões que precisarão ser adicionados ou modificados. Isso requer um conhecimento profundo da arquitetura, o qual pode ser obtido através do desenvolvedor ou pelo conjunto de especificações do sistema. Se duas arquiteturas estão sendo comparadas, então aquela que exigir a adição ou modificação de menos componentes e conexões receberá a pontuação + enquanto aquela requerendo mais adições ou modificações em componentes e conexões receberá a pontuação -.

1.7 Determinação da Interação de Cenários

Uma interação entre cenários ocorre quando dois ou mais cenários indiretos exigem modificações em algum componente ou conexão. A identificação da interação de cenários permite ao analista saber como a funcionalidade do sistema de software é alocada durante o projeto. Em outras palavras, a interação de cenários mostra as tarefas às quais os componentes estão associados. Na realidade, a determinação da interação de cenários avalia a extensão para a qual a arquitetura provê suporte a uma separação de interesses apropriada. Por exemplo, um elevado grau de interação pode indicar que a funcionalidade de um componente específico está inadequadamente isolada. Dessa forma, para cada cenário, o analista deve determinar como os componentes e as conexões são afetados pelo cenário considerado.

1.8 Avaliação de Cenários e da Interação de Cenários

o de análise arquitetural, envolvendo os principais influen l

componentes ativos (que efetuam transformação de dadosarmazenam dados). Além disso, devemos considerar dois ti

componente atua sobre um outro o habitando a executar alguma tarefa). É importanteobservar que a descrição gráfica nos dá uma representação estática da arquitetura do sistemade software. Esta representação é complementada através de uma representação dinâmica, expressa em linguagem natural que fornece uma descr

o tempo.

1.6 Avaliação de Cada Cenário

Para cada cenário, o analista deve determinar se a arquitetura candidata oferece suporte diretamente às tarefas associadas ao cenário ou se alguma modificação é necessária e, portanto, se a arquitetura oferece suporte ao cenário apenas indiretamente. No primeiro casoos cenários representacenários que incluem funções, além dNesse caso, uma modificação deve se

nente ou conexão. Ao final, o analista deve obter uma tabela sumarizando os cenários onde a arquitetura candidata provê suporte aos requisitos não-funcionais associados. Nesta tabela, o analista pode adotar a seguinte convenção:

Esta é uma etapa subjetiva do processciadores do sistema de software. Nesta etapa, o analista realiza uma avaliação globa

atribuindo uma pontuação a cada cenário e interação de cenário. Isso tem como base implicações que os cenários têm sobre a arquitetura do sistema de software. Note que, anteriormente, o analista desenvolveu cenários, realizou o mapeamento deles na descrição


arquitetural do sistema de software e determinou as interações de cenários existentes. Esta avaliação reflete a influência dos atributos de qualidade associados aos cenários.

1.9 Métricas e Arquiteturas Candidatas

O método SAAM permite a um analista na posição de avaliador utilizar um conjunto de métrica s associadas aos cenários elaborados, para que se possa analisar qual arquitetura desoftware, dentre as arquiteturas candidatas, provê suporte melhor ao conjunto de requisitos não-funcionais desejados para o sistema de software.

Ressalta-se que, as atividades do método SAAM de Descrição de Arquitetura e Desenvolvimento de Cenários de possuem elevado grau de dependência entre si, como pode ser visda arquisistem grande importância descrição arquitetural do sis

1.10

Se

to pela Figura 1. Os tipos de cenários desenvolvidos influenciarão no nível de granulosidade tetura. A determinação de um conjunto de cenários depende do tipo de tarefas que o

a de software suportará. Neste contexto, os cenários elaborados têm um papel de uma vez que eles ajudarão o analista a compreender a

tema de software.

Arquitetura Serpent

Analisemos uma das arquiteturas de software para interface do usuário denominada de rpent (Bass, 1990), ilustrada na figura 2.A descrita a seguir.

Figura 2: Visões da Arquitetura Serpent

O componente de aplicação dá suporte à semântica computacional da aplicação. O componente de apresentação é o que oferece suporte às técnicas de interação nos níveis lógico e físico, sendo completamente independente da semântica da aplicação. A coordenação entre esses dois primeiros componentes é feita através do controlador de diálogo. Esse terceiro


componente é encarregado de mediar à comunicação da interação do usuário com a aplicação.comunicação na arquitetura Serpent também é mediada por meio de restrições a dacompartilhados do banco de dados. Esta estrutura é implementada como um banco de dados ativo. Deste modo, quando os valores no banco de dados são alterados, os mesmos são automaticamente comunicados a qualquer componente registrad

A dos

o que possua interesse sobre o dado modificado.

O metamodelo Arch/Slinky de arquiteturas de interface do usuário serve como uma partição funcional canônica neste domínio de aplicação. Ele é uma extensão do modelo Seeheim de sistemas de gerenciamento de interface do usuário, e é o resultado de ampla discussão e acordo entre desenvolvedores e pesquisadores de interface do usuário. Arch/Slinky identificaram cinco funções básicas no software de interface do usuário, a saber:

• Núcleo Funcional (NF): Este componente realiza as manipulações de dados e outras funções orientadas ao domínio. Também chamado de Componente Específico do Domínio ou, simplesmente a Aplicação.

• Adaptador de Núcleo Funcional (ANF): Este componente agrega os dados específicos do domínio em estruturas de alto nível, realiza verificações semânticas e dispara tarefas de diálogo inicializadas no domínio. É o mediador entre o Diálogo e o Núcleo Funcional.

• Diálogo (D): Este componente faz mediação entre partes específicas do domínio e da apresentação de uma interface do usuário, realizando o mapeamento de dados quando necessário. Ele assegura consistência (possibilitando múltiplas visões de dados) e controle de sequenciamento de tarefas.

• Componente de Interação Lógica (IL): Este componente fornece um conjunto de objetos independentes de toolkit (algumas vezes chamados objetos virtuais) para o componente de Diálogo.

• Componente de Interação Física (IF): Este componente implementa a interação física entre usuário e computador. Ele lida com dispositivos de entrada e saída e é, geralmente, conhecido como Componente de Toolkit de Interação.

Quando mapeamos as funções do metamodelo de arquitetura de software para sistemas interativos (Arch/Slinky) na arquitetura Serpent obteremos como resultado a descrição arquitetural ilustrada na figura 2.B.

A arquitetura Serpent foi redesenhada fazendo uso da notação arquitetural ilustrada na figura 2. Após obtemos uma nova visão da arquitetura Serpent baseada no metamodelo Arch/Slinky, algumas observações podem ser destacadas acerca deste mapeamento:

• Não há separação arquitetural entre funções IL e IF no processo de Apresentação.

• Não existe separação arquitetural entre as funções de ANF e D no processo do Controlador de Diálogo.

• Exceto o Gerenciador de Diálogo, todos os componentes da arquitetura Serpent são monolíticos, ou seja, não oferecem suporte arquitetural para subdivisão de funcionalidade dentro de um componente. Dentro do componente Gerenciador de Diálogo, uma hierarquia de processos Controladores de Visão provê uma decomposição arquitetural com suporte a modificação no aspecto de interação entre usuário e sistema de software.

Vamos analisar o grau de suporte a mudanças provido pela arquitetura Serpent quando desejamos, por exemplo, adicionar uma opção de menu na interface do usuário. Neste sentido, observa-se que a arquitetura Serpent isola o Controlador de Diálogo, o que infere que a modificação proposta seja realizada no escopo deste processo. O Controlador de Diálogo é composto por dois componentes: o Gerente de Diálogo, cujo propósito é comandar o comportamento do diálogo com usuário, e o Banco de Dados Ativo, o qual mantém o estado do diálogo. Esse cenário que se deseja fazer uma modificação está associado à mudança no


comportamento do diálogo com usuário e, portanto, está focaddisso, o Gerente de Diálogo é particionado em componentes m

o no Gerente de Diálogo. Além enores associados a

funcione cenário

alidades específicas do comportamento do diálogo, por exemplo, um menu do usuário. Portanto, concluímos que a arquitetura Serpent provê suporte apropriado a este tipo denvolvendo modificação de aparência de um sistema interativo.


2 Arquiteturas de Interface do Usuário Um sistema interativo pode ser decomposto em dois componentes de software principais:

o software da aplicação e o software da interface do usuário. O software da aplicação compreende toda a funcionalidade do sistema interativo enquanto o software de interface do usuário é encarregado de mediar à comunicação entre o usuário e a aplicação do sistema. Neste contexto, o propósito desta seção é apresentar conceitos básicos acerca de arquitetura de software de interface do usuário.

2.1 Histórico de Evolução

As arquiteturas Seeheim e MVC (Model-View-Controller) foram as primeiras propostas de metamodelos de interface do usuário surgidas no início da década de 1980. O desenvolvimento dessas duas arquiteturas coincidiu com o desenvolvimento de alguns tipos de ferramentas (bibliotecas de classes no caso MVC) e de sistemas de janelas (no caso Seeheim). Os frameworks de aplicação foram derivados de evolução lógica de bibliotecas de classes assim como os toolkits e toolkits virtuais. Essas duas correntes de lógicas de desenvolvimento continuaram a evoluir até culminar no aparecimento da arquitetura PAC-Amodeus. A figura 3 ilustra a evolução histórica das várias arquiteturas de software de interface do usuário e seus relacionamentos de herança. Nas seções seguintes relatamos descrições conceituais sucintas acerca dessas arquiteturas de software.

Figura

2.2

r Interf o orient

3: Evolução das Arquitetura de Software de Interface do Usuário

Arquitetura Seeheim

A arquitetura Seeheim tem essa denominação em virtude de um workshop sobre Useace Management System (UIMS) realizado em Seeheim, Alemanha. Muitos UIMS sãados a essa arquitetura de software.


A figura 4.A ilustra a organização global dos componentes da arquitetura Seeheim.

Figur

s (feedback) com usuários finais do sistema interativo.

ção.

é encarregado de tratar a interface do usuário e os componentes de lógica de

é realizado por via da invocação de

ssa a possibilidade do componente da Interface com Aplicação utilizar um caminho secundário, desviando-se do

a 4: Descrição Arquitetural Metamodelos Seeheim, MVC e Arch/Slinky

A arquitetura Seeheim é composta pelos seguintes componentes funcionais:

• Apresentação: Este componente manipula os dispositivos de entrada e saída,layout de telas, técnicas de interação e mecanismos de exibição, possuindo detalhes dependentes de dispositivos bem como da descrição do estilo de interação. Além disso, o componente controla as interações e a geração de resposta

• Controle de Diálogo: Este componente é encarregado do processamento e seqüenciamento do diálogo com usuário. Também é um organizador do tráfego entre o componente de Apresentação e componentes específicos da aplicaResponde pela estrutura de comandos e diálogo utilizados pelo usuário. Esse componente gerencia a quantidade de informação que os componentes de Apresentação e Interface com Aplicação necessitam saber um do outro. Esse controle ocorre através do acesso a estados dos componentes de Apresentação e Interface com Aplicação.

• Interface com Aplicação: Este componente comunicação existente entre aaplicação do sistema interativo. Isso procedimentos da aplicação. Assim, a comunicação com lógica da aplicação é feitapor via de chamada de procedimentos, ao passo que as estruturas de dados são descritas num nível abstrato independente da implementação. O componente menor ilustrado na figura 4.A expre


componente de Controle de Diálogo, objetivando melhorar o desempenho. Entretanto, o Controle de Diálogo é o responsável por inicializar essa segunda via de comunicação.

2.3

componentbem ccom u os de objetos de interação (interactors), Um objeto de interação for C, um sistemsentido,compo4.B.

ntes View e C eo funciofornecendo o comportamento pe s us

uitetura

del: Compreende os objetos estruturais e o núcleo funcional do

ita dados do componente Model associado e

mponente

mbora um componente Model possa ter mais de

2.4

seguirarquit

Arquitetura MVC

A arquitetura MVC (Model-View-Controller) organiza um sistema interativo em termos de es funcionais denominados agentes. Um agente tem um estado, possui conhecimento

omo é capaz de inicializar e reagir a eventos. Os agentes que se comunicam diretamente suário são chamad

nece ao usuário a representação perceptiva de seu estado interno. Na arquitetura MVa interativo é estruturado em um conjunto de agentes funcionais cooperativos. Neste

a arquitetura MVC estabelece uma divisão funcional do sistema interativo nos nentes Model, View e Controller. Uma ilustração da arquitetura MVC é descrita na figura

Na arquitetura MVC, o componente Model comunica-se diretamente com os componeontroller. O componente Model define a competência do agente, ou seja, seu núcl

nal. O componente View define o comportamento perceptivo do agente para a saída, suporte a apresentação. O componente Controller denota

rceptivo do agente para entrada e, é encarregado de tratar as entradas e comandos douários bem como gerenciar toda a informação trocada entre usuário e o componente Model.

Podemos descrever as seguintes responsabilidades para os componentes da arqMVC, a saber:

• Componente Mosistema interativo. È uma realização de software específica de domínio da estrutura central da aplicação. Representa a entidade (objeto) ou informação que é mantida persistente pelo sistema interativo. Esse componente pode ser um simples objeto ou instância de alguma classe composta.

• Componente View: Provê suporte a apresentação. É, na realidade, uma apresentação do objeto Model. Solicexibe os dados. O componente View envia uma mensagem ao componente Model associado a ele. Com isso, passa a existir uma associação entre os componentes View e Model. Consequentemente, toda alteração que ocorrer no componente Model implicará uma atualização do componente View. Ressalta-se que, podem existir várias apresentações, ou seja, múltiplas visões. Neste sentido, um grupo de componentes views pode estar associado a um determinado componente Model.

• Componente Controller: É usado para enviar mensagens para o coModel e fornece interface entre o componente Model e os views associados, bemcomo os dispositivos de interface do usuário como teclado e mouse. Esse componente é encarregado pelo tratamento de ações dos usuários, recebendo entradas dos usuários, checando a decisão a ser tomada e podendo invocar métodos do componente Model. Ressalta-se que, cada View pode ser imaginado como sendo intimamente associado a um componente Controller, sendo que cada um tem exatamente um Model, eum par View/Controller associado.

Arquitetura Arch/Slinky

A arquitetura Arch/Slinky pode ser vista como uma extensão da arquitetura Seeheim. A, relatamos sucintamente os objetivos para os componentes funcionais constituintes desta etura, ilustrados na figura 4.C, a saber:


• Componente Específico do Domínio: Este componente é responsável pela manipulação de dados e outras funções orientadas ao domínio de aplicação. Efunções são expostas ao ambiente externo do sistema interativo atravésinterface do usuário. É considerado como um núcleo funcional.

• Componente Adaptador de Domínio: Este com

ssas da

ponente agrega dados específicos do domínio em estruturas de níveis mais elevados, realiza a verificação semântica dos dados, aciona tarefas de diálogo do domínio iniciadas e relata erros semânticos. Esse componente é similar a Interface com Aplicação na arquitetura Seeheim.

• Componente de Diálogo: Este componente é encarregado de mediar a comunicação entre os componentes específicos de domínio e de apresentação de um sistema interativo, efetuando o mapeamento necessário. Além disso, o componente de diálogo também assegura a consistência entre múltiplas visões de dados e controla o seqüenciamento de tarefas.

• Componente de Apresentação: Este componente fornece um conjunto de objetos (independentes do toolkit) de apresentação para o componente de Diálogo. Esse componente pode ser visto como um componente de lógica de interação entre o sistema interativo e usuários finais.

• Componente do Toolkit de Interação: Este componente implementa a interação física entre usuário e computador, manipulando dispositivos de entrada e saída. Também é referenciado como Componente Físico de Interação.

2.5 Arquitetura PAC

A arquitetura PAC organiza um sistema interativo como uma hierarquia de agentes PAC (Presentation-Abstraction-Control). Cada tríplice PAC constitui um agente composto por três componentes fortemente acoplados. Nesta arquitetura, cada agente possui uma apresentação (a qual está relacionada ao comportamento perceptível de entrada e saída), uma abstração (núcleo funcional) e um controle (o qual expressa múltiplas formas de dependência). Uma ilustração da arquitetura PAC está representada na figura 5.A.

As seguintes responsabilidades estão associadas aos componentes da arquitetura PAC, a saber:

omunicar-se com outros agentes bem como expressar as dependências entre os componentes

tanto, quaisquer dependências são comunicadas através do componente Control. Não é permitida a comunicação direta entre o

vel de

ar o

tão

e

• Componente Control: Este componente é encarregado de c

Abstraction ou Presentation. Por

componente Abstraction e seu correspondente Presentation ou vice-versa.

• Componente Presentation: Este componente é encarregado pelo comportamento perceptível, ou seja, contém todas as decisões feitas a níaparência e interação ao ambiente externo do sistema interativo. É responsável pela comunicação entre a interface do usuário e a aplicação. É encarregado de interpretar ações dos usuários (como arrastar o mouse ou clicar em alguma botão), atualizar o estado de uma chave (indicando se está ligado ou desligada) enotificar o componente Control.

• Componente Abstraction: Este componente é responsável por realizar computações necessárias à lógica da aplicação como, por exemplo, determinvolume de um tanque na forma de cilindro. Neste caso, se a quantidade de algum líquida a ser armazenado no tanque excede ao valor limiar pré-estabelecido, eno componente Abstraction notifica a ocorrência ao componente Control. Por sua vez, o componente Control pode notificar o componente Presentation a fim de queste altere o estado relativo à condição volumétrica do tanque.


Observa-se pela figura 5.A que, todo e qualquer fluxo de informações entre os agentes ocorre através do componente Control de maneira hierárquica. O componente Control atua como u e

a m mediador oferecendo suporte ao mecanismo de coordenação bem como d

transformação entre os componentes Abstraction e Presentation. Os conectores na arquiteturPAC expressam as relações de comunicação entre os agentes.

Figura 5: Descrição Arquitetural Metamodelos PAC

2.6 Arquitetura PAC-Amodeus

A arquitetura etura híb ra PAC e ida na arquite a vez é ut funcional de um sist o Amodeus sidesigners, users an

A arquitetura bidirecional de informações entre os c rda o No i one indos agentes PAC e omponente Adaptador de Domínio (núcleo

onente de Apresentação através de seus componentes Abstraction e Presentation, respectivamente. Observa-se que o componente Abstraction pode ser conectado a um ou mais objetos do domínio providos pelo componente Adaptador de Domínio. Um componente de Presentation pode ser conectado a um ou mais objetos de apresentação providos pelo componente de Apresentação. Os conectores podem ser implementados com chamadas de procedimentos ou outro protocolo apropriado, dependendo dos requisitos do sistema interativo a ser desenvolvido. Uma motivação para comunicação direta é o desempenho.

e PAC-Amodeus

PAC-Amodeus é uma arquittura Arch/Slinky que por suema interativo. O termd systems.

rida onde se tem a arquitetuiliza como base para decomposiçãognifica assimilating models of

mbut

PAC-Amodeus fornece um fluxo dos da arquitetura Arch/Slinky, comnte Diálogo, existem dois fluxos de

(ii) comunicação direta com o c

omponentes henterior do comp

se pode observar pela figura 5.B.formações: (i) travessia hierárquica

funcional) e com o componente de Apresentação (lógica de interação) Um agente PAC pode estar relacionado ao Adaptador de Domínio ou ao comp



2.7 Vantagens e Limitações

. As arquiteturas de software comentadas nas seções anteriores apresentam

características próprias que as tornam aplicáveis e apropriadas em determinadas situaçõesCada uma das arquiteturas apresentadas possui vantagens e limitações que encontram-se resumidas tabela 1. Essa síntese fornece orientação aos projetistas em decisões acerca de qual r u tetura seja mais adequada q i a para atender os requisitos de um sistema interativo a ser

construído.

Arquitetura de Software

Vantagens Limitações

Seeheim

Oferece suporte a facilidade de modificação sob a érspectiva da aplicação e suporte a portabilidade.

Requer modificações no componente de Diálogo quando o toolkit de Apresentação é substituído. Isso é necessário para permitir o uso de atributos e objetos idiossincráticos do novo toolkit.

MVC

Vide Seeheim. Além disso, distribui o estado da interação entre agentes e suporta modularidade.

Vide Seeheim. Dificuldade de projetar uma arquitetura com base em agente devido a ausência de um conjunto explícito de níveis de abstração como encontrado em Arch/Slinky. Outra desvantagem é a homogeneidade da arquitetura uma vez que os aspectos funcionais são expressos num único estilo.

Arch/Slinky Sua partição funcional indica suporte a portabilidade e facilidade de modificação.

As camadas adicionais geram penalidade em termos de desempenho. Todavia, essa penalidade pode ser aceitável uma vez que tem havido significativa melhoria na performance do hardware.

PAC

Vide MVC. Oferece suporte as modificações no Diálogo. A hierarquia PAC é composta por um número geralmente grande de componentes de Diálogo.

Vide MVC. Não é fácil efetuar modificações na Apresentação, pois este componente é distribuído entre os agentes ‘folhas’ na hierarquia PAC.

PAC-Amodeus

Combina as vantagens de PAC e Arch/Slinky, oferecendo suporte a portabilidade, facilidade de modificação e escalabilidade.

Vide PAC e Arch/Slinky.

Tabela 1: Vantagens e Limitações de Arquiteturas de Sistemas Interativos


3 2BBibliografia Fontes de artigos e livros consultados acerca de Arquitetura de Software e assuntos

correlatos: • Arquitetura de Software: Desenvolvimento orientado para arquitetura – Antonio Mendes,

editora Campus 2002. • Engenharia de Software: Teoria e Prática – Shari Lawrence Pfleeger, editora Prentice Hall

2003. • HUWWISAU • HUSEI-CMUU • HUCSE-USCU

Technology

Saam & arquiteturas_iu_halan