Baseado em Componentes
Ana Paula Blois1, 2, Karin Becker2, Cláudia Werner1 1
COPPE/UFRJ, Universidade Federal do Rio de Janeiro, Brasil Caixa Postal 68511 – CEP 21945-970 Rio de Janeiro, Brasil
2
FACIN/PUCRS, Universidade Católica do Rio Grande do Sul, Brasil
Av. Ipiranga, 6681 – Prédio 30 – Bloco 4 CEP 90619-900 Porto Alegre – RS – Brasil {anablois, werner}@cos.ufrj.br, {anapaula, kbecker}@inf.pucrs.br
Abstract. This paper describes a Domain Engineering (DE) process focused on component-based architectural design. Its goal is to improve the support offered by DE Methods, on the design phase, using components technology to generate domain architectures. The process was modeled in Odyssey Environment, which aims to manage artifacts and domain models.
Resumo. Este artigo descreve um processo de Engenharia de Domínio (ED) com foco no projeto arquitetural baseado em componentes. O objetivo deste processo é melhorar o suporte oferecido pelos métodos de ED existentes na sua fase de projeto de domínio, utilizando a tecnologia de componentes para geração de arquiteturas de domínio. Este processo foi modelado no ambiente Odyssey que visa a gerência de artefatos e modelos de domínio.
Palavras-chave: Engenharia de Domínio, Desenvolvimento Baseado em Componentes, Arquitetura de Componentes.
1. Introdução
Existem muitos domínios que possuem características propagáveis em quase todas as suas aplicações, podendo fazer uso dos mesmos processos e artefatos, o que promove a reutilização dos conceitos e funcionalidades em comum. Em Engenharia de Software existe uma área de pesquisa que se preocupa com esta questão, denominada Engenharia de Domínio (ED) [15]. O objetivo da ED é possibilitar que características comuns e variáveis possam ser identificadas e modeladas com base num processo previamente definido. Os artefatos gerados pela ED (e.g. modelos de domínio, arquiteturas de componentes, casos de uso, dentre outros) podem ser instanciados para uma aplicação específica do domínio. A esta instanciação se dá o nome de Engenharia de Aplicação (EA) [12]. A ED prove um conjunto de artefatos “para” reutilização, enquanto que a EA constrói aplicações “com” base na reutilização de artefatos providos pela ED.
Vários métodos de ED têm sido propostos na literatura, dentre eles, FODA (Feature Oriented Domain Analysis) [9], FORM (Feature Oriented Reuse Method) [10] e RSEB (Reuse-Driven Software Engineering Business) [8]. Estes métodos apresentam sistemáticas para modelagem de artefatos na ED, visando a reutilização na EA. Embora existam diferenças entre os métodos, eles são semelhantes quanto as fases envolvidas do processo (e.g. identificação e escopo do domínio, análise, projeto e implementação do domínio). Muitos deles prevêem atividades em todas as fases, mas em geral apresentam maiores contribuições na fase de análise de domínio. No entanto, a etapa de projeto é muito importante, pois é a partir de seus artefatos e modelos que se gera uma arquitetura do domínio modelado.
Se por um lado a ED visa identificar aspectos variáveis e invariáveis de um domínio para sua reutilização, por outro o Desenvolvimento Baseado em Componentes (DBC) propõe soluções
reutilizáveis para o processo de desenvolvimento de software, disponibilizando aos usuários os aspectos variáveis e invariáveis de um componente através de sua interface [4].
Métodos adequados devem ser utilizados para o desenvolvimento de aplicações baseadas em componentes. UML Components [5], Catalysis [6] e Kobra [1] são métodos que têm se destacado para apoio ao DBC, e sobretudo em arquiteturas de software baseadas em componentes. Embora esses métodos visem a reutilização, as experiências com seu uso mostram que eles, no máximo, apóiam a geração de artefatos, mas não necessariamente garantem sua reutilização.
Uma alternativa seria o uso de DBC no contexto de uma abordagem de ED. Através da ED, projetistas podem disponibilizar aos reutilizadores os artefatos das diferentes fases (e.g. casos de uso e features1 na análise) e, em especial, componentes da fase de projeto para a construção de uma arquitetura de componentes do domínio.
Neste sentido, Braga [3] propôs um processo – Odyssey–ED - com o propósito de unir os aspectos de reutilização e entendimento do domínio, providos pelos métodos de ED, e o detalhamento do desenvolvimento de componentes, provido pelos métodos de DBC. Entretanto, o conjunto de atividades, no que tange especificamente ao projeto de domínio com o uso de DBC, não foram detalhadas a contento. Em Odyssey-ED, a proposta de projeto arquitetural de componentes não permite uma especificação detalhada dos componentes e interfaces, da arquitetura interna de cada componente, e da forma como componentes e/ou classes se comunicam entre si e com componentes externos que fazem parte do domínio.
Este artigo apresenta um processo denominado CBD-Arch-DE (Component-Based Development – Architecture – Domain Engineering) [2] com o objetivo de minimizar as limitações dos métodos da ED, principalmente com relação a ênfase oferecida as atividades que compreendem as fases iniciais do processo, e também minimizar as limitações dos métodos de DBC, mais especificamente pela ênfase no suporte à especificação de componentes. Para a especificação de componentes o processo orienta o projetista do domínio no uso de estilos arquiteturais para suporte a sua criação, padrões de projeto e arquiteturais para a especificação interna do componente e técnicas de apoio ao agrupamento de componentes de acordo com as suas funcionalidades no contexto do domínio modelado (e.g. técnicas de adaptação de componentes, métricas de acoplamento). Neste sentido este processo visa detalhar as atividades referentes às questões arquiteturais no projeto de ED, complementando o processo descrito em Braga [3], com o objetivo de oferecer um conjunto de artefatos e modelos que auxiliem na descrição de uma arquitetura de referência do domínio[11].
O restante do artigo está organizado da seguinte maneira: a Seção 2 descreve o processo CBD-Arch-DE; a Seção 3 discute o suporte oferecido ao processo no ambiente Odyssey e, por último, na Seção 4, as considerações finais a respeito do trabalho.
2. Processo CBD-Arch-DE
CBD-Arch-DE supõe o uso do ambiente Odyssey [14], para a gerência de artefatos e modelos de domínio gerados, e da ferramenta Charon [13] para a modelagem, gerência e instanciação do processo, disponível neste ambiente. O diagrama para modelagem de processos
1
Features representam as capacidades/características do domínio, obtidas através de especialistas, usuários e sistemas já existentes [9].
desta ferramenta é semelhante ao diagrama de atividades da UML. A Charon permite não só a modelagem das atividades do CBD-Arch-DE, mas sobretudo o acompanhamento e instanciação do processo.
A Figura 1 mostra as atividades da análise de domínio no CBD-Arch-DE, modeladas na Charon. O processo inicia com a atividade de planejamento do domínio, provendo um conjunto de critérios que permitem ao gerente do domínio (especialista, engenheiro) fazer estimativas de recursos a serem utilizados, custos e cronograma.
Conforme apresenta a Figura 1, a fase Análise de Domínio começa pela identificação dos contextos que representam os principais conceitos do domínio em termos de sub-áreas existentes. A atividade posterior é a identificação das features, ou seja, as capacidades/características do domínio, as quais podem estar relacionadas entre si (e.g. associação, composição), e que são representadas através de modelos de features. Tais abstrações são obtidas através de especialistas, usuários e sistemas já existentes. No modelo podem ser representadas features funcionais, conceituais, como proposto em Miler [12], e features relativas ao ambiente operacional, tecnologias do domínio e técnicas implementacionais, conforme propõe Kang et al.[10]. As features do domínio estão agrupadas em diferentes camadas, de acordo com o tipo de característica que está representando. Independente do tipo de camada, uma feature deve representar aspectos variáveis ou invariáveis no domínio, os quais serão considerados pelo projetista durante a criação dos demais artefatos do domínio nos seus diferentes níveis de abstração (e.g. tipo de negócio, componente). Neste sentido, a característica de variabilidade é representada não só nas features, mas também em todos os outros artefatos do domínio que estão relacionados a elas (e.g. representar variabilidade em casos de uso e componentes que correspondem a uma feature variável do domínio).
Figura 1: Análise de Domínio no Processo CBD-Arch-DE
Após a identificação das features, duas atividades podem ocorrer em paralelo (representado na Figura 1 por uma barra vertical) e de forma complementar no CBD-Arch-DE: i) definição dos tipos de negócio, ou seja, os artefatos de análise que representam os aspectos estáticos do domínio, geralmente candidatos a persistência no contexto da atividade de projeto, e ii) definição dos casos de uso associados às features. Estes casos de uso podem estar relacionados a várias features, e também a um conjunto de tipos de negócio. Casos de uso podem descrever situações de criação, consulta e outras operações sobre tipos de negócio e seus atributos. A Análise de Domínio é concluída somente quando não existirem mais tipos de negócio e casos de uso a serem criados para as features do domínio (Figura 1).
Existem outros artefatos ligados a feature ainda não criados? Identificação de Features não Identificação de contextos (domínios e subdomínios) sim sim ? não
Identificação de Casos de Uso Identificação de Tipos de Negócio
?
Existem outros artefatos ligados a feature ainda não criados?
Domínios e sub-domínios identificados?
sim
?
O Projeto de Domínio envolve a criação, composição e geração de arquitetura de componentes e suas interfaces, conforme ilustra a Figura 2. A criação de componentes do domínio pode ser efetuada a partir do uso de estilos arquiteturais. Estes estilos utilizam os tipos de negócio e casos de uso para a criação de componentes do domínio e de componentes de processo, respectivamente [4][17]. Os componentes de processo do domínio compreendem um ou mais diagramas de seqüência os quais representam a realização de seus respectivos casos de uso, que neste contexto descrevem as interações entre tipos de negócio do domínio modelado. A proposta de geração de componentes de Teixeira [17] pode ser aplicada neste contexto. Independente do processo adotado, internamente deve ser especificado o conjunto de classes que os implementam, seus métodos, atributos e relacionamentos. Este modelo de classes, gerado para cada componente e suas interfaces, pode fazer uso de padrões de projeto [7] e arquiteturais para a estruturação das classes.
Figura 2: Projeto de Domínio no Processo CBD-Arch-DE
Após a criação de componentes e interfaces, deve-se iniciar a atividade de agrupamento de componentes. Esta atividade visa sistematizar o grande volume de componentes possivelmente gerado na atividade anterior, agrupando-os por critérios de acoplamento e coesão. Tendo em vista o alto grau de acoplamento e coesão existente num conjunto de componentes, com classes ligadas a classes de outros componentes, sugere-se que uma avaliação sobre a possibilidade de agrupamento seja conduzida pelo projetista. As interfaces deverão se comunicar para coordenar as atividades atribuídas a cada componente, tanto aquele que representa um agrupamento, quanto um componente isoladamente. Esta comunicação de interfaces é aplicável tanto para aquelas fornecidas pelo componente, quanto para as requeridas.
A atividade de agrupamento de componentes sugere uma estrutura inicial da arquitetura do domínio em função da troca de mensagens entre as interfaces dos componentes. Na atividade de montagem da arquitetura o projetista pode considerar o uso de estilos arquiteturais com o intuito de melhor organizar a arquitetura em função dos requisitos funcionais e também dos não funcionais como desempenho, concorrência, etc.
A última atividade do processo é a implementação do domínio. Embora este não seja o foco do processo, estudos preliminares estão sendo realizados para efetuar um mapeamento dos componentes do domínio para uma tecnologia de componentes específica (e.g. EJB).
3. Apoio do ambiente Odyssey ao Processo CBD-Arch-DE
Conforme relatado anteriormente, o ambiente Odyssey apoia, em parte, a gerência do processo CBD-Arch-DE através da ferramenta Charon. Grande parte das atividades previstas no processo, principalmente aquelas referentes a Análise do Domínio (e.g. geração de artefatos, modelo de features, tipos de negócio e casos de uso), são apoiadas pelo Odyssey. No entanto, as atividades do Projeto de Domínio devem ser aprimoradas, dentre elas: 1) Suporte a geração de componentes, 2) Suporte ao agrupamento de componentes, e 3) Suporte a geração da arquitetura de domínio.
É possível montar a
arquitetura de componentes? ? É possível agrupar componentes?
Montagem da Arquitetura
Agrupamento de Componentes não
Criação de Componentes e Interfaces
sim sim
não ?
Atualmente, o suporte oferecido a geração de componentes se limita as features conceituais do domínio. São utilizados estilos baseados em tipos e instâncias para a geração de componentes de negócio a partir destas features do domínio [17]. Embora estes estilos arquiteturais sejam empregados com maior ênfase aos componentes de negócio, não existem restrições em adotá-los para os demais componentes que representam a especificação das features referentes a infra-estrutura tecnológica do domínio. Neste sentido, tal suporte está sendo incorporado ao Odyssey, provendo apoio a geração de componentes para todas as categorias de features do domínio.
O Odyssey atualmente suporta o agrupamento de tipos de negócio para a geração de gerentes de componentes, baseado em relações como agregação, composição, etc, com seus respectivos graus de relevância [17]. No contexto do processo CBD-Arch-DE, existe a atividade de agrupamento de componentes, onde um componente pode agrupar os demais a ele relacionados, ou um novo componente ser criado, com suas interfaces requeridas e fornecidas, visando a representação semântica deste agrupamento. Como tal suporte ainda não é oferecido, estão sendo estudadas técnicas (e.g. métricas de acoplamento de componentes, técnicas de adaptação de componentes, etc) que possibilitem apoiar não só a decisão do projetista nesta atividade de agrupamento, mas também a própria automatização desta atividade.
Na atual versão do Odyssey, a construção de uma arquitetura de componentes ocorre a partir da ligação destes através de suas interfaces, sem um suporte específico a um estilo arquitetural que defina a arquitetura do domínio. Em nossa proposta, assumimos a possibilidade de estruturação da arquitetura de domínio a partir de estilos arquiteturais propostos na literatura [16] (e.g. pipes and filters, camadas). Até o momento o uso do estilo arquitetural em camadas [4] tem se tornado mais evidente, pois as features do domínio também estão representadas desta forma e, em geral, as camadas do estilo correspondem as camadas de features (e.g. features da camada de tecnologia do domínio correspondem a um ou mais componentes da camada de suporte do estilo arquitetural). Apesar destas evidências preliminares, outros estilos devem ser estudados para avaliar a sua adequação em domínios distintos.
4. Considerações Finais
Este artigo descreveu um processo de ED com foco nas atividades de projeto arquitetural baseado em componentes. O ambiente Odyssey permite, orientado pelo CBD-Arch-DE, definir os artefatos de domínio, baseado nos seus requisitos, contemplando a fase de análise de domínio e parte dos artefatos e modelos da fase de projeto. A Seção 3 descreveu brevemente os passos do processo CBD-Arch-DE. Um conjunto de orientações para o projetista será construído com o intuito de auxiliá-lo na construção de modelos de domínio a partir deste processo, orientando a interação dos requisitos do domínio e dos demais artefatos de mais alto nível de abstração até a obtenção da arquitetura de componentes.
Está em andamento um estudo de caso envolvendo a utilização do processo no domínio de Aprendizagem Cooperativa. Neste estudo se observou que o apoio oferecido pelo Odyssey na fase de análise foi satisfatório, permitindo a geração de artefatos e modelos para atender os requisitos funcionais do domínio. Já os resultados obtidos no projeto não tem sido plenamente atendidos. Não existe suporte a geração de componentes para todos os requisitos do domínio (somente para aqueles especificados como feature conceitual), ao agrupamento e a construção de arquiteturas de componentes. Conforme relatado na Seção 3, a sistemática para a geração de componentes referentes as demais features do domínio (e.g. funcionais, ambiente operacional, tecnologias do domínio e técnicas de implementaçao) é semelhante àquela adotada para a
geração de componentes de negócio. As atividades de agrupamento e de construção de arquiteturas de componentes se encontram em fase de pesquisa.
Tendo em vista os problemas detectados no Odyssey para apoio ao projeto de domínio, estamos trabalhando no sentido de prover apoio ferramental para: a) complementar o suporte para a geração de componentes do domínio; b) suporte ao agrupamento de componentes do domínio. Este agrupamento visa melhorar a arquitetura gerada até o momento, a qual não permite que componentes sejam estruturados através de estilos arquiteturais (e.g. camadas, clusters); c) suporte ao mapeamento dos componentes gerados no Odyssey para uma tecnologia de componentes específica (e.g. .NET, EJB), e d) uso das funcionalidades adicionadas no Odyssey no domínio de ensino colaborativo. Com este ferramental construído e explorado através do processo CBD-Arch-DE, se espera obter maior apoio a atividade de projeto arquitetural baseado em componentes, a qual não é enfatizada nos métodos de ED e DBC.
Referências:
[1]Atkinson, C. et al. (2002) “Component-based Product Line Engineering with UML”. Addison-Wesley, 2002. 505p.
[2]Blois, A. (2004) “Uma proposta de projeto arquitetural baseado em componentes no contexto de Engenharia de Domínio”. Exame de Qualificação, COPPE/UFRJ, Rio de Janeiro, Brasil, janeiro, 2004.
[3]Braga, R. (2000) “Busca e Recuperação de Componentes em Ambientes de Reutilização de Software”. Tese de Doutorado. COPPE Sistemas, 2000, 265p.
[4]Brown, A. (2000) “Large-Scale Component-Base Development”. Prentice Hall. 2000. 286p. [5]Cheesman, J. e Daniels, J. (2001) “UML Components: A simple process for specifying
component-based software”. Addison-Wesley, 208p.
[6]D'Souza, D e Wills, A. (1999) “Objects, components and frameworks with UML: the catalysis approach”. Addison-Wesley, 1999. 785p.
[7]Gamma, E, et al. (1994) “Design Patterns: Elements of Reusable Object-Oriented Software”. Reading, MA: Addison-Wesley, 1994.
[8]Griss, M., et al. (1998) “Integrating Feature Modeling with the RSEB”. Software Reuse, 1998. Proceedings. Fifth International Conference on, 2-5 June 1998. 76 –85p.
[9]Kang, K. et al. (1993). “Feature-Oriented Domain Analysis (FODA) Feasibility Study” (CMU/SEI-90-TR-21). Pittsburg, PA, Software Engineering Institute, Carnegie Mellon University, Nov 1993.
[10]Kang, K. et al. (2002) “Feature-Oriented Product Line Engineering”. IEEE Software, July, 58-65p, 2002.
[11]Liu, L e Yu, E., (2001) “From Requirements to Architectural Design – Using Goals and Scenarios”. First International Workshop From Software Requirements to Architectures. In: 23rd International Conference on Software Engineering. May 14, 2001, Toronto, Canada. [12]Miler, N., (2000) “A Engenharia de Aplicações no Contexto da Reutilização baseada em
Modelos de Domínio”. Tese de M.Sc., COPPE/UFRJ, Rio de Janeiro, Brasil, julho 2000. [13]Murta, L., (2002) “Charon: uma máquina de processo extensível baseada em agentes
inteligentes”. Tese de M.Sc., COPPE/UFRJ, Rio de Janeiro, Brasil, março, 2002. [14]Odyssey SDE (2004) Disponível em: http://www.cos.ufrj.br/~odyssey.
[15]SEI. Software Engineering Institute. (2003) Disponível em: http://www.sei.cmu.edu/domain-engineering/domain_eng.html.
[16]Shaw, M. e Garlan, D. (1996) “Software Architecture: perspectives on an emerging discipline”. 1 ed., Nova Jersey, Prentice-Hall. 1996.
[17]Teixeira, H. (2003) “Geração de Componentes de Negócio a partir de Modelos de Análise”. Tese de M.Sc., COPPE/UFRJ, Rio de Janeiro, Brasil, 2003.
