MBA-ENGSOFT             Arquitetura de Software   1© 2005 Halan Ridolphi
POLI / UFRJ     MBA Engenharia de Software – Turma 2004     Disciplina: Arquitetura de Software     Professor: Daniel Schn...
Sumário1  Método SAAM .......................................................................................................
1 Método SAAM1.1 Arquitetura de Software       O crescimento continuando tanto em termos de tamanho quanto da complexidade...
Visando realizar a análise arquitetural, torna-se necessário considerar o contexto no qualo sistema de software encontra-s...
informar os componentes funcionais e de dados do sistema de software bem como as relaçõesexistentes entre eles. Assim, uma...
arquitetural do sistema de software e determinou as interações de cenários existentes. Estaavaliação reflete a influência ...
componente é encarregado de mediar à comunicação da interação do usuário com a aplicação. Acomunicação na arquitetura Serp...
comportamento do diálogo com usuário e, portanto, está focado no Gerente de Diálogo. Alémdisso, o Gerente de Diálogo é par...
2 Arquiteturas de Interface do Usuário       Um sistema interativo pode ser decomposto em dois componentes de software pri...
A figura 4.A ilustra a organização global dos componentes da arquitetura Seeheim.Figura 4: Descrição Arquitetural Metamode...
componente de Controle de Diálogo, objetivando melhorar o desempenho.              Entretanto, o Controle de Diálogo é o r...
•   Componente Específico do Domínio: Este componente é responsável pela                manipulação de dados e outras funç...
Observa-se pela figura 5.A que, todo e qualquer fluxo de informações entre os agentesocorre através do componente Control ...
2.7 Vantagens e Limitações       As arquiteturas de software comentadas nas seções anteriores apresentamcaracterísticas pr...
3 Bibliografia   2B      Fontes de artigos e livros consultados acerca de Arquitetura de Software e assuntoscorrelatos:   ...
Upcoming SlideShare
Loading in …5
×

Saam & arquiteturas_iu_halan

1,013 views

Published on

