17

2 Desenvolvimento Baseado em Componentes e Engenharia de

Domnio
2.1 Introduo
Segundo PRIETO (1991), um dos maiores problemas na reutilizao de software a
criao de componentes que possam ser reutilizados em outras aplicaes alm daquelas
para as quais eles foram originalmente definidos. Como soluo para este problema, Prieto
aponta como passo fundamental a sistematizao do processo de criao de componentes
em um dado domnio, atravs de uma atividade denominada anlise de domnio.
O termo Anlise de Domnio foi introduzido pela primeira vez por NEIGHBOURS
na dcada de 80 (1981). Sua definio clssica apresenta esta atividade como sendo a de
identificao de objetos e operaes de uma classe de sistemas similares em um domnio de
problema particular. Segundo este autor, o principal produto desta atividade a definio
de uma linguagem especfica do domnio, formada por uma coleo de regras que
relacionam objetos e funes.
Na interpretao dada por PRIETO (1991), a anlise de domnio uma atividade
anterior anlise de sistemas e cujos resultados (modelos de domnio) suportam a anlise
de sistemas da mesma forma que os resultados da fase de anlise de sistemas suportam a
fase de projeto. Entretanto, podemos considerar a anlise de domnio como apenas uma das
atividades envolvidas na disponibilizao de componentes de software realmente
reutilizveis.
Segundo KRUEGER (1992), componentes de software podem ser desde
componentes em cdigo fonte ou binrio, passando por estruturas de projeto, especificaes
e documentao, entre outros. Assim, para que a reutilizao possa ser realmente efetiva,
deve-se consider-la em todas as fases do desenvolvimento de aplicaes, desde a fase de
anlise at a implementao. Desta forma, deve-se disponibilizar componentes reutilizveis
para todas as fases do processo de desenvolvimento das aplicaes e, mais importante
ainda, que estes componentes reutilizveis sejam consistentes ao longo deste
desenvolvimento, ou seja, um componente reutilizvel utilizado na especificao da
aplicao deve ser consistente com um componente de software a ser reutilizado na fase de
implementao.

Para que isso seja possvel, necessria a especificao de uma

18

sistemtica de desenvolvimento destes componentes ao longo de todas as fases do processo.

Sem esta sistematizao na criao de componentes reutilizveis, corremos o risco de
disponibilizar componentes que no contemplem todos os conceitos relevantes do domnio
e que no apresentem uma uniformidade de conceitos entre as diversas etapas de
desenvolvimento. Esta sistemtica conseguida atravs da adoo de um processo de
engenharia de domnio, conforme descreveremos na seo 2.2.
Segundo ARANGO (1988), a engenharia de domnio representa um enfoque mais
sistematizado para a anlise de domnio, sob uma perspectiva mais voltada para a
construo de componentes, criando-se um processo completo para a especificao de
componentes reutilizveis (i.e., anlise, projeto e implementao). As idias apresentadas
por KRUEGER (1992) so consistentes com a abordagem de Arango, uma vez que atesta a
importncia da abstrao para facilitar a reutilizao, sendo esta abstrao especificada
atravs da anlise de domnio, mas tambm apresenta a importncia da realizao da
abstrao em componentes reutilizveis que possam ser empregados no desenvolvimento
de uma dada aplicao no domnio. Neste sentido, a especificao descreve o que a
abstrao faz, ao passo que a realizao da abstrao descreve como isso feito.
Por outro lado, a corrente demanda por software cada vez mais complexo requer
uma mudana na abordagem de desenvolvimento de software atual (COHEN, 1998). O
desenvolvimento de software requer cada vez mais um alto grau de automao de suas
atividades e controle do processo; a utilizao de novas tecnologias como distribuio e
componentizao; a disponibilizao de produtos de software que estejam em
conformidade com os padres adotados pelo mercado, citando apenas alguns aspectos.
Com base nestas novas tecnologias, novos mtodos de desenvolvimento de software
baseado em componentes surgiram recentemente (JACOBSON et al., 1997), (DSOUZA,
1998). No entanto, este mtodos preocupam-se com o desenvolvimento de aplicaes
baseadas em componentes e no com o desenvolvimento dos componentes para serem
reutilizados. Esta constatao tambm apresentada em (FORSELL et al., 2000), que
apresenta a anlise de trs mtodos considerados baseados em componentes. Forsell chega
a concluso que, na verdade, os mtodos iniciam com uma abordagem de desenvolvimento
de componentes, que poderia ser considerada uma abordagem de desenvolvimento para
reutilizao, ou mais especificamente um processo de engenharia de domnio mas no meio

19

do processo h uma mudana para o desenvolvimento com reutilizao, ou seja, uma

abordagem de engenharia de aplicaes. Assim, as abordagens acabam por mesclar os dois
tipos de processos, no apresentando resultados satisfatrios em nenhum dos dois. Forsell
ainda ressalta a importncia de um suporte de infra-estrutura para os mtodos,
principalmente em termos de um repositrio de componentes e tcnicas de busca e
recuperao dos mesmos.
Neste captulo, apresentamos uma descrio genrica sobre a engenharia de domnio e
sobre o desenvolvimento baseado em componentes (DBC) e as abordagens que dispomos
atualmente na literatura. Apresentamos, ainda, alguns mtodos de engenharia de domnio,
pois acreditamos que os mesmos podem trazer contribuies significativas para o DBC.
Atravs do estudo destas abordagens, supomos conseguir especificar uma abordagem
hbrida, que reuna os avanos tecnolgicos e consideraes de projeto e implementao do
DBC com as abstraes e a modelagem detalhada da engenharia de domnio.
2.2 Engenharia de Domnio (ED)
Nesta tese, estamos particularmente

interessados

no

desenvolvimento

de

componentes. Desta forma, analisamos o processo de engenharia de domnio com o intuito

de identificar o que o mesmo tem a contribuir para o processo de desenvolvimento de
componentes no contexto de DBC.
O principal objetivo da engenharia de domnio (ED) o desenvolvimento de
componentes do domnio que possam ser usados (e reutilizados) no desenvolvimento de
aplicaes no domnio. Assim, a ED deve consistir de atividades que sistematizem a busca
e representao de informaes do domnio, de forma a facilitar ao mximo a sua
reutilizao.
2.2.1 Etapas da Engenharia de Domnio
Os mtodos propostos na literatura (KANG et al., 1998), (SIMOS, 1996), (KANG
et al., 1990), (CHAN et al., 1998), (GRISS et al., 1998) concordam que existem
basicamente trs etapas principais na ED1:

Anlise do domnio, que determina os requisitos comuns de uma famlia de aplicaes

com o objetivo de identificar as oportunidades de reutilizao.

20

Projeto do domnio: Utiliza os resultados da anlise do domnio para identificar e

generalizar solues para os requisitos comuns, atravs da especificao de uma
arquitetura de software do domnio. As oportunidades de reutilizao identificadas na
anlise do domnio so refinadas de forma a especificar as restries do projeto.

Implementao do domnio: Transforma as oportunidades de reutilizao e solues do

projeto para um modelo implementacional, que inclui servios tais como: a
identificao, reengenharia e/ou construo, e manuteno de componentes reutilizveis
que suportem estes requisitos e solues de projeto.

2.2.2 Profissionais envolvidos com a Engenharia de Domnio

Em (SIMOS, 1996), so apresentados trs grupos principais de profissionais que
atuam ativamente em um processo de ED:

Fontes: so os usurios finais que utilizam aplicaes j desenvolvidas naquele domnio

e os especialistas do domnio que provem informaes a respeito de conceitos e
funcionalidades relevantes no domnio;

Produtores: So os analistas e projetistas do domnio que capturam as informaes das

fontes

de

aplicaes

existentes

realizam

anlise,

projeto

implementao/empacotamento dos componentes reutilizveis;

Consumidores: so os desenvolvedores de aplicaes e usurios finais interessados no

entendimento do domnio, que utilizam os modelos gerados nas diversas etapas da
engenharia de domnio para a especificao de aplicaes e/ou maior entendimento dos
conceitos e funes inerentes ao domnio.

2.2.3 Fontes de Informao

Existem diversas fontes de informao disponveis para a ED, cada uma com
vantagens e desvantagens. A tabela 2.1, adaptada de (KANG, 1990), apresenta os principais
tipos de fonte de informao disponveis para a ED.

Para o leitor no familiarizado com os conceitos inerentes a Engenharia de Domnio, no captulo 4

21

Fonte
Livros

Vantagem

Fonte segura de
conhecimento terico do
domnio

Desvantagem

Etapas da ED que a
utiliza

Apresentam uma
viso ideal do
domnio

Padronizaes

Aplicaes
existentes

Especialistas do
Domnio

Representa uma viso de

consenso do domnio.
Geralmente utiliza uma
nomenclatura
amplamente aceita no
domnio
A modelagem, se existir,
bem realista
Pode ser diretamente
utilizada para se
determinar os requisitos
do usurio
A arquitetura pode ser
abstrada para a
arquitetura do domnio,
se houver caractersticas
arquiteturais comuns
entre as aplicaes.
Pode permitir a
generalizao e
empacotamento de
componentes
implementacionais
Permitem a captura mais
consistente da dinmica e
da evoluo do domnio

Deve ser
validada para
verificar sua
aceitao no
domnio

Bom para a
construo do
modelo de
abstraes do
domnio.
Fase de anlise e
de projeto
Anlise do
domnio

Se o domnio

dinmico, as
aplicaes
podem no
representar mais
a realidade do
domnio.

Todas as etapas

Podem refletir

uma viso muito

particular do
domnio

Principalmente na
fase de anlise

Tabela 2.1 Principais Fontes de informao para ED

2.2.4 Produtos gerados pela Engenharia de Domnio
Um mtodo de engenharia de domnio para ser efetivo deve prover representaes
especficas para documentar os resultados de cada uma das fases da ED. Estas
representaes devem, prioritariamente, representar o escopo/abrangncia do domnio,
apresentamos uma descrio mais detalhada de um processo de ED.

22

descrever os problemas passveis de serem solucionados atravs de componentes de

software no domnio e prover especificaes arquiteturais e implementaes que
solucionem os problemas encontrados no domnio. Assim, para cada uma das fases da
engenharia de domnio, devem existir produtos especficos a serem disponibilizados.
Na fase de anlise de domnio, devem ser disponibilizadas representaes que
capturem o contexto e a abrangncia do domnio, explicitando seu interfaceamento com
outros domnios. Nesta fase, ainda devem ser disponibilizados modelos que capturem os
principais conceitos e funcionalidades inerentes ao domnio, gerando assim um ou mais
modelos com abstraes do domnio (como recomenda KRUEGER (1992)). Este modelo
de abstraes deve ser acompanhado de uma documentao que detalhe cada uma das
abstraes e como estas podem ser mapeadas em requisitos de aplicaes no domnio.
O projeto do domnio deve disponibilizar modelos que especifiquem a estrutura
arquitetural a ser seguida pelas aplicaes do domnio. As representaes geradas devem
prover modelos arquiteturais que auxiliem na especificao de arquiteturas especficas para
cada aplicao. Pode-se ter vrios modelos arquiteturais para um nico domnio.
A

fase

de

implementao

do

domnio

deve

disponibilizar

componentes

implementacionais que especifiquem as principais funcionalidades encontradas em

