SlideShare uma empresa Scribd logo
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




MBA-ENGSOFT                       Arquitetura de Software   2
© 2005 Halan Ridolphi
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




MBA-ENGSOFT                                             Arquitetura de Software                                          3
© 2005 Halan Ridolphi
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.



MBA-ENGSOFT                                Arquitetura de Software                            4
© 2005 Halan Ridolphi
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
MBA-ENGSOFT                                Arquitetura de Software                           5
© 2005 Halan Ridolphi
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

MBA-ENGSOFT                               Arquitetura de Software                           6
© 2005 Halan Ridolphi
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
MBA-ENGSOFT                               Arquitetura de Software                             7
© 2005 Halan Ridolphi
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

MBA-ENGSOFT                               Arquitetura de Software                            8
© 2005 Halan Ridolphi
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.




MBA-ENGSOFT                               Arquitetura de Software                          9
© 2005 Halan Ridolphi
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.

MBA-ENGSOFT                               Arquitetura de Software                          10
© 2005 Halan Ridolphi
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

MBA-ENGSOFT                             Arquitetura de Software                           11
© 2005 Halan Ridolphi
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:



MBA-ENGSOFT                               Arquitetura de Software                           12
© 2005 Halan Ridolphi
•   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.



MBA-ENGSOFT                                 Arquitetura de Software                           13
© 2005 Halan Ridolphi
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.

MBA-ENGSOFT                              Arquitetura de Software                          14
© 2005 Halan Ridolphi
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




MBA-ENGSOFT                               Arquitetura de Software                              15
© 2005 Halan Ridolphi
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




MBA-ENGSOFT                               Arquitetura de Software                          16
© 2005 Halan Ridolphi

Mais conteúdo relacionado

Mais procurados

Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
Carlos Henrique Martins da Silva
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
Fernando Nogueira
 
Introdução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUPIntrodução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUP
Vagner Santana
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
Igor Takenami
 
A disciplina Teste no RUP
A disciplina Teste no RUPA disciplina Teste no RUP
A disciplina Teste no RUP
tecprog2010
 
Processo Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de SoftwareProcesso Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de Software
elliando dias
 
Resumo Sobre Análise de Pontos de Função
Resumo Sobre Análise de Pontos de FunçãoResumo Sobre Análise de Pontos de Função
Resumo Sobre Análise de Pontos de Função
Gustavo Adolfo Alencar
 
Apresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rupApresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rup
Jarbas Pereira
 
Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software Rup
Felipe
 
Ferramentas Case - fase de análise e projeto
Ferramentas Case - fase de análise e projetoFerramentas Case - fase de análise e projeto
Ferramentas Case - fase de análise e projeto
Helio Henrique L. C. Monte-Alto
 
Aula1 astah
Aula1 astahAula1 astah
Aula1 astah
Gizele Souza
 
Eng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de softwareEng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de software
Manuel Menezes de Sequeira
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Marcelo Yamaguti
 
Análise de processos fluxogrmas aula dia 16-08
Análise de processos fluxogrmas   aula dia 16-08Análise de processos fluxogrmas   aula dia 16-08
Análise de processos fluxogrmas aula dia 16-08
Fabiano Fersant
 
Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)
AnthonnyDayvson
 
Projeto de Sistemas - Aula005
Projeto de Sistemas - Aula005Projeto de Sistemas - Aula005
Projeto de Sistemas - Aula005
Cláudio Amaral
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
Adriano Tavares
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
Vagner Santana
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
Rodrigo Gomes da Silva
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
sergiocrespo
 

Mais procurados (20)

Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Apresentação RUP
Apresentação RUPApresentação RUP
Apresentação RUP
 
Introdução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUPIntrodução à Engenharia de Requisitos e RUP
Introdução à Engenharia de Requisitos e RUP
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
A disciplina Teste no RUP
A disciplina Teste no RUPA disciplina Teste no RUP
A disciplina Teste no RUP
 
