=Paper=
{{Paper
|id=Vol-1135/paper2
|storemode=property
|title=Engenharia de Domínio no Suporte ao Aumento de Flexibilidade nos Sistemas de Software
|pdfUrl=https://ceur-ws.org/Vol-1135/paper2.pdf
|volume=Vol-1135
|dblpUrl=https://dblp.org/rec/conf/quatic/BragancaM04
}}
==Engenharia de Domínio no Suporte ao Aumento de Flexibilidade nos Sistemas de Software==
https://ceur-ws.org/Vol-1135/paper2.pdf
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.