aplicaes do domnio. Estes componentes implementacionais devem estar em
conformidade com o modelo de abstraes da fase de anlise e com os modelos
arquiteturais da fase de projeto, de forma que possam cooperar entre si para implementar
todas as funcionalidades requeridas para uma dada aplicao.
2.3 Desenvolvimento baseado em Componentes (DBC)
At bem pouco tempo atrs, o desenvolvimento da maioria dos produtos de software
disponveis no mercado era baseado em uma abordagem de desenvolvimento em blocos
monolticos, formados por um grande nmero de partes interrelacionadas, onde estes
relacionamentos estavam na maioria das vezes implcitos. O desenvolvimento baseado em
componentes surgiu como uma nova perspectiva para o desenvolvimento de software, cujo
objetivo a quebra destes blocos monolticos em componentes interoperveis, reduzindo
desta forma a complexidade no desenvolvimento, assim como os custos, atravs da
utilizao de componentes que, a princpio, seriam adequados para serem utilizados em
outras aplicaes (SAMETINGER, 1997).

23

O desenvolvimento de software baseado em componentes tem como principal

objetivo o desenvolvimento de aplicaes pela composio de partes j existentes. Assim, o
DBC caracterizado por um conjunto de elementos, i.e., desenvolvimento de componentes
(partes) independentes, composio de partes, interoperao2, que o distinguem do
desenvolvimento de software tradicional. Os componentes so partes operacionais de
software que foram desenvolvidas de forma a desempenhar completamente suas funes.
Assim, os componentes so empacotados a fim de prover conjuntos de servios que so
acessveis apenas atravs de uma interface bem definida.
Este objetivo no novo no desenvolvimento de software. Em 1968, McIlRoy
(MCILROY, 1968 em SAMETINGER, 1997) j vislumbrava uma indstria de
componentes de software reutilizveis. Segundo HALL (2000), desde as primeiras
linguagens de interconexo de mdulos, em 1976, a idia de arquitetura de software
baseada em componentes j surgia. A diferena que estas abordagens se baseavam
essencialmente em cdigo. Entretanto, vemos que o DBC para ser efetivo envolve muito
mais do que isso (SAMETINGER, 1997). Somente recentemente o DBC est sendo
considerado como uma tcnica importante no desenvolvimento de software. Um conjunto
de fatores despertaram um novo interesse em DBC, provendo a motivao necessria para
se acreditar que este possa ser agora mais efetivo e realizado em larga escala. Dentre estes
fatores, podemos citar (SAMETINGER, 1997), (HALL, 2000), (ATKISON et al., 2000):

Desenvolvimento da WWW e da Internet aumentaram o entendimento e preocupao

em relao computao distribuda. A WWW encorajou os usurios a considerarem
um conjunto de servios distribudos no hiperespao como sendo na realidade um
sistema distribudo.

A mudana de sistemas baseados em mainframes para sistemas baseados na arquitetura

cliente/servidor levou os desenvolvedores a considerarem as aplicaes no mais como
sistemas monolticos, mas sim como um conjunto de sub-sistemas interoperveis.

Padres de infra-estrutura para construo de aplicaes como as iniciativas do Object

Management Group (OMG), atravs da Object Management Architecture (OMA) e

Interoperao a capacidade de dois ou mais componentes de software se comunicarem ou trabalharem em

conjunto, independentemente da linguagem de programao em que foram escritos ou de seus domnios de
execuo.

24

dos produtos da Microsoft como o Component Object Model (COM) e seus

derivados, entre outros.

O Gartner Group estima que por volta de 2003, 70% de novas aplicaes
desenvolvidas sejam especificadas como uma combinao de componentes reutilizveis
integrados. Esta reutilizao em larga escala

pode aumentar de maneira decisiva a

qualidade, custos e tempo de entrega (ATIKSON et al., 2000). No entanto, para que as
previses do Gartner Group possam ser cumpridas, ainda existe uma srie de problemas a
serem resolvidos em DBC, desde uma definio mais precisa e amplamente aceitvel do
que seria um componente, passando pelos problemas de interconexo de componentes em
uma

aplicao,

interoperabilidade

entre

componentes

metodologias

para

desenvolvimento baseado em componentes. Pelo que se pode notar nas discusses em

recentes workshops sobre DBC (CBSE, 1998, 1999, 2000), ainda no se tem um
consenso em nenhum destes tpicos, o que mostra a necessidade de um maior
amadurecimento da rea nos prximos anos para que em 2003 as previses possam se
concretizar.
Nas subsees a seguir, apresentamos uma viso geral do estado da arte dos
diversos tpicos envolvidos no desenvolvimento baseado em componentes, apresentando
ainda os pontos onde uma pesquisa mais intensa se faz necessria.
2.3.1 Componentes
A caracterizao do que seria um componente em DBC ainda no um tpico
fechado. Cada grupo de pesquisa caracteriza da maneira mais adequada ao seu contexto o
que seria um componente e, assim, no h ainda na literatura uma definio comum para
este termo.
Desde o primeiro workshop de DBC em 1998, em Kyoto (BROWN e WALLNAU,
1998), at o mais recente, em Los Angeles, Estados Unidos (CBSE, 2000), passando por
outras conferncias mais especficas (SSR e ICSR), vrias definies tm sido
apresentadas. Cada uma delas ressalta um determinado aspecto de um componente. O que
podemos notar que as vises naquela poca eram ainda muito diferentes umas das outras,
o que ressaltava a novidade da rea. Atualmente, podemos observar que j existem
definies mais precisas e convergentes a respeito do que vem a ser um componente. A

25

definio de Sametinger (SAMETINGER, 1997), com algumas consideraes em relao

arquitetura de software feita por Kazan (KAZAN, 2000), seria abrangente o suficiente para
estabelecer uma definio satisfatria do que seria um componente em DBC:

Componentes reutilizveis so artefatos autocontidos, claramente identificveis,

que descrevem ou realizam uma funo especfica e tm interfaces claras em conformidade
com um dado modelo de arquitetura de software, documentao apropriada e um grau de
reutilizao definido.

Assim, j h um certo consenso de que um componente de software deve:

1. ser autocontido em termos da funcionalidade que ele prov.
2. descrever ou realizar uma funo especfica (KOZACZYNSKI, 1999) (SAMETINGER,
1997), (YACOUB et al., 1999b);
3. estar em conformidade e prover um conjunto de interfaces bem definidas (CBSE, 1998,
1999, 2000) (SAMETINGER, 1997), (SZYPERSKI, 1998);
4. estar inserido no contexto de um modelo que guie a composio deste componente
(arquitetura de software);
5. ter

disponvel

uma

documentao

adequada

(YACOUB

et

al.,

1999a),

(SAMETINGER, 1997);
6. prover o grau de maturidade do componente, ou seja, em quantos projetos foi
reutilizado, opinies a respeito do componente, etc. (SAMETINGER, 1997),
(YACOUB et al., 1999b);

Ser autocontido significa que a funo que o componente desempenha deve ser
realizada por ele, de forma completa. Um componente deve tambm ser claramente
identificvel, de forma que possa ser encontrado de maneira facilitada seja qual for sua
localizao (remota ou no). Atualmente, este um atributo muito importante pois cada vez
mais a distribuio e interoperabilidade so caractersticas desejadas pelas aplicaes.
Assim, em um sistema distribudo, importante que um componente seja identificado de
maneira nica, sem ambigidades.

26

Um dado componente no completamente independente dos outros componentes

e do ambiente. O que determina como se d esta dependncia do componente em relao
aos seus pares e ao ambiente que o cerca so suas interfaces. As interfaces de um dado
componente determinam como este componente pode ser reutilizado e interconectado com
outros componentes. Assim, as interfaces so cruciais para o mecanismo de composio,
onde um componente exporta (prov) servios que outro componente importa (requer).
Dois componentes so conectados, portanto, se os requisitos requeridos por um
componente so providos pelo outro componente.
SZYPERSKI (1998) define uma interface como sendo um conjunto de assinaturas
de operaes que podem ser invocadas por um cliente. Para cada operao, sua semntica
deve ser especificada e esta especificao tem um papel duplo, que servir tanto para os
servidores que implementam a interface quanto para os clientes que iro usar esta interface.
Esta abordagem crucial para o DBC, pois a priori, servidores e clientes no precisam se
conhecer. O que mediar a conexo ser a interface que permite que as duas partes
possam trabalhar em conjunto.
BROWN et al. (1998) apresentam como sendo importantes dois tipos de interface:
interface funcional, que reflete o papel do componente no contexto de uma dada aplicao,
e uma outra interface, denominada extra-funcional, que descreve restries impostas pela
arquitetura de software. Esta viso evoluiu no contexto da comunidade de DBC. Em
(YACOUB, et al., 1999a) apresentado um modelo para a classificao de interfaces
bastante interessante. Os autores dividem as interfaces em dois tipos: aplicao e
plataforma. As interfaces de aplicao definem a interao do componente com outros
componentes, de diferentes granularidades. HALL (2000) ressalta, ainda, que existem dois
subtipos de interface de aplicao: interna, que so interfaces que permitem a conexo de
componentes para formar um componente de maior granularidade, e interface externa que
visvel em relao arquitetura de software de uma dada aplicao. Neste sentido, Hall
ressalta que a construo de componentes um processo recursivo, com a composio de
componentes de diversas granularidades. Interfaces de plataforma definem a interao com
a plataforma onde cada componente pode ser executado. Este tipo de interface pode incluir
chamadas ao sistema operacional, a tecnologia de hardware requerida para a execuo do
componente e os subsistemas de comunicao. Os autores ressaltam a importncia deste

27

tipo de interface uma vez que determina a portabilidade do componente e como ele roda e
executa em um hardware especfico.
Outro ponto ressaltado pelos pesquisadores na rea (SAMETINGER, 1997),
(HALL, 2000) a necessidade de se ter em alguns casos uma outra estrutura entre as
interfaces para mediar a conexo. Esta estrutura responsvel por realizar converses
simples. Como exemplo deste tipo de estrutura podemos citar o barramento CORBA.
SZYPERSKI (1998) apresenta ainda a importncia das pr e ps condies para que dois
componentes possam se conectar atravs de uma interface. Neste sentido, as interfaces
podem ser vistas como contratos entre o cliente (requisitor) da interface e o provedor da
implementao da mesma. Assim, para que o contrato possa ser fechado, ambas as partes
tm que cumprir condies especificadas nas pr e ps condies da interface.
A documentao tambm indispensvel para a reutilizao (SAMETINGER, 1997).
Esta deve ser suficiente para que se possa recuperar um componente, avaliar sua
adequabilidade para o contexto da reutilizao, fazer adaptaes (se este for o caso) e
integrar o componente no seu novo ambiente. Outro conceito importante o que os
pesquisadores chamam de grau de reutilizao do componente (YACOUB et al., 1999a)
(SAMETINGER, 1997). O grau de reutilizao contm informaes tais como: quantas
vezes e onde o componente foi reutilizado (demonstrando assim sua maturidade ou no),
quem responsvel pela manuteno do componente, quem o proprietrio do
componente, entre outras.
Atualmente, uma das grandes preocupaes no DBC como especificar componentes
de forma que os mesmos possam ser disponibilizados de maneira adequada para um grande
nmero de usurios. Uma das pesquisas promissoras neste sentido em relao ao uso de
XML (eXtended Markup Language) para a publicao de componentes (LARSEN, 2000).
O XML est sendo usado principalmente para a representao das interfaces dos
componentes e com isso os pesquisadores acreditam que o problema de conexo de
componentes heterogneos poderia ser melhorado. Os pesquisadores argumentam que o uso
de um padro amplamente aceito pela comunidade garante a troca de informaes de
maneira padronizada e que o XML pode ser um mecanismo de representao a ser utilizado
como padro.

Outro ponto onde as pesquisas relacionadas ao XML se mostram

promissoras em relao documentao de componentes de forma que os mesmos

28