Processo Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de SoftwareProcesso Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de Software
 
Resumo Sobre Análise de Pontos de Função
Resumo Sobre Análise de Pontos de FunçãoResumo Sobre Análise de Pontos de Função
Resumo Sobre Análise de Pontos de Função
 
Apresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rupApresentação modelagem de_negócio_rup
Apresentação modelagem de_negócio_rup
 
Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software Rup
 
Ferramentas Case - fase de análise e projeto
Ferramentas Case - fase de análise e projetoFerramentas Case - fase de análise e projeto
Ferramentas Case - fase de análise e projeto
 
Aula1 astah
Aula1 astahAula1 astah
Aula1 astah
 
Eng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de softwareEng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de software
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Análise de processos fluxogrmas aula dia 16-08
Análise de processos fluxogrmas   aula dia 16-08Análise de processos fluxogrmas   aula dia 16-08
Análise de processos fluxogrmas aula dia 16-08
 
Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)Eng de soft. ciclo de vida PARTE(2)
Eng de soft. ciclo de vida PARTE(2)
 
Projeto de Sistemas - Aula005
Projeto de Sistemas - Aula005Projeto de Sistemas - Aula005
Projeto de Sistemas - Aula005
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
 

Destaque

Governança TI halan
Governança TI halanGovernança TI halan
Governança TI halan
Halan Ridolphi
 
El aprendizaje cooperativo en el aula
El aprendizaje cooperativo en el aulaEl aprendizaje cooperativo en el aula
El aprendizaje cooperativo en el aula
Alejandraaa17
 
SHARE Atlanta Workshop - Practical tools and techniques for the share point i...
SHARE Atlanta Workshop - Practical tools and techniques for the share point i...SHARE Atlanta Workshop - Practical tools and techniques for the share point i...
SHARE Atlanta Workshop - Practical tools and techniques for the share point i...
Ruven Gotz
 
Planejamento do processo_de_software_halan
Planejamento do processo_de_software_halanPlanejamento do processo_de_software_halan
Planejamento do processo_de_software_halan
Halan Ridolphi
 
A galinha verde
A galinha verde A galinha verde
A galinha verde
popi97
 
Estudo de caso_com_ferramentas_da_qualidade_halan
Estudo de caso_com_ferramentas_da_qualidade_halanEstudo de caso_com_ferramentas_da_qualidade_halan
Estudo de caso_com_ferramentas_da_qualidade_halan
Halan Ridolphi
 
E book klant 4-0 - partnership marketing
E book klant 4-0 - partnership marketingE book klant 4-0 - partnership marketing
E book klant 4-0 - partnership marketing
Sjors van Leeuwen
 
Códigos de Ética Profissional
Códigos de Ética ProfissionalCódigos de Ética Profissional
Códigos de Ética Profissional
Halan Ridolphi
 

Destaque (9)

Governança TI halan
Governança TI halanGovernança TI halan
Governança TI halan
 
El aprendizaje cooperativo en el aula
El aprendizaje cooperativo en el aulaEl aprendizaje cooperativo en el aula
El aprendizaje cooperativo en el aula
 
Afstudeeronderzoek
AfstudeeronderzoekAfstudeeronderzoek
Afstudeeronderzoek
 
SHARE Atlanta Workshop - Practical tools and techniques for the share point i...
SHARE Atlanta Workshop - Practical tools and techniques for the share point i...SHARE Atlanta Workshop - Practical tools and techniques for the share point i...
SHARE Atlanta Workshop - Practical tools and techniques for the share point i...
 
Planejamento do processo_de_software_halan
Planejamento do processo_de_software_halanPlanejamento do processo_de_software_halan
Planejamento do processo_de_software_halan
 
A galinha verde
A galinha verde A galinha verde
A galinha verde
 
Estudo de caso_com_ferramentas_da_qualidade_halan
Estudo de caso_com_ferramentas_da_qualidade_halanEstudo de caso_com_ferramentas_da_qualidade_halan
Estudo de caso_com_ferramentas_da_qualidade_halan
 
