3.3 Arquitetura de Software
3.4.1 Abordagens de Componentes Aspectuais
Os componentes são úteis não apenas para a modelagem de composição comportamental, mas também são bons construtores para expressar aspectos. Esse novo tipo de componente é cha- mado de componente aspectual e expressa cada aspecto separadamente em uma estrutura modular
(Lieberherr et al., 1999). O componente aspectual representa um interesse transversal e é um com- ponente normal que fornece como serviço o código de um adendo que representa o comportamento a ser combinado com um conjunto de componentes normais (Pessemier et al., 2006).
Pessemier et al. (2006) propõem uma abordagem simétrica, considerando aspectos como com- ponentes. Eles afirmam melhorar a abordagem de componentes, fornecendo suporte à POA, e melhorar a abordagem de aspectos, aplicando conceitos de DSBC à POA. O modelo é chamado de FAC (do inglês Fractal Aspect Component) e é uma extensão de um modelo de componente chamado Fractal (Bruneton et al., 2004). A proposta conta com três noções principais: compo- nente aspectual, domínio de aspecto (aspectual domain) e ligação de aspecto (aspectual binding). O componente aspectual é o encapsulamento do código de um adendo, representado por um com- ponente normal Fractal. O domínio de um aspecto é a retificação dos componentes selecionados pelo componente aspectual. A ligação de aspecto é o relacionamento implícito entre um compo- nente aspectual e o componente em que ele é aplicado. Esses conceitos são mapeados no modelo de componentes Fractal. Ainda estão sendo feitos estudos para considerar o nível arquitetural dos aspectos no DSBC.
Clemente e Hernández (2003) apresentam um processo chamado de ACBSE (do inglês Aspect Component Based Software Engineering) em que a programação orientada a aspectos é utilizada para descrever e implementar as dependências entre componentes, durante as fases de Projeto e Especificação, Implementação, Empacotamento, Montagem e Implantação dos componentes. Para chegar a esse processo, eles focaram no estudo do modelo CCM (Corba Component Model) e na sua extensão orientada a aspecto, o AspectCCM (Clemente et al., 2002b). Para desenvolver o AspectCCM, utilizaram UML para a modelagem e separaram a definição de dependências entre componentes (intrínseca e não-intrínseca) durante a fase de Projeto e Especificação usando técnicas de POA (Clemente et al., 2002a). Além disso, são usados descritores XML para descrever as propriedades dos componentes do sistema na fase de empacotamento e o código de interconexão é gerado pela tradução do XML.
Eler (2006) propõe um método para o Desenvolvimento de Software Baseado em Componen- tes e Aspectos (DSBC/A). O método é uma adaptação do método UML Components (Cheesman e Daniels, 2001) com modificações e inclusões de algumas atividades para considerar aspectos no DSBC. No método de DSBC/A, os componentes são considerados como caixas-pretas e a intera- ção entre os componentes e os aspectos é projetada com o objetivo de preservar o encapsulamento dos componentes, permitindo que os aspectos apenas operem nas interfaces dos componentes. O método proposto tem o objetivo de, a partir do documento de requisitos de um sistema, produzir uma arquitetura de componentes que contenha componentes-base (normais) e componentes trans- versais (aspectuais), bem como suas especificações. Os componentes transversais possuem o com- portamento de um aspecto, tendo a capacidade de entrecortar outros componentes nas operações de suas interfaces e adicionar ou substituir algum comportamento.
3.5
Considerações Finais
É importante utilizar os conceitos e os mecanismos da programação orientada a aspectos para separar e encapsular possíveis interesses transversais, pois assim podem ser obtidos sistemas mais fáceis de entender, implementar, integrar, reusar e manter. Como forma de modularizar os inte- resses transversais existentes em arquiteturas de software e nos componentes do sistema, vários autores propuseram linguagens de descrição de arquiteturas orientadas a aspectos e métodos de desenvolvimento baseado em componentes e em aspectos. Logo, é importante em uma arquitetura baseada em componentes também considerar aspectos. Havendo uma linha de produtos de soft- ware, é interessante usar aspectos não só para tratar requisitos não-funcionais, mas também para representar as variabilidades da linha.
Ao desenvolver uma linha de produtos de software com arquitetura baseada em componentes, as caractertísticas comuns e as variabilidades são projetadas por meio de componentes. Eles são adicionados ou substituídos para obter aplicações-referência. Os aspectos devem ser usados para representar requisitos não-funcionais da linha, separando interessses transversais. Além disso, é interessante usar aspectos para auxiliar a representar as variabilidades de uma linha sem quebrar o encapsulamento fornecido pela arquitetura baseada em componentes, ou seja, entrecortando ape- nas as operações das interfaces dos componentes. Essas variabilidades podem representar tanto requisitos funcionais quanto não-funcionais.
As arquiteturas são importantes para LPSs e uma forma de definir a linguagem de descrição de domínio que possua uma arquitetura baseada em componentes seria usando os conceitos de ADLs. Tratando-se de uma LPS, geralmente a definição de domínio é feita em termos de características, portanto, a linguagem de descrição de domínio pode usar os conceitos de ADLs para mostrar como devem ser associadas as características da LPS para obter a arquitetura baseada em componentes.
4
Desenvolvimento de Linhas de
Produtos de Software
4.1
Considerações Iniciais
Os processos de Engenharia de Domínio e de Aplicação devem ser conduzidos para desenvol- ver uma LPS e produzir suas aplicações. Este capítulo foca o processo de Engenharia de Domínio para desenvolver uma LPS. Alguns princípios foram adotados para o processo de desenvolvimento da LPS proposta e tomou-se como base o método PLUS (Gomaa, 2004), que foi descrito na Se- ção 2.3.1 do Capítulo 2, para desenvolver a LPS. Conforme o que foi discutido nessa seção, Gomaa (2004) define um processo de desenvolvimento específico para o método PLUS, chamado ESPLEP. No contexto desta dissertação decidiu-se por adaptar esse processo de acordo com necessidades encontradas. As adaptações realizadas são apresentadas e o processo resultante é descrito.
O capítulo inicia com a definição de alguns princípios que foram adotados para o desenvolvi- mento da LPS na Seção 4.2. Em seguida, na Seção 4.3, são apresentadas as adaptações propostas ao processo ESPLEP. Essas adaptações foram implementadas na LPS como é detalhado na Se- ção 4.4. Essa seção é dividida na engenharia de domínio e de aplicação da Linha de Produtos de Software de Bilhetes Eletrônicos e Transporte municipal (LPS-BET). Por sua vez, a engenharia de domínio é dividida nos ciclos incrementais de desenvolvimento da LPS-BET, mostrando alguns dos seus artefatos. Posteriormente, na Seção 4.5 são fornecidas informações específicas referentes à construção da LPS-BET. Finalmente, na Seção 4.6 são apresentadas as considerações finais do processo de desenvolvimento da LPS-BET.