LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
MARISA – Uma Ferramenta para Mapeamento
bidirecional de Modelos Orientados a Aspectos: Requisitos e
Arquitetura de Software
Ana Luisa Medeiros1, Thais Batista1, Lyrene Silva2, Leonardo Minora3
1
Departamento de Informática e Matemática Aplicada – Universidade Federal do Rio
Grande do Norte (UFRN)
2
3
Universidade Estadual do Rio Grande do Norte (UERN)
Centro Federal de Educação Tecnológica do Rio Grande do Norte (CEFET-RN)
{analuisafdm,lyrene}@gmail.com, [email protected], [email protected]
Resumo. Esse artigo apresenta MaRiSa (Mapping Requirements to Software
Architecture) – uma ferramenta que realiza o mapeamento bidirecional
automático entre AOV-graph e AspectualACME, e vice-versa. AOV-graph e
AspectualACME são, respectivamente, modelos de requisitos orientados a
aspectos, e especificações arquiteturais orientadas a aspectos. Essa
ferramenta recebe um arquivo XML AOV-graph e gera um arquivo com a
especificação correspondente em AspectualACME. Da mesma forma, recebe
um arquivo contendo especificação AspectualACME e gera um arquivo com o
código respondente em AOV-graph. Esse mapeamento é garantido devido a
regras de mapeamento definidas, encapsuladas e processadas pela
ferramenta.
Abstract. This paper presents MaRiSa (Mapping Requirements to Software
Architecture) – a tool that performs the bidirectional automatic mapping
between AOV-graph and AspectualACME, and vice-versa. AOV-graph and
AspectualACME are, respectively, aspect-oriented requirement models and
aspect-oriented architectural specifications. This tool receives an AOV-graph
XML file and generates a corresponding AspectualACME specification file.
Similarly, it receives an AspectualACME specification and generates a
correspondent AOV-graph specification file. This mapping is supported by the
mapping rules defined and applied by the tool.
1. Introdução
O desenvolvimento de software orientado a aspectos – DSOA (Filman, 2005)surgiu
como uma alternativa para a modularização e composição de características transversais.
Essa nova abordagem vem demonstrando benefícios no que se refere à análise,
modularidade, reusabilidade e evolução do software. Contudo, maiores benefícios são
obtidos quando os modelos construídos em cada etapa do desenvolvimento estão
alinhados de maneira a garantir o mapeamento e rastreabilidade entre eles.
AOV-graph (Silva, 2006) e AspectualACME (Batista, 2006) são estratégias
orientadas a aspectos representativas de requisitos e arquitetura, respectivamente. V-
43
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
graph (Yu, 2004) é um tipo de modelo de metas que provê representações para
requisitos funcionais (goals e tasks) e não funcionais (softgoals) bem como captura
múltiplas formas de relacionamentos entre eles. Modelos de metas explicitam a
complexidade inerente desses relacionamentos e como alguns conceitos entrecortam
outros. ACME (Garlan, 1997) é uma ADL de propósito geral que fornece um conjunto
de elementos básicos e representativos de ADLs e um flexível mecanismo de anotação
usado para incluir descrição adicional que os elementos básicos não conseguem
expressar.
O mapeamento de AOV-graph para AspectualACME, e vice-versa, justifica-se
pois estas linguagens: (i) focam na modelagem de características transversais em
diferentes etapas do desenvolvimento de software, sendo complementares; (ii) utilizam
modelos de propósitos geral e baseiam-se em alguns fundamentos comuns .
O objetivo desse trabalho é apresentar MaRiSa (Mapping Requirements to
Software Architecture) uma ferramenta que operacionaliza o mapeamento de AOVgraph e AspectualACME, e de AspectualACME para AOV-graph. Tais mapeamentos
são baseados em regras de mapeamento definidas entre as linguagens. A ferramenta
oferece duas opções: (i) recebe como entrada um arquivo XML AOV-graph e gera um
arquivo com a especificação correspondente em AspectualACME, ou (ii) recebe como
entrada um arquivo AspectualACME e gera um arquivo XML AOV-graph. As regras de
mapeamento, discutidas detalhadamente em (Silva 2007), (Medeiros 2007) são
resumidamente apresentadas nesse artigo.
Esse artigo está estruturado da seguinte forma. A seção 2 descreve, brevemente,
AOV-Graph e AspectualACME. A seção 3 apresenta, de forma sucinta, as regras de
mapeamento de AOV-graph para AspectualACME e de AspectualACME para AOVgraph, respectivamente. A seção 4 mostra a arquitetura, tecnologias utilizadas e
implementação da ferramenta MaRiSA. A seção 5 contém uma comparação com
trabalhos relacionados. A seção 6 apresenta os comentários finais e trabalhos futuros.
2. AOV-graph e AspectualACME
Visando tratar a separação de características transversais e tratamento dos problemas de
espalhamento e entrelaçamento em requisitos foi definido em (Silva, 2005) uma
linguagem de modelagem que é uma extensão do modelo de metas V-graph (Yu, 2004).
Essa extensão foi definida no contexto de uma estratégia orientada a aspectos para
modelagem de requisitos.
AOV-graph consiste de metas (goals), softmetas (softgoals) e tarefas (tasks).
Metas representam objetivos ou estados concretos a serem atingidos pelo sistema;
softmetas representam objetivos abstratos, freqüentemente associados a requisitos nãofuncionais; e tarefas representam ações (ou requisitos funcionais) a serem realizadas
para atingir metas e softmetas. A linguagem AOV-graph também contém os seguintes
relacionamentos: contribuições (contributions) que representam decomposição e
correlações (correlations) que representam associações positivas ou negativas entre
metas e softmetas.
O relacionamento transversal foi criado com base em elementos tradicionais de
DSOA por AspectJ (pointcut, advice e intertype declaration). Tais elementos possuem
44
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
uma semântica diferenciada e apropriada para modularizar características transversais
no nível de requisitos. Como mostrado na Figura 1, o relacionamento transversal é
descrito por: (i) source - indica o ponto de origem do relacionamento; (ii) pointcut –
indica os pontos de destino do relacionamento, os pontos a serem afetados por uma
característica transversal; (iii) advice - indica elementos pertencentes ao ponto de
origem que estão transversais aos pontos de destino, i.e., a característica transversal em
si. Os tipos before, around e after podem indicar, respectivamente, pré-condição,
decomposição e pós-condição no AOV-graph; e (iv) intertype declaration – define
novos tipos de elementos, também transversais, que surgem com a integração das
características indicadas nos pontos de origem e destino do relacionamento transversal.
Há dois tipos de intertype declaration: element – quando os novos tipos referem-se a
instâncias de elementos de tipos existentes no modelo de requisitos, no caso de AOVgraph referem-se a metas, softmetas e tarefas; e attribute – quando os novos tipos
referem-se a atributos inexistentes no modelo de requisitos, tais como os atributos ator e
custo no modelo AOV-graph.
Figura 1. (a) Relacionamentos entre metas, softmetas e tarefas e (b) exemplo de
relacionamento transversal em AOV-graph
Na Figura 1, exemplificamos o uso do relacionamento transversal. O ponto de
origem do relacionamento transversal é Persistence in (DB) e os pontos afetados são
Configurability e Register.*. Através do advice e intertype declaration, indicamos que
Register of operation e (DB) setting afetam todas as tarefas iniciadas pela string
Register e Configurability, respectivamente. O uso do intertype declaration indica que
DB setting é um elemento criado devido a junção dos conceitos persistência e
configurabilidade.
AspectualACME (Batista, 2006) é uma extensão da linguagem de descrição
arquitetural ACME (Garlan, 1997) incluindo o conector aspectual e um mecanismo de
quantificação que simplifica, sintaticamente, a referência a conjunto de pontos de junção
em uma descrição arquitetural. Além disso, AspectualACME consiste de: componentes
(components), conectores (connectors) e configurações (attachments). Componentes e
conectores possuem interfaces associadas. A interface de um componente é o conjunto
de pontos de interação entre o componente e o mundo externo. Tal interface especifica
os serviços (mensagens, operações e variáveis) que um componente fornece e também
os serviços requisitados de outros componentes e são comumente chamadas de portas.
Conectores especificam regras que governam a interação entre componentes. A
interface do conector, chamadas de papéis (roles) especifica os pontos de interação entre
o conector e os componentes ligados a ele. Configurações definem a conexão de
componentes com conectores.
45
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
O conector aspectual define uma nova interface que distingue os papéis dos
elementos internos do conector na interação transversal. Uma das partes está ligada ao
componente afetado (denominado componente base) por outro componente
(denominado componente aspectual). A interface do conector aspectual contém: (i) uma
base role, (ii) uma crosscutting role, e (iii) uma cláusula glue. A Figura 2 contém a
especificação textual e gráfica do conector aspectual.
C1
C om ponent 1
A s p e c tu a l
C om p on e nt
C 2
C om ponent 2
K e y:
P ro v id e d P o rt
R e q u ire d P o r t
C r o s s c u tt i n g r o l e
B a s e r o le
A s p e c tu a l C o n n e c to r
(a) Notação Textual
(b) Notação Gráfica
Figura 2. Conector aspectual
A Figura 2(b) mostra um exemplo de composição entre um componente
(aspectual) com dois outros componentes. C1 e C2 são exemplos de conectores
aspectuais. É importante ressaltar que não há uma abstração distinta para representar
“aspectos” arquiteturais. Estes são representados por componentes. As cores diferentes
na Figura 2 são usadas apenas para diferenciar qual componente está fazendo o papel de
componente aspectual na interação transversal.
Uma base role deve ser conectada a porta do componente afetado pela interação
transversal – componente base - e uma crosscutting role deve ser conectada a porta do
componente aspectual. O par base-crosscutting roles não impõe a restrição, comum em
ADLs, de conectar portas de entrada (provided ports) e portas de saída (required ports).
A crosscutting role define o local no qual o componente aspectual conecta-se ao
conector. Na Figura 2(b), o conector aspectual C1 conecta a porta de entrada do
componente aspectual com a porta de entrada do componente 1. A cláusula glue
especifica os detalhes da conexão aspectual como, por exemplo, em que momento a
interação aspectual acontece – after, before, around. O conector aspectual provê um
mecanismo de quantificação que simplifica, sintaticamente, a referência a conjuntos de
pontos de junção em uma descrição arquitetural. O mecanismo de quantificação é usado
na configuração através do uso de wildcards (*) que representam parte do nome de
componentes ou portas. A Figura 2(a) ilustra um exemplo em AspectualACME onde o
componente aspectualComponent é conectado, via o conector aspectual aConnector, a
todos os componentes que contenham uma porta com nome começando com prefix.
Dessa forma, AOV-graph e AspectualACME tem seus elementos associados de
forma que é possível propagar mudanças entre eles rapidamente e navegar do modelo de
requisitos para a arquitetura, e vice-versa.
46
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
3. Regras de Mapeamento
3.1 Mapeamento AOV-Graph para AspectualACME
O processo de mapeamento de AOV-graph para AspectualACME definido em (Silva,
2007), ocorre em três etapas:
(i). Mapeamento da hierarquia de metas, softmetas e tarefas de AOV-graph para
componentes, portas e representações (representations) de AspectualACME - Cada
elemento (meta/softmeta/tarefa) de AOV-graph é mapeado para um componente ou
porta de AspectualACME. Essa decisão é baseada na posição em que cada
meta/softmeta/tarefa está na hieraquia: elementos que são raízes da árvore de metas são
mapeados para componentes; subelementos que não são folhas (na árvore AOV-graph)
são mapeados para componentes em representações, e subelementos que são folhas são
mapeados para portas e são inseridos no componente pai correspondente. Para
complementar, quando um componente e uma porta são gerados algumas propriedades
(properties) também são inseridas para registrar a origem de cada um deles. Essas
propriedades registram algumas informações sobre requisitos no modelo arquitetural e
possibilitam o mapeamento inverso – de AspectualACME para AOV-graph.
(ii). Mapeamento de pointcuts e intertype-declarations (element) de AOV-graph
para portas e ligações (bindings) de AspectualACME - Alguns conceitos nos
relacionamentos tranversais também podem ser mapeados para portas: (i) cada elemento
do corpo de uma intertype declaration; (ii) cada elemento do corpo de um advice; e (iii)
cada elemento de um pointcut. Semanticamente, relacionamentos transversais agrupam
diversos relacionamentos entre metas, tarefas e softmetas, ou seja, eles representam as
interações que, na arquitetura, são representadas por conectores ligando portas.
(iii). Mapeamento de relacionamentos transversais para conectores e configurações
(attachments) - Conectores e configurações também são gerados a partir do
relacionamento transversal: (i) intertype declarations e advice são mapeados para
conectores aspectuais, sendo que o tipo da cláusula glue é determinado pelo tipo do
advice (podendo ser around, after ou before), ou pelo tipo de intertype declaration
(sendo around se a intertype for do tipo element e caso contrário assumirá o valor
definido pelo atributo criado); (ii) cada relação intertype declaration pointcut e
advice pointcut é mapeada para uma associação de configuração de elementos, do
intertype declaration para uma crosscutting role, e uma outra associação, de base role
para elementos dos pointcuts.
A Tabela 1 resume como os elementos de AOV-graph são transformados nos
elementos de AspectualACME. Com essas regras de mapeamento é possível gerar
especificações em AspectualACME a partir de descrições em AOV-graph (veja (Silva,
2007) para informações mais detalhadas.
Tabela 1. Mapeamento de AOV-graph para AspectualACME
AOV-graph
Goal, sofgoal, task
Contribution
Correlation
Topic
Advice
Intertype declaration
AspectualACME
Component ou port + property elementType
Representation + property contributions
Property correlation
Property topic
Aspectual connector + properties comesFrom e
crossRelSource
Aspectual connector + properties comesFrom e
47
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
Advice type
Intertype declaration do tipo element
Intertype declaration do tipo attribute
Source (crosscutting relationship)
Pointcut
Property (elemento criado para registrar
informações da arquitetura)
crossRelSource
glueType
glueType = around
glueType = valor do atributo
Attachment
Attachment, port self + binding
Property
3.2. Mapeamento AspectualACME para AOV-graph
O processo que mapeia especificações em AspectualACME para modelos em AOVgraph foi definido em (Medeiros, 2007), e consiste das seguintes etapas:
(i). Mapeamento de conectores aspectuais e attachments para relacionamentos
transversais - cada conector aspectual é mapeado para uma relacionamento transversal
com uma intertype declaration ou advice em AOV-graph. O tipo da cláusula glue é
verificado e mapeado para especificar o tipo deste advice e intertype declaration,
enquanto seus pointcuts e corpo são determinados pelos attachments. Para cada
attachment que possui o mesmo conector ligando portas e papéis: (i) portas relacionadas
com o crosscuttingRole, são mapeadas para o corpo do intertype declaration ou advice
(dependendo do tipo da cláusula glue); (ii) o componente que possui esta porta é
mapeado para a origem do relacionamento transversal no AOV-graph; (iii) enquanto
portas ligadas ao BaseRole são mapeadas para pointcuts. No final do mapeamento é
necessário reunir todos os relacionamentos transversais que possuem a mesma origem,
bem como todos os pontos que são atingidos pelo mesmo intertype declaration ou
advice.
(ii). Mapeamento de componentes, portas, representações (representations) e
propriedades para metas, tarefas ou softmetas de AOV-graph – (i) A partir das
propriedades é possível identificar precisamente qual o tipo do elemento derivado de
componentes ou portas, através da propriedade elementType e através da propriedade
topics identificamos quais strings do nome da meta, softmeta ou tarefa deve ser posta
entre colchetes. (ii) Quando informações sobre o AOV-graph não estão disponíveis – a
hierarquia de componentes e portas gera uma hierarquia de softmetas e tarefas, sendo as
tarefas derivadas de portas e as softmetas derivadas de componentes. Entretanto, é
necessário analisar se cada um destes componentes e portas faz ou não parte do corpo de
alguma intertype declaration, pois se eles fizerem, então eles não são mapeados para
softmeats e tarefas, eles existirão apenas no corpo da intertype declaration.
(iii). Mapeamento da propriedade correlation de AspectualACME para
correlations de AOV-graph – Em AspectualACME as correlações da modelagem em
AOV-graph são especificadas em propriedades.
(iv). Mapeamento de conectores de AspectualACME para contribuições de AOVgraph – conectores não-aspectuais de AspectualACME representam relacionamentos
entre portas que requerem serviços e portas que provêem serviços. Em AOV-graph tais
relacionamentos são representados por contribuições, assim um serviço provido
contribui para duas ou mais softmetas, metas e tarefas. Tendo em vista a maneira como
AOV-graph foi implementado a tarefa derivada da porta provedora é distinta da tarefa
derivada da porta requeredora, porque a primeira é mapeada para uma tarefa de fato,
enquanto a segunda é derivada para uma referência à primeira.
48
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
A Tabela 2 resume o mapeamento de AspectualACME para AOV-graph. Com
estas regras é possível gerar modelos em AOV-graph a partir de especificações em
AspectualACME.
Tabela 2. Mapeamento AspectualACME para AOV-graph
AspectualACME
Component, port
Representation
Aspectual connector
glueType
Attachment
Connector
Property topic
Property elementType
Property correlations
Property comesFrom
Property crossRelSource
Property
AOV-graph
Goal ou sofgoal ou task + property
Contributions
Advice, intertype declaration + property
AdviceType, intertypeDeclarationType
Pointcut, source, contribution (se não está associado a um conector aspectual)
Contribution + Property
Topic
Determina se o elemento é uma meta, softmeta ou tarefa
Correlations
Determina se os conceitos transversais devem ser descritos em advice ou
intertype declaration
Auxilia na identificação da origem do relacionamento transversal
Property
4. MaRiSA – Arquitetura e Implementação
4.1 Funcionamento
MaRiSA é uma ferramenta de mapeamento e transformação entre modelos. Este
processo é resumido na Figura 3 por duas entradas, o processamento de transformação e
duas saídas. Uma das possibilidades de entrada é um arquivo XML AOV-graph. Nesse
caso a saída é um arquivo em AspectualACME. A outra possibilidade de entrada é um
arquivo contendo especificação AspectualACME, e a saída obtida é um arquivo XML
AOV-graph.
(a)
(b)
Figura 3. (a) Representação das entradas e saídas da ferramenta; (b) Processo de
Funcionamento de MaRiSA.
O início do funcionamento de MaRiSA acontece com o usuário selecionando a
opção de mapeamento AOV-graph para AspectualACME, ou AspectualACME para
AOV-graph. O usuário, após escolher a primeira opção, deve selecionar um arquivo
XML AOV-graph. Em seguida a ferramenta carrega o arquivo escolhido. Essa carga é o
início do mapeamento. Após esse passo as seguintes tarefas são realizadas: (i) leitura de
um arquivo XML com especificações AOV-Graph e transformação em uma árvore
DOM (Document Object Model); (ii) transformação da árvore DOM em um modelo de
objetos AOV-graph; (iii) conversão do modelo de objetos AOV-Graph, utilizando as
regras de mapeamento, para o ,modelo de objetos AspectualACME; (iv) Por fim, a
transformação do Modelo de Objetos AspectualACME para arquivo .aacme. No caso do
49
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
mapeamento de AspectualACME para AOV-graph os procedimentos são similares. A
Figura 1(b) ilustra essas tarefas e funcionamento de MaRiSA.
4.2. Arquitetura
MaRiSa está organizada em 2 (dois) principais componentes: (i) interface com o
usuário; (ii) núcleo de processamento, como mostrado na Figura 4 (a).
(a)
(b)
Figura 4. (a) Diagrama de Componentes da Macro-Arquitetura de MaRiSA; (b) Diagrama
de Componentes do núcleo de MaRisa
A Figura 4(b) mostra os componentes do núcleo de MaRiSA, e as dependências
entre suas interfaces. O componente Leitor, caracterizado com o estereótipo equivalente
as linguagens, no caso AOV-graph. Esse leitor contém as classes Java responsáveis pela
leitura do XML e estruturação da árvore DOM – formando uma hierarquia dos
elementos desse XML em memória – e ainda realiza a passagem dos elementos
estruturados em memória para um Modelo de Objetos de AOV-graph.
O componente Transformador contém as classes responsáveis pela
transformação de objetos das linguagens envolvidas, AOV-graph para AspectualACME
e vice-versa. Ambas transformações são baseadas nas regras de mapeamento.
O componente Escritor, também especificado com os estereótipos equivalentes
as linguagens, contém as classes responsáveis pela escrita do arquivo que será gerado,
contendo a especificação da linguagem que está sendo mapeada.
4.3. Implementação
MaRiSa foi desenvolvida em Java (Sun Microsystems, 2007), JSE 6 (Java
Standard Edition), utilizando os recursos da sua API JSE 6 para manipulação com o
XML, em específico os recursos do DOM (uma especificação da World Wide Web
Consortium – W3C), a biblioteca Commons Collections (Commons Collections, 2007)
da Apache e a IDE (Integrated Development Environment) Eclipse em sua versão 3.2.
A Figura 5(a) ilustra a tela inicial de MaRiSA relativa as opções disponíveis para
mapeamento. Já na Figura5(b) está ilustrado a tela referente ao Mapeamento AOV-
50
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
graph para AspectualACME. Ela é composta por quatro abas. A aba Principal
representa a função de escolha e carregamento do arquivo XML AOV-graph. A aba
XML representa a visualização do arquivo XML AOV-graph carregado. A aba Árvore
DOM representa a estrutura do arquivo XML AOV-graph carregado e a aba
AspectualACME mostra a especificação do arquivo AspectualACME gerado.
(a)
(b)
(c)
Figura 5. (a) Tela inicial do Mapeamento AOV-graph para AspectualACME; (b) Tela inicial
do Mapeamento AOV-graph para AspectualACME.
A Figura 5(c) representa a tela inicial de MaRisa relativa ao Mapeamento
AspectualACME. Nessa tela existem três abas. A aba Principal ilustra a opção de
escolha e carregamento do Arquivo AspectualACME. A aba AspectualACME representa
a visualização do arquivo AspectualACME carregado e a aba XML AOV-graph mostra o
código AOV-graph gerado.
A Figura 6(a) mostra um trecho de código do XML AOV-graph escolhido pelo
usuário e carregado pela ferramenta. Nesse caso, a ferramenta encapsula as regras de
mapeamento, mencionadas resumidamente na seção 3, processa essas regras e gera um
arquivo contendo especificação AspectualACME. Na Figura 6(b) está representado o
trecho de código correspondente em AspectualACME ao trecho inicial do AOV-graph.
A Figura 6(c) mostra um trecho de código do arquivo AspectualACME carregado, e na
Figura 6(d) está sua correspondência e mapeamento em XML AOV-graph (ver seção 4).
(a)
(b)
(c)
(d)
Figura 6. (a) Tela com código AOV-graph ; (b) Tela com código gerado em AspectualACME;
(c) Tela com código AspectualACME; (c) Tela com código gerado em AOV-graph
51
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
5. Trabalhos Relacionados
O mapeamento de requisitos para arquitetura e a rastreabilidade de artefatos
desenvolvidos nestas etapas são tópicos de grande importância. (Rashid, 2003) e (Sousa,
2003) definem o mapeamento de candidatos a aspectos para funções, decisões
arquiteturais ou aspectos na arquitetura. Este mapeamento é baseado somente na
experiência do desenvolvedor. Em (Sousa, 2004) casos de uso aspectuais são mapeados
para modelos de interação da UML. Em (Baniassad, 2004) é descrito como mapear
Theme/Doc para Theme/UML. Em (Silva, 2006b) é descrito como gerar diagramas de
classe a partir de modelos V-graph, como uma abordagem automática de gerar visões de
modelos de requisitos. No entanto, esses trabalhos não oferecem ferramentas que
implementem tais funcionalidades.
Alguns trabalhos relacionados à construção de ferramentas foram observados
(Maia, 2005), (Cóbe, 2006). A maioria dessas abordagens mapeia de requisitos para um
modelo de projeto detalhado como, por exemplo, diagramas de classes e interações
UML (Unified Modelling Language). A desvantagem dessa estratégia é que o arquiteto
tem que lidar com muitos detalhes, às vezes desnecessários para alguns tipos de análise
arquitetural. Por sua vez, a ferramenta MaRiSA automatiza o mapeamento bidirecional
entre fases diferentes do ciclo de desenvolvimento de software, requisitos e arquitetura,
e vice-versa.
Assim como, trabalhos relacionados às especificações de transformaçções entre
modelos que o MDD (Model Driven Development) dá suporte foram observados
(Simmonds, 2005), (Sánchez, 2007). No primeiro trabalho é apresentado o Aspect
Oriented Model driven Framework (AOMDF) que auxilia na separação de
características pervasivas, além disso dá suporte as suas transformações em diferentes
níveis de abstração usando a abordagem do MDD, e o segundo trabalho, mostra o MDD
e suas transformações, inseridas e aplicadas na área de Engenharia de Requisitos
Orientada a Aspectos (Early Aspects). Todavia, nossa abordagem inicial apesar de
realizar transformações entre modelos, ainda não enfoca essas transformações sobre a
ótica do MDD, e sim sobre mapeamento entre modelos, com especificação de regras de
mapeamento de propósito geral, com intuito de mostrar a importância e possibilidade de
integração entre diferentes fases do ciclo de desenvolvimento de software, apresentando
uma ferramenta que dá suporte a automatização dessa integração e mapeamento.
6. Conclusões
O mapeamento entre AOV-graph e AspectualACME, e vice-versa, possibilita:
(i) a geração automática da arquitetura de software a partir dos requisitos e vice-versa;
(ii) a correspondência entre as informações modeladas em ambos os modelos; (iii) a
possibilidade de propagar mudanças realizadas nos requisitos para arquitetura e a
possibilidade de realizar alguns tipos de verificação na especificação arquitetural por
meio das ferramentas já existentes; (iv) o mapeamento e rastreabilidade de
características transversais.
Com a construção de MaRiSA houve a operacionalização e validação das regras
de mapeamento.Em termos de contribuições, não há ferramenta similar para
52
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
mapeamento automático entre modelos orientados a aspectos das fases iniciais de
desenvolvimento. Por usar AOV-graph e AspectualACME, que são linguagens-modelos
representativos da sua categoria, a ferramenta pode ser facilmente adaptada para
linguagens-modelos similares. As funcionalidades de MaRiSA foram validadas em um
estudo de caso tradicionalmente usado em sistemas orientados a aspectos, o sistema
HealthWatcher (HW) (Soares, 2002), um sistema de informações disponibilizado via
WEB que oferece ao usuário serviços relacionados ao sistema público de saúde, como o
suporte a registro de reclamações, e guia de saúde para o usuário.
A ferramenta MaRiSa, e seu manual de utilização, estão disponíveis em
http://www.ppgsc.ufrn.br/~analuisa/marisa.
Trabalhos futuros incluem a construção de ferramentas que operacionalizem
regras de mapeamento definidas para outras fases do ciclo de desenvolvimento de
software e utilizem os modelos de requisitos e arquitetura gerados pela ferramenta
MaRiSa, assim como, o relacionamento das transformações entre modelos realizadas
entre as fases do ciclo de desenvolvimento de software, sobre a ótica do MDD..
7. Referências
Baniassad, E., Clarke, S. (2004) “Theme: An approach for aspect-oriented analysis and design”. Proc. of
The 7th International Conference on Software Engineering (ICSE'04), Scotland, 2004. p. 158-167.
Batista, T. et al. (2006). Reflections on Architectural Connection: Seven Issues on Aspects and ADLs.
Workshop on Early Aspects – Aspect-Oriented Requirements, ICSE'06, May 2006, Shanghai, China.
Cóbe, R. M (2006). Janaína: Proposta de Ferramenta MDA para Obtenção de PSM’S Baseado em
Diagrama de Seqüência. Trabalho de Conclusão de Curso – CEFET-RN, Natal, RN.
Commons Collections (2007), http://jakarta.apache.org/commons/collections/.
Filman, R.et al. (2005). Aspect-Oriented Software Development. Addison-Wesley.
Garlan, D. et al (1997). “ACME: An Architecture Description Interchange Language”. Proc.
CASCON’97, Nov.
Maia, N. E. N. et. al (2005). Odyssey-MDA: Uma Ferramenta para transformações de modelos UML.
XIX Simpósio Brasileiro de Engenharia de Software, Uberlândia, MG.
Medeiros, A. L, et. al. (2007). Requisitos e Arquitetura de Software Orientada a Aspectos: Uma
Integração Sinérgica. Anais do XXI Simpósio Brasileiro de Engenharia de Software, João Pessoa,
Paraíba, Brazil. (accepted).
Rashid, A., et al. (2003) “Modularization and composition of aspectual requirements”, Proc. of the 2nd
International Conference on Aspect-Oriented Software Development, ACM, 2003. p. 11-20.
Sanchéz, P., et al. (2007). “Model-Driven Development for Early Aspects”. Journal of Systems and
Software. (accepted).
Silva, L. (2006). Uma Estratégia Orientada a Aspectos em Modelagem de Requisitos. Tese (Doutorado) –
PUC-Rio, Rio de Janeiro.
Silva, L., Leite, J. (2006b) “Generating Requirements Views: A Transformation-Driven Approach”. In:
Proc. of 3rd Workshop on Software Evolution through Transformations, Natal-RN, Setembro, 2006.
Silva, L. et. al. (2007). On the Symbiosis of Aspect-Oriented Requirements and Architectural
Descriptions. Proc. of the EarlyAspects co-located with AOSD 2007, Vancouver, Canada, March
2007.
Simmonds, D., et al. (2005). "An Aspect Oriented Model Driven Framework," EDOC, vol. 151(4), p.
119-130.
Soares, S. et al. (2002).: Implementing Distribution and Persistence Aspects with AspectJ. Proc. of the
OOPSLA’02, (2002). pp. 174-190.
Sousa, G.; SILVA, G.; Castro, J. (2003) “Adapting the NFR framework to aspect-oriented requirements
engineering” Proc. of the 17th Brazilian Symposium on Software Engineering (SBES), Brasil, 2003.
53
LA-WASP.07
I Latin-American Workshop on Aspect-Oriented Software Development
Sousa, G. et al. (2004) “Separation of crosscutting concerns from requirements to design: Adapting the
use case driven approach”. Proc. of the Early Aspects Workshop at AOSD, England, 2004.
Sun Microsystems (2007) , http://java.sun.com.
Yu, Y., Leite, J., Mylopolous, J. (2004). From goals to aspects: discovering aspects from requirements
goal models, Proc. of IEEE Int. Symp. on Requirements Engineering (RE'04), Japan, pp. 38-47.
54