E book klant 4-0 - partnership marketing
E book klant 4-0 - partnership marketingE book klant 4-0 - partnership marketing
E book klant 4-0 - partnership marketing
 
Códigos de Ética Profissional
Códigos de Ética ProfissionalCódigos de Ética Profissional
Códigos de Ética Profissional
 

Semelhante a Saam & arquiteturas_iu_halan

Sis avionico
Sis avionicoSis avionico
Sis avionico
williamfau
 
Trabalho individual
Trabalho individualTrabalho individual
Trabalho individual
Alessandra Fraydewoks
 
diagrama de componentes
diagrama de componentesdiagrama de componentes
diagrama de componentes
elliando dias
 
Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...
Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...
Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...
Lenin Abadie
 
Implementing Product Line Variabilities
Implementing Product Line VariabilitiesImplementing Product Line Variabilities
Implementing Product Line Variabilities
Michel Alves
 
Objectory
ObjectoryObjectory
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
elliando dias
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
Caroline Raquel Rodrigues
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
Rudson Kiyoshi Souza Carvalho
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
wilsonguns
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Fábio Nogueira de Lucena
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
CursoSENAC
 
Projeto de Software
Projeto de SoftwareProjeto de Software
Projeto de Software
Wagner Zaparoli
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
Robson Silva Espig
 
Dfd
DfdDfd
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
Athena542429
 
Aula15 arquitetura software_01_introducao-convertido
Aula15 arquitetura software_01_introducao-convertidoAula15 arquitetura software_01_introducao-convertido
Aula15 arquitetura software_01_introducao-convertido
Ana Claudia Annunciação
 
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGILAula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
CarlosHenriqueRamalh2
 

Semelhante a Saam & arquiteturas_iu_halan (20)

Sis avionico
Sis avionicoSis avionico
Sis avionico
 
Trabalho individual
Trabalho individualTrabalho individual
Trabalho individual
 
diagrama de componentes
diagrama de componentesdiagrama de componentes
diagrama de componentes
 
Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...
Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...
Uma Arquitetura para a Implantação Automática de Serviços em Infraestruturas ...
 
Implementing Product Line Variabilities
Implementing Product Line VariabilitiesImplementing Product Line Variabilities
Implementing Product Line Variabilities
 
Objectory
ObjectoryObjectory
Objectory
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Projeto de Software
Projeto de SoftwareProjeto de Software
Projeto de Software
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
Dfd
DfdDfd
Dfd
 
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
 
Aula15 arquitetura software_01_introducao-convertido
Aula15 arquitetura software_01_introducao-convertidoAula15 arquitetura software_01_introducao-convertido
Aula15 arquitetura software_01_introducao-convertido
 
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGILAula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
Aula 03 - IBM Rational Unified Process- METODOLOGIA ÁGIL
 

Mais de Halan Ridolphi

Estudo de caso_com_app_halan
Estudo de caso_com_app_halanEstudo de caso_com_app_halan
Estudo de caso_com_app_halan
Halan Ridolphi
 
Estudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halanEstudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halan
Halan Ridolphi
 
Monografia eng soft1_halan
Monografia eng soft1_halanMonografia eng soft1_halan
Monografia eng soft1_halan
Halan Ridolphi
 
Artigo halan t14_seminário21102006
Artigo halan t14_seminário21102006Artigo halan t14_seminário21102006
Artigo halan t14_seminário21102006
Halan Ridolphi
 
Artigo halan t14_seminário28042007
Artigo halan t14_seminário28042007Artigo halan t14_seminário28042007
Artigo halan t14_seminário28042007
Halan Ridolphi
 
Artigo halan t14_seminário07072007
Artigo halan t14_seminário07072007Artigo halan t14_seminário07072007
Artigo halan t14_seminário07072007
Halan Ridolphi
 
