-
Notifications
You must be signed in to change notification settings - Fork 0
/
introducao.tex
138 lines (109 loc) · 11.9 KB
/
introducao.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
\chapter{Introdução}
Este capítulo contextualiza o tema deste trabalho, apresentando motivações para o uso da programação orientada a aspectos e a necessidade de realizar
a modelagem de sistemas orientados a aspectos. Apresentam-se os objetivos, a hipótese, a metodologia da pesquisa e a justificativa para realização do
estudo. Ao final, apresentam-se as limitações e a organização desta dissertação.
\section{Contextualização}
A Programação Orientada a Objetos (POO) \sigla{POO}{Programação Orientada a Objetos} é um paradigma de programação amplamente difundido e utilizado
para o desenvolvimento de aplicações. Esse paradigma permite implementações em um nível mais alto de abstração e o reuso de comportamentos
\cite{Laddad:2003:AAP:993468}.
O desenvolvimento de um sistema utilizando POO geralmente é dividido em quatro fases: análise, projeto, implementação e testes
\cite{pressman:01}. Durante as fases de análise e projeto eliciam-se os requisitos e elabora-se a modelagem do sistema. Esta modelagem deve expressar
características estruturais e dinâmicas. As características estruturais representam os interrelacionamentos entre os componentes do sistema. A parte
dinâmica representa as funcionalidades do sistema e como elas são realizadas em tempo de execução. Ambas características devem ser modeladas em alto
(modelos representando o domínio do problema) e baixo nível de abstração (modelos próximos ao nível de código), obtendo assim uma visão do todo e da
parte \cite{silva:00}.
Na fase de análise, primeiramente deve-se descobrir qual o problema do cliente e eliciar quais são os requisitos do sistema. Cada requisito
pode ser classificado como um interesse do cliente a fim de atingir um objetivo final \cite{Laddad:2003:AAP:993468}. Ao final do desenvolvimento,
após a modelagem nas fases de análise e projeto e o código nas fases de implementação e testes, todos interesses do cliente devem estar resolvidos, tendo
como resultado um sistema completo e funcional. Os interesses podem ser separados em dois tipos \cite{Laddad:2003:AAP:993468}:
\begin{itemize}
\item Interesses núcleo: Capturam uma funcionalidade principal e impactam apenas uma parte do sistema.
\item Interesses entrecortantes (\textit{Crosscutting concerns}): Capturam uma funcionalidade que impacta uma ou mais partes do sistema.
\end{itemize}
A POO pode ser utilizada para implementação de ambos tipos de interesses. Na POO, os interesses são agrupados em diferentes módulos. O problema é que
para sistemas complexos, há uma tendência de misturar interesses entrecortantes com interesses núcleo, prejudicando a manutenabilidade e compreensão do código.
Conclui-se que a POO tem limitações para implementar extensões para comportamentos que impactam várias partes de um sistema: os interesses
entrecortantes \cite{Kiczales97aspect-orientedprogramming}. A Programação Orientada a Aspectos (POA) \sigla{POA}{Programação Orientada a Aspectos} é uma extensão a
POO que permite uma implementação mais elegante para interesses entrecortantes.
O objetivo da POA é a modularização dos interesses entrecortantes para que os mesmos fiquem separados dos módulos que implementam os interesses
núcleo da aplicação \cite{Laddad:2003:AAP:993468}. Os interesses devem ser separados em módulos em todas as fases do desenvolvimento:
análise, projeto, implementação e testes. Assim, obtém-se um mapeamento direto de um interesse, facilitando a manutenção e compreensão de um sistema
desenvolvido utilizando aspectos. A separação de interesses é uma excelente prática para a construção de sistemas complexos, pois quanto maior o
número de interesses, maior a complexidade para implementá-los. Com a separação de interesses, cada módulo representa um interesse, que pode ser
implementado separadamente, diminuindo a complexidade de implementação \cite{Jacobson:2004:ASD:1062430}.
\section{Definição do Problema}
Segundo \cite{silva:00}, na modelagem de programas orientados a objetos podem-se identificar quatro pontos de vista essenciais: estrutural e
comportamental de sistema e estrutural e comportamental de classe. Um sistema modelado pelos quatro pontos de vista permite a compreensão e manutenção
do sistema e contribui para a geração de código em qualquer linguagem de programação, sendo considerada assim uma modelagem completa \cite{silva:07}.
Algumas abordagens já foram propostas para modelagem de sistemas orientados a aspectos com UML (Unified Modeling
Language)\sigla{UML}{Unified Modeling Language}\cite{uml:05}. Um grupo de propostas estende o meta-modelo da linguagem
\cite{Kienzle:2009:AMM:1509239.1509252} \cite{theme:04} \cite{Stein02onrepresenting} \cite{Klein:2007:WMA:1805812.1805819} \cite{Jacobson:2004:ASD:1062430} \cite{france:06}, introduzindo novas construções para representar a estrutura e o comportamento de aplicações orientadas a aspectos. Outro conjunto de propostas estende a UML através de um perfil UML \cite{Evermann:2007:MSP:1229375.1229379} \cite{Cottenier06themotorola} \cite{Cui:2009:MIA:1529282.1529377}, o qual
pode ser utilizado em ferramentas CASE que suportem a importação de perfis. No entanto, não existe nenhuma abordagem para modelagem de aspectos que
represente a estrutura e a dinâmica de um sistema e que forneça subsídios para visualização do efeito dos aspectos no sistema, realizando a
composição de modelos de aspectos com modelos núcleo automaticamente. Além disso, a modelagem deve permitir representar as características
inerentes à POA, como a possibilidade de capturar múltiplos pontos de execução de um programa com apenas uma expressão regular. A maior parte das propostas se
limitam a modelar apenas parte destas características.
\section{Objetivos}
\subsection{Objetivo Geral}
Propor uma abordagem para modelar sistemas orientados a aspectos nas fases de análise e projeto com a segunda versão da UML. Esta modelagem deve
representar a estrutura e a dinâmica de um sistema, permitir automatizar parte do processo de modelagem, possibilitando a alternância de visões da
dinâmica do sistema (com e sem explicitação dos aspectos) e, com isso, facilitar a compreensão e manutenção dos modelos.
\subsection{Objetivos Específicos}
\begin{itemize}
\item Modelar as características inerentes a aspectos com a segunda versão da UML.
\item Representar a estrutura e a dinâmica de sistemas orientados a aspectos, fornecendo subsídios para a composição de modelos e facilitando
a compreensão e manutenção do sistema.
\item Permitir a alternância de visões de um sistema orientado a aspectos, visualizando o efeito de modelos de
interesses entrecortantes (aspectos) em modelos núcleo.
\end{itemize}
\section{Hipótese de Pesquisa}
É possível modelar todas as características de programas orientados a aspectos com a segunda versão de UML, bem como é possível manipular esta
modelagem em um procedimento algorítmico capaz de explicitar e ocultar dinamicamente os aspectos da modelagem.
\section{Justificativa}
Tratando-se de POO, uma modelagem pode ser considerada completa se modelar os quatro pontos de vista fundamentais \cite{silva:00}. Em relação a
sistemas orientados a aspectos, além da modelagem estrutural e comportamental, definem-se dois requisitos para se obter uma modelagem
completa:
\begin{enumerate}
\item Representação das características inerentes à programas orientados a aspectos como: \textit{wildcards}, pontos de corte, avisos e
introduções.
\item Representação da estrutura e da dinâmica do sistema para permitir a composição em nível de modelo de interesses núcleo com interesses
entrecortantes (aspectos).
\end{enumerate}
Sabendo que a modelagem estrutural e dinâmica de um sistema facilita a compreensão e manutenção e também contribui para a composição de modelos,
conclui-se que este trabalho justifica-se pelo uso de artefatos que representem a estrutura e a dinâmica de um sistema, automatizando parte do
processo de modelagem. Além disso, a representação das características de aspectos deve ser completa na modelagem do sistema. Por isso, é importante
que a proposta de especificação permita representar todas as características da POA, como \textit{wildcards}, pontos de corte complexos, todos os
tipos de avisos e introduções. Sabe-se também que a segunda versão da UML é um padrão e é amplamente utilizada na modelagem de aplicações, sendo
assim, justifica-se que os modelos propostos estejam de acordo com a especificação proposta por esta linguagem. No entanto, a segunda versão da UML não
permite representar sistemas orientados a aspectos. Sendo assim, necessita-se estender a linguagem através de um perfil UML. Justifica-se a pesquisa
pela necessidade de buscar uma alternativa que permita modelar sistemas orientados a aspectos de maneira completa, representando todas as suas
características e automatizando parte do processo de modelagem.
\section{Método de Pesquisa}
A realização deste trabalho é composta pelos seguintes passos:
\begin{enumerate}
\item Análise de trabalhos correlatos;
\item Proposta para a especificação de sistemas orientados a aspectos utilizando a segunda versão da UML;
\item Implementar o suporte para modelagem proposta no ambiente SEA \cite{silva:00}, gerando um produto deste trabalho, que é o suporte a
modelagem de programas orientados a aspectos no ambiente SEA, permitindo a alternância de visões dos interesses modelados automaticamente;
\item Realizar um estudo de caso com a proposta de modelagem, realizando a composição de aspectos em nível de modelo e utilizando o visualizador de
interesses.
\item Comparar a abordagem proposta por esta dissertação com os trabalhos correlatos, explicitando os diferentes requisitos cumpridos por cada
proposta.
\end{enumerate}
\section{Classificação da Pesquisa}
A classificação desta pesquisa foi realizada baseando-se nas informações sobre metodologia de pesquisa de Silva e Menezes \cite{silva-menezes:01}. Em
relação a natureza, classifica-se esta pesquisa como \textbf{aplicada}, pois ela tem como objetivo gerar conhecimentos para aplicação prática em cima de
problemas específicos na área de modelagem de sistemas orientados a aspectos. A abordagem do problema utilizada nesta dissertação é
\textbf{qualitativa}, com o pesquisador realizando a análise dos dados indutivamente, onde o processo e seu significado são os
focos principais da abordagem. Em relação aos objetivos, classifica-se esta pesquisa como \textbf{exploratória}, realizando a análise dos trabalhos
correlatos e identificando quais parâmetros são implementados por cada proposta para modelagem de sistemas orientados a aspectos. Finalmente, em
relação aos procedimentos técnicos utilizados, classifica-se esta pesquisa como \textbf{pesquisa bibliográfica}, pois foi elaborada a partir de
material já publicado sobre a modelagem de sistemas orientados a aspectos. Esta pesquisa também tem um caráter \textbf{experimental} com a
implementação do protótipo para modelagem de aspectos no ambiente SEA.
\section{Organização desta dissertação}
Esta dissertação está organizada da seguinte maneira: o presente capítulo descreveu a motivação para a modelagem de sistemas orientados a aspectos,
objetivos, hipótese, método de pesquisa e justificativa. O capítulo {2} apresenta a fundamentação teórica com conceitos de programação orientada a
aspectos e da linguagem AspectJ, conceitos de análise e projetos de sistemas e modelagem e meta-modelagem com a segunda versão da UML. O capítulo {3}
discute sobre os trabalhos correlatos, realizando uma comparação entre abordagens. O capítulo {4} descreve a metodologia de modelagem
para a especificação de sistemas orientados a aspectos, incluindo o algoritmo para composição de aspectos. O capítulo {5} apresenta a modelagem de um
sistema de gerenciamento de hotel para verificar a aplicação da abordagem. Finalizando, o capítulo {6} discute sobre as conclusões deste trabalho.