Software Engineering

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,013
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Saam & arquiteturas_iu_halan

  1. 1. MBA-ENGSOFT Arquitetura de Software 1© 2005 Halan Ridolphi
  2. 2. POLI / UFRJ MBA Engenharia de Software – Turma 2004 Disciplina: Arquitetura de Software Professor: Daniel Schneider Aluno: Halan Ridolphi AlvesMBA-ENGSOFT Arquitetura de Software 2© 2005 Halan Ridolphi
  3. 3. Sumário1 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 ...........................................................................................72 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 .................................................................................... 153 Bibliografia ............................................................................................................. 16MBA-ENGSOFT Arquitetura de Software 3© 2005 Halan Ridolphi
  4. 4. 1 Método SAAM1.1 Arquitetura de Software O crescimento continuando tanto em termos de tamanho quanto da complexidade dossistemas de software, aliados há demanda cada vez acentuada por sistemas com maiorconfiabilidade, bom desempenho e menor custo fazem com que o desafio do desenvolvimentode software extrapole o projeto de algoritmos e estruturas de dados. Para lidar com acomplexidade crescente, a especificação da estrutura global, ou seja, a arquitetura de softwarepassa a ser um aspecto técnico de maior relevância no projeto de sistemas de software degrande porte. Neste sentido, torna-se cada vez mais evidente que processos de engenharia desoftware requeiram projeto arquitetural de software. No projeto de um sistema de software, aarquitetura de software compõe-se de subsistemas ou componentes (responsáveis pelocomportamento do sistema), de conectores (interligando os componentes) e de padrões deconexão (possibilitando vários tipos de interação e compartilhamento de informações entre oscomponentes).1.2 Análise Arquitetural Análise Arquitetural é um processo iterativo de refinamento do modelo arquitetural inicialde um sistema, o qual é derivado a partir de um conjunto de requisitos arquiteturais compostospor atributos de qualidade e de projeto. É muitas vezes difícil associar novas arquiteturas aatributos de qualidade. Mas comumente, observa-se que, os desenvolvedores de softwareconcentram-se nos aspectos funcionais das arquiteturas. Assim, o propósito principal da análisearquitetural é verificar se os requisitos arquiteturais têm sido considerados durante o processode desenvolvimento de um sistema de software.1.3 Objetivos do SAAM O método SAAM (Software Architecture Analysis Method) para análise arquitetural desoftware foi concebido inicialmente com objetivo de apoiar arquitetos de software a omparemsoluçõ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 arquiteturasque estão sendo avaliadas, denominadas de arquiteturas candidatas. Recai sobre o avaliador aresponsabilidade de determinar os pesos dos cenários considerados bem como a pontuaçãoglobal das arquiteturas candidatas. O método SAAM tem como base o uso de cenários, com os quais um analista pode usaruma descrição de arquitetura de software para avaliar o potencial do sistema de software emprover suporte a atributos de qualidade ou requisitos não-funcionais. Entretanto, é importanteobservar 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.MBA-ENGSOFT Arquitetura de Software 4© 2005 Halan Ridolphi
  5. 5. Visando realizar a análise arquitetural, torna-se necessário considerar o contexto no qualo sistema de software encontra-se inserido bem como considerar as circunstâncias especificasaquele contexto. Uma forma de atingirmos esse objetivo é fazendo uso de cenários a fim deentender 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 possueminterdependê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 paramétodo SAAM.1.4 Desenvolvimento de Cenários O foco desta etapa é o desenvolvimento de cenários de tarefas que ilustrem os tipos deatividades 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 essescenários, o analista deve capturar todos os usos importantes do sistema, os quais irão refletir osrequisitos 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, taiscomo: 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, paracada análise em elaboração, fazendo uso de uma notação arquitetural definida, descrevendocomponentes e conectores utilizados na especificação da arquitetura. Isso possibilitará que opessoal envolvido na análise tenha um entendimento comum. A especificação arquitetural deveMBA-ENGSOFT Arquitetura de Software 5© 2005 Halan Ridolphi
  6. 6. informar os componentes funcionais e de dados do sistema de software bem como as relaçõesexistentes entre eles. Assim, uma representação arquitetural fará uma distinção entrecomponentes ativos (que efetuam transformação de dados) e componentes passivos (quearmazenam dados). Além disso, devemos considerar dois tipos de conexões: (a) conexões dedados (onde se tem passagem de dados entre componentes) e (b) conexões de controle (naqual um 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 descrição do comportamento do sistema aolongo do tempo.1.6 Avaliação de Cada Cenário Para cada cenário, o analista deve determinar se a arquitetura candidata oferece suportediretamente à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 compreendecená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 umcomponente ou conexão. Ao final, o analista deve obter uma tabela sumarizando os cenáriosonde a arquitetura candidata provê suporte aos requisitos não-funcionais associados. Nestatabela, 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 exigemmodificações em algum componente ou conexão. A identificação da interação de cenáriospermite ao analista saber como a funcionalidade do sistema de software é alocada durante oprojeto. Em outras palavras, a interação de cenários mostra as tarefas às quais os componentesestão associados. Na realidade, a determinação da interação de cenários avalia a extensão paraa qual a arquitetura provê suporte a uma separação de interesses apropriada. Por exemplo, umelevado 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 oscomponentes 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 principaisinfluenciadores do sistema de software. Nesta etapa, o analista realiza uma avaliação globalatribuindo uma pontuação a cada cenário e interação de cenário. Isso tem como baseimplicaçõ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çãoMBA-ENGSOFT Arquitetura de Software 6© 2005 Halan Ridolphi
  7. 7. arquitetural do sistema de software e determinou as interações de cenários existentes. Estaavaliaçã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 demétricas associadas aos cenários elaborados, para que se possa analisar qual arquitetura desoftware, dentre as arquiteturas candidatas, provê suporte melhor ao conjunto de requisitosnão-funcionais desejados para o sistema de software. Ressalta-se que, as atividades do método SAAM de Descrição de Arquitetura eDesenvolvimento de Cenários de possuem elevado grau de dependência entre si, como pode servisto pela Figura 1. Os tipos de cenários desenvolvidos influenciarão no nível de granulosidadeda arquitetura. A determinação de um conjunto de cenários depende do tipo de tarefas que osistema de software suportará. Neste contexto, os cenários elaborados têm um papel de grandeimportância uma vez que eles ajudarão o analista a compreender a descrição arquitetural dosistema de software.1.10 Arquitetura Serpent Analisemos uma das arquiteturas de software para interface do usuário denominada deSerpent (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. Ocomponente de apresentação é o que oferece suporte às técnicas de interação nos níveis lógicoe físico, sendo completamente independente da semântica da aplicação. A coordenação entreesses dois primeiros componentes é feita através do controlador de diálogo. Esse terceiroMBA-ENGSOFT Arquitetura de Software 7© 2005 Halan Ridolphi
  8. 8. componente é encarregado de mediar à comunicação da interação do usuário com a aplicação. Acomunicação na arquitetura Serpent também é mediada por meio de restrições a dadoscompartilhados do banco de dados. Esta estrutura é implementada como um banco de dadosativo. Deste modo, quando os valores no banco de dados são alterados, os mesmos sãoautomaticamente comunicados a qualquer componente registrado que possua interesse sobre odado modificado. O metamodelo Arch/Slinky de arquiteturas de interface do usuário serve como umapartição funcional canônica neste domínio de aplicação. Ele é uma extensão do modelo Seeheimde sistemas de gerenciamento de interface do usuário, e é o resultado de ampla discussão eacordo entre desenvolvedores e pesquisadores de interface do usuário. Arch/Slinky identificaramcinco 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 sistemasinterativos (Arch/Slinky) na arquitetura Serpent obteremos como resultado a descriçãoarquitetural ilustrada na figura 2.B. A arquitetura Serpent foi redesenhada fazendo uso da notação arquitetural ilustrada nafigura 2. Após obtemos uma nova visão da arquitetura Serpent baseada no metamodeloArch/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 quandodesejamos, 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 amodificaçã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 ocomportamento do diálogo com usuário, e o Banco de Dados Ativo, o qual mantém o estado dodiálogo. Esse cenário que se deseja fazer uma modificação está associado à mudança noMBA-ENGSOFT Arquitetura de Software 8© 2005 Halan Ridolphi
  9. 9. comportamento do diálogo com usuário e, portanto, está focado no Gerente de Diálogo. Alémdisso, o Gerente de Diálogo é particionado em componentes menores associados afuncionalidades 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árioenvolvendo modificação de aparência de um sistema interativo.MBA-ENGSOFT Arquitetura de Software 9© 2005 Halan Ridolphi
  10. 10. 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çãocompreende toda a funcionalidade do sistema interativo enquanto o software de interface dousuário é encarregado de mediar à comunicação entre o usuário e a aplicação do sistema. Nestecontexto, o propósito desta seção é apresentar conceitos básicos acerca de arquitetura desoftware de interface do usuário.2.1 Histórico de Evolução As arquiteturas Seeheim e MVC (Model-View-Controller) foram as primeiras propostas demetamodelos de interface do usuário surgidas no início da década de 1980. O desenvolvimentodessas 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). Osframeworks de aplicação foram derivados de evolução lógica de bibliotecas de classes assimcomo os toolkits e toolkits virtuais. Essas duas correntes de lógicas de desenvolvimentocontinuaram a evoluir até culminar no aparecimento da arquitetura PAC-Amodeus. A figura 3ilustra a evolução histórica das várias arquiteturas de software de interface do usuário e seusrelacionamentos de herança. Nas seções seguintes relatamos descrições conceituais sucintasacerca dessas arquiteturas de software.Figura 3: Evolução das Arquitetura de Software de Interface do Usuário2.2 Arquitetura Seeheim A arquitetura Seeheim tem essa denominação em virtude de um workshop sobre UserInterface Management System (UIMS) realizado em Seeheim, Alemanha. Muitos UIMS sãoorientados a essa arquitetura de software.MBA-ENGSOFT Arquitetura de Software 10© 2005 Halan Ridolphi
  11. 11. 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 doMBA-ENGSOFT Arquitetura de Software 11© 2005 Halan Ridolphi
  12. 12. 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 decomponentes funcionais denominados agentes. Um agente tem um estado, possui conhecimentobem como é capaz de inicializar e reagir a eventos. Os agentes que se comunicam diretamentecom usuário são chamados de objetos de interação (interactors), Um objeto de interaçãofornece ao usuário a representação perceptiva de seu estado interno. Na arquitetura MVC, umsistema interativo é estruturado em um conjunto de agentes funcionais cooperativos. Nestesentido, a arquitetura MVC estabelece uma divisão funcional do sistema interativo noscomponentes Model, View e Controller. Uma ilustração da arquitetura MVC é descrita na figura4.B. Na arquitetura MVC, o componente Model comunica-se diretamente com os componentesView e Controller. O componente Model define a competência do agente, ou seja, seu núcleofuncional. O componente View define o comportamento perceptivo do agente para a saída,fornecendo suporte a apresentação. O componente Controller denota o comportamentoperceptivo do agente para entrada e, é encarregado de tratar as entradas e comandos dosusuá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 arquiteturaMVC, 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. Aseguir, relatamos sucintamente os objetivos para os componentes funcionais constituintes destaarquitetura, ilustrados na figura 4.C, a saber:MBA-ENGSOFT Arquitetura de Software 12© 2005 Halan Ridolphi
  13. 13. • 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êscomponentes fortemente acoplados. Nesta arquitetura, cada agente possui uma apresentação (aqual está relacionada ao comportamento perceptível de entrada e saída), uma abstração (núcleofuncional) e um controle (o qual expressa múltiplas formas de dependência). Uma ilustração daarquitetura PAC está representada na figura 5.A. As seguintes responsabilidades estão associadas aos componentes da arquitetura PAC, asaber: • 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.MBA-ENGSOFT Arquitetura de Software 13© 2005 Halan Ridolphi
  14. 14. Observa-se pela figura 5.A que, todo e qualquer fluxo de informações entre os agentesocorre através do componente Control de maneira hierárquica. O componente Control atuacomo um mediador oferecendo suporte ao mecanismo de coordenação bem como detransformação entre os componentes Abstraction e Presentation. Os conectores na arquiteturaPAC expressam as relações de comunicação entre os agentes.Figura 5: Descrição Arquitetural Metamodelos PAC e PAC-Amodeus2.6 Arquitetura PAC-Amodeus A arquitetura PAC-Amodeus é uma arquitetura híbrida onde se tem a arquitetura PACembutida na arquitetura Arch/Slinky que por sua vez é utiliza como base para decomposiçãofuncional de um sistema interativo. O termo Amodeus significa assimilating models ofdesigners, users and systems. A arquitetura PAC-Amodeus fornece um fluxo bidirecional de informações entre oscomponentes herdados da arquitetura Arch/Slinky, como se pode observar pela figura 5.B. Nointerior do componente Diálogo, existem dois fluxos de informações: (i) travessia hierárquicados agentes PAC e (ii) comunicação direta com o componente Adaptador de Domínio (núcleofuncional) 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 deApresentaçã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ínioprovidos pelo componente Adaptador de Domínio. Um componente de Presentation pode serconectado 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 protocoloapropriado, dependendo dos requisitos do sistema interativo a ser desenvolvido. Uma motivaçãopara comunicação direta é o desempenho.MBA-ENGSOFT Arquitetura de Software 14© 2005 Halan Ridolphi
  15. 15. 2.7 Vantagens e Limitações As arquiteturas de software comentadas nas seções anteriores apresentamcaracterí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-seresumidas tabela 1. Essa síntese fornece orientação aos projetistas em decisões acerca de qualarquitetura seja mais adequada para atender os requisitos de um sistema interativo a serconstruí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 InterativosMBA-ENGSOFT Arquitetura de Software 15© 2005 Halan Ridolphi
  16. 16. 3 Bibliografia 2B Fontes de artigos e livros consultados acerca de Arquitetura de Software e assuntoscorrelatos: • 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 UMBA-ENGSOFT Arquitetura de Software 16© 2005 Halan Ridolphi

×