possam ser consultados por mecanismos de busca de forma mais eficiente (FAYAD et al.,
2000). Neste sentido, a publicao dos componentes seria feita atravs de uma descrio
em XML. A utilizao de XML em DBC bastante promissora e este parece ser uma
caminho de pesquisa forte em DBC nos prximos anos.
Sametinger (SAMETINGER, 1997) define alguns atributos que um componente deve
ter de forma que sua classificao, busca e seleo sejam bem caracterizadas. Estes
atributos complementam as caractersticas descritas acima, descrevendo com mais detalhes
algumas delas. So eles:

funcionalidade: a funcionalidade de um dado componente deve ser bem

caracterizada, de forma que possa ser facilmente identificvel em relao a sua
utilidade em um dado contexto;

interatividade: o quanto o ambiente e os outros componentes afetam o componente e

a forma como ele se comporta;

interao: como se d a comunicao com outros componentes;

concorrncia: define entre outras coisas a ordem de execuo dos componentes, se

dois componentes podem executar concomitantemente, etc. O estudo da
concorrncia entre os componentes pode levar a ganhos de velocidade, entre outros
aspectos;

distribuio: principalmente com o advento da Internet, este atributo passou a ter

grande importncia no contexto de DBC;

formas de adaptao: podemos ter duas formas de adaptao, a customizao, que

a possibilidade de parametrizao do componente, e a modificao que a criao
de uma nova verso do componente;

controle de qualidade: deve-se prover mecanismos para garantir a qualidade de

componentes .

Outra questo interessante que, no incio, a viso de um componente como um

elemento somente como cdigo era bastante forte e hoje (GOMMA, 2000) (GRISS, 2000),
(FORSELL et al., 2000) (HALL, 2000) esta viso est mudando e as pessoas comeam a
visualizar componentes em todos os nveis de abstrao do processo de desenvolvimento.
Atualmente, h um consenso em relao a dois grupos principais de componentes.

29

Szyperski (SZYPERSKI, 1998), WALLNAU (CBSE, 1999) classificam os componentes

em:

componentes de negcio, que so componentes que o domnio em si consegue

reconhecer, tais como cliente, contas, etc;

componentes de infra-estrutura, que so componentes de suporte aos componentes

de negcio, tais como segurana, auditoria, tratador de mensagens de erro, etc.

Existe tambm um consenso em relao importncia dos componentes de negcio,

apesar dos mesmos ainda no serem to bem explorados. Esta abordagem se deve ao fato
de que os pesquisadores na rea concordam que o que ir dar retorno em termos de
investimento para as empresas so os componentes que descrevem as funcionalidades do
negcio da empresa.
2.3.2 DBC e a Orientao a Objetos
Um grande foco de debate ainda hoje em relao a DBC a sua relao com a
orientao a objetos (OO). Do ponto de vista do desenvolvimento OO, podemos considerar
o DBC como uma evoluo do mesmo. Em particular, a evoluo se deve, principalmente,
em termos de como se d a construo de novos artefatos. No contexto do paradigma OO,
quando um novo comportamento precisa ser definido, este geralmente criado atravs da
reutilizao, ou herana, de um comportamento j existente no sistema, que ento
especializado. Em muitas situaes esta abordagem benfica. No entanto, podemos
observar que a mesma tem algumas limitaes. Por exemplo, para sistemas complexos, as
hierarquias de comportamento herdado podem se tornar estruturas pesadas, difceis de
serem entendidas e cheias de interdependncias que as tornam difceis de serem
modificadas. Assim, podemos considerar o DBC como uma evoluo da OO no sentido de
pregar construes onde as hierarquias de comportamento somente sejam permitidas no
contexto de um componente. Este tipo de dependncia no deve existir entre componentes,
enfatizando-se neste caso o uso de agregaes ao invs da herana.
A tecnologia de objetos bastante adequada para DBC, uma vez que os conceitos
importantes em DBC j so inerentes ao desenvolvimento OO, tais como encapsulamento e
polimorfismo. Um dos pontos conflitantes entre as duas tecnologias justamente o uso ou
no da herana. DBC, em geral, prega o no uso da herana da forma que ela usada em

30

OO. De acordo com HEINEMAN (1999), existem dois tipos de herana: essencial, que a
herana de um comportamento ou de uma caracterstica externa visvel, ou a herana
acidental, que a herana de parte ou toda a implementao de um objeto mais genrico.
No desenvolvimento OO, a herana acidental, feita estritamente para herana de cdigo,
leva a um projeto pobre. Outro problema, ressaltado por Heineman e tambm por
SZYPERSKI (1998), que a utilizao indiscriminada do mecanismo de herana leva a
uma hierarquia de classes muitas vezes complexa, o que dificulta seu entendimento. Assim,
se for necessria alguma modificao, o engenheiro de software tem que entender toda a
hierarquia. Como a dificuldade deste entendimento inerente, muitas vezes ao invs de
modificar uma dada classe prefere-se adicionar uma nova classe, o que leva a herana
acidental e ao projeto pobre.
No caso de DBC, isso ainda mais grave, pois um dado componente deve ser
conhecido apenas pelas suas interfaces externas. Assim, qualquer adaptao necessria
deve ser feita idealmente atravs destas interfaces. Se houver a necessidade de utilizar
herana ser a do tipo essencial, ou seja, herana de interfaces.
Para tentar superar estas dificuldades, o DBC prega que o comportamento e as
interfaces dos componentes sejam claramente especificados, sem ter que se preocupar com
estruturas herdadas e possveis modificaes na mesma. Alm disso, so providos
mecanismos que permitem a conexo dos componentes de forma flexvel, sendo que um
componente pode ser substitudo por outro similar a qualquer momento, sem haver a
necessidade de modificaes internas na estrutura dos componentes relacionados.
Apesar do DBC poder ser considerado uma evoluo do desenvolvimento OO, isso
no quer dizer que um componente tenha que necessariamente ser desenvolvido a partir da
tecnologia OO. Um componente pode conter procedimentos tradicionais, ou pode ser
desenvolvido inteiramente utilizando um abordagem de desenvolvimento estruturado, ou
outra qualquer. O que importa para que o mesmo seja caracterizado como sendo um
componente que esteja em conformidade com a definio de componentes em relao as
suas interfaces, arquitetura e funcionalidade, para citar somente os principais aspectos
(SZYPERSKI, 1998).

31

2.3.3 Distribuio e Heterogeneidade

Devido, principalmente, ao advento da Internet e da mudana da arquitetura
cliente/servidor para a idia de pequenas aplicaes que se comunicam pela WEB,
formando uma aplicao distribuda, a importncia da distribuio e interoperabilidade de
componentes heterogneos se disseminou pela comunidade de desenvolvedores de
software. Esta abordagem conhecida como componentware (SANTANNA, LEITE e
PRADO, 1998) e as previses apontam (KAPLAN, 1999) que este vai ser o grande
mercado nos prximos anos no que tange o desenvolvimento de software. Com esta
disseminao da abordagem de componentware criou-se uma certa confuso em relao ao
que seria efetivamente o DBC. Muitos acreditam que o DBC seria puramente uma
abordagem de componentware.
O componentware tem como objetivo o inter-relacionamento de componentes atravs
de modelos de objetos ou similares. Neste contexto, modelos de objetos como o COM da
Microsoft (Microsoft, 2000) e o CORBA da OMG (OMG, 2000) so utilizados,
descrevendo como os objetos se comunicam uns com os outros, no se preocupando com a
linguagem de programao, espao de endereamento, mquina ou sistema operacional
utilizados. Modelos de documentos como o OLE 2 da Microsoft e OpenDoc do CILabs
tambm so usados nesta abordagem. Como exemplo de utilizao desta abordagem temos
o desenvolvimento de componentes utilizando tecnologias como ActiveX, JavaBeans,
como o caso do projeto San Francisco, da IBM (IBM, 2000). A interoperabilidade em um
ambiente distribudo outra caracterstica marcante da abordagem, permitindo
componentes desenvolvidos em diferentes plataformas de hardware, sistemas operacionais
e linguagens de programao se comunicarem atravs de interfaces bem definidas. Outro
ponto importante que apenas componentes binrios so considerados, tais como
componentes DCOM, JavaBeans e CORBA (PARISH et al., 1999).
Apesar destas caractersticas serem importantes e desejveis em um componente, sua
importncia se deve, principalmente, pelo apelo do mercado por produtos na forma de
cdigo, ou seja, um componente que possa ser integrado ao cdigo de uma dada aplicao e
execute de forma adequada. Desta forma, em uma abordagem de desenvolvimento de
componentes, este seria o produto final do processo, onde este componente comeou a ser
delineado atravs da especificao de uma dada funcionalidade importante em um domnio

32

de aplicao. Somente desta forma, possvel inferir que o componente ser codificado
(espao da soluo) de acordo com as necessidades do domnio (espao do problema). A
abordagem de componentware enfatiza o produto final sem se preocupar com o processo
que foi utilizado para produzi-lo.
A utilizao da abordagem de componentware pura para DBC esbarra ainda em
alguns problemas como a falta de orientao em relao escolha dos componentes mais
adequados a um dado contexto e a melhor maneira destes componentes se relacionarem.
Muitas vezes, a forma de composio escolhida pelo desenvolvedor no a mais adequada,
e nem os componentes escolhidos so os que melhor atendem s necessidades da aplicao,
levando-se em considerao as caractersticas do ambiente e do domnio onde sero
utilizados. Um forma de atenuar estes problemas a especificao de uma arquitetura que
apresente a interao entre os componentes a serem utilizados em um dado contexto, alm
de um maior detalhamento das funcionalidades dos componentes. Por outro lado, a
abordagem de componentware tem uma caracterstica que a torna primordial no processo
de desenvolvimento atual, que a facilidade de permitir que componentes heterogneos
sejam agregados.
Assim, devemos considerar o DBC em um contexto mais amplo, sendo o
componentware apenas uma das tecnologias envolvidas. A fim de que uma abordagem
consistente de DBC tenha sucesso, primordial o entendimento dos conceitos que esto por
trs das funcionalidades disponibilizadas pelos componentes e seus relacionamentos; a
concretizao do conhecimento em componentes reutilizveis e o uso de um modelo que
apresente o interfaceamento entre os componentes (modelo arquitetural).
Entre os padres para interoperabilidade que surgiram no mercado nos ltimos anos,
ganharam maior destaque CORBA (OMG, 2000), DCOM (Microsoft, 2000) e RMI
(JAVASUN, 2000). Como apelo para sua utilizao, estes padres propem um alto nvel
de abstrao para viabilizar a interoperao dos componentes atravs da utilizao de
linguagens intermedirias, geradores de cdigo e linguagens para especificao de
interfaces.
A utilizao destes padres realmente facilita a interoperao dos componentes. No
entanto, resolve apenas um problema pontual na especificao de uma arquitetura de
software para DBC, e mesmo assim, conforme KAPLAN et al. (1999) ressaltam, muitas

33

