UM CONJUNTO DE CARACTERÍSTICAS DESEJÁVEIS EM UMA ADL ...mestrado/diss/2007/mendes.pdf · de...

JUCIMAR DE ALMEIDA MENDES

UM CONJUNTO DE CARACTERÍSTICAS DESEJÁVEIS EM UMA ADL ORIENTADA A ASPECTOS

MARINGÁ

2007



Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientadora: Profa. Dra. Elisa Hatsue Moriya

Huzita

MARINGÁ

2007

Dados Internacionais de Catalogação-na-Publicação (CIP) (Biblioteca Central - UEM, Maringá – PR., Brasil)

Mendes, Jucimar de Almeida

M538c Um conjunto de características desejáveis em uma ADL

orientada a aspectos / Jucimar de Almeida. -- Maringá :

[s.n.], 2007.

167 p. : il. , figs., tabs.

Orientadora : Prof. Dr. Elisa Hatsue Moriya Huzita.

Dissertação (mestrado) - Universidade Estadual de

Maringá. Programa de Pós-graduação em Ciência da

Computação, 2007.

1. Arquitetura de software. 2. Linguagem de descrição de

arquitetura. 3. Sistemas distribuídos. 4. Desenvolvimento

de software orientado a aspectos. 5. ADL-OA. I.

Universidade Estadual de Maringá. Programa de Pós-graduação

em Ciência da Computação.

CDD 21.ed. 005.12028



Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Aprovado em 11/12/2007.

BANCA EXAMINADORA

Profa. Dra. Elisa Hatsue Moriya Huzita Universidade Estadual de Maringá – DIN/UEM

Profa. Dra. Maria Madalena Dias Universidade Estadual de Maringá – DIN/UEM

Prof. Dr. Marcelo Morandini Universidade de São Paulo – USP-Leste

DEDICATÓRIA

Aos meus amados pais,

Maria Carmem de Almeida Mendes e Osmar Mendes,

os quais com muito carinho, sempre perseveraram em ensinar-me na senda de luz,

preocupando-se em cingir-me com amor, fé e esperança.

AGRADECIMENTOS

Ao Eterno Criador, pelo rico dom da vida eterna a mim concedido e pelo Seu infinito amor

demonstrado para com a minha alma.

Aos meus amados pais, Maria Carmem e Osmar, que nunca mediram esforços para

propiciar condições a fim de que eu pudesse, com dignidade e honradez, galgar degraus nesta

vida sem me esquecer dos Degraus que conduzem à Vida Eterna.

À minha amada esposa Gilsimara Honório Antonelli Mendes, cuja ternura e doce

companhia muito me alentou durante esta árdua jornada, proporcionado o conforto necessário

nos momentos difíceis.

À minha brilhante orientadora, professora Elisa Hatsue Moriya Huzita, por sua sabedoria,

compreensão e paciência ao apontar-me o norte durante minha busca pelo conhecimento.

Aos inesquecíveis amigos participantes do Projeto DiSEN, com quem temos compartilhado

muitas idéias, vitais para a realização deste trabalho.

A todos os ilustres professores que passaram pela minha vida, desde os que se dedicaram a

me ensinar as primeiras letras até os que ministraram magníficas aulas durante esse curso de

mestrado.

Ao CNPQ (Conselho Nacional de Desenvolvimento Científico e Tecnológico) pelo apoio

financeiro concedido à pesquisa.

“Ainda que eu falasse as línguas dos homens e dos anjos,

e não tivesse amor,

seria como o metal que soa ou como o sino que tine.

E ainda que tivesse o dom de profecia, e conhecesse todos os mistérios e toda a ciência,

e ainda que tivesse toda a fé de maneira tal que transportasse os montes,

e não tivesse amor, nada seria.

E ainda que distribuísse toda a minha fortuna para sustento dos pobres,

e ainda que entregasse meu corpo para ser queimado,

e não tivesse amor, nada disso me aproveitaria.”

I Epístola do Apóstolo São Paulo aos Coríntios, Cap. 13, versos 1-3

BÍBLIA SAGRADA

RESUMO

Os desenvolvedores de sistemas de software distribuídos têm se deparado com diferentes

propriedades, tais como compartilhamento de recursos, abertura, transparência, estado

compartilhado, concorrência, independência de escala, tolerância a falhas e segurança. Muitos

dos interesses inerentes aos sistemas distribuídos não podem ser modularizados e compostos

apenas com o apoio das abstrações e mecanismos oferecidos pelo paradigma orientado a

objetos. À medida que a complexidade de um sistema de software é incrementada, os

interesses tendem a se espalhar por vários componentes, no nível arquitetural, de design e de

implementação. Isto conduz a uma separação de interesses ineficiente e ineficaz e,

conseqüentemente, dificulta o desenvolvimento, a manutenção e o reuso do software.

No âmbito do Desenvolvimento de Software Orientado a Aspectos, aspecto é a abstração

usada para modularizar interesses que entrecortam diversos componentes do software do

sistema.

Este trabalho apresenta uma coleção de diretrizes que norteiam o design de uma Linguagem

de Descrição de Arquitetura Orientada a Aspectos (ADL-OA). Com base nessas diretrizes é

proposto um conjunto de características desejáveis para uma ADL-OA.

Fundamentado no conjunto de características elaboradas, este trabalho culmina com uma

proposta de notação gráfica para uma ADL-OA. Foi realizado um experimento sobre a

arquitetura de um ambiente distribuído de desenvolvimento de software para mostrar os

benefícios do uso da notação proposta.

Palavras-Chave: Arquitetura de Software; Linguagem de Descrição de Arquitetura; Sistemas

Distribuídos; Desenvolvimento de Software Orientado a Aspectos.

ABSTRACT

Distributed system software developers have faced with different properties, such as resource

sharing, openness, transparency, shared state, concurrency, independence of scale, fault

tolerance, and security. Concerns inherent to distributed systems can not be effectively

modularized and composed only by support of abstractions and mechanisms provide by object

oriented paradigm. As the system complexity is increased, concerns tend to be scattered and

tangled through several components, on architectural, design and implementation levels. This

leads to an inefficient and ineffective separation of concerns, which consequently make more

difficult the software development, maintaining and reuse.

In the Aspect Oriented Software Development approach, aspect is an abstraction used for

modularize concerns that crosscut several system software components.

This work presents a collection of guidelines which support the design of an Aspect Oriented

Architectural Description Language (AO-ADL). Based upon those guidelines, this work

proposes a set of eligible characteristics for an AO-ADL.

Based on the set of characteristics previously elaborated, this work culminates with an AO-

ADL graphical notation proposal. Experimentation about an architecture of a distributed

software development environment was accomplished to shows the benefits by using the

proposed notation.

Key-Words: Software Architecture; Architecture Description Language; Distributed

Systems; Aspect Oriented Software Development.

LISTA DE FIGURAS

Nro Título Pág.

1.1 Metodologia empregada na elaboração das características desejáveis .............. 18

2.1 Host em um Sistema Distribuído ....................................................................... 22

2.2 Middleware em um Sistema Distribuído ........................................................... 22

2.3 Visão de funcionamento de um Sistema Distribuído ....................................... 23

2.4 Sistema Distribuído organizado como Middleware .......................................... 24

2.5 Estrutura Genérica de um Sistema Distribuído como um Middleware ............. 25

2.6 Dimensões de Transparências ........................................................................... 29

2.7 Mecanismos de Comunicação via APIs em Sistemas Distribuídos .................. 31

2.8 Aplicações Orientadas a Eventos Estruturadas em Camadas ............................ 32

5.1 Fases do desenvolvimento apoiadas na AOGA ................................................. 70

5.2 Aspectos arquiteturais em interfaces transversais ............................................. 70

5.3 As atividades para o ASAAM ........................................................................... 72

5.4-a Especificação convencional de uma arquitetura de software ........................... 75

5.4-b Especificação separada de interesses transversais no nível arquitetural ........... 75

6.1 Engenheiros de software interagem com o processo de software por meio de SAESs 86

6.2-a Usuário final utiliza a máquina por meio de uma solução de software ............. 87

6.2-b Engenheiro de software emprega uma SAES para se beneficiar da máquina ... 87

6.3-a Notação como interface entre o ser humano e a máquina ................................. 89

6.3-b Notação como interfaces entre SAESs .............................................................. 89

7.1 Arquitetura do DiSEN proposta em (PASCUTTI, 2002) .................................. 127

7.2 Arquitetura inicial do DiSEN em uma visão de módulos ................................. 130

7.3 Arquitetura do DiSEN em uma visão C&C (componente-e-conector) ............. 131

7.4 Componente Infra-estrutura modelado na forma de um middleware ................ 133

7.5 Arquitetura do DiSEN em uma visão C&C em uma abordagem OA ............... 134

7.6 Componente Supervisor de Configuração Dinâmica expandido ....................... 135

7.7 Componente Supervisor de Configuração modelado como um aspecto ........... 136

LISTA DE TABELAS

Nro Título Pág.

3.1 Documentação da arquitetura e os stakeholders ................................................ 41

5.1 Exemplos de aspectos e componentes ............................................................... 67

5.2 Comparação de ADLs OA ................................................................................. 80

6.1 Influência recíproca entre as diretrizes norteadores .......................................... 97

6.2 Diretrizes norteadoras atendidas pelas características desejáveis ..................... 112

6.3 Inter -relacionamento das características desejáveis em uma ADL-OA ........... 113

6.4 Comparação das ADLs-OA em relação às características propostas ................ 114

6.5 Proposta de uma notação gráfica para uma ADL-OA ....................................... 118

6.6 Formalismos empregados pelas principais ADLs para o domínio de SDs ........ 121

6.7 Algumas capacidades de modelagem encontradas nos formalismos estudados 121

6.8 Mapeamento dos elementos da notação visual proposta frente às características

elencadas

122

LISTA DE QUADROS

Nro Título Pág.

4.1 Framework de classificação e comparação de ADLs ............................................ 57

5.1 Regras heurísticas para avaliação de cenários ....................................................... 73

LISTA DE ABREVIATURAS

ADL Architectural Description Language (Linguagem de Descrição de Arquitetura)

ADL-OA Linguagem de Descrição de Arquitetura Orientada a Aspectos

ADS Ambiente de Desenvolvimento de Software

ADDS Ambiente Distribuído de Desenvolvimento de Software

API Application Programming Interface; Application Programmer Interface

ASAAM Aspectual Software Architecture Analysis Method

CASE Computer-Aided Software Engineering

CBSE Component-Based Software Engineering

CORBA Commom Object Request Broker Architecture

COTS Commercial Off-The-Shelf

CSP Communicating Sequential Processes

DiSEN Distributed Software Engineering Environment

DSOA Desenvolvimento de Software Orientado a Aspectos

GUI Graphical User Interface

LAN Local Area Network

LP Linguagem de Programação

MIL Module Interconnecting Language

OA Orientado a Aspectos

OO Orientado a Objetos

POA Programação Orientada a Aspectos

RMI Remote Method Invocation

RUP Rational Unified Process

SAES Solução de Apoio à Engenharia de Software

SD Sistema Distribuído

SO Sistema Operacional

SoC Separation of Concerns

TCP Transfer Control Protocol

UML Unified Modeling Language

XML Extensible Markup Language

WAN Wide Area Network

xiii

SUMÁRIO 1 – Introdução ........................................................................................................................... 15

1.1 Motivação ....................................................................................................................... 15 1.2 Objetivos ......................................................................................................................... 18 1.3 Metodologia da Pesquisa ................................................................................................ 18 1.4 Estrutura da Dissertação ................................................................................................. 19

2 – Sistemas Distribuídos ......................................................................................................... 21 2.1 Introdução ....................................................................................................................... 21 2.2 Conceito .......................................................................................................................... 21 2.3 Requisitos de Sistemas Distribuídos .............................................................................. 26 2.4 Desafios Encontrados no Design de Sistemas Distribuídos ........................................... 30

2.4.1 Desafio: Acesso e Configuração de Serviços .......................................................... 30 2.4.2 Desafio: Tratamento de Falhas ................................................................................ 31 2.4.3 Desafio: Concorrência ............................................................................................. 32 2.4.4 Desafio: Sincronização ............................................................................................ 33 2.4.5 Desafios genéricos ................................................................................................... 33

2.5 Considerações ................................................................................................................. 34 3 – Arquitetura de Software...................................................................................................... 35

3.1 Introdução ....................................................................................................................... 35 3.2 Conceito .......................................................................................................................... 36

3.2.1 Arquitetura versus Design ....................................................................................... 37 3.2.2 Especificação, Representação, Descrição ou Documentação? ................................ 38 3.2.3 Interfaces ................................................................................................................. 38 3.2.4 Módulos versus Componentes ................................................................................. 38

3.3 Usos da Documentação Arquitetural .............................................................................. 40 3.4 Visões Arquiteturais ....................................................................................................... 43

3.4.1 Conceito de Visão Arquitetural ............................................................................... 45 3.4.2 Tipos de Visões e Estilos Arquiteturais ................................................................... 45 3.4.3 Tipo de Visão Módulos ........................................................................................... 47 3.4.4 Tipo de Visão Componente-e-Conector (C&C) ...................................................... 48 3.4.5 Tipo de Visão Alocação .......................................................................................... 50

3.5 Considerações ................................................................................................................. 50 4 – Linguagens de Descrição de Arquiteturas .......................................................................... 53

4.1 Introdução ....................................................................................................................... 53 4.2 Principais ADLs ............................................................................................................. 54 4.3 Conceito .......................................................................................................................... 54 4.4 Características de ADLs ................................................................................................. 55 4.5 Um Framework Conceitual para ADLs .......................................................................... 56

4.5.1 Modelagem dos Componentes................................................................................. 58 4.5.2 Modelagem dos Conectores..................................................................................... 59 4.5.3 Modelagem das Configurações Arquiteturais ......................................................... 60 4.5.4 Ferramentas de Suporte para Descrição Arquitetural .............................................. 62

4.6 Considerações ................................................................................................................. 63 5 – Desenvolvimento de Software Orientado a Aspectos ........................................................ 65

5.1 Introdução ....................................................................................................................... 65 5.2 Programação Orientada a Aspectos ................................................................................ 65 5.3 Abordagens de Arquitetura de Software Orientada a Aspectos ..................................... 68

5.3.1 Abordagens para Modelagem Arquitetural ............................................................. 68

xiv

5.3.2 Abordagens para o Processo de Design Arquitetural .............................................. 69 5.3.3 Abordagens para Avaliação Arquitetural ................................................................ 71

5.4 Uma Análise de Abordagens de Aspectos Preliminares ................................................ 73 5.5 ADLs Orientadas a Aspectos ......................................................................................... 74

5.5.1 A Abordagem de Navasa et al. (2002) .................................................................... 74 5.5.2 DAOP-ADL ............................................................................................................ 75 5.5.3 Fractal...................................................................................................................... 76 5.5.4 PRISMA .................................................................................................................. 76 5.5.5 AspectualACME ..................................................................................................... 76 5.5.6 Questões sobre Aspectos e Conexão Arquitetural .................................................. 76 5.5.7 Observações ............................................................................................................ 79

5.6 Considerações ................................................................................................................ 81 6 – Características Desejáveis em uma ADL-OA .................................................................... 83

6.1 Introdução ...................................................................................................................... 83 6.2 Diretrizes Norteadoras ................................................................................................... 84 6.3 Interdependência das Diretrizes ..................................................................................... 97 6.4 Desiderata: características desejáveis em uma ADL-OA .............................................. 97

6.4.1 – Características Relacionadas à Notação de Design Arquitetural ......................... 99 6.4.2 – Características Relacionadas ao Método de Design Arquitetural ...................... 105 6.4.3 – Características Relacionadas às Ferramentas de Apoio ..................................... 109

6.5 Relações entre Diretrizes e Características .................................................................. 111 6.6 Proposta de Notação Visual e Formalismo para uma ADL-OA .................................. 115

6.6.1 Notação Gráfica .................................................................................................... 117 6.6.2 Formalismo Subjacente ......................................................................................... 120

6.7 Considerações .............................................................................................................. 121 7 – Modelagem Arquitetural do DiSEN: Um exemplo de utilização de uma ADL-OA ........ 123

7.1 Introdução .................................................................................................................... 123 7.2 O DiSEN: Visão Geral ................................................................................................. 123 7.3 Requisitos Relevantes para um ADDS ........................................................................ 124 7.4 Abordagem Arquitetural .............................................................................................. 126 7.5 Representação Arquitetural do DiSEN ........................................................................ 128

7.5.1 Uma Abordagem Arquitetural Convencional (não-OA) ....................................... 128 7.5.2 Uma Abordagem Arquitetural Orientada a Aspectos ........................................... 131

7.6 Considerações .............................................................................................................. 136 8 – Conclusões e Trabalhos Futuros ...................................................................................... 137

8.1 Conclusões ................................................................................................................... 137 8.2 Trabalhos futuros ......................................................................................................... 139

Referências ............................................................................................................................. 141 Anexo 1 – Resultados da Comparação de ADLs de (MEDVIDOVIC; TAYLOR, 2000) .... 151 Anexo 2 – Resultados do survey de (CLEMENTS, 1996) .................................................... 157 Anexo 3 – Caracterização de Abordagens de Aspectos Preliminares ................................... 161

15

1 – Introdução

1.1 Motivação

As aplicações utilizadas atualmente requerem um alto grau de interação entre os

computadores e as pessoas, principalmente em virtude das atividades inerentemente

colaborativas.

Apesar de as aplicações distribuídas oferecerem muitos benefícios potenciais, elas são

mais difíceis de serem projetadas, implementadas, otimizadas, e gerenciadas em comparação

com as aplicações centralizadas. Teoricamente, o desenvolvimento de aplicações distribuídas

(que usam serviços concorrentes e em rede) pode melhorar o desempenho, a confiabilidade, a

escalabilidade, e a efetividade do custo do sistema. Na prática, entretanto, é difícil o

desenvolvimento de aplicações distribuídas eficientes, robustas, extensíveis, e com a

requerida disponibilidade, devido a diferenças chaves entre as arquiteturas de aplicações

centralizadas (stand-alone) e as arquiteturas de aplicações em rede (SCHMIDT et al., 2000)

(COULOURIS; DOLLIMORE; KINDBERG, 2007) (TANENBAUM; STEEN, 2002).

O crescimento dos sistemas de software, em termos de tamanho e complexidade, faz

com que o problema de desenvolvimento extrapole o design das estruturas de dados e

algoritmos para o sistema. Ou seja, projetar a estrutura global de um sistema emerge como um

problema novo, qual seja, o desenvolvimento de software orientado para arquitetura.

Os sistemas distribuídos têm se multiplicado, principalmente em função do advento da

Web, e o desenvolvimento de tais sistemas é significativamente mais complexo, provocando

uma crescente necessidade de Linguagens de Descrição Arquitetural (ADLs – Architectural

Description Languages) para modelar as arquiteturas de software de tais sistemas.

Os métodos tradicionais de design arquitetural não fazem distinção explícita entre os

interesses arquiteturais convencionais e interesses arquiteturais que entrecortam múltiplos

componentes arquiteturais. Conseqüentemente, há um risco de que potenciais aspectos

possam ser facilmente negligenciados durante o design arquitetural e continuem não

solucionados em nível de design e programação.

Os sistemas de software atuais demandam que o foco do desenvolvimento migre de

uma visão puramente funcional, para uma que lide também com propriedades não funcionais.

Com a inclusão dessas propriedades não funcionais no desenvolvimento do software, as

preocupações do desenvolvedor alteram-se. Ele deixa de concentrar-se, exclusivamente, nas

características intrínsecas da aplicação para preocupar-se com as propriedades não funcionais

16

que o sistema deve satisfazer. Alguns exemplos de características não funcionais encontrados

freqüentemente na literatura compreendem (BOEHM; IN, 1996): tratamento de falhas,

persistência, comunicação, replicação, coordenação, gerenciamento de memória, restrições de

tempo-real e muitas outras questões relacionadas ao comportamento do sistema.

Incorporar requisitos não funcionais em qualquer tipo de software é uma das

atividades mais complexas. Além disso, esses requisitos dificultam o processo de

desenvolvimento, visto que podem gerar diversos problemas, tais como falta de transparência,

código não funcional disperso e/ou entrelaçado em vários componentes e, em decorrência,

prejudicam a reutilização e a manutenção desses componentes. Percebe-se que esses

problemas são oriundos da relação intrínseca que existe entre a funcionalidade e as

características não comportamentais.

A Programação Orientada a Aspectos (POA) (KICZALES et al., 1997) oferece apoio

para implementar de forma modular interesses espalhados por várias classes, tais como

segurança, sincronização e persistência. Apesar de que os aspectos foram, originalmente,

definidos apenas em nível de programação (KICZALES et al., 1997), o Desenvolvimento de

Software Orientado a Aspectos (DSOA) tenta cobrir todas as fases do ciclo de vida de

desenvolvimento de software, desde os requisitos à implementação (BAKKER;

TEKINERDOGAN; AKSIT, 2005). Portanto, é necessário definir notações e linguagens que

auxiliem os desenvolvedores de software a especificar e validar arquiteturas de software

baseadas em componentes e aspectos.

Semelhantemente à noção de aspecto em nível de programação, os interesses

transversais arquiteturais denotam os chamados aspectos arquiteturais. Uma vez que a

propriedade transversal dos aspectos arquiteturais é inerente, ela não pode simplesmente ser

desfeita por meio da redefinição da arquitetura de software usando-se abstrações arquiteturais

convencionais. Da mesma forma que para as várias abstrações de programação orientada a

aspectos, é necessário explicitar novos mecanismos para identificar, especificar e avaliar

aspectos no nível de design arquitetural. Neste sentido, as abordagens de design arquitetural

orientadas a aspectos descrevem passos para a identificação de aspectos arquiteturais e seus

componentes entrelaçados. Esta informação é usada para re-projetar a arquitetura na qual os

aspectos arquiteturais são explicitados (CHITCHYAN et al., 2005).

A emergência da Engenharia de Software Baseada em Componentes (CBSE)

(SZYPERSKI, 1998) impõe uma nova forma de desenvolvimento de aplicações por meio da

17

conexão em componentes de software stand-alone, ao invés de desenvolvê-las a partir do

zero.

Comumente, pode ocorrer de um mesmo interesse estar espalhado em diferentes

componentes, criando dependências indesejáveis entre eles. Estas dependências tornam difícil

a decomposição funcional de um sistema em componentes autônomos. Deste modo, a

separação avançada de interesses é amplamente aceita como a abordagem mais adequada para

solucionar este problema, estendendo a CBSE com novas dimensões de interesses, a qual vai

além dos “objetos” ou “componentes”.

O DSOA baseia-se no princípio de separação de interesses, e introduz uma nova

abstração (dimensão), denominada aspecto, que modela esses interesses que apresentam-se

nos múltiplos componentes em um sistema que pode se modificar ou evoluir

independentemente, resultando em sistemas menos acoplados. Conseqüentemente, as técnicas

proporcionadas pela DSOA podem ser aplicadas com sucesso no contexto da CBSE,

aprimorando a modularidade e, em conseqüência, a reusabilidade e evolução das aplicações.

Não obstante muitas das dificuldades enfrentadas pelos desenvolvedores possam ser

atenuadas por meio de técnicas e métodos consolidados de engenharia de software, a

crescente complexidade no desenvolvimento de software (decorrente principalmente de

características tais como concorrência, distribuição, heterogeneidade, dinamismo, e

mobilidade) requer novas tecnologias que venham apoiar o desenvolvedor. No contexto do

desenvolvimento de software orientado a arquitetura, as ADLs convencionais não apresentam

as abstrações necessárias para que os interesses arquiteturais transversais possam ser

modularizados. Neste sentido, este presente trabalho se preocupa em investigar quais são as

características essenciais que uma ADL Orientada a Aspecto deve apresentar para que o

arquiteto de software possa modelar, com eficácia, os interesses arquiteturais transversais.

As ADLs lidam com a descrição, análise e o reuso de arquiteturas de software

(MEDVIDOVIC; TAYLOR, 2000). As ADLs descrevem a estrutura do sistema, a qual

compreende os componentes de software, as propriedades externamente visíveis desses

componentes, e os relacionamentos entre eles. Qualquer adaptação de ADLs existentes, ou a

engenharia de novas ADLs, deve estar baseada em uma clara compreensão dos novos desafios

que os aspectos impõem em nível arquitetural, mas que não podem ser manipulados com as

abstrações de ADL existentes. Quando do design de uma ADL-OA, algumas questões

surgem, e tais questões devem ser respondidas a fim de embasar o design dessa nova ADL.

18

1.2 Objetivos

O objetivo geral deste trabalho consiste em definir um conjunto de características (ou

propriedades) desejáveis em uma ADL-OA.

Como objetivos específicos, tem-se:

• Elaborar uma lista de diretrizes norteadoras para a definição de um conjunto de

características (ou propriedades) desejáveis em uma ADL-OA.

• Propor uma notação gráfica para uma ADL-OA.

• Realizar um experimento representando a arquitetura do DiSEN com base na notação

gráfica proposta.

1.3 Metodologia da Pesquisa

Conforme ilustra a Figura 1.1, com base nas investigações realizadas em tópicos como

Sistemas Distribuídos, Arquitetura de Software, ADLs convencionais, ADLs-OA disponíveis,

e DSOA, é levantada uma coleção de características consideradas essenciais a uma ADL-OA.

Figura 1.1 – Metodologia empregada na elaboração deste trabalho

Com base nos estudos realizados, foi definida uma série de “diretrizes norteadoras ao

estabelecimento das características essenciais a uma ADL-OA” (Seção 6.2). Tais diretrizes,

derivadas a partir da literatura na área de engenharia de software, são enunciadas visando

embasar um elenco de “características desejáveis em uma ADL-OA” – de modo que tal ADL

seja capaz de apoiar sistemática e solidamente o desenvolvimento de sistemas de software

orientado à arquitetura1. Essa coleção de características compreende as propriedades

(capacidades e recursos de modelagem) que uma ADL-AO deve apresentar, adicionalmente

1 É válido ressaltar que importantes metodologias de desenvolvimento de software são orientadas à arquitetura (ex.: RUP).

Conceitos de Sistemas

Distribuídos

Framework de ADLs

Conceitos de DSOA

Diretrizes norteadoras

Características Desejáveis

Proposta de Notação Gráfica

Conceitos de Arquitetura de

Software

ADLs-OA disponíveis

Experimento envolvendo o

DiSEN

19

àquelas enunciadas no framework de ADLs proposto por Medvidovic e Taylor (2000), de

modo que seja possível modelar eficazmente os interesses arquiteturais transversais e suas

interações com os demais elementos da arquitetura do sistema de software.

Uma proposta de notação gráfica para uma ADL-OA é apresentada neste trabalho. Por

fim, foi realizado um experimento envolvendo o DiSEN (Distributed Software Engineering

Environment), e o resultado alcançado encontra-se descrito neste trabalho. Neste sentido, a

arquitetura do DiSEN foi modelada com base na notação gráfica proposta, com o objetivo de

realizar experimento e constatar os benefícios oferecidos por uma ADL-OA que apresenta as

características elencadas.

Evidencia-se, pelo esquema apresentado na Figura 1.1, que a metodologia empregada

neste trabalho distingue-se daquelas utilizadas em trabalhos relacionados, tais como

(NAVASA et al., 2005), (PINTO; FUENTES; TROYA, 2003), (PEREZ et al., 2003),

(PESSEMIER; SEINTURIER; DUCHIEN, 2004), (BATISTA et al., 2006-a). Neste presente

trabalho, realizou-se uma abordagem top-down, partindo dos princípios fundamentais da

engenharia de software até chegar aos conceitos básicos do DSOA, provenientes da POA.

Diferentemente, os trabalhos supracitados partem dos conceitos da POA para alcançar o nível

de arquitetura de software, em uma abordagem claramente botton-up.

A abordagem top-down deu condições para que a proposta de uma ADL-OA fosse

fundamentalmente respaldada em sólidos princípios de engenharia de software, em particular

os da área de arquitetura de software, sem abrir mão das necessidades que o paradigma

orientado a aspectos impõe.

1.4 Estrutura da Dissertação

No Capítulo 2 é abordado o tópico de Sistemas Distribuídos: apresenta os principais

conceitos relacionados; cita e explica, separadamente, cada um dos requisitos de sistemas

distribuídos; e expõe os principais desafios encontrados no design de tais sistemas.

No Capítulo 3 é coberta a disciplina de Arquitetura de Software: os principais

conceitos associados; as principais finalidades de uma documentação arquitetural; e um

conteúdo abrangente sobre visões arquiteturais.

No Capítulo 4 é enfocado, especificamente, as Linguagens de Descrição de

Arquiteturas (ADLs): introduz-se conceitos relevantes acerca de ADLs; são descritas as

características de ADLs apresentadas pelos principais pesquisadores da área; apresenta-se o

clássico framework conceitual sobre ADLs proposto por Medvidovic e Taylor (2000); e é

20

mostrada a metodologia e a estrutura de um importante survey sobre ADLs realizado por

Clements (1996).

No Capítulo 5 é apresentada a emergente disciplina denominada Desenvolvimento de

Software Orientado a Aspectos (DSOA): faz-se uma breve introdução sobre a Programação

Orientada a Aspectos (POA); são apresentas as principais abordagens arquiteturais orientadas

a aspectos; é exposta uma análise das principais abordagens de aspectos preliminares; e são

descritas as principais ADLs Orientadas a Aspectos encontradas na literatura.

O Capítulo 6 desenvolve-se apresentando um conjunto de diretrizes norteadoras ao

estabelecimento das características essenciais a uma ADL-OA. Tais diretrizes são enunciadas

visando embasar a lista de características desejáveis em uma ADL-OA para o domínio de

sistemas distribuídos. É apresentada uma tabela sintetizando uma comparação das ADLs-OA

disponíveis em relação ao elenco das características consideradas essenciais. Por fim,

apresenta-se uma proposta de notação gráfica para uma ADL-OA; também é apontada uma

notação matemática com prováveis condições de servir como base ao formalismo subjacente

adequado para a modelagem estrutural e comportamental de arquiteturas de sistemas de

software distribuídos.

No Capítulo 7 são mostrados os resultados de um Experimento realizado com base no

DiSEN (Distributed Software Engineering Environment), um Ambiente Distribuído de

Desenvolvimento de Software (ADDS). A arquitetura do DiSEN é apresentada a partir de

uma abordagem convencional (não orientada a aspectos) e, na seqüência, a arquitetura do

mesmo sistema é representada com base nos conceitos do DSOA, utilizando a notação gráfica

de uma ADL-OA proposta no Capítulo 6.

As Conclusões e os Trabalhos Futuros estão contidos no Capítulo 8.

21

2 – Sistemas Distribuídos

2.1 Introdução Durante a década de 1990, os avanços na tecnologia VLSI (Very Large Scale

Integration) e nas fibras ópticas incrementaram o poder de processamento dos computadores

em 3 ou 4 ordens de magnitude e as velocidades das conexões de rede em 6 ou 7 ordens de

magnitude (SCHMIDT, et al., 2000). Supondo que essa tendência continue, esses autores

afirmam ainda que, até 2010, serão verificadas as seguintes velocidades: clocks dos

computadores ~ 100 Gigahertz; links de redes locais ~ 100 Gigabits/segundo; links de redes

sem fio ~ 100 Megabits/segundo; links de backbone da Internet ~ 10 Terabits/segundo.

Conseqüentemente, para maximizar os benefícios dos avanços em tecnologia de

hardware, a qualidade e a produtividade de tecnologias para desenvolvimento de middlewares

e aplicações de softwares concorrentes e conectados em rede também devem aumentar.

As principais características dos sistemas distribuídos são: concorrência;

compartilhamento de recursos; abertura; transparência; estado compartilhado; independência

de escala; e tolerância a falhas (TANENBAUM; STEEN, 2002) (EMMERICH, 2001).

Segundo Schmidt et al. (2000), há três razões gerais para se adotar uma arquitetura

distribuída: colaboração e conectividade; desempenho, escalabilidade, e tolerância a falhas

melhorada; e efetividade do custo.

O restante deste capítulo encontra-se organizado como segue. Na Seção 2.2 estão

expostos os principais conceitos relacionados aos sistemas distribuídos. Na Seção 2.3 explica-

se, separadamente, cada um dos requisitos de sistemas distribuídos. Na Seção 2.4 são

apresentados os principais desafios encontrados no design de sistemas distribuídos. Algumas

considerações sobre o conteúdo deste capítulo estão expostas na Seção 2.5.

2.2 Conceito

Na literatura corrente, encontram-se várias definições sobre sistemas distribuídos, cada

qual refletindo pontos de vista particulares de seus autores, nem sempre consensuais. Em

(TANENBAUM, 2003), encontramos que:

“Em um sistema distribuído, um conjunto de computadores independentes parece ser,

para seus usuários, um sistema único e coerente. Em geral, ele tem um único modelo

ou paradigma que se apresenta aos usuários. Com freqüência, uma camada de software

sobre o sistema operacional, chamada middleware, é responsável pela implementação

desse modelo”.

22

Intuitivamente, um sistema distribuído terá componentes que são distribuídos em

vários computadores. Um computador que hospeda os componentes, incluindo hardware e seu

software de sistema operacional (SO) de rede, de um sistema distribuído é referenciado como

um host (EMMERICH, 2000). A Figura 2.1 transmite esta idéia.

Componente 1 . . . Componente n

Sistema Operacional de Rede

Hardware Host

Figura 2.1 – Host em um Sistema Distribuído – Fonte: Adaptado de (EMMERICH, 2000, p. 5)

Um sistema distribuído tem mais do que um componente em mais do que um host.

Estes componentes necessitam interagir um com o outro: eles necessitam fornecer acesso aos

serviços um do outro e devem estar aptos a solicitar serviços um do outro. Teoricamente, os

componentes poderiam fazer isso diretamente por meio do uso das primitivas que os SOs de

rede fornecem. Na prática, conforme Emmerich (2000), isto seria muito complexo para muitas

aplicações. Como mostrado na Figura 2.2, os sistemas distribuídos, usualmente, empregam

alguma forma de middleware, o qual consiste em uma camada de software posicionada

logicamente entre os SOs de rede e as aplicações, e cujo objetivo principal é resolver a

heterogeneidade e a distribuição (vide Seção 2.3).

Componente 1 . . . Componente n

Middleware


Hardware Host1

Figura 2.2 – Middleware em um Sistema Distribuído – Fonte: Adaptado de (EMMERICH, 2000, p. 5)

Em sua obra, Emmerich (2000) culmina com a seguinte conceituação, conforme está

ilustrado na Figura 2.3:

“Um sistema distribuído é uma coleção de hosts autônomos que estão conectados ao

longo de uma rede de computadores. Cada host executa componentes e opera um

middleware de distribuição, o qual possibilita aos componentes coordenarem suas

atividades de forma tal que os usuários percebam o sistema como um recurso de

computação único e integrado”.

23

Figura 2.3 – Visão de funcionamento de um Sistema Distribuído – Fonte: Adaptado de (EMMERICH, 2000, p. 6)

Coulouris, Dollimore, e Kindberg (2007) definem um sistema distribuído como segue:

“Um sistema distribuído é aquele no qual os componentes de hardware ou software,

localizados em computadores interligados em rede, se comunicam e coordenam suas

ações apenas enviando mensagens entre si”.

Segundo Coulouris, Dollimore, e Kindberg (2007), os desafios advindos da construção

de sistemas distribuídos são: (a) heterogeneidade de seus componentes; (b) abertura do

sistema; (c) segurança; (d) escalabilidade; (e) tratamento de falhas; (f) concorrência de

componentes; e (g) transparência. (Vide Seção 2.3).

A interligação dos computadores em rede, distribuída de maneira útil, traz à tona as

seguintes conseqüências (COULOURIS; DOLLIMORE, KINDBERG, 2007):

• Concorrência: Em uma rede de computadores, a execução concorrente de programas é a

norma. A coordenação de programas em execução concorrente e que compartilham

recursos é um assunto importante e recorrente.

• Inexistência de relógio global: Quando os programas precisam cooperar entre si, eles

coordenam suas ações trocando mensagens, o que freqüentemente depende de uma noção

compartilhada do tempo em que as ações dos programas ocorrem. Entretanto, não existe

uma noção global única do tempo correto. Essa é uma conseqüência direta do fato de que

a comunicação se dá por meio do envio de mensagens em uma rede.

• Falhas independentes: Falhas na rede resultam no isolamento dos computadores que estão

conectados a ela, o que não significa que eles param de funcionar. Na verdade, os

Componente1 . . . Componenten

Middleware


Hardware

Host2


Middleware


Hardware

Host1


Middleware


Hardware

Hostn


Middleware


Hardware

Hostn-1

Rede

24

programas neles existentes talvez não consigam detectar se a rede falhou ou tornou-se

demasiadamente lenta. Analogamente, a falha de um computador ou o término inesperado

de um programa em algum lugar no sistema (um colapso no sistema) não é imediatamente

percebida pelos outros componentes, deixando os outros ainda em funcionamento.

Tanenbaum e Steen (2002) evidenciam que, para apoiar computadores heterogêneos e

redes heterogêneas e, ao mesmo tempo, oferecer uma visão uniforme do sistema, os sistemas

distribuídos normalmente são organizados por meio de uma camada de software que está

logicamente localizada entre uma camada de nível mais alto consistindo de usuários e

aplicações, e de uma camada inferior consistindo de SOs. Na perspectiva desses autores, tais

sistemas distribuídos são normalmente chamados de middleware, como mostrado na Figura

2.4 (é possível observar que a camada de middleware estende-se por múltiplas máquinas).

Figura 2.4 – Sistema Distribuído organizado como Middleware –

Fonte: Adaptado de (TANENBAUM; STEEN, 2002, p. 3)

A maioria dos autores cita como exemplos típicos de sistemas distribuídos: a Web,

uma intranet (que é uma parte de Internet gerenciada por uma organização), e a computação

móvel e ubíqua (WEISER, 1993).

Ponderando tudo o que foi posto acima, é possível afirmar que um sistema distribuído

consiste em um conjunto de computadores autônomos conectados em rede; cada computador

executa componente(s) de software e opera sobre um middleware, o qual possibilita aos

componentes coordenarem suas atividades de maneira tal que os usuários tenham a

impressão de ser um sistema único integrado.

Em termos de hardware, os sistemas distribuídos possuem pelo menos uma

característica comum: consistem de múltiplas CPUs. Porém, o hardware pode ser organizado

de diferentes formas, especialmente no tocante ao modo como eles estão interconectados e

Rede

Host 1 . . . Host 2 Host N

SO Local SO Local SO Local

Serviços do Middleware

Aplicações Distribuídas

25

como se comunicam. Para os propósitos deste trabalho devem ser considerados os sistemas

construídos a partir de um conjunto de computadores independentes.

Na verdade, é a arquitetura do software que realmente determina aquilo que de fato é

um sistema distribuído. Tanenbaum e Steen (2002) sustentam que os sistemas distribuídos

agem, muitas vezes, como “gerenciadores de recursos para o hardware subjacente, tentando

ocultar suas complexidades e sua natureza heterogênea por intermédio de uma máquina

virtual sobre a qual as aplicações podem ser facilmente executadas”.

Em (TANENBAUM; STEEN, 2002) os SOs são classificados como: a) sistemas

fortemente acoplados, que tentam manter uma visão única e global dos recursos gerenciados

(SO distribuído, usado para o gerenciamento de sistemas multiprocessados e

multicomputadores homogêneos); e b) sistemas fracamente acoplados, considerados como

um conjunto de computadores, cada qual executando seu SO (SO de rede, usado para sistemas

multicomputadores heterogêneos).

Middleware

Schmidt et al. (2000) conceituam um middleware com sendo o conjunto de serviços,

protocolos, e utilitários de suporte que proporcionam a infra-estrutura que torna possível a

execução dos sistemas e aplicações distribuídas – a infra-estrutura sobre a qual se baseiam os

web services, objetos distribuídos, aplicações colaborativas, sistemas de e-commerce, e outras

plataformas importantes (Figura 2.5).

Figura 2.5 – Estrutura Genérica de um Sistema Distribuído como um

Middleware – Fonte: Adaptado de (TANENBAUM; STEEN, 2002, p. 37)

Convencionalmente, o middleware consiste do software necessário para se construir

sistemas e aplicações, ainda que não seja, contudo, uma parte intrínseca do kernel de um SO.

O middleware pode aparecer em bibliotecas e frameworks, SOs e seus adicionais, máquinas

Rede

Host 1

Kernel SO

.... Host 2 Host N

Serviços SO de Rede

Aplicações Distribuídas

Kernel SO


Kernel SO


Serviços do Middleware

26

virtuais Java e outros sistemas em tempo de execução, componentes de software de alta

granularidade, e em partes de produtos finais tais como os próprios web services.

Um middleware incorpora idéias básicas por trás de muitos padrões de software e,

normalmente, são variações de padrões OO (orientados a objetos) mais genéricos (ex.:

proxies, adaptadores, e facades) (LEA; ALEXANDER, 1994). Os desenvolvedores de

middlewares podem resolver uma ampla faixa de forças incluindo desempenho,

confiabilidade, interoperabilidade, portabilidade e acomodação de softwares legados

(SCHMIDT et al., 2000).

Segundo Coulouris, Dollimore e Kindberg (2007), o termo middleware refere-se a

“uma camada de software que fornece uma abstração de programação, assim como o

mascaramento da heterogeneidade das redes, do hardware, de SOs e linguagens de

programação (LPs) subjacentes”. Podem ser citados como exemplos o CORBA (Common

Object Request Broker Architecture) e o Java RMI (Remote Method Invocation). Todo

middleware, em si, trata das diferenças em nível dos SOs e do hardware.

Além de resolver o problema da heterogeneidade, o middleware “fornece um modelo

computacional uniforme para ser usado pelos programadores de serviços e de aplicativos

distribuídos” e “sua implementação oculta o fato de que as mensagens passam por uma rede

para enviar o pedido de invocação e sua resposta” (COULOURIS; DOLLIMORE,

KINDBERG, 2007). Possíveis modelos incluem notificação remota de eventos, acesso remoto

a banco de dados, processamento de transações distribuídas, e invocação remota de objetos.

2.3 Requisitos de Sistemas Distribuídos

Um requisito funcional corresponde a uma declaração de alguma função ou

característica que deve ser implementada em um sistema. Diferentemente, um requisito não-

funcional refere-se a uma declaração de uma restrição ou comportamento esperado que se

aplica a um sistema – essa restrição pode corresponder às propriedades emergentes do

software sendo desenvolvido ou ao processo de desenvolvimento (SOMMERVILLE, 2007)

A necessidade de distribuir um sistema é normalmente derivada de requisitos não

funcionais. O design de um sistema distribuído tem sua complexidade incrementada devido à

presença de alguns desafios, como os listados a seguir: heterogeneidade, abertura,

escalabilidade, tratamento de falhas, concorrência e transparência (COULOURIS;

DOLLIMORE, KINDBERG, 2007) (EMMERICH, 2000) (TANENBAUM; STEEN, 2002).

27

• Heterogeneidade

A heterogeneidade de componentes surge a partir do uso de tecnologias diferentes para

a implementação de serviços, para o gerenciamento de dados e para a execução de

componentes em diferentes plataformas de hardware; o conceito de heterogeneidade aplica-se

aos seguintes aspectos: redes, hardware de computador, SOs, LPs, implementações de

diferentes desenvolvedores. A menos que se utilizem padrões comuns, programas escritos por

diferentes desenvolvedores não podem se comunicar.

• Abertura do Sistema

Coulouris, Dollimore e Kindberg (2007) enfatizam que “um sistema computacional é

aberto quando ele pode ser estendido e reimplementado de várias maneiras”, e que “o fato de

um sistema distribuído ser ou não um sistema aberto é determinado, principalmente, pelo grau

com que novos serviços podem ser adicionados e disponibilizados para uso por uma variedade

de programas clientes”. Essa característica, a de sistema aberto, pode ser alcançada por meio

da publicação das interfaces (EMMERICH, 2000).

• Segurança

A segurança de recursos de informação compõe-se da seguinte tríade:

confidencialidade (proteção contra exposição a pessoas não autorizadas), integridade

(proteção contra alteração ou dano) e disponibilidade (proteção contra interferência nos meios

de acesso aos recursos). Tais desafios são solucionados com o uso de técnicas de criptografia.

Entretanto, alguns desafios ainda não foram totalmente resolvidos, a saber: ataque de negação

de serviço; e segurança de código móvel (COULOURIS; DOLLIMORE, KINDBERG, 2007).

• Escalabilidade

Segundo Emmerich (2000), a escalabilidade “denota a capacidade de acomodar uma

crescente carga no futuro”. Um sistema é considerado escalável se permanecer eficiente

mesmo quando houver um aumento significativo no número de recursos e de usuários.

O design de sistemas escaláveis apresenta desafios como: controlar o custo dos

recursos físicos, controlar a perda de desempenho, impedir que os recursos de software se

esgotem, e evitar gargalos de desempenho. Um difícil objetivo almejado é que o software de

sistema e de aplicativo não tenha que ser modificado quando a escala do sistema aumentar. As

técnicas que têm obtido sucesso na solução dos problemas de escalabilidade incluem: dados

replicados, a técnica associada com o uso de cache, e a distribuição de vários servidores para

manipular as tarefas comumente executadas, permitindo que várias tarefas semelhantes sejam

executadas concorrentemente (COULOURIS; DOLLIMORE, KINDBERG, 2007).

28

• Tratamento de falhas

Quando um dos componentes de um sistema distribuído falha, apenas o trabalho que

estava usando o componente defeituoso é afetado. Conforme (EMMERICH, 2000), “uma

operação que continua mesmo na presença de falhas é dita como tolerante à falha”. Em um

sistema distribuído alguns componentes falham enquanto outros continuam funcionando

(falhas parciais), o que torna o tratamento de falhas uma atividade particularmente difícil.

As principais técnicas para tratamento de falhas encontradas na literatura são: detecção

de falhas; mascaramento de falhas; tolerância a falhas; recuperação de falhas; e redundância.

Os sistemas distribuídos tendem a ter alto grau de disponibilidade perante falhas de hardware.

• Concorrência

Existe a possibilidade de que vários clientes tentem acessar um recurso compartilhado

(hardware, software, dados) ao mesmo tempo. A estratégia de fazer com que o processo que

gerencia um recurso compartilhado aceite e trate um pedido de cliente por vez limita o

desempenho do tratamento de pedidos. Conseqüentemente, os serviços e aplicativos

geralmente permitem que vários pedidos de cliente sejam processados concorrentemente.

Assim, qualquer objeto que represente um recurso compartilhado em um sistema

distribuído deve ser responsável por garantir que ele opere corretamente em um ambiente no

qual a concorrência se faz presente. Isso se aplica não apenas aos servidores, mas também aos

objetos nos aplicativos (COULOURIS; DOLLIMORE, KINDBERG, 2007). As operações de

um objeto devem ser sincronizadas de tal maneira que seus dados permaneçam consistentes, o

que pode ser obtido por técnicas padrão (ex.: semáforos), disponíveis na maioria dos SOs.

• Transparência

O fato de o sistema ser composto de múltiplos componentes deve estar oculto aos

usuários. Conforme (EMMERICH, 2000), “determinado aspecto de distribuição é dito

transparente se ele não for visível aos usuários, aos programadores ou aos administradores”.

Coulouris, Dollimore e Kindberg (2007) definem a transparência como sendo “a

ocultação, para um usuário final ou para um programador de aplicativos, da separação dos

componentes em um sistema distribuído de modo que o sistema seja percebido como um todo,

em vez de uma coleção de componentes independentes”.

As diversas dimensões de transparências foram inicialmente identificadas no ANSA2

Reference Manual (ANSA, 1989 apud COULOURIS; DOLLIMORE, KINDBERG, 2007) e

fazem parte do Padrão Internacional sobre Processamento Distribuído Aberto (International

2 Advanced Network Systems Architecture

29

Standard on Open Distributed Processing – ODP) (ISO/IEC, 1996 apud EMMERICH, 2000).

A Figura 2.6 sugere que há diferentes níveis de transparência. Os critérios de transparência de

níveis inferiores dão suporte ao alcance de critérios nos níveis superiores.

Figura 2.6 – Dimensões de Transparências – Fonte: Adaptado de (EMMERICH, 2000, p. 19)

As formas de transparência do ANSA Reference Manual estão parafraseadas a seguir:

• Transparência de acesso: recursos locais e remotos acessados com o uso de operações

distribuídas; as interfaces para a comunicação local e a remota são as mesmas.

• Transparência de localização: recursos acessados sem o conhecimento de sua localização

física ou na rede.

• Transparência de concorrência: vários processos operando concorrentemente, usando

recursos compartilhados sem interferência entre eles.

• Transparência de replicação: várias instâncias dos recursos são usadas para aumentar a

confiabilidade e o desempenho, sem conhecimento das réplicas por parte dos usuários ou

dos programadores de aplicativos; uma réplica é uma cópia de componente que

permanece sincronizada com seu original.

• Transparência de mobilidade: movimentação de recursos e clientes dentro de um sistema,

sem afetar a operação de usuários ou programas.

• Transparência de falhas: ocultação de falhas, possibilitando que usuários e programas

concluam suas tarefas, a despeito de falhas de componentes de hardware ou software.

• Transparência de desempenho: re-configuração do sistema para melhorar o desempenho à

medida que as cargas variam.

• Transparência de escalabilidade: expansão em escala do sistema e dos aplicativos, sem

alterar a estrutura do sistema ou os algoritmos de aplicativos.

Conforme o ANSA Reference Manual, as transparências mais importantes são a de

acesso e de localização, pois sua presença ou ausência afetam mais fortemente a utilização de

recursos distribuídos; na literatura, são referidas, conjuntamente, como transparência de rede.

Transparência de Escalabilidade

Transparência de Desempenho

Transparência de Falhas

Transparência de Mobilidade

Transparência de Replicação

Transparência de Concorrência

Transparência de Acesso

Transparência de Localização

30

2.4 Desafios Encontrados no Design de Sistemas Distribuídos

Apesar de as aplicações distribuídas oferecerem muitos benefícios potenciais, elas são

mais difíceis de serem projetadas, implementadas, otimizadas e gerenciadas do que as

aplicações centralizadas. Além disso, afirmam Schmidt et al. (2000) que no contexto destes

tópicos muitos desafios de design e de programação surgem devido a várias complexidades

inerentes e acidentais associadas com sistemas concorrentes e em rede.

As complexidades inerentes comuns associadas com sistemas distribuídos incluem: (a)

gerenciamento de largura de banda; (b) minimização de atrasos (latência) e variação de atraso;

(c) detecção e recuperação de falhas parciais; (d) determinação do particionamento adequado

de serviços e estratégias para balanceamento de carga; e (e) garantia de ordenação causal de

eventos (SCHMIDT et al., 2000).

As complexidades acidentais associadas com sistemas distribuídos incluem: (a) falta

de APIs (Application Programming Interfaces) portáveis do SO; (b) suporte inadequado à

depuração e falta de ferramentas para análise de aplicações concorrentes em rede; (c) uso

difundido de decomposição algorítmica (ao invés de decomposição orientada a objetos); (d) e

re-descoberta e re-invenção contínua de conceitos core e componentes comuns.

2.4.1 Desafio: Acesso e Configuração de Serviços

Os componentes em uma aplicação centralizada podem colaborar em um único espaço

de endereçamento por meio de passagem de parâmetros através de chamadas de funções e por

meio de acesso a variáveis globais. Em contraste, conforme (SCHMIDT et al., 2000), os

componentes em aplicações distribuídas podem colaborar usando: Mecanismo de

comunicação inter-processo (IPC); Protocolos de comunicação; Operações remotas em

componentes de serviços em nível de aplicação usando middleware de comunicação de alto

nível, tais como COM+ e CORBA.

As aplicações e os componentes de software podem acessar estes mecanismos de

comunicação via APIs definidas em todos os níveis de abstração em um sistema conectado

em rede, conforme mostra a Figura 2.7.

31

Figura 2.7 – Mecanismos de Comunicação via APIs em Sistemas Distribuídos – Fonte: Adaptado de

(SCHMIDT et al., 2000, p. 9)

O suporte à evolução estática e dinâmica de serviços e aplicações é outro desafio em

sistemas de software distribuídos. A evolução pode ocorrer de duas formas:

• As interfaces e a conectividade entre papéis de serviços de componentes podem se alterar

em tempo de execução, e novos papéis podem ser instalados nos componentes existentes.

• O desempenho de sistemas distribuídos pode ser melhorado por meio da re-configuração

da carga dos serviços para aproveitar o poder de processamento de múltiplos hosts.

Um desafio de design é garantir que um sistema inteiro não necessite ser desativado,

re-compilado, re-ligado, e reiniciado simplesmente porque um determinado serviço em um

componente é re-configurado ou sua carga é re-distribuída.

Em (SCHMIDT et al., 2000) encontram-se alguns padrões para o design de APIs de

programação efetivas para acessar e configurar serviços e componentes em sistemas de

software e aplicações centralizadas e distribuídas: Wrapper Facade, Component

Configurator, Interceptor, e Extension Interface.

2.4.2 Desafio: Tratamento de Falhas

À medida que os sistemas se tornam cada vez mais distribuídos, as técnicas de

desenvolvimento de software que dão suporte às aplicações orientadas a eventos têm se

tornado cada vez mais pervasivas, de modo que tais aplicações são estruturadas com

arquiteturas em camadas com “inversão de controle”, conforme mostra a Figura 2.8.

pedido de operação

argumentos de entrada

argumentos de saída + valor de retorno

Rede

Cliente Serviço Camada de Aplicação

Kernel e Protocolos do SO Camada do SO

API

Kernel e Protocolos do SO

API

Middleware

API API

API

Camada do Middleware

32

Figura 2.8 – Aplicações Orientadas a Eventos estruturadas em camadas –

Fonte: Adaptado de (SCHMIDT et al., 2000, p. 14)

Na camada da base estão as fontes de eventos, as quais detectam e recuperam eventos

de vários dispositivos de hardware ou drivers de dispositivos de software de baixo nível que

residem dentro de SO. Na próxima camada está o demultiplexador de eventos, o qual usa

funções para aguardar por eventos que chegam das várias fontes e então despacha eventos

callbacks para seus manipuladores de eventos correspondentes. Os manipuladores de eventos,

juntos com o código da aplicação, formam outra camada que executa processamento

específico da aplicação em resposta aos callbacks – vem daqui a expressão “inversão de

controle”.

O trabalho de Schmidt et al. (2000), apresenta padrões que descrevem como iniciar,

receber, demultiplexar, despachar, e processar vários tipos de eventos efetivamente em

frameworks de software conectados em rede, quais sejam: Reactor, Proactor, Asynchronous

Completion Token, e Acceptor-Connector.

2.4.3 Desafio: Concorrência

O termo concorrência refere-se a uma família de políticas e mecanismos que

possibilitam a um ou mais processos, ou threads, executarem suas tarefas de processamento

de serviço simultaneamente (SCHMIDT et al., 2000).

Conforme definido em (SCHMIDT et al., 2000), um processo é “uma coleção de

recursos, tais como memória virtual, manipuladores de I/O, e manipuladores de sinais, que

fornecem o contexto para a execução das instruções de programa”; e uma thread é “uma

seqüência única de passos de instrução no contexto de um processo”.

A opinião dos pesquisadores na literatura é unânime ao considerar “notavelmente

difícil” o desenvolvimento de aplicações concorrentes eficientes, previsíveis, escaláveis, e

robustas, pois uma fonte de complexidade surge dos riscos comuns ao multi-threading, por

exemplo: impasses (deadlocks). Outra fonte de complexidade surge das limitações com

métodos de desenvolvimento, ferramentas, e plataformas de SOs existentes. A

Código da Aplicação

Manipuladores de Eventos

Demultiplexador

Fontes de Eventos

executa loop de eventos despacha callbacks

33

heterogeneidade das plataformas de hardware e de software complica o desenvolvimento de

aplicações e ferramentas concorrentes que devem executar sobre múltiplos SOs.

Padrões de design de propósito geral, tais como Adapter (GAMMA et al., 1995) e

Wrapper Facade (SCHMIDT et al., 2000), podem ser aplicados para proteger o software

concorrente das complexidades acidentais das APIs. Em (SCHMIDT et al., 2000), encontram-

se alguns Padrões de Concorrência, incluindo cinco padrões que definem vários tipos de

arquiteturas de concorrência para componentes, subsistemas e aplicações inteiras; são eles:

Active Object, Monitor Object, Half-Sync/Half-Async, Leader/Followers, e Thread-Specific

Storage.

2.4.4 Desafio: Sincronização

A eficiência, a receptividade, e o design de muitas aplicações distribuídas podem se

beneficiar do uso dos mecanismos e dos padrões de concorrência. Por exemplo, objetos em

uma aplicação podem ser executados concorrentemente em diferentes threads para simplificar

a estrutura do programa. Se múltiplos processadores estão disponíveis, as threads podem ser

programadas para explorarem o verdadeiro paralelismo em hardware e, por conseguinte,

melhorar o desempenho (SCHMIDT et al., 2000).

Quatro Padrões de Sincronização, os quais aliviam os problemas descritos acima para

simplificar a serialização e travas em sistemas concorrentes, são descritos em (SCHMIDT et

al., 2000): Scoped Locking, Strategized Locking, Thread-Safe Interface, e Double-Checked

Locking Optimization.

2.4.5 Desafios genéricos

Segundo (SCHMIDT et al., 2000), não obstante os quatro tópicos cobertos acima –

acesso e configuração de serviços, manipulação de eventos, concorrência, e sincronização –

representem os principais desafios do desenvolvimento de software distribuído, os

desenvolvedores de software de aplicações distribuídas devem tratar outras questões, tais

como confiabilidade, nomeação de serviços, e seleção de locais:

• Confiabilidade. Uma das razões para a adoção de uma arquitetura distribuída é a

melhoria da confiabilidade e a prevenção de pontos únicos de falhas. Conforme atestam.

A detecção de erros em aplicações distribuídas é mais difícil, devido ao conhecimento

incompleto do estado do sistema global.

• Nomeação de Serviços e Seleção de Locais. As aplicações distribuídas requerem

mecanismos mais elaborados para nomear, fixar em um local, e selecionar seus serviços

34

remotos. Endereços de IP hosts e números de portas TCP são esquema de endereçamento

de serviços remotos comuns usados por CORBA, DCOM, Java RMI, DCE, e SunRPC.

Entretanto, estes mecanismos de baixo nível são freqüentemente inadequados para

sistemas conectados em rede em larga escala, pois eles são difíceis de serem

administrados de uma maneira portável e não-ambígua. A computação de objetos

distribuídos e o middleware RPC, conseqüentemente, fornecem brokers de locais que

permitem aos clientes acessarem serviços através de nomes de alto nível ao invés de fazê-

lo por meio de endereços de IP e números de portas TCP de baixo nível.

Buschmann et al., (1996) apresentam uma série de padrões relacionados à vinculação

de nomes e locais de serviços.

2.5 Considerações Não obstante os sistemas distribuídos possam garantir muitos benefícios, eles são

inerentemente mais complexos em relação aos sistemas centralizados, o que dificulta o seu

design, implementação, otimização, e gerenciamento e manutenção. O uso de padrões

arquiteturais é capaz de alavancar o trabalho do desenvolvedor, provendo soluções

comprovadas para problemas recorrentes, possíveis de atenuar as dificuldades inerentes e

acidentais.

Para que a complexidade do desenvolvimento de sistemas distribuídos seja amenizada,

faz-se necessário o uso de técnicas e métodos de engenharia de software avançados. O

princípio da separação de interesses (SoC – Separation of Concerns) já no design arquitetural

de um sistema distribuído é de suma importância para o êxito do projeto.

Também ficou evidente que a arquitetura de um sistema distribuído é dinâmica,

devendo, em muitos casos, ser re-configurada em tempo de execução, e que a tendência é que

cada vez mais os sistemas distribuídos atuais sejam compostos de componentes móveis. Tais

características exigem recursos de modelagem que permitam ao designer a representação de

tais características em nível arquitetural, de modo que uma avaliação preliminar possa ser

realizada, minimizando os custos decorrentes de ajustes necessários em fases mais avançadas

do ciclo de vida do software.

35

3 – Arquitetura de Software

3.1 Introdução

A Arquitetura de Software emergiu como uma importante disciplina da engenharia de

software, particularmente no campo do desenvolvimento de sistemas de grande porte. Para

Clements et al. (2003), arquitetura “é o particionamento prudente de um todo em partes, com

relações específicas entre as partes”; sustentam também que é o que permite a um grupo de

pessoas (freqüentemente separadas por limites organizacionais, geográficos, ou até mesmo

temporais) trabalharem, cooperativamente e produtivamente, juntas para solucionar um

problema muito maior do que qualquer uma delas seria capaz de fazê-lo individualmente.

Para quase todos os sistemas, os atributos de qualidade (BOEHM; IN, 1996) ou metas

de engenharia – tais como desempenho, confiabilidade, segurança, ou modificabilidade – são

tão importantes quanto assegurar que o software compute a resposta correta. É na arquitetura

onde estas metas de engenharia são encontradas. Segundo (CLEMENTS et al., 2003), a

documentação da arquitetura comunica a consecução dessas metas:

• Se for requerido alto desempenho, é necessário: (i) preocupar-se com a decomposição do

trabalho em processos cooperativos; (ii) gerenciar o volume da comunicação inter-

processo e as freqüências de acesso aos dados; (iii) identificar potenciais gargalos de

desempenho; e (iv) entender as ramificações de uma falha de rede ou de processador.

• Se o sistema necessita de alta precisão, deve-se prestar atenção em como os elementos de

dados são definidos e usados.

• Se a segurança é importante, faz-se necessário: (i) elaborar restrições de relacionamentos

de usos e de comunicação entre as partes; (ii) detectar com precisão partes do sistema que

são vulneráveis às intrusões externas; e (iii) possivelmente introduzir componentes

específicos e com confiabilidade.

• Se for requerido suporte à modificabilidade ou portabilidade, deve-se separar

cuidadosamente os interesses entre as partes do sistema.

• Se for preciso produzir o sistema de modo incremental, por meio da liberação (releases)

de subconjuntos sucessivamente maiores, deve-se manter os relacionamentos de

dependência entre as peças não entrelaçadas a fim de evitar a síndrome do “nada funciona

até que tudo funcione”.

O restante deste capítulo encontra-se organizado como segue. Na Seção 3.2 são

apresentados os principais conceitos associados ao presente tópico. Na Seção 3.3 explicam-se

as principais finalidades de uma documentação arquitetural. Na Seção 3.4 é apresentado um

36

conteúdo abrangente sobre visões arquiteturais. Por fim, algumas considerações concernentes

ao conteúdo abordado neste capítulo são expressas na Seção 3.5.

3.2 Conceito

É mister estabelecer uma base comum acerca do que se entende por arquitetura de

software, pois, não obstante o termo arquitetura de software tenha múltiplas definições,

nenhuma definição universal existe ainda (SEI, 2006).

“A arquitetura de software de um programa ou sistema computacional é a estrutura

ou estruturas do sistema, que compreende componentes de software, as propriedades

externamente visíveis desses componentes, e os relacionamentos entre eles. Por

“propriedades externamente visível”, estamos nos referindo às hipóteses que outros

componentes podem fazer sobre um componente, tal como seus serviços fornecidos,

características de desempenho, manipulação de falhas, uso de recurso compartilhado,

e assim por diante” (BASS; CLEMENTS; KAZMAN, 1998).

Ao analisarmos muitas das definições encontradas na literatura (PERRY; WOLF,

1992), (GARLAN; SHAW, 1993), (GARLAN; PERRY, 1995), (IEEE, 2000), (BOOCH;

RUMBAUGH; JACOBSON; 2005), observamos que elas proporcionam uma perspectiva

estrutural sobre arquitetura de software: defendem que arquitetura de software é composta de

elementos, conexões entre eles, e, usualmente, alguns aspectos tais como configuração ou

estilo, restrições e semântica, análises ou propriedades, ou análise racional, requisitos, ou

necessidades de stakeholders3.

Shaw (1995) observou que, além da perspectiva estrutural acerca da arquitetura,

adicionalmente existem outras três importantes perspectivas:

• Modelos de framework são similares à perspectiva estrutural, mas sua ênfase principal está

na estrutura única e coerente do sistema como um todo, o oposto de concentrar-se em sua

composição. A perspectiva de framework concentra-se em arquiteturas de software de

domínio específico ou repositórios de domínio específico e, freqüentemente, elevam o

middleware ou a infra-estrutura de comunicação para um papel distinto.

• Modelos dinâmicos enfatizam a qualidade comportamental de sistemas. “Dinâmico”

refere-se a alterações na configuração geral do sistema, estabelecendo ou desabilitando

caminhos de interação ou comunicação pré-habilitados envolvidos no progresso de

computação, tal como alteração de valores de dados.

3 A norma IEEE 1471 (IEEE, 2000), considera como sendo um stakeholder o “o indivíduo, a equipe, ou a organização (ou classes deles) com interesse em um sistema, ou preocupações relativas a um sistema”.

37

• Modelos de processos concentram o foco na construção da arquitetura e nos passos ou

processos envolvidos nessa construção. A partir desta perspectiva, a arquitetura é o

resultado do ato de seguir um script de processo.

Vê-se que essas perspectivas não se excluem, tampouco representam um conflito

fundamental sobre o que é a arquitetura de software. Pelo contrário, elas representam aquilo

que a comunidade de software acredita que deve ser enfatizado e colocado na arquitetura:

suas partes constituintes, a entidade como um todo, a forma como ela se comporta uma vez

construída ou a construção dela.

3.2.1 Arquitetura versus Design

Trata-se de uma questão que tem incomodado a comunidade de arquitetura de

software, mas felizmente uma resposta elucidativa é fornecida em (CLEMENTS et al., 2003):

“Arquitetura é design, mas nem todo design é arquitetural. Isto é, muitas decisões de

design não são restringidas pela arquitetura e, felizmente, são deixadas ao critério e

bom julgamento subseqüentes dos designers e implementadores. A arquitetura

estabelece restrições sobre as atividades subseqüentes, e essas atividades devem

produzir artefatos – designs e códigos de fina granularidade – que estão de acordo com

o estabelecido na arquitetura, apesar de a arquitetura não definir a implementação.”

Disso, emerge a questão: “Quais decisões são não-arquiteturais? Isto é, quais decisões

a arquitetura deixa livre e a critério de outros?” Para responder a esta questão, faz-se

necessário retornar à definição de arquitetura de software, citada na seção anterior, extraída de

(BASS; CLEMENTS; KAZMAN, 1998): “... a estrutura ou estruturas do sistema, cada uma

das quais compreende elementos, as propriedades externamente visíveis desses elementos, e

os relacionamentos entre eles”.

Se uma propriedade de um elemento arquitetural não é visível, ou discernível, para

qualquer outro elemento arquitetural, esse elemento não é arquitetural. A seleção de uma

estrutura de dados, paralelamente aos algoritmos para gerenciar o acesso a essa estrutura de

dados, é um exemplo típico.

Segundo Clements et al., (2003), não há escala, ou escopo, ou medida, ou linha que

divide o que é arquitetural e o que não é. Para uma pessoa, uma determinada representação

arquitetural pode ser a implementação da arquitetura de outra pessoa e vice-versa.

Outro questionamento surge: “Quando um arquiteto deve parar de decompor módulos

em módulos menores e atribuições de trabalhos menores?” Uma heurística advém de Parnas e

Clements (1986): eles dizem que um módulo está “pequeno o suficiente” quando, face a uma

alteração, seria tão fácil recodificá-lo quanto alterá-lo.

38

Garlan e Shaw (1993) afirmam que “as decisões são arquiteturais ou não, de acordo o

contexto”. Se uma dada estrutura é importante para o alcance das metas do sistema, então essa

estrutura é arquitetural. Todavia, os designers de elementos, ou subsistemas, a quem foram

atribuídos trabalhos, podem ter que introduzir suas próprias estruturas a fim de alcançar suas

metas: nesses casos, eles considerarão tais estruturas como sendo elementos arquiteturais.

3.2.2 Especificação, Representação, Descrição ou Documentação?

Outra questão suscitada pela comunidade refere-se a qual denominação deve ser dada

à atividade de escrever a arquitetura de software. Em (CLEMENTS et al., 2003), os autores

discutem a terminologia como segue:

• O termo especificação tende a dar a conotação de uma versão de arquitetura em uma

linguagem estritamente formal.

• O termo representação dá a conotação de um modelo, uma abstração, uma versão de uma

coisa a qual se encontra separada ou diferente da própria coisa.

• O termo descrição foi apropriado pela comunidade de ADLs.

• O termo documentação denota a criação de um artefato denominado arquitetura de

software: um documento que pode compreender arquivos eletrônicos ou papéis.

Portanto, Clements et al. (2003) consideram que este último termo é o que pode ser

mais adequadamente usado. De fato, este termo possui razoável abrangência. A essência da

atividade é escrever, e manter atualizados, os resultados de decisões arquiteturais para que os

stakeholders da arquitetura tenham a informação que eles necessitam de uma forma acessível

e não ambígua.

3.2.3 Interfaces

Uma interface é uma fronteira por meio da qual duas entidades independentes se

encontram e interagem ou se comunicam (BASS; CLEMENTS; KAZMAN, 2003). É possível

e provável que uma entidade tenha mais do que uma interface por meio da qual ela interage

ou se comunica. Uma interface é mais do que uma lista de seus serviços disponíveis.

Idealmente, a especificação de uma interface deve prover informação suficiente para evitar

interações inesperadas que podem ocorrer devido a hipóteses que uma entidade faz sobre o

ambiente no qual ela será inserida ou sobre as entidades com as quais ela interage.

3.2.4 Módulos versus Componentes

Durante os anos 1960 e 1970, houve o incremento do tamanho dos sistemas de

software, os quais não eram mais possíveis de serem produzidos por uma única pessoa. Isso

tornou claro que novas técnicas eram necessárias para gerenciar a complexidade do software e

39

particionar o trabalho entre programadores. Para lidar com tais questões de “programação em

larga escala”, vários critérios foram introduzidos para auxiliar os programadores sobre como

particionar seus softwares. O encapsulamento, a ocultação de informação, e tipos de dados

abstratos, tornaram-se os paradigmas de design dominantes, usando o termo módulo como o

portador desse significado (PARNAS, 1972).

Os anos 1970 e 1980 testemunharam o advento de “linguagens de interconexão de

módulos” (DEREMER; KRON, 1975) e as características de novas LPs tais como módulos da

Modula, classes da Smalltalk, pacotes da Ada: o paradigma OO traz em seu cerne esses

conceitos de módulo. Os componentes, por contraste, estão em evidência com a engenharia de

software baseada em componentes (SZYPERSKI, 1998) e com a perspectiva de componente-

e-conector na área da arquitetura de software.

Ambos os movimentos aspiram atingir a construção e a evolução rápida de sistemas

por meio da seleção, montagem, e reposição indiscriminada de sub-peças independentes.

Ambos, módulos e componentes, estão relacionados à decomposição de um sistema de

software completo em partes constituintes. Conforme (CLEMENTS et al., 2003), esses dois

termos assumem diferentes significados:

• Módulo: tende a referir-se a uma entidade em tempo de design. O trabalho fundamental

de Parnas (1972) sobre design de módulos usou a ocultação de informação como critério

para a alocação de responsabilidade a um módulo. A informação que, provavelmente,

mudaria no decorrer do ciclo de vida de um sistema, tal como a escolha de estrutura de

dados ou algoritmos, era associada a um módulo, que tinha uma interface por meio da

qual seus recursos eram acessados.

• Componente: tende a referir-se a uma entidade em tempo de execução. Shaw e Garlan

(1996), por exemplo, falam da arquitetura de um sistema como uma coleção de

“componentes computacionais” – ou simplesmente “componentes” – paralelamente com

uma descrição de suas interações. Szyperski (1998) afirma que um componente “pode ser

implantando independentemente e está sujeito a composição com terceiros”. Herzum e

Sims (2000) dizem que um componente é “uma parte auto-contida de software com uma

interface bem definida ou conjunto de interfaces”. Deduz-se uma clara conotação de

tempo de execução e implantação; isto é, o componente tem interfaces que são acessíveis

em tempo de execução e, em alguns pontos no seu ciclo de vida do seu desenvolvimento,

o componente pode ser independentemente entregue e instalado. A ênfase está claramente

no produto acabado e não nas considerações de design que vão nele.

40

Em resumo, um módulo sugere propriedades de encapsulamento, com menos ênfase

no meio de distribuição e no que continuará em tempo de execução. Não é assim com os

componentes: um arquivo de código binário distribuído mantém sua individualidade durante a

execução, pois um componente sugere unidades de software implantadas independentemente,

sem visibilidade no processo de desenvolvimento (CLEMENTS et al., 2003).

Obviamente há sobreposição. O tipo de visão módulo (veja Seção 3.4.3) contém

estilos que refletem principalmente considerações em tempo de design: decomposições que

associam partes do problema a unidades de design e desenvolvimento, camadas que refletem

quais usos são permitidos enquanto o software é escrito, e classes que fatoram a existência de

atributos comuns a partir de um conjunto de instâncias. Naturalmente, todos estes estilos têm

implicações em tempo de execução. Similarmente, o tipo de visão componente-e-conector

(veja Seção 3.4.4) contém estilos que focalizam sobre como os processos interagem e os

dados trafegam pelo sistema durante a execução. Todos estes efeitos em tempo de execução

são resultantes das cuidadosas atividades em tempo de design (CLEMENTS et al., 2003).

Embora seja uma superposição conceitual, uma determinada arquitetura, geralmente,

também exibirá uma sobreposição concreta. Um elemento documentado em uma visão de

módulo pode se apresentar em uma visão componente-e-conector como as manifestações em

tempo de execução do seu próprio tempo de design. Como um componente, o elemento pode

estar replicado várias vezes – por meio de diferentes processadores, por exemplo. Como um

módulo, entretanto, é muito improvável que ele seja duplicado, pois dificilmente seria pedido

a alguém para produzir a mesma parte de código duas vezes (CLEMENTS et al., 2003).

Módulos e componentes representam o real fundamento da abordagem de engenharia

de software para sistemas de software rapidamente construídos e facilmente modificáveis.

Como tais, os módulos e os componentes servem como blocos de construção fundamentais à

criação e documentação de arquiteturas de software (BASS; CLEMENTS; KAZMAN, 2003).

3.3 Usos da Documentação Arquitetural

Na visão de Clements et al. (2003), a documentação arquitetural deve: (a) ser

suficientemente abstrata para ser rapidamente entendida por novos stakeholders; (b) ser

suficientemente detalhada para servir como uma planta para construção; (c) ter informação

suficiente para servir como uma base para análise. A documentação arquitetural é prescritiva

(para algumas audiências, ela prescreve o que deve ser verdadeiro, impondo restrições nas

decisões a serem tomadas) e descritiva (para outras audiências, ela descreve o que é

41

verdadeiro, relatando decisões já tomadas sobre o design). Segundo (CLEMENTS et al.,

2003), uma documentação arquitetural pode ser utilizada como um(a):

1. Meio de educação: O uso educacional consiste na introdução de pessoas ao sistema

(novos membros da equipe, analistas externos, ou até novo arquiteto).

2. Veículo primário de comunicação: Um uso preciso da arquitetura como um veículo de

comunicação depende de quais stakeholders estão fazendo a comunicação. Alguns

exemplos estão descritos na Tabela 3.1.

Tabela 3.1: Documentação da arquitetura e os stakeholders – Fonte: (CLEMENTS et al., 2003)

Stakeholder Comunicação

Arquitetos e engenheiros de requisitos representando o cliente

Um fórum para negociação e realização de trade-offs4 entre

os requisitos que competem entre si.

Arquitetos e designers das partes constituintes

Para solucionar a contenção de recursos e estabelecer desempenho e outros tipos de orçamento de consumo de recursos em tempo de execução.

Implementadores Para prover restrições invioláveis e liberdades exploráveis nas atividades de desenvolvimento subseqüentes.

Testadores e integradores Para especificar o comportamento caixa-preta correto das partes que devem se unir, adequadamente.

Responsáveis pela manutenção Um ponto de partida para as atividades de manutenção, revelando as áreas que uma possível futura alteração afetará.

Designers de outros sistemas com os quais este deve inter-operar

Definir o conjunto de operações fornecidas e requeridas e os protocolos para suas operações.

Gerentes Base para a formação de equipes de desenvolvimento correspondentes às atribuições de trabalhos identificados, estrutura do desdobramento de trabalho, planejamento, alocação de recursos de projeto, e rastreamento de progresso.

Gerentes de linhas de produto Para determinar se um possível novo membro de uma família de produto está dentro ou fora do escopo.

Equipe de garantia de qualidade Base para a verificação da conformidade, e garantia que a implementação está sendo fiel às prescrições arquiteturais.

Uma arquitetura pode ser re-usada em outros sistemas para os quais ela for apropriada.

Se gerenciada com cautela, uma família inteira de produtos pode ser produzida usando-se uma

única arquitetura. Neste caso, sua importância é ampliada, pois poderá servir como uma

planta para desenvolvimento de uma linha de produtos (CLEMENTS; NORTHROP, 2002).

3. Base para análise do sistema: Para dar suporte à análise, a arquitetura deve conter a

informação necessária à análise particular sendo executada (CLEMENTS et al., 2003):

4 Análise dos prós e dos contras; balanceamento das forças;

42

• Para os engenheiros de software que analisam o desempenho, a documentação da

arquitetura provê o modelo formal que direciona as ferramentas de análise, tais como

análise de escalonamento em tempo real e simulações. Estas ferramentas requerem

informações sobre consumo de recursos, política de escalonamento e dependências.

• A documentação da arquitetura serve para alimentar os métodos de avaliação, devendo

conter a informação necessária para avaliar uma variedade de atributos, tais como

segurança, desempenho, usabilidade, disponibilidade, e modificabilidade.

A arquitetura representa o primeiro mapeamento dos requisitos para os componentes

computacionais. A alocação de funcionalidades para cada componente consiste em uma

codificação das decisões de design preliminares sobre um projeto. Todas as decisões de

design subseqüentes (ex.: design detalhado, implementação) devem ser consistentes com as

escolhas arquiteturais (BASS; CLEMENTS; KAZMAN, 2003).

Uma arquitetura pode permitir ou impedir a realização da maioria dos atributos de

qualidade (BOEHM; IN, 1996) almejados em um sistema, tais quais os exemplificados em

(KAZMAN et al., 1994): (i) a modificabilidade depende extensivamente da modularização

do sistema, a qual reflete as estratégias de encapsulamento; (ii) a reusabilidade dos

componentes depende fortemente do quão fortemente acoplados eles estão com outros

componentes no sistema; e (iii) o desempenho depende muito do volume e complexidade da

comunicação de coordenação inter-componente, especificamente se os componentes são

processos fisicamente distribuídos. Uma arquitetura incorpora decisões sobre as prioridades e

o trade-off das qualidades, e representa a primeira oportunidade para a avaliação destas

decisões e balanceamentos, sendo a primeira abordagem para atingir os atributos de qualidade

(CLEMENTS; KAZMAN; KLEIN, 2002).

Clements et al. (2003) enumeram as seguintes regras para que a atividade de

documentação arquitetural alcance resultados sólidos e eficazes:

� Regra 1: Escrever a documentação a partir do ponto de vista do leitor.

� Regra 2: Evitar repetição desnecessária.

� Regra 3: Evitar ambigüidade (explicar a notação).

� Regra 4: Usar uma organização padronizada.

� Regra 5: Registrar a análise racional (rationale).

� Regra 6: Manter a documentação atualizada.

� Regra 7: Revisar a documentação para ajuste de propósito.

43

3.4 Visões Arquiteturais

Parnas (1974) observou que o software consiste de muitas estruturas, que podem ser

definidas como descrições parciais mostrando um sistema como uma coleção de partes e

mostrando algumas relações entre as partes. Esta ainda definição persiste nos artigos de

arquitetura atuais. Parnas (1974) também identificou várias estruturas predominantes no

software. Algumas eram mais específicas para SOs, tais como a estrutura que define qual

processo possui qual segmento de memória, mas outras são mais genéricas e amplamente

aplicáveis. Estas incluem: estrutura de módulo (unidades são atribuições de trabalho, a

relação é-uma-parte-de ou compartilha-parte-do-mesmo-segredo-como) a estrutura usa

(unidades são programas, e a relação é depende-da-corretude-de) e a estrutura de processos

(unidades são processos, e a relação é dá-trabalho-computacional-para).

Perry e Wolf (1992) reconheceram que, semelhantemente à arquitetura de um edifício,

uma variedade de visões de um sistema são requeridas. Cada visão enfatiza certos aspectos

arquiteturais usados por diferentes stakeholders ou para diferentes propósitos.

Kruchten (1995) descreve quatro visões principais de arquitetura de software que

podem ser usadas com grande vantagem na construção de sistemas, paralelamente com uma

quinta visão distinta que vincula as outras quatro: a abordagem para arquitetura “4+1”:

1. A visão lógica: Primariamente, dá suporte a requisitos comportamentais (os serviços que o

sistema deve oferecer aos usuários finais). Os designers decompõem o sistema em um

conjunto de abstrações chaves, extraídas principalmente a partir do domínio do problema.

2. A visão de processo: Lida com a concorrência e distribuição, integridade do sistema e

tolerância a falhas. Também especifica qual thread de controle executa cada operação

identificada na visão lógica. Esta visão pode ser vista como um conjunto de redes lógicas

de programas de comunicação executando independentemente (processos) que estão

distribuídos ao longo dos recursos de hardware, os quais por sua vez estão conectados por

uma rede de barramento ou LAN, ou rede WAN.

3. A visão de desenvolvimento: Centraliza o foco na organização dos módulos do software

no ambiente de desenvolvimento de software. As unidades desta visão são as partes do

software (bibliotecas de programa ou subsistemas) que podem ser desenvolvidos por um

ou mais desenvolvedores. A visão de desenvolvimento dá suporte à alocação de requisitos

e trabalho para equipes e dá suporte à avaliação de custos, planejamento, monitoramento

de progresso, e raciocínio sobre reuso de software, portabilidade, e segurança.

44

4. A visão física: Leva em conta os requisitos do sistema, tais como disponibilidade do

sistema, confiabilidade, desempenho, e escalabilidade. Esta visão mapeia os vários

elementos identificados nas visões lógica, de processo e de desenvolvimento (redes,

processos, tarefas, e objetos) para nós de processamentos.

Além disso, Kruchten (1995) descreve um pequeno subconjunto de cenários

importantes (instâncias de casos de uso) para mostrar que os elementos das quatro visões

trabalham juntos. Esta é a visão “+1”, redundante com as outras, mas servindo a um propósito

distinto. A abordagem “4+1” tem sido adotada como uma peça fundamental do RUP

(Rational Unified Process).

Soni, Nord, e Hofmeister (1995) chegaram a algumas conclusões similares sobre

visões arquiteturais em função ao que eles observaram no uso prático na indústria:

• A visão conceitual descreve o sistema em termos de seus principais elementos de design e

os relacionamentos entre eles.

• A visão de interconexão de módulos abrange duas estruturas ortogonais: decomposição

funcional e camadas.

• A visão de execução descreve a estrutura dinâmica de um sistema.

• A visão de código descreve como o código fonte, binários, e bibliotecas são organizados

no ambiente de desenvolvimento.

Outros “conjuntos de visões” têm emergido, como por exemplo, as visões de Herzum

e Sims (2000), os quais prescrevem as quatro seguintes visões como sendo as mais

importantes:

• A arquitetura técnica, focalizada no ambiente de execução de componentes, o conjunto de

ferramentas, o framework de interface com o usuário, e outros serviços/facilidades

técnicas requeridas para desenvolver e executar um sistema baseado em componentes.

• A arquitetura da aplicação, interessada com o conjunto de decisões arquiteturais, padrões

(patterns), diretrizes, e normas (standards) necessários para a construção do sistema.

• A arquitetura do gerenciamento de projeto, a qual consiste nos elementos (os conceitos,

diretrizes, princípios, e ferramentas de gerenciamento) necessários para se construir um

grande sistema escalável com uma grande equipe.

• A arquitetura funcional, onde estão a especificação e a implementação do sistema.

Cada visão arquitetural é usada para um propósito diferente, freqüentemente por

diferentes stakeholders. Dessa forma, um conjunto de várias visões forma a unidade básica

para a documentação de uma arquitetura de software.

45

3.4.1 Conceito de Visão Arquitetural

O conceito de visão está entre os mais importantes conceitos associados à

documentação de arquitetura de software, já que esta última é uma entidade complexa a qual

não pode ser descrita de um modo unidimensional. Uma visão é uma representação de um

conjunto de elementos de sistema e os relacionamentos associados a eles (CLEMENTS et al.,

2003). Diferentes visões dão suporte a diferentes metas e usos (PERRY; WOLF, 1992).

Kruchten (1995) afirma que “a essência da documentação consiste na supressão de

informação não necessária à tarefa em mãos” e, assim, “é de algum modo conveniente que a

natureza da arquitetura seja tal que ela nunca apresente seu todo para nós, mas apenas uma

faceta ou duas de cada vez”. Nenhuma das visões tem a capacidade de, individualmente,

documentar de modo adequado a arquitetura de software para o sistema. Isto é realizado pelo

conjunto completo de visões, paralelamente à informação que as transcende.

Clements et al. (2003) elaboraram um template para a documentação de uma visão, o

qual consiste no conjunto das informações seguintes:

1. Uma apresentação primária, usualmente gráfica, que representa os elementos primários e

os relacionamentos da visão.

2. Um catálogo de elementos que explica e define os elementos mostrados na visão, e lista

suas propriedades.

3. Uma especificação das interfaces e do comportamento dos elementos.

4. Um guia de variabilidade explicando quaisquer mecanismos built-in disponíveis para

adaptação da arquitetura.

5. A análise racional e informações de design.

6. A documentação que se aplica a tudo o que está contido nas visões.

7. Uma introdução ao pacote completo, incluindo uma seção “guia do leitor” que auxilia o

stakeholder a encontrar uma parte desejada da informação rapidamente.

8. Informações descrevendo como as visões relacionam entre si, e ao sistema como um todo.

9. Restrições e análise racional para a arquitetura global.

10. Informações de gerenciamento na forma como podem ser requeridas para efetivamente

manter o pacote completo.

3.4.2 Tipos de Visões e Estilos Arquiteturais

Conforme (CLEMENTS et al., 2003), um tipo de visão define os tipos de elementos e

os tipos de relacionamentos usados para se descrever a arquitetura de um sistema de software

46

a partir de uma determinada perspectiva. Um tipo de visão restringe o conjunto de elementos

e relações que existem em suas visões.

Clements et al. (2003) alegam que os arquitetos precisam pensar sobre seus softwares

de três formas simultaneamente: (i) como ele é estruturado na forma de um conjunto de

unidades de implementação; (ii) como ele é estruturado na forma de um conjunto de

elementos que têm comportamentos e interações em tempo de execução; e (iii) como ele

relaciona-se em seu ambiente com estruturas que não são softwares. Cada visão cai numa das

categorias, chamadas de tipos de visões. Conforme (CLEMENTS et al., 2003), os três tipos de

visões são: (i) tipo de visão módulos, as visões de módulos documentam as principais

unidades de implementação de um sistema; (ii) tipo de visão componente-e-conector (C&C),

as visões C&C documentam as unidades de execução de um sistema; e (iii) tipo de visão

alocação, as visões de alocação documentam os relacionamentos entre um software de um

sistema e seus ambientes de desenvolvimento e de execução.

No âmbito de um determinado tipo de visão, formas recorrentes têm sido amplamente

observadas (até mesmo as escritas para sistemas completamente diferentes) (GARLAN;

SHAW, 1993). A descrição de cada tipo de visão inclui uma seção sobre variações e formas

que ocorrem com freqüência: isso é chamado de estilos arquiteturais ou estilos, os quais têm

implicações para a documentação arquitetural (SHAW, 1995).

Um estilo arquitetural é uma especialização de tipos de elementos e de relações,

juntamente com um conjunto de restrições sobre como eles podem ser usados (SHAW, 1995)

(SHAW; CLEMENTS, 1997). Um guia de estilo é a descrição de um estilo arquitetural que

especifica o vocabulário de design (conjunto de tipos de elementos e de relacionamentos) e as

regras (conjunto de restrições topológicas e semânticas) sobre como esse vocabulário pode ser

usado (GARLAN; SHAW, 1993).

Um estilo define uma família de arquiteturas que satisfazem determinadas restrições

(PARNAS, 1976). Os estilos permitem a alguém aplicar conhecimento de design

especializado a uma categoria particular de sistemas e oferecem suporte a essa categoria de

design de sistema com ferramentas, análise, e implementações específicas do estilo. A

literatura está repleta de estilos: (PARNAS, 1976), (NII, 1986), (ANDREWS, 1991),

(GARLAN; SHAW, 1993), (GARLAN; ALLEN, OCKERBLOON, 1994), (ABOWD;

ALLEN; GARLAN, 1995), (BUSCHMANN et al., 1996), (SHAW; CLEMENTS, 1997),

(MEDVIDOVIC; ROSENBLUM, 1997), (MONROE et al., 1997), (SCHMIDT et al., 2000).

47

Por exemplo, os módulos podem ser arranjados em uma configuração útil restringindo

o que é permitido a cada um usar. O resultado é um estilo em camadas – uma espécie do

gênero tipo de visão módulos (veja Seção 3.4.3) – por meio do qual se concebe sistemas que

usam suas qualidades de modificabilidade, portabilidade, e a habilidade de extrair

rapidamente um subconjunto útil. Sistemas diferentes terão uma quantidade diferente de

camadas, conteúdos diferentes em cada camada, e regras diferentes para o que é permitido a

cada camada usar. Entretanto, o estilo em camadas é abstrato a respeito dessas opções e pode

ser estudado e analisado sem vinculá-las (CLEMENTS et al., 2003).

3.4.3 Tipo de Visão Módulos

De acordo com o definido em (PARNAS, 1972), um módulo é um código que

implementa um conjunto de responsabilidades. Um módulo pode ser uma classe, uma coleção

de classes, uma camada, ou qualquer decomposição da unidade de código. Todo módulo tem

uma coleção de propriedades atribuídas a ele. Estas propriedades têm a intenção de expressar

a informação relevante associada ao módulo, assim como restrições sobre o módulo.

Exemplos de propriedades são responsabilidades, informação de visibilidade, e autor.

Módulos têm relações entre si; ex.: é parte de ou herda de. Conforme (CLEMENTS et al.,

2003), os estilos do tipo de visão módulo são os seguintes:

1. Estilo decomposição: Representa a decomposição do código em sistemas, subsistemas,

sub-subsistemas, e assim por diante, representando uma visão top-down do sistema5.

Usado para dar uma visão geral do sistema e suas partes para os stakeholders, é

particularmente útil para a educação e comunicação em nível de gerência. Auxilia novos

membros da equipe de desenvolvimento a entender quais os seus papéis em termos de

desenvolvimento de código; é a base de designação de trabalhos e medidas de conclusões.

2. Estilo usa: Depende das relações usa, que é uma forma especial da relação depende-de. A

unidade de software P1 depende de P2 estar igualmente correta. Informa ao desenvolvedor

quais outros módulos devem existir para que sua parte do sistema possa executar

corretamente. Oferece suporte ao desenvolvimento incremental, já que possibilita a

identificação de subconjuntos do sistema que podem ser produzidos antecipadamente.

3. Estilo generalização: Mostra como diferentes unidades de código estão relacionadas uma

às outras, em uma hierarquia de classes: a determinação de quais classes herdam de outras

classes ocorre observando-se o estilo generalização. Comumente usado para expressar

designes OO, assim como dar suporte à uma variedade de formas de manutenção. O reuso

5 O termo sistema ou subsistema também tem uma interpretação em tempo de execução, e assim o seu uso necessita ser esclarecido em um contexto particular.

48

é freqüentemente baseado em classes, novas funções são freqüentemente adicionadas por

meio da modificação de funções antigas, e a parte do código a ser reparada, no caso de um

erro, é usualmente especificada em termos de classes.

4. Estilo camadas: Organiza o código em camadas6 disjuntas onde o código em camadas

mais altas tem a permissão de usar código em camadas mais baixas, conforme regras pré-

definidas. Por exemplo, as regras podem estipular que apenas o código na camada

imediatamente inferior pode ser usado, ou que o código em qualquer camada inferior pode

ser usado, ou que o código em camadas inferiores pode ser usado. Este estilo é usado para

mostrar como o código é decomposto em máquinas virtuais. Tipicamente, os níveis

inferiores envolvem partes do sistema próximas ao hardware, incluindo o SO, enquanto

que as camadas mais altas contêm software mais dependente da aplicação. Este estilo é

usado para educação e para dar suporte ao reuso.

3.4.4 Tipo de Visão Componente-e-Conector (C&C)

Os estilos no tipo de visão componente-e-conector (C&C) expressam o

comportamento em tempo de execução; eles são descritos em termos de componentes e

conectores. Um componente é uma das principais unidades de processamento do sistema em

tempo de execução; um conector é um mecanismo de interação para os componentes. Objetos,

processos, ou coleções de objetos podem ser componentes. Quanto aos conectores, incluem

dutos, repositórios, e sockets (GARLAN, SHAW, 1994) (SHAW et al., 1995).

O middleware pode ser visto como um conector especial entre os componentes

(MEDVIDOVIC; DASHOFY; TAYLOR, 2003). Tanto os componentes quanto os conectores

podem ser decompostos em outros componentes e conectores; a decomposição de um

componente pode incluir conectores e vice-versa: por exemplo, a decomposição de um

middleware (um conector) produzirá vários componentes e conectores adicionais (SHAW et

al., 1995) (MORICONI; QIAN; RIEMENSCHNEIDER, 1995). Os componentes e conectores

têm propriedades que podem ser usadas para associar-se com a análise da arquitetura. Os

estilos do tipo de visão componente-e-conector são (CLEMENTS et al., 2003):

1. Estilo duto-e-filtro (pipe-and-filter): o padrão de interação é caracterizado por meio de

sucessivas transformações de dados. Os dados chegam a um filtro, é transformado, e é

passado através do duto para o próximo filtro no pipeline (metáfora do oleoduto).

Exemplos de tais sistemas são sistemas de processamento de sinais e os pipes do UNIX.

6 Uma camada é pode ser vista como um conjunto de código que forma uma máquina virtual e que interage com outras camadas somente de acordo regras pré-definidas.

49

2. Estilo dados-compartilhados: centraliza-se na retenção dos dados persistentes. Múltiplos

elementos acessam os dados persistentes, os quais estão retidos em, no mínimo, um

repositório. Sistemas de banco de dados e sistemas de base de conhecimento são exemplos

de estilos dados-compartilhados. Uma característica de um estilo dados-compartilhados é:

como o consumidor de dados pode descobrir que os dados de interesse estão disponíveis.

3. Estilo publicar-subscrever: é caracterizado por componentes que interagem por meio de

anúncio de eventos. Os componentes podem se subscrever a um conjunto de eventos. O

estilo é comumente usado para desacoplar produtores e consumidores de mensagens. Este

desacoplamento permite a postergação da vinculação de produtores e consumidores de

mensagens até o momento da execução e, conseqüentemente, oferece suporte à

modificação destes produtores e consumidores.

4. Estilo cliente-servidor: mostra componentes interagindo por meio da requisição de

serviços de outros componentes (a comunicação é tipicamente formada por um par). Um

pedido de serviço de um cliente está emparelhado com o fornecimento desse serviço. Os

servidores neste estilo fornecem um conjunto de serviços por meio de uma ou mais

interfaces, e os clientes usam zero ou mais serviços fornecidos por outros servidores no

sistema. Pode haver um servidor central ou vários servidores distribuídos. Exemplos de

sistemas cliente-servidor incluem: (a) sistemas de janelas que particionam o sistema

conforme a aplicação cliente e o servidor de tela; (b) serviços de diretórios de nomes que

particionam de acordo com o solver de nomes e com o servidor de nomes; (c) sistemas de

banco de dados em três camadas que particionam o sistema de acordo aos clientes e

dados; e (d) sistemas distribuídos baseados na Web que particionam o sistema de acordo

com os interesses das aplicações clientes, lógica do negócio, e serviços de gerenciamento

de dados.

5. Estilo peer-to-peer: é caracterizado pela interação direta de pares de componentes

trocando serviços. A comunicação peer-to-peer é um tipo de interação pedido/resposta

encontrado no estilo cliente-servidor. Qualquer componente pode, em princípio, interagir

com qualquer outro componente por meio de requisição de serviços. Conseqüentemente,

os conectores neste estilo podem envolver protocolos de interações bidirecionais

complexos, refletindo a comunicação de duas vias que pode existir entre dois ou mais

componentes peer-to-peer. Exemplos de sistemas peer-to-peer incluem arquiteturas que

são baseadas em infra-estrutura de objetos distribuídos, tais como CORBA, COM+, e

50

Java RMI. De forma mais geral, as visões arquiteturais de sistemas de objetos, tais

como as mostradas em diagramas de colaboração, podem ser exemplos deste estilo.

6. Estilo comunicação-processos: é distinguido por meio da interação de componentes

executando concorrentemente através de vários mecanismos de conectores. Exemplos dos

mecanismos de conectores são: sincronização, passagem de mensagem, troca de dados,

start, stop, etc. Os processos em comunicação são comuns na maioria dos sistemas de

grande porte e necessários em todo sistema distribuído. Conseqüentemente, para a maioria

dos sistemas, o estilo comunicação-processos é adequado para o entendimento de

qualquer comportamento associado à concorrência.

3.4.5 Tipo de Visão Alocação

Cada estilo do tipo de visão alocação descreve o mapeamento de unidades de software

a elementos do ambiente (hardwares, sistemas de arquivos, ou equipes de desenvolvimento).

O tipo de visão alocação inclui os seguintes estilos (CLEMENTS et al., 2003):

1. Estilo implantação: Mapeia processos a elementos de hardware: nós de processamento,

canais de comunicação, memórias, e armazém de dados (os elementos de software são

usualmente processos). Usado para: descrever como os processos são alocados ao

hardware e o tráfego de mensagem resultante: para análise de desempenho, segurança, e

confiabilidade; e como base para estimativa de custo de implantação de um único módulo.

2. Estilo implementação: Mapeia módulos do tipo de visão módulos para uma infra-

estrutura de desenvolvimento. Seus elementos são módulos e itens de configuração. É

usado para descrever como os módulos são mapeados a entidades dentro do sistema de

gerenciamento de configuração, assim como para gerenciar versões e ramificações e para

coordenar o desenvolvimento multi-equipes.

3. Estilo atribuição de trabalho: Mapeia módulos de um tipo de visão módulos para

equipes de desenvolvimento. Os elementos são módulos e equipes de

desenvolvimento. É usado para designar quais equipes são responsáveis por quais

elementos da estrutura de desdobramento de trabalho, assim como para informar

estimativas de cronograma e de orçamento.

3.5 Considerações

Arquitetura de software é uma representação de alto nível da estrutura dos

componentes e seus inter-relacionamentos, cujos princípios e diretrizes servem para guiar o

projeto em seu ciclo de vida, proporcionando meios para o particionamento efetivo e a

comunicação entre as diversas partes envolvidas no projeto.

51

Os três tipos de visões – módulos, C&C, e alocação – representam as três perspectivas

que um arquiteto deve considerar quando do design de um sistema: o sistema como unidades

de implementação, o sistema como unidades executadas em tempo de execução, e o

mapeamento a partir dos elementos de software para as estruturas ambientais. Um tipo de

visão restringe os tipos de elementos e os tipos de relacionamentos correspondentes. Algumas

escolhas devem ser feitas até mesmo dentro dos limites de um tipo de visão: como os

elementos estão restritos, como eles se relacionam entre si, e restrições sobre seu uso ou

configuração.

Diferentes visões também expõem diferentes atributos de qualidade para diferentes

graus. Conseqüentemente, os atributos de qualidade que são de maior interesse a um grupo de

stakeholders no desenvolvimento do sistema afetará a escolha sobre quais visões devem ser

documentadas. Por exemplo, uma visão em camadas diz respeito à portabilidade do sistema,

uma visão de implementação conduz a um raciocínio sobre o desempenho e a confiabilidade

do sistema. As visões que devem ser documentadas dependem dos usos esperados da

documentação. Diferentes visões realçarão diferentes elementos e/ou relacionamentos do

sistema.

Um estilo é uma especialização de um tipo de visão e reflete padrões de interação

recorrentes, porém, até mesmo dentro dos limites de um estilo, escolhas devem ser feitas:

como os tipos de elementos e de relações em um estilo estão vinculados aos elementos e

relações em um sistema. No contexto de tipos de visões e estilos, conseqüentemente, uma

visão pode ser vista como um estilo que está vinculado a um sistema em particular.

Por exemplo, descreve-se o estilo publicar-subscrever (GARLAN; SHAW, 1993) em

termos de “componentes fracamente acoplados cujas interfaces permitem a publicação de

eventos e a subscrição aos eventos”, mas a descrição do estilo é independente de qualquer

estilo. Se for escolhido o estilo publicar-subscrever como estratégia de design para o sistema,

o arquiteto produzirá uma visão publicar-subscrever nomeando os elementos e os eventos que

eles publicam e os que eles aceitam.

Diversos pesquisadores constataram que nenhum sistema é construído exclusivamente

a partir de um único estilo, pois todo sistema pode ser visto como um amálgama de muitos

estilos diferentes. Alguns estilos ocorrem em todo sistema, mas há sistemas que exibem uma

combinação de estilos (GARLAN; SHAW, 1993), que pode ocorrer de várias formas

(CLEMENTS et al., 2003).

Diferentes “áreas” de sistemas podem exibir diferentes estilos. Por exemplo, um

sistema pode usar um estilo duto-e-filtro para processar dados de entrada, mas faz o

52

roteamento do resultado para um banco de dados que é acessado por muitos elementos. Este

sistema seria uma mistura dos estilos duto-e-filtro e dados-compartilhados. A documentação

para este sistema incluiria: (a) uma visão duto-e-filtro que mostraria uma parte do sistema; e

(b) uma visão dados-compartilhados que mostraria a outra parte. Em um caso como este, um

ou mais elementos podem ocorrer em ambas as visões e podem ter propriedades de ambos os

tipos de elementos. (Por outro lado, as duas partes do sistema poderiam não se comunicar uma

com a outra.) Estes elementos pontes fornecem a continuidade de entendimento de uma visão

para a seguinte: têm múltiplas interfaces, cada qual provendo os mecanismos para permitir os

elementos trabalharem com outros elementos em cada uma das visões à qual pertence.

Um elemento, sendo uma parte em um estilo, pode ele próprio ser composto de

elementos arranjados em outro estilo. Por exemplo, um servidor em um sistema cliente-

servidor pode (transparente para outros servidores ou para seus próprios clientes) ser

implementado usando um estilo duto-e-filtro. A documentação para este sistema incluiria uma

visão cliente-servidor mostrando o sistema global, assim como uma visão duto-e-filtro

documentando esse servidor.

A escolha de estilos depende apenas dos usos para os quais o grupo de stakeholders

pretende incluir na documentação. Por exemplo, se o estilo dados-compartilhados oferecer

todas as ferramentas de análise necessárias, ele deve ser escolhido ao invés das outras duas

opções. Se for necessária uma perspectiva propiciada por mais de um estilo é possível

documentar as visões correspondentes separadamente, ou combiná-las em uma única visão

que é, grosso modo, a união daquilo que as visões separadas seriam.

Todos os três casos evidenciam a necessidade de documentar diferentes partes de um

sistema usando diferentes visões. Isto é, uma visão não necessita mostrar o sistema inteiro.

Como uma regra, um elemento se apresenta apenas uma vez em uma visão de módulo,

enquanto um componente correspondente pode ocorrer muitas vezes em uma visão C&C.

Alguns estilos são aplicáveis a qualquer sistema de software, ex.: decomposição, usos,

implantação, e atribuição de trabalho, por exemplo; mas outros estilos ocorrem apenas em

sistemas nos quais eles foram explicitamente escolhidos e projetados pelo arquiteto: camadas,

comunicação-processos, cliente-servidor, etc.

Em relação à UML, pode-se dizer que essa linguagem oferece notações gráficas para

quase tudo; mas resta-lhe, ainda, prover um conjunto de ferramentas para análise, verificação

de consistência, ou outro meios de conectar, automaticamente, a informação em nível

arquitetural expressa em UML com o código do sistema.

53

4 – Linguagens de Descrição de Arquiteturas

4.1 Introdução As Linguagens de Descrição de Arquiteturas (ADLs – Architecture Description

Languages) têm suas raízes nas Linguagens de Interconexão de Módulos (MILs – Module

Interconnecting Languages), em cuja proposta original (DEREMER; KRON, 1975) os

autores distinguem a atividade de escrever pequenos programas da atividade de escrever

grandes programas, considerando os grandes programas como sistemas consistindo de muitos

programas pequenos (módulos), possivelmente escritos por diferentes pessoas.

DeRemer e Kron (1975) argumentam que a estruturação de uma vasta coleção de

módulos para formar um “sistema” é uma atividade intelectual essencialmente distinta da

atividade de construção de módulos individuais (uma questão de caráter cognitivo): os autores

distinguem a atividade de “programming-in-the-large” da atividade de “programming-in-the-

small”, sustentando, por conseguinte, que linguagens essencialmente distintas devem ser

usadas para essas duas atividades: uma MIL é adequada para a descrição da estrutura do

sistema, necessária para apoiar a atividade de programming-in-the-large.

Inicialmente, as arquiteturas eram amplamente representadas por desenhos na forma

de círculos-e-linhas nos quais a natureza dos componentes, suas propriedades, a semântica das

conexões e o comportamento do sistema eram vagamente definidos. Tais figuras, usualmente,

falham quando tentam responder questões como as levantadas em (CLEMENTS, 1996):

• Quais são os componentes? Eles são módulos que existem apenas em tempo de design?

Eles são tarefas ou processos em thread a partir de diferentes módulos, montados em

tempo de compilação, e formam unidades em tempo de execução? O que os componentes

fazem? Como eles se comportam?

• O que significam as conexões? Elas significam “enviar dados para”, “enviar controle

para”, “chamadas”, “é uma parte de”, alguma combinação disso, ou alguma outra coisa?

Quais são os mecanismos usados para preencher estes relacionamentos?

O restante deste capítulo encontra-se organizado como segue. Na Seção 4.2 estão

listadas as principais ADLs encontradas na literatura. Na Seção 4.3 são introduzidos os

conceitos relevantes acerca de ADLs. Na Seção 4.4 são listadas e explicadas as características

de ADLs apresentadas pelos principais pesquisadores da área. Na Seção 4.5 apresenta-se o

clássico framework conceitual sobre ADLs proposto por Medvidovic e Taylor (2000). Na

Seção 4.6 são apresentas algumas considerações relacionadas ao conteúdo deste capítulo.

54

4.2 Principais ADLs Várias ADLs foram propostas, tanto dentro de um domínio particular quanto

linguagens de modelagem de arquitetura de propósito geral. Em um trabalho bastante

elucidativo, que irradia luz sobre a área de ADLs, os autores tratam das seguintes linguagens

comumente referenciadas como ADLs (MEDVIDOVIC; TAYLOR, 2000):

• Aesop: explora propriedades de estilos (GARLAN; ALLEN, OCKERBLOON, 1994);

• ArTek: (TERRY et al., 1995);

• C27: explora o poder de um dado estilo baseado em eventos (MEDVIDOVIC et al., 1996);

• Darwin: design e especificação de sistemas distribuídos dinâmicos (MAGEE et al., 1995);

• LILEANNA: linguagem parametrizada (TRACZ, 1993);

• MetaH: controle de aviação em tempo real (BLINN; VESTAL, 1993);

• Rapide: simulação e análise de comportamento dinâmico (LUCKHAM et al., 1995);

• SADL: refinamento de arquiteturas (MORICONI; QIAN; RIEMENSCHNEIDER, 1995);

• UniCon: conjunto de conectores e estilos, e compilação para código (SHAW et al., 1995);

• Weaves: explora a análise (GORLICK; RAZOUCK, 1991); e

• Wright: explora a interação de componentes (ALLEN; GARLAN, 1997).

Além das ADLs listadas acima, há a ACME (GARLAN; MONROE; WILE, 1997), que,

apesar de não ser considerada estritamente como uma ADL (MEDVIDOVIC; TAYLOR,

2000), ela contém várias características do tipo ADL. É uma linguagem de intercâmbio de

arquiteturas cuja intenção é dar suporte ao mapeamento de especificações arquiteturais entre

diferentes ADLs e, conseqüentemente, possibilitar a integração de ferramentas de suporte por

intermédio de ADLs. A ACME foi projetada para considerar os conceitos essenciais comuns a

diferentes ADLs e permitir extensões para incluir outros elementos.

Os resultados de uma comparação realizada por Medvidovic e Taylor (2000)

encontram-se sintetizados em tabelas no Anexo 1 deste texto, enquanto que os resultados

alcançados pelo survey de Clements (1996) estão disponibilizadas no Anexo 2.

4.3 Conceito Com o objetivo de apoiar o desenvolvimento baseado em arquitetura, são necessárias

notações de modelagem formal e análise formal, e ferramentas de desenvolvimento que

operem sobre as especificações arquiteturais. Como resposta a esta necessidade, foram

propostas as ADLs e os conjuntos de ferramentas que as acompanham.

7 O nome completo da ADL C2 é “C2SADEL”. Para distingui-la da SADL, a qual resultou de um projeto não relacionado, a C2SADEL é comumente referenciada na literatura simplesmente como “C2”.

55

Vestal (1993) define, informalmente, que “uma ADL para aplicações de software

concentra-se na estrutura de alto nível da aplicação global ao invés de os detalhes de

implementação de algum módulo fonte específico”. Nas palavras de Clements (1996), no

entanto, “as linguagens de descrição de arquitetura são linguagens formais que podem ser

usadas para representar a arquitetura de um sistema de software”.

As ADLs provêem uma sintaxe concreta e um framework conceitual para a

caracterização de arquiteturas (GARLAN; MONROE; WILE, 1997). O framework conceitual

tipicamente reflete as características do domínio para o qual a ADL foi planejada e/ou o estilo

arquitetural. O framework tipicamente inclui a teoria semântica subjacente da ADL – ex.: CSP

(HOARE, 1978), Redes de Petri, máquinas de estado finito.

Medvidovic e Taylor (2000) culminam com uma definição concisa sobre ADL, a qual

é adotada como a definição padrão no âmbito deste presente trabalho:

“Uma ADL deve explicitamente modelar componentes, conectores, e suas

configurações; além disso, para ser verdadeiramente usável e útil, ela deve prover

uma ferramenta de suporte ao desenvolvimento baseado em arquitetura e suporte à

evolução.”

4.4 Características de ADLs

DeRemer e Kron (1975) concluem sua proposta fazendo as seguintes alegações,

relacionadas a uma MIL: (i) incorpora uma metodologia para software reusável8; (ii) provê

muitas formas necessárias de abstração, expressão, e verificação, frente à atividade de

programming-in-the-large; (iii) melhora os efeitos de confiabilidade que são ganhos por

outros métodos: estilos de gerenciamento (top-down, modular, e programação estruturada),

abstração de dados, e ocultação de informação; e (iv) a confiabilidade é aprimorada durante o

design do sistema, a fase de programação real, teste, manutenção e modificação do sistema.

Em um trabalho fundamental sobre as ADLs, Shaw et al. (1995) listam as

propriedades essenciais que as ADLs devem exibir:

• capacidade para representar componentes (primitivos ou compostos) paralelamente às

declarações de propriedades, interfaces e implementações;

• capacidade para representar conectores, paralelamente com protocolos, declarações de

propriedades, e implementações;

• abstração e encapsulamento;

8 Os autores já anteviam o Desenvolvimento de Software Baseando em Componentes.

56

• tipos e verificação de tipos;

• capacidade para acomodar ferramentas de análise de forma aberta.

Por sua vez, Luckham e Vera (1995) listam os seguintes requisitos para uma ADL:

• abstração de componentes;

• abstração de comunicação;

• integridade de comunicação (limitando a comunicação àqueles componentes

arquiteturalmente conectados um ao outro);

• habilidade para modelar arquiteturas dinâmicas;

• habilidade para raciocinar sobre causalidade e tempo;

• relatividade, o mapeamento de comportamentos (possivelmente diferentes) a arquiteturas,

como um primeiro passo rumo à verificação da consistência.

Após realizar um levantamento sobre uma ampla seleção de linguagens, Clements

(1996) concluiu seu trabalho com uma lista de requisitos para que uma linguagem possa ser

considerada uma ADL, quais sejam:

• dar suporte às tarefas de criação, refinamento, e validação de arquitetura; incorporar

regras sobre o que constitui uma arquitetura completa ou consistente.

• prover a capacidade de representar a maioria dos estilos arquiteturais comuns enumerados

em (GARLAN; SHAW, 1993).

• ter a capacidade de prover visões do sistema que expressam informações arquiteturais,

mas ao mesmo tempo suprimir informações não arquiteturais.

• se for possível expressar informações em nível de implementação, então deve dar suporte

à especificação de famílias de implementação que satisfazem uma arquitetura comum.

• dar suporte à capacidade analítica, baseada em informação de nível arquitetural, ou dar

suporte à capacidade para geração rápida de implementações de protótipos.

Diversos pesquisadores tentaram esclarecer essas questões, seja por meio de um

levantamento daquilo que eles consideraram como sendo as ADLs existentes (CLEMENTS,

1996) (KOGUT; CLEMENTS, 1994) (VESTAL, 1993), ou pela listagem dos requisitos

essenciais para uma ADL (LUCKHAM; VERA, 1995) (SHAW et al., 1995) (SHAW;

GARLAN, 1994) (SHAW; GARLAN, 1995) e (MEDVIDOVIC; ROSENBLUM, 1997).

4.5 Um Framework Conceitual para ADLs Medvidovic e Taylor (2000) realizaram um estudo sobre os conjuntos de

características e requisitos de uma ADL, e usaram os resultados desse estudo como um guia

57

na formulação do seu framework para classificação e comparação de ADLs. Os autores

estudaram as características de ADLs individuais, dando origem a uma proposta de taxonomia

que reflete as características da maioria das ADLs até então existentes. Conforme o

framework representado na Quadro 4.1, os blocos de construção de uma descrição arquitetural

são os seguintes: (1) componentes, (2) conectores, e (3) configurações arquiteturais.9 Uma

ADL deve prover os meios para sua especificação, explicitamente; isto possibilita decidir se

uma determinada notação pode ser de fato considerada uma ADL.

Quadro 4.1 – Framework10 de classificação e comparação de ADLs – Fonte: (Medvidovic; Taylor, 2000)

ADL Características de Modelagem de Arquitetura Componentes

Interface

Tipos Semântica Restrições Evolução Propriedades Não-funcionais Conectores

Interface Tipos Semântica Restrições Evolução Propriedades Não-funcionais Configurações Arquiteturais

Capacidade de Compreensão Capacidade de Composição Refinamento e Rastreamento Heterogeneidade Escalabilidade Evolução Dinamismo Restrições Propriedades Não-funcionais Ferramentas de Suporte Especificação Ativa Múltiplas Visões Análise Refinamento Geração de Implementação Dinamismo

Medvidovic e Taylor (2000) afirmam que, a fim de inferir informações sobre uma

arquitetura, no mínimo, as interfaces dos componentes constituintes devem ser modeladas.

Sem esta informação, uma descrição arquitetural torna-se, similar a um diagrama de “caixas e

linhas” sem semântica subjacente explícita. Vários outros aspectos de componentes,

conectores e configurações são desejáveis, mas não essenciais: seus benefícios têm sido

reconhecidos e demonstrados no contexto do domínio de um problema ou de um estilo, mas

sua ausência não significa que uma dada linguagem não seja uma ADL.

9 “Configurações arquiteturais” poderão ser referidas simplesmente como “configurações” ou “topologias”. 10 As características de modelagem essenciais estão em negrito.

58

Um conjunto de ferramentas torna uma ADL mais usável e útil, ainda que a

adequação de uma dada linguagem para a modelagem de arquiteturas de software seja

independente de quais tipos de ferramenta de suporte ela provê.

4.5.1 Modelagem dos Componentes

Um componente em uma arquitetura é, por excelência, uma unidade de computação ou

um armazém de dados e, conseqüentemente, os componentes são “o local da computação e do

estado” (SHAW et al., 1995). Os componentes podem ser tão pequenos quanto um único

procedimento ou tão grandes quanto uma aplicação inteira. Cada componente pode requerer

seus próprios dados ou espaço de execução, ou pode compartilhá-los com outros

componentes. As interfaces explícitas de componentes são características necessárias das

ADLs. Para fins de comparação, as características adicionais são (MEDVIDOVIC; TAYLOR,

2000): tipos, semântica, restrições, evolução, e propriedades não-funcionais.

• Interface: É um conjunto de pontos de interação entre um componente e o mundo

externo. A interface especifica os serviços (mensagens, operações, e variáveis) que um

componente provê. Para apoiar o raciocínio sobre um componente e a arquitetura, podem

ser fornecidos recursos para a especificação das necessidades dos componentes (serviços

requeridos de outros componentes na arquitetura). Portanto, uma interface define os

compromissos computacionais que um componente pode fazer e restrições sobre seu uso.

• Tipos: São abstrações que encapsulam as funcionalidades em blocos reusáveis. Um tipo

de componente pode ser instanciado múltiplas vezes em uma única arquitetura ou pode ser

parametrizado e reusado em várias arquiteturas.

• Semântica: É definida como um modelo de alto nível do comportamento do componente.

Tal modelo é necessário para executar análise, impor restrições arquiteturais, e garantir

mapeamentos consistentes de arquiteturas de um nível de abstração para outro.

• Restrições: Devem ser especificadas restrições sobre os componentes a fim de: garantir a

fidelidade aos usos pretendidos; forçar os limites de uso; e estabelecer dependências entre

as partes internas de um componente.

• Evolução: Pode ser informalmente definida como a modificação de suas propriedades,

ex.: interface, comportamento, ou implementação. As ADLs podem garantir que a

evolução ocorra de um modo sistemático, empregando a sub-tipificação (hierarquização)

de tipos e refinamento de características de componentes.

• Propriedades Não Funcionais: É necessária a especificação preliminar de propriedades

no nível arquitetural, tais como confiabilidade, segurança, desempenho, e portabilidade, a

59

fim de: habilitar a simulação do comportamento em tempo de execução, executar a

análise, impor as restrições, mapear as implementações de componentes aos

processadores, e auxiliar o gerenciamento de projeto.

4.5.2 Modelagem dos Conectores

Os conectores são blocos de construção arquiteturais, que ensejam a modelagem das

interações entre componentes e a modelagem das regras que governam essas interações. Os

conectores podem não corresponder às unidades de compilação em um sistema

implementado: podem ser implementados como dispositivos de roteamento de mensagens

compiláveis separadamente, mas podem também manifestarem-se como: variáveis

compartilhadas, entradas em tabelas, estruturas de dados dinâmicas, seqüências de chamadas

de procedimentos embutidos no código, parâmetros de inicialização, protocolos cliente-

servidor, pipes, links SQL entre uma base de dados e uma aplicação, e assim por diante

(GARLAN; MONROE; WILE, 1997) (SHAW et al., 1995). Conforme (MEDVIDOVIC;

TAYLOR, 2000), os conectores são caracterizados por: interfaces, tipos, semântica,

restrições, evolução, e propriedades não funcionais11:

• Interface: É um conjunto de pontos de interação entre o conector e os componentes e

outros conectores vinculados a ele. As interfaces possibilitam a conectividade adequada

de componentes e suas interações em uma arquitetura e, por meio disso, o raciocínio sobre

as configurações arquiteturais.

• Tipos: São abstrações que encapsulam a comunicação, coordenação, e decisões de

mediação de componentes (interações em nível arquitetural podem ser caracterizadas por

protocolos complexos). Tornar esses protocolos reusáveis requer que as ADLs modelem

conectores como tipos: na forma de um sistema de tipos extensível, definido em termos de

protocolos de interação, ou como tipos enumerados built-in, baseados em mecanismos de

implementação particulares.

• Semântica: É definida como um modelo de alto nível do comportamento de um conector,

e acarreta especificações de protocolos de interação (independentes da computação). As

ADLs podem dar suporte à modelagem da semântica de conectores a fim de possibilitar: a

análise da interação de componentes; o refinamento consistente de arquiteturas através dos

níveis de abstração; e a imposição de restrições de interconexão e de comunicação.

11 Apesar de as categorias de comparação para componentes e conectores serem idênticas, segundo Medvidovic e Taylor (2000), elas foram derivadas e refinadas independentemente umas das outras.

60

• Restrições: Garantem a fidelidade aos protocolos de interação planejados, estabelecem

dependências intra-conectores, e impõem limites de uso. Ex.: a restrição do número de

componentes que interagem por meio do conector.

• Evolução: É definida como a modificação de suas propriedades, ex.: interface, semântica,

ou restrições sobre ambos. As ADLs podem acomodar essa evolução por meio da

modificação ou refinamento de conectores usando técnicas tais como filtragem de

informações incrementais, subtipificação, e refinamento.

• Propriedades Não Funcionais: Representam requisitos (adicionais) para a correta

implementação do conector. Ex.: simulação de comportamento dinâmico; análise de

conectores; imposição de restrições; e seleção de conectores off-the-shelf12 (OTS)

adequados (ex.: barramento de mensagens) e seus mapeamentos a processadores.

4.5.3 Modelagem das Configurações Arquiteturais

As configurações arquiteturais, ou topologias, são grafos conectados de componentes

e conectores que descrevem a estrutura arquitetural. Esta informação é necessária para

determinar se os componentes adequados estão conectados, se suas interfaces são

equivalentes, se os conectores possibilitam comunicação adequada, e se suas semânticas

combinadas resultam em comportamento desejado (MEDVIDOVIC; TAYLOR, 2000).

Os aspectos característicos no nível de configurações arquiteturais caem em três

categorias genéricas (MEDVIDOVIC; TAYLOR, 2000): (1) qualidades da descrição da

configuração: capacidade de compreensão, composição, refinamento e rastreabilidade, e

heterogeneidade; (2) qualidades do sistema descrito: heterogeneidade, escalabilidade,

capacidade de evolução, e dinamismo; (3) propriedades do sistema descrito: dinamismo,

restrições, e propriedades não funcionais.13

Vê-se que as três categorias não são completamente ortogonais: heterogeneidade e

dinamismo aparecem em duas categorias. Heterogeneidade pode ser manifestada nos vários

formalismos empregados nas descrições de configuração, e em múltiplas LPs. As

características das configurações são (MEDVIDOVIC; TAYLOR, 2000):

• Especificações Compreensíveis: As ADLs devem modelar a informação estrutural

(topológica) com sintaxe simples e compreensível, pois um dos papéis da arquitetura é

servir como um canal de comunicação preliminar para diferentes stakeholders em um

projeto e facilitar o entendimento de sistemas (ou famílias) em um alto nível de abstração. 12 Previamente desenvolvido, sem ter sido necessariamente encomendado. 13 O termo “qualidade” é usado de maneira convencional, independente da aplicação. O termo “propriedade” refere-se às características de uma aplicação introduzidas para tratar requisitos específicos.

61

• Composição Hierárquica: Mecanismo que permite às ADLs descreverem softwares em

diferentes níveis de detalhes. Há situações nas quais uma arquitetura torna-se um único

componente de uma arquitetura em um nível de abstração superior.

• Refinamento e Rastreabilidade: As ADLs também podem possibilitar o refinamento

consistente e correto de arquiteturas em sistemas executáveis e permitir a rastreabilidade

de alterações ao longo de diferentes níveis de refinamento arquitetural.

• Heterogeneidade: É salutar que as ADLs sejam extensíveis, isto é, que forneçam recursos

para a especificação e desenvolvimento arquitetural, preferencialmente, com componentes

e conectores pré-existentes de granularidade variada, possivelmente especificados em

diferentes linguagens de modelagem formal e implementados em diferentes LPs.

• Escalabilidade: As ADLs podem apoiar diretamente a especificação e o desenvolvimento

de sistemas de grande porte que são plausíveis de crescimento no futuro, por meio de

recursos que possibilitem expressar as abstrações necessárias para lidar com as questões

de complexidade e de tamanho de software.

• Capacidade de Evolução: As ADLs necessitam aumentar o suporte à evolução no nível

de componentes e conectores com recursos para sua adição incremental, remoção,

substituição, e re-conexão em uma configuração. A evolução refere-se às alterações

estáticas (em tempo de desenvolvimento) em uma arquitetura (e ao sistema resultante).

• Dinamismo: O dinamismo refere-se à modificação da arquitetura e realização destas

modificações enquanto o sistema está sendo executado. O suporte ao dinamismo é

importante em sistemas de missão crítica que requerem alto grau de confiabilidade, tais

como controle de tráfego aéreo, comutação de telefone, sistemas de informação pública de

alta disponibilidade (OREISY; MEDVIDOVIC; TAYLOR, 1998). Para tanto, as ADLs

necessitam prover características específicas para modelagem de alterações dinâmicas e

técnicas para sua efetivação no sistema em tempo de execução.

• Restrições: As restrições que representam dependências em uma configuração

complementam as restrições específicas a componentes e conectores individuais. Muitas

restrições globais são derivadas, ou dependem diretamente, de restrições locais. Ex.: as

restrições sobre as configurações válidas podem ser expressas como restrições de

interações entre componentes e conectores constituintes.

• Propriedades Não Funcionais: São necessárias em nível de configuração para selecionar

os componentes e conectores adequados, executar análise, impor restrições, mapear blocos

de construção arquiteturais para processadores, e auxiliar no gerenciamento de projetos.

62

4.5.4 Ferramentas de Suporte para Descrição Arquitetural

A motivação para o desenvolvimento de linguagens formais para descrição

arquitetural é que o seu formalismo lhes confere adequação para o raciocínio e manipulação

por meio de ferramentas de software. Um conjunto de ferramentas de suporte que acompanha

uma ADL não é, estritamente falando, parte da linguagem. Entretanto, a utilidade de uma

ADL está diretamente relacionada aos tipos de ferramentas que ela provê para dar suporte ao

design arquitetural, à análise, à evolução, e à geração de sistemas executáveis.

Os pesquisadores na área de ADLs vêm tentando identificar os elementos que

compreendem um toolkit canônico (conjunto de ferramentas). Diversas categorias genéricas

que têm emergido refletem os tipos de ferramentas de suporte, comumente, fornecidas pelas

abordagens arquiteturais existentes: especificação ativa, múltiplas visões, análise,

refinamento, geração da implementação, e dinamismo (MEDVIDOVIC; TAYLOR, 2000).

• Especificação Ativa: Fornecer suporte à especificação por meio da redução das possíveis

opções de design baseadas no estado atual da arquitetura. Podem ser pró-ativas, sugerindo

cursos de ação ou proibindo opções de design que podem resultar em estados de design

indesejados, ou reativas, informando o arquiteto quando tais estados são atingidos durante

o design. Elas podem dar seus feedbacks de modo intrusivo, forçando o arquiteto a tomar

conhecimento antes de continuar, ou não intrusivo, permitindo ao arquiteto visualizar o

feedback conforme sua conveniência.

• Múltiplas Visões: Fornecer a visão mais apropriada para um determinado stakeholder e

garantir a consistência inter-visões são as questões chave. Os clientes podem ficar

satisfeitos com uma apresentação gráfica, enquanto os desenvolvedores podem desejar

especificações mais formais de componentes e conectores, ao passo que os gerentes

podem requerer uma visão do processo de desenvolvimento do sistema correspondente.

• Análise: A capacidade de avaliar as propriedades de sistemas grandes, distribuídos, e

concorrentes, em um nível arquitetural, pode diminuir substancialmente o custo dos erros.

• Refinamento: A redefinição de descrições arquiteturais é uma tarefa complexa cuja

corretude e consistência não podem ser sempre garantidas por meio de provas formais,

mas as ferramentas de suporte adequadas podem aumentar a confiabilidade a este respeito

(MORICONI; QIAN; RIEMENSCHNEIDER, 1995).

• Geração da Implementação: A meta suprema de qualquer empreendimento de design e

modelagem de software é produzir o sistema executável. A realização manual dessa

atividade pode resultar em muitos problemas de consistência e rastreabilidade entre uma

63

arquitetura e sua implementação. Portanto é desejável, senão imperativo, a um conjunto de

ferramentas de ADL prover ferramentas para assistir a produção do código fonte.

• Dinamismo: Medvidovic e Taylor (2000) têm argumentado sobre a necessidade de

modelar alterações dinâmicas no nível arquitetural. As ferramentas de software são

necessárias para: analisar a arquitetura modificada e garantir suas propriedades desejáveis;

mapear corretamente as alterações expressas em termos de construtores arquiteturais para

os módulos de implementação; garantir a execução contínua dos subsistemas vitais da

aplicação e a preservação de estado durante a modificação; a análise e teste da aplicação

modificada enquanto ela está sendo executada.

4.6 Considerações Uma ADL é, por excelência, uma linguagem de alto nível que enseja, no contexto do

sistema de software, a modelagem de componentes e conectores, assim como suas

configurações. As ADLs têm sido reconhecidas como uma importante ferramenta para dar

suporte ao raciocínio sistemático sobre componentes de sistemas e as conexões entre eles no

princípio do processo de desenvolvimento.

As ADLs resultam de uma abordagem lingüística à representação formal de

arquiteturas e tratam as deficiências das representações informais. Além disso, há ADLs que

permitem análises e testes antecipados sobre a exeqüibilidade das decisões de design.

A principal contribuição do trabalho proposto por Medvidovic e Taylor (2000) é

justamente um framework de definição e classificação. A definição fornece um teste simples

para ADLs, o qual reflete o consenso da comunidade sobre o que é essencial na modelagem

de uma arquitetura: uma descrição arquitetural difere de outras notações pelo seu foco

explícito sobre componentes, conectores e configurações arquiteturais.

A comparação de ADLs, realizada por Medvidovic e Taylor (2000), destacou várias

áreas onde elas fornecem extensivo suporte, em termos de capacidades de modelagem de

arquitetura e ferramenta de suporte. Conforme mostram as tabelas contidas no Anexo 1, várias

linguagens usam notações formais capazes de modelar a semântica de componentes e

conectores. Elas também fornecem uma ampla gama de ferramentas de visualização e análise

de arquiteturas. O levantamento de Medvidovic e Taylor (2000)apontou áreas seriamente

carentes de ADLs. Poucas apóiam a especificação de propriedades não funcionais, ainda que

tais propriedades possam ser essenciais à implementação e ao gerenciamento do processo de

desenvolvimento. O refinamento arquitetural e a especificação de restrições também

permanecem inexplorados.

64

Na literatura há controvérsias no que concerne ao nível de suporte que uma ADL deve

prover aos desenvolvedores. Alguns pesquisadores sustentam que o papel primário das

descrições arquiteturais é auxiliar a compreensão e a comunicação sobre o sistema de

software. Como tal, uma ADL deve ter uma sintaxe simples, compreensível, e possivelmente

gráfica, uma semântica bem entendida, mas não necessariamente definida formalmente, e os

tipos de ferramentas que auxiliam a visualização, a compreensão e a análise simples das

descrições arquiteturais, ex.: a Argo (ROBBINS; REDMILES; ROSENBLUM, 1997).

Em uma posição extremamente oposta, a tendência tem sido prover a sintaxe e a

semântica formal de ADLs, poderosas ferramentas de análise, verificadores de modelos,

analisadores sintáticos, compiladores, ferramentas de síntese de código, ferramentas de

suporte em tempo de execução, etc., ex.: padrões de refinamento de arquitetura da SADL

(MORICONI; QIAN; RIEMENSCHNEIDER, 1995), uso do π-Calculus para formalizar a

semântica arquitetural da Darwin (MAGEE; KRAMER, 1996), ou o analisador sintático e o

compilador da UniCon (SHAW et al., 1995). Ambas as perspectivas têm o seu mérito, o que

faz com que os pesquisadores geralmente adotem uma ou outra visão extrema.

As categorias identificadas no framework proposto em (MEDVIDOVIC; TAYLOR,

2000) são ortogonais ao escopo de aplicabilidade de uma ADL. Como um modelo de sistema

em um alto nível de abstração, uma ADL é planejada para prover uma representação parcial

do sistema. Os tipos de informações focalizados por uma ADL podem ser as características de

um domínio de aplicação, um estilo arquitetural, ou um conjunto específico de propriedades

(ex.: distribuição, concorrência e segurança).

Em combinação com modelos de componentes e conectores, as descrições de

configurações possibilitam a avaliação de aspectos concorrentes e distribuídos de uma

arquitetura (ex.: possíveis impasses, desempenho, confiabilidade e segurança). As descrições

de configurações também possibilitam a análise da arquitetura em relação à fidelidade às

heurísticas de design (ex.: links de comunicação direta entre componentes dificultam a

capacidade de evolução de uma arquitetura), e restrições de estilos arquiteturais (ex.: links de

comunicação direta entre componentes são proibidos).

O dinamismo antecipado é uma propriedade na qual o sistema pode ser arquitetado

especificamente para acomodar a alteração dinâmica (esperada); o dinamismo não-antecipado

é a qualidade que se refere à adequabilidade genérica do sistema para alteração dinâmica.

As ferramentas de design arquitetural de especificação ativa orientam o design e

podem reduzir significativamente a carga cognitiva exigida do arquiteto de software.

65

5 – Desenvolvimento de Software Orientado a Aspectos

5.1 Introdução

Não obstante o paradigma orientado a objetos tenha se consolidado como o estado da

arte para o desenvolvimento de sistemas de software, suas abstrações e mecanismos de

composição possuem limitações para separar e compor alguns interesses relevantes em um

sistema de software. Conseqüentemente, muitos interesses importantes espalham-se por vários

módulos e misturam-se com outros interesses de um sistema de maneira intrusiva,

dificultando a reutilização e manutenção de seus componentes. Alguns exemplos clássicos

destes interesses são: realização de log (logging), tratamento de erros, controle de

concorrência, segurança e persistência (GARCIA et al., 2004).

O Desenvolvimento de Software Orientado a Aspectos (DSOA) é um paradigma de

desenvolvimento fundamentado nos conceitos da Programação Orientada a Aspectos (POA).

A POA propõe um tipo de abstração – denominado aspecto – e mecanismos de composição

que permitem a descrição modular e a composição de interesses que, geralmente, encontram-

se espalhados e misturados – a saber, os interesses transversais – em vários pontos de um

sistema de software orientado a objeto.

O DSOA relaciona-se com campos tradicionais e emergentes da Engenharia de

Software, tornando-se, conseqüentemente, um tema de real interesse para pesquisadores de

outras áreas, tais como engenharia de requisitos, métodos formais, engenharia de software

baseada em componentes, manutenção e reutilização de software, teste de software e

engenharia de software empírica (GARCIA et al., 2004).

Uma descrição bastante abrangente das tecnologias do DSOA pode ser encontrada em

(AOSD, 2007). O restante deste capítulo encontra-se organizado como segue. Na Seção 5.2

faz-se uma breve introdução sobre a Programação Orientada a Aspectos. Na Seção 5.3 são

apresentadas as principais abordagens arquiteturais orientadas a aspectos. Na Seção 5.4 é

mostrada uma análise das principais abordagens de aspectos preliminares. Na Seção 5.5 são

apresentadas algumas das principais ADLs Orientadas a Aspectos. As conclusões referentes a

este capítulo estão expostas na Seção 5.6.

5.2 Programação Orientada a Aspectos

Pelo fato de o modelo de objetos subjacente prover uma melhor adequação aos

problemas do mundo real, a Programação Orientada a Objetos (POO) tem sido utilizada como

uma tecnologia que realmente auxilia a engenharia de software. Porém, segundo Kiczales et

66

al. (1997), são encontrados muitos problemas de programação onde as técnicas de POO não

são suficientes para capturar com clareza todas as decisões importantes de design que o

programa deve implementar. Há alguns problemas de programação que não se encaixam na

abordagem POO nem na abordagem procedimental que ela intentou substituiu.

Kiczales et al. (1997) apresentam a seguinte argumentação:

“quando uma linguagem de programação provê abstração e mecanismos de

composição que dão suporte, de forma clara, aos tipos de unidades do sistema que um

processo de design quebra, é possível dizer que o processo de design e a linguagem de

programação, juntos, trabalham de modo eficiente”.

A noção de aspecto – do latim aspectu – é multímoda. Apresenta-se prima face, como

um problema vocabular e conceitual. Pode ser estudada como um termo (expressão), um

conceito ou uma entidade. Assim, tem-se a definição semântica de aspecto e uma definição

concreta de aspecto. Mas, entendido como algo concreto, exige distinguir a espécie de

realidade: entidade, relacionamento ou propriedade de uma entidade.

Os aspectos foram introduzidos por (KICZALES et al., 1997) e são definidos como as

propriedades do sistema que tendem a entrecortar (cortar transversalmente) componentes

funcionais, resultando em sistemas mais acoplados (código entrelaçado). As tecnologias do

DSOA modelam componentes e aspectos como duas entidades separadas onde os aspectos

estão automaticamente combinados no comportamento funcional do sistema a fim de produzir

o sistema global.

Dois termos importantes devem ser definidos com mais precisão a respeito de um

sistema e de sua implementação usando-se uma linguagem PG; uma propriedade que deve ser

implementada pode ser (KICZALES et al., 1997):

“Um componente, se ela pode ser encapsulada de modo claro14

em um

procedimento generalizado (i.e. objeto, método, procedimento, API). Por

claro, nós queremos dizer bem localizado, e facilmente acessado e composto

quando necessário. Os componentes tendem a ser unidades da decomposição

funcional do sistema, tais como filtros de imagem, contas bancárias e widgets

de GUI.”

ou

14 Legível, organizado.

67

“Um aspecto, se ela não pode ser encapsulada de modo claro em um

procedimento generalizado. Os aspectos tendem a não ser unidades da

decomposição funcional do sistema, mas serem propriedades que afetam o

desempenho ou semântica dos componentes de modo sistemático. Exemplos de

aspectos incluem padrões de acesso à memória e sincronização de objetos

concorrentes.”

Kiczales et al. (1997) exprimem, claramente, a meta da POA nos seguintes termos:

“Oferecer suporte ao programador para a separação clara de componentes e

aspectos,15

fornecendo mecanismos que possibilitam abstraí-los e compô-los

para se produzir o sistema global”.

Para exemplificar como os aspectos cortam transversalmente os componentes, é

apresentada a Tabela 5.1, na qual se encontram exemplos de aspectos e componentes. Para

cada exemplo são listados: uma aplicação; um tipo de linguagem que faria um bom trabalho

na captura da estrutura de componentes da aplicação; uma estrutura plausível de componentes

para a aplicação, se programada usando-se esse tipo de linguagem; e os aspectos que

cortariam transversalmente essa estrutura de componente.

Tabela 5.1 - Exemplos de aspectos e componentes – Fonte: Adaptado de (KICZALES et al., 1997)

Aplicação Linguagem Componentes Aspectos Processamento de imagem

Procedimental Filtros Fusão de laços, Compartilhamento de resultados, Alocação de memória em tempo de compilação.

Biblioteca digital

Orientada a objetos

Repositórios, Impressoras, Serviços.

Minimização de tráfego de rede, Restrições de sincronização, Manipulação de falhas.

Algoritmos de matrizes

Procedimental Operações de álgebra linear.

Representação de matrizes, Permutação, Erro de ponto flutuante.

Kiczales et al. (1997) sustentam que alguns aspectos são tão comuns que podem ser

facilmente imaginados sem uma referência a um domínio em particular, citando como

exemplo a manipulação de erros e falhas. Esses mesmos autores seguem defendendo que

muitas das questões relacionadas ao desempenho são aspectos, porque a otimização de

desempenho, muitas vezes, explora informações sobre o contexto de execução as quais se

encontram espalhadas pelos componentes.

15 Componentes entre si, aspectos entre si, e componente e aspectos.

68

5.3 Abordagens de Arquitetura de Software Orientada a Aspectos

Uma vez que os métodos de design arquitetural atuais não distinguem, explicitamente,

os interesses arquiteturais convencionais dos interesses arquiteturais que entrecortam

múltiplos componentes arquiteturais, há o risco de que potenciais aspectos possam ser

facilmente negligenciados durante o design arquitetural e continuem não solucionados nas

etapas subseqüentes (design e programação).

Semelhantemente à noção de aspecto no nível de programação, estes interesses são

transversais e denotam os chamados aspectos arquiteturais. Uma vez que a propriedade

transversal de aspectos arquiteturais é inerente, ela não pode ser refeita através da redefinição

da arquitetura de software usando-se abstrações arquiteturais convencionais.

Conseqüentemente, é necessário explicitar mecanismos para identificar, especificar e avaliar

aspectos no nível de design arquitetural (CHITCHYAN et al., 2005).

Chitchyan et al. (2005) discutem o estado da arte das abordagens arquiteturais

orientadas a aspectos sob uma perspectiva de tratamento de interesses transversais no nível

arquitetural. As abordagens são categorizadas como segue:

1. Abordagens para modelagem de arquitetura – incluem as abordagens para modelagem de

arquitetura, visual e textualmente.

2. Abordagens para o processo de design arquitetural – incluem as abordagens que

proporcionam um processo explícito e regras heurísticas para o design de arquiteturas.

3. Abordagens para avaliação de arquitetura – incluem as abordagens que focam

principalmente na análise da arquitetura em relação aos critérios de qualidade requeridos.

5.3.1 Abordagens para Modelagem Arquitetural

Framework Perspectival Concern-Space (PCS)

O framework PCS (KANDE, 2003) é uma técnica para a descrição de interesses de

múltiplas dimensões em uma visão arquitetural consistindo de um ou mais modelos e

diagramas. Uma perspectiva é uma “forma de visualização”, em um espaço multidimensional,

de interesses de software sob um ponto de vista específico. O PCS usa o conceito de

combinação de realizações dos frameworks conceituais: Multi Dimension Separation of

Concerns – MDSoC – (OSSHER; TARR, 2000) e (TARR et al., 2005); padrão IEEE-1471

(IEEE, 2000); e da UML (BOOCH; RUMBAUGH; JACOBSON; 2005).

Dynamic Aspect-Oriented Platform ADL (DAOP-ADL)

69

A DAOP-ADL (PINTO; FUENTES; TROYA, 2003) é uma linguagem de descrição

arquitetural, baseada em XML, para descrever a arquitetura de uma aplicação em termos de

um conjunto de componentes, um conjunto de aspectos e a interconexão entre eles. As

interconexões são estruturadas em dois tipos diferentes de restrições de composição:

1. regrasDeComposiçãoDeComponentes: descreve as regras para direcionar a composição

de componentes.

2. regrasDeAvaliaçãoDeAspectos: é o equivalente aos conjuntos de pontos de junção nas

LPs orientada a aspectos, e descreve as regras de combinação entre componentes e

aspectos.

O processo para o design de arquitetura baseado na DAOP-ADL é o seguinte: todos os

componentes e aspectos que podem ser instanciados em uma aplicação são descritos usando a

seção de descrição de componentes e aspectos da linguagem DAOP-ADL.

A ferramenta Component and Aspect Repository, usada para registrar aspectos e

componentes COTS, gera automaticamente a descrição de aspectos e componentes carregados

usando-se a sintaxe da linguagem DAOP-ADL. Na seqüência, é empregada a ferramenta

Aspect Specification and Validation, a qual possui a linguagem DAOP-ADL em seu back-end

e oferece suporte à descrição e validação da arquitetura de software da aplicação.

A DAOP-ADL é usada em conjunto com o CAM/DAOP. O CAM (Componet-Aspect

Model) é um modelo de design usado para projetar aplicações baseadas em componentes e

aspectos em UML. A DAOP, por outro lado, é uma plataforma baseada em componentes e

aspectos que carrega a descrição da arquitetura fornecida via especificação DAOP-ADL para

obter as informações necessárias à instanciação dos componentes e dos aspectos e para

executar a composição dinâmica de componentes em tempo de execução.

5.3.2 Abordagens para o Processo de Design Arquitetural

Aspect-Oriented Generative Approaches (AOGA)

Trata-se de uma abordagem centrada na arquitetura, inicialmente esboçada em

(GARCIA, 2001) e posteriormente estendida em (KULESZA; GARCIA; LUCENA, 2004-a),

com o propósito de dar suporte a desenvolvedores de sistemas multi-agentes (MAS - Multi

Agent Systems) com linguagens específicas de domínio, notações de modelagem, e

ferramentas de geração de código. A AOGA tem extensões definidas para modelos de

características (features) e uma nova linguagem específica de domínio Agent-DSL, além da

notação baseada na UML para expressar aspectos arquiteturais.

70

Esta abordagem cobre as seguintes fases do ciclo de vida: Análise e Especificação de

Domínio, Design e Implementação da Arquitetura, conforme ilustrado na Figura 5.1.

Análise e Especificação do Domínio

Especificação de aspectos do domínio

Especificação de propriedades dos agentes

Modelos de Características Estendido Agent-DSL

Design da Arquitetura

Arquitetura Orientada Aspectos

Notação UML

Implementação Frameworks + Componentes

Templates de Código

Gerador de Código

Implementação

Classes e Aspectos da Aplicação

Arquitetura Agente OA Gerada

Figura 5.1 – Fases do desenvolvimento apoiadas na AOGA – Fonte: (KULESZA; GARCIA; LUCENA, 2004-a).

A AOGA tem uma linguagem baseada em UML para especificação e comunicação de

arquiteturas de software orientadas a aspectos (Figura 5.2). Conforme mostra a Figura 5.2,

cada componente arquitetural tem uma ou mais interfaces; diferentes componentes podem

conceber a mesma interface. As interfaces são anexadas aos componentes arquiteturais e são

categorizados em dois grupos: interfaces normais (NI) e interfaces transversais (CI)

(CHAVEZ et al., 2005).

Figura 5.2 – Aspectos arquiteturais em interfaces transversais. Fonte: (KULESZA; GARCIA; LUCENA, 2004a).

Uma interface normal apenas fornece serviços para outros componentes enquanto

que uma interface transversal em um modelo arquitetural especifica quais componentes

arquiteturais um componente aspectual afeta. Um componente aspectual está em

71

conformidade com um conjunto de interfaces transversais. Uma interface de um aspecto

entrecorta os elementos internos de componentes arquiteturais ou entrecorta outras interfaces.

O primeiro caso significa que o aspecto arquitetural afeta, diretamente, a estrutura interna ou

o comportamento dinâmico do componente alvo. O segundo caso significa que o aspecto afeta

o comportamento definido pela interface transversal.

TranSAT

O TranSAT (BARAIS et al., 2004) é um framework para a especificação da evolução

do software que enfatiza a facilitação da evolução da arquitetura através dos princípios de

DSOA em um contexto arquitetural. Ele propõe a definição incremental da arquitetura do

software através da combinação (weaving) de um novo plano arquitetural dentro da

arquitetura de software. A especificação da arquitetura é transformada por meio da integração

de interesses dentro da arquitetura.

5.3.3 Abordagens para Avaliação Arquitetural

Aspectual Software Architecture Analysis Method (ASAAM)

O ASAAM (TEKINERDOGAN, 2004) tem como objetivo identificar e especificar,

explicitamente, aspectos arquiteturais nos estágios iniciais do ciclo de vida do software. Essa

abordagem, construída com base em métodos de análise arquitetural baseada em cenários

(KAZMAN et al., 1994), é considerada como uma abordagem complementar a tais métodos.

Os dois artefatos chave no ASAAM são cenários e componentes arquiteturais. Existem

três tipos de cenários: direto (pode ser executado diretamente), indireto (exigem uma mudança

de um componente) e aspectual (pode ser direto ou indireto e está disperso entre múltiplos

componentes). Em (TEKINERDOGAN, 2004) são classificados quatro tipos de componentes:

• Componente coeso, um componente que está bem definido e executa cenários

semanticamente fechados.

• Componente mal definido, um componente que consiste de vários sub-componentes,

sendo que cada um deles executa um conjunto de cenários semanticamente fechados.

• Componente entrelaçado, um componente que executa um cenário aspectual o qual é

direta ou indiretamente executado pelo componente.

• Componente composto, um componente que inclui cenários semanticamente distintos, mas

que não podem ser decompostos ou não incluem um cenário aspectual.

72

Os aspectos arquiteturais são os artefatos de saída, que podem ser usados para

refatorar a arquitetura. Conforme ilustrado na Figura 5.3, o processo ASAAM consiste de

cinco atividades (TEKINERDOGAN, 2004):

Figura 5.3 – As atividades para o ASAAM – Fonte: (TEKINERDOGAN, 2004).

1. Desenvolvimento da arquitetura candidata: um design de arquitetura (candidata) fornecido

será analisado levando em conta os fatores de qualidade e potenciais aspectos requeridos.

2. Desenvolvimento de cenários: cenários provenientes de vários stakeholders são coletados,

os quais representam usos importantes e usos antecipados da arquitetura de software.

3. Avaliação de cenário individual e identificação de aspectos: a avaliação de cenários

também busca por potenciais aspectos. A aplicação de regras heurísticas resulta em uma

classificação posterior dos cenários em: cenário diretos, cenários indiretos, cenários

aspectuais e aspectos arquiteturais. Cenários aspectuais são derivados de cenários diretos ou

indiretos e representam potenciais aspectos.

4. Avaliação da interação do cenário e identificação de componentes entrelaçados: A meta

desta atividade é avaliar se a arquitetura suporta uma separação apropriada de interesses.

Inclui-se os interesses não-transversais e os aspectos arquiteturais. Para cada componente, os

componentes diretos e indiretos são analisados e categorizados em componentes coesos,

componentes entrelaçados, componentes compostos, ou componentes mal definidos.

5. Refatoração da arquitetura: A refatoração da arquitetura é proposta baseando-se na

avaliação da interação dos cenários e nas classificações dos componentes. Os aspectos

arquiteturais e os componentes entrelaçados são descritos explicitamente na arquitetura. A

ASAAM define um conjunto de regras heurísticas para categorizar cenários em cenários

diretos, cenários indiretos e cenários arquiteturais e aspectos arquiteturais (Quadro 5.1). O

ASAAM também define regras heurísticas para categorizar os componentes arquiteturais.

Desenvolvimento de uma Arquitetura Candidata

Avaliação de Cenário Individual e Identificação de

Aspectos

Avaliação da Interação de Cenários e Identificação de Componentes Entrelaçados

Refatoração da Arquitetura

Refatoração Aspectual da Arquitetura

Desenvolvimento de Cenários

73

Quadro 5.1 – Regras heurísticas para avaliação de cenários – Fonte: (TEKINERDOGAN, 2004).

R0: Desenvolver artefatos CENÁRIOS baseados na DESCRIÇÃO DO PROBLEMA R1: SE CENÁRIO não requer quaisquer alterações na descrição arquitetural ENTÃO CENÁRIO torna-se CENÁRIO DIRETO R2: SE CENÁRIO requer alterações a um ou mais COMPONENTES ARQUITETURAIS ENTÃO CENÁRIO torna-se CENÁRIO INDIRETO R3: SE CENÁRIO INDIRETO pode ser resolvido após a refatoração ENTÃO CENÁRIO INDIRETO é CENÁRIO DIRETO R4: SE CENÁRIO DIRETO estiver espalhado e não pode ser localizado em um componente ENTÃO CENÁRIO DIRETO é CENÁRIO ASPECTUAL R5: SE CENÁRIO INDIRETO estiver espalhado e não pode ser localizado em um componente ENTÃO CENÁRIO INDIRETO é CENÁRIO ASPECTUAL R6: Derivar a ASPECTO ARQUITETURAL do CENÁRIO ASPECTUAL

O ASAAM tem sido implementado como um plug-in Eclipse no ambiente da

ferramenta ASAAM-T (TEKINERDOGAN; SCHOLTEN, 2005).

5.4 Uma Análise de Abordagens de Aspectos Preliminares

Na opinião de Bakker, Tekinerdoğan e Aksit (2005), apesar da noção comum e estável

sobre o conceito de aspecto no nível de programação, a noção de aspectos nas fases

preliminares (também denominados aspectos preliminares), não está consolidada. Contudo,

isto não resulta de um entendimento superficial do conceito de aspectos preliminares, mas,

principalmente, devido à falta de uma base comum para discussão em torno deste conceito.

O objetivo do trabalho apresentado por Bakker, Tekinerdoğan e Aksit (2005) é

proporcionar uma visão geral de diferentes técnicas em torno de aspectos preliminares que

possam ser usadas como guia para atividades de pesquisa, quais sejam:

• Avaliação individual das abordagens: É importante entender os conceitos subjacentes das

abordagens com seus pontos fortes e fracos em um framework de avaliação.

• Comparação das abordagens: Uma vez que as abordagens selecionadas são analisadas

individualmente, elas são comparadas para se determinar o quanto elas se sobrepõem ou

se complementam uma a outra.

• Definir as questões de pesquisa em aberto: Juntamente com o entendimento dos conceitos

essenciais do estado da arte da tecnologia, é necessário identificar seus problemas.

No Anexo 3 constam os resultados da análise de Bakker, Tekinerdoğan e Aksit (2005).

74

5.5 ADLs Orientadas a Aspectos

De acordo com o framework de classificação proposto por Medvidovic e Taylor

(2000), os blocos de construção essenciais de uma descrição arquitetural são componentes,

conectores, e configurações arquiteturais. Componentes e conectores podem ter interfaces,

tipos, semântica e restrições, associados a eles, mas apenas as interfaces de componentes

explícitas são uma característica exigida para ADLs.

A literatura mostra que há uma diversidade de pontos de vistas sobre como os aspectos

(e geralmente interesses) devem ser modelados nas ADLs (NAVASA et al., 2002) (NAVASA

et al., 2005), (PINTO; FUENTES; TROYA, 2003), (PINTO; FUENTES; TROYA, 2005),

(PEREZ et al., 2003) (PEREZ et al., 2006), (PESSEMIER; SEINTURIER; DUCHIEN,

2004), (PESSEMIER et al., 2006), (BATISTA et al., 2006-a), (BATISTA et al., 2006-b).

Batista et al. (2006-a) alegam que “a introdução dos conceitos de OA nas ADLs tem

sido experimental, de forma que os pesquisadores vêm tentando incorporar nas ADLs os

principais conceitos da POA”. A maioria das ADLs OA são motivadas pela integração de

conceitos de ADL existentes (componentes, interfaces, conectores e configurações) com as

abstrações OA (aspectos, pontos de junção, conjuntos de pontos de junção, comportamentos

transversais) a fim de tratar a modelagem de interesses transversais na arquitetura.

5.5.1 A Abordagem de Navasa et al. (2002)

A partir de uma perspectiva estrutural (NAVASA et al., 2002) (NAVASA et al., 2005)

é definido um conjunto de requisitos que as atuais ADLs necessitam tratar para permitir o

gerenciamento de interesses transversais usando abstrações de conexões arquiteturais. Tais

requisitos são: (i) definição de primitivas para especificar pontos de junção em componentes

funcionais; (ii) definição da abstração de aspectos como um tipo especial de componente; (iii)

especificação de conectores entre pontos de junção e aspectos. É sugerido o uso de modelos

de coordenação para especificar os conectores entre componentes funcionais e aspectos.

Em (NAVASA et al., 2002) a separação de aspectos no nível arquitetural resume-se a

um problema de coordenação. Considere que as Figuras 5.4-a e 5.4-b especificam a

arquitetura de software do mesmo sistema. A Figura 5.4-a mostra como as arquiteturas de

software são atualmente especificadas: os arquitetos de softwares têm que especificar a

funcionalidade do sistema usando componentes e as interações entre componentes usando

conectores. Entretanto, a especificação dos interesses interferindo no sistema permanece

transversal à especificação dos componentes.

75

Figura 5.4-a – Especificação convencional

de uma arquitetura de software Figura 5.4-b – Especificação separada de interesses transversais no nível arquitetural

Fonte: (NAVASA et al., 2002)

Na Figura 5.4-b a especificação de aspectos está separada, de modo que o arquiteto de

software tem que especificar componentes com suas interfaces, conexões entre interfaces e

aspectos separados.

Navasa et al. (2002) concluem que, para gerenciar a separação de interesses em nível

de design arquitetural de sistemas de software, as atuais ADLs devem ser estendidas a fim de

prover as seguintes funcionalidades:

a) Especificar componentes funcionais com interfaces e conexões entre interfaces;

b) Especificar aspectos;

c) Especificar conectores entre pontos de junção e aspectos.

5.5.2 DAOP-ADL

A DAOP-ADL é uma ADL para Desenvolvimento Dinâmico Baseado em

Componentes e Aspectos. Em (PINTO; FUENTES; TROYA, 2003) é descrita a DAOP-ADL,

baseada em componentes e aspectos para especificar a arquitetura de uma aplicação em

termos de componentes, aspectos e um conjunto de regras de compatibilidade de conexão

(plug-compatibility rules) entre eles. Com o objetivo de conectar a especificação da

arquitetura da aplicação à implementação, a linguagem usa XML e XML Schemas.

A linguagem DAOP-ADL foi projetada para ser interpretada pela DAOP, uma

plataforma dinâmica orientada a componentes e a aspectos (PINTO et al., 2001). A DAOP

76

provê um mecanismo de composição que conecta aspectos a componentes, dinamicamente,

em tempo de execução (PINTO et al., 2002). O arquiteto de software usará a linguagem

DAOP-ADL em tempo de design para descrever a arquitetura da aplicação. Mais tarde esta

informação arquitetural é carregada na plataforma DAOP, a qual necessita dela para

estabelecer as conexões dinâmicas entre componentes autônomos e aspectos.

Conseqüentemente, o uso da DAOP-ADL fecha a lacuna entre o design e a implementação de

aplicação baseadas em componentes e aspectos (PINTO; FUENTES; TROYA, 2005).

5.5.3 Fractal

Em (PESSEMIER et al., 2006) a ADL Fractal é estendida usando a noção de Aspect

Components (ACs). Os ACs são responsáveis pela especificação de interesses transversais

existentes na arquitetura do software. Cada AC pode afetar componentes por meio de uma

interface de interceptação especial. Dois tipos de vinculações entre componentes e ACs são

oferecidos: (i) uma vinculação transversal direta por meio da declaração das referências a

componentes e (ii) uma vinculação transversal usando expressões de conjuntos de pontos de

junção nos nomes dos componentes, nomes de interfaces e nomes de serviços.

5.5.4 PRISMA

Na abordagem PRISMA (PEREZ et al., 2003) (PEREZ et al., 2006), os aspectos são

as novas abstrações de ADL usadas para definir a estrutura ou comportamento de elementos

arquiteturais (componente e conectores), de acordo com pontos de vistas específicos do

sistema. Os componentes e conectores incluem uma especificação de combinação que define

a execução de um aspecto e contém operadores de combinação para descrever a ordem

temporal do processo de combinação: depois, antes, durante, e outros.

5.5.5 AspectualACME

O trabalho de Batista et al. (2006-b) reflete sobre a necessidade de extensões às

abstrações convencionais frente à presença de interesses transversais. Para cada questão

levantada, foi esboçada uma solução proposta sempre que as ADLs OA e não-OA existentes

não fornecem a solução adequada. O resultado foi o desenvolvimento de uma ADL

denominada AspectualACME (BATISTA et al., 2006-a) (GARCIA et al., 2006-b), produto

de uma extensão da linguagem ACME (GARLAN; MONROE; WILE, 1997) com vistas a

apoiar a descrição de arquiteturas orientadas a aspectos.

5.5.6 Questões sobre Aspectos e Conexão Arquitetural

Segundo Batista et al. (2006-b) há sete questões fundamentais que surgem quando são

relacionados interesses transversais e abstrações de ADLs: (a) Quais elementos em uma ADL

77

podem conter interesses transversais; (b) Composição; (c) Quantificação; (d) Interfaces de

Aspectos; (e) Exposição de Pontos de Junção; (f) Aprimoramentos na Interface; e (g) Como

Representar Aspectos.

Os autores optaram por focalizar nessas questões pelos seguintes motivos: (a) elas

envolvem elementos (ex.: interfaces de módulos), que têm sido discutidas nas abordagens de

implementação OA – tais como (ALDRICH, 2005), (RAJAN; SULLIVAN, 2005) –, as quais

também são arquiteturalmente relevantes; e (b) elas têm sido, recorrentemente, uma área

perigosa ou ponto de controvérsia nas soluções arquiteturais OA existentes.

I. Quais elementos de ADL podem ter interesses transversais?

Os elementos de ADL dão suporte à especificação explícita (e possivelmente

modularização) de alguns interesses arquiteturais através do uso de diferentes categorias de

elementos arquiteturais tais como componentes, conectores e configurações arquiteturais. De

acordo com o framework de Medvidovic e Taylor (2000), componentes, conectores,

configurações e interfaces de componentes constituem um conjunto mínimo de características

requeridas para ADLs. Conseqüentemente, Batista et al. (2006-b) adotaram como elementos

de ADL candidatos aqueles que podem ser afetados pelos interesses arquiteturais transversais

em pontos bem definidos.

Há algumas situações que sugerem que diferentes elementos de ADLs podem estar

sujeitos ao entrelaçamento e ao espalhamento de interesses e, conseqüentemente, os interesses

transversais podem potencialmente existir e afetá-los. Uma vez que as configurações

arquiteturais podem ser consideradas como componentes compostos, elas podem ser afetadas

por interesses transversais (BATISTA et al., 2006-b).

II. Composição

Baseado no amplo uso de conectores para diferentes propósitos de interconexão,

Batista et al. (2006-b) propuseram uma abordagem baseada em conexão a fim de modelar a

composição entre componentes “regulares” e componentes “aspectuais”.

A proposta de (BATISTA et al., 2006-b) consiste em estender a interface de conector

a fim de especificar um papel básico e um papel transversal e, também, definir uma cláusula

glue para especificar detalhes sobre a conexão, tal como o local onde o comportamento

transversal deve afetar o componente “regular” (depois, antes, ou durante). Um papel básico

pode ser conectado à porta de um componente e um papel transversal pode ser conectado à

porta de um componente aspectual.

78

A configuração também tem uma função importante no modelo composicional, pois,

conforme (BATISTA et al., 2006-b), ela define a conexão entre componentes, conectores e

componentes aspectuais. Por isso, na descrição da configuração são definidos os pontos de

junção nos quais o componente aspectual age. Na verdade, o conceito de configuração já

define o ponto onde um componente une-se a um conector.

III. Quantificação

A fim de evitar a necessidade de fazer referência a cada ponto de junção

explicitamente em uma descrição arquitetural, é necessário usar um mecanismo de

quantificação que fornece uma única declaração para alcançar vários pontos de junção. Uma

vez que a parte da configuração é o local onde os pontos de junção estruturais estáticos são

identificados, o mecanismo de quantificação é definido incluindo wildcards e expressões

lógicas. A quantificação deve ser usada na conexão do papel básico com o componente

destino (BATISTA et al., 2006-b).

IV. Interfaces de Aspectos

A interface de um componente é um conjunto de pontos de interação. Uma interface,

conseqüentemente, define compromissos (envolvimentos) arquiteturais que um componente

pode fazer e restringe seu uso.

Segundo Batista et al. (2006-b), a noção de interfaces arquiteturais não deveria ser

alterada para expressar os limites de um componente “aspectual”, uma vez que, em nível

arquitetural, já possuem abstrações de conexão adequadas para a especificação tal como um

protocolo de colaboração.

Batista et al. (2006-b) afirmam que a presença de interesses transversais no design da

arquitetura leva a novos conectores aspectuais, mas as interfaces e os componentes

permanecem os mesmos.

V. Exposição de Pontos de Junção

Batista et al. (2006-b) alegam que a noção de interfaces das ADLs não necessita ser

alterada a fim de expor a natureza transversal do componente. Um “componente aspectual”, o

qual representa um interesse transversal, afeta outros componentes por meio de seus

conectores. Neste contexto, a questão é se as interfaces dos componentes afetados necessitam

expor informações extras para permitir a conexão com “componentes aspectuais” e, como

conseqüência, o conceito tradicional de interfaces em ADLs necessita ser estendido.

79

Batista et al. (2006-b) alegam que, no nível arquitetural, o arquiteto deve preparar o

componente para ser afetado pelos “componentes aspectuais” expondo na interface dos

componentes a informação necessária à composição de um “componente afetado” com outros

componentes, representando um interesse transversal arquitetural. Conseqüentemente, as

ADLs deveriam suportar a exposição de pontos de junção nas interfaces dos componentes.

VI. Aprimoramentos na Interface

Algumas abordagens de implementação OA, tal como AspectJ (KICZALES et al.,

2001), também associam ao aspecto a habilidade de alteração do tipo e da interface dos

módulos por meio das chamadas declarações inter-tipos. A partir de uma perspectiva

arquitetural, isto significaria que os componentes “aspectuais” poderiam melhorar as

interfaces dos componentes com novos elementos, tais como serviços e atributos.

O ponto de vista apresentado em (BATISTA et al., 2006-b) é que tal característica não

é necessária para capturar os interesses transversais nas especificações arquiteturais. Se um

serviço ou um atributo relativo a um interesse estiver entrelaçado com outros serviços e

atributos na interface de um dado componente, é possível fiar-se, facilmente, em sua noção de

conector aspectual para expressar isso de um modo mais modular.

VII. Como Representar Aspectos?

Batista et al. (2006-b) levantam a seguinte questão: “É realmente ainda necessário

introduzir outra abstração em nível de arquitetura resultando na necessidade de treinar

arquitetos na sintaxe e na semântica de tal abstração?” Segundo Batista et al. (2006-b), as

composições de aspectos podem ser modeladas por meio de conectores, papéis transversais e

papéis básicos, sem a introdução de novas abstrações.

5.5.7 Observações

A proposta de (BATISTA et al., 2006-b) define um modelo de composição que tira

vantagem das abstrações arquiteturais existentes – conectores e configurações – estendendo-

as para dar suporte à definição de algumas facilidades de composição tal como um

mecanismo de quantificação.

A proposta de (BATISTA et al., 2006-b) está baseada no enriquecimento da semântica

de composição por meio da introdução de conectores ao invés da introdução de novas

abstrações que elevam os conceitos de LP ao nível arquitetural.

A Tabela 5.3 apresenta o resultado de uma comparação realizada por Batista et al.

(2006-b) sobre as principais ADLs-OA e as sete questões tratadas.

80

Tabela 5.2 – Comparação de ADLs OA – Fonte: (BATISTA et al., 2006-b)

Questão

ADL

Questão 1

Interesses Transversais

Questão 2

Composição

Questão 3

Quantificação

Questão 4 Interface de Aspecto

Questão 5 Exposição de Pontos

de Junção

Questão 6 Melhoramento de

Interface

Questão 7 Aspectos em ADLs

Aspectual

ACME

Podem ser encontrados em componentes, conectores e em configurações

Modelada por conectores com papéis básicos e transversais e por configurações

Suportada por wildcards e operadores lógicos definidos da seção de configuração

Extensão não requerida

Os componentes e conectores podem expor seus eventos internos

Não suportado Os aspectos são modelados por meio de conectores e papéis aspectuais e básicos

Prisma Podem ser encontrados em componentes, conectores e em configurações

Componentes, conectores e configurações são definidos em termos de aspectos

Não tratado Não tratado Os aspectos têm acesso direto a todas as propriedades de um componente ou conector

Os aspectos permitem o refinamento das propriedades de componentes e conectores

Os aspectos definem a semântica de componentes e conectores

Fractal Podem ser encontrados apenas em componentes

Suporta vinculação transversal direta e vinculação transversal usando conjuntos de junção

A expressão de ponto de junção pode ser expressa em termos de interface de componente e nomes de métodos

Interface de interceptação permite a vinculação entre aspectos e componentes

As chamadas de entrada e saída a componentes podem ser expostas

Não suportado Aspect Components especificam os interesses transversais

DAOP-ADL

Podem ser encontrados apenas em componentes

Suportado por um conjunto de regras de avaliação de aspectos

Não suportado Interfaces de avaliação objetivam as interfaces de eventos

Extensão não requerida, a interfaces de componentes podem expor pontos de junção

Não suportado Uma especificação separada com uma interface de avaliação

Proposta da Navasa

Podem ser encontrados apenas em componentes

Usa conectores entre pontos de junção e aspectos

Depende do modelo de coordenação adotado

Apenas fixa que os aspectos devem ter semântica diferente dos componentes

Cria novas primitivas para especificar pontos de junção

Não suportado Aspecto é um novo componente com uma semântica diferente

81

5.6 Considerações

O Desenvolvimento de Software Orientado a Aspectos (DSOA) é uma abordagem

emergente que provê meios explícitos para se modelar interesses que tendem a entrecortar

múltiplos componentes do sistema. Apesar de que inicialmente o foco estava unicamente nos

aspectos em nível de programação, recentemente uma quantia considerável de pesquisa tem

sido realizada para identificar e modelar aspectos nas fases preliminares do ciclo de vida do

desenvolvimento de software.

Nas abordagens de design arquitetural orientadas a aspecto, é possível encontrar

alternativas diferentes para atacar a questão da separação de interesses. Tais abordagens

diferem, principalmente, no que concerne ao local onde a informação de combinação é

colocada (quais aspectos são aplicados ao código primário e quando), e à fase no ciclo de vida

do software na qual o processo de combinação é executado (estaticamente durante a

compilação ou dinamicamente em tempo de execução). A variedade das abordagens é

consideravelmente extensiva, o que torna impossível cobrir todas elas neste capítulo.

Vê-se que há uma diversidade de opiniões sobre como os aspectos (e geralmente

interesses) devem ser modelados nas ADLs.

A maioria das ADLs tem o problema de ser fracamente acoplada às linguagens de

implementação, causando problemas na análise, implementação, entendimento e evolução de

sistemas de software (ALDRICH; CHAMBERS; NOTKIN, 2002-a).

Em relação às ADLs, as linguagens convencionais não provêem primitivas para se

especificar a separação de aspectos. Portanto, seria necessário especificar conexões com

outros aspectos e não apenas entre componentes, mas também entre componentes e aspectos e

aspectos com outros aspectos. Entretanto, a idéia de se ter interfaces nos aspectos não é clara.

A maioria dos trabalhos ainda não esclarecem como especificar aspectos.

Com base no que foi posto acima, conclui-se que novos mecanismos são requeridos

para se introduzir a separação de aspectos durante o design arquitetural.

83

6 – Características Desejáveis em uma ADL-OA

6.1 Introdução

Recentemente, tem havido esforços para a integração de conceitos do DSOA no

contexto específico da disciplina de Arquitetura de Software. Ainda que ambas as áreas,

individualmente, tenham uma história não muito recente, em suas atuais expressões elas são

razoavelmente jovens. Não obstante estejam intrinsecamente relacionadas, sua combinação é

uma idéia recente, presente em propostas tais como (NAVASA et al., 2002), (PEREZ et al.,

2003), (CUESTA et al., 2005), (BATISTA et al., 2006-a) e (GARCIA et al., 2006-b).

Segundo Cuesta et al. (2005), ainda há vários problemas estruturais abertos na área do

DSOA (tais como composição de aspectos, definição de prioridades nesta composição e

resolução de dependências estruturais entre eles) os quais seriam muito beneficiados quando

dissecados sob uma perspectiva arquitetural, pois as áreas de arquitetura de software e de

DSOA têm pontos em comum.

Convém observar que, a partir de trabalhos como (NAVASA et al., 2002) e

(BAKKER; TEKINERDOGAN; AKSIT, 2005), o conceito de aspecto passa a ser

dimensionado como uma abstração que transcende o nível de implementação para encontrar

espaço nas fases preliminares do desenvolvimento de software, como por exemplo, na

engenharia de requisitos e no design arquitetural. Tal concepção é de extrema relevância, já

que a engenharia de software não pode prescindir de uma vinculação conceitual coerente entre

as diversas soluções de apoio à engenharia de software (SAES)16 que dão suporte às

diferentes fases e atividades do processo de software. Destarte, a noção de aspecto arquitetural

poderá vir a fazer parte do arsenal conceitual fundamental do arquiteto de software.

A partir da consolidação do DSOA, emergiu a necessidade de refletir se as abstrações

arquiteturais fundamentais oferecem os meios necessários à modularização de interesses

transversais (CUESTA et al., 2005-a). Um interesse transversal em nível arquitetural é um

interesse que, de fato, não pode ser efetivamente modularizado usando-se as abstrações de

uma ADL convencional. A sua não modularização pode conduzir a conseqüências tais como:

acréscimo no custo de manutenção, possibilidade de reuso reduzida, e desgaste arquitetural

acima do tempo de vida do software (TARR et al., 2005) (BANIASSAD et. al., 2006).

16 Genericamente, consiste de Modelos de Processos, Métodos de Engenharia de Software, Técnicas de Desenvolvimento e Notações que apóiam as atividades de engenharia de software.

84

Com a intenção de poder tratar da modelagem de interesses transversais em nível

arquitetural, a maioria das ADLs Orientadas a Aspectos (ADLs-OA) são motivadas pela

integração indiscriminada dos conceitos de ADL (tais como componentes, interfaces,

conectores, configurações)17 com as novas abstrações da POA (tais como aspectos, pontos de

junção, conjuntos de pontos de junção, comportamentos transversais, declarações inter-

tipos)18. A fim de dar suporte à modularização de interesses transversais, algumas ADLs-OA

(PEREZ et al., 2003) (PINTO; FUENTES; TROYA, 2003) têm sido desenvolvidas a partir do

zero, empregando as citadas abstrações OA.

Embora essas ADLs-OA sejam consideradas as primeiras contribuições e pontos de

vistas interessantes na área, conforme (BATISTA et al., 2006a) “ainda constam divergências

sobre como as ADLs devem ser integradas ao DSOA, pois há pouca informação sobre como e

porque são requeridas extensões às noções tradicionais de elementos de ADLs”.

É mister analisar se a presença de interesses transversais em uma arquitetura exige

extensões às abstrações convencionais existentes, e quais são essas extensões. Portanto, urge

esclarecer até que ponto os arquitetos de software estão aptos a especificar modularmente os

interesses transversais e suas interconexões com outros elementos arquiteturais.

O restante deste capítulo encontra-se organizado como segue. Na Seção 6.2 são

discutidas seis importantes diretrizes enunciadas com vistas a nortear o estabelecimento de

um conjunto de características desejáveis em uma ADL-OA. Na Seção 6.3 é apresentada uma

tabela mostrando como as seis diretrizes direcionadoras relacionam entre si. Na Seção 6.4

apresenta-se e discute-se dezesseis características consideradas desejáveis em uma ADL-OA.

Na Seção 6.5 são apresentadas duas tabelas que mostram as influências mútuas entre as

características desejáveis em uma ADL-OA. Na Seção 6.6 é apresentada a proposta de uma

notação gráfica e do formalismo para uma ADL-OA. Na Seção 6.7 estão descritas algumas

considerações à respeito deste capítulo.

6.2 Diretrizes Norteadoras

Nesta seção são enunciados alguns princípios gerais, de ampla validade no campo da

engenharia de software, consistindo em um conjunto de diretrizes norteadoras para o

estabelecimento de uma lista de características desejáveis em uma ADL-OA. Este conjunto

representa um esboço inicial que certamente será aprimorado à partir de novas pesquisas

17 Presentes no clássico framework de ADLs proposto em (MEDVIDOVIC; TAYLOR, 2000) – vide Capítulo 4. 18 Comumente adotadas em frameworks e linguagens de programação, como por exemplo na AspectJ (KICZALES et al., 2001) – vide Capítulo 5 sobre DSOA.

85

Conforme (IEEE, 1993), a disciplina de engenharia de software pode ser definida

como a aplicação de uma abordagem sistemática, disciplinada e quantitativa para o

desenvolvimento, operação e manutenção de software, isto é, a aplicação da engenharia ao

software. A engenharia de software tem como principal objetivo apoiar o trabalho do

engenheiro de software com vistas à produção de software com qualidade (o qual satisfaz as

necessidades dos usuários, com desempenho sem falhas por um período de tempo satisfatório,

fácil de ser usado e modificado), com o menor esforço e maior eficiência possíveis.

Embora a área de pesquisa em engenharia de software tenha se desenvolvido muito

nos últimos anos em relação ao conjunto de ferramentas CASE19 disponíveis para apoiar o

esforço de desenvolvimento de software, pode-se dizer que algumas soluções de apoio à

engenharia de software (ex.: ADLs) ainda não foram integradas ao processo de software

como um todo (ex.: ADLs, métodos de avaliação de arquiteturas). Portanto, ainda persiste a

busca por um ambiente de engenharia de software20 que apresente capacidades para atender

idealmente as necessidades requeridas por um processo de software.

Seria insuficiente o desenvolvimento de uma nova solução de apoio à engenharia de

software sem a preocupação com sua devida integração ao processo. Um exemplo concreto

disso consiste em uma das maiores dificuldades enfrentadas pelo gerente de projeto quando

ele necessita visualizar o processo sob diferentes perspectivas ao longo do ciclo de vida do

software (CLELAND; IRELAND, 2002), pois a ausência de integração no processo provoca

rupturas, a partir das quais podem originar lapsos que comprometem a gestão do projeto.

Idealmente, os artefatos produzidos devem ser os elos de integração do processo de

software, de modo que os produtos resultantes de uma determinada atividade possam ser os

pontos de partida para atividades subseqüentes (Figura 6.1). Tal ligação visa garantir a

continuidade do processo de desenvolvimento, evitando que, ao longo do ciclo de vida,

rupturas conceituais indesejáveis sejam capazes de desencorajar o engenheiro de software a

utilizar, satisfatoriamente, os artefatos oriundos de fases precedentes. O engenheiro de

software interage com o processo mediante o uso de soluções de apoio à engenharia de

19 Um produto de software que auxilia o engenheiro de software fornecendo suporte automatizado para as atividades do ciclo de vida do software (ISO/IEC 14102-1995). 20 Um sistema que fornece suporte automatizado à engenharia de sistemas de software do processo de software; inclui plataforma, softwares de sistema, utilitários, e ferramentas CASE instaladas. A arquitetura do ambiente de engenharia de software tem dois aspectos: as ferramentas CASE que oferecem recursos para dar suporte aos processos do ciclo de vida; e um framework genérico que provê um conjunto de recursos que oferecem serviços comuns usados pelas ferramentas (ISO/IEC 14102-1995). (Vide Capítulo 7)

86

software (SAESs) e, o quão mais adequadas forem tais SAESs, maior será a qualidade do

processo de software, resultando, potencialmente, e um produto final com qualidade.

Figura 6.1 – Engenheiros de software interagem com o processo de software por meio de SAESs; os artefatos produzidos constituem-se nos elos de integração do processo de software

As diretrizes norteadoras, listadas a seguir, têm como finalidade precípua assegurar

não apenas a produção de um software de qualidade, mas também a qualidade da produção

do software na perspectiva do engenheiro de software:

� Diretriz 1: Suporte aos Limites Naturais da Cognição e do Intelecto Humano

� Diretriz 2: Adoção de um Modelo de Processo de Software

� Diretriz 3: Automatização de Tarefas

� Diretriz 4: Reuso

� Diretriz 5: Suporte às Atividades de Gestão de Projetos

� Diretriz 6: Suporte ao Desenvolvimento Distribuído de Software

Na seqüência são apresentadas as explanações referentes às diretrizes enumeradas

acima, dignas de serem observadas durante o design de uma ADL-OA.

Diretriz 1: Suporte aos Limites Naturais da Cognição e do Intelecto Humano

De forma geral, as soluções de apoio à engenharia de software visam auxiliar trabalhos

essencialmente intelectuais desempenhados, primordialmente, por engenheiros de software (e

também por outros stakeholders). No que tange à sua capacidade cognitiva e intelectual (ex.:

lidar com grande número de informações e realizar análises complexas) o ser humano possui

limites inerentemente inatos, os quais independem do treinamento ou nível educacional. Um

exemplo típico dessa limitação diz respeito ao processamento simultâneo de informações.

Tarefas:

---------

---------

Tarefas:

---------

---------

- - - - -

Tarefas:

---------

---------

Atividade1 Atividade2 Atividaden

SAES

SAES

SAES

Engenheiro de Software



Artefato

Realiza

Produz Utiliza

Realiza

Artefato

Interage Interage Interage

Produz Utiliza

Realiza

Processo de Software

87

Segundo a teoria de Miller (1956), encontra-se na faixa de 7 +/– 2 a quantidade de porções de

informações que podem ser armazenadas na memória de curto prazo das pessoas. Outro

exemplo clássico é o uso preferencial por notações visuais em relação ao uso de notações

formais textuais: normalmente, o ser humano encontra-se mais apto a lidar com figuras do

que com simbolismos matemáticos com sintaxe complexa e minuciosa.

Portanto, novas soluções de apoio à engenharia de software devem ser concebidas

sempre levando em consideração a pessoa humana do engenheiro de software e, com base

nessa premissa, são enunciadas as demais diretrizes constantes neste trabalho. Conforme

(CLELAND; IRELAND, 2002), o sucesso dos projetos depende, primordialmente, das

pessoas nele envolvidas e a tecnologia vem em segundo lugar.

Genericamente, é possível distinguir dois grupos de usuários de recursos

computacionais: a) usuários finais, quando as atividades apoiadas pelo computador não

apresentam qualquer relação direta com o desenvolvimento de software (Figura 6.2-a e 6.2-b)

engenheiros de software, quando as atividades são diretamente relacionadas ao

desenvolvimento de software – neste último caso, o engenheiro de software emprega soluções

de apoio à engenharia de software para se beneficiar da máquina (Figura 6.2-b).

Figura 6.2-a – Usuário final usa a máquina por

meio de uma solução de software para desempenhar atividades não relacionadas diretamente ao

desenvolvimento de software.

Figura 6.2-b – Engenheiro de software emprega SAESs para se beneficiar da máquina durante o

processo de desenvolvimento de software.

Historicamente, as soluções de apoio à engenharia de software têm tido receptividade

e sucesso ao oferecerem suporte direto ao intelecto do engenheiro de software e, ao mesmo

tempo, servirem como uma alavanca para incrementar sua capacidade cognitiva. Como

exemplos, podemos citar: a) limitação da memória humana ao lidar com código muito

extenso: solução dada em parte pela técnica de estruturação do código (DIJKSTRA, 1968) e

aprimorada pela orientação a objetos; b) abstração de detalhes de implementação ao lidar com

a estrutura global do sistema: solução alcançada pelo conceito de modularização (PARNAS,

1972) e concretizada inicialmente pelas linguagens de interconexão de módulos (DEREMER;

KRON, 1975), culminando com o conceito de arquitetura de software juntamente com o de

ADLs (PERRY; WOLF, 1992) e (GARLAN; SHAW, 1993).

SAES


Solução de

Software

Usuário Final

88

Estudos realizados (SHAW; GARLAN, 1994) têm mostrado que o paradigma OO teve

seu sucesso garantido, em grande parte, devido ao fato de atender a esta presente diretriz.

Similarmente, o DSOA também vem se consolidando como um paradigma altamente eficaz

pelo fato de resolver um dos grandes problemas que fogem à capacidade cognitiva humana,

qual seja, lidar com a dispersão e o entrelaçamento de interesses. O raciocínio por traz do

DSOA visa proporcionar maior conforto intelectual ao arquiteto de software, oferecendo

abstrações e recursos diferenciados que facilitam o tratamento dado ao problema dos

interesses transversais.

A modularização pode ser considerada como um dos principais avanços das técnicas

de engenharia de software. Em sua essência, tal conceito constitui-se em recurso que auxilia

na superação dos limites cognitivos inerentes ao ser humano, já que sua proposta original

preconiza, entre outras coisas, o encapsulamento de decisões de design em unidades de

software e a ocultação de informações (PARNAS, 1972). Seus fundamentos têm servido de

base ao desenvolvimento estruturado, ao paradigma OO e, mais recentemente, ao DSOA.

O conceito de modularidade é imanente ao de aspecto: esta abstração possui

capacidade para apoiar o engenheiro de software em sua natural limitação cognitiva, pois os

interesses transversais não podem ser intelectualmente tratados sem o apoio de uma abstração

modular (aspecto). A idéia de aspecto está intrinsecamente relacionada à de modularidade, e

constitui-se em um recurso eficaz para superar uma natural limitação intelectual do arquiteto

de software, já que nem sempre é possível modelar e compor interesses transversais dentro de

compartimentos estanques por meio das abstrações e mecanismos convencionais.

Similarmente, as técnicas de abstração presentes nas LPs modernas (SHAW, 1984)

também ilustram essa questão, já que as LPs dependem da técnica de abstração, pois elas

gerenciam a complexidade enfatizando o que é significativo e suprimindo o que não é. Tal

abordagem favorece as análises realizadas pelos desenvolvedores, pois permite que o foco

seja centrado nos interesses que são relevantes à solução do problema em questão.

Na perspectiva do engenheiro de software (Figura 6.3-a), uma notação é um meio de

comunicação (interface) entre o homem e a máquina. Quanto mais elaboradas forem suas

abstrações (tipos de dados estruturados, tipos de dados abstratos, objetos, componentes e

aspectos), menor será a sobrecarga cognitiva imposta ao seu usuário e menor o esforço de

desenvolvimento e manutenção.

89

Por outro lado, na perspectiva computacional (Figura 6.3-b), uma notação formal

textual (ex.: ADL) pode ser entendida como um meio de comunicação (interface) entre

diferentes SAESs. Quanto mais formal, precisa, e concisa forem sua sintaxe e semântica,

maior o seu poder de expressão e menor o esforço de processamento demandado na análise

dos modelos representados pela notação. Neste sentido, há grandes avanços com diversos

formalismos desenvolvidos, como π-Calculus, CSP, Redes de Petri (embora haja problemas

relacionados às limitações de interoperabilidade entre esses diversos formalismos). Portanto, é

necessário que uma dada notação contenha em seu bojo certo grau de formalismo.

Diretriz 2: Adoção de um Modelo de Processo de Software

O processo de software constitui-se em uma série de atividades que, classicamente,

inicia-se com a análise de requisitos, passa pelo planejamento, modelagem, construção, e

estende-se à fase de implantação do software. Dessa forma, uma das metas mais almejadas,

pela comunidade de engenharia de software, é a plena integração das tarefas compreendidas

nessas atividades e, por conseqüência, de todo o processo de software.

Como um dos princípios basilares neste trabalho, é defendida a necessidade de que os

produtos (artefatos) resultantes das atividades de análise em nível arquitetural sejam,

efetivamente, (re-)utilizáveis no apoio às diversas necessidades do engenheiro de software,

assim como nas atividades de gerenciamento de projeto.

Para que o desiderato da integração das atividades seja alcançado, é mister a existência

de um ambiente integrado de desenvolvimento de software propiciando um contexto onde

seja possível aos desenvolvedores atuarem do modo mais cooperativo possível.

Neste sentido, verifica-se que uma integração satisfatória só é factível se houver

interoperabilidade entre ferramentas CASE. A integração pode ser por dados, por controle,

por apresentação, ou por intermédio de metadados (ISO/IEC, 1995). Ressalta-se que a

interoperabilidade também depende da compatibilidade semântica das soluções de apoio à

engenharia de software, já que tais soluções de apoio devem ser passíveis de integração

conceitual (semântica).

Figura 6.3-a – Notação como interface entre o ser humano e a máquina

Figura 6.3-b – Notação como interfaces entre diferentes SAESs

SAES1

SAES2

Notação Notação

90

Embora algumas linguagens padrão (ex.: XML) tenham possibilitado grandes avanços

em termos de compatibilidade sintática, ainda há muito trabalho a ser feito em relação à

compatibilidade semântica entre diferentes soluções de apoio à engenharia de software.

A fim de alcançar a integração e automatização do processo de software, os

desenvolvedores estão sendo contemplados com plataformas integradas de suporte ao

desenvolvimento de software (ex., .Net, Eclipse, Net Beans), as quais oferecem um amplo

conjunto de recursos, que vão desde simples editores de textos, passando por compiladores,

bibliotecas, frameworks, até uma coleção de serviços úteis (do tipo built-in) pré-

implementados. Tais plataformas devem ser integradas ao ambiente de desenvolvimento de

software como um todo, e esta integração pode se dar por meio de SAESs adequadas. Há

propostas de plataformas orientadas a aspectos, como a DAOP (Dynamic Aspect Oriented

Platform) (PINTO; FUENTES; TROYA, 2005).

Diretriz 3: Automatização de Tarefas

Uma das utilidades primárias da computação é a automatização de atividades

altamente complexas e repetitivas, passíveis de serem realizadas por máquinas, nos mais

variados campos de trabalho, principalmente aquelas atividades que vão além da capacidade

intelectual do ser humano. Há atividades do processo de software que compreendem tarefas

cuja realização demanda esforço repetitivo (ex.: codificação em linguagem de baixo nível) ou

análise demasiadamente complexa (ex.: compilação, depuração, composição, verificação da

arquitetura em relação à implementação) incapazes de serem realizadas de modo confiável

sem o apoio da máquina. Porém, algumas das tarefas do tipo citado acima, ainda não contam

com o apoio de soluções automatizadas, ex.: análise de arquitetura (CLEMENTS; KAZMAN;

KLEIN, 2002), e tampouco foram integradas ao processo de software como um todo.

Em muitos casos, a automatização depende da interoperabilidade. A interoperabilidade

pode ocorrer entre soluções de apoio à engenharia de software que oferecem suporte a

diferentes tarefas pertencentes a uma mesma atividade do processo de software (operabilidade

inter-tarefa), assim como entre soluções que apóiam tarefas compreendidas em diferentes

atividades do processo de software (operabilidade inter-atividade). Evidentemente, a

realização da operabilidade inter-atividade é mais complexa, pois exige a compatibilidade de

dados (artefatos ou metadados) produzidos em diferentes fases do ciclo de vida e, portanto,

conceitualmente distintos (diferenças na sintaxe ou na semântica). Um exemplo clássico dessa

capacidade é a geração automática de código a partir do design detalhado, ou a engenharia

reversa. Em (ALDRICH; CHAMBERS; NOTKIN, 2002-a) é apresentada uma solução que

91

permite que código Java seja gerado a partir da descrição arquitetural especificada por meio

da ArchJava, e que as alterações efetuadas no código fonte sejam refletidas na arquitetura.

Como um exemplo de solução de apoio à engenharia de software que provê recursos

para a realização da operabilidade inter-tarefa, pode-se citar a ACME (GARLAN; MONROE;

WILE, 1997) (GARLAN; MONROE; WILE, 2000): essa notação, útil na fase de design

arquitetural, foi projetada, principalmente, para servir como um veículo primário a ser usado

para a transferência de uma ADL para outra, o que facilita, conseqüentemente, a

interoperabilidade entre várias ADLs, permitindo ao arquiteto valer-se dos benefícios do uso

de múltiplas notações de design.

Embora em muitas circunstâncias (ex.: interoperabilidade entre tarefas de atividades

de gestão de projeto, e tarefas inerentes às atividades do processo de software) o uso de uma

linguagem padrão possa garantir a interoperabilidade, o problema maior a ser enfrentado está

relacionado à compatibilidade semântica entre as soluções de apoio à engenharia de software

de atividades das diferentes fases do processo.

Neste sentido, é desejável que todo produto de software apresente um conjunto

mínimo de atributos de qualidade. Consoante à norma ISO/IEC 14102 (ISO/IEC, 1995),

algumas das características de qualidade a serem analisadas quando da avaliação e seleção de

ferramentas CASE são as seguintes: (a) Funcionalidade; (b) Confiabilidade; (c) Usabilidade;

(d) Eficiência; (e) Manutenibilidade; (e) Portabilidade; tais características desdobram-se em

sub-características. Adicionalmente, podem ser listadas outras características importantes de

serem analisadas em uma ferramenta CASE, quais sejam: (a) Extensibilidade dos Recursos

(DASHOFY; van der HOEK; TAYLOR, 2005); (b) Abertura de Código; (c) Escalabilidade; e

(d) Flexibilidade (COULOURIS; DOLLIMORE; KINDBERG, 2007).

Analogamente, os artefatos de software também devem preencher determinados

requisitos de qualidade (SEBESTA, 2003), dentre os quais podem ser citados os seguintes:

• Precisão: a precisão das informações contidas em um artefato de software é obtida

empregando formalismos, que é requerido também nas análises ou verificações

automatizadas, utilizando-se ferramentas CASE.

• Legibilidade: representações complexas não se constituem em problemas para as

máquinas, entretanto, para os humanos tal característica pode trazer conseqüências

indesejáveis, tais como: dificuldades associadas à compreensão e análise puramente

intelectual da representação, dificuldade de aprendizado e também de manutenção. Via de

92

regra, os artefatos de software são mais facilmente compreendidos mediante a

possibilidade de representação visual ou por meio de uma notação simples, cuja sintaxe

esteja a mais próxima possível da linguagem natural, uma vez que alguns artefatos (ex.:

arquitetura de software, planos de projeto) podem vir a ser objetos de análise por parte de

stakeholders diversos, inclusive leigos (ex.: usuários finais, clientes).

• Padronização: atualmente há um grande empenho para a padronização dos formatos dos

dados que compõem os artefatos de software de modo a propiciar a tão almejada

interoperabilidade de ferramentas; há soluções propostas que se baseiam em meta-

modelos e linguagens padrão (ex.: XML).

• Leveza: além de terem que permanecer armazenados em repositórios de dados de

projetos, muitos artefatos deverão trafegar pela rede a fim de possibilitar o

desenvolvimento distribuído de software; neste sentido, surge a necessidade de que seus

respectivos arquivos não venham a acarretar altos custos de armazenamento ou

sobrecarregar o tráfego de dados pela rede de comunicação, para facilitar a atualização e

consistência do sistema.

Evidentemente, tais requisitos são mutuamente conflitantes (ex.: precisão versus

legibilidade), no entanto cabe ao designer da ADL-OA valorar cada um deles e realizar um

balanceamento (trade-off) a fim de atingir um equilíbrio relativo ao contexto.

Diretriz 4: Reuso

Da idéia de reuso originaram alguns dos primeiros avanços da engenharia de software

– ex.: estruturação do código fonte (DJIKSTRA, 1968), modularização (PARNAS, 1972)

(PARNAS; CLEMENTS; WEISS, 1985), e orientação a objetos.

Nos primórdios da computação, quando o custo de armazenamento era elevadíssimo,

as sub-rotinas foram idealizadas objetivando economizar memória. O papel das sub-rotinas

era dar condições ao programador de executar segmentos de código várias vezes, em

circunstâncias distintas (com o uso de parâmetros), sem a necessidade de duplicação do

código fisicamente em todos os trechos do programa nos quais ele fosse necessário.

Atualmente, o reuso busca, primordialmente, poupar recursos humanos, pois custo do

hardware tem diminuído acentuadamente em comparação com o custo do software (este

produzido por recursos humanos).

A filosofia da reutilização de software, em suas muitas concepções, não visa tão

somente à redução de esforço necessário para exercer as atividades, mas preocupa-se também

93

com o compartilhamento e disseminação de soluções comprovadas para problemas

recorrentes. Tais soluções tendem a adquirir maturidade à medida que são adotadas e

utilizadas em projetos reais de software, resultando daí a noção básica de padrões de

software. O reuso com maturidade reduz, consideravelmente, os custos de desenvolvimento e

implica em amadurecimento e consolidação dos aspectos utilizados reiteradamente em

diversos projetos de software (GAMMA et al., 1995) (BUSCHMANN et al., 1996).

A Engenharia de Software Baseada em Componentes tem como um de seus

objetivos primordiais o reuso com vistas à redução do esforço de desenvolvimento e a

utilização de soluções maduras e comprovadas. O desenvolvimento baseado em componentes

(fruto de uma evolução do paradigma orientado a objetos) trata-se de uma evolução bem

sucedida dos princípios de reuso (SZYPERSKI, 1998).

Ainda em nível de implementação, observa-se que os aspectos e os componentes de

software servem a um propósito semelhante, a saber: encapsular um determinado interesse

que possa ser reusado posteriormente.

Um componente bem projetado deve prover uma função claramente definida e, neste

sentido, encapsular um interesse. Além disso, as plataformas de desenvolvimento disponíveis

(ex.: Net Beans, .NET) incluem um conjunto de componentes e bibliotecas, pré-definidos,

capazes de proporcionar suporte para interesses não-funcionais genéricos (ex.: concorrência,

controle de acesso, segurança) de uma maneira transparente. Em relação a isso, Cuesta et al.,

(2005) sustentam que a única diferença real entre estes componentes “tradicionais” e a noção

de aspectos é a forma como eles são decompostos em módulos e compostos em subsistemas:

a distinção essencial não está no tipo dos módulos, mas sim no relacionamento entre eles.

A Engenharia de Software Baseada em Componentes prescreve o desenvolvimento de

componentes de software com vistas a serem reutilizados na maior quantidade possível de

projetos e objetiva, também, poupar o engenheiro de software do trabalho de desenvolver

componentes a partir do zero. Tais componentes devem ser submetidos a um processo de

composição de modo a funcionarem corretamente em um todo integrado. Tal composição

pode ser realizada em tempo de desenvolvimento (composição estática) ou pode dar-se em

tempo de execução (composição dinâmica).

Em atendimento ao princípio da modularização, as informações concernentes à

composição devem estar encapsuladas em uma unidade de design que possa ser facilmente

manipulada pelo engenheiro de software. Tal unidade deve encapsular a topologia

94

(configuração) resultante entre os elementos de computação (componentes) por meio dos

elementos de conexão (conectores). Caso as informações de composição estejam dispersas ou

entrelaçadas, sua modularização poderá ocorrer por meio de unidades aspectuais.

Quando o engenheiro de software concebe uma solução de software levando em

consideração o domínio da aplicação, diversas soluções genéricas para problemas recorrentes

no domínio podem ser desenvolvidas e, possivelmente, serão reutilizadas em diversos

projetos. No contexto particular de sistemas distribuídos, um amplo conjunto de soluções

poderá ser concebido visando atender necessidades comuns às aplicações pertinentes a esse

domínio, como por exemplo: controle de acesso, autenticação, tratamento de falhas,

transações distribuídas, controle de concorrência, distribuição, etc. Uma vez que tais

interesses são comprovadamente transversais, eles podem ser modularizados e representados

com clareza na forma de componentes aspectuais, inclusive em nível arquitetural.

Diretriz 5: Suporte às Atividades de Gestão de Projetos

Dada a dimensão dos atuais empreendimentos de desenvolvimento de sistemas de

software, algumas atividades, denominadas atividades guarda-chuva, são imprescindíveis ao

bom êxito dos projetos, dentre as quais se destacam: (a) Rastreamento das atividades ao longo

do ciclo de vida; (b) Gerenciamento de riscos; (c) Garantia de qualidade de software; (d)

Métricas; (e) Gerenciamento da configuração do software (PRESSMAN, 2006).

No contexto do gerenciamento de projetos de software, é fundamental a existência de

subsídios quantitativos extraídos dos artefatos produzidos ao longo do ciclo de vida, a fim de

que as tarefas de gerenciamento sejam levadas a efeito tendo como base parâmetros reais

oriundos do processo de software propriamente dito (ex.: tempo de início e de término de

tarefas, identificação do desenvolvedor responsável, interdependência entre tarefas).

A capacidade de rastreamento de alterações arquiteturais constitui-se em uma

solução eficaz para o arquiteto de software, proporcionando meios adicionais de

acompanhamento de projetos de desenvolvimento de software, principalmente aqueles cujo

desenvolvimento seja orientado à arquitetura. Uma meta associada (embora bastante

ambiciosa) é o rastreamento do implemento das decisões arquiteturais, de modo a poder

verificar se as decisões constantes na descrição arquitetural foram realmente levadas a efeito

nas fases subseqüentes.

Quando uma solução de apoio à engenharia de software não é projetada tendo em vista

o fornecimento dos dados necessários (preferencialmente quantitativos) às atividades de

95

gerenciamento de projeto, as possibilidades de automatização ficam drasticamente reduzidas

ou comprometidas. Portanto, a automatização das atividades de gerenciamento depende,

fortemente, das informações contidas nos artefatos produzidos ao longo do ciclo de vida do

software.

Ademais, uma das certezas que se tem a respeito de qualquer sistema de software é

que ele passará por uma evolução, pois ocorrerão modificações em situações tais como: (a) na

presença da correção de erros; (b) quando o software tiver que ser adaptado a um novo

ambiente; (c) quando o cliente solicitar novas características ou funções; e (d) quando a

aplicação tiver que passar por um processo de reengenharia a fim de se beneficiar (ou oferecer

benefícios) a partir de em um contexto mais atual.

As soluções de apoio à engenharia de software devem subsidiar um desenvolvimento

preventivo em relação à evolução do software, de modo que: (a) a complexidade resultante

da evolução não atinja um grau que inviabilize a manutenção do software; (b) novos

engenheiros de software possam ser incorporados à equipe de desenvolvimento ou de

manutenção; e (c) uma modificação em um software produza o menor impacto possível (ex.:

minimização da propagação de efeitos colaterais).

Diretriz 6: Suporte ao Desenvolvimento Distribuído de Software (DDS)

Ante ao fenômeno da globalização, muitas organizações, buscando custos menores e

acesso às pessoas melhor qualificadas, começaram a experimentar o desenvolvimento de

software com recursos localizados remotamente. A onda da terceirização também contribuiu

bastante para esta circunstância (HERBSLEB; MOITRA, 2001).

Os recursos tecnológicos atuais estão, visivelmente, caracterizados pela computação

ubíqua (comunicação e distribuição em massa, dispositivos móveis), a qual se apresenta na

forma da comunicação entre máquinas distribuídas e pessoas dispersas geograficamente – ao

invés de ser apenas uma comunicação entre dois indivíduos ou entre um indivíduo e uma

máquina (vide Capítulo 2).

Os fatores enumerados em (HERBSLEB; MOITRA, 2001), aliados aos reflexos da

computação ubíqua (ou, no mínimo, distribuída) também influenciaram, diretamente, os

conceitos e as tecnologias utilizados no desenvolvimento de software, os quais devem ser

repensados e, quando necessário, adaptados ao novo contexto. O conceito de ambiente de

desenvolvimento de software ilustra muito bem essa situação, pois sua arquitetura teve que

ser adequada a fim de, efetivamente, apoiar o desenvolvimento distribuído de software (vide

96

Capítulo 7). Neste sentido, pesquisas vêm sendo realizadas para que as tecnologias de

sistemas distribuídos possam ser usadas de forma inteligente e eficiente no âmbito do

desenvolvimento distribuído de software (PASCUTTI, 2002), (BATISTA, 2003), (PEDRAS,

2003), (MORO, 2003), (LIMA, 2004), (POZZA, 2005), (ENAMI, 2006), (WIESE, 2006) e

(SCHIAVONI, 2007), (HUZITA, 2007).

O desenvolvimento de sistemas complexos demanda a cooperação intensiva entre os

vários membros de um projeto com diferentes responsabilidades. O processo de

desenvolvimento é, freqüentemente, distribuído ao longo do tempo e do espaço e realiza-se

dentro e entre grupos de trabalho especializados.

Ambientes de desenvolvimento que, explicitamente, dão apoio ao trabalho em grupo,

são um importante pré-requisito para a produção de sistemas de software de alta qualidade.

Deste modo, uma das áreas que tem despertado o interesse de pesquisadores refere-se ao

estabelecimento de estudos relacionados ao apoio efetivo do envolvimento de diversos

profissionais que atuam cooperativamente no processo de desenvolvimento de software

(PASCUTTI, 2002).

A almejada interoperabilidade entre determinadas soluções de apoio à engenharia de

software visa proporcionar avanços no sentido de integrar as fases do ciclo de vida do

software. Contudo, há de se considerar que, no DDS, as atividades pertinentes a uma única

fase podem estar sob a incumbência de diversas equipes dispersas geograficamente, o que

pode ampliar a liberdade de escolha de soluções de apoio à engenharia de software, tornando,

assim, imprescindível o quesito interoperabilidade.

As ferramentas de groupware têm se tornado uma constante no mundo do

desenvolvimento de software, dada à grande necessidade de desenvolvimento colaborativo

inter-equipes. Contudo, as vantagens do Trabalho Cooperativo Auxiliado por Computador

(CSCW – Computer Supported Cooperative Work) estariam drasticamente reduzidas sem a

presença de soluções de apoio à engenharia de software inter-operáveis.

Uma realidade que tem se tornado cada vez mais presente é o desenvolvimento de

software com a filosofia open source (código aberto). As pessoas estão cada vez mais

aderindo a essa filosofia e utilizando soluções disponíveis na Web para a elaboração de suas

soluções de software. Contudo, o desenvolvimento open source consiste em um trabalho

eminentemente cooperativo, que requer soluções de apoio que contemplem o

desenvolvimento distribuído de software.

97

Muitas ferramentas CASE utilizadas nos projetos de software estão sendo

disponibilizadas com o código aberto (ex.: Eclipse, Net Beans), o que pode gerar uma

interdependência entre os desenvolvedores da comunidade de usuários dessas ferramentas.

Deve ser salientado que a oferta cada vez maior de ferramentas de código aberto constitui-se

em um fator influenciador no ato de escolha da ferramenta CASE.

6.3 Interdependência das Diretrizes

Quando analisadas em conjunto, nota-se uma influência mútua entre as diretrizes. A

Tabela 6.1 mostra essa relação da seguinte forma: a influência exercida pelas diretrizes

constantes nas linhas sobre as diretrizes constantes nas colunas está assinalada com um X na

sua intersecção. Exemplo: a Diretriz 6 (linha) “Suporte ao desenvolvimento distribuído de

software” influencia diretamente na consecução da Diretriz 3 “Automatização de tarefas”.

• Diretriz 1: Suporte aos Limites Naturais da Cognição e do Intelecto Humano

• Diretriz 2: Adoção de um Modelo de Processo de Software

• Diretriz 3: Automatização de Tarefas

• Diretriz 4: Reuso

• Diretriz 5: Suporte às Atividades de Gestão de Projetos

• Diretriz 6: Suporte ao Desenvolvimento Distribuído de Software

Tabela 6.1 – Influência recíproca entre as diretrizes norteadores

Diretriz 1 2 3 4 5 6 1 X X X X X 2 X X X X X 3 X X X X 4 X X X 5 X X 6 X X X X

6.4 Desiderata: características desejáveis em uma ADL-OA

A estrutura dos textos explicativos sobre as características foi concebida com vistas a

constituir um conjunto mínimo de informações para que o leitor compreenda a real

necessidade de cada uma das características.

• Explicação: texto descritivo apresentando em que consiste a característica; explica porque

a presença de tal característica é imprescindível ao design de arquiteturas OA.

• Utilidade: apresenta as vantagens diretas da presença da característica em uma ADL-OA,

explicando quando tal capacidade de ADL pode ser usada durante as atividades de design

arquitetural.

98

• Requisitos necessários à sua realização: são mostrados quais recursos adicionais (em

relação a uma ADL não OA) tais como recursos sintáticos e semânticos, capacidades de

expressão, elementos estruturais, etc., uma ADL-OA deve prover para que tal

característica possa ser levada a efeito.

• Diretrizes atendidas: apresentadas na Tabela 6.2 (vide Seção 6.6), referenciam as

diretrizes que fundamentais para o estabelecimento da característica em questão.

• Características relacionadas: constam na Tabela 6.3 (vide Seção 6.6), trata-se de uma

forma de mostrar as influências mútuas entre as diversas características listadas.

Por questão de clareza, o conjunto de características desejáveis em uma ADL-OA foi

subdividido em três subconjuntos principais, como segue:

I. Características relacionadas à notação de design arquitetural:

1) Aspectos arquiteturais como elementos de primeira classe;

2) Componentes aspectuais e Conectores aspectuais;

3) Representação de middlewares como conectores;

4) Modelagem de composição dinâmica;

5) Extensibilidade dos recursos de modelagem da ADL;

6) Aspectos arquiteturais built-in inerentes ao domínio;

7) Uso de bibliotecas de estilos/padrões arquiteturais;

8) Uso de bibliotecas de aspectos arquiteturais;

9) Notação visual correspondente; e

10) Formalismo subjacente.

OBS.: os itens 7 e 8 transcendem o primeiro subconjunto e estão também associados às

características relacionadas às ferramentas de apoio.

II. Características relacionadas ao método de design arquitetural:

1) Identificação de aspectos arquiteturais.

2) Avaliação/Validação arquitetural apoiada por ADLs;

3) Controle de alterações dinâmicas.

III. Características relacionadas à ferramenta de apoio:

1) Imposição da arquitetura: verificação do design detalhado e da implementação;

2) Verificação do estilo ou padrão arquitetural;

3) Rastreabilidade das alterações arquiteturais ao longo do ciclo de vida.

99

6.4.1 – Características Relacionadas à Notação de Design Arquitetural

1.1.1.1. Aspectos arquiteturais como elementos de primeira classe

Defende-se que uma ADL-OA apresente capacidade de modelagem de interesses

arquiteturais transversais por meio de uma abstração particular, qual seja, uma unidade

explicitamente aspectual. Tais construtores de design devem ser elementos que não exijam

qualquer extensão adicional por parte do usuário da ADL-OA. A notação não deve exigir

esforços de seu usuário no sentido de criar abstrações a partir dos tipos primitivos da

linguagem com o objetivo de modelar os aspectos arquiteturais. Esta característica está

estreitamente relacionada à capacidade de expressão da linguagem.

Considerando que uma das metas da documentação/descrição arquitetural é a de servir

como meio de comunicação entre os stakeholders do projeto, não é interessante manter uma

mesma abstração para representar componentes convencionais e aspectos: deve ficar explícito

na descrição arquitetural que um determinado interesse é transversal (tem comportamento

disperso ou entrelaçado), ou seja, é aspectual (para ser modularizado deve-se lançar mão dos

recursos do DSOA). O implemento dessa característica depende da definição da sintaxe e

semântica da ADL-OA.

2.2.2.2. Componentes e Conectores aspectuais

O componente é, por excelência, a sede da computação do sistema de software.

Contudo, alguns interesses arquiteturais, diretamente relacionados às tarefas de computação,

podem estar dispersos e isso leva à conclusão de que, por uma questão de coerência e de

legibilidade, tais interesses devem ser modelados na forma de componentes aspectuais.

Uma conexão arquitetural compreende os elementos envolvidos nas interações de

componentes, tais como interfaces, conectores e configurações arquiteturais. As abstrações

para expressar as conexões arquiteturais desempenham um papel importante no design de

arquitetura em ADLs. Portanto, com o advento do DSOA, há uma necessidade de entender a

adequação das abstrações e conexões convencionais das ADLs a fim de capturar a natureza

transversal dos interesses arquiteturais.

Conseqüentemente, os conectores são capazes de representar tanto as interações entre

os componentes convencionais quanto entre componentes aspectuais. Semelhantemente, há a

possibilidade de entrelaçamento e dispersão das regras de coordenação ao longo da

arquitetura, o que nos leva a considerar a necessidade de conectores aspectuais. Ressalta-se

que o conceito de aspecto em AspectJ modela tanto a computação quanto a interação.

100

3.3.3.3. Representação de middlewares como conectores

Boa parte dos sistemas distribuídos são implementados sobre middlewares off-the-

shelf tais como CORBA, RMI, DCOM e .NET. Entretanto, no âmbito de alguns projetos de

sistemas de software distribuídos, os designers optam pelo desenvolvimento de middlewares

próprios, a partir do zero. Alguns trabalhos (DASHOFY; MEDVIDOVIC; TAYLOR, 1999)

(MEDVIDOVIC; DASHOFY; TAYLOR, 2003) (MIKIK-RAKIK; MEDVIDOVIC, 2003)

classificam middlewares como conectores.

As questões suscitadas aqui são as seguintes: Como as ADLs-OA podem dar suporte à

modelagem arquitetural representando as interações dos interesses transversais com os

elementos pertencentes ao middleware? Quais características especiais uma ADL-OA deve

prover a fim de permitir a descrição arquitetural com conectores representados como

middleware no contexto da arquitetura do software?

Como visto no Capítulo 2, um middleware comporta-se como um conector composto

especial, consistindo em uma camada de software que serve de interface entre os aplicativos

distribuídos e a plataforma subjacente, oferecendo serviços de infra-estrutura aos aplicativos.

Entretanto, alguns dos serviços oferecidos pelos middlewares devem ser modelados, em nível

arquitetural, na forma de aspectos.

Defende-se que uma ADL-OA seja capaz de: representar, explicitamente, middlewares

na forma de conectores; modelar, expressamente, diferentes tecnologias de middleware em

uma única arquitetura; e representar os conectores aspectuais como sendo um composto de

componentes e conectores.

4.4.4.4. Modelagem de Composição Dinâmica

Uma das principais características dos sistemas distribuídos é o dinamismo de suas

arquiteturas. É desejável que um sistema distribuído mantenha-se operável ainda que uma

parcela de suas partes constituintes se torne indisponível e, conseqüentemente, este requisito

pode levar à alteração da configuração da arquitetura do sistema em tempo de execução.

Dada essa possibilidade de re-configuração dinâmica da arquitetura (principalmente

quando se tratar de um sistema distribuído e com componentes móveis) torna-se

imprescindível a capacidade de modelagem de composição dinâmica, a qual está

estreitamente relacionada com a capacidade de controle de alterações dinâmicas.

101

Em nível arquitetural, a informação referente ao tempo em que ocorrerá a composição

deve estar compreendida entre as demais informações de design de modo a viabilizar as

devidas análises arquiteturais. Além disso, segundo (PAWLAK et al., 2004) há o conceito de

aspectos dinâmicos – os quais são adicionados e removidos da estrutura do sistema – que

fornece uma abordagem interessante para se descrever o dinamismo arquitetural, o qual é

particularmente complexo. No âmbito dos sistemas distribuídos, as arquiteturas dinâmicas

ocorrem com freqüência, e é essencial que o suporte às arquiteturas dinâmicas seja

acompanhado de mecanismos de composição em tempo de execução21.

5.5.5.5. Extensibilidade dos recursos de modelagem da ADL

Conforme exposto no Capítulo 4, existe uma ampla gama de ADLs, cada qual se

propondo a modelar diferentes conjuntos específicos de características do sistema. Entretanto,

para ser útil em um contexto prático do mundo real, a pesquisa em arquitetura de software

deve avançar além das notações para propósitos específicos, pois uma arquitetura deve

capturar, simultaneamente, os mais variados aspectos de um sistema de software.

É notório que as ADLs existentes são muito específicas (ex: ADLs para um único

propósito, como Rapide, Darwin, ou SADL) ou muito genéricas (ex: ACME). Ademais, o

custo para adaptar uma notação (e suas ferramentas) para dar suporte a uma nova

característica pode ser muito elevado. Via de regra, as atuais ADLs foram desenvolvidas sem

levar em consideração o reuso ou a extensão do seu próprio design, e essa abordagem pode

fazer com que o esforço de adaptação da notação existente para um novo propósito seja

proporcional ao desenvolvimento de uma nova notação a partir do zero.

Outro fator a ser destacado é que o conjunto de características relevantes a serem,

necessariamente, modeladas pode variar de um domínio para outro. Por exemplo, os projetos

de software embutidos podem requerer capacidade de modelagem detalhada para representar

o consumo de tempo e energia, ao passo que os sistemas distribuídos podem exigir recursos

de modelagem para aspectos relacionados a tolerância a falhas e uso de largura de banda.

A despeito deste amplo conjunto de necessidades em diferentes domínios, existem

necessidades de modelagem que podem ser compartilhadas por muitos projetos (ex.: atributos

de projeto). Os arquitetos de sistemas embutidos e de sistemas distribuídos podem necessitar

de capacidades para lidar com o rastreamento e gerenciamento da evolução de arquiteturas à

medida que ocorrem as liberações das versões dos produtos de software. Obviamente, os

21 Vide Seção 6.6.1 referente à Proposta de Notação Visual

102

projetos dentro de um domínio particular, normalmente, poderão ter conjuntos maiores de

interesses comuns.

A questão da extensibilidade de ADLs foi tratada em (LICHTNER; ALENCAR;

COWAN, 2000) e (DASHOFY; van der HOEK; TAYLOR, 2005). Este último trabalho

apresenta uma abordagem que permite a construção rápida de novas ADLs: propõe o

encapsulamento das características de ADLs em módulos que são compostos para formar

ADLs. Os autores atingem este objetivo utilizando-se dos mecanismos de extensão fornecidos

por XML e XML Schemas: foi definido um conjunto de módulos genéricos e reusáveis de

ADL denominado xADL 2.0, extensível para apoiar novas aplicações e novos domínios. Para

apoiar a extensibilidade, foi desenvolvido um conjunto de ferramentas, baseadas em sintaxe

reflexiva, que se adaptam automaticamente às alterações da linguagem, assim como diversas

ferramentas que fornecem suporte para características avançadas da xADL 2.0.

Em (LICHTNER; ALENCAR; COWAN, 2000) é apresentado um modelo formal de

descrição de arquitetura: tal modelo formaliza os conceitos de design genéricos que são

comuns às muitas ADLs popularmente conhecidas, incluindo as principais categorias de

informação de design, seus inter-relacionamentos e restrições. O modelo foi desenvolvido

com o interesse principal de servir como uma base para um framework. As principais

categorias de design foram particionadas em um componente núcleo e em um conjunto de

extensões, permitindo a adição de informações de design úteis, ao passo que permite também

a remoção de informações menos relevantes quando estas não forem necessárias.

Conclui-se que uma infra-estrutura intermediária (fazendo o papel de uma máquina

virtual) teria a principal finalidade de possibilitar ao arquiteto estender a ADL-OA, optando

por características comuns do sistema (em nível arquitetural), e escolher as características que

sejam relevantes e que deseja modelar, a fim de adicioná-las na notação. Uma questão que

deve ser explorada é como garantir a compatibilidade semântica entre as características de

ADLs-OA: o uso de ontologia pode prover uma solução a este problema.

6.6.6.6. Aspectos arquiteturais built-in inerentes ao domínio

Sistemas de software pertencentes a um mesmo domínio, geralmente, apresentam

interesses comuns. Em se tratando de interesses transversais, uma solução pode ser a sua

modularização na forma de aspectos, os quais podem ser armazenados em uma biblioteca de

aspectos com a finalidade de serem reutilizados em projetos diversos.

103

Pelo fato de serem inerentes a um determinado domínio, alguns aspectos estarão

presentes na maioria das aplicações pertinentes. Por exemplo, os sistemas distribuídos

apresentam os seguintes aspectos comuns: persistência, tolerância a falhas, autenticação,

criptografia, distribuição (concorrência), manipulação de erros e sincronização

(compartilhamento de recursos).

Considerando que o design arquitetural de uma aplicação distribuída exigirá a

presença de componentes e conectores aspectuais previsíveis (como os citados anteriormente),

é de grande utilidade ao arquiteto de software que uma ADL-OA ofereça tais aspectos na

forma de blocos de construção pré-implementados e nativos (do tipo built-in: aqui

denominados de aspectos nativos). Tal capacidade tende a aumentar o poder de expressão da

linguagem e minimizar o esforço de desenvolvimento por parte do arquiteto, inclusive com a

redução das possibilidades de erros decorrentes do uso incorreto da ADL, pois os aspectos

nativos podem ser oferecidos ao usuário da ADL-OA na forma de primitivas da linguagem.

Também será de grande utilidade ao arquiteto a capacidade de criação de novos aspectos

nativos (neste ponto, a extensibilidade da linguagem é imprescindível).

O uso reiterado de aspectos em um mesmo domínio pode culminar com a descoberta

de novos estilos ou padrões arquiteturais: se a ferramenta de apoio à ADL-OA for

implementada com a capacidade de inferir as regras comuns que governam as interações entre

componentes e aspectos arquiteturais, um novo estilo pode ser deduzido automaticamente

pela própria ferramenta, com base em um mecanismo de descoberta de estilos. Essa

capacidade requer um alto grau de formalismo na notação.

Emerge uma questão importante: Quais capacidades adicionais uma ADL-OA deve

prover para que essa capacidade possa ser implementada? A solução pode ser obtida a partir

do desenvolvimento da sintaxe e semântica da ADL: a linguagem deve oferecer condições

para que novos tipos sejam definidos e declarados pelo usuário (arquiteto de software).

7.7.7.7. Biblioteca de aspectos arquiteturais

Uma ADL com a capacidade de utilizar elementos arquiteturais armazenados em uma

biblioteca impulsionará o trabalho do arquiteto de software, possibilitando ao mesmo manter

armazenado e recuperar componentes, conectores e configurações (aspectuais ou não)

conforme as necessidades do projeto em mãos.

Aspectos clássicos, relacionados aos interesses transversais, tais como realização de

log (logging), tratamento de erros, controle de concorrência, controle de acesso, segurança e

104

persistência (GARCIA et al., 2004), entre outros, poderão ser providos pela própria ADL-OA

na forma de aspectos built-in. Entretanto, alguns interesses funcionais também podem ser

transversais. Em se tratando de interesses típicos de um determinado domínio, o arquiteto de

software poderá modelá-los na forma de aspectos e armazená-los em repositórios, de maneira

que possam ser reutilizados em projetos futuros.

Emerge a questão: Quais recursos adicionais uma ADL-OA deve prover a fim de

permitir o reuso de aspectos armazenados em bibliotecas? A capacidade de definição e

declaração de novos tipos, e a capacidade de uso de bibliotecas de aspectos constitui-se nos

recursos úteis para a solução dessa questão. Tal capacidade depende da definição sintática e

semântica da ADL.

8.8.8.8. Biblioteca de estilos/padrões arquiteturais

Caso a ADL forneça capacidades que permitam ao desenvolvedor descrever as linhas

gerais de estilos/padrões arquiteturais (com vistas ao armazenamento e recuperação em uma

biblioteca), o trabalho do arquiteto de software pode ser reduzido significativamente, além de

provocar, conseqüentemente, o aprimoramento das soluções.

Emerge uma questão importante: Quais recursos adicionais uma ADL-OA deve prover

a fim de permitir o reuso de estilos/padrões armazenados em bibliotecas? Tal meta pode ser

atingida ao se projetar uma ADL-OA com capacidade de descrição de configurações

arquiteturais com vistas ao reuso: de modo que tais configurações possam ser armazenadas

em uma biblioteca e reutilizadas em projetos futuros. A idéia de reutilização pode ser

estendida ao campo dos estilos e padrões arquiteturais.

9.9.9.9. Notação visual (gráfica) correspondente

Não obstante toda ADL possa ser considerada, por excelência, uma notação formal, é

indispensável que haja uma notação visual correspondente capaz de ilustrar, de modo mais

intuitivo e simplificado, por meio de diagramas e figuras, a idéia que a representação

arquitetural intenta transmitir.

Normalmente, as pessoas possuem mais habilidade para lidar com representações

visuais (figuras ou diagramas) do que com modelos matemáticos (formalismos e simbolismo

matemáticos). A leitura do contexto deve preceder a leitura da descrição (FREIRE, 2003).

Todavia, a notação visual deve estar estreitamente associada a um formalismo subjacente.

A UML tem se tornado uma notação padrão já consagrada, tanto na indústria de

software quanto na academia. Visto que os artefatos de software resultantes nos estágios mais

105

avançados da etapa de design são representados, geralmente, em UML, é interessante que a

arquitetura do software seja descrita em uma ADL-OA inter-operável com a UML.

Novamente a solução reside no uso de uma linguagem padrão (ex.: XML).

Há trabalhos que utilizaram como recurso a UML 2.0 Profile para o desenvolvimento

de uma notação visual baseada em UML (OQUENDO, 2006). Em (ALDAWUD; ELRAD;

BADER, 2003) a UML 2.0 Profile é utilizada no contexto do DSOA.

10.10.10.10. Formalismo subjacente

A presença de qualquer formalismo matemático garante um nível de precisão que está

além das capacidades das notações informais ou semi-formais. Além disso, muitas das

funcionalidades apresentadas pelas ferramentas CASE associadas são implementadas tendo

em vista os códigos dos artefatos (as ferramentas não trabalham com figuras). Grande parte

das análises arquiteturais, assim como os processos de validação com fundamento

matemático, podem ser computacionalmente implementados com base em formalismos.

Em uma perspectiva computacional, as notações formais podem ser entendidas como a

linguagem utilizada pela máquina. O quão mais formais, precisas e concisas forem suas

sintaxe e semântica, e maior o seu poder de expressão, tão menor será o esforço de

processamento demandado na sua análise. A maioria das ADLs convencionais foram

desenvolvidas com base em algum formalismo, tais como π-Calculus, CSP, Redes de Petri;

porém há problemas relacionados às limitações de interoperabilidade entre essas diversas

notações. Portanto, é necessário que a notação, na qual se baseia uma ADL-OA, seja definida

e especificada com base em certo grau de formalismo (suficiente para que os resultados das

análises realizadas pelas ferramentas sejam consistentes).

Uma questão que ainda deve ser estudada é o quão adequados são esses formalismos

para a modelagem das abstrações e mecanismos tipicamente aspectuais, principalmente no

que tange à modelagem da composição dinâmica de aspectos.

6.4.2 – Características Relacionadas ao Método de Design Arquitetural

1.1.1.1. Identificação de Aspectos Arquiteturais

Os chamados aspectos preliminares são interesses que entrecortam a decomposição

dominante de um artefato (realizada por meio de visões arquiteturais), ou módulos básicos

derivados do critério de separação de interesses, nos estágios preliminares do ciclo de vida do

software. Um aspecto na arquitetura é um interesse que entrecorta artefatos arquiteturais

(BANIASSAD et al., 2006).

106

Identificar e gerenciar aspectos preliminares ajuda a aprimorar a modularidade no

design da arquitetura e detectar interesses conflitantes preliminarmente, quando os trade-offs

podem ser resolvidos mais economicamente. Tomar conhecimento de aspectos em nível

arquitetural tem como conseqüência uma implementação mais robusta.

Alguns tratamentos de arquitetura representam as estruturas e outras informações

arquiteturais como um conjunto de visões, cada qual mostrando determinados tipos de

elementos e os relacionamentos correspondentes entre esses elementos. Os três tipos básicos

de visões são: módulo, componente-e-conector, e alocação (vide Capítulo 3). Algumas visões

são híbridas, comunicando informações pertencentes a mais do que uma dessas famílias.

Um arquiteto projeta as estruturas nativas a cada uma das visões para atingir as metas

de qualidade e de comportamento do sistema. Um processo de elaboração de arquitetura

baseado em visões poderá revelar atributos comuns intra-visões ou transversais-a-visões, que

o arquiteto pode capturar como sendo aspectos (BANIASSAD et al., 2006).

Baniassad et al. (2006) consideram que as próprias visões formam a decomposição

dominante da arquitetura. O ponto chave da abordagem arquitetural multivisão é livrar-se da

idéia de que os sistemas têm apenas uma estrutura ou estilo determinando a decomposição. A

decomposição é hierárquica, uma vez que as visões têm subestruturas. O arquiteto pode

decompor uma visão em “pacotes de visões” que mostram pequenas partes do sistema em

grande profundidade, ou partes maiores do sistema em profundidade.

Os aspectos na arquitetura manifestam-se como interesses que entrecortam visões ou

partes de visões. Baniassad et al. (2006) descrevem as principais atividades a respeito dos

aspectos arquiteturais, quais sejam: identificar, capturar, compor e analisar.

Em (BASS; KLEIN; NORTHROP, 2004) os autores afirmam estar desenvolvendo um

método para derivar uma arquitetura de software a partir de seus requisitos de atributos de

qualidade, por meio de insights obtidos à partir de modelos de atributos de qualidade

denominados táticas arquiteturais. Os autores acreditam que algumas das descobertas que

ocorrem durante o processo de derivação podem ser vistas como aspectos candidatos. Em

particular, o processo de derivação ilustra o que os autores chamam de aspectos arquiteturais.

Esses autores afirmam que os aspectos arquiteturais surgem como análogos arquiteturais de

comportamento transversal (advice), conjuntos de pontos de junção (pointcuts), e pontos de

107

junção (join points). Os aspectos candidatos são aspectos para serem executados através de

um design detalhado e implementados usando a POA.

Atributos de qualidade são propriedades como: confiabilidade, segurança, usabilidade,

modificabilidade, desempenho, portabilidade, etc. Alguns domínios de aplicação possuem

interesses que lhes são inerentes de modo que, desde o início do desenvolvimento da

arquitetura, o arquiteto já pode ter consciência dos principais componentes e aspectos que

farão parte da arquitetura. Entretanto, alguns interesses podem escapar a essa análise

preliminar, fazendo com que a arquitetura continue com interesses transversais não

modularizados (principalmente quando se tratar de interesse funcional, mas nada impede que

até mesmo um interesse relacionado a atributo de qualidade e de projeto permaneça não

modularizado).

Geralmente, o arquiteto de software inicia seu trabalho de análise tendo em mente

alguns interesses transversais, bastando apenas modularizá-los na forma de aspectos

arquiteturais. Inclusive, o arquiteto pode recorrer à lista dos clássicos (anteriormente citados)

sem, no entanto, descartar a presença de algum outro aspecto que não esteja tão aparente.

Há duas formas de verificar essa situação: mentalmente, por meio da aplicação mental

de heurísticas adequadas (ex.: método ASAAM); ou por meio de uma ferramenta, a qual toma

como base a descrição arquitetural e a submete a uma análise computacional com vistas a

detectar a presença de algum aspecto, o qual não se encontra visível aos olhos do arquiteto.

A meta é que a própria ADL-OA forneça subsídios suficientes para que seu conjunto

de ferramentas de suporte disponha dos recursos adequados para a identificação automática

dos interesses transversais (fazendo uso de regras heurísticas ou outro tipo de método, ex.:

ASAAM). Esta capacidade é bastante útil quando tratar-se de aspectos funcionais, inerentes a

um determinado domínio de aplicação.

Os dados da topologia da arquitetura, presentes na configuração arquitetural,

juntamente aos dados referentes às interfaces, descritos pela ADL, são os recursos úteis para

proporcionar a capacidade de identificação de aspectos. A identificação de aspectos seria uma

função desempenhada pela ferramenta de ADL, a qual teria embutida, por exemplo, um

conjunto de regras heurísticas cuja aplicação proporcionaria a captura de aspectos.

2.2.2.2. Avaliação/Validação da arquitetura apoiada por ADLs

108

Há na literatura diversos métodos de análise de arquitetura: SAAM, ATAM, ARID

(CLEMENTS; KAZMAN; KLEIN, 2002) e ASAAM (TEKINERDOGAN, 2004). Nenhum

deles faz referência sobre uso automatizado da descrição arquitetural representada por ADLs.

Uma abordagem de avaliação arquitetural pode se valer dos recursos oferecidos por

notações formais de design arquitetural a fim de produzir resultados mais precisos e

estritamente condizentes com as decisões de design incorporadas na descrição arquitetural.

Uma análise apoiada por uma ferramenta de ADL produzirá resultados mais consistentes,

confiáveis e precisos.

Para que essa meta seja atingida, é necessário que a notação ofereça os subsídios

necessários para a avaliação (ex.: modelagem do uso de largura de banda, composição

dinâmica de aspectos), ou que pelo menos seja possível a sua extensão, em tempo de design.

Tal abordagem permite a adição de informações de design úteis aos métodos de análise

arquitetural

3.3.3.3. Controle de alterações dinâmicas

Um dos fatores complicadores no desenvolvimento de modelos arquiteturais reside no

design de sistemas cujas arquiteturas alteram-se dinamicamente (durante o tempo de

execução); fator esse que tem presença marcante no domínio de sistemas distribuídos. Isto se

deve ao fato de que as alterações dinâmicas estruturais podem interagir de modo sutil com as

computações em andamento. O paradigma OA prevê dois modos de composição de aspectos:

estática e dinâmica.

Arquitetura “dinâmica” diz respeito aos sistemas para os quais a composição de

componentes de interação altera-se durante o curso de uma única computação. Esse problema

foi tratado inicialmente em (ALLEN; DOUENCE; GARLAN, 1998).

Há muitos aspectos de um sistema de software que podem ser tratados em uma

descrição arquitetural e que podem ser afetados mediante a alteração dinâmica, incluindo

comportamento funcional, alocação de recursos, desempenho, tolerância a falhas,

flexibilidade em face de requisitos alterados, etc.

Uma ADL-OA deve fornecer recursos para a modelagem comportamental do sistema,

permitindo a imposição de restrições na configuração arquitetural. Neste sentido, a questão da

inter-operabilidade é essencial para o cumprimento desse desiderato, pois é comum que um

sistema distribuído apresente considerável grau de heterogeneidade.

109

6.4.3 – Características Relacionadas às Ferramentas de Apoio

1.1.1.1. Imposição da arquitetura: verificação do design detalhado e da implementação

A atividade de desenvolvimento de software compreende uma série de etapas que,

classicamente, inicia-se na fase de levantamento de requisitos e estende-se até à fase de

manutenção. A fase de design arquitetural encontra-se entre as etapas preliminares, e as

decisões de design contidas na descrição arquitetural podem não ser respeitadas nas fases

subseqüentes.

Essa possível incongruência entre a arquitetura do software e os produtos das

atividades realizadas nas fases subseqüentes (análise, implementação e manutenção) pode ser

oriunda dos seguintes fatores: alterações dos requisitos funcionais; limitações tecnológicas

nas etapas de análise e implementação subseqüentes; descoberta de soluções mais adequadas;

e até mesmo por falhas humanas na execução das tarefas relacionadas. Tais ações acarretam a

denominada erosão arquitetural.

Seria vão e ineficaz um grande esforço na fase de design arquitetural se as fases

subseqüentes não seguissem à risca as decisões incorporadas na documentação arquitetural.

Há alguns trabalhos nesse sentido, como por exemplo ArchJava (ALDRICH; CHAMBERS;

NOTKIN, 2002-a) e DAOP-ADL (PINTO et al., 2003), que prezam pela verificação da

compatibilidade entre a arquitetura e a implementação, porém há uma dependência entre a

ADL e a LP usada na implementação.

Ao fornecer uma forma de verificar se a implementação está acontecendo conforme as

decisões arquiteturais incorporadas na descrição arquitetural durante a fase de análise, a ADL

torna-se capaz de impedir (ou minimizar) a erosão arquitetural. Em parte, o problema da

erosão arquitetural decorre da não obediência às decisões arquiteturais preliminares.

A questão suscitada nesse momento é a seguinte: “Seria possível impor a arquitetura

às fases subseqüentes? Em caso afirmativo, seria possível tornar a ADL independente da LP?

Como essa independência poderia ser levada a efeito?

A imposição é possível desde que haja uma forma de confrontar a descrição

arquitetural com o design detalhado e, na seqüência, com o código fonte. Neste ponto surge

um problema de semântica das informações, o qual pode ser resolvido por meio de um

“tradutor” capaz de abstrair informações de níveis inferiores para o nível arquitetural. É

bastante provável que o uso de conceitos de ontologia seja eficaz nessa tarefa de abstração.

110

A questão da independência da ADL em relação à LP pode ser alcançada mediante o

conceito de abstração presente em uma máquina virtual: uma camada intermediária entre o

nível arquitetural e o código fonte. Se o design detalhado estiver estritamente compatível com

a descrição arquitetural, essa questão torna-se mais simples, pois a verificação da

compatibilidade entre o design detalhado e a implementação já apresenta soluções (geração de

código fonte e engenharia reversa).

2.2.2.2. Verificação do estilo ou padrão arquitetural

A utilização de estilos ou padrões em uma determinada arquitetura de software tem

muitas vantagens, como a agregação de uma solução já comprovada dentro de um contexto ou

domínio delimitado. A erosão poderá ocorrer em todas as fases subseqüentes, mas pode

ocorrer, inclusive, na própria etapa de design em nível arquitetural, decorrente de freqüentes

atualizações da arquitetura.

Há situações em que o arquiteto de software se aprofunda em refinamentos sucessivos,

ou que a arquitetura começa a ganhar uma dimensão que vai além daquela em que o arquiteto

é capaz de manter sob controle meramente intelectual (com base nas regras específicas do

estilo). Assim, surge a necessidade de um recurso de monitoramento e restrição das ações do

arquiteto, isto é, coibindo suas ações, quando estas violarem as regras do estilo (é possível até

mesmo permitir a ação, mas notificar o arquiteto de que as regras do estilo estão sendo

violadas).

É de se esperar que uma dada arquitetura venha a ser elaborada não apenas com base

em um único estilo (arquiteturas híbridas), e essa possibilidade justifica ainda mais a

necessidade de um suporte automático a fim de aliviar a sobrecarga cognitiva exigida do

arquiteto. É fato que o atendimento aos requisitos não funcionais (de projeto e de qualidade)

está estreitamente relacionado à qualidade arquitetural, entretanto, uma vez que o arquiteto

tenha decidido por um determinado estilo, é bastante salutar que ele possa permanecer

despreocupado com tais questões durante o restante do design em nível arquitetural.

Almeja-se uma ferramenta que efetue a verificação da compatibilidade da arquitetura

descrita em relação a um determinado estilo previamente documentado e devidamente

armazenado em biblioteca. Os dados necessários à verificação de compatibilidade com estilos

e padrões estão compreendidos nas informações referentes à configuração arquitetural e às

interfaces dos elementos arquiteturais descritas por meio da ADL-OA.

111

3.3.3.3. Rastreabilidade das alterações arquiteturais ao longo do ciclo de vida

As alterações arquiteturais, quando não devidamente gerenciadas, podem ser

prejudiciais, acarretando, entre outras conseqüências, o aumento nos custos de manutenção e a

discrepância da documentação frente ao produto implementado. Tais conseqüências

inviabilizariam todo o esforço realizado na fase de design arquitetural.

Uma ferramenta de ADL apresentando a capacidade de rastreamento de alterações

arquiteturais constitui-se num recurso ideal para os gerentes de projeto, proporcionando meios

adicionais para o acompanhamento do projeto centrado na arquitetura.

A capacidade de rastreamento das alterações arquiteturais ao longo do ciclo de vida,

com vistas a minimizar a erosão arquitetural, requer mecanismos especiais implementados

pela ferramenta da ADL (ex.: registro do histórico da arquitetura, motivos das alterações e

responsáveis), assim como algumas propriedades adicionais na própria notação, como por

exemplo a verificação da compatibilidade entre a descrição arquitetural inicial e artefatos

gerados posteriormente (ex.: caso a arquitetura seja alterada depois que o design detalhado

tenha sido realizado, é necessário verificar a compatibilidade de ambos, ou pelo menos alertar

o arquiteto sobre esse fato). A capacidade de refinamento arquitetural é também

imprescindível.

É importante que tanto o arquiteto como o gerente de projeto disponham de algum

recurso de controle por meio do qual seja possível gerenciar de modo seguro, confiável e

racional a possível seqüência de alterações. O gerenciamento racional apoiado por uma

ferramenta de ADL ajudará a evitar que alterações em fases subseqüentes possam provocar

incongruências entre as decisões arquiteturais iniciais.

O rastreamento pode ser levado a efeito por meio da integração das etapas do ciclo e

vida do software, com vistas a permitir a verificação da compatibilidade entre a arquitetura

inicial e os artefatos das fases subseqüentes: design detalhado; implementação; atualizações e

alterações na manutenção do software.

6.5 Relações entre Diretrizes e Características

A Tabela 6.2 mostra as relações existentes entre as diretrizes norteadoras e o elenco de

características desejáveis; a intersecção entre uma linha (característica) e uma coluna (diretriz)

assinalada, indica que a característica participa do atendimento à respectiva diretriz. Exemplo:

a Característica 8 (Grupo 1) “Uso de bibliotecas de aspectos arquiteturais” é essencial para

que a Diretriz 3 “Automatização de tarefas” seja atendida.

112

I. Características relacionadas à notação de design arquitetural:

1) Aspectos arquiteturais como elementos de primeira classe;

2) Componentes aspectuais e Conectores aspectuais;

3) Representação de middlewares como conectores;

4) Modelagem de composição dinâmica;

5) Extensibilidade dos recursos de modelagem da ADL;

6) Aspectos arquiteturais built-in inerentes ao domínio;

7) Uso de bibliotecas de estilos/padrões arquiteturais;

8) Uso de bibliotecas de aspectos arquiteturais;

9) Notação visual correspondente; e

10) Formalismo subjacente.

II. Características relacionadas ao método de design arquitetural:

1) Identificação de aspectos arquiteturais.

2) Avaliação/Validação arquitetural apoiada por ADLs;

3) Controle de alterações dinâmicas.

III. Características relacionadas à ferramenta de apoio:

1) Imposição da arquitetura: verificação do design detalhado e da implementação;

2) Verificação do estilo ou padrão arquitetural;

3) Rastreabilidade das alterações arquiteturais ao longo do ciclo de vida.

Tabela 6.2 – Diretrizes norteadoras atendidas pelas características desejáveis

Característica Diretriz

Suporte a Limites Cognitivos

Modelo de Processo

Automatização Reuso Gestão de Projetos

Desenv. Distribuído

Grupo 1

1 X X X X X 2 X X X X X 3 X X X X X 4 X X X X X X 5 X X X 6 X X X X X X 7 X X X X X X 8 X X X X X X 9 X X X X

10 X X X

Grupo 2 1 X X X X X X 2 X X X X X 3 X X X X X X

Grupo 3 1 X X X X X 2 X X X X X 3 X X X X X X

113

A Tabela 6.3 mostra as relações existentes entre as próprias características; a

intersecção entre uma linha e uma coluna assinalada, indica que uma característica está

diretamente associada à outra. Exemplo: a Característica 4 (Grupo 1) “Modelagem de

composição dinâmica” está diretamente relacionada à Característica 3 (Grupo 2) “Controle de

alterações dinâmicas”.

Tabela 6.3 – Inter-relacionamento das características desejáveis em uma ADL-OA

Características Grupo 1 Grupo 2 Grupo 3

1 2 3 4 5 6 7 8 9 10 1 2 3 1 2 3

Grupo 1

1 X X X X X X X 2 X X X X X X X X X 3 X X X X X X X X 4 X X X X X X X X X X X 5 X X X X X X X X X 6 X X X X X X X X X 7 X X X X X X X X X X X X X 8 X X X X X X X X 9 X X X X X X X X X X

10 X X X X X X X X X X X X X X X

Grupo 2 1 X X X X X X X X X X X X X 2 X X X X X X X X 3 X X X X X X X X

Grupo 3 1 X X X X X X X X 2 X X X X X X X X 3 X X X X X X X X X

A Tabela 6.4 mostra uma comparação realizada entre as ADLs-OA pesquisadas e as

características propostas no âmbito deste trabalho. Vê-se que, entre as características

elencadas, oito delas não são contempladas nas ADLs-OA pesquisadas, quais sejam:

Middlewares modelados como conectores; Aspectos nativos (built-in); Biblioteca de estilos;

Controle de alterações dinâmicas; Suporte à avaliação arquitetural; Suporte à identificação de

aspectos arquiteturais; Verificação de estilos/padrões arquiteturais; Rastreabilidade de

alterações arquiteturais ao longo do ciclo de vida do software.

114

Tabela 6.4 – Comparação das ADLs-OA em relação às características propostas

ADL Característica

AspectualACME Prisma Fractal DAOP-ADL Proposta de Navasa

Aspectos como Elementos de Primeira Classe

Sim: construtores primitivos da linguagem


Não: baseia-se no modelo de AC



Componentes Aspectuais Não: utiliza os mesmos construtores para modelar interesses transversais

Sim: provê novos construtores com novas abstrações

Sim: estende componentes convencionais


Sim

Conectores Aspectuais Extensão da noção de conectores tradicionais conector regular com nova interface


Não Sim: provê novos construtores com novas abstrações

Não

Middlewares Modelados como Conectores

Não Não Não Não Não

Modelagem da Composição Estática: modelada por meio de conectores aspectuais em tempo de design

Estática: realizada em tempo de design


Dinâmica: realizada por meio da plataforma DAOP


Extensibilidade Sim: usa a ACME como base Não Não Não Não

Aspectos Nativos (built in) Não Não Não Não Não

Biblioteca de Estilos Não Não Não Não Não

Biblioteca de Aspectos Não Não Não Sim Não

Notação Visual Sim: extensão da notação da ACME

Sim: notação própria Sim: notação própria Sim: notação própria Sim: notação própria

� Compatibilidade com a UML Não Sim Não Não Não

Formalismo subjacente Não Não Sim Não Usa modelos de composição

Controle de Alterações Dinâmicas Não Não Não Não Não

Suporte a avaliação Não Não Não Não Não

Identificação de Aspectos Não Não Não Não Não

Verificação do Design e da Implementação

Não Não Não Sim: usa um framework de desenvolvimento

Não

Verificação do estilo/padrão Não Não Não Não Não

Rastreabilidade de Alterações Não Não Não Não Não

115

6.6 Proposta de Notação Visual e Formalismo para uma ADL-OA

Uma dada arquitetura de software pode ser caracterizada de acordo com sua evolução

em tempo de execução. Uma arquitetura é considerada: (a) estática, se ela não evoluir durante

a execução do sistema; (b) dinâmica, se for possível a sua evolução em tempo de execução

(ex.: componentes puderem ser criados, excluídos, ou re-configurados em tempo de

execução); e (c) móvel, se os seus componentes puderem se mover (sob uma perspectiva

lógica) durante a execução.

Normalmente, conforme (IEEE, 2000), a partir de uma perspectiva em tempo de

execução, são usados dois pontos de vista na arquitetura de software, quais sejam:

a) estrutural, especificado em termos de componentes, conectores e configurações;

b) comportamental, especificado em termos de: as ações que o sistema executa ou

participa; os relacionamentos entre ações para especificar comportamentos; e

comportamentos de componentes e conectores, e como eles interagem.

Portanto, a fim de descrever arquiteturas dinâmicas e móveis, uma ADL deve ser

capaz de descrever as alterações nas estruturas e nos comportamentos dos componentes e

conectores (inclusive criação, exclusão, re-configuração e movimentação) em tempo de

execução (OQUENDO, 2004).

Diversos trabalhos levaram em consideração as arquiteturas dinâmicas: Rapide

(LUCKHAM et al., 1995), (LUCKHAM; VERA, 1995); Darwin (MAGEE et al., 1995),

(MAGEE; KRAMER, 1996); Dynamic-Wright (ALLEN; DOUENCE; GARLAN, 1998);

Dynamic-ACME (GARLAN; MONROE; WILE, 2000).

Mais recentemente, outros trabalhos têm buscado contemplar, em suas propostas, a

modelagem da mobilidade dos componentes, além da característica de dinamismo

arquitetural: π-ADL (OQUENDO, 2004); Con Moto22 (GRUHN; SCHÄFER, 2004),

(GRUHN; SCHÄFER, 2005). Contudo, essas duas propostas ainda não foram estendidas a

fim de permitir a modelagem de arquiteturas de software orientadas a aspectos. Ressalta-se

que em (ALDAWUD; ELRAD; BADER, 2003) os autores apresentam a utilização do recurso

UML Profile com a finalidade de apoiar o desenvolvimento de software orientado a aspectos.

Não obstante a DAOP-ADL seja uma ADL orientada a aspectos que trata,

explicitamente, de questões relacionadas ao dinamismo arquitetural (PINTO; FUENTES;

22 Do italiano: “em movimento”.

116

TROYA, 2003), (PINTO; FUENTES; TROYA, 2005), essa proposta não contempla a questão

da mobilidade dos componentes, bastante presente no domínio de sistemas distribuídos.

A presente proposta de uma ADL-OA pretende contemplar as características elencadas

anteriormente (relacionadas à notação de design arquitetural), quais sejam:

1) Aspectos arquiteturais como elementos de primeira classe: a notação permitirá ao

arquiteto de software modelar os interesses transversais por meio de construtores

arquiteturais básicos providos pela ADL, sem a necessidade de extensão.

2) Componentes aspectuais: a notação permitirá (por meio da abstração de aspecto

arquitetural) a modelagem de interesses arquiteturais transversais cujo papel primário

seja a computação.

3) Conectores aspectuais: a notação permitirá a modelagem de interesses arquiteturais

transversais cuja finalidade seja a mediação da interação entre componentes e aspectos.

4) Representação de middlewares como conectores: a notação permitirá a modelagem

explícita de conectores especiais off-the-shelf, cuja finalidade é o fornecimento de

serviços essenciais (vide Capítulo 2) para que os componentes em um sistema distribuído

possam funcionar juntos; por serem bastante elaborados, tais conectores são, por sua

própria natureza, conectores compostos.

5) Modelagem de composição dinâmica: a composição dinâmica poderá ocorrer mediante

a interação de um aspecto arquitetural com outro elemento arquitetural.

6) Extensibilidade dos recursos de modelagem da ADL-OA: o usuário da notação poderá

utilizar os estereótipos para estender a notação.

7) Aspectos arquiteturais built-in inerentes ao domínio: A notação fornecerá, na forma

de primitivas da linguagem, alguns aspectos básicos, inerentes ao domínio de sistemas

distribuídos (ex.: autenticação, controle de acesso, logging, tratamento de erros). Tais

aspectos encontram-se pré-especificados, bastando ao usuário da ADL invocá-los por

meio do uso de palavras reservadas ou utilizando os ícones adequados, disponibilizados

na interface gráfica da ferramenta da ADL.

8) Uso de bibliotecas de estilos/padrões arquiteturais: estilos já consagrados, mormente

no domínio de sistemas distribuídos, poderão ser fornecidos ao usuário; no ato da

descrição da arquitetura, o arquiteto poderá referenciar o estilo por meio de um comando.

9) Uso de bibliotecas de aspectos arquiteturais: da mesma forma que a ADL oferecerá

uma coleção de aspectos arquiteturais nativos, o usuário poderá especificar novos

aspectos e armazená-los, disponibilizando-os na biblioteca para uso futuro.

117

Além disso, duas características, que expressam o dinamismo arquitetural e estão

bastante presentes em uma arquitetura de sistema de software distribuído, devem ser

modeladas, a saber: replicação e mobilidade dos componentes. É importante que tais

características sejam modeladas, explicitamente, a fim de permitir a compreensão imediata da

arquitetura por parte dos diversos stakeholders. Tais características são úteis para representar,

em nível de design arquitetural, requisitos de um sistema distribuído, tais como:

escalabilidade, concorrência, tolerância a falhas, e dinamismo arquitetural.

6.6.1 Notação Gráfica

A UML versão 2.0 (OMG, 2007), não apresenta diagramas específicos para a

modelagem de arquiteturas. Na verdade, o Diagrama de Componentes, que na UML 1.5 servia

como diagrama detalhado para sistemas baseados em componentes (com o foco na visão de

implementação do sistema em termos de componentes de software), sofreu uma evolução: na

UML 2.0 os componentes foram generalizados e são considerados como estando em um nível

de abstração mais elevado do que as classes, tendo sido introduzido o Diagrama de Estrutura

Composto (OQUENDO, 2006).

Embora o recurso de máquinas de estado finito da UML possa ser usado efetivamente

para a modelagem do comportamento dinâmico dos componentes e conectores (e suas

interações), a UML 2.0 não oferece construtores especializados para a modelagem de

arquitetura de software a partir de uma perspectiva em tempo de execução (ex.: componentes

e conectores devem ser modelados usando o mesmo mecanismo, e as regras de um

determinado estilo arquitetural devem ser aplicadas mentalmente pelo arquiteto de software).

Entretanto, a UML 2.0 fornece uma base adequada para a definição de perfis (profiles)

para que a modelagem formal de uma arquitetura de software seja possível. Assim, uma

notação visual correspondente para uma ADL-OA pode ser definida a partir do recurso de

estereótipos da UML 2.0. Em (OQUENDO, 2006), é apresentada essa abordagem, a qual deu

origem à notação visual da linguagem π-ADL (OQUENDO, 2004). Uma vez que

consideramos ser interessante que a notação visual tenha compatibilidade com a UML, a

elaboração de nossa proposta de notação visual encontra-se baseada na abordagem utilizada

por Oquendo (2006).

A Tabela 6.5 apresenta os ícones referentes à notação gráfica proposta no presente

trabalho.

118

Tabela 6.5 – Proposta de uma notação gráfica para uma ADL-OA Estereótipo Ícone Significado Exemplo

<<componente>>

Componente convencional. Componente GUI.

<<componente replicado>>

Componente convencional o qual se encontra replicado no sistema.

Componente Banco de Dados.

<<componente móvel>>

Componente convencional o qual se movimenta em tempo de execução.

Componente GUI.

<<componente composto>>

Componente composto por outros elementos arquiteturais (componentes e conectores).

Componente Aplicação, o qual é composto por vários outros componentes.

<<conector>>

Conector convencional.

Um link SQL entre o Componente GUI e qualquer Componente Banco de Dados.

<<conector replicado>>

Conector convencional o qual se encontra replicado no sistema.

Um link SQL entre o Componente GUI e um Componente Banco de Dados replicado.

<<conector composto>>

Conector convencional, mais elaborado, composto por outros elementos arquiteturais (componentes e conectores).

Um conector que pode agrupar serviços e estabelecer a ligação entre diferentes componentes, pode ser entendido como sendo um conector composto.

<<middleware>>

Um conector composto especial (possivelmente off-the-

shelf), o qual provê determinados serviços básicos para o funcionamento de um sistema distribuído.

A Camada de Infraestrutura, contendo os serviços essenciais ao funcionamento do sistema.

M

119

Estereótipo Ícone Significado Exemplo

<<interface>> Consiste nas conexões entre o componente e seu

ambiente. Um atributo de entrada/saída de um método ou set/get.

<<aspecto>>

Modela os interesses arquiteturais transversais (funcionais e não-funcionais).

Aspecto Persistência, ou Concorrência em um ADDS.

<<aspecto replicado>>

Aspecto que se encontra replicado no sistema.

Aspecto Controle de Acesso o qual se conecta com um Componente Banco de Dados replicado de um ADDS.

<<conector aspectual>>

Modela a interação entre um aspecto e outro elemento arquitetural.

Conector entre o Aspecto Persistência e qualquer outro elemento arquitetural.

<<aspecto móvel>>

Componente aspectual o qual se movimenta em tempo de execução.

Qualquer Aspecto que seja passível de composição com algum outro elemento arquitetural móvel

<<composição dinâmica>

Modela uma conexão entre um elemento aspectual e outro elemento arquitetural, explicitando a situação na qual ocorrerá composição em tempo de execução.

Relacionamento que indica a composição aspectual em tempo de execução entre o Aspecto Controle de Acesso e, por exemplo, um Componente Aplicação.

Obs.: no Capítulo 7 (vide Seção 7.5) é apresentado um experimento envolvendo a representação arquitetural de um Ambiente Distribuído de Desenvolvimento de

Software, a saber, o DiSEN (Distributed Software Engineering Environment), no qual são demonstradas as vantagens do uso desta notação gráfica.

M

120

6.6.2 Formalismo Subjacente

A representação formal de uma arquitetura está mais apta a ser mantida e seguida do

que uma representação informal, pois pode ser consultada mais rapidamente e ser mais

facilmente transferida para outros projetos (BASS; CLEMENTS; KAZMAN, 2003).

A definição da Rapide, uma linguagem baseada em eventos, espelha-se no modelo de

execução fundado no conceito de posets (partially ordered set of events) (FIDGE, 1988). Para

a Dynamic-Wright, a notação para a especificação de comportamento baseado em eventos é

uma adaptação do CSP (HOARE, 1978).

A semântica operacional da Darwin baseia-se no formalismo do π-Calculus

(MILNER; PARROW; WALKER, 1992). A π-ADL é uma linguagem formal baseada no π-

Calculus. A ADL Con Moto também teve seu formalismo desenvolvido para a especificação

de propriedades não-funcionais, com base no π-Calculus.

Excetuando-se a π-ADL e a Con Moto, as demais linguagens não têm poder de

expressão suficiente para descrever arquiteturas dinâmicas nas quais as alterações

arquiteturais dependem de seus dados de entrada; além disso, elas não apresentam

construtores arquiteturais capazes de modelar explicitamente a descrição de componentes

móveis.

Com base nas considerações precedentes, é razoavelmente provável que o π-Calculus

seja o formalismo capaz de oferecer mais condições para a definição de uma ADL suficiente

para a modelagem de arquiteturas de sistemas de software distribuídos.Entretanto, ainda não

encontramos uma resposta sobre como estender tal formalismo de modo que as características

desejáveis em uma ADL-OA (ex.: composição dinâmica) possam se fazer presentes na

notação formal, constituindo-se, portanto, como uma sugestão para trabalho futuro.

Como pode ser observado na Tabela 6.6, o π-Calculus é o formalismo utilizado pelas

ADLs seguintes: π-ADL (projetada para modelar arquiteturas de sistemas dinâmicos); Darwin

(inicialmente projetada para dar suporte à modelagem dos requisitos não funcionais de

sistemas distribuídos); e Con Moto (cuja ênfase está na modelagem da mobilidade dos

componentes de um sistema distribuído). As ADLs Rapide e a Dynamic-Wright estão

embasada nos formalismos providos por posets e CSP, respectivamente.

121

Tabela 6.6 – Formalismos empregados pelas principais ADLs para o domínio de SDs

Formalismo ADLs

posets CSP π-Calculus

Rapide

Dynamic-Wright

π-ADL

Darwin

Con Moto

A Tabela 6.7 mostra claramente que o formalismo π-Calculus é o que mais contempla

algumas das capacidades de modelagem requeridas no design arquitetural de sistemas

distribuídos.

Tabela 6.7 – Algumas capacidades de modelagem encontradas nos formalismos estudados

Formalismo Capacidade de modelagem

posets CSP π-Calculus

Alterações arquiteturais dependentes de dados de I/O

Dinamismo arquitetural

Mobilidade dos componentes

Especificação de propriedades não funcionais

Comportamento baseado em eventos

Depreende-se, intuitivamente, com base na análise das Tabelas 6.6 e 6.7, que o

formalismo π-Calculus é um candidato em potencial, pois seu poder de expressão,

provavelmente, atenderá às necessidades de modelagem de uma ADL-OA para sistemas

distribuídos.

6.7 Considerações

Não foram realizados experimentos em relação à definição de qual formalismo

matemático é o mais adequado para o design da notação textual de uma ADL-OA.

A Tabela 6.8 mapeia as características em relação aos elementos da notação visual

proposta. Por exemplo, a características Rastreabilidade de Alterações depende,

fundamentalmente, do elemento Composição Dinâmica da notação visual de uma ADL-AO.

122

Tabela 6.8 – Mapeamento dos elementos da notação visual proposta (Seção 6.7.1) frente às características elencadas (Seção 6.5) Elementos

Característica Componente

Replicado Componente

Móvel Conector Replicado

Middleware Aspecto Aspecto

Replicado Conector Aspectual

Aspecto Móvel

Composição Dinâmica

Aspectos como Elementos de Primeira Classe

Componentes Aspectuais

Conectores Aspectuais

Middlewares Modelados como Conectores

Modelagem da Composição

Extensibilidade

Aspectos Nativos (built in)

Biblioteca de Estilos

Biblioteca de Aspectos

Notação Visual

Formalismo subjacente

Controle de Alterações Dinâmicas

Suporte a avaliação

Identificação de Aspectos

Verificação do Design e da Implementação

Verificação do estilo/padrão

Rastreabilidade de Alterações

123

7 – Modelagem Arquitetural do DiSEN: Um exemplo de utilização de uma ADL-OA

7.1 Introdução

Com base na proposta da notação gráfica para uma ADL-AO, exposta no Capítulo 6,

neste capítulo serão apresentados os resultados de um experimento de modelagem arquitetural

de um Ambiente Distribuído de Desenvolvimento de Software (ADDS), a saber, o DiSEN

(Distributed Software Engineering Environment).

O restante deste capítulo encontra-se organizado como segue. Na Seção 7.2 é

fornecida uma visão geral do sistema alvo, citando alguns trabalhos associados. Na Seção 7.3

são apresentados os requisitos genéricos do sistema e os principais cenários. Na Seção 7.4 é

discutida a arquitetura ADDS DiSEN. Na Seção 7.5 encontram-se ilustradas algumas

representações arquiteturais do ADDS DiSEN. As considerações referentes ao experimento

encontram-se registradas na Seção 7.6.

7.2 O DiSEN: Visão Geral

Um Ambiente de Desenvolvimento de Software (ADS) tem como objetivo: prover um

ambiente onde o software possa ser desenvolvido por meio da integração de um conjunto de

ferramentas que dêem suporte a métodos de desenvolvimento apoiados por uma estrutura que

permite a comunicação e cooperação entre essas ferramentas e os desenvolvedores.

Um ADS é um sistema computacional que provê suporte para o desenvolvimento,

reparo e melhorias em software, e para o gerenciamento e controle dessas atividades. Para tal,

um ADS contém um repositório com todas as informações relacionadas ao desenvolvimento

do projeto ao longo do seu ciclo de vida, além de ferramentas que oferecem o apoio às várias

atividades, técnicas e gerenciais, passíveis de automação que devem ser realizadas no projeto

(PASCUTTI, 2002). Um ADS deve preocupar-se em apoiar as atividades individuais e o

trabalho em grupo, o gerenciamento do projeto, o incremento da qualidade geral dos produtos

e o aumento da produtividade, permitindo o acompanhamento do projeto e a constatação, por

meio de informações obtidas ao longo do desenvolvimento, da evolução dos trabalhos

(PASCUTTI, 2002).

O DiSEN (Distributed Software Engineering Environment) é um Ambiente

Distribuído de Desenvolvimento de Software desenvolvido por um grupo de pesquisa do

124

Departamento de Informática da Universidade Estadual de Maringá, cuja arquitetura foi

proposta, originalmente, em (PASCUTTI, 2002).

O DiSEN é um ambiente de desenvolvimento de software concebido para dar suporte,

inicialmente, à MDSODI (Metodologia de Desenvolvimento de Software Distribuído) e ao

trabalho cooperativo. Seu design incorpora também a tecnologia de agentes, de acordo com o

padrão estabelecido pela FIPA (Foundation for Intelligent Physical Agents). Vários trabalhos

já forma desenvolvidos no contexto do DiSEN, dentre os quais: (BATISTA, 2003),

(PEDRAS, 2003), (MORO, 2003), (LIMA, 2004), (POZZA, 2005), (ENAMI, 2006),

(WIESE, 2006) e (SCHIAVONI, 2007).

7.3 Requisitos Relevantes para um ADDS

Em se tratando de um ADDS, idealmente, é desejável que sua arquitetura atenda aos

seguintes requisitos:

• Armazenar, gerenciar, e garantir a segurança de dados e metadados de projetos de

desenvolvimento de software distribuídos geograficamente.

• Oferecer capacidade para incorporação de novos processos e métodos de gerenciamento

de projetos de software.

• Permitir que sejam adicionados, excluídos, configurados ou modificados componentes de

software e serviços de forma dinâmica.

• Atingir requisitos de desempenho e de confiabilidade necessários ao suporte ao

desenvolvimento integrado e cooperativo de software.

Espera-se que o DiSEN, em sua plenitude, ofereça apoio para as seguintes situações:

1. Ser integrado com ferramentas desenvolvidas em LPs diferentes [requisito de abertura]23.

2. Dar suporte ao uso de ferramentas CASE que apóiem o trabalho cooperativo entre

usuários distantes geograficamente.

3. Prover acesso ao desenvolvedor de diferentes locais24 – em casa, no aeroporto, etc.

[requisito de mobilidade] –, de modo a realizar tarefas tais como:

a) salvar artefato em sua casa (local) e, na seqüência, sincronizar, remotamente, com o

repositório localizado em um site do DiSEN;

b) sincronizar, remotamente, com o site do DiSEN e trabalhar sobre o artefato atualizado.

4. Ser integrado com bancos de dados diferentes [requisito de abertura];

23 A ser realizado em trabalhos futuros. 24 Local � site / endereço.

125

5. Utilizar diferentes repositórios (CVSs) [requisito de abertura];

6. Prover suporte ao trabalho cooperativo, com as seguintes características:

a) percepção (awareness)25 – vide (POZZA, 2005);

b) comunicação via chat;

c) recursos de voz26.

7. Manter dados replicados em diferentes repositórios [requisito da tolerância a falhas];

8. Manter serviços – suporte a persistência, a local, a nomes, etc. – replicados em diferentes

hosts [requisito da tolerância a falhas];

9. Permitir a um usuário acessar dados ou serviços em outro host27, caso um host fique

inativo [requisito de tolerância a falhas].

10. Permitir que novas ferramentas externas (inclusive proprietárias, ou desenvolvidas por

terceiros) possam ser integradas ao ambiente [requisito de abertura]:

a) integração da execução;

b) integração dos artefatos – vide (WIESE, 2006).

11. Uma vez estabelecida a comunicação cliente-servidor, mediante a ocorrência de uma falha

de comunicação, um tratamento de falha é realizado conforme uma política pré-

estabelecida (ex.: possibilidade de replicação dos dados), de modo que:

a) um cliente poderá estar conectado a um servidor e outro conectado a outro servidor;

b) seja garantido o suporte ao CSCW: a percepção, a sincronização e a comunicação.

12. Resolver problemas relacionados à interdependência de serviços: ex.: se a máquina do

controle de acesso tornar-se inativa, isso implica na impossibilidade de acessar o serviço

de persistência [requisito da disponibilidade].

13. Instanciação dinâmica de servidores proporcionando o compartilhamento de dados de

projetos [requisito da escalabilidade].

14. Adicionar/distribuir serviços em novas máquinas, que poderão estar fisicamente no

mesmo local ou não [requisito da escalabilidade].

15. Ser flexível o suficiente para permitir que o gerente (local/projeto) estabeleça políticas de

funcionamento do sistema – ex.: desenvolvedor dá comando para o DiSEN salvar um

artefato, sem a necessidade de especificar o endereço de persistência [requisito de

transparência]: uma política que poderia ser estabelecida é que o artefato seja salvo

localmente e depois remotamente.

25 Pode ser conceituada como a contextualização das atividades individuais através da compreensão das atividades realizadas por outras pessoas. 26 A ser realizado em trabalhos futuros. 27 Host � máquina, estação de trabalho;

126

7.4 Abordagem Arquitetural

A arquitetura do DiSEN, proposta por Pascutti (2002), baseia-se no estilo camadas, o

qual proporciona uma maior flexibilidade de desenvolvimento, organizando o sistema em

camadas hierárquicas. Uma camada pode ser definida como um conjunto de sub-sistemas com

o mesmo grau de generalidade. Tradicionalmente, as interações ocorrem somente entre

camadas adjacentes (GAMMA et al., 1995) (BUSCHMAN, 1996).

Figura 7.1 – Arquitetura do DiSEN proposta em (PASCUTTI, 2002)

Conforme ilustra a Figura 7.1, a arquitetura do DiSEN possui uma camada dinâmica

a qual permite, por exemplo, que sejam adicionados, excluídos, configurados ou modificados

componentes de software e serviços de forma dinâmica (em tempo de execução); uma

camada de aplicação de apoio à MDSODI, gerenciamento de workspace, gerenciamento de

agentes, contendo o(s) banco(s) de dados necessário(s) para armazenamento dos dados sobre

o ambiente (todas as informações geradas durante o desenvolvimento de software e as

informações da aplicação), bem como a base de conhecimento e, futuramente, as ontologias.

A camada de infra-estrutura será responsável pelo alicerce da arquitetura e oferecerá

suporte às tarefas de (i) persistência: deverá fornecer uma interface única para os acessarem

os vários mecanismos de persistência, tais como, bases de dados, bases de conhecimento e

simples arquivos; (ii) nomeação: deverá permitir que elementos possam referenciar e localizar

outros pelo nome, e (iii) concorrência: deverá assegurar ao banco de dados que um cliente por

vez tenha acesso a um registro ou arquivo – deve fazer o controle compartilhado, evitando

impasses (PASCUTTI, 2002).

Os elementos da arquitetura do DiSEN, proposta por (PASCUTTI, 2002), são: (a)

Supervisor de Configuração Dinâmica; (b) Gerenciador de Objetos; (c) Gerenciador de

127

Workspace; (d) Gerenciador de Agentes; (e) Repositório; e (f) Canal de Comunicação. A

seguir, cada um desses elementos são brevemente destacados.

• O Supervisor de Configuração Dinâmica

Em um ADS distribuído, devem ser levadas em consideração duas questões chaves

(PASCUTTI, 2002): (i) é necessário considerar que um ambiente de desenvolvimento é

dinâmico em relação à sua arquitetura, ou seja, seus elementos, sua organização e suas

interconexões mudam durante a execução do sistema; (ii) deve ser considerado também que

novos serviços podem ser acrescentados ao ambiente também de forma dinâmica.

Portanto, o supervisor está subdividido em Supervisor de Configuração que terá como

tarefa básica o controle e gerenciamento da configuração do ambiente e Supervisor de

Serviços que deverá controlar e gerenciar os serviços que podem ser acrescentados ao

ambiente de forma dinâmica.

• O Gerenciador de Objetos

Uma das principais tarefas dos ambientes de desenvolvimento de software é

armazenar, estruturar e controlar, além do próprio software, os artefatos gerados durante o

desenvolvimento. Esses artefatos são, por natureza, mais complexos que os itens tratados por

sistemas de banco de dados tradicionais, pois são mais estruturados e requerem operações

complexas.

O Gerenciador de Objetos é constituído pelo gerenciador de acesso, gerenciador de

atividades, gerenciador de recursos, gerenciador de artefatos, gerenciador de projetos,

gerenciador de processos e gerenciador de versões e configurações – explicações detalhadas

sobre esses gerenciadores podem ser obtidas em (PASCUTTI, 2002).

• O Gerenciador de Workspace

O Gerenciador de Workspace deve prover funcionalidades para criar um ou mais

workspaces de um repositório sendo que, no caso do DiSEN, isso será feito através do canal

de comunicação e do suporte à tarefa de persistência. No caso mais simples, isso consiste em

copiar um arquivo simples, porém, mais freqüentemente, uma configuração inteira é copiada

do repositório para o workspace possibilitando ao desenvolvedor ter todos os módulos e

documentos necessários para o sistema à sua disposição, localmente. Assim, o desenvolvedor

não tem que decidir entre o que deve ser mantido globalmente no repositório e o que é

necessário localmente para carregar suas mudanças. Além disso, ele está isolado das

alterações das outras pessoas para o repositório – e outras pessoas estão isoladas das suas

128

alterações. Isso significa que ele tem um controle completo do seu mundo e sabe exatamente

o que foi alterado e por que (PASCUTTI, 2002).

• O Gerenciador de Agentes

O gerenciador de agentes é responsável pela criação, registro, localização, migração e

destruição de agentes e compreende a Região de Agente (RA) e o Servidor de Ontologia, –

explicações detalhadas sobre esses dois elementos podem ser obtidas em (PASCUTTI, 2002).

• O Canal de Comunicação

De acordo com Pascutti (2002), o Canal de Comunicação é um elemento fundamental

da arquitetura, já que toda a comunicação entre os elementos constituintes da camada de

aplicação e da camada da infra-estrutura será realizada através desse canal. É constituído pelo

middleware e pelo middle-agent, sendo que, quando a comunicação envolver somente

objetos, esta será feita pelo middleware, e quando os agentes estiverem envolvidos, devido às

suas propriedades, a comunicação deverá ser gerenciada pelo middle-agent. Neste último

caso, além dos serviços convencionais de nomeação, por exemplo, outras propriedades devem

ser consideradas, tais como: colaboração, negociação, coordenação e mobilidade.

7.5 Representação Arquitetural do DiSEN

Nesta seção será apresentada uma representação arquitetural do DiSEN, considerando

tomando como base o tipo de visão componente-e-conector (C&C), conforme consta na Seção

3.4.4. Como a visão do tipo módulo é considerada essencial para compreensão do sistema por

parte dos stakeholders, foi incluída uma representação do tipo de visão módulos na Seção

7.5.1. Não foi disponibilizado neste trabalho qualquer visão do tipo alocação por estar além

do escopo deste trabalho. As visões do tipo C&C nesta seção estão representadas utilizando-

se a notação gráfica para uma ADL-OA proposta na Seção 6.5.

7.5.1 Uma Abordagem Arquitetural Convencional (não-OA)

A Figura 7.2 representa a arquitetura inicial do DiSEN, proposta por Pascutti (2002),

em uma visão de módulos, o que permite visualizar as inter-dependências entre os diversos

componentes arquiteturais, devido ao tipo de relacionamento típico desse tipo de visão, o

relacionamento depende-de.

129

Figura 7.2 – Arquitetura inicial do DiSEN em uma visão de módulos

Como visto na Seção 3.4.3, um módulo implementa um conjunto de

responsabilidades. Portanto, esse tipo de elemento arquitetural não permite a análise do

sistema em tempo de execução, impedindo, por exemplo, analisar questões arquiteturais

relacionadas à configuração dinâmica do sistema. Contudo, é importante que essa visão seja,

inicialmente, apresentada de modo a permitir uma visão mais abrangente e simplificada do

sistema em questão.

Em uma visão C&C, a Figura 7.3 representa a arquitetura do DiSEN com base nos

seguintes elementos arquiteturais:

130

Figura 7.3 – Arquitetura do DiSEN em uma visão C&C (componente-e-conector)

COMPONENTES:

• GUI: este componente destina-se a oferecer a interface de acesso aos usuários do DiSEN

(apesar do acrônimo GUI, em algumas circunstâncias, pode ser uma interface no modo

texto). Todo usuário do DiSEN necessita ter instalado este componente em sua estação de

trabalho.

• Supervisor de Configuração Dinâmica

• Aplicação: componente composto dos seguintes sub-componentes:

o Repositório, que classicamente podem ser constituídos de Sistemas Gerenciadores

de Banco de Dados e/ou de CVSs.

o Gerenciador de Objetos,

o Gerenciador de Workspace,

o Gerenciador de Agentes.

• Infra-estrutura: este componente engloba:

o Persistência,

o Nomeação,

o Concorrência,

o Canal de Comunicação.

Aplicação

C1

C3

C4

Infra-estrutura

C2

Supervisor de Configuração Dinâmica

GUI

131

CONECTORES:

• C1: este conector provê a comunicação entre o componente GUI e os serviços fornecidos

pelo componente Supervisor de Configuração Dinâmica. A comunicação se dá mediante a

observância de regras e protocolos pré-definidos.

• C2: este conector permite a comunicação entre os serviços constituintes do componente

Supervisor de Configuração Dinâmica e os gerenciadores compreendidos no componente

Aplicação (de acordo com um conjunto de regras e protocolos previamente definidos).

• C3: provê a comunicação entre os gerenciadores compreendidos no componente

Aplicação e o componente Infra-estrutura.

• C4: há algumas situações que exigem que o componente GUI comunique diretamente com

o componente Aplicação. Para que essa comunicação seja viabilizada, o conector C4 se

faz necessário. Por exemplo, um determinado usuário do DiSEN pode necessitar

comunicar com outro usuário por meio do canal de comunicação, tendo a intermediação

do Gerenciador de Objetos.

Por meio de análise visual da Figura 7.3, é possível constatar que os componentes

Supervisor de Configuração Dinâmica, Aplicação e Infra-estrutura são elementos compostos,

pois os retângulos que os representam são formados por linhas duplicadas.

7.5.2 Uma Abordagem Arquitetural Orientada a Aspectos

Analisando o componente Infra-estrutura, vemos que ele compreende uma coleção de

serviços essenciais ao funcionamento de um sistema distribuído (Suporte à Tarefa de

Persistência, Suporte à Tarefa de Nomeação e Suporte à Tarefa de Concorrência). Conforme

proposto em (PASCUTTI, 2002), tal componente consiste, basicamente, em um middleware

(vide Figura 7.2). Sendo assim, a representação ideal para tal componente pode ser modelada

como mostra a Figura 7.4.

O middleware foi definido como uma entidade específica, dada a sua importância para

o contexto considerado no presente trabalho. Com isso, ela já carrega a informação de que o

elemento Infra-estrutura (Figura 7.4) é composto e, potencialmente, replicado.

132

Figura 7.4 – Componente Infra-estrutura modelado na forma de um middleware.

Com base na aplicação do método ASAAM (TEKINERDOGAN, 2004), os seguintes

aspectos foram identificados na arquitetura do DiSEN: Persistência; Controle de Acesso;

Distribuição; Configuração Dinâmica (alguns dos quais constantes na Figura 7.5).

Pela Figura 7.5, é possível observar que a notação OA, proposta neste trabalho,

fornece recursos para modelar a replicação (indicada por retângulos sombreados) e a

mobilidade de componentes (indicada pela letra M), assim como a composição dinâmica

(linha do relacionamento na forma de raio). Por questões de distribuição, balanceamento de

carga, segurança, etc., os componentes Aplicação e Infra-estrutura poderão estar replicados e

a modelagem explícita dessa característica na representação arquitetural mostra-se bastante

útil.

Um usuário do DiSEN poderá necessitar locomover-se fisicamente com sua estação de

trabalho (por exemplo, durante uma viagem) e, ao mesmo tempo, continuar trabalhando em

algum projeto ao qual está vinculado. A modelagem desse requisito de sistema é muito útil

aos stakeholders. Um possível exemplo de componente que pode ser representado como tal é

o GUI, que traz consigo esta informação na notação correspondente, qual seja, a letra M.

Aplicação

C1

C3

C4

C2


GUI

Infra-estrutura

133

Figura 7.5 – Arquitetura do DiSEN em uma visão C&C em uma Abordagem OA.

A replicação dos serviços essenciais e de infra-estrutura é fundamental para garantir a

disponibilidade do ADDS. A composição dinâmica fica evidente pela própria replicação dos

componentes, pois se um componente ficar inativo, o aspecto correspondente (com o qual ele

se relaciona) deverá ser composto em tempo de execução.

A modelagem explícita da replicação tem a capacidade de indicar aos desenvolvedores

a possibilidade da re-configuração do sistema em tempo de execução.

Os relacionamentos representados por linhas na forma de raio, indicam que o aspecto

Controle de Acesso e Persistência serão compostos dinamicamente (isto é, durante a execução

do sistema) com os componentes com os quais eles se relacionam diretamente.

O componente composto Supervisor de Configuração Dinâmica pode ser expandido e

apresentar a configuração ilustrada na Figura 7.6 (o componente GUI, o aspecto Controle de

Acesso e o aspecto Persistência, foram incluídos com a finalidade de mostrar os

relacionamentos com seus sub-componentes).

GUI

M

C2

Controle de Acesso

C1 Persistência


Aplicação

Infra-estrutura

134

Figura 7.6 – Componente Supervisor de Configuração Dinâmica expandido

O Supervisor de Serviços controlará e gerenciará os serviços acrescentados ao

ambiente dinamicamente, enquanto o Supervisor de Configuração do ADS, basicamente,

controlará e gerenciará a configuração do ambiente. Ambos os componentes necessitam

realizar controles de acesso. O interesse controle de acesso encontra-se modularizado no

aspecto arquitetural Controle de Acesso. A linha na forma de raio indica que o aspecto

Controle e Acesso poderá ser composto em tempo de execução, dinamicamente.

Contudo, o problema da configuração dinâmica ainda não fica completamente

resolvido por meio da modelagem apresentada na Figura 7.6, pois muitos outros componentes

necessitam ter acesso aos serviços oferecidos pelo componente Supervisor de Configuração, e

o problema do entrelaçamento de interesses persiste.

A solução consiste em modelar tal componente na forma de uma aspecto arquitetural,

conforme mostra a Figura 7.7, de modo que o entrelaçamento arquitetural possa ser

amenizado, quando não for eliminado.

C1

Controle de Acesso

Supervisor de Configuração do ADS

Supervisor de Serviços

GUI

M

C2

Persistência

135

Figura 7.7 – Componente Supervisor de Configuração modelado como um aspecto

Considerando que o componente Aplicação (vide Figura 7.3) está representado como

um componente composto (Repositório, Gerenciador de Objetos, Gerenciador de Workspace

e Gerenciador de Agentes) e replicado, vejamos o seguinte cenário, em tempo de execução:

• O repositório encontra-se replicado em três bases de dados, mantidas em locais

fisicamente distintos.

• O usuário grava os dados sem conhecer o endereço físico das bases de dados.

• É perdida uma determinada conexão entre um componente GUI e um host do DiSEN, no

qual se encontra localizada uma base de dados replicada e outros serviços essenciais.

Neste caso, o aspecto Supervisor de Configuração será encarregado de localizar outra

base de dados ativa e estabelecer as devidas conexões com os demais componentes do

sistema, em tempo de execução e de modo transparente ao usuário.

A situação esboçada acima ilustra um caso típico de re-configuração de um sistema

distribuído, atendendo plenamente ao requisito transparência. Os aspectos Serviço de Nomes

(Nomeação) e Controle de Acesso são imprescindíveis em situações como essas, pois uma

Supervisor de Serviços

GUI

M

C2

Serviço de Nomes

Supervisor de Configuração do ADS

Controle de Acesso

136

nova configuração dependerá da localização dos componentes necessários assim como a

devida liberação de acesso a tais componentes.

7.6 Considerações

Pelo experimento realizado, foi possível constatar que a notação proposta é capaz de

sanar vários problemas relacionados à modelagem arquitetura de software do domínio de

sistemas distribuídos (vide Seção 2.4) , assim como satisfaz algumas necessidades oriundas da

abordagem orientada a aspectos.

No primeiro caso, é possível modelar explicitamente componentes compostos,

replicados, móveis e middlewares; além disso, permite modelar relacionamentos dinâmicos, a

fim de propiciar a evolução arquitetural em tempo de execução.

Vale ressaltar que os problemas da configuração dinâmica não se restringem apenas

aos casos de replicação de componentes, mas também estão presentes nos chamados sistemas

de missão crítica (ex.: sistemas bancários, controle de tráfego aéreo, controle de usinas

nucleares, telecomunicações, monitoramento de pacientes em tratamentos médicos). Tais

sistemas não podem ser desativados quando o código executável necessita ser atualizado (ex.:

correção de erros, implantação de novos componentes). Desse modo, a questão da

configuração dinâmica deve ser modelada preliminarmente, ou seja, em tempo de design

arquitetural, para permitir que os stakeholders envolvidos nas fases posteriores do ciclo de

vida possam ser comunicados sobre tal requisito.

Dentre as funcionalidades que uma ADL-OA deveria ter (vide Seção 5.5.1),

enumeradas por Navasa et al. (2002), apenas a especificação de conectores entre pontos de

junção e aspectos não se encontra contemplada pela notação gráfica proposta neste presente

trabalho.

137

8 – Conclusões e Trabalhos Futuros

8.1 Conclusões

Ficou evidente, por este trabalho, que a incorporação dos conceitos provenientes do

DSOA em nível arquitetural é de grande valia ao desenvolvimento de sistemas de software.

Há na literatura uma lista de interesses transversais inerentes ao domínio de sistemas

distribuídos, e a abstração de aspectos arquiteturais é capaz de modularizar tais interesses,

resolvendo problemas relacionados à dispersão e ao entrelaçamento de interesses. Essa

solução atende prontamente ao princípio da separação de interesses (SoC – Separation of

Concerns).

No entanto, as ADLs convencionais não oferecem os recursos de modelagem

necessários para que os interesses transversais possam ser modularizados. As ADLs-OA

encontradas na literatura constituem-se em soluções que integram conceitos do DSOA com

elementos de ADL propostos no framework de Medvidovic e Taylor (2000). No entanto, tais

propostas são muito divergentes, dificultando um consenso acerca de quais conceitos,

provenientes da POA, realmente necessitam ser elevados a um nível arquitetural, de modo que

a modelagem de arquiteturas orientadas a aspectos torne-se uma tarefa factível. A lista de

características desejáveis em uma ADL-OA apresentada nesta dissertação, constitui-se em

uma contribuição para uma possível padronização.

O conjunto de diretrizes norteadoras, enunciadas no Capítulo 6, teve grande

importância na pesquisa e elaboração do elenco de características desejáveis em uma ADL-

OA apresentado. Tal conjunto serviu para orientar na decisão de quais características

deveriam de fato constar em uma ADL-OA. A proposta de notação visual apresentada neste

trabalho basicamente resultou do esforço realizado para atingir o conjunto das características

desejáveis em uma ADL-OA.

Em relação aos assuntos abordados sobre os tópicos de Sistemas Distribuídos,

Arquitetura de Software, ADL e DSOA, esta proposta cobre, conforme consta na Tabela 6.8,

quesitos como: Replicação; Mobilidade; Heterogeneidade; Transparência; Modelagem de

middlewares. Dinamismo Arquitetural; Refinamento Arquitetural; Modelagem preliminar, em

alto nível de abstração, das metas de projeto e de negócio. Formalidade na representação; Elo

entre o nível arquitetural e estágios subseqüentes; Meio de comunicação intra-equipes e inter-

equipes; Modelagem de interesses transversais em nível arquitetural; Modelagem e controle

da composição dinâmica.

138

Possivelmente, alguns obstáculos poderão ser encontrados, principalmente em relação

à implementação das seguintes características em uma ferramenta de ADL-OA: Identificação

de Aspectos; Verificação do Design e da Implementação; Verificação do Estilo/Padrão; e

Rastreabilidade de Alterações. Tais características requerem um estudo mais aprofundado.

O presente trabalho diferencia-se dos demais, encontrados na literatura, pelo fato de

adotar uma abordagem top-down, partindo de preceitos gerais da Engenharia de Software até

atingir os conceitos da POA. Enquanto os demais (vide Seção 5.5) abordam questões

eminentemente técnicas, de caráter mais computacional, nesta dissertação, algumas questões

são enfatizadas a partir de uma perspectiva do arquiteto de software como ser humano, já que

toda ADL serve, fundamentalmente, como uma ferramenta conceitual para o desenvolvimento

de software numa das etapas mais preliminares do ciclo de vida do software. Além disso, vale

ressaltar que uma representação arquitetural pode ser objeto de análise por parte de

stakeholders leigos (ex.: usuários e clientes), os quais necessitam “visualizar” a arquitetura do

software de um modo bastante claro e simplificado, o que pode ser constatado na notação

gráfica proposta.

Por outro lado, em uma perspectiva de hardware, pode-se afirmar que o custo do

hardware tem reduzido bastante, quando comparado ao custo do software. Ademais, o

desenvolvimento de software é deveras muito mais complexo devido aos fatores humanos

envolvidos. Conseqüentemente, qualquer pesquisa no sentido de facilitar o desenvolvimento

de software com ênfase na minimização das complexidades inerentes ao ser humano é muito

bem vinda. Esta preocupação encontra-se presente em grande parte das diretrizes norteadoras

elencadas na Seção 6.2.

Não obstante esta preocupação referente às necessidades humanas dos usuários de uma

ADL, enfatizada neste trabalho, é salutar a preocupação com a minimização do uso de

recursos de hardware28, pois a sociedade global necessita preservar o meio ambiente em

vários sentidos: economizando energia (consumo de memória e processador, e uso de

displays) e poupando recursos naturais (material utilizado na fabricação de equipamentos).

A utilização de uma ADL eficaz contribui para a redução do tempo de

desenvolvimento, favorecendo, conseqüentemente, a economia de energia (devido à redução

do tempo que os equipamentos permanecerão ativos para dar suporte ao desenvolvimento).

Em tempo de execução, a construção de um software modelado por meio de uma ADL eficaz

28 Os recursos de hardware já não se constituem mais na preocupação central no desenvolvimento de projetos de software, devido à constante queda do seu custo comparado com o custo do software.

139

tende a resultar em um software executável com melhor desempenho, consumindo menos

largura de banda, e mais fácil de ser mantido: gerando menos consumo de recursos de energia.

8.2 Trabalhos futuros

Uma pesquisa com a finalidade de verificar qual formalismo matemático é o mais

adequado para servir como fundamento para a especificação/definição da notação formal de

uma ADL-OA, constitui-se em um trabalho cujo campo pode ser bastante fértil. Na literatura,

ainda não se encontram disponíveis trabalhos comprovando quais recursos são

imprescindíveis, em uma notação formal, para a modelagem arquitetural de uma sistema

orientada a aspectos.

Como trabalho futuro principal, consta a elaboração de uma notação formal textual,

possivelmente, com base no π-Calculus, de modo que as análises formais possam ser

realizadas sobre as descrições arquiteturais modeladas por meio dessa notação. Somente após

a definição formal da notação, será possível implementar as características relacionadas ao

processo de design arquitetural e às ferramentas de apoio.

Um trabalho bastante interessante é a verificação da compatibilidade entre a notação

gráfica proposta e o formalismo matemático π-Calculus que servirá de base à ADL. Faz-se

necessário verificar se o formalismo π-Calculus oferece todos os recursos de modelagem

apresentados na notação gráfica proposta. Essa pesquisa validaria, formalmente, a notação

gráfica proposta, proporcionando-lhe consistência e a possibilidade de implementação em

uma ferramenta de ADL.

Outro trabalho futuro consiste na utilização do recurso Profile da UML a fim de

implementar a notação gráfica aqui proposta. A especificação precisa da notação visual, com

base na UML 2.0, é também um trabalho que dará suporte à construção de ferramentas de

apoio à ADL-OA. O uso de estereótipos da UML 2.0 pode dar condições para a especificação

de um profile para a notação visual proposta.

As características relacionadas às ferramentas de design arquitetural não puderam ser

verificadas durante o experimento devido ao fato de que seria necessário ter uma ferramenta

já implementada, e isso dependeria, também, da especificação da ADL por meio de um

formalismo matemático. Uma iniciativa poderia ser a utilização de alguma ADL extensível,

como, por exemplo, a proposta por Dashofy, Hoek e Taylor (2005), a fim de realizar a

implementação das características levantadas nesse trabalho.

140

Da mesma forma, os itens relacionados à modelagem de configurações arquiteturais

listados no framework de Medvidovic e Taylor (2000) não puderam ser verificados, já que as

informações referentes às configurações arquiteturais são formalmente descritas em termos de

uma notação textual. Por exemplo, a especificação das restrições que representam as

dependências em uma configuração não pode ser completa e formalmente descrita em termos

de uma notação gráfica, pois, para tanto, é necessário que a sintaxe e a semântica da notação

textual da ADL estejam devidamente definidas.

141

Referências

ABOWD, Gregory D.; ALLEN, Robert; GARLAN, David; Formalizing Style to Understanding Descriptions of Software Architecture, In ACM Transactions on Software Engineering and Methodology, vol. 4, no.4, pp. 319-364, Oct 1995.

ALDAWUD, Omar; ELRAD, Tzilla; BADER, Atef; UML Profile for Aspect-Oriented Software Development, In Omar Aldawud, editor, 3rd Workshop on Aspect-Oriented Modeling (AOM/AOSD’03), Boston, March 2003.

ALDRICH, Jonathan; CHAMBERS, Craig; NOTKIN, David; ArchJava: Connecting Software Architecture to Implementation, In Proceedings of the International Conference on Software Engineering (ICSE’02), May 19-25, Orlando, Published by ACM Press, pp. 187-197, 2002-a.

ALDRICH, Jonathan; Open Modules: Modular Reasoning about advice, In Proceedings of the European Conf. on Object-Oriented Programming (ECOOP’05), 144-168, July 2005.

ALLEN, Robert; GARLAN, David; A formal approach to software architectures, In Proceedings of the IFIP’92, Elsevier, pp. 134-141, September, 1992.

ALLEN, Robert; GARLAN, David; Formalizing Architectural Connection, In Proceedings of the 16th International Conference on Software Engineering, pp. 71-80, May 1994.

ALLEN, Robert; A Formal Approach to Software Architecture, Ph.D. Thesis, School of Computer Science, Carnegie Mellon University, CMU Technical Report CMU-CS-97-144, May 1997.

ALLEN, Robert; GARLAN, David; A Formal Basis for Architectural Connection, In ACM Transactions on Software Engineering and Methodology, Jul 1997.

ALLEN, Robert; DOUENCE, Rémi; GARLAN, David; Specifying and Analyzing Dynamic Software Architectures, In Proceedings of the 1998 Conference on Fundamental Approaches to Software Engineering, Lisbon, Portugal, Mar 1998.

ALLEN, Robert J.; GARLAN, David; IVERS, James; Formal Modeling and Analysis of the HLA Component Integration Standard, In Proceedings of the 6th International Symposium on Foundations of Software Engineering, Published by ACM Press, pp. 70-79, November 1998.

ANDREWS, Gregory; Paradigms for process interaction in distributed programs, In ACM Computing Surveys, vol. 23, no. 1, pp. 49-90, Mar 1991.

AOSD; Aspect Oriented Software Development Homepage, disponível em http://aosd.net, ultimo acesso em Julho de 2007.

BACHMANN, Felix; BASS, Len; KLEIN, Mark; SHELTON, C.; Designing software architectures to achieve quality attribute requirements, In IEE Proceedings -Software, vol. 152, no. 4, pp. 153- 165, August 2005.

BAKKER, Jethro; TEKINERDOĞAN, Bedir; AKSIT, Mehmet; Characterization of Early Aspects Approaches, In Proceedings of the Workshop on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design (with AOSD’05), 2005.

BANIASSAD, Elisa L. A.; CLARKE, Siobhán; Theme: An Approach for Aspect-Oriented Analysis and Design, In Proceedings of the 26th International Conference on Software Engineering (ICSE’04), Edinburgh, Scotland, Published by IEEE Computer Society Press, pp. 158-167, May 2004.

BANIASSAD, Elisa; CLEMENTS, Paul C.; ARAÚJO, João; MOREIRA, Ana; RASHID, Awais; TEKINERDOGAN, Bedir; Discovering Early Aspects, In IEEE Software, v. 23, n. 1, pp. 61-70, Jan-Feb 2006.

BARAIS, O.; CARIOU, E.; DUCHIEN, L.; PESSEMIER, N.; SEINTURIER, L.; TranSAT: A Framework for the Specification of Software Architecture Evolution, Presented at Workshop on Coordination and Adaptation Techniques for Software Entities (ECOOP’2004), Oslo, Norway, 2004.

142

BASS, Len; CLEMENTS, Paul; KAZMAN, Rick; Software Architecture in Practice, Addison-Wesley, 1998.

BASS, L.; CLEMENTS, P.; KAZMAN, R.; Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003.

BASS, Len; KLEIN, Mark; NORTHROP, Linda; Identifying Aspects Using Architectural Reasoning, Publishe by IEEE Software, 2004.

BATISTA, Sueleni Mendez; Uma ferramenta de apoio à fase de requisitos da mdsodi no contexto do ambiente DiSEN, Dissertação de Mestrado – Programa de Pós-Graduação em Informática, Universidade Federal do Paraná, Curitiba, 2003.

BATISTA, Thais; CHAVEZ, Christina; GARCIA, Alessandro; SANT’ANNA, Cláudio; KULESZA, Uirá; RASHID, Awais; COSTA FILHO, Fernando; Aspectual Connectors: Supporting the Seamless Integration of Aspects and ADLs, In Proceedings of the ACM SIGSoft XX Brazilian Symposium on Software Engineering (SBES’06), Florianópolis, Brazil, Oct 2006-a.

BATISTA, Thais; CHAVEZ, Christina; GARCIA, Alessandro; SANT’ANNA, Cláudio; KULESZA, Uirá; RASHID, Awais; COSTA FILHO, Fernando; Reflections on Architectural Connections: Seven Issues on Aspects and ADLs, In Proceedings of the EA’06, May 21, Shangay, Published by ACM Press, 2006-b.

BLINN, P.; VESTAL, S.; Formal real-time architecture specification and analysis, Pres. at 10th IEEE Workshop on Real-Time Operating Systems and Software, May 1993.

BOEHM, Barry W.; Software Engineering Economics, Prentice Hall, 1991.

BOEHM, Barry; IN, Hoh; Identifying Quality-Requirement Conflicts, Published in IEEE Software, vol. 13, no. 2, p. 25-35, March 1996.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar; UML: guia do usuário, 2a ed. rev. e atualiz. – Rio de Janeiro: Elsevier, 2005.

BRITO, I.; MOREIRA, A.; Integrating the NFR framework in a RE model, In Proceedings of 3rd Workshop on Early Aspects, 3rd International Conference on Aspect-Oriented Software Development, March 2004.

BUSCHMANN, Frank; MEUNIER, Regine; ROHNERT, Hans; SOMMERLAND, Peter; STAL, Michael; Pattern-Oriented Software Architecture: a system of patterns, reprinted April 1999 - Chichester-UK: John Wiley & Sons, 1996.

CHAVEZ, C.; GARCIA, A.; KULESZA, U.; SANT’ANNA, C.; LUCENA, C.; Crosscutting Interfaces for Aspect-Oriented Modeling, PUC-Rio, Rio de Janeiro, Brazil, Technical Report TR-23-05, March 2005.

CHITCHYAN, Ruzanna; RASHID, Awais; SAWYER, Peter; GARCIA, Alessandro (ULANC); PINTO Alarcon, Mónica; (UMA); BAKKER, Jethro; TEKINERDOGAN, Bedir (UT); CLARKE, Siobhán; JACKSON, Andrew (TCD), Survey of Aspect-Oriented Analysis and Design Approaches, AOSD-Europe-ULANC-9, AOSD-Europe Network of Excellence, University of Lancaster, May 2005.

CLELAND, D. I.; IRELAND, L. R.; Gerência de Projetos, Rio de Janeiro: Reichmann & Affonso, 2002.

CLEMENTS, Paul; A Survey of Architecture Description Languages, In Proceedings of the Eighth International Workshop on Software Specification and Design, Paderborn, Germany, Mar 1996.

CLEMENTS, Paul; KAZMAN, Rick; KLEIN, Mark; Evaluating software architectures: methods and case studies, CMU-SEI – Boston: Addison-Wesley, 2002.

CLEMENTS, P.; NORTHROP, L.; Software Product Lines: Practices and Patterns, Addison-Wesley, 2002.

143

CLEMENTS, Paul; BACHMANN, Felix; BASS, Len; GARLAN, David; IVERS, James; LITTLE, Reed; NORD, Robert; STAFFORD, Judith; Documenting software architectures: views and beyond, CMU-SEI – Boston: Addison-Wesley, 2003.

COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim; Sistemas Distribuídos: conceitos e projeto, 4a ed. – Porto Alegre: Bookman, 2007.

CUESTA, Carlos E.; del PILAR Romay, María; de la FUENTE, Pablo; BARRIO Solórzano, Manuel; Architectural Aspects of Architectural Aspects, In Proceedings of the 2nd European Workshop on Software Architecture: (EWSA’05), Pisa, Italy, LNCS 3527, pp. 247-262, Jun 13-14, 2005-a.

DASHOFY, Eric M.; MEDVIDOVIC, Nenad; TAYLOR, Richard N.; Using Off-The-Shelf Middleware to Implement Connectors in Distributed Software Architectures, In Proceeding of the International Conference on Software Engineering (ICSE’99), Los Angeles, ACM Press, pp. 3-10, May 16-22, 1999.

DASHOFY, Eric M.; van der HOEK, André; TAYLOR, Richard N.; A Highly-Extensible, XML-Based Architecture Description Language, In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA’01), pp.103-112, IEEE CS Press, Aug 28-31, 2001.

DASHOFY, Eric M.; van der HOEK, André; TAYLOR, Richard N.; A Comprehensive Approach for the Development of Modular Software Architecture Description Languages, In ACM Transactions on Software Engineering and Methodology, vol. 14, no. 2, pp. 199-245, Apr 2005.

DEREMER, Frank; KRON, Hans; Programming-in-the-Large versus Programming-in-the-small, In Proceedings of the International Conference on Reliable Software, ACM Press, pp. 114-121, 1975.

DIJKSTRA, E. W.; The Structure of the THE Multiprogramming System, Published in Communications of ACM, 1968.

EMMERICH, Wolfgang; Engineering Distributed Objects, Reprinted August 2001, Chichester, England: John Wiley & Sons, 2000.

ENAMI, Lúcia Norie Matsueda; Um modelo de gerenciamento de projetos para um ambiente de desenvolvimento distribuído de software, Dissertação de Mestrado, Programa de Pós-Graduação em Ciência da Computação, Universidade Estadual de Maringá, Maringá, 2006.

FIDGE, C. J.; Timestamps in message-passing systems that preserve the partial ordering, In Australian Computer Science Comm. vol. 10, no. 1, pp. 55-66, Feb 1988.

FREIRE, Paulo; A Importância do Ato de Ler: em três artigos que se completam, 45ª ed., Cortez: São Paulo, 2003.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.; Design Patterns: Elements of Reusable Object-Oriented Software, Mass: Addison-Wesley, 1995.

GARCIA, Alessandro; From Objects to Agents: An Aspect-Oriented Approach, PhD Thesis, Department of Computer Science, PUC-Rio, Brazil, 2001.

GARCIA, Alessandro; CHAVEZ, Christina; SOARES, Sérgio; PIVETA, Eduardo; PENTEADO, Rosângela; de CAMARGO, Valter; FERNANDES, Fabrício; Relatório do 1º Workshop Brasileiro sobre Desenvolvimento de Software Orientado a Aspectos – WASP 2004, In Proceedings of 1st the Workshop Brasileiro sobre Desenvolvimento de Software Orientado a Aspectos (WASP’2004), SBES, Brasília, Brasil, 2004.

GARCIA, Alessandro; KULESZA, Uirá; SANT’ANNA, Cláudio; CHAVEZ, Christina; de LUCENA, Carlos J. P.; Aspects in Agent-Oriented Software Engineering: Lessons Learned, Presented at Workshop on Agent-Oriented Software Engineering (held with AAMAS’05), Utrecht, The Netherlands, Jul 2005.

GARCIA, Alessandro; CHAVEZ, Christina; BATISTA, Thaís; SANT'ANNA, Cláudio; KULESZA, Uirá; RASHID, Awais; de LUCENA, Carlos; Driving and Managing Architectural Decisions with

144

Aspects, Presented at SHARK’06 (held with ICSR’06 Conference), Turin, Italy, ACM Press, Jun 11, 2006-a.

GARCIA, Alessandro; CHAVEZ, Christina; BATISTA, Thaís; SANT'ANNA, Cláudio; KULESZA, Uirá; RASHID, Awais; de LUCENA, Carlos; On the Modular Representation of Architectural Aspects, In Proceedings of the 3rd European Workshop on Software Architecture, France, Sep 2006-b.

GARLAN, David; ALLEN, Robert; OCKERBLOON, J.; Exploiting Style in Architectural Design Environments, In Proceedings of the SIGSOFT’94: The 2nd ACM SIGSOFT Symp. Foundations of Software Engineering, pp. 179-185, New Orleans, Dec 1994.

GARLAN, David; MONROE, Robert; WILE, David; Acme: An Architecture Description Interchange Language, In Proceedings of the CASCON’97, Ontario, Published by ACM Press, pp. 169-183, Nov 1997.

GARLAN, David; MONROE, Robert; WILE, David; Acme: Architectural Description of Component-Based Systems, In Foundations of Component-Based Systems, Gary T. Leavens and Murali Sitaraman (eds.), pp. 47-68, Cambridge University Press, 2000.

GARLAN, David; SHAW, Mary; An Introduction to Software Architecture, In Advances in Software Engineering and Knowledge Engineering, Volume I, 39 pp., V. Ambriola and G. Tortora (eds.), World Scientific Publishing Company, New Jersey, 1993.

GARLAN, David; SHAW, Mary; An Introduction to Software Architecture, CMU-CS-94-166 TR, Jan 1994.

GARLAN, David; PERRY, Dewayne; Introduction to the Special Issue on Software Architecture, In IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 269-274, 1995.

GIMENES, Itana M. S.; HUZITA, Elisa H. M.; (orgs.) Desenvolvimento baseado em componentes: conceitos e técnicas, Rio de Janeiro: Ciência Moderna, 2005.

GORLICK, M. M.; RAZOUK, R. R.; Using Weaves for Software Construction and Analysis, In Proceedings of the 13th International Conference on Software Engineering (ICSE’91), pp. 23-34, Austin, May 1991.

GRUHN, Volker; SCHÄFER, Clements; An Architecture Description Language for Mobile Distributed Systems, In Proceedings of the 1st European Workshop on Software Architecture (EWSA’04), St. Andrews, Scotland, UK, May 21-22, Published by Springer-Verlag, Heidelberg, pp. 212-218, 2004.

GRUHN, Volker; SCHÄFER, Clements; Architecture Description for Mobile Distributed Systems, In Proceedings of the 2nd European Workshop on Software Architecture (EWSA’05), Pisa, Italy, June 13-14, Published in LNCS 3527, 2005.

HERBSLEB, James D.; MOITRA, Deependra; Global Software Development, Guest Editors’ Introduction, IEEE Software, pp. 16-20, Mar/Apr, 2001.

HERZUM, P.; SIMS, O.; Buziness Component Factory: a comprehensive overview of component-based development for enterprise, John-Wiley & Sons, 2000.

HOARE, C. A. R.; Communicating Sequential Processes, In Communications of ACM, vol. 21, no. 28, pp. 666-677, 1978.

HOFMEISTER, C.; NORD, R. L.; SONI, D.; Applied Software Architecture, Addison-Wesley, 1999.

HUZITA, Elisa Hatsue Moriya; Suporte à Reutilização em Ambientes Distribuídos de Desenvolvimento de Software. Projeto em andamento (CNPq). Projeto de pesquisa em andamento, Universidade Estadual de Maringá. Departamento de Informática, 2007.

IEEE; IEEE Standard 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Press, 2000.

145

IEEE; IEEE Standard 610.12-1990, IEEE Press, 1990.

ISO; ISO/IEC 14102-1995 Information Technology, Guideline for the Evaluation and Selection of CASE Tools, 1995.

KANDÉ, M. M.; A concern-oriented approach to software architecture, In Computer Science, vol. PhD, Lausanne, Switzerland: Swiss Federal Institute of Technology (EPFL), 2003.

KAZMAN, Rick; BASS, Len; ABOWD, Gregory; WEBB, Mike; SAAM: A Method for Analyzing the Properties of Software Architectures, In Proceedings of the 16th International Conference on Software Engineering (ICSE’94), Published by IEEE CS Press, pp. 81-90, May 16-21, 1994.

KAZMAN, R.; ABOWD, G.; BASS, L.; CLEMENTS, P.; Scenary-Based Analysis of Software Architecture, In IEEE Software, vol. 13, no. 6, pp.47-55, Nov 1996.

KHARE, Rohit; GUNTERSDORFER, Michael; OREIZY, Peyman; MEDVIDOVIC, Nenad; TAYLOR, Richard N.; xADL: Enabling Architecture-Centric Tool Integration With XML, In Proceedings of the 34th Hawaii International Conference on System Sciences, 9 pp., Jan 3-6, 2001.

KICZALES, G.; LAMPING, J.; MENDHEKAR, A.; MAEDA, C.; LOPES, C.; LOINGTIER, J. M.; IRWIN, J.; Aspect-Oriented Programming, In Proceedings of the ECOOP’97 - Object-Oriented Programming, 11th European Conf., LNCS 1241, pp. 220-242, 1997.

KICZALES, G.; HILSDALE, E.; HUGUNIN, J.; KERSTEN, M.; PALM, J.; GRISWOLD, W. G.; An overview of AspectJ, In Proceedings of the European Conference on Object-Oriented Programming, Budapest, Hungary, pp. 18-22, Jun 2001.

KICZALES, Gregor; MEZINI, Mira; Aspect-Oriented Programming and Modular Reasoning, In: Proc. of the International Conference on Software Engineering (ICSE’05), St. Louis, Missouri, USA, May 15-21, 2005.

KOGUT, P.; CLEMENTS, P. C.; Features of Architecture Description Languages, CMU/SEI Technical Report Draft, December 1994.

KRUCHTEN, Philippe; Architectural Blueprints - The ‘4+1’ View Model of Software Architecture, In IEEE Software, vol. 12, no. 6, pp. 42-50, Nov 1995.

KRUCHTEN, Philippe; OBBINK, Henk; STAFFORD, Judith; The Past, Present, and Future of Software Architecture, In IEEE Software, vol. 22, no. 2, pp. 22-30, Mar-Apr 2006.

KULESZA, U.; GARCIA, A.; LUCENA, C.; Generating Aspect-Oriented Agent Architectures, In Proceedings of the 3rd Workshop on Early Aspects (held with AOSD’04), Mar 2004-a.

KULESZA, U.; GARCIA, A.; LUCENA, C.; von STAA, A.; Integrating Generative and Aspect-Oriented Technologies, presented at 19th ACM SIGSoft Brazilian Symposium on Software Engineering, Brasília, 2004-b.

LAMPSON, B. W.; Hints for Computer System Design, In IEEE Software, vol. 1, no. 1, pp. 11-28, Jan 1984.

LEA, Doug; ALEXANDER, Christopher; An Introduction for Object Oriented Designers, In ACM SIGSOFT Software Engineering Notes, vol. 19 no. 1, pp. 39-46, Jan 1994.

LICHTNER, Kurt; ALENCAR, Paulo; COWAN, Don; An Extensible Model of Architecture Description, In Proccedings of the SAC’00, Como, Italy, Published by ACM, pp. 156-165, Mar 19-21, 2000.

LIMA, Fabiana; Mecanismos de Apoio ao Gerenciador de Recursos Humanos no Contexto de um Ambiente Distribuído de Software, Dissertação de Mestrado – Programa de Pós-Graduação em Ciência da Computação, Univ. Estadual de Maringá, Maringá, 2004.

LUCKHAM, David C.; KENNEY, John; AUGUSTIN, Larry; VERA, James; BRYAN, Doug; MANN, Walter; Specification and Analysis of System Architecture Using Rapide, In IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 336-355, Apr 1995.

146

LUCKHAM, David C.; VERA, James; An Event-Based Architecture Definition Language, In IEEE Transactions on Software Engineering, vol. 21, no. 9, pp. 717-734, Sep 1995.

MAGEE, J.; DULAY, N.; EISENBACH, S.; KRAMER, J.; Specifying Distributed Software Architectures, In W. Schafer and P. Botella (eds.), In Proceedings of the 5th European Software Engineering Conference (ESEC’95), Springer-Verlag, pp. 137-153, Sep 1995.

MAGEE, J.; KRAMER, J.; Dynamic Structure in Software Architectures, In Proc. of ACM SIGSOFT’96: 4th Symposium on the Foundations of Software Engineering (FSE4), pp. 3-14, San Francisco, CA, Oct 1996.

MEDVIDOVIC, N.; OREIZY, P.; ROBBINS, J. E.; TAYLOR, R. N.; Using Object-Oriented Typing to Support Architectural Design in the C2 Style, In Proceedings of ACM SIGSOFT’96: 4th Symposium on the Foundations of Software Engineering (FSE4), pp. 24-32, San Francisco, CA, Oct 1996.

MEDVIDOVIC, N.; ROSENBLUM, D. S.; Domains of Concern in Software Architectures and Architecture Description Languages, In Proceedings of the USENIX Conference on Domain-Specific Languages, pp. 199-212, Santa Barbara, CA, Oct 1997.

MEDVIDOVIC, Nenad; ROSENBLUM, David S.; TAYLOR, Richard N.; A Language and Environment for Architecture-Based Software Development and Evolution, In Proc. of the 1999 International Conference on Software Engineering (ICSE’99), Los Angeles, Published by ACM Press, pp. 44-53, May 16-22, 1999.

MEDVIDOVIC, Nenad; TAYLOR, Richard N.; A Framework for Classifying and Comparing Architecture Description Languages, In Proceedings of 6th European Software Engineering Conference, LNCS vol. 1301, pp. 60-76, Sep 1997.

MEDVIDOVIC, N.; TAYLOR, R.; A Classification and Comparison Framework for Software Architecture Description Languages, In IEEE Transactions on Software Engineering, vol. 26, no. 1, pp.70-93, Jan 2000.

MEDVIDOVIC, Nenad; ROSENBLUM, David S.; REDMILES, David F.; ROBBINS, Jason E.; Modeling Software Architecture in the Unified Modeling Language, In ACM Trans. on Software Engineering and Methodology, vol. 11, no. 1, pp.2-57, Jan 2002.

MEDVIDOVIC, Nenad; DASHOFY, Erich M.; TAYLOR, Richard N.; The Role of Middleware in Architecture-Based Software Development, In International Journal of Software Engineering and Knowledge Engineering, vol. 13, no. 4, pp. 267-393, World Scientific Publishing Company, 2003.

MIKIC-RAKIK, Marija; MEDVIDOVIC, Nenad; A Connector-Aware Middleware for Distribution Deployment and Mobility, In Proceedings of the 23rd International Conference on Distributed Computing Systems Workshops (ICDCSW’03), IEEE Software Press, pp. 388-393, May 19-22, 2003.

MILLER, George; The magical number seven, plus minus two: some limits on our capacity for processing information, Psychological Review, vol. 63, pp. 81-97.

MILLS, John A.; A Pragmatic View of the System Architect, In Communications of ACM, vol. 28, no. 7, pp. 708-717, July 1985.

MILNER, R.; PARROW, J.; WALKER, D.; A calculus of mobile process, Parts I and II, Journal of Information and Computation, vol. 100, pp. 1-40 and pp. 41-77, 1992.

MONROE, Robert T.; KOMPANEK, Andrew; MELTON, Ralph; GARLAN, David; Architectural Styles, Design Patterns, and Objects, In IEEE Software, vol. 14, no. 1, pp. 43-52, Jan-Feb 1997.

MORICONI, M.; QIAN, X.; RIEMENSCHNEIDER, R. A.; Correct Architecture Refinement, Published in IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 356-372, Apr 1995.

147

MORO, César Fernado; Suporte à persistência de artefatos para o ambiente distribuído de desenvolvimento de software DiSEN, Dissertação de Mestrado – Programa de Pós-Graduação em Informática, Univ. Federal do Paraná, Curitiba, 2003.

NAVASA, Amparo; PÉREZ, Miguel Angel; MURILLO, Juan Manuel; HERNÁNDEZ, J. Aspect-Oriented Software Architecture: a Structural Perspective, Workshop on Early Aspect, (held with AOSD’02), Enschede, Holland, 2002.

NAVASA, Amparo; PÉREZ, Miguel Angel; MURILLO, Juan Manuel; Aspect Modelling at Architecture Design, In Proceedings of the 2nd European Workshop on Software Architecture (EWSA’05), Pisa, Italy, LNCS 3527, Jun 13-14, 2005.

NII, H. P.; Blackboard Systems, AI Magazine, vol. 7, no. 3, pp. 38-53, 1986, vol. 7, no. 4, pp. 82-107, 1986.

OMG; Object Management Group, disponível em http://www.omg.org/, último acesso em Julho de 2007.

OQUENDO, Flavio; ππππ-ADL: An Architecture Description Language based on the Higher-Order Typed ππππ-Calculus for Specifying Dynamic and Mobile Software Architectures, In ACM Software Engineering Notes, vol. 29, no. 5, 14 pp., May 2004.

OQUENDO, F.; Formally Modelling Software Architectures with the UML 2.0 Profile for ππππ-ADL, In ACM SIGSOFT Software Engineering Notes, vol. 31, no. 1, 13 pp., Jan 2006.

OREISY, P.; MEDVIDOVIC, N.; TAYLOR, R. N.; Architecture-Based Runtime Software Evolution, In Proceedings of the 20th Intern. Conference on Software Engineering (ICSE’98), pp. 177-186, Kyoto, Apr 1998.

OSSHER, H.; TARR, P.; Multi-Dimensional Separation of Concerns and The Hyperspace Approach, In Proceedings of the Symposium on Software Architectures and Component Technology: The State of the Art in Software Development, Kluwer, 2000.

PARNAS, David Lorge; On the Criteria to Be Used in Decomposing Systems into Modules, Communications of ACM, vol. 15, no.12, pp.1053-1058, Dec. 1972.

PARNAS, D.; On a ‘Buzzword’: Hierarchical Structure, In Proc. of the IFIP Congress 74, pp. 336-339, 1974.

PARNAS, David Lorge; On the Design and Development of Program Families, IEEE Transactions on Software Engineering, vol. 2, no.1, pp.1-9, Mar 1976.

PARNAS, D.; CLEMENTS, P.; WEISS, D.; The Modular Structure of Complex Systems, In IEEE Trans. on Software Engineering, vol. SE-11, no. 3, pp. 259-266, Mar 1985.

PARNAS, D.; CLEMENTS, P.; A Rational Design Process: How and Why to Fake It, In IEEE Transactions on Software Engineering, vol. 12, no. 2, pp. 251-257, 1986.

PASCUTTI, Márcia C. D.; Uma Proposta de Arquitetura de um Ambiente de Desenvolvimento de Software Distribuído Baseada em Agentes, Dissertação de Mestrado, Instituto de Informática, Univ. Federal do Rio Grande do Sul, Porto Alegre, 2002.

PAWLAK, R.; SEINTURIER, L.; DUCHIEN, Lionel; FLORIN, G.; LEGOND-AUBRY, F.; MARTELLI, L.; JAC: an Aspect-based Distributed Dynamic Framework, Software – Practice and Experience, vol. 34, pp. 1119-1148, 2004.

PEDRAS, Maria Edith V.; Uma Ferramenta de Apoio ao Gerenciamento de Desenvolvimento de Software Distribuído, Dissertação de Mestrado – Programa de Pós-Graduação em Informática, Universidade Federal do Paraná, Curitiba, 2003.

PÉREZ Benedí, Jennifer; RAMOS, Isidro; JAÉN, J.; Patricio; NAVARRO, Elena; PRISMA: Towards Quality, Aspect-Oriented and Dynamic Software Architectures, In Proceedings of the 3rd IEEE International Conference on Quality Software (QSIC’2003), Dallas, Nov 2003.

148

PÉREZ Benedí, Jennifer; ALI, Nour; Angel; CARSÍ, José; RAMOS, Isidro; Dynamic Evolution in Aspect-Oriented Architectural Models, In R. Morrison and F. Oquendo (eds), In Proceedings of the 2nd European Workshop on Software Architecture (EWSA’05), LNCS, Pisa, Jun 2005.

PÉREZ, Jennifer; NAVARRO, Elena; LETELIER, Patricio; RAMOS, Isidro; Graphical Modelling for Aspect Oriented SA, In Proc. of the SAC’06, Dijon, France, Published by ACM Press, pp. 597-598, Apr 23-27, 2006.

PERRY, Dewayne E.; WOLF, Alexander L.; Foundations for the Study of Software Architecture, In ACM Software Engineering Notes, vol. 17, no. 4, pp. 40-52, Oct 1992.

PESSEMIER, N.; SEINTURIER, L.; DUCHIEN, L.; Components, ADL and AOP: Towards a Common Approach, Presented at Workshop ECOOP Reflection, AOP and Meta-Data for Software Evolution (RAM-SE’04), Jun 2004.

PESSEMIER, N.; SEINTURIER, L.; COUPAYE, T.; DUCHIEN, L.; A Model for Developing Component-based and Aspect-Oriented Systems, In Proceedings of the 5th International Symposium on Software Composition (SC’06), Vienna, Mar 2006.

PINTO, Monica; FUENTES, Lidia; FAYAD, M. E.; TROYA, J. M.; Towards an Aspect-Oriented Framework in the Design of Collaborative Virtual Environments, In Proceedings of the 8th IEEE Workshop on FTDCS’01, Nov 2001.

PINTO, Monica; FUENTES, Lidia; FAYAD, M. E.; TROYA, J. M.; Separation of Coordination in a Dynamic Aspect-Oriented Framework, In Proc. of the 1st International Conference on AOSD’02, Apr 2002.

PINTO, Monica; FUENTES, Lidia; TROYA, J. M.; DAOP-ADL: An Architecture Description Language for Dynamic Component and Aspect-Based Development, In Proceedings of the 2nd International Conference on GPCE, F. Pfenning and Y. Samaradakis (eds.), Erfurt, LNCS, vol. 2830, Springer-Verlag, pp. 118-137, 2003.

PINTO, Monica; FUENTES, Lidia; TROYA, J. M.; A Dynamic Component and Aspect Platform, The Computer Journal, 401-420, 2005.

POZZA, Rogério dos Santos; Proposta de um Framework para Aspectos do Gerenciador de Workspace no Ambiente DiSEN, Dissertação de Mestrado – Programa de Pós-Graduação em Ciência da Computação, Univ. Estadual de Maringá, Maringá, 2005.

PRESSMAN, Roger S., Engenharia de Software, 6a ed. – São Paulo: McGraw-Hill, 2006.

RAJAN, H.; SULLIVAN, K.; Classpects: Unifying Aspect- and Object-Oriented Language Design, In Proceedings of the ICSE’2005, USA, 2005.

RASHID, A.; MOREIRA, A.; ARAÚJO, J.; Modularization and composition of aspectual requirements, In Proc. of the 2nd Intern. Conference on Aspect-oriented Software Development, pp. 11-20, ACM Press, 2003.

ROBBINS, Jason E.; REDMILES, David F.; ROSENBLUM, David S.; Integrating C2 with the Unified Modeling Language, In Proceedings of the California Software Symposium (CSS’97), Irvine, Nov 1997.

SCHMIDT, Douglas C.; STAL, Michael; ROHNERT, Hans; BUSCHMANN, Frank; Pattern-Oriented Software Architecture: patterns for concurrent and networked objects, reprinted April 2001 – Chichester: John Wiley & Sons, 2000.

SCHIAVONI, Flávio Luiz; FRADE – Framework para infra-estrutura de um Ambiente Distribuído de Desenvolvimento de Software, Dissertação de Mestrado – Programa de Pós-Graduação em Ciência da Computação, Universidade Estadual de Maringá, Maringá, 2007.

SEBESTA, Robert W.; Conceitos de Linguagens de Programação, 5ª ed. – Porto Alegre: Bookman, 2003.

149

SEI; Software Engineering Institute Web Site, disponível em www.sei.cmu.com.edu, ultimo acesso em 20/11/2006.

SELIC, B.; The Pragmatics of Model-Driven Development, In IEEE Software, vol. 20, n. 5, pp. 19-25, 2003.

SHAW, Mary; Abstraction Techniques In Modern Programming Languages, In IEEE Software, vol. 1, no. 4, pp. 10-26, Oct 1984.

SHAW, Mary; Toward Higher-Level Abstractions for Software Systems, In Proceedings of Tercer Simposio Internacional del Conocimiento y su Ingerieria, (printed by Rank Xerox) (invited), pp.55-61, Oct 1988.

SHAW, Mary; Elements of a Design Language for Software Architecture, Position Paper for IEEE Design Automation Workshop, January 1990.

SHAW, Mary; Heterogeneous Design Idioms for Software Architecture, In Proceedings of the 6th International Workshop on Software Specification and Design, pp. 158-165, IEEE Press, Oct 1991.

SHAW, Mary; Making Choices: A Comparison of Styles for Software Architecture, In IEEE Software, Special Issue on Software Architecture, vol. 12, no. 6, pp. 27-41, 1995.

SHAW, Mary; The Coming-of-Age of Software Architecture Research, In Proceedings of the 23rd International Conference on Software Engineering (ICSE’01), Published by IEEE CS Press, pp. 657-664, 2001.

SHAW, M.; GARLAN, D.; Characteristics of Higher-Level Languages for Software Architecture, Tech. Report, CMU-CS-94-210, Carnegie Mellon University, Dec 1994.

SHAW, M.; GARLAN, D.; Formulations and Formalisms in Software Architecture, Jan van Leeuwen, editor, Computer Science Today: Recent Trends and Developments, vol. 1000, LNCS, Springer-Verlag, 1995.

SHAW, M.; GARLAN, D.; Software Architectures: Perspectives on an Emerging Discipline, Englewood Cliffs, NJ: Prentice-Hall, 1996.

SHAW, M.; DELINE, R.; ZELESNIK, G.; Abstractions and Implementations for Architectural Connections, In Proc. of the 3rd International Conference on Configurable Distributed Systems, May 1996.

SHAW, M.; CLEMENTS, P.; A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems, In Proceedings of the 21st International Computer Software and Applications Conference (COMPSAC’97), Published by CS Press, pp. 6-13, 1997.

SHAW, M.; CLEMENTS, P.; The Golden Age of Software Architecture, Technical Report CMU-ISRI-06-101, Carnegie Mellon, Institute for Software Research International, Feb 2006.

SHAW, M.; DELINE, R.; KLEIN, Daniel V.; ROSS, Theodore L.; YOUNG, David M.; ZELESNIK, G.; Abstractions for Software Architecture and Tools for Support Them, In IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 314-335, Apr 1995.

SOMMERVILLE, Ian; Engenharia de Software, 8ª ed., São Paulo: Pearson Addison-Wesley, 2007.

SONI, Dilip; NORD, Robert L.; HOFMEISTER, Christine; Software Architecture in Industrial Applications, In Proc. of 17th International Conference on Software Engineering (ICSE’95), ACM Press, pp. 196-207, 1995.

SUTTON, S.; ROUVELLOU, I.; Modeling of Software Concerns in Cosmos, In Proceedings of the 1st Aspect-Oriented Software Development Conference, pp. 127-134, Enschede, The Netherlands, 2003.

SZYPERSKI, C.; Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1998.

TANENBAUM, A. S.; Redes de Computadores, 4ª ed., Rio de Janeiro: Campus, 2003.

150

TANENBAUM, Andrew S.; van STEEN, Maarten; Distributed Systems: principles and paradigms, Upper Saddle River – NJ: Prentice-Hall, 2002.

TARR, Peri; OSSHER, Harold; SUTTON Jr., Stanley M.; HARRISON, William; N-Degrees of Separation: Multi-Dimensional Separation of Concerns, In Robert E. Filman, Tzilla Elrad, Siobhán Clarke, and Mehmet Aksit (eds.), Aspect-Oriented Software Development, pp. 37-61, Addison-Wesley, Boston, 2005.

TEKINERDOGAN, Bedir; ASAAM: Aspectual software architecture analysis method, In Proc. of the 4th Working IEEE/IFIP Conf. on Software Architecture (WICSA’04), Published by IEEE CS Press, pp. 5-14, 2004.

TEKINERDOGAN, Bedir; SCHOLTEN, Frank; ASAAM-T: A tool environment for identifying architectural aspects, Technical Report, University of Chicago, 2005.

TERRY, A.; LONDON, R.; PAPANAGOPOULOS, G.; DEVITO, M.; The ARDEC/Teknowledge Architecture Description Language (ArTek), Version 4.0 Technical Report, Teknowledge Federal Systems, Inc. e U.S. Army Armament Research, Development, e Engineering Center, Jul 1995.

TRACZ, W.; LILEANNA: A Parameterized Programming Language, In Proceedings of the 2nd International Workshop on Software Reuse, pp. 66-78, Lucca, Italy, Mar 1993.

VESTAL, S.; A Cursory Overview and Comparison of Four Architecture Description Languages, Technical Report, Honeywell Technology Center, Feb 1993.

WEISER, M.; Some computer science issues in ubiquitous computing, Published in Communications of ACM, vol. 36, no. 7, pp. 74-84, 1993.

WIESE, Igor; Um Modelo de Interoperabilidade para Ambientes de Desenvolvimento Distribuído de Software, Dissertação de Mestrado – Programa de Pós-Graduação em Ciência da Computação, Universidade Estadual de Maringá, Maringá, 2006.

151

Anexo 1 – Resultados da Comparação de ADLs de (MEDVIDOVIC; TAYLOR, 2000)

Tabela A1-1: Escopo e Aplicabilidade das ADLs – Fonte: (MEDVIDOVIC; TAYLOR, 2000)

ADL ACME Aesop C2 Darwin MetaH Rapide SADL UniCon Weaves Wright

Foco

Intercâmbio arquitetural, predominan-temente no nível estrutural

Especificação de arquiteturas em estilos específicos

Arquiteturas altamente distribuídas, evolutivas, e de sistemas dinâmicos

Arquiteturas de sistemas altamente distribuídos cujo dinamismo é guiado por um estrito alicerce formal

Arquiteturas no domínio de guia, navegação e controle de navegação (GN&C)

Modelagem e simulação do comportamento dinâmico descrito por uma arquitetura

Refinamento formal de arquiteturas através de níveis de detalhes

Geração de código glue para a interconexão de componentes existentes usando protocolos de interação de componentes

Arquitetura de fluxo de dados, caracterizadas por grande volume de dados e requisitos de tempo real no seu processamento

Modelagem de sistemas do comportamento dinâmico (especificamente, análise de deadlock) de sistemas concorrentes

152

Tabela A1-2: Suporte das ADL para Modelagem de Componentes – Fonte: (MEDVIDOVIC; TAYLOR, 2000) ADL Características Interface Tipos Semântica Restrições Evolução Propried Não Funcionais

ACME

Component; independente da implementação

Pontos de interface são ports

Sistema de tipos extensível; parametrização possibilitada c/ templates

Não apóia; pode usar modelos semânticos de outras ADLs na lista de propriedades

Apenas através de interfaces

Subtificação estrutural através da feature extends

Permite qualquer atributo na lista de propriedades, mas não opera eles

Aesop Component; independente da implementação

Pontos de interface são input ports e output

ports

Sistema de tipos extensível

(opcional) linguagens de estilo específico para especificação de semântica

Por meio de interfaces e semântica; invariantes estilísticas

Subtipificação com preservação do comportamento

Permite associação de texto arbitrário com componentes

C2


Interface exportada das ports do topo às da base; elementos da interface são provided e required

Sistema de tipos extensível

Invariantes de componentes e pré e pós condições de operações em lógica de 1ª ordem

Através de interfaces e semântica; invariantes estilísticas

Subtipificação heterogênea

Não

Darwin Component; independente da implementação

Pontos de interface são services (provided e required)

Sistema de tipos extensível; suporta parametrização

π-calculus Através de interfaces e semântica

Não Não

MetaH

Process; restrição de implementação

Pontos de interface são ports

Conjunto de tipos enumerados pré-definidos

ControlH para modelagem de algoritmos no domínio GN&C29; semântica de implementação através de paths

Através de interfaces e semântica; modos; atributos não funcionais

Não Atributos necessários para análise de escalonamento de tempo real, confiabilidade, e segurança

Rapide

Interface; independente de implementação

Pontos de interface são constituints (provides,

requires, action, e service)

Sistema de tipos extensível; contém uma sublinguagem de tipos; apóia parametrização

Conjuntos de eventos parcialmente ordenados (posets)

Através de interfaces e semântica; restrições algébricas no estado do componente; restrições de padrões em eventos posets

Herança (subtipificação estrutural)

Não

SADL


Pontos de interface são ports de entrada e de saída (iports e oports)

Sistema de tipos extensível; permite parametrização de assinaturas de componentes

Não Através de interfaces; invariantes estilísticas

Subtipificação por restrição de subtipos; refinamento por meio de mapas de padrões

Requer modificação de componentes

UniCon

Component; restrição de implementação

Pontos de interface são players

Conjunto de tipos pré-definidos enumerados

Rastreia eventos em listas de propriedades

Através de interfaces e semântica; atributos; restrições em players que podem ser fornecidos por tipos de componentes

Não Atributos para análise de escalonamento

Weaves

Component; restrição de implementação

Pontos de interface são read ports e write ports; elementos de interfaces são objetos

Sistema de tipos extensível; tipos são sockets components

Ordenação parcial sobre objetos de entrada e de saída

Através de interfaces e semântica

Nada Permite associação de anotações arbitrárias não interpretadas com componentes

Wright


Pontos de interface são ports; semântica de interação da porta especificada em CSP

Sistema de tipos extensível; número parametrizável de portas e computação

Não focaliza; permitido em CSP Protocolos de interação para cada porta em CSP; invariantes estilísticas

Através de diferentes instanciações de parâmetros

Nada

29 Domínio GN&C: Domínio de Guia, Navegação e Controle de Navegação.

153

Tabela A1-3: Suporte das ADL para Modelagem de Conectores – Fonte: (MEDVIDOVIC; TAYLOR, 2000) ADL Características Interface Tipos Semântica Restrições Evolução Prop. Não Funcionais

ACME

Connector; explícito Pontos de interface são roles

Sistema de tipos extensível, baseado em protocolos; parametrização via templates

Não suporta; pode usar modelos semânticos de outras ADLs na lista de propriedades

Via interfaces e estrutural para instâncias de tipos

Subtificação estrutural através da feature extends

Permite qualquer atributo na lista de propriedades, mas não opera eles

Aesop Connector; explícito Pontos de interface são

roles

Sistema de tipos extensível, baseado em protocolos

(opcional) semântica especificada usando Wright

Via interfaces e semântica; invariantes estilísticos

Subtipificação com preservação do comportamento

Permite associação de texto arbitrário com componentes

C2

Connector; explícito Interface com cada componente através de uma porta separada; elementos de interface são provided e required

Sistema de tipos extensível, baseado em protocolos

Semântica parcial especificada via filtros de mensagens

Via semântica; invariantes estilísticos (cada porta participa em apenas um link)

Interfaces reflexivas ao contexto; mecanismos de filtragem evolutivos

Nada

Darwin

Binding; in-lin; sem modelagem explícita de interações de componentes

Nada; permite “componentes de conexão”

Nada Nada Nada Nada Nada

MetaH

Connection; in-line; permite às conexões serem nomeadas opcionalmente

Nada Nada; suporta três classes genéricas de conexão: porta, evento, e equivalência

Nada Nada Nada Nada

Rapide

Connection; in-line; conectores reusáveis complexos apenas via “components de conexão”

Nada; permite “componentes de conexão”

Nada Posets; conexões condicionais

Nada Nada Nada

SADL

Connector; explícito Assinatura de componente especifica os tipos de dados suportados

Sistema de tipos extensível; assinaturas e restrições parametrizadas

Axiomas na linguagem de restrição

Via interfaces; invariantes estilísticos

Subtipificação; refinamento de conectores via mapas de padrões

Requer modificação de componetes (veja Seção 4.3.9)

UniCon

Connector; explícito Pontos de interface são roles

Conjunto de tipos pré-definidos enumerados

Implícita nos tipos dos conectores; informação semântica pode ser dada em listas de propriedades

Via interfaces; restringe o tipo de players que pode ser usados em um dado papel

Nada Atributos para análise de escalonamento

Weaves

Transport services; explícito

Pontos de interface são o encapsulamento de socket pads

Sistema de tipos extensível; tipos são sockets conectores

Via convenções de nomeação

Via interface Nada Permite associação de anotações arbitrárias não interpretadas com serviços de transporte

Wright

Connector; explícito Pontos de interface são roles; a semântica de interação de papéis é especificada em CSP

Sistema de tipos extensível, baseado em protocolos; número parametrizável de papéis e glue

Semântica do glue conector em CSP

Via interfaces e semântica; protocolos de interação para cada papel em CSP; invariantes estilísticos

Através de instanciações de parâmetros diferentes

Nada

154

Tabela A1-4: Suporte das ADLs para Modelagem de Configurações Arquiteturais – Fonte: (MEDVIDOVIC; TAYLOR, 2000)

ADL Caracter. Compreensão Composição Refin/Rastreab Heterogeneidade Escalabilidade Evolução Dinamismo Restrições Propr. Não Func.

ACME

Attachmen

ts; explícito

Especificação textual explícita e concisa

Fornecida por meio de templates, representações e rep-maps

Rep-maps Listas de propriedades aberta; mapeamentos explícitos através de ADLs

Auxiliada por configurações explícitas; dificultada pelo número fixo de papéis

Auxiliada por configurações explícitas; famílias como primeira classe

Não As portas podem apenas estar vinculadas a papéis vice-versa

Permite qualquer atributo na lista de propriedades, mas não os opera

Aesop

Configu-

ration; explícito

Especificação gráfica explícita e concisa; hierarquia de tipos paralela para visualização

Fornecida por meio de representações

Não Permite múltiplas linguagens para modelagem da semântica; apóia desenvolvimento em C

Auxiliada por configurações explícitas; dificultada pelo número fixo de papéis

Sem suporte a arquiteturas parciais; auxiliada por configurações explícitas;

Não As portas podem apenas estar vinculadas a papéis vice-versa; invariantes estilísticas programáveis

Não

C2

Architec-

tural

Topology; explícito

Especificação gráfica e textual explícita e concisa

Permitida; suportada via arquitetura de componentes interna

Não Possibilitada pela arquitetura de componentes interna; suporta desenvolvimento em C++, Java e Ada

Auxiliada por configurações explícitas e número variável de portas de conectores; usada na construção de sua própria suíte de ferramentas

Permite arquiteturas parciais; auxiliada por configurações explícitas; mínimas dependências inter-componentes; conectores heterogêneos

Dinamismo não antecipado; inserção, remoção, e re-escrita de elementos

Invariantes estilísticas fixas

Não

Darwin

Binding; in-line

Especificação textual in-line com muitos detalhes de conectores; provê notação gráfica

Suportada pela feature componente composta da linguagem

Suporta geração de sistemas durante restringindo implementação

Permite múltiplas linguagens para a modelagem da semântica de componentes primitivos; suporta desenvolvimento em C++

Dificultada pelas configurações in-

line

Sem suporte a arquiteturas parciais; dificultada pelas configurações in-line

Dinamismo limitado: aplicação em tempo de execução de componentes e configuração condicional

Serviços fornecidos podem apenas estar vinculados a serviços requeridos e vice-versa

Não

MetaH

Connec-

tions; in-

line


Suportada via macros

Suporta geração de sistemas; restringindo implementação

Suporta desenvolvimento em Ada; exige que todo componente contenha um laço de despacho de processo

Dificultada pelas configurações in-line;

Sem suporte a arquiteturas parciais; dificultada pelas configurações in-line

Não Applications são restrições com atribuos não funcionais

Suporta atributos tais como processadores de execução e período de clock

Rapide

Connect; in-line


Mapeamentos associam uma arquitetura a uma interface

Mapas de refinamentos possibilitam simulações comparativas de arquiteturas em diferentes níveis

Suporta desenvolvimento de simulações executáveis na sub-linguagem executável da Rapide

Dificultada pelas configurações in-line; usada em projetos de grande porte

Sem suporte a arquiteturas parciais; dificultada devido a configurações in-line

Dinamismo limitado; configuração condicional e geração de eventos dinâmica

Mapas de refinamentos forçam refinamentos válidos; linguagem de restrição de poset temporizada

Modelo poset temporizado permite a modelagem de temporização na linguagem de restrição

SADL

Configu-

ration; explícito


Mapeamentos associam uma arquitetura a um componente

Mapas de refinamentos possibilitam refinamentos corretos através de estilos

Suporta elementos de alta e baixa granulosidade

Auxiliada por configurações explícitas; usada em projetos de grande porte

Sem suporte a arquiteturas parciais; auxiliada por configurações explícitas

Não Invariantes estilísticas programáveis; mapas de refinamento forçam refinamentos válidos

Arquitetura modificada pela adição de restrições

155

ADL Caracter. Compreensão Composição Refin/Rastreab Heterogeneidade Escalabilidade Evolução Dinamismo Restrições Propr. Não Func.

UniCon

Connect; explícito

Especificação gráfica e textual explícita; a descrição da configuração pode estar distribuída

Suportada via componentes compostos e conectores


Suporta apenas tipos de componentes e conectores pré-definidos; suporta wrappers de componentes

Auxiliada por configurações explícitas e número variável de portas de conectores

Algum suporte a arquiteturas parciais; auxiliada por configurações explícitas

Não Players podem apenas ser anexados a papéis e vice-versa

Não

Weaves

Weaves; explícito

Especificação gráfica explícita e concisa

Apoiada por meio de sockets componentes


Desenvolvimento em C, C++, Objective C, e Fortran; requer que todos os tool

fragments forneçam um conjunto de métodos

Auxiliada por configurações explícitas, sockets, e número variável de sockets pads; usada em projetos de grande porte

Permite arquiteturas parciais; auxiliada por configurações explícitas; suporte para famílias via framework populados por sockets


Impede links diretos componente-a-componente

Permite associação de anotações interpretadas arbitrárias com weaves

Wright

Attach-

ments; explícito


Computations e glue são expressos como arquiteturas

Não Suporta elementos de alta e baixa granulosidade

Auxiliada por configurações explícitas e número variável de papéis; usada em projetos de grande porte

Adequada para especificação parcial; auxiliada por configurações explícitas


As portas podem apenas serem anexadas a papéis e vice-versa; invariantes estilísticas programáveis

Não

156

Tabela A1-5: Ferramentas de Suporte das ADLs – Fonte: (MEDVIDOVIC; TAYLOR, 2000) ADL Especificação Ativa Múltiplas Visões Análise Refinamento Geração de Implementação Dinamismo

ACME

Não Textual; “weblets” na ACME-Web; visões arquiteturais em termos de alto nível (template), assim como construtores básicos

Analisador sintático (parser) Não Não Não

Aesop

Editor de componentes dirigido à sintaxe; classes de visualização invocam editores especializados externos

Textual e gráfico; visualizações específicas de estilo; tipos de componentes e de conectores em ícones distintos

Analisador sintático (parser); compilador específico do estilo; verificador de tipo; verificador para conflitos de recursos e factibilidade de escalonamento

Não Ferramenta build constrói código glue do sistema em C para o estilo pipe-and-filter

Não

C2

Processo de “arquiteturação” pró-ativo em DRADEL; verificador de tipos reativo, não intrusivo; crítica de design e listas to-do no Argo

Textual e gráfico; visão do processo de desenvolvimento

Analisador sintático (parser); verificador de regras do estilo; verificador de tipos

Gera skeletons de aplicações que podem ser completadas por meio de reuso de componentes OTS

A classe framework possibilita a geração de código em C/C++, Ada, e Java; o DRADEL gera skeletons de aplicações

ArchStudio permite a manipulação do dinamismo antecipado de arquiteturas

Darwin

Adição automatizada de portas para componentes de comunicação; propagação de alterações ao longo de portas vinculadas; diálogos para especificar propriedades de componentes

Textual, gráfico, e visão hierárquica do sistema

Analisador sintático (parser); compilador; cenários “what if” por meio de instanciação de parâmetros e de componentes dinâmicos

Compilador; componentes primitivos são implementados em uma linguagem de programação tradicional

Compilador gera código em C++

Suporte em tempo de compilação e de execução para alteração dinâmica restrita de arquiteturas ( replicação e configuração condicional)

MetaH

Editor gráfico requer correção de erros quando as alterações à arquitetura são aplicadas; restringe a escolha de propriedades de componentes por meio de menus

Textual e gráfico; tipos de componentes distintos por ícones diferentes

Analisador sintático (parser); compilador; análise de escalonamento, de confiabilidade, e de segurança


Abordagem DSSA30; compilador gera código em Ada

Não

Rapide

Não Textual e gráfico; visualização do comportamento da execução por meio de simulações animadas

Analisador sintático (parser); compilador; análise por meio de filtragem e animação de eventos; verificador de restrição para garantir mapeamentos válidos

Compilador para sub-linguagem executável; ferramentas para verificar e compilar mapas de padrões de eventos durante a simulação

Construção da simulação do executável na sub-linguagem executável da Rapide

Suporte em tempo de compilação e de execução para alteração dinâmica restrita de arquiteturas (configuração condicional)

SADL

Não Apenas textual Analisador sintático (parser); análise de corretude relativa da arquitetura em relação a um mapa de refinamento

Verificador para aderência de arquiteturas em face de um mapeamento provado manualmente

Não Não

UniCon

Editor gráfico previne erros durante o design por meio da invocação do verificador de linguagem

Textual e gráfica; tipos de componentes e conectores distintos por ícones diferentes

Analisador sintático (parser); animação da execução em tempo real; observadores de baixo overhead; análise/depuração de componentes em uma weave


Compilador gera código em C Não

Weaves

Não Apenas gráfico; tipos de componentes e conectores (sockets) distintos por ícones diferentes

Analisador sintático (parser); verificador de modelo para conformidade de tipo de portas para papéis; análise de conectores individuais para deadlock

Não Ligação dinâmica de componentes em C, C++, Objective C, e Fortran; sem geração de código

A Jacqurd permite a manipulação dinâmica não antecipada de weaves

Wright

Não Textual apenas; verificador de modelo fornece um equivalente textual de símbolos CSP

Não Não Não

30 DSSA (Domain Specific Software Architecture): Arquitetura de Software de um Domínio Específico

157

Anexo 2 – Resultados do survey de (CLEMENTS, 1996)

A2-1. Tabelas de Resultados

O questionário circulou junto aos mantenedores de mais de uma dezena de ADLs. A

Tabela A2-1 contém a lista daquelas que tiveram seus questionários respondidos e tiveram

seus resultados validados. A fim de ganhar confiança no questionário, os autores aplicaram-no

a algumas linguagens, tais como Modechart, que não seriam consideradas ADLs. O objetivo

foi observar como essas linguagens se classificaram a fim de tentar entender as qualidades

que distinguem as ADLs das não ADLs.

Tabela A2-1: ADLs levantadas – Fonte: (CLEMENTS, 1996)

ADL Origem Referência

ArTek Teknowledge (TERRY; ERMAN; DEVITO, 1994)

CODE University of Texas at Austin (NEWTON; BROWNE, 1992)

Demeter Northeastern University (PALSBERG; XIAO; LIEBERHERR, 1995)

Modechart University of Texas at Austin (JAHANIAN; MOK, 1994)

PSDL/CAPS Naval Postgraduate School (SHING; BARNES; HUGHES, 1993)

Resolve Ohio State University (HEYM et al., 1994)

UniCon Carnegie Mellon University (SHAW et al., 1995)

Wright Carnegie Mellon University (ALLEN; GARLAN, 1994)

A Tabela A2-2 explica os símbolos das respostas contidas na Tabela A2-3, a qual, por

sua vez, serve como um guia de referência rápido para os leitores interessados em encontrar

uma linguagem para uma aplicação em particular.

Tabela A2-2: Legenda das respostas

Símbolo Significado S Sim N Não A Alta capacidade: a linguagem provê características explícitas para dar suporte a

esta capacidade. M Médio: a linguagem provê características genéricas por meio das quais esta

capacidade pode ser indiretamente alcançada. B Baixo: a linguagem provê pouco suporte. F Ferramenta desenvolvida especificamente para a ADL dar suporte a esta

capacidade. E Ferramenta externa que fornece esta capacidade. P A linguagem provê informação suficiente para dar suporte à capacidade, mas

nenhuma ferramenta de suporte atualmente existe.

158

Tabela A2-3: Resultados do survey das ADLs

Atributos

AR

TE

K

CO

DE

DE

ME

TE

R

MO

DE

CH

AR

T

PSD

L/C

AP

S

RE

SOL

VE

UN

ICO

N

WR

IGH

T

Aplicabilidade

Habilidade para representar estilos M M M M A M M A

Habilidade para manipular questões de tempo real M M A A B A B

Habilidade p/ manipular questões de sist. distrib. A A A A A M M M

Habilidade para manipular arquiteturas dinâmicas B A A B M B ? B

Qualidade de definição da linguagem

Atenção à completude da especificação da arquit. M B A M M B M A

Atenção à consistência da especificação da arquit. B B M B M A B A

Escopo da linguagem; usuário pretendidos

Requisitos A B ? A A M B B

Design/algoritmos detalhados B M A M A M B B

Código M B A B B A A B

Engenheiro de domínio S S S N S N S S

Engenheiro da aplicação S S S S S S S S

Analista de sistemas S N S S S S N S

Captura do histórico do design ? B ? B ? ? ? ?

Visões

Textual S N S S S S S S

Gráfico S S S S S N S N

Riqueza da visão semântica B M A A A B ? B

Referência cruzada inter-visões M B B M M B M B

Suporte a variabilidade M B A B A A B A

Poder de expressão, extensibilidade A B M M A A M M

Suporte à criação de arquitetura F F P F F E F

Suporte à validação de arquitetura F F E F F P F E

Suporte à refinamento de arquitetura F P P F F P P P

Suporte à análise de arquitetura E P F F P

Suporte à construção da aplicação F P P

Maturidade das ferramentas

Disponível como COTS N N ? N N N N N

Idade (anos) 3 ? 10 7 5 ? 2 3

Número de sites em uso 11 ? ? 4 12 4 1 1

Suporte ao cliente disponível S S N N N S N N

A2-2. Explicação dos Resultados

Para criar o guia de referência rápido, os surveys completos foram extraídos usando-se as seguintes heurísticas:

159

• Se fosse possível combinar um conjunto de questões em um conjunto geral sobre a capacidade da linguagem sem perder o detalhe significativo, isto era feito. A classificação da capacidade geral de uma linguagem é a média aritmética de suas pontuações nas questões componentes (se a escala for ordenada, tal como Alto/Médio/Baixo), ou a resposta que aparecia com mais freqüência nas questões componentes (se a escala de classificação não for ordenada). Se as questões componentes eram Sim/Não, então a classificação sumária reflete a taxa de respostas Sim.

• As questões nas quais todas as linguagens fizeram a mesma pontuação, ou aproximadamente a mesma, tendiam a serem suprimidas, uma vez que elas não serviam como discriminadores úteis entre as linguagens.

A2-2.1. ADLs versus outras linguagens

As linguagens que são consideradas as tendências atuais das ADLs compartilham os seguintes aspectos:

• As abstrações que elas fornecem aos usuários eram arquiteturais por natureza. Todas representaram componentes e conexões.

• A maioria das visões fornecidas pelas ADLs continham informações predominantemente arquiteturais. Isto está em contraste com uma linguagem de programação ou uma linguagem de requisitos que tendem a mostrarem outros tipos de informações.

• A análise fornecida pela linguagem fia-se em informação de nível arquitetural. Isto está em contraste a um analisador de desempenho que identifica gargalos baseados em informações de implementação (isto é, código fonte).

A2-2.2 Discriminadores

As áreas seguintes descobriram diferenças interessantes entre as ADLs levantadas:

• As ADLs diferiram de forma marcante em relação às suas habilidades para manipular construtores de tempo real no nível arquitetural. Grosso modo, a metade tinham a pretensão de tratar construtores de tempo real hard tais como deadlines; apenas um pequeno número lidaram com construtores de tempo real soft tais como prioridades das tarefas.

• As ADLs variam em relação às suas habilidades em dar suporte à especificação de estilos arquiteturais. Todas as ADLs eram capazes de representar arquiteturas pipe-and-filter, diretamente ou indiretamente. Outros estilos não se saíram muito bem. Todas forneceram estruturação hierárquica de componentes, e eram capazes de representar objetos, mas apenas poucas eram capazes de manipular herança de classes orientadas a objetos. Apenas duas manipulavam arquiteturas dinâmicas.

• O conjunto de ADLs levantadas se divide uniformemente em relação às suas habilidades de permitir o usuário definir novos tipos de componentes e conectores, definir novos comandos na ADL, e representar informações não arquiteturais (tais como requisitos, ou casos de teste) usando a ADL. Extensibilidade e escopo foram bons discriminadores.

• Enquanto todas linguagens forneceram regras de consistência interna e regras de completude integradas para artefatos representados nessas linguagens, poucas permitiram ao usuário definir o que queriam dizer por consistência, e poucas lidaram com consistência entre diferentes artefatos (ex., entre uma arquitetura e designs de componentes).

160

• As ADLs variaram amplamente em suas habilidades de dar suporte à análise. A Modechart caracteriza um verificador de modelo que recebe como entrada uma asserção lógica e relata se a descrição do sistema garante, proíbe, ou é meramente compatível com essa asserção. Uma capacidade de análise mais genérica (tal como no caso de um verificador) mostrado no questionário como a habilidade para analisar muitos atributos de qualidade diferentes. Por exemplo, um simulador tinha a capacidade de ser usado para analisar a usabilidade permitindo que os usuários observem o comportamento simulado para ver se ele atinge suas expectativas.

• As ADLs diferiram em relação às suas capacidades de manipular variabilidade, ou diferentes instanciações da mesma arquitetura. Todas apoiavam a variabilidade de componentes por meio da capacidade de simples re-escrita, mas poucas apoiavam a manutenção de diferentes instanciações da mesma arquitetura simultaneamente.

• Quando oferecem mais do que uma visão arquitetural, as ADLs variam amplamente em suas habilidades de converter entre essas visões. A capacidade de intercambiar entre visões é um forte discriminador entre as ADLs levantadas.

A2-2.3 Atributos comuns

Foram observados os seguintes atributos comuns:

• Todas as ADLs levantadas tinham uma sintaxe gráfica; todas exceto uma tinham uma forma textual. Toda linguagem exceto uma tinha a característica de uma sintaxe formal, e a vasta maioria era caracterizada por semântica definida formalmente.

• Toda linguagem tinha a pretensão de ser apta a modelar sistemas distribuídos.

• As ADLs tendiam a não fornecer muito suporte para capturar o rationale e/ou histórico do design, a não ser por meio de mecanismos de anotações genéricas ou de propósito geral.

• Todas as ADLs tinham a pretensão de manipular fluxo de dados e fluxo de controle na forma de mecanismos de interconexão. A Modechart foi a mais fraca a este respeito, devido a sua habilidade para lidar apenas com predicados de estados (tais como “data

sent”) ao invés de valores de dados realísticos.

• Todas as ADLs forneceram ajuda na criação e validação e refinamento de arquiteturas, mesmo se a validação fosse apenas feita no contexto das regras da própria linguagem para completude ou legalidade.

• Todas as ADLs tinha a características da habilidade para representar níveis hierárquicos de detalhes, e manipular instanciações de uma template como um modo rápido para executar a cópia de sub-estruturas durante a criação.

• Todas ADLs oferecem suporte ao engenheiro da aplicação, e a maioria dá suporte ao engenheiro de domínio, mesmo que apenas indiretamente. A maioria dá suporte ao analista do sistema por meio do fornecimento de capacidades analíticas abertamente. Nenhuma tinha a pretensão de diretamente dar suporte ao gerenciamento de projetos.

• Finalmente, um atributo comum muito evidente foi a carência de experiência detalhada e aplicação do mundo real que as ADLs atualmente oferecem. Espera-se que assim como que os benefícios da arquitetura tornam-se melhor compreendidos, que os benefícios de representações formais serão igualmente recompensados, e as ADLs se tornarão elas próprias como tecnologias viáveis para o desenvolvimento de sistemas complexos.

161

Anexo 3 – Caracterização de Abordagens de Aspectos Preliminares

Este anexo apresenta uma análise realizada por Bakker, Tekinerdoğan e Aksit (2005) acerca das seguintes abordagens de aspectos preliminares,

• Theme/Doc (BANIASSAD; CLARKE, 2004)

• Modularização e composição de requisitos aspectuais (RASHID; MOREIRA; ARAÚJO, 2003)

• Integração do framework NFR em um modelo ER (BRITO; MOREIRA, 2004)

• Identificação de aspectos usando raciocínio arquitetural (BASS; KLEIN; NORTHROP, 2004)

• Abordagens generativas orientadas a aspectos (KULESZA; GARCIA; LUCENA, 2004-a) e (KULESZA; GARCIA; LUCENA, 2004-b)

• Método de análise de arquitetura de software aspectual (TEKINERDOGAN, 2004)

• Modelagem de interesse no Ambiente de Manipulação de Interesse (SUTTON; ROUVELLOU, 2003)

A3-1 Theme/Doc

(BANIASSAD; CLARKE, 2004)

1. Fase: Análise de Requisitos.

2. Objetivo: Identificação e especificação de aspectos preliminares.

3. Artefatos: requisitos textuais, ações, entidades e temas. Dois tipos de temas são distinguidos: temas básicos e temas transversais.

4. Regras Heurísticas e Processos: Theme/Doc consiste de três sub-processos: Identificação de ações e entidades que formam os requisitos textuais, categorização de ações em temas, identificação de temas transversais. Cada sub-processo inclui regras heurísticas. A decisão se um tema é transversal é explicitamente definida, enquanto as regras para a identificação de ações e entidades e a decisão de quais ações são suficientemente grandes para ser um tema permanece implícita (“altamente intuitiva”).

5. Modelo de Aplicação: Theme/Doc fornece visões que expõe quais comportamentos estão co-localizados nos requisitos. A visão de ação principal é usada para mostrar graficamente a relação entre requisitos e ações. A clipped action view é usada para representar os temas transversais. Juntamente com essas visões a visão de temas é usada para planejar o design e a modelagem dos temas identificados. A visões de temas diferem das visões de ações no fato de que elas apenas mostram requisitos e ações, mas também mostram elementos essenciais do sistema que necessitam ser considerados para cada design de tema.

6. Ferramenta de Suporte: a ferramenta Theme/Doc está atualmente sob desenvolvimento. A ferramenta adota requisitos textuais, interesses, grupos de interesses, entidades, anexos, associações e postponements com entrada. Esta ferramenta cria várias visões e suporta a identificação e especificação de interesses transversais na fase de análise de requisitos.

7. Suporte à Rastreabilidade: Theme/Doc é focada apenas na fase de análise de requisitos. Não há suporte à rastreabilidade para a fase de análise de domínio ou de design de arquitetura.

162

A3-2 Modularização e Composição de Requisitos Aspectuais (AORE)

(RASHID; MOREIRA; ARAÚJO, 2003)


2. Objetivo: Identificação de interesses transversais no nível de análise de requisitos, especificação e avaliação destes interesses.

3. Artefatos: interesses, requisitos dos stakeholders, uma matriz relacionando interesses e requisitos de stakeholders, regras de composição e uma matriz de contribuição.

4. Regras Heurísticas e Processos: AORE fornece os seguintes sete passos que são seqüencialmente executados: identificar & especificar interesses e requisitos de stakeholders; identificar interesse de alta granularidade / relacionamentos de requisitos de stakeholders; identificar aspectos candidatos; definir regras de composição para um aspecto candidato e os requisitos de stakeholders; identificar e resolver conflitos entre aspectos candidatos; redefinir requisitos; e especificar dimensões de aspectos.

Apesar de o processo ser bem definido, não se pode dizer o mesmo em relação às regras heurísticas. Algumas regras heurísticas estão explícitas, tais como, a identificação de aspectos candidatos, mas muitas outras regras permanecem implícitas.

5. Modelo de aplicação: O resultado do processo é um conjunto de aspectos candidatos, que são interesses que entrecortam múltiplos requisitos.

6. Ferramenta de Suporte: Há uma ferramenta chamada Aspectual Requirements

Composition and Decision (ARCADE). Esta ferramenta está atualmente sob desenvolvimento. A ferramenta torna possível definir os requisitos de ponto de vista, requisitos aspectuais e regras de composição usando templates pré-definidos.

7. Suporte à Rastreabilidade: AORE suporta identificação e especificação de aspectos na fase de análise de requisitos, mas não há suporte a rastreabilidade para outras fases.

A3-3 Integração do framework NFR em um modelo ER (INFR)

(BRITO; MOREIRA, 2004)


2. Objetivo: Identificação de interesses transversais.

3. Artefatos: documentação de stakeholders, catálogos, templates, interesses e match points. Os templates são usados para especificar um interesse. Um match point especifica qual interesse transversal deve ser composto com um dado interesse. As regras de composição definem a ordem na qual os interesses serão aplicados em um determinado match point.

4. Regras Heurísticas e Processos: A abordagem INFR consiste de quatro tarefas: identificar interesses, especificar interesses, identificar interesses transversais e compor interesses.

5. Modelo de Aplicação: aspectos candidatos, que são interesses que entrecortam múltiplos requisitos.

6. Ferramenta de Suporte: atualmente não há disponível ferramenta de suporte para esta abordagem.

7. Suporte à Rastreabilidade: A abordagem INFR foca na fase de análise de requisito, e não contém suporte à rastreabilidade para outras fases preliminares do ciclo de vida do desenvolvimento de software.

163

A3-4 Identificação de aspectos usando raciocínio arquitetural

(BASS; KLEIN; NORTHROP, 2004)

1. Fase: Design Arquitetural.

2. Objetivo: A identificação de aspectos usando a abordagem de raciocínio arquitetural (IAAR) tenta derivar uma arquitetura de software partindo de seus requisitos de atributo de qualidade por meio de insights captados dos modelos de atributos de qualidade criados usando-se táticas arquiteturais.

3. Artefatos: requisitos de atributos de qualidade, arquitetura.

4. Regras Heurísticas e Processos: contém táticas arquiteturais que conduzem a aspectos arquiteturais (candidatos). Uma tática arquitetural é um meio de satisfazer uma response

measure de um cenário de atributo de qualidade por meio da manipulação de algum aspecto de um modelo de atributo de qualidade através de decisões de design arquitetural. Os pontos de junção arquiteturais são pontos bem definidos na especificação da arquitetura de software. Conjuntos de junção arquiteturais são meios de referência para coleções de pontos de junções arquiteturais. Aspectos arquiteturais são visões arquiteturais consistindo de conjuntos de junções e comportamentos transversais arquiteturais.

As táticas arquiteturais levam a aspectos arquiteturais. Mas como identificar as táticas arquiteturais? O primeiro passo do processo é formular requisitos de atributos de qualidade em formato de cenário. O segundo passo do processo consiste em construir um modelo de atributo de qualidade. O terceiro passo do processo é transferir informações entre frameworks de raciocínio. O quarto passo no processo é resolver restrições conflitantes. O último passo consiste na interação entre o método de design e o arquiteto.

5. Modelo de Aplicação: os aspectos candidatos identificados a partir do modelo de aplicação.

6. Ferramenta de Suporte: atualmente não há ferramenta de suporte disponível para esta abordagem.

7. Suporte a Rastreabilidade: esta abordagem foca na fase de design de arquitetura, e não há suporte a rastreabilidade para outras fases preliminares do ciclo de vida do desenvolvimento de software.

A3-5 Abordagens Generativas Orientadas a Aspectos (AOGA)

(KULESZA; GARCIA; LUCENA, 2004a) e (KULESZA; GARCIA; LUCENA, 2004b)

A abordagem AOGA31 concentra-se no domínio de Sistemas Multi-Agentes (MAS – Multi-

Agent Systems). Os conceitos introduzidos são genéricos e não limitados ao domínio MAS. 1. Fase: Análise de Domínio e Design de Arquitetura.

2. Objetivo: identificação e especificação de aspectos do domínio e arquiteturais. Com o uso de aspectos a modularização de features MAS poderia ser realizada.

3. Artefatos: conceitos de domínio representam os artefatos na fase de análise de domínio. Nesta primeira camada da fase de design de arquitetura, os componentes e componentes aspectuais com interfaces são os artefatos.

4. Regras Heurísticas e Processos: o processo é composto como segue, primeiro uma linguagem específica de domínio (DSL – domain specific language), chamada Agent-DSL

31 Aspect-Oriented Generative Approach

164

é usada para coletar e modelar as features ortogonais e as features transversais de um agente de software. Segundo, uma arquitetura OA é desenhada para modelar uma família de agentes de software. A arquitetura está centrada na definição de componentes aspectuais para modularizar as features de agentes transversais no nível arquitetural de abstração. No último passo, é usado um gerador de código que mapeia abstrações da Agent-DSL para composições específicas de objetos e aspectos na arquitetura agente.

5. Modelo de Aplicação: contém dois principais modelos de aplicação: modelos de features e modelos de componentes. Os modelos de features são representados em uma linguagem de domínio específico chamada Agent-DSL. A Agent-DSL usa o XML-Schema para representar as features. Na fase de design de arquitetura, a linguagem de modelagem aSide é usada para representar a arquitetura de software.

6. Ferramenta de Suporte: A ferramenta agent architecture generator é implementada como um plug-in Eclipse. A ferramenta é capaz de ler a descrição do agente da Agent-DSL. O plug-in pode gerar as classes para representar os elementos de uma XML-Schema.

7. Suporte a Rastreabilidade: há uma ligação direta de mapeamento entre uma feature transversal na análise de domínio e uma componente aspectual no design de domínio. Assim, há um suporte a rastreabilidade disponível a partir do modelo de aplicação do domínio para o modelo de aplicação arquitetural.

A3-6 Método de Análise de Arquitetura de Software Aspectual (ASAAM32)

(TEKINERDOGAN, 2004)

1. Fase: Design de Arquitetura.

2. Objetivo: o alvo desta abordagem é identificar e especificar explicitamente aspectos preliminares arquiteturais no ciclo de vida do software.

3. Artefatos: cenários e componentes arquiteturais. Existem três tipos de cenários: direto, indireto e aspectual. Um cenário direto pode ser executado diretamente. Cenários indiretos exigem uma alteração de um componente. E cenários aspectuais podem ser diretos ou indiretos e estarem espalhados através de múltiplos componentes. Existem quatro tipos de componentes: componente coeso, componente mal definido, componente entrelaçado, componente composto.

4. Regras Heurísticas e Processos: O processo consiste de cinco passos: desenvolvimento de arquitetura candidata, desenvolvimento de cenários, avaliação de cenário individual e identificação de aspecto, avaliação de interação de cenário & identificação de componentes e refatoração da arquitetura.

5. Modelo de aplicação: um conjunto de aspectos arquiteturais que podem ser usados para refatorar a arquitetura. Os componentes de arquitetura são especificados usando-se o estereótipo: arquitetura. Isto não é uma notação de abstração para aspectos candidatos.

6. Suporte a Ferramentas: ASAAM tem sido implementada como um plug-in Eclipse em no ambiente da ferramenta ASAAM-T.

7. Suporte à Rastreabilidade: esta abordagem foca na fase de design de arquitetura, e não há suporte à rastreabilidade para outras fases preliminares do ciclo de vida do desenvolvimento de software.

32 Aspectual Software Architecture Analysis Method

165

A3-7 Modelagem de Interesse no Ambiente de Manipulação de Interesse (SUTTON; ROUVELLOU, 2003)

1. Fase: a abordagem ConMan abstrai informações a partir do ciclo de vida de software e conseqüentemente este modelo pode ser usado em toda fase do ciclo de vida de software.

2. Objetivo: ConMan tem a pretensão de ser uma ferramenta para modelagem de interesses e uma plataforma para desenvolvimento de abordagens alternativas de modelagem de interesses.

3. Artefatos: o espaço de interesses consiste de: unidades, interesses, relacionamentos e restrições. As unidades são elementos do modelo de interesses cujo propósito é representar, no modelo de interesse, o produto do trabalho do desenvolvimento de software. No espaço de interesses, cada unidade refere-se a um artefato, o qual representa os detalhes do software. No ConMan novos tipos de artefatos, possivelmente envolvendo linguagens não manipuladas previamente podem ser introduzidas. Isto inclui linguagens de software (tais como requisitos, design ou programação) assim como artefatos como diretórios, arquivos jar, XML e outros documentos.

4. Regras heurísticas e Processos: não há suporte à processo e não há regras heurísticas.

5. Modelo de aplicação: o ConMan gerencia um espaço de interesses, o qual modela um corpo de software, e os interesses que são relevantes dentro dele. O corpo de software pode ser um único projeto, sistema ou componente, ou um grande corpo, tal como um workspace do conjunto de trabalho do Eclipse.

6. Suporte a ferramentas: a ferramenta Concern Manipulation Environment (CME) oferece um conjunto de componentes para criar e compor interesses. Atualmente, a ferramenta CME oferece suporte à identificação e modelagem de interesses no nível de design detalhado. Entretanto, no futuro a ferramenta poderá ser usada para a identificação e modelagem de interesses em todas as fases do ciclo de vida do software.

7. Suporte à rastreabilidade: não há suporte explícito à rastreabilidade porque esta abordagem abstrai informações a partir do ciclo de vida do software.

A3-8 Avaliação das Abordagens A Tabela A3-1 representa a análise das abordagens de aspectos preliminares

apresentadas nas seções prévias. Usando os dados da tabela, Bakker, Tekinerdoğan e Aksit (2005) derivaram as seguintes observações.

1. Não há identificação de aspectos na fase de Análise de Domínio

A maioria das abordagens parece estar focalizada na fase de análise de requisitos ou na fase de design de arquitetura. Ainda não há suporte para a identificação de aspectos na fase de análise de domínio. A análise de domínio almeja identificar, capturar e organizar o conhecimento do domínio sobre o domínio do problema, e como tal provê os conceitos a partir de uma perspectiva do domínio da solução. A análise de requisitos provê os interesses a partir de uma perspectiva do domínio do problema. Na verdade, a identificação dos aspectos na análise de requisitos e análise de domínio poderia oferecer suporte um ao outro.

2. Forte foco na identificação de aspectos

Parece haver um forte foco na identificação de aspectos em todas as abordagens. Não obstante, diversas abordagens têm sido fornecidas para modelar aspectos no nível de design detalhado, a modelagem de aspectos preliminares não tem sido investigada em detalhes. Também foi observado que a avaliação de aspectos está faltando. Em (RASHID; MOREIRA;

166

ARAÚJO, 2003) uma análise de trade-off e priorização de aspectos conflitantes é apresentada. Além da análise de aspectos um em relação ao outro, obviamente também deveria haver uma avaliação mais ampla em abordagens para julgar se os aspectos apropriados são identificados, e se os aspectos têm sido especificados corretamente.

3. Não há modelo de interesses uniforme

Apesar de a noção de interesse parecer ser um tema comum a todas as abordagens, os artefatos adotados para a identificação de aspectos e os modelos de interesses adotados são diferentes. Até mesmo as abordagens definidas para uma mesma fase no ciclo de vida parecem ter diferenças. Por exemplo, a abordagem Theme/Doc identifica interesses mas não especifica propriedades dos interesses identificados mas a abordagem INFR usa um template para descrever as propriedades dos interesses. Nós podemos além disso observar que a definição do termo aspecto em diversas abordagens é muito similar à definição de aspectos nas linguagens de programação. Além disso, diferentes abordagens aplicam conceitos que são similares aos conceitos de conjunto de pontos de junção, pontos de junção e comportamento

transversal. Entretanto, não está claro se estes conceitos são os melhores meios para lidar com os interesses transversais nas fases preliminares do desenvolvimento de software.

4. As regras heurísticas diferem por abordagem

Apesar de que a maioria das abordagens definirem um processo explícito, as heurísticas adotadas estão geralmente implicitamente definidas ou dependem da intuição do engenheiro de software. Isto não apenas reduz o entendimento das abordagens, mas também torna subjetiva a interpretação dos métodos.

5. Não há ferramenta de suporte estável

Parece que as metas definidas para a identificação, especificação ou avaliação de aspectos preliminares não estão maduras ainda. Todavia, há esforços intensivos para o desenvolvimento de ferramentas de suporte, por exemplo para as abordagens Theme/Doc, AORE, INFR e ASAAM.

6. Não há suporte a rastreabilidade

A maioria das abordagens tem um forte foco em uma fase dedicada do ciclo de vida do software. Nenhuma das abordagens oferece suporte para rastreamento entre as fases. Para fornecer o rastreamento, o mapeamento a partir de interesses em uma fase para outra deveria ser bem definido. O ConMan provê um meta-modelo que pode ser usado para modelar interesses em toda fase do ciclo de vida do software.

A3-9 Conclusão

Durante os últimos anos diversas abordagens têm sido apresentadas para o tratamento dos aspectos nos estágios preliminares do ciclo de vida de desenvolvimento de software. Nós temos fornecido uma caracterização de abordagens selecionadas e temos comparado estas em relação aos critérios derivados a partir de um framework metodológico para desenvolvimento de software. A caracterização provê uma perspectiva sistemática nas diferentes abordagens e resultou na identificação de diversos problemas abertos que são importantes na identificação, especificação e na avaliação de aspectos na análise de requisitos, análise de domínio e no nível de design de arquitetura. Parece que o foco está meramente na identificação de aspectos durante a análise de requisitos e no design arquitetural. Além disso, está faltando um modelo de interesses uniforme para a representação de aspectos nos estágios preliminares. Não obstante as diferentes abordagens fornecerem um processo sistemático, as regras heurísticas que são aplicadas não são sempre explícitas.

167

Tabela A3-1 – Avaliação das abordagens de aspectos preliminares – Fonte: (BAKKER; TEKINERDOGAN; AKSIT, 2005)

Ciclo de Vida

Objeti-vo

Artefatos Regras Heurísticas Modelos de Aplicação

Ferramentas de Suporte

Suporte à Rastrea-bilidade

Theme/Doc AR Ident Requisitos textuais, ações, entidades e temas

Visões de ações, suporte a regras e suporte a processos para identificação de aspectos

Visão de temas

Em desenvolv. -

AORE AR Ident Interesses, requisitos de stakeholders, matriz relacionando interesses e requisitos de stakeholders e uma matriz de contribuição

Regras de composição, suporte a processo de identificação e especificação de aspectos

Aspectos candidatos

Em desenvolv. -

INFR AR Espec Documentação, catálogos, templates, interesses e match

points

Suporte a processo para identificação e especificação de aspectos, regras heurísticas e regras de composição

Aspectos candidatos, modelo do sistema

Em desenvolv. -

AOAR DA Ident Requisitos de atributos de qualidade

Suporte a processo para identificação de aspectos candidatos

Aspectos candidatos

- -

AOGA AD

DA

Ident Conceitos de Domínio, Componentes (arquiteturais), modelos de features

Suporte a processo para especificação de aspectos

Modelo de arquitetura

Editor XML de modelo de feature, Gerador de Arquitetura Agente, Geração de Código

Sim, mapeamento direto de features transversais

ASAAM DA Ident Cenários Regras heurísticas e suporte a processo para identificação de aspectos: explicitamente especificados

Aspectos arquiteturais

ASAAM-T -

ConMan Abs-trato

Espec. de aspectos

Interesses, Relaciona-mentos, restrições, unidades

- Modelo de interesses

CME -

Legenda – AR: Análise de Requisitos – DA: Design Arquitetural – AD: Análise de Domínio

UM CONJUNTO DE CARACTERÍSTICAS DESEJÁVEIS EM UMA ADL ...mestrado/diss/2007/mendes.pdf · de...

Documents

Transcript of UM CONJUNTO DE CARACTERÍSTICAS DESEJÁVEIS EM UMA ADL ...mestrado/diss/2007/mendes.pdf · de...