Principais métodos De Comunicação Usados Pelos Analistas Para Obtenção Das Informações
Exames: Principais métodos De Comunicação Usados Pelos Analistas Para Obtenção Das Informações. Pesquise 862.000+ trabalhos acadêmicosPor: • 4/11/2013 • 7.401 Palavras (30 Páginas) • 542 Visualizações
LUCIANA DE PAIVA SILVA
A ENGENHARIA DE REQUISITOS ORIENTADA A
ASPECTOS: A ABORDAGEM DAORE
MARINGÁ
2007
ii
Dados Internacionais de Catalogação-na-Publicação (CIP)
Biblioteca Central do Campus de Cascavel - Unioeste
S581e
Silva, Luciana de Paiva
A engenharia de requisitos orientada a aspectos: a abordagem
DAORE. / Luciana de Paiva Silva. — Maringá, PR: UEM, 2007.
233 f. ; 30 cm
Orientadora: Profa Dra. Tania F. Calvi Tait
Dissertação (Mestrado) – Universidade Estadual de Maringá. Programa
de Pós- Graduação em Ciência da Computação.
Bibliografia.
1. Sistemas de informação. 2. Orientação a aspectos. 3. Engenharia
de requisitos. I. Tait, Tania F. Calvi. II. Universidade Estadual de
Maringá. III. Título.
CDD 21ed. 005.1
CIP – NBR 12899
Ficha catalográfica elaborada por Jeanine Barros CRB-9/1362
iii
LUCIANA DE PAIVA SILVA
A ENGENHARIA DE REQUISITOS ORIENTADA A
ASPECTOS: A ABORDAGEM DAORE
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. Tania Fatima Calvi
Tait
MARINGÁ
2007
iv
Ao que foi e que sempre será meu apoio, meu amigo, meu cúmplice e
meu marido: Sérgio.
v
AGRADECIMENTOS
“Nada é mais difícil, e por isso mais precioso, do que ser capaz de decidir.”
Napoleão
Apoiar do Latim Appodiare significa ajudar, confirmar, dar apoio, fundar-se..
Todas as conquistas são repletas de dificuldades e, para vencê-las, é necessário apoio em
todas as formas.
O apoio recebido ajuda no desenvolvimento de um projeto, seja ele pessoal ou comunitário.
As pessoas aqui listadas ofereceram um tipo de apoio, que é imprescindível a qualquer
projeto, a força que move montanhas... o apoio que vence barreiras de distâncias, de oceanos
e até mesmo espiritual.
Gostaria de agradecer a todos que de alguma forma me ajudaram a realizar este desafio. Sem
o apoio recebido jamais teria conseguido.
Muito obrigado:
· A Nossa Senhora, pela força espiritual que inspira,
protege e ilumina constantemente a minha vida;
· Aos meus amados pais, Antonio e Francisca, por me
tornarem quem eu sou, pelo amor, pela dedicação, por todos
os sacrifícios para que eu chegasse até aqui, sacrificando
sua antiga morada e seus amigos, no Rio de Janeiro, para
uma cidade estranha, apenas para me ajudar e por terem
sido fortes, mesmo quando a minha distância os fazia
sofrer;
· Ao meu filho Thyago, por ser meu amigo e me incentivar no
caminho do saber;
· A minha filha Julia, que com seu sorriso e seu jeitinho
meigo de ser, me fizeram vivenciar momentos de alegrias
durante minha jornada;
· Ao meu amigo, meu cúmplice e meu companheiro de sempre,
Sergio, que com seu amor incondicional me impulsionaram a
buscar mais uma realização, mais uma conquista, e por
despertar em mim uma admiração crescente e constante;
· A minha avó Nina, seu apoio espiritual foi imprescindível
para a realização dos meus sonhos;
· A minha amiga Aline, por ser minha irmã e minha
companheira dos momentos felizes e infelizes em nossa
estada em Maringá;
vi
· A minha orientadora Tânia, pelo incentivo, confiança e
pela parceria nas idéias e discursões, alem de agüentar
minhas reclamações;
· A professora Elisa, por ter me propiciado o primeiro
contato com a orientação a aspectos e pelas importantes
contribuições para o enriquecimento desta dissertação;
· Aos pesquisadores com os quais me correspondi,
especialmente a Awais Rashid, Eric SK Yu, Marcio
Cysneiros, Silvio Meira, Jaelson Castro, Julio Leite,
Karin Breitman e John Mylopoulos;
· Ao prof. André Luiz de Medeiros Santos, meu orientador do
doutorado, do Cin - UFPE, pela paciência e bom humor
durante esta fase do mestrado;
· Ao Departamento de Informática da UEM, pelo suporte
técnico e acadêmico durante minha estada; e
· A todos aqueles que torceram e acreditaram em mim e neste
trabalho.
Agradecimentos
vii
“Há duas formas para viver sua vida:
uma é acreditar que não existe milagre;
a outra é acreditar que todas as coisas são um milagre“.
Albert Einstein
“Porque para Deus nada é impossível”.
Lucas 1,37
viii
Resumo
SILVA, Luciana de Paiva. A Engenharia de Requisitos Orientada a Aspectos: A Abordagem DAORE.
233f. Dissertação (Mestrado em Ciência da Computação) – Programa de Pós- Graduação em Ciência
da Computação, UEM,Maringá.
Ao desenvolvermos um projeto de sistemas de informação, geralmente não
modelamos os chamados crosscuting concerns, tendemos a modelar algumas características
isoladas e não realizamos a separação e composição destas características.
A orientação a aspectos permite a modelagem destas características nos projetos,
possibilitando a identificação de características comuns em várias partes do sistema.
Inicialmente voltada para a implementação e agora com várias pesquisas relacionadas às fases
iniciais do desenvolvimento do processo de software, a orientação a aspectos permite que se
obtenha muitas vezes os requisitos aspectuais, ou seja, os aspectos identificados nas fases
iniciais do processo de desenvolvimento, que são fatores importantes e imprescindíveis desde
o início do projeto de sistemas.
Assim, este projeto de dissertação insere-se num tema que tem recebido crescente
atenção no processo de desenvolvimento de sistemas: a aplicação da orientação a aspectos nas
fases iniciais do processo de desenvolvimento, ou como é conhecida na linguagem aspectos:
early aspects.
Este trabalho realiza um estudo e análise de algumas das abordagens existentes na fase
de engenharia de requisitos por meio da introdução de uma nova abordagem, denominada
DAORE – Distributed Aspect Oriented Approach for Requirements Engineering, como
solução para aplicação do LEL – Léxico Extendido da Linguagem e da metodologia MDSODI
- Methodology for Development of Distributed Software, permitindo a definição destes
conceitos nos projetos e requisitos elucidados a serem desenvolvidos no projeto DiSEN -
Distributed Software Engineering Environment e em outros projetos a serem desenvolvidos
utilizando esta metodologia.
Para avaliar nossa abordagem aplicamo-la em um sistema de controle de eventos.
ix
Abstract
SILVA, Luciana de Paiva. A Engenharia de Requisitos Orientada a Aspectos: A Abordagem DAORE.
233f. Dissertação (Mestrado em Ciência da Computação) – Programa de Pós- Graduação em Ciência
da Computação, UEM, Maringá.
When we develop a information systems project, generally we do not shape the calls
crosscutting concerns, we tend shape it some isolated characteristics and we do not carry
through the separation and composition of these characteristics.
The aspects oriented approach allows the modeling of these characteristics in the
projects, allowing to identify common characteristics in some parts of the system are
identified. Initially come back toward the implementation and now with some related research
the initial phases of the project, the orientation the aspects allows that if it gets many times the
aspects, that they are important and essential factors since the beginning of the project of
systems.
Thus, this project is inserted in a subject that has received increasing attention in the
process from development of systems: the application of the aspects oriented in the initial
phases of the development process, or as it is known in the language aspects: early aspects.
The considered work search to carry through a study and analysis of the existing
approaches in the phase of the requirements engineering by means of the introduction of a
new approach, called DAORE - Distributed Aspect Oriented Approach for Requirements
Engineering, as solution for application of the LEL – Language Extended Lexicon and the
methodology MDSODI - Methodology for Development of Distributed Software, allowing to
the definition of these concepts in the projects and elucidated requirements to be developed in
the project DiSEN - Distributed Software Engineering Environment and in other projects to
be developed using this methodology.
To evaluate the use of our approach, we apply it in the context of an events manager
system.
x
Lista de Abreviaturas
AOD Aspect Oriented Development
AORE Aspects Oriented Requirement Engineering
DiSEN Distributed Software Engineering Environment
DAORE Distributed Aspect Oriented Approach for Requirements Engineering
I* Distributed Intentionality
LAL Léxico Ampliado da Linguagem
LEL Language Extended Lexicon ou Léxico Extendido da Linguagem
MDSODI Methodology for Development of Distributed Software
NFR Non-functional Requirements
POA Programação orientada a aspectos
POO Programação orientada a objetos
UML Unified Modeling Language
RE Engenharia de Requisitos
RF Requisitos Funcionais
RNF Requisitos não-funcionais
RO Requisitos organizacionais
XML Extensible Markup Language
xi
Lista de Figuras
CAPÍTULO 1
FIGURA 1.1 ESTRUTURA DA PESQUISA A SER SEGUIDA.......................................... 9
CAPÍTULO 2
FIGURA 2.1 MODELO DE SEPARAÇÃO AVANÇADA DE CONCERNS......................... 18
FIGURA 2.2 PROCESSO DE COMBINAÇÃO DE ASPECTOS E CLASSES PARA GERAR O
SISTEMA.............................................................................................
23
FIGURA 2.3 ESTRUTURA DE UMA ENTIDADE ASPECT EM ASPECTJ....................... 25
FIGURA 2.4 EXEMPLO DE CÓDIGO EM ASPECTJ.................................................... 25
FIGURA 2.5 MODELO DE PROCESSO AORE........................................................... 27
FIGURA 2.6 EXEMPLO DE CASO DE USO COM ASPECTO CANDIDATO.................... 34
FIGURA 2.7 USE CASE DE OVERLAP DO ASPECTO SEGURANÇA.............................. 35
FIGURA 2.8 EXEMPLO DE REGRA DE COMPOSIÇÃO............................................... 37
FIGURA 2.9 O GRÁFICO V-GRAPH E SUA COMPOSIÇÃO.......................................... 38
FIGURA 2.10 O GRÁFICO V-GRAPH E SUA REPRESENTAÇÃO................................... 38
FIGURA 2.11 A VISÃO GERAL DA ABORDAGEM GOAL............................................. 39
FIGURA 2.12 ATUALIZAÇÃO DOS MODELOS NO DESENVOLVIMENTO....................... 42
FIGURA 2.13 EFEITOS DE DISPERSÃO E ENROLAÇÃO QUANDO REALIZAMOS PEERS.. 43
FIGURA 2.14 EXEMPLO DE EXTENSION................................................................... 44
FIGURA 2.15 ESTRUTURA DOS ELEMENTOS E CASOS DE USO SLICES........................ 45
FIGURA 2.16 COMPOSIÇÃO DA REALIZAÇÃO DE CASOS DE USO PEER COM CASOS
DE USO SLICES....................................................................................
45
FIGURA 2.17 REPRESENTAÇÃO DE CASOS DE USO.................................................. 46
FIGURA 2.18 ESTRUTURANDO CASOS DE USO DE INFRA-ESTRUTURA..................... 46
FIGURA 2.19 A ESPECIFICAÇÃO DO CASO DE USO <PERFORM TRANSACTION>....... 47
FIGURA 2.20 O PROCESSO THEME........................................................................... 49
FIGURA 2.21 EXEMPLO ABSTRATO DO GRÁFICO DE VISÃO DE AÇÕES.................... 52
FIGURA 2.22 EXEMPLO ABSTRATO DO GRÁFICO DE AÇÕES LIGADAS..................... 53
FIGURA 2.23 EXEMPLO ABSTRATO DO GRÁFICO DE THEME VIEW.......................... 54
CAPÍTULO 3
FIGURA 3.1 CICLO DE VIDA DO MDSODI............................................................. 66
FIGURA 3.2 O AMBIENTE DISEN E SUA ESTRUTURA EM CAMADAS....................... 70
FIGURA 3.3 REPRESENTAÇÃO DO GERENCIADOR DE WORSPACE .......................... 72
FIGURA 3.4 MODELO DE PROCESSO UTILIZADO NA REQUISITE......................... 73
FIGURA 3.5 DIAGRAMA USE CASE DA FERRAMENTA REQUISITE....................... 74
FIGURA 3.6 ARQUITETURA DETALHADA DA FERRAMENTA REQUISITE.............. 77
FIGURA 3.7 ESQUEMA DE INSTÂNCIAS DA FERRAMENTA REQUISITE................ 79
FIGURA 3.8 REPRESENTAÇÃO DA ARQUITETURA DO DISEN................................. 80
CAPÍTULO 4
FIGURA 4.1 MODELO DE PROCESSO DA ABORDAGEM DAORE..................................... 89
FIGURA 4.2 PROCESSO GERAL DE COSNTRUÇÃO DE REQUISITOS.................................. 90
FIGURA 4.3 UMA TAXONOMIA PARA RNFS. ................................................................. 93
FIGURA 4.4 MODELO DE PROCESSO DE CONSTRUÇÃO DO LEL N A ABORDAGEM
DAORE......................................................................................................
101
xii
CAPÍTULO 5
FIGURA 5.1 MENU PRINCIPAL DA FERRAMENTA CALEL 118
FIGURA 5.2 TELA DE INCLUSÃO DO LEL 119
FIGURA 5.3 O PROCESSO DE MAPEAMENTO LEL – ONTOLOGIAS 147
FIGURA 5.4 MAPEAMENTO DOS SÍMBOLOS DO TIPO ESTADO 153
FIGURA 5.5 ESTRUTURA HIERÁRQUICA DA ONTOLOGIA EVENTOS 154
FIGURA 5.6 TRECHO DO ARQUIVO DO LEL DOS SÍMBOLOS EM XML 155
FIGURA 5.7 TRECHO DO ARQUIVO DO LEL DOS CENÁRIOS EM XML 155
FIGURA 5.8 TRECHO DO ARQUIVO DE ASPECTOS XML 156
FIGURA 5.9 TRECHO DO ARQUIVO DE ONTOLOGIAS XML 156
CAPÍTULO 6
FIGURA 6.1 MENU PRINCIPAL DA FERRAMENTA REQUISITE 160
FIGURA 6.2 NETBEANS E A FERRAMENTA REQUISITE 161
FIGURA 6.3 BORLAND TOGETHER ARCHITECT E A REQUISITE 162
FIGURA 6.4 DIAGRAMA DE CASOS DE USO DA REQUISITE PROPOSTO 163
FIGURA 6.5 DIAGRAMA DE CLASSES PROPOSTO DA NOVA VERSÃO DA REQUISITE 165
FIGURA 6.6 TELA DE ACESSO AO REQUISITE 166
FIGURA 6.7 NOVO MENU PRINCIPAL DA FERRAMENTA REQUISITE 167
FIGURA 6.8 SUB-MENU DE PROJECT 167
FIGURA 6.9 NEW PROJECT 168
FIGURA 6.10 SUB-MENU DA OPÇÃO LEL 169
FIGURA 6.11 NEW/UPDATE LEL 170
FIGURA 6.12 SUB-MENU DA OPÇÃO USE CASE 171
Lista de Figuras
xiii
Lista de Tabelas
CAPÍTULO 2
TABELA 2.1 RELACIONANDO PROPRIEDADES COM REQUISITOS DOS
STAKEHOLDERS.....................................................................................
28
TABELA 2.2 MAPEAMENTO ENTRE ASPECTOS CANDIDATOS...................................... 29
TABELA 2.3 EXEMPLO DE UMA ESPECIFICAÇÃO DA DIMENSÃO DO ASPECTO........... 30
TABELA 2.4 TEMPLATE PARA ATRIBUTOS DE QUALIDADE......................................... 31
TABELA 2.5 TEMPLATE PARA REQUISITOS NÃO FUNCIONAIS..................................... 32
TABELA 2.6 IDENTIFICAÇÃO DE MATCH POINTS....................................................... 36
TABELA 2.7 CONTRIBUIÇÃO E CORRELAÇÃO............................................................ 39
TABELA 2.8 CARACTERÍSTICAS DE QUALIDADE ISO/IEC 9126................................ 41
TABELA 2.9 ADAPTAÇÃO DOS CONCEITOS DAS CARACTERÍSTICAS DE QUALIDADE
ISO/IEC 9126.......................................................................................
55
TABELA 2.10 SUB-CARACTERÍSTICAS DE COMPARAÇÃO............................................ 56
TABELA 2.11 CRITÉRIOS DE PADRÕES UTILIZADOS NA COMPARAÇÃO....................... 57
TABELA 2.12 COMPARAÇÃO DAS ABORDAGENS AORE.............................................. 59
TABELA 2.13 RESUMO DA COMPARAÇÃO – ABORDAGEM VIEWPOINT........................ 60
TABELA 2.14 RESUMO DA COMPARAÇÃO – ABORDAGEM GOALS............................... 61
TABELA 2.15 RESUMO DA COMPARAÇÃO – ABORDAGEM USE CASE.......................... 62
TABELA 2.16 RESUMO DA COMPARAÇÃO – ABORDAGEM THEME/DOC................... 63
TABELA 2.17 RESUMO GERAL DA COMPARAÇÃO....................................................... 63
CAPÍTULO 3
TABELA 3.1 ESPECIFICAÇÃO DOS ELEMENTOS UTILIZADOS NA MDSODI 68
CAPÍTULO 4
TABELA 4.1 CONCEITOS E ARTEFATOS USADOS NA DAORE.................................... 84
TABELA 4.2 RELAÇÃO ENTRE DIRETRIZES DA DAORE E AS CARACTERÍSTICAS DE
QUALIDADE..........................................................................................
86
TABELA 4.3 RNFS E ESTRATÉGIAS DE SATISFAÇÃO.................................................. 94
TABELA 4.4 MAPEAMENTO DOS REQUISITOS NÃO FUNCIONAIS E FUNCIONAIS ....... 98
TABELA 4.5 MAPEAMENTO DOS REQUISITOS ORGANIZACIONAIS EM REQUISITOS
FUNCIONAIS E NÃO FUNCIONAIS............................................................
100
TABELA 4.6 CONTRIBUIÇÕES DOS ASPECTOS............................................................ 104
TABELA 4.7 COMPOSIÇÃO DOS ASPECTOS IDENTIFICADOS....................................... 105
TABELA 4.8 EXEMPLO DE PREENCHIMENTO DA TABELA DE CONFLITOS.................. 106
TABELA 4.9 MAPEAMENTO DOS ELEMENTOS DO LEL PARA OS ELEMENTOS DA
ONTOLOGIA...........................................................................................
107
TABELA 4.10 EXEMPLO DE HIERARQUIA DE CLASSES.................................................. 108
TABELA 4.11 DAORE E OS OBJETIVOS PROPOSTOS................................................... 110
CAPÍTULO 5
TABELA 5.1 REQUISITOS DO SISTEMA....................................................................... 117
TABELA 5.2 REQUISITOS NÃO FUNCIONAIS E ORGANIZACIONAIS DO SISTEMA......... 117
TABELA 5.3 SÍMBOLOS DO LEL ENCONTRADOS NOS REQUISITOS FUNCIONAIS......... 119
TABELA 5.4 SÍMBOLOS DO LEL DETALHADO............................................................ 120
TABELA 5.5 INCLUSÃO DOS REQUISITOS NÃO FUNCIONAIS........................................ 128
xiv
TABELA 5.6 INCLUSÃO DOS REQUISITOS ORGANIZACIONAIS..................................... 128
TABELA 5.7 MAPEAMENTO ENTRE OS TERMOS DO LEL............................................ 129
TABELA 5.8 CENÁRIOS DO LEL................................................................................ 130
TABELA 5.9 CONTRIBUIÇÕES DOS ASPECTOS............................................................ 141
TABELA 5.10 COMPOSIÇÃO DOS ASPECTOS IDENTIFICADOS....................................... 142
TABELA 5.11 RESOLUÇÃO DE CONFLITOS................................................................... 146
TABELA 5.12 TERMOS DO LEL LISTADOS SEGUNDO O SEU TIPO................................. 149
TABELA 5.13 MAPEAMENTO REALIZADO.................................................................... 150
CAPÍTULO 6
TABELA 6.1 MAPEAMENTO ENTRE AS VERSÕES DA REQUISITE................................. 172
Lista de Tabelas
xv
Índice
AGRADECIMENTOS................................................................................................ iv
RESUMO.................................................................................................................... vii
ABSTRACT................................................................................................................ viii
LISTA DE ABREVIATURAS................................................................................... ix
LISTA DE FIGURAS................................................................................................. x
LISTA DE TABELAS................................................................................................ xiii
1. INTRODUÇÃO.................................................................................................. 1
1.1 CONTEXTO............................................................................................... 1
1.2 PROBLEMA............................................................................................... 4
1.3 CONTRIBUIÇÕES....................................................................................... 6
1.4 OBJETIVOS............................................................................................... 6
1.5 JUSTIFICATIVA.......................................................................................... 7
1.6 ESCOPO DA DISSERTAÇÃO........................................................................ 7
1.7 METODOLOGIA......................................................................................... 8
1.8 ORGANIZAÇÃO DA DISSERTAÇÃO............................................................. 10
2. DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS....... 12
2.1 CONCEITOS GERAIS DE AOSD................................................................. 13
2.1.1 CONCEITOS DE ASPECTOS, CONCERN E CROSSCUTTING
CONCERNS.................................................................................
14
2.1.2 SEPARAÇÃO DE PROPRIEDADES................................................. 15
2.1.3 COMPOSIÇÃO DE PROPRIEDADES.............................................. 20
2.1.4 A PROGRAMAÇÃO ORIENTADA A ASPECTOS E A LINGUAGEM
ASPECTJ...................................................................................
22
2.2 FASE DE REQUISITOS............................................................................... 26
2.2.1 ABORDAGEM DE VIEWPOINT..................................................... 26
2.2.2 ABORDAGEM AORE UTILIZANDO UML................................... 30
2.2.3 ABORDAGEM GOALS............................................................... 37
2.2.4 ABORDAGEM COM CASOS DE USO............................................. 42
2.2.5 ABORDAGEM THEME/DOC...................................................... 48
2.3 COMPARAÇÃO DAS ABORDAGENS APRESENTADAS.................................. 54
2.4 RESUMO DO CAPÍTULO............................................................................ 64
3 A METODOLOGIA MDSODI E O AMBIENTE DISEN................................. 65
3.1 A METODOLOGIA MDSODI..................................................................... 66
3.2 O AMBIENTE DISEN................................................................................ 70
3.3 A FERRAMENTA REQUISITE................................................................. 72
3.3.1 ASPECTOS FUNCIONAIS............................................................. 74
3.3.2 A ARQUITETURA DA REQUISITE............................................. 76
3.3.3 EXEMPLO DE INSTÂNCIAS DA REQUISITE NO DISEN............. 79
3.4 RESUMO DO CAPÍTULO............................................................................. 81
4. A ABORDAGEM DAORE................................................................................ 82
4.1 OBJETIVOS E DIRETRIZES PRINCIPAIS....................................................... 83
4.2 O PROCESSO DE DESENVOLVIMENTO PROPOSTO...................................... 89
4.2.1 FASE 1 – CONSTRUÇÃO DOS REQUISITOS.................................. 90
xvi
4.2.1.1 LEVANTAMENTO DOS REQUISITOS.............................. 90
4.2.1.2 CONSTRUÇÃO DE REQUISITOS FUNCIONAIS................. 91
4.2.1.3 CONSTRUÇÃO DE REQUISITOS NÃO FUNCIONAIS......... 91
4.2.1.4 CONSTRUÇÃO DE REQUISITOS ORGANIZACIONAIS...... 98
4.2.2 FASE 2 – CONSTRUÇÃO DO LEL............................................... 100
4.2.3 FASE 3 – DEFININDO ASPECTOS CANDIDATOS........................... 102
4.2.3.1 IDENTIFICANDO CONTRIBUIÇÕES............................ 103
4.2.3.2 DEFININDO COMPOSIÇÃO........................................ 104
4.2.3.3 IDENTIFICANDO CONFLITOS.................................... 105
4.2.4 FASE 4 - MAPEAMENTO DE ONTOLOGIAS................................. 107
4.2.5 GERAÇÃO DE ARQUIVOS PARA EXPORTAÇÃO........................... 108
4.3 CONSIDERAÇÕES SOBRE A ABORDAGEM DAORE.................................... 109
4.3.1 COM RELAÇÃO AOS OBJETIVOS PROPOSTOS............................. 109
4.3.2 USO NA REQUISITE E NO PROJETO DISEN................................. 110
4.3.3 DIFERENÇAS COM AS ABORDAGENS ESTUDADAS...................... 111
4.4 RESUMO DO CAPÍTULO............................................................................. 111
5. EXPERIMENTAÇÃO: CONTROLE DE EVENTOS....................................... 113
5.1 OBJETIVOS............................................................................................... 114
5.2 A ESCOLHA DA FERRAMENTA DE IMPLEMENTAÇÃO................................. 114
5.3 O SISTEMA PROPOSTO.............................................................................. 115
5.4 FASE 1 - IDENTIFICANDO OS REQUISITOS ................................................ 116
5.5 FASE 2 – CONSTRUINDO O LÉXICO........................................................... 118
5.5.1 ANALISANDO INTERDEPENDÊNCIAS E RESOLVENDO CONFLITOS 129
5.5.2 CONSTRUINDO OS CENÁRIOS..................................................... 129
5.5.3 ANALISANDO OS CENÁRIOS....................................................... 139
5.6 FASE 3 - DEFINIÇÃO DE ASPECTOS CANDIDATOS..................................... 139
5.7 FASE 4 - MAPEAMENTO DE ONTOLOGIAS................................................. 147
5.8 GERAÇÃO DE ARQUIVOS PARA EXPORTAÇÃO.......................................... 154
5.9 RESUMO DO CAPITULO............................................................................. 157
6 A FERRAMENTA REQUISITE E A ABORDAGEM DAORE....................... 158
6.1 SITUAÇÃO ATUAL.................................................................................... 158
6.1.1 MENU PRINCIPAL DA REQUISITE 159
6.2 SITUAÇÃO FUTURA................................................................................... 161
6.2.1 PROJETO DISEN........................................................................ 161
6.2.2 MUDANÇAS PREVISTAS NA REQUISITE...................................... 162
6.2.3 ANÁLISE DO IMPACTO DAS MUDANÇAS..................................... 171
6.3 RESUMO DO CAPÍTULO............................................................................. 176
7 CONCLUSÃO.................................................................................................... 177
7.1 CONTRIBUIÇÕES....................................................................................... 177
7.2 LIMITAÇÕES E TRABALHOS FUTUROS...................................................... 178
7.3 CONSIDERAÇÕES FINAIS........................................................................... 179
7.4 TRABALHOS SUBMETIDOS........................................................................ 180
REFERÊNCIAS BILBIOGRÁFICAS................................................................ 182
ANEXOS............................................................................................................ 189
Índice
1. Introdução 1
CAPÍTULO
1
INTRODUÇÃO
The best preparation for good work
tomorrow is to do good work today.
Elbert Hubbard
Neste capítulo apresentamos uma visão geral da proposta de
dissertação. Inicialmente, descrevemos o contexto no qual este
trabalho de pesquisa se insere. A seguir, discutimos qual o problema
que pretendemos resolver e quais os objetivos e finalidades da
pesquisa, por fim apresentamos a metodologia de pesquisa que foi
adotada, delimitamos o escopo da proposta de dissertação e
descrevemos a estrutura dos capítulos deste trabalho.
1.1 Co ntexto
O processo de desenvolvimento de sistemas de informação sofreu uma quebra de
paradigma com o surgimento da orientação a objetos na década de 80 (SHAELER &
MELLOR, 1 9 90). Até então, os sistemas eram desenvolvidos de forma procedural e
estruturada, isso quando eram desenvolvidos seguindo um processo de desenvolvimento, pois
a maioria ignorava os conceitos propostos ou até mesmo desconheciam o processo em si.
Infelizmente, os conceitos advindos com a orientação a objetos não eram fáceis de s e
incorporar ao cotidiano, mesmo que os defensores da orientação a objetos afirmassem que “a
orientação a objetos é uma coisa natural, pois o mundo é orientado a objetos”
1. Introdução 2
(www.forumweb.com.br/artigos/artigos.php? action=file&id=535). Muitas vezes, estas dificuldades
na assimilação dos conceitos se deviam à formação acadêmica, por esta ser de base
estruturada e, por outra, ser uma maneira completamente diferente de abstrair conceitos do
mundo real.
Atualmente, uma nova abordagem no desenvolvimento de sistemas tem sido
pesquisada e utilizada: o Desenvolvimento de Sistemas baseado na Orientação a Aspectos -
AOSD.
Esta abordagem, em parte, segue os conceitos de (DIJKSTRA, 1976), que
apresenta o princípio da separação de concerns1, onde para superar a complexidade, deve-se
resolver um concern importante por vez. Em engenharia de software, esse princípio está
relacionado à modularização e à decomposição de sistemas (PARNAS, 1972). Os sistemas de
software complexos devem ser decompostos em unidades modulares menores e claramente
separados, cada uma lidando com um único concern. Se bem realizada, a separação de
concerns pode oferecer muitos benefícios cruciais (DIJKSTRA, 1976) (TARR, 1999). Ela
oferece suporte a uma melhor manutenibilidade com alterações aditivas, em vez de evasivas,
melhor compreensão e redução da complexidade, melhor reusabilidade e uma integração de
componentes simplificada.
Para (ELRAD et al., 2001 apud SOUZA, 2004), assim como o paradigma
orientado a objetos (POO) não descarta as idéias de dados e operações do paradigma
estrutural, o paradigma orientado a aspectos (POA) não rejeita a tecnologia existente. O
paradigma orientado a aspectos complementa o paradigma orientado a objetos a fim de
auxiliar na separação daquelas preocupações que o POO manipula deselegantemente (não
possuindo recursos para fazer tal tarefa, necessitando de outras formas que tornam o código
mais difícil de entender e manutenir). Para isso, o paradigma orientado a aspectos provê
mecanismos para localizar e compor os crosscutting concerns2 (ou aspectos) com as unidades
que eles afetam de maneira não invasiva, ou seja, evitando que fiquem explicitamente
espalhados nos artefatos de software ou misturados com as preocupações específicas desses
artefatos.
Esse é um paradigma emergente (ELRAD et al., 2001 apud SOUZA, 2004) e, o
estado atual da pesquisa nessa área pode ser comparado ao estado da pesquisa em orientação a
1 Um concern pode ser definido como: questão, característica ou preocupação. Porém, neste trabalho
utilizaremos o termo em inglês.
2 Crosscutting concerns podem ser traduzidos como preocupações ou características transversais. Em Piveta
(2004) foi proposto que se utilizasse o termo concerns transversais, porém, neste trabalho, utilizaremos o termo
em inglês.
1. Introdução 3
objetos há vinte anos atrás: os conceitos básicos estão se formando e um grupo crescente de
pesquisadores está usando esses conceitos em seus trabalhos sobre orientação a aspectos.
As pesquisas realizadas em Early Aspects têm evoluído muito desde 2002
(RASHID et al, 2002). Por conseqüência, várias abordagens têm se preocupado com a
identificação de aspectos nas fases iniciais do desenvolvimento, principalmente na fase de
requisitos, como a Abordagem Viewpoint (RASHID et al., 2002) (RASHID et al., 2003),
Metas (YU et al., 2004) (SILVA&LEITE, 2005b), Casos de Uso (JACOBSON&NG, 2005)
(SOUZA, 2004) e Theme/DOC (CLARKE&BANIASSAD, 2005). Estas abordagens tiveram
início na orientação não aspectos e foram adaptadas e desenvolvidas a fim de se moldar ao
novo paradigma da orientação a aspectos.
Ainda se tratando da abordagem orientada a objetos, muitos projetos se
desenvolveram utilizando esta abordagem em Universidades Brasileiras (UFPE, UEM, UFRJ,
PUC-Rio, entre outras) e ainda estão em desenvolvimento, mesmo porque, a abordagem de
aspectos não chega a ser uma quebra de paradigmas, mas sim uma extensão da abordagem
que está sendo utilizada (JACOBSON&NG, 2005).
No Paraná, mais especificamente na Universidade Estadual de Maringá (UEM),
membros do Grupo de Estudos e Pesquisa de Sistemas de Software Distribuídos (GESSD),
desenvolvem vários trabalhos relacionados à Metodologia de Desenvolvimento de Software
Distribuído – MDSODI (GRAVENA, 2000) (HUZITA, 1999) .
A MDSODI é uma metodologia de desenvolvimento de software que oferece
suporte à especificação de alguns aspectos relacionados a sistemas distribuídos desde as fases
iniciais de projeto. A notação desta metodologia baseia-se na Unified Modeling Language –
UML (UML, 2006), mas adota também algumas extensões para a representação de sistemas
distribuídos. Dessa forma é possível abordar de forma clara os aspectos relacionados à
distribuição do sistema desde, as fases iniciais do processo de desenvolvimento de software.
Como a MDSODI é uma metodologia que cobre todo o processo de
desenvolvimento de software, é natural imaginar-se um cenário onde serão utilizadas várias
ferramentas de apoio ao desenvolvimento de software cada qual criando e, possibilitando a
manutenção necessária dos vários artefatos relativos às diversas fases do processo. Estas
ferramentas poderão ter sido criadas especialmente para esta metodologia, ou então serem
ferramentas já existentes no mercado, produzidas por terceiros, cada uma com sua
especialidade e potencialidade.
Na mesma universidade, existe também o projeto de um ambiente distribuído de
desenvolvimento de software, denominado Distributed Software Engineering Environment -
1. Introdução 4
DiSEN (PASCUTTI, 2002) (HUZITA,2004). O ambiente DiSEN foi concebido com vistas à
utilização da metodologia MDSODI, enquanto que na sua arquitetura, pode-se observar que o
mesmo oferece suporte a agentes. Entende-se, que neste ambiente, estarão sendo utilizadas
várias ferramentas de desenvolvimento de software, onde cada uma delas estará produzindo
artefatos como resultados do trabalho do desenvolvedor de software.
No ambiente do projeto DiSEN a preocupação com o gerenciamento de requisitos
surgiu com a elaboração de uma ferramenta própria a REQUISITE (BATISTA, 2003). Esta
ferramenta foi desenvolvida baseada nos conceitos de orientação a objetos, seguindo ainda a
metodologia MDSODI para ambientes distribuídos, porém não considera os crosscutting
concerns, tanto em nível de desenvolvimento da ferramenta em si como em nível de projeto
dos requisitos inseridos.
A elaboração de uma nova abordagem que contemple a identificação e composição
dos crosscutting concerns e que esteja inserida no contexto da metodologia MDSODI
permitirá a atualização dos projetos a serem desenvolvidos e os que estão atualmente sendo
desenvolvidos, como o projeto do ambiente DiSEN e suas ferramentas de apoio.
1.2 Problema
As motivações para o surgimento do paradigma orientado a aspectos originaramse,
principalmente, a partir de problemas encontrados na codificação de sistemas. Por isso, a
maior parte da pesquisa nessa área tem sido focada nas atividades orientadas à
implementação. Atualmente, a orientação a aspectos vem sendo utilizada, q u a s e que
exclusivamente, na codificação de sistemas através de linguagens como AspectJ (KICZALES,
2001) e Hyper/J (OSSHER&TARR, 2000).
Recentemente, a comunidade de Engenharia de Software tem se interessado em
propagar a utilização dos fundamentos e práticas desse paradigma para as atividades iniciais
do ciclo de desenvolvimento (SOUZA, 2004). Algumas das razões que impulsionam essa área
de pesquisa são:
· Antecipar a identificação e a modelagem de aspectos;
· Antecipar o raciocínio sobre quais unidades devem ser afetadas por um aspecto e
como a composição entre o aspecto e as unidades afetadas por ele deve ser realizada;
· Permitir que os benefícios da utilização do paradigma orientado a aspectos sejam
obtidos ao longo de todo processo de desenvolvimento e não apenas nos artefatos de
implementação;
1. Introdução 5
· Possibilitar que o entendimento de um sistema implementado com uma linguagem
orientada a aspectos possa ser obtido através de modelos de análise e projeto, ao invés
de exigir que ele dependa da análise do código do sistema.
Desde 2002, algumas abordagens iniciais vêm sendo propostas nesse sentido.
Alguns trabalhos já se preocupam com outras fases do desenvolvimento, desde requisitos até
a implementação, (SOUZA, 2004) (JACOBSON & NG, 2005) (CLARKE & BANIASSAD,
2005). Porém, todos os trabalhos pesquisados não possuem uma maneira clara e objetiva de
tratar alguns problemas relacionados à fase de requisitos. Alguns problemas gerais
encontrados foram:
· A identificação e tratamento de requisitos organizacionais;
· A identificação de crosscutting concerns (sendo estes funcionais, não-funcionais ou
até mesmo organizacionais);
· Representação gráfica do modelo, em muitos casos o modelo não é adequado ou a
ferramenta para tal não está disponível, como podemos observar no Capítulo 3, onde
realizamos um estudo comparativo das abordagens existentes; e
· Em algumas abordagens, a representação dos requisitos não funcionais (RNF)
(CHUNG et al., 2000) se confunde com características adicionais do sistema, como no
trabalho de Jacobson & Ng (2005).
Adicionalmente podemos citar alguns problemas específicos ligados ao nosso
projeto no ambiente DISEN:
· Inserção no contexto da metodologia MDSODI;
· Exportação de modelos no padrão XML, usando XML 3 Schema para definir padrões
a serem utilizados. Estes modelos englobam: Léxico Extendido da Linguagem4 (LEL),
aspectos candidatos5, cenários6 e ontologias7.
Algumas abordagens estudadas, relativas à fase de requisitos, como: como a
Abordagem Viewpoint (RASHID et al., 2002) (RASHID et al., 2003), Metas (YU et al., 2004)
(SILVA & LEITE, 2005b), Casos de Uso (JACOBSON & NG, 2005) (SOUZA, 2004) e
Theme / DOC (CLARKE & BANIASSAD, 2005), possuem vantagens e desvantagens em
relação a outras. Esse fato foi a principal motivação para o desenvolvimento desta proposta de
3 Uma definição de XML Schema e seus conceitos principais podem ser encontrados em XML (2006).
4 LEL – Léxico Extendido da Linguagem (Language Extended Lexicon), técnica que auxilia a descrição de
cenários utilizando linguagem natural – encontramos também o termo LAL (Léxico Ampliado da Linguagem)
que significa a mesma coisa (Leite, 1997)
5 Veremos os conceitos de aspectos candidatos no Capítulo 3.
6 Conceitos de cenários e sua relação com o LEL podem ser encontrados em Leite (1997).
7 Conceitos de ontologias pode ser encontradas em Breitman (2005).
1. Introdução 6
dissertação (veremos mais no Capítulo 3, item 3.5 - Análise Comparativa das Abordagens em
AORE).
1.3 Contribuições
A principal contribuição deste trabalho é integrar a metodologia MDSODI ao
desenvolvimento de software orientado a aspectos.
Esta contribuição é baseada na técnica do LEL utilizada pelo ambiente DISEN na
elicitação dos requisitos através da ferramenta Requisite. Com o desenvolvimento de uma
nova abordagem que possa integrar o LEL na orientação a aspectos, de forma a facilitar a
identificação dos aspectos candidatos nas fases iniciais do processo de desenvolvimento, irá
contribuir para aumentar o reuso de componentes especificados.
1.4 Objetivos
O objetivo geral desta dissertação é apresentar uma nova abordagem de orientação
a aspectos para a fase de engenharia de requisitos, que se utilize do LEL, para que possa
facilitar a identificação e a separação de concerns nos projetos elaborados com base na
metodologia MDSODI.
A partir desse objetivo geral, definimos os seguintes objetivos específicos:
- Compreender os fundamentos do Desenvolvimento de Sistemas baseado na
Orientação a Aspectos nas fases iniciais do processo de desenvolvimento;
- Propor uma nova abordagem através da análise e seleção de pontos de vantagens
oferecidas pelas abordagens existentes, permitindo uma abordagem mais flexível que
possibilite o suporte tanto na adaptação de projetos existentes (por se utilizar do LEL)
quanto para novos projetos; e
- Realizar a validação utilizando a abordagem proposta através da experimentação, onde
o projeto a ser desenvolvido será o mesmo apresentado pela ferramenta REQUISITE
para que se possa avaliar o impacto das mudanças propostas na ferramenta e no
ambiente DISEN.
1. Introdução 7
1.5 Justificativa
Os fundamentos do paradigma orientado a aspectos podem ser usados de maneira
complementar aos do paradigma orientado a objetos8 (SOUZA, 2004). Por isso, o paradigma
orientado a aspectos pode ser considerado uma evolução, não uma revolução, em relação ao
paradigma orientado a objetos e pode ser usado para melhorar técnicas existentes.
A quebra de paradigmas sempre foi um grande problema na área de
desenvolvimento de sistemas, em particular na década de 80 com o surgimento da orientação
a objetos. Podemos dizer que foi uma grande revolução, pois apresentava conceitos até então
desconhecidos e completamente diferentes dos usados na época.
A orientação a aspectos, por outro lado, não apresenta conceitos tão diferentes
assim, pois ela apenas agrega alguns conceitos à abordagens que já existem. Desde o seu
surgimento, no fim da década de 90, voltada apenas para a implementação, é um exemplo
disso, uma vez que adicionava construções e mecanismos específicos para o tratamento de
aspectos em linguagens de programação, como AspectJ (KICZALES., 2001), que estende a
linguagem orientada a objetos Java (GOSLING et al., 2000).
Atualmente, as abordagens existentes em orientação a aspectos possuem algumas
vantagens, como:
(i) Descrição detalhada das fases principais do desenvolvimento;
(ii) Características próprias definidas pelo tipo de abordagem considerada;
Porém, todas possuem uma característica negativa: não oferece a p o i o à
identificação de aspectos.
Pelos motivos acima descritos, a direção que escolhemos para alcançar o objetivo
geral deste trabalho foi o de propor uma nova abordagem que facilite a identificação de
aspectos nas fases iniciais do processo de desenvolvimento utilizando a metodologia
MDSODI para sistemas distribuídos, que estejam inseridas no contexto de cenários utilizando
o LEL.
1.6 Escopo da Disse rtação
Conforme mencionado anteriormente, para alcançar o objetivo geral desta
dissertação, decidimos adaptar algumas características das abordagens existentes para as fases
iniciais do processo de desenvolvimento.
8 Mas não se limita ao paradigma orientado a objetos, podendo ser usado também em conjunto com outros
paradigmas como o estruturado e o funcional (CONSTANTINIDES & HASSOUN, 2002).
1. Introdução 8
Nosso trabalho focará a fase de requisitos, uma vez que as abordagens estudadas
se referem, principalmente, à fase de requisitos e que nosso objetivo é identificar os aspectos
nesta fase. Assim, deixaremos de abordar o tratamento de projeto, implementação e testes,
sendo um trabalho a ser feito futuramente.
1.7 Metodo logia de Desenvo lvimento da Pesquisa
A pesquisa em Engenharia de Software pode ser conduzida através de quatro
métodos: o científico, o de engenharia, o experimental e o analítico (WOHLIN, 2000 apud
TRAVASSOS, 2002).
O método científico foca na observação de um ambiente e na tentativa de extrair
dele algum modelo ou teoria que possa explicar o fenômeno estudado. O método de
engenharia, por sua vez, é baseado na observação de soluções existentes, na identificação de
problemas nessas soluções e na sugestão de abordagens para melhorar as soluções analisadas.
Já o método experimental pretende fornecer um modelo novo para solução de um problema e
tenta estudar o impacto desse modelo. Por fim, o método analítico oferece uma base analítica
(ou matemática) para o desenvolvimento de modelos.
Este trabalho de pesquisa seguiu o método de engenharia (baseado na Figura 1.1).
1. Introdução 9
1 - Revisão
Bibliográfica
2 - Análise das
Abordagens
4 - Elaboração
da Nova
Abordagem
5 - Aplicação
na nova
Abordagem
6 - Validação
7 - Apresentação
- AOSD
-MDSODI, DISEN e REQUISITE
- Abordagens existentes em
AORE
- Análise Comparativa;
- Definição de pontos principais
a serem considerados
-Nova abordagem a partir dos
pontos considerados
- através da experimentação
-Análise do impacto das
mudanças no ambiente DISEN e
na ferramenta REQUISITE
- Apresentação da dissertação
3 – Exame de
Qualificação
-Apresentação da proposta de
qualificação
FIGURA 1.1 – ESTRUTURA DA PESQUISA SEGUIDA.
Na Figura 1.1 temos a estrutura de pesquisa que foi seguida:
1. Inicialmente foi feita uma revisão bibliográfica sobre os conceitos de
AOSD, a metodologia MDSODI, o ambiente DISEN e a ferramenta
REQUISITE. Após isso, foi elaborado u m estudo sobre algumas
abordagens existentes par a a AORE: Viewpoint (RASHID et al., 2002)
(RASHID et al., 2003), Metas (YU et al., 2004) (SILVA & LEITE, 2005b),
Casos de Uso (JACOBSON & NG, 2005) (SOUZA, 2004) e Theme / DOC
(CLARKE & BANIASSAD, 2005);
1. Introdução 10
2. Nesta fase foi realizada uma análise comparativa das abordagens para
identificar os conceitos, vantagens e desvantagens de cada uma, ou seja, os
elementos relevantes foram identificados e mapeados;
3. Foi apresentada a proposta de qualificação para o mestrado;
4. Baseado nos pontos considerados no passo 2 foi elaborada a nova
abordagem de forma a apresentar características identificadas em algumas
das abordagens estudadas, além de possuir características próprias;
5. Aplicação da nova abordagem em um estudo de caso para validar a mesma.
Este estudo de caso foi o mesmo realizado por ocasião da validação da
ferramenta REQUISITE, a fim de se obter um comparativo de avaliação
utilizando duas abordagens diferentes;
6. Análise das mudanças para avaliar o impacto na ferramenta REQUISITE e
no projeto DISEN, com o objetivo de sugerir mudanças e pontos críticos
para a validação da nova abordagem, ou seja, o quanto esta mudança foi
benéfica para o projeto; e
7. Apresentação do trabalho.
1.8 Organização da Disse rtação
Além deste capítulo introdutório e de um glossário e um anexo que incluímos no
final da dissertação, este trabalho é composto pelos seguintes capítulos:
· Capítulo 2: apresenta uma visão geral do Desenvolvimento Orientado a Aspectos e
descreve algumas abordagens utilizadas para a fase de Requisitos. Ao final do capítulo
é apresentado um comparativo entre as abordagens. Este estudo comparativo foi
utilizado como base da confecção da nova abordagem;
· Capítulo 3: apresenta uma visão geral sobre a metodologia MDSODI, o ambiente
DiSEN e a ferramenta REQUISITE e como se relacionam;
· Capítulo 4: detalha a nova abordagem, descrevendo em cada fase o que dever ser feito;
· Capítulo 5: descreve a utilização da abordagem apresentada no Capítulo 4 em uma
experimentação. O objetivo principal é propiciar a validação da nova abordagem, de
maneira que se possa avaliar o impacto sobre a ferramenta REQUISITE e o projeto
DiSEN;
1. Introdução 11
· Capítulo 6: apresenta o impacto da abordagem DAORE na ferramenta Requisite, suas
principais implicações, análises e comparações; e
· Capítulo 7: apresenta as conclusões, enumera as contribuições e propõe trabalhos
futuros.
2.Desenvolvimento de Software Orientado a Aspectos 12
CAPÍTULO
2
DESENVOLVIMENTO DE SOFTWARE ORIENTADO A
ASPECTOS
O que sabemos é uma gota, o que ignoramos é um oceano.
Isaac Newton
O desenvolvimento de software tem sido alvo de estudos
(CHITCHYAN et al, 2005b) (SILVA, 2004) a fim de garantir a
qualidade do produto final, ou seja, o software em s i, e do próprio
processo de desenvolvimento que o definiu. Isto tem ocorrido desde
meados da década de 70 com o desenvolvimento estruturado, sendo
a Análise Estruturada de Sistemas oriunda da programação
estruturada.
O Desenvolvimento de Software Orientado a Aspectos (AOSD) é
advindo da programação orientada a aspectos, assim como foi na
época do desenvolvimento estruturado de sistemas.
As técnicas existentes de AOSD provêm uma forma sistemática de
identificar, modularizar, representar e compor os crosscutting
concerns (propriedades transversais) como: segurança, mobilidade e
regras de tempo real (CHITCHYAN et al., 2005).
2.Desenvolvimento de Software Orientado a Aspectos 13
Em 1999, em um congresso de Engenharia de Requisitos em
Lymerick – Ireland, fo i utilizado pela primeira vez o termo
“Aspect-oriented Requirements Engineering” ou AORE
(GRUNDY,1999), demonstrando o interesse e a preocupação em
tratar estes crosscutting concerns já na fase de requisitos. Em 2002,
em Essen-Alemanha, igualmente no congresso de Engenharia de
Requisitos o termo Early Aspects (RASHID et al, 2002) fo i usado
pela primeira vez.
Early Aspects tem como foco principal a gerência das propriedades
transversais nos estágios inic iais do desenvolvimento, englobando
desde a engenharia de requis itos até o design de arquitetura.
Neste capítulo é apresentado uma visão geral dos principais
conceitos do desenvolvimento de software orientado a aspectos e
algumas abordagens existentes em AOSD. Inic ialmente, descrevese
os conceitos básicos da orientação a aspectos, como a separação
de propriedades, por exemplo. Em seguida, é detalhado as
motivações para o surgimento desse paradigma de
desenvolvimento, descrevendo os problemas que ele se propõe a
solucionar e algumas abordagens existentes em AORE. Por fim, é
realizada uma comparação entre as abordagens apresentadas,
enfatizando seus pontos fortes e fracos nas considerações finais, a
qual será o ponto de partida para o próximo capítulo.
2.1 Co nceitos Gera is de Desenvolv imento Orientado a
Aspectos (AOSD)
Alguns conceitos relacionados à AOSD são muito importantes para o perfeito
entendimento deste paradigma, pois são a partir destes que todo o processo é baseado.
Assim, veremos alguns destes conceitos a seguir.
2.Desenvolvimento de Software Orientado a Aspectos 14
2.1.1 Co nceito de aspectos, concern e crosscutting concern
Encontramos algumas definições de aspectos na literatura pesquisada, que se
segue:
Segundo Jr (2003) aspectos são representações de concerns que atravessam as
representações de outros concerns.
Para Clarke & Baniassad (2004, 2005) os aspectos são comportamentos que
estão misturados e espalhados através do sistema e é um tipo particular de concern.
Brito & Moreira (2003) definem um concern como sendo uma questão ou
assunto de interesse no sistema de software, exemplificando ainda que concern pode ser
um objetivo ou um conjunto de propriedades que o sistema deve satisfazer.
Segundo Tekinerdogan (2004) um concern é um subproblema.
Para Mili et al. (2004) um concern é um conjunto de requisitos relacionados.
Para Silva & Leite (2005) um concern é uma característica do sistema ou do
domínio que seja interessante analisar quer isoladamente quer em conjunto com outras.
Figueiredo et al. (2005) argumenta que um concern está crosscutting se está
atravessado em outros concerns em um módulo ou em múltiplos módulos do sistema.
Para Chitchyan et al. (2005a) o termo crosscutting concerns se refere a fatores
de qualidade ou funcionalidades do software que não podem ser eficientemente
modularizados usando técnicas existentes de desenvolvimento de software (a abordagem
orientada a objetos).
Nesse trabalho será utilizado o conceito de que um concern é uma propriedade,
sendo esta propriedade um requisito funcional ou não funcional (YU et al, 2004) e que um
crosscutting concern é uma propriedade transversal, ou seja, um requisito (ou propriedade)
que está transversal em relação a outros requisitos é um forte candidato a ser um aspecto.
Existem vários exemplos de comportamentos que podem ser citados como
aspectos e que possuem este comportamento ou funcionalidade de precisar ser carregada
em diferentes módulos de um código orientado a objeto, como segurança, persistência e
sincronização, entre outros.
Atualmente há uma preocupação crescente em conseguir identificar aspectos
nas fases iniciais do processo de desenvolvimento, sendo alvo de estudos comparativos de
2.Desenvolvimento de Software Orientado a Aspectos 15
abordagens que tratam da fase de requisitos (CHITCHYAN et al, 2005a) (BAKKER et al,
2005).
Assim, temos o termo early aspects que define os crosscutting concerns ou as
propriedades transversais identificadas nas fases iniciais do ciclo de desenvolvimento de
software (RASHID et al, 2002) (ARAUJO et al, 2005). Estas fases incluem a análise de
requisitos, análise de domínio e a fase de projeto da arquitetura.
As técnicas de AOSD provêm uma maneira sistemática de identificar,
modularizar, representar e compor os crosscutting concerns, ou seja, separação e
composição de propriedades (CHITCHYAN et al, 2005a).
A seguir é descrito estes dois conceitos, que são os pilares da orientação a
aspectos.
2.1.2 Sepa ração de Pro prieda des
Produzir software com qualidade sempre foi um dos objetivos de todo o
desenvolvedor de software. P ressman (2005) alega que além de produzir software de
qualidade deve-se tentar fazê-lo em um menor espaço de tempo possível, sendo esse um
dos principais objetivos da Engenharia de Software.
Para alcançar tal objetivo, diversas abordagens foram propostas ao longo dos
anos: Análise Estruturada de Sistemas (GANE & SARSON, 1977), Análise Essencial de
Sistemas (MCMENAMIN & PALMER, 1984), Análise Orientada a Objetos (SHLAER &
MELLOR, 1990), P r o c e s s o Catalysis (SOUZA & WILLS, 1 9 9 5 ), Processo
Unificado/UML (BOOCH et al, 1999) (JACOBSON et al., 1999) (SCOTT, 2003) e o
Desenvolvimento Orientado a Aspectos (JACOBSON & NG, 2005) (CLARKE &
BANIASSAD, 2005).
Guezzi apud S ouza ( 2004) estabeleceu alguns princípios que devem ser
aplicados ao longo do processo de desenvolvimento e nos artefatos de software: separação
de propriedades, modularidade, rigor e formalidade, incrementalidade, abstração,
generalidade e antecipação de mudanças.
O objetivo da separação de propriedades é identificar e modularizar as partes
do software que são relevantes para um conceito em particular, meta ou propósito (BRITO
& MOREIRA, 2003).
2.Desenvolvimento de Software Orientado a Aspectos 16
Com isso, este princípio permite que se reduza o raciocínio a uma quantidade
factível (DIJKSTRA, 1976). Esse princípio estabelece que um problema possa s e r
decomposto em unidades menores, claramente separadas, de maneira que cada uma delas
represente uma única preocupação (AKSIT et al. apud SOUZA, 2004). A idéia básica é
manipular com uma preocupação do sistema de cada vez, ou seja, o velho e bom “dividir
para conquistar”. Como conseqüência, a aplicação desse princípio possibilita:
· Diminuir a complexidade do desenvolvimento de software, concentrandose
em diferentes preocupações separadamente;
· Raciocinar sobre diferentes preocupações de maneira relativamente
independente;
· Facilitar a inserção/remoção de preocupações na aplicação;
· Dividir esforços e separar responsabilidades entre membros da equipe de
desenvolvimento; e
· Melhorar a modularidade de artefatos de software.
Souza (2004) aponta ainda que quando os artefatos de software possuem a
capacidade de separação de propriedades, elas tendem a ser similares (forte coesão) e a
dependência entre os artefatos é minimizada (fraco acoplamento).
Conseqüentemente, mudanças em artefatos relacionadas a uma propriedade,
tendem a ter um efeito limitado ou até mesmo nenhum efeito em artefatos relacionados a
outras propriedades. Isso facilita a compreensão, evolução, adaptação, customização e
reuso dos artefatos de software.
Para implementar este princípio o engenheiro de software deverá se basear no
paradigma de programação adotado (objetos, estruturado ou aspectos).
De maneira geral, os métodos para separação de propriedades envolvem as
seguintes atividades (AKSIT et al. 2001):
· Identificação d e propriedades: seleção de propriedades que o sistema vai
incluir;
· Representação de propriedades separadamente: especificação de propriedades
em unidades ou num conjunto de unidades que concretizam a realização de
cada uma das propriedades; e
2.Desenvolvimento de Software Orientado a Aspectos 17
· Composição de propriedades: integração de unidades separadas a fim de dar
a elas alguma coerência para formar o conjunto do sistema.
As abordagens tradicionais de desenvolvimento de software (orientação a objetos e
métodos estruturados) f oram criadas com este princípio geral em mente. Entretanto, elas
possuem limitações no tratamento dos requisitos não-funcionais. Assim, não consideram a
natureza de transversal destas propriedades. Para tentar solucionar essas limitações, foram
propostas algumas abordagens na literatura, tais como: Programação Adaptativa
(LIEBERHERR, 1996), Filtros de Composição (BERGMANS & AKSIT, 2001; BERGMANS
et al., 2001), Separação Multidimensional de Preocupações (TARR et al., 1999; OSSHER &
TARR, 2000) e Programação Orientada a Aspectos (KICZALES et al., 1997). Essas propostas
pertencem a uma área de pesquisa denominada de Separação Avançada de Preocupações
(Advanced Separation of Concerns).
Um modelo genérico para tratar a separação avançada de propriedades1 foi
proposto por Brito & Moreira (2003) e é baseado nas atividades citadas anteriormente
propostas por Aksit (2001), conforme pode ser observado na figura 3.1.
1 o termo preocupações é utilizada na tradução em alguns artigos, porém iremos utilizar
propriedades.
2.Desenvolvimento de Software Orientado a Aspectos 18
FIGURA 2.1 – MODELO DE SEPARAÇÃO AVANÇADA DE PROPRIEDADES. ADAPTADO DE (BRITO &
MOREIRA, 2003).
A seguir segue-se uma breve descrição das tarefas a serem realizadas na Figura
2.1:
· Tarefa 1 – Identificar Concerns2 – a identificação de propriedades é uma tarefa
extremamente importante, pois é acompanhada por um entendimento completo e
exaustivo do sistema por meio da análise da documentação e qualquer outra
informação fornecida pelos stakeholders3 do sistema. Segundo Brito &Moreira
(2003) ainda é uma atividade dependente principalmente da experiência do
engenheiro de software.
· Tarefa 2 – Especificar Concerns – esta tarefa é subdividida em três sub-tarefas:
aplicar a abordagem que melhor especifica cada propriedade; identificar
2 O termo concern é utilizado por Brito & Moreira (2003). Assim, será utilizado apenas nos títulos das
tarefas explicitadas por eles.
3 Stakeholder pode ser qualquer pessoa que tem uma influência direta ou indireta no projeto (BRITO &
MOREIRA, 2003).
2.Desenvolvimento de Software Orientado a Aspectos 19
contribuições entre propriedades de tal forma que os conflitos possam ser
detectados e identificar prioridades e inter-relacionamentos.
· Tarefa 2.1 – Especificar concerns usando a melhor abordagem – podemos
utilizar qualquer técnica para a especificação de requisitos. Em certos casos, a
escolha deve ser feita durante a Tarefa 1, especialmente se uma técnica particular
foi usada para auxiliar o processo de elicitação. Se for assim, podemos construir
qualquer modelo ou outra documentação proposta por estas técnicas.
· Tarefa 2.2 – Identificar contribuições entre concerns – o relacionamento de
contribuição entre duas propriedades define a maneira pela qual uma propriedade
afeta o outro. Esta contribuição pode ser colaborativa (ou positiva, quando auxilia
o propriedade afetada) e sua representação é feita por um “+”, ou perigosa (ou
negativa, obstruindo a propriedade afetada) e sua representação é feita por um “-“.
· Tarefa 2.3 – Identificar prioridades e inter-relacionamentos – uma prioridade
proporciona um grau de importância a uma propriedade no sistema. A prioridade
da propriedade é um contexto de dependência, por exemplo, uma mesma
propriedade pode ser classificada com diferentes prioridades pelo stakeholder
dependendo do domínio de negócio. Os inter-relacionamentos fornecem uma lista
de propriedades e suas necessidades.
· Tarefa 3 – Identificar Crosscutting Concerns – uma propriedade está transversal
se precisa de mais de uma outra propriedade, identificado na Tarefa 2.3.
· Tarefa 4 – Compor Concerns – o objetivo desta tarefa é compor todas as
propriedades para formar todo o sistema. Esta tarefa é composta de quatro subtarefas.
· Tarefa 4.1 – Identificar match points – Identificar os pontos onde a composição
será realizada. Um match point indica qual propriedade transversal deve ser
composta com uma dada propriedade.
· Tarefa 4.2 – Identificar conflitos – identificar as situações de conflito entre
propriedades. Para um dado match point precisamos analisar se as propriedades
transversais envolvidas contribuem negativamente para outras quaisquer. Se
contribuírem positivamente não há problema.
2.Desenvolvimento de Software Orientado a Aspectos 20
· Tarefa 4.3 – Identificar concerns dominantes – Esta sub-tarefa ajuda a resolver
os conflitos identificados na tarefa anterior e é baseado nas prioridades atribuídas.
Se a prioridade atribuída a cada propriedade é diferente, o problema não é tão
difícil de resolver, e a propriedade dominante é aquele com a maior prioridade.
Entretanto, se no mínimo duas propriedades transversais possuem a mesma
prioridade, um trade-off4 devem ser negociado entre os usuários. A identificação
da propriedade dominante é importante para guiar a regra de composição.
· Tarefa 4.4 – Definindo regras de composição – a regra de composição define a
ordem na qual as propriedades devem ser aplicadas em um particular match point.
(BRITO & MOREIRA, 2003) indica o seguinte formato: <concern> <operador>
<concern>. Os operadores irão depender da linguagem a ser utilizada. Esta regra
expressa a ordem seqüencial na qual o aspecto deve ser combinado com a(s)
unidade(s) que ele afeta, ou seja, especifica como o comportamento do aspecto
deve ser aplicado no(s) match point ou ponto(s) de junção.
2.1.3 Composição de Propriedades
Na Figura 2.1 a composição de propriedades é realizada através da Tarefa 4 ( e
suas sub-tarefas), como explicado anteriormente.
Jacobson (2005) argumenta que a composição de aspectos, principalmente se
for feita em um nível mais alto de modelos de pontos de junção não é uma tarefa trivial.
Realizar a composição de aspectos dinamicamente tem seus próprios desafios, tornando
esta tarefa complicada na fase de programação. Porém, isto não implica que a composição
em nível de requisitos seja trivial.
Sem dúvida, são problemas diferentes, mas possuem desafios em ambas as
situações. Na programação pelo menos um modelo estruturado do sistema já está definido
(JACOBSON, 2005). Já na fase de requisitos, a situação é diferente, pois requisitos
tendem a estar em pedaços de textos os quais, geralmente, são difíceis de serem
interpretados e possuem informações ambíguas e incompletas (muitas das vezes).
4 Trade-off não pode ser traduzido literalmente pois perderá o sentido, porém neste contexto se refere a um
ponto de equilíbrio ou uma troca, a fim de achar um ponto neutro.
2.Desenvolvimento de Software Orientado a Aspectos 21
Assim o trabalho de especificação de regras de composição (pointcuts) é muito
mais complicado do que aparenta.
De maneira geral, o paradigma orientado a aspectos complementa paradigmas
anteriores (estruturado e orientado a objetos) em dois sentidos (ELRAD, 2001):
(i) Localizando propriedades transversais em unidades separadas, denominadas de
aspectos; e
(ii) Provendo mecanismos para fazer a composição de propriedades transversais
com as unidades de decomposição do sistema que elas afetam (também
denominadas de unidades base). Para que um aspecto seja combinado com a(s)
unidade(s) que ele afeta, são necessárias algumas informações:
(a) Ponto(s) de junção: indica em que ponto(s) na especificação da(s)
unidade(s) base o comportamento do aspecto deve ser incluído (BRITO
& MOREIRA, 2003);
(b) Regra de composição: expressa a ordem seqüencial na qual o aspecto
deve ser combinado com a(s) unidade(s) que ele afeta (MOREIRA et
al., 2002), ou seja, especifica como o comportamento do aspecto deve
ser aplicado no(s) ponto(s) de junção. As regras de composição mais
comuns são: “antes”, “depois”, e “ao invés de”; Exemplificando:
quando dito que o aspecto de autenticação de senha deve ser aplicado
antes da execução de transações bancárias, o termo antes corresponde a
uma regra de composição e a sentença execução de transações
bancárias corresponde ao ponto de junção (SOUZA, 2004)
Existem quatro possibilidades de especificar a composição entre um aspecto e
unidades base (KERSTEN & MURPHY, 1999):
· Fechada: o aspecto e a unidade base não “têm conhecimento” sobre a
existência um do outro, ou seja, eles não se referenciam diretamente;
· Aberta: aspecto e a unidade base “têm conhecimento” sobre a existência
um do outro, ou seja, eles se referenciam mutuamente;
· Dirigida ao componente: somente o asp
...