vezes trazem outros problemas, tais como grande acoplamento da aplicao com o
mecanismo de interoperabilidade escolhido e no resolvem outros de maneira adequada,
como somente lidar com componentes binrios e a especificao da interface somente se
preocupar com a sintaxe das operaes.
Assim, apesar destes padres de interoperabilidade serem uma tecnologia que
facilita a interoperao dos componentes, esta por si s no pode ser considerada uma
abordagem para DBC. Ressaltando este argumento podemos observar que os mecanismos
de interoperao lidam somente com componentes binrios encapsulados em um invlucro
que possui as diretivas do mecanismo de interoperao. HAN (2000) argumenta que a
interoperao dos componentes dificultada tambm pela no compreenso das
capacidades dos componentes. Como os mecanismos de interoperao consideram apenas o
componente na sua forma binria, as capacidades ficam explicitadas nas descries de suas
interfaces. As abordagens atuais de definio de interfaces tratam somente questes
sintticas, como o caso da IDL de CORBA. O autor argumenta que para se compreender
de forma mais adequada um dado componente, dever-se-ia ter mais informaes sobre o
componente, tais como: a semntica dos elementos da interface; seu relacionamento, o
contexto de uso e os atributos de qualidade. Uma abordagem interessante proposta pelo
autor, onde as assinaturas das operaes so disponibilizadas pelo componente, incluindo
tambm a semntica de interao de cada elemento da assinatura e restries adicionais em
relao ao uso destas assinaturas.
2.3.4 Arquitetura de Software para conexo de componentes
Um dos pontos em que existe consenso entre os pesquisadores na rea de DBC
que um componente no pode ser visto de forma completamente independente de outros
componentes com os quais se relaciona e de seu ambiente. Sendo assim, a arquitetura de
software assume um papel de extrema importncia, pois a partir dela que podemos
especificar de forma mais detalhada como se d a interconexo entre componentes.
GARLAN et al. (1994) definem arquitetura de software em geral como sendo a
especificao e o projeto das estruturas de controle e de organizao de um dado sistema,
incluindo-se os protocolos de comunicao utilizados para conexo dos elementos
arquiteturais, sincronizao, acesso aos dados, escalabilidade, desempenho, distribuio
fsica e seleo entre alternativas de projeto. Neste contexto, um estilo arquitetural define

34

um vocabulrio comum de tipos de componentes e conectores, e um conjunto de regras de

como componentes e conectores podem ser combinados. importante ressaltar que, na
definio de GARLAN et al. (1994), os componentes e conectores arquiteturais so
especificados de maneira abstrata, sem se levar em considerao o tipo de funcionalidade
especfica que um dado componente disponibilizaria. Exemplos de estilos arquiteturais so
os estilos pipe and filter, broker, model-view-controller, entre outros. Desta forma, nenhum
tipo de considerao em relao ao domnio de aplicao do componente feita.
Segundo SZYPERSKI (1998), uma arquitetura de software para atender ao DBC
consiste de um conjunto de decises relacionadas seleo de alternativas de projeto em
relao plataforma operacional, ao modelo de composio dos componentes e ao projeto
de interoperao para o modelo de composio. Podemos notar, atravs desta definio,
que o autor separa claramente a arquitetura de software para DBC em trs aspectos
principais:
1. A infra-estrutura para interconexo dos componentes, que na verdade nos remete
definio de arquitetura de software e estilos arquiteturais, utilizados por Mary Shaw e
David Garlan (SHAW et al., 1996);
2. A composio dos componentes em termos funcionais, o que alguns autores
denominam de framework de componentes e outros de arquitetura do domnio
(DIGRE, 1998). A idia de composio estaria ligada necessidade de ligao dos
componentes para a especificao da funcionalidade desejada em um dado contexto;
3. A interoperao, introduzindo uma viso mais ligada distribuio e heterogeneidade
dos componentes. Neste contexto, a interoperao seria a capacidade de dois ou mais
componentes

de

software

se

comunicarem

ou

trabalharem

em

conjunto,

independentemente da linguagem de programao em que foram escritos ou de seus

domnios de execuo.

Todos estes pontos so muito importantes em DBC. No entanto, consideramos que

uma arquitetura de software para DBC seria mais ligada composio dos componentes e
infra-estrutura para esta conexo. A interoperao, item 3, trata-se de uma deciso
arquitetural ligada infra-estrutura de conexo, uma vez que para que a interoperao seja
realizada, pressupe-se a utilizao de um mecanismo tal como um barramento CORBA,

35

RMI, entre outros. Este barramento parte integrante da infra-estrutura para a interconexo
de componentes.
A infra-estrutura necessria para a conexo dos componentes vem ao encontro das
especificaes de estilos arquiteturais definidas por SHAW e GARLAN (1996). Assim,
esta infra-estrutura seria composta pelos servios bsicos, restries e ligaes semnticas
que devem estar disponveis em uma aplicao que siga um determinado estilo arquitetural.
BUSHMMAN (1996) descreve os vrios estilos arquiteturais por meio de padres,
apresentando os diversos servios e ligaes arquiteturais ligadas a um dado estilo. Por
exemplo, um dos padres apresentados por BUSHMMAN (1996, pp. 99-122) descreve
uma configurao arquitetural para sistemas distribudos. feita toda uma discusso a
respeito dos principais aspectos do padro e, ao final, so apresentados modelos estruturais
e comportamentais de como se daria a interao entre os elementos de uma aplicao que
seguisse este estilo arquitetural. Assim, o que na verdade so apresentados so os servios e
a infra-estrutura necessria para que uma aplicao se comporte como um sistema
distribudo. No feita nenhuma considerao em relao s funcionalidades que os
componentes da aplicao devem disponibilizar. Este estilo arquitetural dominante mais
dependente da aplicao em si e do ambiente onde ela ser executada. O que teramos a
mais em DBC seria o modelo de componentes do domnio ou frameworks de componentes
que seria especfico para um dado domnio. Derivar uma especificao de estilo arquitetural
para um conjunto de componentes reutilizveis de forma independente da aplicao que ir
utiliz-los no uma tarefa simples. Existem alguns domnios de aplicao mais estveis
onde se pode observar uma certa tendncia em que todas as aplicaes do domnio sigam
um dado estilo arquitetural, como por exemplo, o domnio de telecomunicaes, onde um
estilo arquitetural distribudo utilizado pela maioria das aplicaes. Nestes casos, pode-se
pensar em termos de um estilo arquitetural predominante, mas mesmo assim pode existir
uma ou outra aplicao que no se encaixe perfeitamente no estilo arquitetural
predominante.
A parte mais estvel da definio dada por SZYPERSKI (1998) a composio dos
componentes em termos funcionais (item 2). Este framework de componentes uma
estrutura mais estvel em relao ao domnio e no to dependente das especificidades do
ambiente em que a aplicao ser desenvolvida e executada. Podemos considerar que este

36

um modelo derivado a partir das especificaes dos componentes, ou seja, dos modelos de
anlise que especificam os componentes. O que vai mudando a forma de representao,
indo de um alto nvel de abstrao, na fase de anlise, at um detalhamento maior, nas fases
de projeto e codificao. Este o modelo que caracteriza o porqu de se reutilizar um dado
componente no contexto de uma dada aplicao de um certo domnio e, mais importante
ainda, como se d a interao com os outros componentes para a especificao das
funcionalidades necessrias aplicao. Esta interao deve ser regulada por um conjunto
de restries, tais como a ordem de chamada de operaes, pr e ps condies funcionais,
entre outras. DIGRE (1998) considera esta parte da especificao arquitetural como a mais
importante de todo o modelo de DBC.
A interoperao dos componentes, a terceira caracterstica (item 3) da descrio de
arquitetura de DBC dada por SZYPERSKI (1998), faz parte do estilo arquitetural escolhido
(item 2). SAMETINGER (1997) define a interoperao de componentes como a habilidade
dos componentes de se comunicar e cooperar sem levar em considerao diferenas de
linguagem, plataforma de execuo e interfaces. O autor ainda ressalta que a composio
de componentes no implica, necessariamente, na sua interoperao. Assim, quem ir
resolver os problemas de interoperabilidade ser o estilo arquitetural escolhido.
Em (GARLAN et al., 1994), so descritos alguns enganos arquiteturais
(architectural mismatches) que podem ocorrer quando se constri uma aplicao a partir de
componentes. So descritas algumas categorias com possibilidade de ocorrer enganos:

natureza do componente, incluindo suporte de infra-estrutura que o componente

pode necessitar, modelo de controle de sincronizao e modelo de dados;

natureza dos conectores, onde problemas podem ser encontrados nos protocolos
utilizados e tipos de dados a serem transmitidos pelos conectores;

estrutura da arquitetura, que pode apresentar problemas em termos das

interaes entre os componentes;

processo de construo, principalmente relacionados a problemas de

heterogeneidade dos componentes.

37

Para tentar minimizar estes possveis enganos, Garlan prope algumas diretivas:

utilizar uma descrio arquitetural padronizada e bem definida em termos de

modelos e restries;

utilizar componentes previamente desenvolvidos para serem reutilizados, onde

os pontos de conexo em suas interfaces estejam bem documentados e
explicitados;

utilizar invlucros (wrappers) e um software de conexo (middleware) sempre

que problemas de compatibilidade de interfaces ocorrerem;

tentar se basear em modelos arquiteturais de sucesso e que forem bem

documentados (uso de padres arquiteturais).

Assim, uma arquitetura de software para DBC, caracterizada pelo estilo arquitetural
e por um modelo funcional de conexo de componentes, auxilia nas questes levantadas
por Garlan, elucidando a natureza do componente, atravs do uso do modelo funcional, a
natureza dos conectores, descrevendo-se os tipos de conexo necessrias para atender s
necessidades funcionais dos componentes e tambm ao estilo arquitetural adotado; a
estrutura da arquitetura, descrita pelo estilo arquitetural e o processo de construo, que
engloba o processo de construo do componente como um todo.
2.3.5 Mtodos para desenvolvimento de componentes
Como todo processo de desenvolvimento de software, preciso prover uma
sistemtica (i.e. mtodos) para o desenvolvimento baseado em componentes, devendo ser
cuidadosamente planejada e controlada para ser efetiva. Assim, necessria uma
abordagem que enfatize a reutilizao em todas as etapas do desenvolvimento.
Podemos dividir o processo de desenvolvimento em duas etapas: desenvolvimento
para reutilizao e desenvolvimento com reutilizao (KRUEGER, 1992). Colocando esta
abordagem sobre o prisma do desenvolvimento baseado em componentes, mudaramos um
pouco a nomenclatura e teramos a mesma diviso: desenvolvimento de componentes e
desenvolvimento com componentes. Em (LIM, 1998), ainda considerada a importncia do
apoio de uma infra-estrutura para o processo como um todo.
Conforme visto anteriormente, o desenvolvimento de componentes pode ser visto
como um processo de engenharia de domnio, que seria o desenvolvimento para

38

reutilizao seguindo a nomenclatura utilizada por ARANGO (1988). Nesta abordagem,

so trs as etapas envolvidas: anlise de domnio, projeto de domnio e implementao.
Entretanto, alguns autores (SAMETINGER, 1997), (HALLSTEINSEN e SKYLSTAD,
1999) vem o desenvolvimento de componentes como uma etapa posterior engenharia de
domnio. Esta viso se deve, principalmente, ao fato de que estes autores consideram
componentes como itens implementacionais, sendo os modelos utilizados para a construo
dos componentes relacionados a cdigo considerados como documentao.
Ao considerar componentes muito mais do que somente cdigo, uma abordagem de
desenvolvimento de componentes, pode ser vista como um processo de engenharia de
domnio completo, onde a preocupao, alm de ser com a disponibilizao de
componentes em todos os nveis de abstrao, no com uma nica aplicao, mas com
uma famlia de aplicaes. Assim, o grau de reutilizao de um dado componente ser
muito maior e seu entendimento tambm, uma vez que este componente ser
disponibilizado tanto para especificao (mais fcil de ser entendido pelo usurio) quanto
para cdigo.
Por outro lado, o desenvolvimento com componentes deve ser visto como um
processo de desenvolvimento de aplicaes, onde a reutilizao de componentes deve estar
presente em todas as fases. Tambm neste ponto, podemos ver muita confuso em relao a
como reutilizar os componentes e muitos dos mtodos considerados para DBC no
promovem a reutilizao de componentes em todas as etapas, considerando esta
reutilizao principalmente para componentes implementacionais. Conforme ressaltam
FORSELL et al. (2000), muitas mesclam o desenvolvimento de componentes com o
desenvolvimento com componentes, fazendo as duas etapas ficarem misturadas. Com isso,
no se enfatiza tanto o desenvolvimento de componentes genricos, mas sim somente o
compartimentar a aplicao em partes interoperveis, sem a preocupao inerente de se
construir componentes para serem reutilizados em contextos alm dos quais eles foram
originalmente construdos, uma vez que os componentes so construdos especificamente
para serem utilizados na aplicao. Nenhum compromisso com flexibilidade de extenso,
generalidade utilizado. Assim, um processo detalhado e bem definido melhorar
substancialmente o DBC.

