1 Engenharia de Domínio no Suporte ao Aumento de Flexibilidade nos Sistemas de Software Alexandre Bragança e Ricardo J. Machado Resumo — A flexibilidade é uma das principais qualidades que são requeridas actualmente às aplicações. As técnicas de implementação de variabilidade fornecem meios para atingir essa flexibilidade. A indústria de software adopta correntemente diversas técnicas de implementação de variabilidade. Estas técnicas fornecem diversos graus de variabilidade. As técnicas que fornecem níveis mais elevados de variabilidade também implicam processos mais complexos de engenharia. Este artigo aborda esta problemática. É proposto um método simples para medir o grau de variabilidade. Mostra-se também como a adopção de métodos de engenharia do domínio, aplicados em paralelo com o método de engenharia da aplicação, pode fornecer um suporte adequado para gerir a complexidade resultante da adopção de algumas técnicas de implementação de variabilidade. Palavras-chave — Engenharia de Domínio, Extensibilidade, Flexibilidade, Variabilidade. ——————————  —————————— 1 INTRODUÇÃO A flexibilidade de comportamento é actualmente uma característica necessária em sistemas de software complexos. Esta flexibilidade pode ser conseguida vados para as aplicações. Apesar de tais promessas, para se atingirem as vantagens inerentes às técnicas de implemen- tação de variabilidade, a sua simples adopção não é sufi- introduzindo pontos de variabilidade no software. Estes ciente. pontos de variabilidade podem ser introduzidos em diver- De facto, a adopção de técnicas de implementação de sas fases do ciclo de desenvolvimento do software e podem variabilidade também eleva o nível da complexidade das adoptar diversas técnicas para implementar a variabilidade. aplicações e, desta forma, pode aumentar a dificuldade do Com o objectivo de atingir níveis mais elevados de flexibi- desenvolvimento e da manutenção. Neste artigo, na secção lidade, a indústria de software tem vindo a adoptar técnicas 2 e 3, apresenta-se uma visão geral sobre as técnicas de de implementação de variabilidade suportadas em tempo implementação de variabilidade. Com base nesta análise de execução das aplicações. Os padrões da indústria para geral, na secção 4 discute-se como o grau de variabilidade é componentes de software como o COM, XPCOM, Java2, influenciado pela adopção das técnicas mais comuns de CORBA e o .Net suportam este tipo de implementação de implementação de variabilidade nas diversas fases do pro- variabilidade. Estes permitem que diversas implementações cesso de desenvolvimento. Apresentam-se também razões possam ser utilizadas para uma determinada interface fun- para o facto da adopção de técnicas de implementação de cional. Assim, diversos componentes de software podem variabilidade (principalmente aquelas que são suportadas ser desenvolvidos para uma determinada interface funcio- em tempo de execução) no processo de desenvolvimento de nal. Estes diversos componentes podem ser instalados e software poder falhar. Na secção 5 apresenta-se uma abor- dinamicamente utilizados nos pontos de variabilidade da dagem centrada na adopção de métodos de desenvolvi- aplicação. mento de software, baseados em engenharia de domínio, As plataformas de software como o Java2 e o .Net come- como forma de abordar o desenvolvimento de aplicações çam também a suportar a geração em tempo de execução complexas com elevado grau de variabilidade. A secção 6 de componentes de software e a sua instalação. Exemplos conclui o artigo. dessas novas capacidades das plataformas de software são os mecanismos de introspecção e a capacidade de compila- ção de código em tempo de execução. Algumas aplicações e 2 TÉCNICAS DE IMPLEMENTAÇÃO DE VARIABILIDADE sistemas, como o JBoss, aplicam já estas técnicas [1]. Um dos conceitos mais importantes quando se aborda a A adopção de técnicas de implementação de variabilida- variabilidade no software, em particular no processo de de, particularmente técnicas suportadas em tempo de exe- desenvolvimento, corresponde ao momento em que se cução, promete níveis de flexibilidade e evolução mais ele- selecciona uma das variantes do ponto de variabilidade, ou seja, o momento em que o ponto de variabilidade é fechado ———————————————— (momento usualmente designado por binding time). Esta • Alexandre Bragança é investigador na I2S Informática – Sistemas e Servi- acção significa, normalmente, que a partir desse momento o ços, S.A. e docente do Instituto Superior de Engenharia do Porto. E-mail: software executará a opção seleccionada para o ponto de alexandre.braganca@i2s.pt; alex@dei.isep.ipp.pt. • Ricardo J. Machado é Prof. Auxiliar do Departamento de Sistemas de variabilidade, ou seja, esse ‘local’ do software deixa de ser Informação da Universidade do Minho. E-mail: rmac@dsi.uminho.pt. um ponto de variabilidade. É possível seleccionar uma opção de um ponto de variabilidade em diversas fases do 2 QUATIC’2004 PROCEEDINGS processo de desenvolvimento: derivação da arquitectura do Jak = Sm ( Templ ( Java ) ) produto (aplicação), compilação, edição de ligações (linking) Esta expressão está a definir um dialecto de Java que e execução. Este artigo baseia-se nas últimas três fases por- amplia a linguagem Java com suporte para máquinas de que estas dizem respeito a técnicas que podem ser utiliza- estados e templates. Cada característica é representada pelos das nas linguagens de programação e ambientes de desen- tipos de dados de uma camada. Cada camada contribui volvimento mais comuns. Não obstante, é possível conce- para a composição final do componente com classes, atribu- ber outros momentos de binding como, por exemplo, o tem- tos e métodos que implementam a característica correspon- po de depuração. dente. Empilhando as diversas camadas podem-se combi- Relativamente às técnicas de implementação de variabi- nar as características necessárias ao componente. lidade, é muito útil fazer a distinção entre técnicas em que o A principal limitação destes mecanismos de composição binding time se realiza antes do momento da distribuição de código semelhantes ao GenVoca, no que respeita a das técnicas nas quais o binding time é após a distribuição implementação de pontos de variabilidade, é que eles do software. Esta distinção é muito importante porque dependem da selecção e composição dos componentes em define uma linha que separe o ciclo de vida tradicional de fases do processo de desenvolvimento que precedem a dis- desenvolvimento do software onde é possível mudar quase tribuição do software. A secção 4 descreve como o grau de tudo da instalação e execução do software no cliente e, no variabilidade do software pode ser mais elevado quando os qual a mudança e a variabilidade são quase impossíveis de pontos de variabilidade são fechados em fases posteriores à introduzir. As técnicas de implementação de variabilidade distribuição do software. com tempos de binding antes da distribuição, usadas vul- garmente pela indústria, têm por base [2]: - Pré-processamento de código de fonte (por exemplo atra- 3 TÉCNICAS DE SUPORTE À VARIABILIDADE EM vés de directivas do pré-processador de C); TEMPO DE EXECUÇÃO - Directivas do editor de ligações (por exemplo ligando Uma técnica muito frequente de implementação de variabi- objectos e/ou bibliotecas diversas); lidade em tempo de execução, que é utilizada por quase - Parâmetros (por exemplo templates do C++); todas as aplicações, é a execução condicional de código - Herança; baseada no valor de uma variável ou expressão. Neste caso, - Composição de código. todos as opções ou variantes do ponto de variabilidade De acordo com a nossa experiência, as técnicas de com- estão incluídas na aplicação e não é possível aumentar o posição de código não são usadas extensivamente na indús- conjunto de variantes do ponto de variabilidade após a tria. A maioria destas técnicas são resultado da investigação construção (compilação) da aplicação. Outras técnicas, recente desenvolvida nos meios académicos e, como tal, na como o uso de apontadores para funções ou o uso do grande maioria dos casos, estas técnicas ainda não são padrão de desenho template method [9], são muito similares adoptadas pela indústria. Exemplos destas técnicas são a em efeito, pois todas as variantes possíveis são definidas programação orientada pelos aspectos [3], a programação em tempo de compilação. Uma forma de alargar as varian- orientada pelos sujeitos [4], a programação generativa [5] e tes de um ponto de variabilidade, no contexto das técnicas o GenVoca [6]. referenciadas, consiste em substituir o módulo com o ponto As técnicas de composição de código são baseadas na de variabilidade por um módulo novo e compatível que suposição que o modelo de programação orientado pelos contenha as novas variantes. Esta técnica é usada normal- objectos tem limitações relativamente à composição de clas- mente quando uma empresa necessita de corrigir proble- ses, tal como o suporte para assuntos transversais (crosscut- mas com um módulo de uma aplicação. Para tal, substitui o ting concerns) [7]. No GenVoca, por exemplo, é possível binário do módulo por uma versão nova que corrija o pro- compor o código de diversas classes como uma unidade ou blema. No caso de variabilidade suportada em tempo de camada. A combinação de diversas camadas, como forma execução, o objectivo não é corrigir um problema, como um de atingir um determinado comportamento, tem algumas bug, mas aumentar um ponto de variabilidade com novas similaridades com o mecanismo da herança do modelo variantes. Existem outras técnicas de variabilidade em tem- orientado pelos objectos. No modelo de programação orien- po de execução que são mais flexíveis. Nestas, é possível tado pelos objectos, a herança é utilizada para adicionar que o ponto de variabilidade esteja aberto a novas variantes comportamento novo a uma classe através da especializa- depois da produção do software. As principais técnicas que ção das suas características originais. As camadas do Gen- suportam variabilidade pós-distribuição, adoptadas pela Voca funcionam de uma forma similar à herança mas com indústria e com pontos de variabilidade abertos a novas uma abrangência maior. Estas aproximações à composição variantes em tempo de execução, são: de componentes são geralmente baseadas em técnicas de - Carregamento dinâmico de bibliotecas; transformação de programas [8]. - Infra-estruturas de componentes; O desenvolvimento de software com o GenVoca é - Linguagens de scripting; baseado na composição dos componentes através de cama- - Introspecção. das de tipos de dados. Estas camadas de tipos de dados Uma forma de alargar um conjunto de variantes em representam características dos componentes. Desta forma, tempo de execução consiste em utilizar a técnica de carre- as composições das camadas podem ser descritas por gamento dinâmico de bibliotecas. Esta técnica é bastante expressões. Segue-se um exemplo de uma expressão de usada pela indústria, sendo um exemplo muito conhecido composição de um componente em GenVoca [6]: de aplicação desta técnica a arquitectura dos controladores ALEXANDRE BRAGANÇA E RICARDO J. MACHADO: ENGENHARIA DE DOMÍNIO NO SUPORTE AO AUMENTO DE FLEXIBILIDADE NO SOFTWARE 3 (drivers) de ODBC. A capacidade de dinamicamente carre- ambientes de desenvolvimento durante as fases anteriores à gar uma biblioteca e usar os seus pontos de entrada possibi- distribuição do software para fases posteriores. lita distribuir apenas as bibliotecas que executam as varian- tes que são necessárias para um determinado ponto de variabilidade. Com esta técnica, é também possível adicio- 4 A VARIABILIDADE NO PROCESSO DE nar novas variantes após a distribuição e instalação inicial DESENVOLVIMENTO DE SOFTWARE da aplicação. Todas as técnicas de implementação de variabilidade que A técnica de carregamento dinâmico de bibliotecas é foram apresentadas podem ser usadas para aumentar o uma das bases das infra-estruturas de componentes de grau de variabilidade das aplicações. Existem dois concei- software como o COM ou o XPCOM. Estas infra-estruturas tos nucleares relativamente à variabilidade e ao ciclo de baseiam-se no conceito de componente de software supor- vida do software: o momento da introdução da variabilida- tado em bibliotecas de código que são carregadas dinami- de (introduction time) e o momento da selecção da variante camente em memória e também na noção de interfaces (binding time). O momento da introdução diz respeito à fase como forma de aceder aos serviços prestados pelos compo- do processo de desenvolvimento de software na qual é nentes de software. Uma vez que as aplicações acedem aos introduzido o ponto de variabilidade. Por exemplo, na fase componentes através das interfaces, é possível substituir o de análise de requisitos é possível introduzir um ponto de componente que a aplicação está a usar se o novo compo- variabilidade respeitante a uma característica da base de nente suportar a interface que a aplicação necessita. Para dados da aplicação que especifica que motor de base de além desta funcionalidade básica, as infra-estruturas de dados deve ser suportado: orientado para o objecto ou rela- componentes podem oferecer outras funcionalidades, como cional. No momento da introdução, o ponto de variabilida- a invocação de serviços remotos ou o pooling de componen- de é aberto para as diversas variantes possíveis. Numa fase tes. As infra-estruturas de componentes são uma técnica de posterior do processo de desenvolvimento de software, o implementação de variabilidade em tempo de execução que ponto de variabilidade é fechado através da selecção de é bastante usada pela indústria, como por exemplo no pro- uma das possíveis variantes. Este é o momento da selecção jecto Mozzila e no pacote de aplicações de escritório da da variante ou binding time. No exemplo apresentado, nal- Microsoft. Estes dois exemplos usam também uma outra guma fase posterior do processo de desenvolvimento de técnica de implementação de variabilidade: linguagens de software, uma das possibilidades de motor de base de scripting. dados será seleccionada. As línguagens de scripting permitem um grau muito ele- vado de variabilidade e de flexibilidade visto que a funcio- Requisitos nalidade de uma aplicação pode ser totalmente alterada em tempo de execução. Não obstante, estas são usadas, na IT Análise maior parte dos casos, para expandir e adaptar aplicações e não explicitamente como mecanismo de suporte à variabi- BT Desenho lidade. A grande vantagem das linguagens de scripting é Implementação que elas não necessitam de processos de construção muito pesados (envolvendo compilação e edição de ligações), Compilação usuais em linguagens de programação comuns. No entanto, o seu uso é limitado, nomeadamente, devido a requerem Pré-distribuição Edição de Ligações algum treino por parte do utilizador final. Este é um factor muito importante em técnicas que suportam variabilidade Pós-distribuição Instalação em tempo de execução, já que a sua utilização em fases pos- Execução teriores à distribuição do software pode, em determinados casos, implicar a participação do utilizador final. É o que Fig. 1. Exemplo de Introduction time (IT) e binding time (BT) para um ponto de variabilidade no ciclo de vida do software. acontece normalmente no caso das linguagens de scripting. A introspecção é também uma técnica que pode ser usa- da para suportar variabilidade em tempo de execução. As Alguns autores desenvolvem estes conceitos simples de plataformas de software mais utilizadas na indústria, como variabilidade introduzindo o conceito de binding site que o Java2 ou o .Net, suportam esta técnica. Como estas plata- difere do binding time porque abrange a dimensão espaço formas lideram o mercado relativamente a ambientes de para além da dimensão tempo [5]. Basicamente, o binding desenvolvimento de software, é muito provável que a site representa quando e onde o ponto de variabilidade é introspecção se torne também uma técnica utilizada no fechado através da selecção de uma das variantes. Por ques- suporte à implementação de variabilidade em tempo de tões de simplicidade, adopta-se o conceito de binding time execução. No mínimo, esta técnica permite o carregamento durante o artigo. Um ponto de variabilidade pode também dinâmico de tipos, a instanciação dinâmica de objectos e permanecer aberto após o binding time. Isto significa que se também a execução dinâmica de métodos. Algumas plata- podem continuar a seleccionar novas variantes no ponto de formas fornecem ainda funcionalidades mais avançadas variabilidade mesmo após se ter seleccionado uma varian- como, por exemplo, a geração dinâmica de código. Estas te, ou seja, o ponto de variabilidade permanece aberto. características de introspecção são muito poderosas pois Uma outra característica importante a respeito de um podem trazer quase todas as possibilidades existentes nos ponto de variabilidade é o número de variantes que este 4 QUATIC’2004 PROCEEDINGS suporta. No exemplo anterior, relativo ao motor de base de malizada para a variabilidade [10]. A expressão simplifica- dados, o ponto de variabilidade apenas suporta duas da que foi apresentada para quantificar a variabilidade é variantes. adoptada pois está mais de acordo com os objectivos do A fig. 1 apresenta um cenário possível para o introduction artigo. time e binding time do exemplo do motor de base de dados Torna-se claro que um grau elevado de variabilidade relativamente às fases mais comuns do ciclo de vida do pode ser atingido quando se adopta a variabilidade em software. Neste caso, o introduction time (IT) e o binding time fases finais do ciclo de vida do software, particularmente (BT) correspondem a duas fases consecutivas do ciclo de nas fases que se seguem à distribuição. Esta é uma das vida do software. Isto significa que o ponto de variabilida- razões pelas quais as técnicas que suportam variabilidade de permanece aberto apenas entre as fases de análise e de em tempo de execução, tais como as que foram apresenta- desenho. Depois da fase de desenho, o ponto de variabili- das na secção anterior, são cada vez mais adoptadas na dade é fechado pois é seleccionada uma das variantes rela- indústria. tivas ao motor de base de dados da aplicação. Assim, a par- Como o grau de variabilidade quantifica a capacidade tir dessa fase, pode-se afirmar que o grau de variabilidade para uma aplicação suportar alterações, este constitui tam- da aplicação, relativamente ao suporte de motores de base bém uma medida da flexibilidade da aplicação. No exem- de dados, é nulo. Isto não significa que globalmente a apli- plo do motor de base de dados, a aplicação torna-se mais cação não tenha variabilidade. De facto, a aplicação apre- flexível ao conter um ponto de variabilidade que permite senta características de variabilidade, no entanto, neste seleccionar entre dois motores de base de dados possíveis. exemplo, o momento de introdução e o binding time aconte- Ou seja, mudar o motor de base de dados da aplicação cem em fases inicias do ciclo de vida do software. Se o pon- requer menos esforço do que num caso em que esse ponto to de variabilidade permanecer aberto até fases mais poste- de variabilidade não exista. Assim, a introdução de pontos riores, por exemplo até à fase da compilação, então o grau de variabilidade no ciclo de vida do software aumenta a de variabilidade da aplicação aumenta. Isto acontece pois flexibilidade das aplicações. Um tópico bastante interessan- quando se atrasa a introdução e o binding time de um ponto te é como identificar possíveis pontos de variabilidade. Este de variabilidade está-se a aumentar o seu grau de variabili- artigo não aborda esse tópico. Contudo, a variabilidade é dade e, por consequência, o grau de variabilidade da apli- um dos tópicos nucleares das linhas de produtos e das cação. Ou seja, quanto mais tarde se aplicar a variabilidade famílias de produtos, e muitos autores têm proposto méto- maior será o grau de variabilidade de uma aplicação. A dos e técnicas relativamente à identificação e representação adopção de pontos de variabilidade em fases finais do ciclo da variabilidade [11], [12], [13]. Quando o objectivo é de vida do software pode possibilitar uma mais rápida desenvolver uma única aplicação ou sistema, a adopção de mudança de variantes pois não é necessário regressar às técnicas de variabilidade não visa suportar a possibilidade fases iniciais de desenvolvimento. No exemplo da fig. 1, se de construção de múltiplas aplicações a partir de uma base for necessário mudar de motor de base de dados, essa ope- comum, mas acrescentar flexibilidade e capacidade de evo- ração é executada na fase de desenho. Assim, o caso da fig. lução a uma única aplicação, isto é, facilitar a possibilidade 1 apresenta um grau de variabilidade menor do que um de alterações na aplicação. caso similar que tenha o binding time numa fase posterior De forma geral, quando se considera que a implementa- como, por exemplo, a fase de compilação. ção de uma característica da aplicação pode vir a ser altera- Com base nos princípios apresentados, é possível quan- da no futuro, então deve-se adoptar uma técnica de imple- tificar o grau de variabilidade de um ponto de variabilida- mentação de variabilidade. Estas decisões devem ser efec- de. Assim, os conceitos mais significativos a ter em conta tuadas com especial cuidado. Se, por exemplo, a implemen- são o momento da introdução, o binding time e o número de tação de uma característica desse género já implicar algum variantes. Para um determinado ponto de variabilidade, tipo de variabilidade, então poder-se-á justificar adoptar quanto mais tarde ele for introduzido ou seleccionada uma uma técnica de implementação de variabilidade que supor- das variantes, maior será o seu grau de variabilidade. A te mais facilmente a possível futura adição de novas varian- variabilidade também aumenta com o aumento do número tes. Desta forma, é possível aumentar a flexibilidade de de variantes associado ao ponto de variabilidade. Assim, uma aplicação com pouco esforço de desenvolvimento uma associando valores crescentes às fases do ciclo de vida do vez que o mecanismo de variabilidade já era necessário. No software (por exemplo, 1-Requisitos; 2-Análise; 3-Desenho, caso do exemplo do motor de base de dados, em vez de etc.) consegue-se uma medida muito simples para o grau de adoptar uma técnica de suporte à variabilidade numa fase variabilidade através da seguinte expressão: antes da distribuição, como o uso de directivas de compila- ção para suportar os dois motores da base de dados, era IT * BT * nV possível adoptar uma técnica que permitisse maior flexibi- Nela, IT representa o momento da introdução, BT lidade e capacidade de evolução. Duas possibilidades representa o binding time e nV representa o número das seriam a adopção de um padrão de desenho do tipo fábrica variantes possíveis. Com base nesta expressão, o grau de [9], com binding time das variantes em tempo de execução, variabilidade para o caso da fig. 1 é 2*3*2=12. Alterando o ou ainda, uma técnica de implementação de variabilidade binding time para a fase de compilação obtém-se um grau de baseada em bibliotecas de carregamento dinâmico, que variabilidade de 2*5*2=20. Outros autores desenvolvem suportam a introdução de novas variantes em tempo de mais profundamente esta aproximação para quantificar o execução da aplicação. grau de variabilidade e propõem uma representação nor- Como mencionado, a identificação de pontos de variabi- ALEXANDRE BRAGANÇA E RICARDO J. MACHADO: ENGENHARIA DE DOMÍNIO NO SUPORTE AO AUMENTO DE FLEXIBILIDADE NO SOFTWARE 5 lidade não está no âmbito deste artigo. No entanto, se um 5 ENGENHARIA DE DOMÍNIO COMO FORMA DE ponto de variabilidade for identificado, isto significa que IMPLEMENTAÇÃO E GESTÃO DE VARIABILIDADE pelo menos existem duas variantes para esse ponto de variabilidade. Neste contexto, e se o objectivo for desenvol- As linhas de produtos e as famílias de produtos visam pro- ver uma aplicação flexível, deve-se dar muita atenção no mover a reutilização entre aplicações [15]. Para conseguir que diz respeito à técnica adoptada para suportar essa esta reutilização entre as diversas aplicações de uma linha variabilidade. Foi apresentada uma expressão simples que de produtos, as mesmas devem partilhar características. permite ter uma ideia do grau de variabilidade que se pode Isso geralmente só é conseguido se as aplicações partilham obter quando se adopta uma técnica de implementação de algum domínio. Assim, é possível conseguir algum nível de variabilidade. Usando esta aproximação simples, um enge- reutilização entre um processador de texto e uma aplicação nheiro de software pode mais facilmente prever as implica- de apresentação pois estas partilham o domínio das aplica- ções em termos de flexibilidade das suas opções de desen- ções de escritório. volvimento. Com base na nossa experiência, podemos afir- mar que, com a eventual excepção das técnicas de intros- Engenharia de Domínio Engenharia de Aplicações pecção e geração dinâmica de código, o esforço e a comple- Requisitos Requisitos xidade acrescidas, resultantes da adopção de técnicas de implementação de variabilidade nas fases finais do ciclo de Análise Análise vida do software, não têm implicações muito significativas no custo de projectos médios e grandes [14]. Desenho Desenho Como se verificou nesta secção, a adopção de técnicas de implementação de variabilidade fornece um suporte para Implementação Implementação aumentar a flexibilidade das aplicações. Com as técnicas referidas, torna-se mais fácil a introdução de variantes Compilação novas nas aplicações. Isto verifica-se pois técnicas de supor- Edição de ligações te de variabilidade em tempo de execução, como bibliotecas Pré-distribuição de carregamento dinâmico, tornam possível a introdução Pós-distribuição de novas variantes sem ser necessária a alteração das apli- Instalação cações. Um exemplo bastante conhecido desta aproximação Execução é a arquitectura do ODBC que suporta a mudança do motor da base de dados de uma aplicação em tempo de execução. Se o suporte de variabilidade for adoptado numa aplica- ção com o objectivo de aumentar a sua flexibilidade, é pos- Fig. 2. Engenharia de Domínio vs. Engenharia de Aplicação. sível que mudanças nos requisitos possam ser suportadas pela adição de novas variantes. No entanto, esta possibili- A engenharia de domínio é um processo que visa identi- dade apenas é exequível se não for necessário alterar a ficar, representar e implementar artefactos reutilizáveis de estrutura, ou interface, do ponto de variabilidade. Ou seja, é um domínio [16]. Exemplos de métodos que aplicam prin- possível que o ODBC suporte um novo motor de base de cípios de engenharia de domínio são o FODA [11] e o RSEB dados se o controlador respectivo for compatível com a [12]. Tradicionalment, estes métodos são aplicados apenas interface do ODBC. Se tal não for possível, então é necessá- quando diversas aplicações partilham o mesmo domínio, rio alterar a interface do ODBC para acomodar o novo con- como o caso das linhas de produtos. Nestes casos, a enge- trolador, e isso pode ter várias implicações, como a actuali- nharia de domínio fornece métodos e técnicas adequados zação dos controladores antigos ou o suporte de duas ver- para suportar o desenvolvimento de artefactos reutilizá- sões. Neste caso, será necessário regressar às fases mais veis, como arquitecturas de software, modelos de desenho e iniciais do ciclo de vida do software, possivelmente à fase componentes de software. A fig. 2 apresenta as interacções de introdução do ponto de variabilidade, de forma a alterar possíveis entre a engenharia de domínio e a engenharia de a estrutura do ponto de variabilidade. Quando isto aconte- aplicação. Os artefactos produzidos pela engenharia de ce, o processo do desenvolvimento do software pode-se domínio podem ser reutilizados na engenharia de aplica- tornar mais complexo e, normalmente, outros problemas de ção. As setas com sentido da engenharia de aplicação para a desenvolvimento de software aparecem. Uma vez que este engenharia de domínio demonstram que a engenharia de tipo de problema pode ocorrer com alguma frequência, aplicação pode fornecer entradas para a engenharia de propõe-se, na secção seguinte, uma aproximação baseada domínio, usualmente sob a forma de conhecimento do na engenharia do domínio que tem por objectivo controlar domínio em causa. Cada nova aplicação que é construída o nível de complexidade que as técnicas de implementação dentro do domínio ganhará da reutilização dos artefactos de variabilidade podem impor ao processo de desenvolvi- do domínio mas também fornecerá conhecimento para refi- mento de software. nar os mesmos artefactos do domínio ou para construir novos artefactos. Os artefactos resultantes do processo de engenharia de domínio consistem nos componentes comuns que são reutilizados nas aplicações mas também nos componentes que implementam os pontos de variabili- dade e que são usados apenas em algumas aplicações. Estes 6 QUATIC’2004 PROCEEDINGS são também os tipos de artefactos que são necessários desenvolvimento de linhas de produtos ou de familias de quando o objectivo é construir aplicações flexíveis e que produtos [15]. possam evoluir mais facilmente. Assim, em vez de adoptar Neste artigo foi proposta uma nova perspectiva relati- a engenharia de domínio como um processo que visa vamente à engenharia de domínio. Esta assenta no princípi- suportar o desenvolvimento de diversas aplicações de um o de que a engenharia de domínio pode ser adoptada como domínio, este pode ser adoptado para apoiar o desenvol- um método bem sucedido para suportar a introdução e o vimento de variantes e respectivos pontos de variabilidade desenvolvimento de pontos de variabilidade em aplicações na engenharia de aplicações comuns. O que se propõe é que isoladas. Os pontos de variabilidade e as técnicas que per- os métodos de engenharia de domínio sejam adoptados mitem a sua implementação podem suportar o aumento do para suportar a implementação de pontos de variabilidade grau de flexibilidade e a capacidade de evolução das apli- na engenharia de aplicações. De facto, ao considerar-se cações. Para atingir este objectivo, diversas técnicas de cada ponto de variabilidade como um domínio, então faz implementação de variabilidade estão disponíveis. Estas sentido que os métodos de engenharia de domínio possam técnicas, quando adoptadas, possibilitam diferentes graus ser aplicados a cada ponto de variabilidade. Uma vez que de variabilidade. Este artigo apresenta uma forma muito os métodos de engenharia de domínio requerem esforço simples para medir o grau de variabilidade que as diversas extra no processo de engenharia, deve-se ter um cuidado técnicas de implementação de variabilidade podem intro- especial na selecção dos pontos de variabilidade que devem duzir numa aplicação. Esta medida simples pode apoiar o ser desenvolvidos através da aplicação de princípios de engenheiro de software na selecção da técnica de imple- engenharia de domínio. mentação de variabilidade mais adequada ao seu caso par- Como regra geral, somente os pontos de variabilidade ticular. As técnicas que possibilitam um grau mais elevado que possibilitem um elevado grau de variabilidade devem de variabilidade também são geralmente aquelas que são ser desenvolvidos utilizando métodos e técnicas de enge- mais complexas de implementar e manter. Para gerir esta nharia de domínio. Este é, normalmente, o caso de pontos complexidade propõe-se que a adopção de métodos de de variabilidade que necessitem de suporte em tempo de engenharia de domínio, com utilização paralela ao método execução. O exemplo do motor de base de dados, introdu- de engenharia da aplicação, seja apenas efectuada no zido na secção precedente, é um caso típico em que poderia desenvolvimento dos pontos de variabilidade mais com- ser adoptado um método de engenharia de domínio. Se o plexos. grau de variabilidade for elevado, por exemplo porque Esta aproximação é baseada na nossa própria experiên- devem ser suportados dinamicamente diferentes motores cia com a adopção de técnicas de implementação de varia- de base de dados, então deve-se adoptar métodos de enge- bilidade na engenharia de aplicações como forma de nharia de domínio no ponto de variabilidade, mesmo se o aumentar a flexibilidade das aplicações [14]. Para um suporte de diferentes motores de base de dados seja apenas determinado ponto de variabilidade podem ser possíveis utilizado para uma única aplicação. Neste caso, o suporte diversas técnicas de suporte à variabilidade. Como descrito para o ponto de variabilidade deve ser promovido a um neste artigo, é relativamente simples medir o grau de varia- componente a reutilizar na aplicação. Desta forma, um bilidade de diferentes técnicas. O que se torna mais difícil é método de engenharia de domínio poderia ser utilizado a identificação prévia de possíveis pontos de variabilidade para desenvolver o componente que suporta o ponto de e a selecção da técnica mais adequada para cada ponto de variabilidade, assim como as respectivas variantes. variabilidade. No futuro, pretendemos desenvolver o nosso Esta aproximação à engenharia de pontos de variabili- trabalho no contexto destas preocupações. dade, que combina engenharia de domínio e engenharia de aplicações, tem muitas vantagens face à engenharia simples REFERÊNCIAS de aplicações. Na nossa opinião, uma das principais vanta- [1] M. Fleury and F. Reverbel, “The JBoss Extensible Server,” gens é a de tornar mais simples a gestão de mudanças Proc. of Middleware 2003 - ACM/IFIP/USENIX Interna- estruturais nos pontos de variabilidade. Como o suporte tional Middleware Conference, 2003. para o ponto de variabilidade consiste num componente [2] J.v. Gurp, “On the Design & Preservation of Software Sys- resultante da engenharia de domínio, uma alteração estru- tems,” PhD dissertation, Computer Science Department, tural num componente deste tipo consiste, de facto, numa University of Groningen, Groningen, 2003. alteração no domínio do ponto de variabilidade. Devido às [3] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris suas características, este tipo de alteração é gerida no con- Maeda, Cristina Videira Lopes, Jean-Marc Loingtier, John texto do processo de engenharia de domínio adoptado e Irwin, “Aspect-Oriented Programming,” Proc.European não implica maior complexidade no processo de engenha- Conference on Object-Oriented Programming (ECOOP), ria da aplicação. 1997. [4] Harold Ossher, William Harrison, Frank Budinsky, Ian Sim- 6 CONCLUSÕES monds, “Subject-Oriented Programming: Supporting Decen- Existem exemplos documentados de adopção bem sucedida tralized Development of Objects,” Proc. 7th IBM Conference de métodos de engenharia de domínio para o desenvolvi- on Object-Oriented Technology, 1994. [5] K. Czarnecki, “Generative Programming Principles and mento de artefactos de domínio. As linguagens específicas de domínio são um de muitos exemplos possíveis [17]. Techniques of Software Engineering Based on Automated Noutros contextos encontram-se outros exemplos, como o Configuration and Fragment-Based Component Models,” PhD dissertation, Department of Computer Science and ALEXANDRE BRAGANÇA E RICARDO J. MACHADO: ENGENHARIA DE DOMÍNIO NO SUPORTE AO AUMENTO DE FLEXIBILIDADE NO SOFTWARE 7 Automation, Technical University of Ilmenau, 1998. [6] Don Batory, Roberto E. Lopez-Herrejon, Jean-Philippe Marti, “Generating Product-Lines of Product-Families,“ Proc. ASE'02, Edinburgh, Scotland, 2002. [7] Cristina Lopes, “D: A Language Framework For Distributed Programming,” PhD dissertation, College of Computer Sci- ence, Northeastern University, 1997. [8] J. M. Neighbors, “The Draco approach to constructing soft- ware from reusable components,” IEEE Transactions on Software Engineering, vol. 10, pp. 64-74, 1984. [9] Erich Gamma, Richard Helm, Ralph Johnson, John Vlis- sides, Design Patterns - Elements of Reusable Object- Oriented Software, Addison-Wesley, 1995. [10] Michel Jaring, Jan Bosch, “Representing Variability in Soft- ware Product Lines: A case study,“ Proc.Second Software Product Line Conference (SPLC2), 2002. [11] Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, A. Spencer Peterson, “Domain Analysis (FODA) Feasibility Study Technical Report”, Software Engineering Institute, Carnegie Mellon University, 1990. [12] Ivar Jacobson, Martin Griss, Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Addison Wesley Longman, 1997. [13] Martin Griss, John Favaro, Massimo d'Alessandro, “Integrat- ing Feature Modeling with the RSEB,” Proc. Fifth Interna- tional Conference on Software Reuse, Victoria, Canada, 1998. [14] Alexandre Bragança, Ricardo J. Machado, “Run-time Vari- ability Issues in Software Product Lines,” ICSR8 Workshop on Implementation of Software Product Lines and Reusable Components, Madrid, 2004. [15] Jan Bosch, Design and Use of Software Architectures Adopt- ing and Evolving a Product-Line Approach, Addison-Wesley, 2000. [16] SEI, “Domain Engineering: A Model-Based Approach,” Software Engineering Institute, http://www.sei.cmu.edu/domain-engineering/, 2004. [17] Arie v. Deursen, Paul Klint, Joost Visser, “Domain-Specific Languages: An Annotated Bibliography,” ACM SIGPLAN Notices, vol. 35, pp. 26-36, 2000.