Artigo halan t14_seminário10112007
Artigo halan t14_seminário10112007Artigo halan t14_seminário10112007
Artigo halan t14_seminário10112007
Halan Ridolphi
 
Governança TI
Governança TIGovernança TI
Governança TI
Halan Ridolphi
 
Como Conduzir Reuniões Eficazes
Como Conduzir Reuniões EficazesComo Conduzir Reuniões Eficazes
Como Conduzir Reuniões Eficazes
Halan Ridolphi
 

Mais de Halan Ridolphi (9)

Estudo de caso_com_app_halan
Estudo de caso_com_app_halanEstudo de caso_com_app_halan
Estudo de caso_com_app_halan
 
Estudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halanEstudo de caso_com_modelagem_de_software_halan
Estudo de caso_com_modelagem_de_software_halan
 
Monografia eng soft1_halan
Monografia eng soft1_halanMonografia eng soft1_halan
Monografia eng soft1_halan
 
Artigo halan t14_seminário21102006
Artigo halan t14_seminário21102006Artigo halan t14_seminário21102006
Artigo halan t14_seminário21102006
 
Artigo halan t14_seminário28042007
Artigo halan t14_seminário28042007Artigo halan t14_seminário28042007
Artigo halan t14_seminário28042007
 
Artigo halan t14_seminário07072007
Artigo halan t14_seminário07072007Artigo halan t14_seminário07072007
Artigo halan t14_seminário07072007
 
Artigo halan t14_seminário10112007
Artigo halan t14_seminário10112007Artigo halan t14_seminário10112007
Artigo halan t14_seminário10112007
 
Governança TI
Governança TIGovernança TI
Governança TI
 
Como Conduzir Reuniões Eficazes
Como Conduzir Reuniões EficazesComo Conduzir Reuniões Eficazes
Como Conduzir Reuniões Eficazes
 

Saam & arquiteturas_iu_halan

  • 1. MBA-ENGSOFT Arquitetura de Software 1 © 2005 Halan Ridolphi
  • 2. POLI / UFRJ MBA Engenharia de Software – Turma 2004 Disciplina: Arquitetura de Software Professor: Daniel Schneider Aluno: Halan Ridolphi Alves MBA-ENGSOFT Arquitetura de Software 2 © 2005 Halan Ridolphi
  • 3. 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 MBA-ENGSOFT Arquitetura de Software 3 © 2005 Halan Ridolphi
  • 4. 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. MBA-ENGSOFT Arquitetura de Software 4 © 2005 Halan Ridolphi
  • 5. 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 MBA-ENGSOFT Arquitetura de Software 5 © 2005 Halan Ridolphi
  • 6. 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 MBA-ENGSOFT Arquitetura de Software 6 © 2005 Halan Ridolphi
  • 7. 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 MBA-ENGSOFT Arquitetura de Software 7 © 2005 Halan Ridolphi
  • 8. 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 MBA-ENGSOFT Arquitetura de Software 8 © 2005 Halan Ridolphi
  • 9. 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. MBA-ENGSOFT Arquitetura de Software 9 © 2005 Halan Ridolphi
  • 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çã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. MBA-ENGSOFT Arquitetura de Software 10 © 2005 Halan Ridolphi
  • 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 do MBA-ENGSOFT Arquitetura de Software 11 © 2005 Halan Ridolphi
  • 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 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: MBA-ENGSOFT Arquitetura de Software 12 © 2005 Halan Ridolphi
  • 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ê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. MBA-ENGSOFT Arquitetura de Software 13 © 2005 Halan Ridolphi
  • 14. 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. MBA-ENGSOFT Arquitetura de Software 14 © 2005 Halan Ridolphi
  • 15. 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 MBA-ENGSOFT Arquitetura de Software 15 © 2005 Halan Ridolphi
  • 16. 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 MBA-ENGSOFT Arquitetura de Software 16 © 2005 Halan Ridolphi