39

Para termos um mtodo de DBC que possa ser realmente efetivo, devemos buscar
inspirao nos mtodos essencialmente baseados em reutilizao, tanto no que diz respeito
ao desenvolvimento de componentes quanto ao desenvolvimento com componentes.
Existem atualmente alguns mtodos de desenvolvimento de software baseados em
componentes que se mostram promissores. O primeiro deles baseado no trabalho de Ivar
Jacobson, Martin Griss e P. Jonsson, descrito em (JACOBSON et al., 1997). Este trabalho
apresenta o desenvolvimento de software baseado em componentes de forma genrica. O
mtodo baseado no paradigma OO e em padres como UML e CORBA e utiliza casos de
uso como ponto de partida para a identificao dos componentes reutilizveis. O mtodo,
seguindo a caracterstica bsica do DBC, d maior destaque parte comportamental dos
objetos. Outro mtodo que vem despontando no contexto de DBC o Catalysis (DSOUZA
et al., 1998). O mtodo Catalysis tambm fortemente baseado no uso de objetos,
frameworks e padres, alm de privilegiar o desenvolvimento de aplicaes distribudas.
Neste sentido, o Catalysis consegue unir as duas tecnologias atualmente consideradas no
desenvolvimento baseado em componentes, ou seja, a orientao a objetos e a computao
distribuda.
No entanto, ainda est por surgir um mtodo para DBC que privilegie, alm da OO
e computao distribuda, tcnicas que permitam o empacotamento de componentes com o
objetivo especfico de serem reutilizados, levando em considerao a captura de abstraes
que facilitem o entendimento dos componentes, e com processos bem identificados e
detalhados tanto para o desenvolvimento de componentes (desenvolvimento para
reutilizao) como para o desenvolvimento com componentes (desenvolvimento com
reutilizao).
Alm dos mtodos, o apoio de um ambiente de suporte automatizado tambm
importante para o DBC. BROWN e WALLNAU (1998) apresentam alguns elementos
bsicos que devem ser considerados na utilizao de ferramentas em DBC. Segundo estes
autores, existem 4 elementos bsicos que uma ferramenta automatizada para DBC deve
apresentar: um repositrio de componentes, que utilizado para armazenar os componentes
a serem utilizados no processo, uma ferramenta de modelagem baseada em componentes,
que permita a descrio de uma aplicao completa em termos de seus componentes e suas
interaes, um gerador de aplicaes, para a criao de aplicaes baseadas em

40

componentes, e uma ferramenta de busca de componentes, para a busca e seleo dos

componentes de interesse.
2.3.6 Repositrio de Componentes
SAMETINGER (1997) conceitua repositrio de componentes como sendo uma base
preparada para o armazenamento, seleo e obteno de componentes. Apesar do uso de
repositrios de componentes ser considerado uma caracterstica operacional, consideramos
que o sucesso do DBC est intrinsecamente ligado aos mecanismos para a disponibilizao
de componentes reutilizveis, e a utilizao de um repositrio caracterstica bsica para
isso. Assim, consideramos a utilizao de um repositrio de componentes caracterstica to
importante quanto a distribuio e interoperabilidade, conforme iremos apresentar nos
captulos seguintes desta tese.
Para que esta recuperao seja efetiva, SAMETINGER (1997) ressalta a
importncia do armazenamento de informaes adicionais relativas ao componente. A
chance que um desenvolvedor tem de reutilizar um dado componente, ao invs de
desenvolver um novo, depende da disponibilidade do componente em um repositrio, de
forma que este possa ser facilmente localizado e recuperado.
O autor distingue ainda trs tipos de repositrios, a saber:

Repositrios locais: armazenam componentes de propsito geral;

Repositrios especficos a um domnio: armazenam componentes especficos,

com escopo bem definido, podendo prover componentes alternativos para as
mesmas tarefas;

Repositrios de referncia: auxilia na busca por componentes em outros

repositrios, funcionando como uma espcie de pginas amarelas.

De acordo com SEACORD (1999), repositrios locais e centralizados que

armazenam componentes genricos historicamente falharam, principalmente por conta de
serem repositrios centralizados e inchados. Outros autores reforam tambm esta posio.
BANKER et al., em (SAMETINGER, 1997), argumentam atravs de constataes na
prtica, que o grau de reutilizao no aumenta com o aumento do nmero de componentes
disponveis. Assim, a soluo e evoluo destes repositrios locais genricos foi organizlos por domnios de aplicao, o que diminui o escopo dos componentes a serem

41

consultados em uma busca. Entretanto, melhora os resultados da busca, uma vez que os
componentes so mais focados em relao chave de busca.
No entanto, com o advento da Internet e a disponibilidade de informaes
distribudas e heterogneas, permitiu-se que se tenha acesso a repositrios distribudos, o
que aumenta a gama de componentes disponveis. Assim, uma abordagem que os autores
na rea vem como promissora a interconexo de repositrios atravs de um mecanismo
como os chamados repositrios de referncia. O sistema Agora (SEACORD, 1999) utiliza
uma abordagem similar a de repositrios de referncia. No entanto, os mecanismos de
busca empregados, atravs de introspeo de componentes de cdigo, limitado tanto
semanticamente quanto na abrangncia, uma vez que somente recupera componentes
binrios CORBA e JavaBeans. Os prprios autores apresentam como limitador de sua
abordagem a falta de informaes descritivas acerca dos componentes, ou seja, adicionar
mais semntica ao componente, de forma que a busca seja mais precisa. Atributos no
funcionais tambm devem ser levados em considerao nesta abordagem, tais como
confiabilidade, desempenho, disponibilidade, etc. Em (MERAD, 1999), apresentada uma
proposta que considera estes aspectos. Outros aspectos que devem ser tratados so
unicidade do componente, copyrights, privacidade e comrcio dos componentes via
Internet.
2.3.6.1 Busca e seleo dos componentes

Quando se considera um repositrio de componentes, uma questo importante

como se d a busca e seleo destes componentes armazenados no repositrio. Esta busca e
seleo de componentes est intrinsecamente relacionada qualidade dos mecanismos de
classificao dos mesmos. Vrios mtodos de classificao de componentes j foram
descritos na literatura. Dentre eles podemos citar: texto livre, classificao por palavraschave (BARROS, 1995), classificao enumerada, faceta e pares de atributos.
A classificao por texto livre a mais simples de todas. No requer nenhum tipo de
preparao, apenas a disponibilidade de uma documentao textual. A busca por palavraschave tambm bastante simples, bastando que o desenvolvedor do componente utilize um
conjunto de palavras de forma livre, ou a partir de um vocabulrio controlado. A utilizao
de texto livre e palavras-chave permitem casamentos perfeitos, ou no mximo
aproximaes baseadas nos radicais das palavras. No entanto, o uso deste tipo de busca por

42

si s tem um alto grau de inexatido, o que resulta na recuperao de componentes

inadequados.
A criao de hierarquias de termos, denominada classificao enumerada outra
forma utilizada para classificar componentes para a busca. Sua vantagem que fcil de
ser entendida e utilizada. Como desvantagem, SAMETINGER (1997) cita sua
inflexibilidade. Novos tpicos s podem ser inseridos em nveis mais baixos da hierarquia.
Outro problema a ambigidade, uma vez que um dado componente pode pertencer a
vrias categorias.
A classificao por facetas (PRIETO, 1991) outra abordagem bastante utilizada.
As facetas so baseadas no vocabulrio de um domnio particular, onde so consideradas
perspectivas, pontos de vista e dimenses deste domnio. Os componentes so classificados
segundo o conjunto de facetas. A vantagem da utilizao do mecanismo de facetas que
relaes complexas podem ser criadas combinando facetas com termos e modificaes no
esquema podem ser feitas sem modificar as facetas j existentes e suas ligaes. A
classificao por pares de atributos pode ser considerada um super conjunto da
classificao por facetas onde mais combinaes podem ser utilizadas. Uma das
desvantagens do mecanismo de facetas que utiliza a figura do bibliotecrio para a criao
das facetas ao passo que deveria ser sim um especialista do domnio.
No entanto, at o momento, nenhum destes mtodos se mostrou realmente eficiente
para a busca e seleo de componentes. Um estudo emprico realizado por Frakes e Poulin
(FRAKES, 1994) em relao aos mtodos de classificao por palavras-chave, enumerao,
atributos/valor e facetas mostrou que nenhum dos mtodos vantajoso em relao aos
demais em termos de resultados. POULIN et al. (1995) mostraram ainda, atravs de
experincias com vrios mecanismos de classificao para busca por componentes, que a
melhor tcnica at ento era a combinao dos mecanismos. No caso especfico de sua
experincia, que era baseada em componentes na forma de cdigo, mecanismos de busca
baseados em texto e a adoo de ordem hierrquica se mostraram mais promissores.
Assim, embora j bastante explorado este tema, ainda hoje investiga-se um
mecanismo eficiente para a busca e seleo de componentes. Esta um rea de pesquisa
proeminente em DBC. MILI et al. (1995) formalizam o problema da busca e recuperao
por componentes da seguinte forma:

43

1. O espao do problema;
2. O espao do problema da forma que o desenvolvedor entende;
3. O espao da consulta, que consiste da necessidade que o desenvolvedor
conseguiu entender traduzida para uma consulta que possa ser entendida pelo
sistema de busca.

Estes trs pontos precisam ser o mais prximo possvel um dos outros, de forma que
os componentes certos sejam recuperados. Outro ponto importante que atualmente esta
busca deve ser a mais automatizada e transparente possvel para o usurio, uma vez que,
com a Internet, a busca por componentes se tornou uma atividade muito mais complexa
devido disponibilidade de um grande nmero de componentes desenvolvidos por terceiros
e que podem estar distribudos ao longo da rede. Assim, deve-se considerar uma abordagem
onde se mescle tcnicas consagradas de busca por componentes, como o mecanismo de
facetas ou similar, busca por palavras-chave, entre outras, levando tambm em
considerao tcnicas que se mostram promissoras para busca na WEB, como tcnicas de
aprendizado, e a natureza distribuda dos componentes.
2.3.7 Outros tpicos de pesquisa em DBC
Existem ainda na literatura vrios outros tpicos de pesquisa em DBC que esto
comeando a ser evidenciados. Apesar das pesquisas ainda estarem incipientes, estas se
mostram bastante promissoras. Dentre eles esto a certificao da qualidade de
componentes e a evoluo e adaptao dos mesmos.

Certificao da qualidade de componentes

No CBSE 2000, um dos temas discutido foi a qualidade de componentes e
mecanismos para se certificar esta qualidade. No entanto, ainda no se tem um consenso em
relao a quais atributos de qualidade um componente deve ter. HAN (2000) define como
atributos de qualidade os aspectos no funcionais de um componente, tais como segurana,
performance e confiabilidade. SAMETINGER (1997) tambm define algumas propriedades
que deveriam ser analisadas na avaliao da qualidade de um dado componente. So elas:
uso de recomendaes, realizao de testes baseados em algum padro de testes, clareza

44

conceitual (um componente deve ser claro e fcil de ser entendido), definies precisas para
o grau de acoplamento e coeso.
Outro ponto importante na anlise da qualidade de um dado componente que no
podemos esquecer da caracterstica de composio de um componente. Assim, um ponto
fundamental analisar a qualidade de

um componente em termos da arquitetura de

