Saam & arquiteturas_iu_halan

MBA-ENGSOFT Arquitetura de Software 1
© 2005 Halan Ridolphi

POLI / UFRJ
MBA Engenharia de Software – Turma 2004
Disciplina: Arquitetura de Software
Professor: Daniel Schneider
Aluno: Halan Ridolphi Alves


Sumário
1 Método SAAM ...........................................................................................................4
1.1 Arquitetura de Software .....................................................................................4
1.2 Análise Arquitetural ...........................................................................................4
1.3 Objetivos do SAAM ............................................................................................4
1.4 Desenvolvimento de Cenários..............................................................................5
1.5 Descrição de Arquitetura ....................................................................................5
1.6 Avaliação de Cada Cenário ..................................................................................6
1.7 Determinação da Interação de Cenários ................................................................6
1.8 Avaliação de Cenários e da Interação de Cenários ..................................................6
1.9 Métricas e Arquiteturas Candidatas ......................................................................7
1.10 Arquitetura Serpent ...........................................................................................7
2 Arquiteturas de Interface do Usuário .......................................................................... 10
2.1 Histórico de Evolução ....................................................................................... 10
2.2 Arquitetura Seeheim ........................................................................................ 10
2.3 Arquitetura MVC .............................................................................................. 12
2.4 Arquitetura Arch/Slinky .................................................................................... 12
2.5 Arquitetura PAC .............................................................................................. 13
2.6 Arquitetura PAC-Amodeus................................................................................. 14
2.7 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 complexidade dos
sistemas de software, aliados há demanda cada vez acentuada por 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:
• Definir um conjunto de cenários que representem usos importantes do ssistema
no domínio, envolvendo os pontos de vista de todos aqueles que possuem papéis
influenciadores no sistema;
• Utilizar cenários para gerar uma partição funcional do domínio, uma ordenação
parcial das funções e um acoplamento dos cenários às várias funções existentes
na 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 arquiteturas
que 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 pontuação
global das arquiteturas candidatas.
O método SAAM tem como base o uso de cenários, com os quais um analista pode usar
uma descrição de arquitetura de software para avaliar o potencial do sistema de software em
prover suporte a atributos de qualidade ou requisitos não-funcionais. Entretanto, é importante
observar 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 qual
o sistema de software encontra-se inserido bem como considerar as circunstâncias especificas
aquele contexto. Uma forma de atingirmos esse objetivo é fazendo uso de cenários a fim de
entender 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:

Figura 1: Atividades do SAAM

Nas seções seguintes, desenvolvemos os propósitos de cada atividade ilustrada para
método 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 considerar
possí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 apresentar interações,
considerando os principais influenciadores com papéis relevantes ao sistema de software, tais
como: usuário ou cliente, desenvolvedor, mantenedor e administrador de sistema.

1.5 Descrição de Arquitetura
Nesta etapa, o analista deve possuir uma representação arquitetural do sistema, para
cada análise em elaboração, fazendo uso de uma notação arquitetural definida, descrevendo
componentes e conectores utilizados na especificação da arquitetura. Isso possibilitará que o
pessoal envolvido na análise tenha um entendimento comum. A especificação arquitetural deve

informar os componentes funcionais e de dados do sistema de software bem como as relações
existentes entre eles. Assim, uma representação arquitetural fará uma distinção entre
componentes ativos (que efetuam transformação de dados) e componentes passivos (que
armazenam dados). Além disso, devemos considerar dois tipos 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 componente atua sobre um outro o habitando a executar alguma tarefa). É importante
observar que a descrição gráfica nos dá uma representação estática da arquitetura do sistema
de software. Esta representação é complementada através de uma representação dinâmica,
expressa em linguagem natural que fornece uma descrição do comportamento do sistema ao
longo do 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 caso,
os cenários representam funções que a arquitetura já possui. O segundo caso compreende
cenários que incluem funções, além das existentes, para as quais a arquitetura provê suporte.
Nesse caso, uma modificação deve ser feita à arquitetura através da adição ou alteração de um
componente 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:
• 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
Esta é uma etapa subjetiva do processo de análise arquitetural, envolvendo os principais
influenciadores do sistema de software. Nesta etapa, o analista realiza uma avaliação global
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étricas associadas aos cenários elaborados, para que se possa analisar qual arquitetura de
software, 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
visto pela Figura 1. Os tipos de cenários desenvolvidos influenciarão no nível de granulosidade
da arquitetura. A determinação de um conjunto de cenários depende do tipo de tarefas que o
sistema de software suportará. Neste contexto, os cenários elaborados têm um papel de grande
importância uma vez que eles ajudarão o analista a compreender a descrição arquitetural do
sistema de software.

