O Desenvolvimento de Software Orientado a Aspectos (Aspect-Oriented Software
Development - AOSD) é uma tecnologia recente de desenvolvimento de software que objetiva a
identificação e composição de propriedades ou funcionalidades de interesse, existentes em determinado sistema, popularmente referidos por assuntos. Por outro lado, um assunto representa uma matéria de interesse associada a um certo problema, quando importa às partes interessadas no sistema. A importância da separação dos assuntos foi primeiramente descrita em Dijkstra (1976).
O AOSD surgiu para resolver os problemas associados aos efeitos de dispersão e confusão de códigos de programação, propondo mecanismos para identificar, modularizar, representar e compor os assuntos transversais. Assim, há a real necessidade de sua utilização para compor sistemas naturais complexos, caso em que se enquadra a formatação de cenários para o planejamento e gestão de recursos hídricos.
Considerando o Paradigma de Orientação a Aspectos (POA), tem-se duas etapas de trabalho: a primeira é a decomposição do sistema em partes não entrelaçadas e não espalhadas; a segunda envolve juntar essas partes novamente, de forma significativa, para obter-se o sistema desejado. Ao processo de juntar as partes, dá-se o nome de composição. Há então três questões a serem definidas, para que se possa fazer a composição: a correspondência, a semântica composicional, e o tempo de ligação. A correspondência é o modo que descreve quais elementos serão compostos entre si. A semântica composicional é o que deve acontecer com os elementos que correspondem; e o tempo de ligação diz respeito ao momento em que a correspondência tem efeito.
A forma de composição das partes é o que realmente distingue a modelagem orientada a aspectos. Em linguagens procedurais ou orientadas a objetos (OO), a composição é feita através de chamadas de procedimentos ou métodos, ou seja, uma parte usa a funcionalidade de outra, chamando um método. Em POA, não há chamadas explícitas de métodos entre partes. Ao invés disso, especifica-se, em uma parte separada, como ela deve reagir a eventos que acontecem em outra parte, estratégia que propicia a redução do acoplamento entre si.
Dentre os benefícios da POA, podem ser citados:
1. Menor responsabilidade em cada parte: como os interesses entrecortantes são separados em seus próprios módulos, as partes que lidam com a lógica de
negócios não ficam poluídas com as que lidam com interesses periféricos;
2. Melhor modularização: como os módulos em POA não são chamados diretamente, há uma redução no nível de acoplamento;
3. Evolução facilitada: novos aspectos podem ser acrescentados, facilmente, sem necessidade de alterar o código existente;e,
4. Maiores possibilidades de reutilização: como o código não mistura interesses, aumentam as possibilidades de reutilização de módulos em sistemas diferentes. Os termos desenvolvimento estruturado e orientação a objetos (OO) dizem respeito à modularidade do sistema. São formas distintas de se dividir um sistema em partes. A divisão em partes é importante para reduzir a complexidade.
É muito difícil, para o ser humano, compreender um sistema de grande porte, se este for monolítico, sem fronteiras claras que definam suas funções. Já o termo separação de interesses foi cunhado por Edsger Dijkstra, em 1974, para denotar o princípio que guia a divisão em partes: todo sistema lida com diferentes interesses, sejam eles dados, operações, ou outros requisitos do sistema. O ideal é que a parte dedicada a satisfazer um determinado interesse fosse concentrada em uma única localidade física, separada de outros interesses, para poder ser estudada e compreendida com facilidade.
O desenvolvimento estruturado realizou a separação de interesses, orientando-se através das diferentes funcionalidades oferecidas pelo software. Cada função é implementada em um único módulo, ou procedimento. Daí surgiram conceitos que ajudam a manter a separação de interesses, como o baixo acoplamento e a alta coesão. Já a orientação a objetos é uma forma de sanar deficiências do desenvolvimento estruturado. Apesar de interesses relativos a funcionalidades ficarem separados, interesses relativos a dados ficavam distribuídos em diversos módulos. O paradigma OO definiu que a separação deveria acontecer em duas dimensões, primeiro dividido em termos de dados e, depois, em termos das funções que utilizam cada tipo de dados.
O objetivo da proposta de uso do AOSD é encapsular interesses entrecortantes em módulos fisicamente separados. Pensando em termos abstratos, AOSD introduz uma terceira dimensão de decomposição. Além de decompor o sistema em objetos (dados) e métodos (funções), decompõe-se cada objeto e função, de acordo com o interesse, a que serve, agrupando-se cada interesse em um módulo distinto, ou aspecto.
No cenário analisado, os rios são intermitentes, apresentando como característica marcante uma longa estação de vazão nula subseqüente a uma estação úmida concentrada de 3 a
6 meses. Essas características fazem com que os deflúvios anuais sejam serialmente independentes. Tal observação já indicaria uma nova forma de analisar a região, além é claro, do viés de interesses políticos, visto que a região cobre uma vasta área de operação, mais entrecortantes. Outrossim, dada à extensa região de interesses, há que se reforçar a idéia de utilização de ferramentas SIG e SAD para melhor representar os processos envolvidos, dando- lhes maior visualidade, e compartilhar as informações por diferentes tomadores de decisões. O SIG modela a morfologia do mundo real, através dos dados espaciais, capturando sua dinâmica através dos atributos; o SAD os quantifica, qualifica e analisa, com foco em uma determinada meta a ser alcançada.
As estratégias de acoplamento são definidas conforme Quadro 6.
Neste estudo, em que se fez uso de ferramentas computacionais no paradigma de
software livre, descrito posteriormente, houve total integração de vários modelos, considerada
essa uma estratégia de acoplamento de classe plena (Full); além do que, possibilita, ao pesquisador, fazer uso de softwares completos ou parte deles, com total liberdade, fomentando críticas e melhoramentos continuados.
Quadro 6: Estratégias de acoplamento de modelos (NETO & RODRIGUES, 2000)
Classe Modelo Dados Controle Característica
Fraca (loose) IND T IND Sem integração física e lógica Próxima (close) IND T INC Sem integração física e lógica Rígida (Tight) IND C INC Transferência direta de dados
Plena (Full) INC C INC Total integração