software na qual ou nas quais ele est inserido. J existem alguns trabalhos na rea de
anlise de qualidade de arquiteturas de software como os trabalhos realizados no SEI com
os mtodos SAAM e sua evoluo ATM (KAZAM, 2000).
SAMETINGER (1997) apresenta tambm uma primeira proposta para nveis de
certificao de componentes. Estes nveis, segundo o autor, vo depender da natureza,
freqncia de reutilizao e importncia do componente no contexto. Os nveis destacados
por Sametinger so os seguintes:

Nvel 1: O componente descrito por palavras-chave e armazenado para

recuperao automtica. Nenhum teste realizado e o nvel de completude
desconhecido;

Nvel 2: O componente de cdigo compilado. Mtricas so definidas e

utilizadas para uma linguagem em particular;

Nvel 3: So realizados testes, dados e resultados dos testes so adicionados aos

componentes;

Nvel 4: Um manual de reutilizao adicionado.

Evoluo e adaptao de componentes

Outra preocupao que os pesquisadores esto levando em considerao em relao
adoo efetiva do desenvolvimento baseado em componentes, a evoluo e adaptao dos
componentes a fim de que possam ser reutilizados em diferentes contextos. BRERETON
(1999) ressalta que esta dificuldade grande, principalmente, em relao evoluo do
sistema, uma vez que esta responsabilidade de evoluo distribuda entre diversos autores
e organizaes proprietrias dos componentes.
Brereton apresenta alguns tpicos relacionados evoluo de componentes. Ele
divide estes tpicos em trs grandes reas:

45

Negcios: responsabilidade pela mudana (deve-se ter claramente o responsvel

pela mudana do componente e sua integrao no sistema); risco de mudana
(riscos inerentes mudana, tais como anlise do impacto de mudana de um
componente em um sistema como um todo); pagamentos pela mudana; suporte a
longo prazo.

Gerenciamento: diretivas para mudana (o quanto a mudana necessria);

restries para sistemas distribudos (os componentes residem nos seus sites
remotos e preciso lidar com questes, tais como trocar um componente por uma
nova verso sem notificar os usurios ou notificando-os; deixar os usurios
escolherem se querem utilizar a verso antiga, novos usurios s utilizam a verso
nova); documentao e descrio de componentes.

Tcnicas: atualizar um dado componente por um novo componente do mesmo

fornecedor ou de fornecedores diferentes; adicionar e remover componentes;
localizar, entender e avaliar componentes adicionais ou que vo ser trocados;
determinar o impacto da mudana no sistema como um todo; avaliar os custos de
testar novamente o sistema; avaliar o risco com a adoo de novos fornecedores.

SZYPERSKI (1998) e SAMETINGER (1997) argumentam que para minimizar estas

questes de adaptao, um componente deve idealmente ser adaptado baseado apenas na
sua interface externa. Assim, adaptaes e evolues necessrias seriam feitas apenas no
mbito da interface, podendo-se at criar novas verses de interfaces.
2.4 Mtodos de Desenvolvimento Baseado em Componentes e de
Engenharia de Domnio Existentes
Analisamos a seguir alguns mtodos de ED e de DBC que se destacam na literatura.
Esta anlise feita com base no framework de comparao utilizado no estudo de
viabilidade do mtodo FODA (KANG et al., 1990), que apresenta trs principais aspectos a
serem considerados na avaliao de um mtodo:
a) processo: como o mtodo ir afetar uma dada organizao que o adota; como feita a
gerncia e a manuteno dos produtos; como a representao do conhecimento do

46

domnio nos produtos e como os usurios podem aplicar efetivamente os produtos no

desenvolvimento de aplicaes no domnio;
b) produto: quais so os tipos de produtos gerados pelo mtodo; como so representados e
o quo aplicveis estes so no desenvolvimento de aplicaes no domnio;
c) ferramentas para automatizar o processo: disponibilidade de ferramentas
automatizadas que auxiliem na utilizao do mtodo. Como estas ferramentas esto
integradas, facilidade de uso das mesmas e sua robustez.

Os mtodos analisados so os clssicos, tais como FODA (KANG et al., 1990),

ODM (SIMOS, 1996) e EDLC (GOMMA, 1995), dos quais foram derivados os principais
mtodos de ED disponveis atualmente; mtodos derivados diretamente do FODA, como
FORM (KANG et al., 1998) e FeatuRBSE (GRISS et al., 1998); e outros mtodos
derivados de abordagens clssicas, como o OODE (CHAN et al., 1998). Estes mtodos
possuem idias interessantes que podem ser aplicveis no contexto do DBC, principalmente
para a fase de modelagem de domnio, servindo de guia posterior para o empacotamento
dos componentes, que no so atividades bem desenvolvidas pelos mtodos de DBC. Alm
destes, que foram desenvolvidos com o propsito de serem realmente mtodos de ED,
analisamos tambm alguns mtodos de desenvolvimento de aplicaes que representam
abordagens de DBC, a saber, RSEB (JACOBSON et al., 1997) e Catalysis (DSOUZA et
al., 1998).
2.4.1 FODA (Feature Oriented Domain Analysis)
O mtodo de anlise de domnio FODA (KANG et al., 1990) foi criado no contexto
dos projetos de pesquisa do SEI (Software Engineering Institute), tornando-se um dos
mtodos de anlise de domnio mais populares no incio da dcada de 90. Os autores
descrevem o FODA como um mtodo para dar suporte reutilizao no nvel arquitetural e
funcional. No entanto, os estudos apresentados na literatura descrevem principalmente a
modelagem de estudos de caso na fase de anlise, dando nfase modelagem funcional,
mas no apresentando com detalhes a parte arquitetural e nem as ligaes entre os diversos
modelos.
A abordagem adotada pelo FODA bastante interessante do ponto de vista do DBC,
uma vez que a captura das funcionalidades relevantes ao domnio auxilia na identificao

47

de que componentes, disponibilizando quais funcionalidades, estariam disponveis no

domnio. Outro ponto interessante, mas que no muito ressaltado nos estudos de caso
conduzidos, a possibilidade de modelagem de caractersticas adicionais ao domnio como
a modelagem dos ambientes operacionais disponveis e as tcnicas de implementao. Estas
informaes auxiliam o desenvolvedor na seleo das funcionalidades mais adequadas,
levando-se em considerao o ambiente operacional e as questes implementacionais.

Processo

Descreve um processo de desenvolvimento de modelos para anlise de domnio

que pode se encaixar no processo de desenvolvimento de uma organizao, uma
vez que o tipo de modelo disponibilizado, ( modelos hierrquicos, ER, DFD)
so entendidos pela comunidade de desenvolvimento de software. No entanto,
com o uso de novas tecnologias como OO, pode haver uma certa dificuldade de
adaptao dos modelos do FODA (mais centrado no desenvolvimento
estruturado) com os modelos das aplicaes (se for utilizada uma abordagem
OO). Outro ponto importante que no existe nenhum ponto formal de
validao, sendo esta validao feita de maneira ad-hoc pelos especialistas.

Produto

Os produtos disponibilizados so compatveis com o desenvolvimento

estruturado e desta forma entendidos pelos desenvolvedores.
Nas etapas de especificao da arquitetura e implementao, no existe um
detalhamento maior de como especificar os modelos desta fase.

Ferramental Automatizado

No existem ferramentas especficas e integradas para o suporte ao

desenvolvimento com o FODA. O conjunto de ferramentas 001(KANG et al.,
1991) foi utilizado em um dos estudos de caso do FODA. No entanto, o suporte
dado pelo 001 limitado, no suportando as ligaes entre modelos, o
desenvolvimento de aplicaes no domnio e nem uma estrutura de
armazenamento para os modelos.

Tabela 2.2 Principais caractersticas do FODA

Uma crtica que pode ser feita ao mtodo que por ser a modelagem centrada na
captura das funcionalidades do domnio, todos os modelos utilizados carregam esta
caracterstica. O mtodo dito ser muito preocupado com a gerao de cdigo, e no se
preocupa com a devida nfase na captura de todas as abstraes do domnio. A
preocupao somente com caractersticas funcionais das aplicaes no domnio.
Caractersticas ditas no codificveis acabam por serem descartadas na modelagem do

48

FODA. Estas caractersticas (no codificveis) tambm so importantes no contexto do

domnio, principalmente para facilitar o reutilizador no entendimento dos conceitos e
assim, consequentemente, facilitar o entendimento dos componentes, promovendo de forma
mais eficiente a reutilizao de componentes no desenvolvimento de aplicaes no
domnio. Alm disso, o FODA no apresenta um detalhamento maior em relao criao
de componentes reutilizveis. O mtodo se atm modelagem das caractersticas, mas no
especifica como criar componentes.
2.4.2 ODM (Organization Domain Modelling)
O mtodo de engenharia de domnio ODM (SIMOS, 1996) , conforme ressaltado
pelos prprios autores, um mtodo altamente configurvel e customizvel. Podemos
considerar o ODM um framework para a criao de mtodos de engenharia de domnio
particularizados, de acordo com as necessidades das organizaes.

Processo

O ODM possui fases bem definidas em relao engenharia do domnio. No

entanto, por ser um processo genrico, no possui um detalhamento maior dos
produtos gerados em cada uma das fases. Um aspecto interessante e que no
tratado com igual nfase pelos outros mtodos de ED a fase de planejamento,
onde proposto um estudo para se analisar a viabilidade ou no de se realizar a
ED naquele domnio.
Possui tambm um enfoque bastante gerencial do processo de reutilizao.
Como os usurios iro aplicar os produtos da ED no desenvolvimento de
aplicaes ir depender da customizao a ser realizada.

Produto

Os produtos gerados pelo mtodo sero modelos de anlise, arquiteturais e

implementacionais. Como sero representados depender da customizao a ser
feita e de sua aplicao.

Ferramental Automatizado

O ODM em si no possui nenhum suporte automatizado. Em alguns projetos

especficos foram criadas ou utilizadas algumas ferramentas de modelagem,
mas no existe nenhum tipo de suporte efetivo para auxiliar no processo de
entendimento e posterior reutilizao de informaes no domnio.

Tabela 2.3 - Principais caractersticas do ODM

Um aspecto interessante do mtodo a grande preocupao com o planejamento e

organizao do domnio. O ODM ressalta a importncia da escolha correta de um domnio

49

onde ser aplicada a ED, uma vez que o processo caro e uma escolha errada pode
comprometer o projeto em questo e novos projetos que possam surgir.
O ODM j foi aplicado em vrios projetos mas sempre com a caracterstica de ser
particularizado para cada um deles. Esta particularizao complicada de ser realizada,
pois envolve decises que muitas vezes so difceis de serem tomadas, tais como, que
tecnologias se deve utilizar, qual a melhor representao a ser adotada, entre outros. Alm
disso, pela prpria dimenso do ODM, ele um mtodo para ser aplicado em grandes
organizaes, onde um planejamento a nvel gerencial realizado.
2.4.3 EDLC (Evolutionary Domain Life Cycle)
O EDLC um mtodo de engenharia de domnio criado na Universidade de George
Mason pelo pesquisador Gomaa e sua equipe. O EDLC adota uma abordagem gerativa de
aplicaes em um dado domnio, em contraste com a abordagem de componentes adotada
pelo FODA.
Processo

A abordagem adotada pelo EDLC baseada na especificao de mltiplos

modelos que esto relacionados entre si. Por ser a abordagem baseada no
paradigma OO, facilmente reconhecida pelos desenvolvedores OO, o que
facilita sua integrao no processo de desenvolvimento das aplicaes. No
entanto, as representaes disponibilizadas pelo ambiente de suporte podem
dificultar a integrao dos modelos no desenvolvimento de aplicaes do
domnio, a no ser que este desenvolvimento seja realizado totalmente no
contexto do ambiente de suporte. A manuteno dos produtos gerados em
mltiplas representaes, que como o ambiente de suporte realiza a
verificao pode tambm representar um problema.