1.10 Arquitetura Serpent
Analisemos uma das arquiteturas de software para interface do usuário denominada de
Serpent (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. A
comunicação na arquitetura Serpent também é mediada por meio de restrições a dados
compartilhados 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 registrado 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á focado no Gerente de Diálogo. Além
disso, o Gerente de Diálogo é particionado em componentes menores associados a
funcionalidades 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 de cenário
envolvendo 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 3: Evolução das Arquitetura de Software de Interface do Usuário

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


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

Figura 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
respostas (feedback) com usuários finais do sistema interativo.
• 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 aplicação.
Responde 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 é encarregado de tratar a
comunicação existente entre a interface do usuário e os componentes de lógica de
aplicação do sistema interativo. Isso é realizado por via da invocação de
procedimentos da aplicação. Assim, a comunicação com lógica da aplicação é feita
por 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 expressa a possibilidade do componente da
Interface com Aplicação utilizar um caminho secundário, desviando-se do


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 Arquitetura MVC
A arquitetura MVC (Model-View-Controller) organiza um sistema interativo em termos de
componentes funcionais denominados agentes. Um agente tem um estado, possui conhecimento
bem como é capaz de inicializar e reagir a eventos. Os agentes que se comunicam diretamente
com usuário são chamados de objetos de interação (interactors), Um objeto de interação
fornece ao usuário a representação perceptiva de seu estado interno. Na arquitetura MVC, um
sistema interativo é estruturado em um conjunto de agentes funcionais cooperativos. Neste
sentido, a arquitetura MVC estabelece uma divisão funcional do sistema interativo nos
componentes Model, View e Controller. Uma ilustração da arquitetura MVC é descrita na figura
4.B.
Na arquitetura MVC, o componente Model comunica-se diretamente com os componentes
View e Controller. O componente Model define a competência do agente, ou seja, seu núcleo
funcional. O componente View define o comportamento perceptivo do agente para a saída,
fornecendo suporte a apresentação. O componente Controller denota o comportamento
perceptivo do agente para entrada e, é encarregado de tratar as entradas e comandos dos
usuá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 arquitetura
MVC, a saber:
• Componente Model: Compreende os objetos estruturais e o núcleo funcional do
sistema 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. Solicita dados do componente Model associado e
exibe 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 componente
Model e fornece interface entre o componente Model e os views associados, bem
como 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, embora um componente Model possa ter mais de
um par View/Controller associado.

2.4 Arquitetura Arch/Slinky
A arquitetura Arch/Slinky pode ser vista como uma extensão da arquitetura Seeheim. A
seguir, relatamos sucintamente os objetivos para os componentes funcionais constituintes desta
arquitetura, 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. Essas
funções são expostas ao ambiente externo do sistema interativo através da
interface do usuário. É considerado como um núcleo funcional.
• Componente Adaptador de Domínio: Este componente 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:
• Componente Control: Este componente é encarregado de comunicar-se com
outros agentes bem como expressar as dependências entre os componentes
Abstraction ou Presentation. Portanto, quaisquer dependências são comunicadas
através do componente Control. Não é permitida a comunicação direta entre o
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ível de
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) e
notificar o componente Control.
• Componente Abstraction: Este componente é responsável por realizar
computações necessárias à lógica da aplicação como, por exemplo, determinar o
volume 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, então
o componente Abstraction notifica a ocorrência ao componente Control. Por sua
vez, o componente Control pode notificar o componente Presentation a fim de que
este 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 um mediador oferecendo suporte ao mecanismo de coordenação bem como de
transformação entre os componentes Abstraction e Presentation. Os conectores na arquitetura
PAC expressam as relações de comunicação entre os agentes.

Figura 5: Descrição Arquitetural Metamodelos PAC e PAC-Amodeus

2.6 Arquitetura PAC-Amodeus
A arquitetura PAC-Amodeus é uma arquitetura híbrida onde se tem a arquitetura PAC
embutida na arquitetura Arch/Slinky que por sua vez é utiliza como base para decomposição
funcional de um sistema interativo. O termo Amodeus significa assimilating models of
designers, users and systems.
A arquitetura PAC-Amodeus fornece um fluxo bidirecional de informações entre os
componentes herdados da arquitetura Arch/Slinky, como se pode observar pela figura 5.B. No
interior do componente Diálogo, existem dois fluxos de informações: (i) travessia hierárquica
dos agentes PAC e (ii) comunicação direta com o componente Adaptador de Domínio (núcleo
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 componente 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.


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ções.
Cada 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
arquitetura seja mais adequada para atender os requisitos de um sistema interativo a ser
construído.

Arquitetura de Vantagens Limitações
Software
Requer modificações no
componente de Diálogo quando o
Oferece suporte a facilidade de
toolkit de Apresentação é
modificação sob a érspectiva da
Seeheim substituído. Isso é necessário
aplicação e suporte a
para permitir o uso de atributos e
portabilidade.
objetos idiossincráticos do novo
toolkit.
Vide Seeheim.
Dificuldade de projetar uma
arquitetura com base em agente
devido a ausência de um conjunto
Vide Seeheim.
explícito de níveis de abstração
Além disso, distribui o estado da
MVC como encontrado em Arch/Slinky.
interação entre agentes e suporta
Outra desvantagem é a
modularidade.
homogeneidade da arquitetura
uma vez que os aspectos
funcionais são expressos num
único estilo.
As camadas adicionais geram
penalidade em termos de
Sua partição funcional indica desempenho. Todavia, essa
Arch/Slinky suporte a portabilidade e facilidade penalidade pode ser aceitável
de modificação. uma vez que tem havido
significativa melhoria na
performance do hardware.
Vide MVC. Vide MVC.
Oferece suporte as modificações no Não é fácil efetuar modificações
Diálogo. A hierarquia PAC é na Apresentação, pois este
PAC
composta por um número componente é distribuído entre os
geralmente grande de agentes ‘folhas’ na hierarquia
componentes de Diálogo. PAC.
Combina as vantagens de PAC e
Arch/Slinky, oferecendo suporte a
PAC-Amodeus Vide PAC e Arch/Slinky.
portabilidade, facilidade de
modificação e escalabilidade.
Tabela 1: Vantagens e Limitações de Arquiteturas de Sistemas Interativos


3 Bibliografia
2B

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.
• WWISA
HU U

• SEI-CMU
HU U

• CSE-USC
HU U


Saam & arquiteturas_iu_halan

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Saam & arquiteturas_iu_halan

Ähnlich wie Saam & arquiteturas_iu_halan (20)

Mehr von Halan Ridolphi

Mehr von Halan Ridolphi (9)

Saam & arquiteturas_iu_halan