Produto

Os tipos de produtos disponibilizados, conforme descrito pelo mtodo, so

prioritariamente modelos de anlise. Na literatura disponvel a respeito do
mtodo no so especificados modelos arquiteturais. Um aspecto interessante
a verificao de consistncia entre os diversos modelos.

Ferramental Automatizado

O suporte automatizado feito atravs do ambiente KBSEE (Knowledge Based

Software Engineering Environment). Um aspecto interessante do ambiente o
uso de mecanismos de inferncia para a checagem de consistncia entre os
modelos. Um ponto fraco a falta de integrao das ferramentas, o que leva
necessidade de transformao em mltiplas representaes. Outro ponto fraco
a falta de suporte para a fase de projeto e implementao.

Tabela 2.4 Principais caractersticas do EDLC

50

Utiliza fortemente a orientao a objetos em seus modelos, inclusive incluindo uma

representao grfica dos mesmos. Outro ponto interessante do EDLC a verificao de
consistncia que se faz entre os diversos modelos gerados. Com isso, se tem uma maior
garantia da corretude e consistncia dos mesmos. Para esta checagem de consistncia, o
EDLC usa uma base de regras e um mecanismo de inferncia.
Alm disso, o EDLC, atravs do seu ambiente de suporte automatizado, permite a
gerao dos modelos de anlise adequados a uma dada aplicao, verificando possveis
inconsistncias.
No entanto, o EDLC possui alguns pontos crticos, por ser baseado em uma
abordagem gerativa. Sua aplicao fica limitada a domnios muito bem definidos e
maduros, onde no existe uma evoluo contnua do domnio. A bibliografia disponvel
sobre os projetos onde ele foi utilizado somente descreve a fase de anlise, no havendo um
detalhamento da fase de projeto. O prprio ambiente automatizado no possui suporte para
a fase de projeto e implementao, o que crtico em uma abordagem gerativa.
2.4.4 FORM (Feature-Oriented Reuse Method)
O mtodo FORM (KANG et al., 1998) uma evoluo do mtodo FODA, onde um
maior detalhamento de questes arquiteturais e implementacionais foi adicionado. O
mtodo ficou mais voltado para o detalhamento de como desenvolver componentes a partir
das caractersticas identificadas. Para isso, utiliza tcnicas como templates, gerao
automtica de cdigo, parametrizao, entre outros, para o desenvolvimento dos
componentes.
Novamente, a maior crtica a ser feita ao mtodo, assim como o FODA, a nfase
dada s funcionalidades do domnio em detrimento de outros aspectos, tais como captura de
conceitos do domnio, caractersticas como desempenho, portabilidade, entre outros, que
merecem destaque.
Entretanto, para um completo entendimento do domnio e suas abstraes,
necessitamos de uma descrio mais detalhada no s das funcionalidades do domnio mas
tambm de seus conceitos. Alm disso, no existe um suporte automatizado para o mtodo,
o que dificulta sua aplicao.

51

Processo

Descreve um processo de ED completo, detalhando inclusive a fase de projeto e

implementao do domnio. Os modelos especificados seguem uma abordagem
OO e de componentizao, o que facilita sua integrao no desenvolvimento de
software atual.

Produto

O principal produto disponibilizado pelo mtodo o modelo de caractersticas,

onde as principais caractersticas (sob um prisma de construo de software) so
explicitadas. Uma abordagem interessante so as regras de composio e o
armazenamento de decises tomadas em relao ao modelo de caractersticas.
Os modelos arquiteturais e implementacionais no so bem detalhados. So
apenas disponibilizadas diretivas para auxiliar na sua criao. As caractersticas
selecionadas para uma dada aplicao seriam os guias para a criao da
arquitetura. Nenhum detalhamento de como criar explicitamente a arquitetura e
seus componentes, inclusive especificando interfaces, dado.

Ferramental Automatizado

No existe nenhum suporte automatizado. Pela complexidade na seleo das

caractersticas e verificao manual de consistncia (que um dos pontos fortes
do mtodo) a aplicao do mtodo se torna bastante difcil.

Tabela 2.5 Principais caractersticas do FORM

2.4.5 OODE (Object-Oriented Domain Engineering)
O mtodo de engenharia de domnio OODE (CHAN et al., 1998) centrado
principalmente em dois pilares: a orientao a objetos e a distribuio. um mtodo
desenvolvido internamente na BOEING para atender demanda de seus projetos de
desenvolvimento de software.
Segundo os prprios autores descrevem, o mtodo um apanhado de diversas
abordagens de modelagem OO, como o uso de CRC cards (em CHAN et al., 1998), OMT
(RUMBAUGH et al., 1991), entre outros, adaptadas para o contexto da engenharia de
domnio. Em termos tecnolgicos, o OODE utiliza abordagens avanadas para a
modelagem e implementao de componentes no domnio, com o foco centrado na criao
de arquiteturas de objetos distribudos e heterogneos, com o auxlio de design patterns
(GAMMA et al., 1994). Esta uma abordagem bastante interessante, uma vez que a
computao distribuda e a necessidade de cooperao entre aplicaes heterogneas cada
vez mais requerida.
No entanto, para um mtodo de engenharia de domnio, apenas focar um estilo
arquitetural, que, segundo a classificao de BUSHMANN (1996), seria o estilo

52

arquitetural Broker, muito limitado, uma vez que em um dado domnio,

reconhecidamente podemos ter aplicaes que seguem outros estilos arquiteturais que no
este. Desta forma, o mtodo fica limitado a disponibilizar componentes que atendam
aplicaes que sigam esta arquitetura. Atualmente, apesar de ser uma tendncia, poucas
aplicaes se baseiam na arquitetura Broker (OMG, 2000). Outro ponto crtico para a
aplicao do mtodo a falta de ferramental adequado para sua execuo, principalmente
no que tange a especificao de componentes distribudos e suas interfaces.

Processo

O OODE utiliza um processo em espiral para a especificao de componentes

reutilizveis. O processo constitudo de trs fases: anlise de domnio, projeto
do domnio e instalao (entrega) dos produtos. Na literatura disponvel sobre o
mtodo dada pouca nfase fase de projeto e implantao. No entanto, pelos
estudos de caso apresentados, podemos concluir que em todas as fases, produtos
especficos so disponibilizados e validados atravs de testes.

Produto

So disponibilizados produtos reutilizveis em todas as fases. Como o mtodo

utiliza uma abordagem OO, ele facilmente integrado em processos de
desenvolvimento de aplicaes OO. No entanto, os produtos disponibilizados na
fase de projeto e implementao podem no ser adequados para todos os tipos
de aplicaes, uma vez que o OODE utiliza uma abordagem de arquitetura
distribuda.

Ferramental Automatizado

No existe nenhum suporte automatizado especfico para o mtodo. Isto pode

dificultar sua aplicao em domnios mdios a grandes. O batimento dos
modelos gerados com os padres de projeto e de anlise pode ser dificultado
neste caso. Alm disso, necessrio um suporte mais especfico para a criao
de arquiteturas distribudas, principalmente no que tange ao interfaceamento das
mesmas.

Tabela 2.6 Principais caractersticas do OODE

2.4.6 RSEB
O RSEB (Reuse-Driven Software Engineering Business) um mtodo para o
desenvolvimento de aplicaes baseado em reutilizao (JACOBSON et al., 1997). Os
autores partem da abordagem OO para a criao de um mtodo com caractersticas de
desenvolvimento baseado em componentes. Para isso, o mtodo estende a abordagem OO

53

com construes, tais como pontos de variao3 em casos de uso, uso de frameworks e
facades4, para permitir o desenvolvimento de aplicaes baseadas em componentes
previamente definidos.
O desenvolvimento de aplicaes se baseia, ento, no preenchimento dos pontos de
variao, instanciao de frameworks e especificao de contratos que permitam a
reutilizao de interfaces (facades).
Conforme podemos perceber, o enfoque bsico do mtodo no desenvolvimento de
aplicaes baseadas em componentes, no existindo uma sistemtica para a engenharia de
componentes, ou seja, para a construo dos componentes. Podemos notar algumas
atividades semelhantes s da engenharia de domnio, mas no existe uma nfase em ED.
Alm disso, no existe um modelo de abstraes, nos moldes do modelo de caractersticas,
que guie e facilite a reutilizao.

Processo

O RSEB como um processo para engenharia de aplicaes baseadas em

componentes bastante interessante. No entanto, como um mtodo baseado em
reutilizao, ele no atende a alguns requisitos. Seus produtos no so
organizados de forma a serem identificados como reutilizveis. Desta forma,
difcil para o usurio identificar os produtos a serem reutilizados.

Produto

Apesar de se ter uma nfase na generalizao de produtos de todas as fases, com

o intuito de que estes sejam reutilizados, no existe uma sistemtica de criao
dos mesmos e, por este motivo, fica difcil garantir sua reutilizabilidade. Os
modelos disponibilizados so casos de uso, modelos de classes, entre outros
modelos OO, cuja nfase na variabilidade ressaltada.

Ferramental Automatizado

Conforme j ressaltado, no existe um suporte automatizado especfico para o

mtodo. O que existem so ferramentas tais como o Rational Rose que podem
ser utilizadas. No entanto, nem sempre estas ferramentas esto integradas.

Tabela 2.7 Principais caractersticas do RSEB

Um ponto interessante do RSEB a preocupao com a descrio arquitetural de

forma detalhada. No entanto, no feita uma descrio detalhada do que realmente seria

Pontos de Variao so partes especficas onde se pode acoplar novas construes que modifiquem e/ou
especializem a funcionalidade de uma dada construo.
4
Facades so as especificaes de uma interface, fachada externa de uma determinada construo, ou seja, o
que visvel para as demais construes.

54

uma arquitetura de componentes para o RSEB. O que apresentado uma arquitetura para
aplicaes baseadas em componentes que basicamente uma arquitetura em camadas.
Uma crtica ao RSEB a falta de suporte automatizado para o mtodo. Os autores
argumentam que ferramentas CASE como o Rational Rose (RATIONAL, 2000) e
repositrios de componentes como o da Microsoft (MICROSOFT, 2000) poderiam ser
utilizados. No entanto, no caso do Rational Rose, a ferramenta no possui suporte para a
modelagem dos pontos de variao, interfaces ou frameworks, o que seria a parte
interessante do mtodo e o que o difere das outras abordagens OO. Alm disso, no existe
uma perfeita integrao entre o ROSE e o repositrio da Microsoft, que alm do mais s
disponibiliza componentes Microsoft.
2.4.7 FeatuRSEB (Featuring RSEB)
Observando as deficincias do RSEB em relao ao suporte engenharia de domnio
e do FODA em relao utilizao de uma abordagem de modelagem mais atual, foi criado
o FeatuRSEB, no contexto dos projetos de engenharia de domnio da TELECOM Itlia
(GRISS et al., 1998).
Assim, o FeatuRSEB tenta unir as vantagens do FODA, que a modelagem de
abstraes do domnio, que representaria quais funcionalidades so importantes no domnio
com as vantagens do RSEB, que a descrio detalhada de como implementar estas
funcionalidades.
O mtodo foi aplicado na TELECOM Itlia e, segundo os autores, obteve bons
resultados. Novamente, a grande crtica na nfase em modelar apenas as funcionalidades
abstratas do domnio. SIMOS et al. (1998) ressaltam este ponto, ou seja, a necessidade de
modelar mais do que somente as funcionalidades do domnio, com um exemplo tirado do
estudo de viabilidade do FODA (KANG et al., 1990), que apresenta uma modelagem do
domnio de gerenciamento de janelas grficas. No exemplo, ele atesta que sem uma
definio precisa do que janela, o que redimensionamento e o que dinmico, as
funcionalidades do domnio suporte ao redimensionamento de janelas e suporte
dinmico

ao

redimensionamento

de

janelas

seu

relacionamento

de

generalizao/especializao ficam restritos a uma deciso do projetista e no podem ser

comprovados e melhor entendidos pelo usurio.

55

Processo

Processo bem definido e detalhado para a engenharia de domnio, com uma

preocupao grande de representar o que (modelo de caractersticas) e o como (
modelo de caso de uso e seus desdobramentos). Utiliza abordagens atuais de
engenharia de software como padres e frameworks. Pela prpria caracterstica
dos modelos, a integrao com abordagens de desenvolvimento OO facilitada.

Produto

Os produtos disponibilizados facilitam a reutilizao quando da escolha de

quais componentes sero reutilizados (modelo de caractersticas) e no
detalhamento destes produtos, de forma que possam ser integrados ao processo
de desenvolvimento de aplicaes.

Ferramental Automatizado

No existe nenhuma ferramenta que suporte o processo de desenvolvimento do

FeatuRSEB. Os autores descrevem algumas ferramentas que poderiam ser
utilizadas como o Rational Rose, Platinum Plus e o Microsoft Repository, mas
nenhuma disponibiliza as funcionalidades requeridas pelo mtodo e que o fazem
um mtodo de engenharia de domnio. Os autores tambm mencionam um
ferramental em desenvolvimento denominado DEUS.

Tabela 2.8 Principais caractersticas do FeatuRSEB

2.4.8 Catalysis
O mtodo Catalysis um mtodo de desenvolvimento baseado em componentes
completo, cobrindo todas as fases do desenvolvimento de um componente, a ser utilizado
no desenvolvimento de uma dada aplicao, desde a especificao at sua implementao
(DSOUZA et al., 1998).
Todos os modelos so descritos em detalhe e h uma grande preocupao com a
especificao da arquitetura da aplicao, que na verdade seria a especificao da
colaborao entre os componentes. interessante ressaltar que esta descrio arquitetural
no se prende a nenhum estilo arquitetural especfico, como o caso do OODE.
Em termos arquiteturais, o Catalysis descreve dois nveis, o nvel da macroarquitetura, que seria o nvel de colaborao entre os componentes e a micro-arquitetura,
que seria a descrio de como cada componente projetado internamente.
Existe uma preocupao grande em relao interface dos componentes. Esta
abordagem interessante uma vez que a possibilidade de colaborao entre os componentes
para formar a arquitetura dada pelas interfaces. Por isso, existe todo um formalismo para
a definio das interfaces, com especificao de restries, detalhamento da interface, entre
outros, de forma que esta consistncia possa ser verificada de maneira formal.

56

Um aspecto interessante do Catalysis que, apesar de no ser um mtodo de

engenharia de domnio, ele apresenta um conceito de tipo, que seria a descrio de alguma
funcionalidade da aplicao em termos apenas de seu comportamento externo. Esta
definio vem muito ao encontro da definio de caractersticas que descrevem
funcionalidades. No entanto, o Catalysis no especifica nenhum tipo de modelo de
relacionamento destas funcionalidades, capturando as similaridades e diferenas entre as
mesmas, como feito no modelo de caractersticas. Este o ponto onde o Catalysis no
pode ser considerado um mtodo de ED; ele no possui nenhum modelo que apresente as
abstraes do domnio de forma a facilitar a reutilizao. Alm disso, apesar de detalhar
bastante como seria o desenvolvimento de componentes, o mtodo est mais preocupado
com o desenvolvimento de uma nica aplicao e no com uma famlia destas. Assim, os
componentes no so especificamente empacotados para reutilizao posterior.
Outro ponto interessante do Catalysis e que est em conformidade com alguns dos
princpios da reutilizao, segundo apresentado por KRUEGER (1992), o mecanismo de
realizao, onde uma descrio mais abstrata de um componente est ligada ao seu (s)
detalhamento (s) em fases de projeto e implementao.
Processo

Fases bem definidas para o desenvolvimento de componentes, utilizando

construes consagradas no desenvolvimento de software atual como padres e
frameworks. Bom detalhamento da fase arquitetural, com especial nfase na
parte de especificao formal das interfaces. Falta um comprometimento maior
com a reutilizao para que possa ser adotado como um processo de engenharia
de domnio.

Produto

No existe um modelo que apresente o que reutilizar. S apresenta modelos

de como so especificadas estas funcionalidades. No entanto, neste segundo
aspecto, os modelos so bastante consistentes, inclusive com mecanismos de
rastreabilidade entre os mesmos. Podem ser facilmente integrados em um
processo de desenvolvimento OO.

Ferramental Automatizado

Como o mtodo muito badalado, algumas ferramentas especficas esto sendo

disponibilizadas para o mesmo. Como exemplo, podemos citar o Cool-Gen.

Tabela 2.9 Principais caractersticas do Catalysis

Na literatura disponvel, consideramos o Catalysis como o melhor mtodo de
desenvolvimento baseado em componentes, pois o detalhamento do seu processo bastante
consistente. Este ponto de vista comprovado pela utilizao do Catalysis em diversas

57

abordagens de desenvolvimento de software, inclusive com ferramentas especficas para

ele.
2.5 Concluses
Existem algumas similaridades entre os enfoques de ED e o DBC. Ambos buscam o
desenvolvimento de componentes que possam ser utilizados e reutilizados novamente no
desenvolvimento de aplicaes. No entanto, o que podemos verificar que ao passo que a
ED est essencialmente preocupada com a captura das abstraes do domnio e como estas
abstraes esto relacionadas, de forma a compor uma infra-estrutura de reutilizao que
seja capaz de disponibilizar componentes reutilizveis, o DBC est mais preocupado em
como estes componentes podem cooperar para a especificao de uma dada aplicao.
Podemos notar claramente nos mtodos de ED uma grande preocupao com a
especificao de um modelo de abstraes, que capture as similaridades e diferenas do
domnio. A concretizao, ou melhor, segundo KRUEGER (1992) a realizao destas
abstraes, principalmente nos mtodos mais antigos como FODA e ODM, no recebe
muita nfase, disponibilizando-se apenas algumas diretivas de como deve ser a fase de
projeto e implementao. As metodologias de ED atuais mais representativas, tais como
FeatuRSEB, FORM e OODE, j apresentam um detalhamento maior das etapas que tratam
este aspecto especfico, i.e., as fases de projeto e implementao, mas no apresentam a
captura destas abstraes nas fases posteriores, alm de no especificarem como estas
abstraes so concretizadas em componentes reutilizveis.
Nas sees 2.4.1 a 2.4.6 foram analisados e comparados os principais mtodos
existentes. Verificamos que nenhum deles apresenta a realizao das abstraes do
domnio em componentes reutilizveis. Essa constatao compromete a efetividade da
reutilizao. Acreditamos que para a reutilizao ser efetiva, todas as etapas (anlise,
projeto e implementao) do processo de engenharia de domnio devem ser contempladas
com igual nfase, compreendendo assim desde a especificao do conhecimento do
domnio at a concretizao deste conhecimento em um componente implementacional.
Os mtodos de DBC tm uma grande preocupao com o detalhamento dos
componentes e seus relacionamentos para a especificao de aplicaes. Por serem
abordagens preocupadas com a especificao de aplicaes, no tm uma preocupao

58

maior no processo de abstrao dos componentes, com o objetivo claro de que estes possam
ser reutilizados o maior nmero de vezes por aplicaes similares.
Portanto, a unio dessas duas abordagens poderia resultar em um mtodo de
Engenharia de Domnio voltado para a especificao de componentes (EC) que unisse o
melhor das duas abordagens, ou seja, da ED viria a especificao de um modelo de
abstraes capturando as similaridades e diferenas do domnio, e do DBC o detalhamento
necessrio para as fases de projeto e implementao, com grande preocupao com as
interfaces dos componentes e arquitetura de software. O modelo de abstraes serviria de
guia para a reutilizao e posterior empacotamento dos componentes, alm de permitir a
especificao dos componentes em um alto nvel de abstrao, de forma que seu grau de
reutilizao fosse o maior possvel.
Analisando as metodologias apresentadas na seo anterior, podemos concluir que
um mtodo de engenharia de domnio atual, contemplando o desenvolvimento baseado em
componentes, deveria levar em considerao os seguintes pontos:

Especificar um modelo de abstraes do domnio, que no s levasse em considerao

aspectos funcionais das aplicaes do domnio mas tambm considerasse conceitos,
ligaes com outros domnios correlatos, atores envolvidos e caractersticas no
funcionais. Neste sentido, o modelo de abstraes poderia ser considerado uma
ontologia5 (GUARINO, 1998) do domnio. Este modelo serviria ainda como um guia
para o processo de reutilizao.

Criar um mecanismo que permitisse a verificao de consistncia entre os modelos e

tambm verificasse a consistncia na seleo de abstraes que no fossem conflitantes.
Esta checagem de consistncia uma caracterstica muito importante.

Definir um mecanismo de ligao entre os modelos de abstrao e os modelos de

especificao dos componentes de forma que se pudesse identificar claramente que
abstraes deram origem a que componentes e quais os conceitos ligados
especificao do componentes. Seria a ligao de realizao que KRUEGER (1992)
descreve.

A definio dos componentes deveria seguir uma abordagem essencialmente DBC, que
possui o detalhamento necessrio para tal, com definio de interfaces, levando em

Metadados semanticamente rico para a descrio precisa de uma determinada rea de aplicao ou domnio.

59

considerao as restries do estilo arquitetural adotado na colaborao entre os

componentes.

Necessidade de suporte automatizado para o processo de criao de componentes

reutilizveis, uma vez que as ligaes entre os modelos, checagem de consistncia,
entre outros, so atividades complexas de serem realizadas manualmente.

Esta tese apresenta no captulo 4 um processo de engenharia de domnio baseado em

componentes que contempla, entre outros aspectos, a realizao das abstraes em
componentes reutilizveis e o suporte automatizado ao processo .

60

Desenvolvimento Baseado em Componentes e Engenharia de Domnio_________ 17

2.1

Introduo __________________________________________________________ 17

2.2

Engenharia de Domnio (ED) ___________________________________________ 19

2.2.1
2.2.2
2.2.3
2.2.4

2.3

Etapas da Engenharia de Domnio _______________________________________________

Profissionais envolvidos com a Engenharia de Domnio ______________________________
Fontes de Informao _________________________________________________________
Produtos gerados pela Engenharia de Domnio _____________________________________

19
20
20
21

Desenvolvimento baseado em Componentes (DBC)__________________________ 22

2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7

Componentes _______________________________________________________________
DBC e a Orientao a Objetos __________________________________________________
Distribuio e Heterogeneidade _________________________________________________
Arquitetura de Software para conexo de componentes _______________________________
Mtodos para desenvolvimento de componentes ____________________________________
Repositrio de Componentes ___________________________________________________
Outros tpicos de pesquisa em DBC______________________________________________

24
29
31
33
37
40
43

2.4 Mtodos de Desenvolvimento Baseado em Componentes e de Engenharia de Domnio

Existentes ________________________________________________________________ 45
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.4.7
2.4.8

2.5

FODA (Feature Oriented Domain Analysis) _______________________________________

ODM (Organization Domain Modelling) __________________________________________
EDLC (Evolutionary Domain Life Cycle) _________________________________________
FORM (Feature-Oriented Reuse Method) _________________________________________
OODE (Object-Oriented Domain Engineering) _____________________________________
RSEB _____________________________________________________________________
FeatuRSEB (Featuring RSEB) __________________________________________________
Catalysis ___________________________________________________________________

46
48
49
50
51
52
54
55

Concluses__________________________________________________________ 57