O Desenvolvimento Baseado em Componentes

Marco Aurlio Gerosa

Departamento de Cincia da Computao USP
Rua do Mato, 1010 - Cidade Universitria
05508-090 So Paulo SP Brasil
gerosa@ime.usp.br

Componentes de Software

Para atingir a qualidade e cumprir o oramento e os prazos previstos, no mais possvel

comear a construir software a partir do zero e estrutur-lo na forma de blocos monolticos
onde uma modificao propaga efeitos colaterais por todo o cdigo, dificultando a
manuteno e a substituio de suas partes [Werner & Braga, 2005 pg 66]. O
Desenvolvimento Baseado em Componentes (DBC) surgiu como uma nova perspectiva para
o desenvolvimento de software, cujo objetivo a quebra dos blocos monolticos em
componentes interoperveis, reduzindo, tanto a complexidade no desenvolvimento, quanto os
custos, por meio da reutilizao de componentes [Sametinger, 1997]. O software passa a ser
composto de partes relativamente independentes, que foram concebidas para serem
substituveis, reutilizveis e interoperveis.
Componentes tm um papel de destaque em outras engenharias (como a engenharia
eletrnica), uma vez que permite a adoo do conceito de caixa-preta, que possibilita ao
desenvolvedor um maior nvel de abstrao e independncia. Na indstria automobilstica,
possvel utilizar o mesmo pneu, parafuso, gasolina e motor para diferentes marcas e modelos
de automveis. No necessrio, e seria demasiadamente caro, reprojetar e construir sob
demanda cada pea para cada carro.
Boto

ligar
velocidade
Motor

Boto

Marcador

parar

Figura 1. Exemplo de uso de componentes [DSouza & Wills, 1998, pg. 405]

O exemplo da Figura 1, tratado por DSouza & Wills [1998], ilustra a componentizao na
ligao de um motor a dois botes e a um marcador. Os mesmos botes e o marcador podem
ser reutilizados em outras situaes (por exemplo, utilizando o marcador para marcar a
temperatura) e estes componentes so substituveis por outros equivalentes, porm com
implementaes diferentes (por exemplo, substituindo os dois botes por uma chave ligadesliga ou o marcador analgico por um digital). A interoperabilidade assegurada pela
compatibilidade entre os conectores e as interconexes so feitas pelos fios eltricos. O
conjunto todo pode ser encarado como um componente de um sistema maior.
A componentizao de software visa trazer estes princpios para o desenvolvimento:
reutilizao, substituio e montagem. O desenvolvedor passa a desenvolver pedaos de
software encapsulados na forma de componentes para que outros desenvolvedores possam

utiliz-los, substitu-los ou modific-los, com efeitos colaterais reduzidos. aproximar o

desenvolvimento de software ao conceito de Lego 1 .
Aplicao

Newsfeed

Planilha

Aplicao Web

Banco de Dados

Figura 2. Exemplo de uso de componentes de software [DSouza & Wills, 1998, pg 384]

DSouza & Wills [1998] exemplificam a composio de software atravs da situao ilustrada
na Figura 2. Uma aplicao l dados de um newsfeed sobre aes, registra em uma planilha e
passa os resultados a um banco de dados. O banco de dados compartilhado por uma
aplicao web, que extrai as informaes sob demanda. Cada componente relativamente
independente, compartilhado e utilizado para compor um sistema maior. Os componentes
disponibilizam interfaces para interconexo e podem ser substitudos por outros equivalentes.
Eventualmente, um componente, como a planilha, no precisa de interface com o usurio ou
de mecanismos de persistncia.

Definio de Componentes de Software

Nesta seo so analisadas algumas definies para componente de software encontradas na

literatura. O termo componente tambm comparado com outros termos e conceitos
utilizados no desenvolvimento de software. Para alguns autores um componente de software
pode ser qualquer elemento que possa ser reutilizado: cdigo binrio, cdigo fonte, estruturas
de projeto, especificaes e documentaes [Krueger, 1992]. Outros autores focam na
tecnologia, e consideram um componente qualquer pedao de cdigo que segue uma
especificao. A Tabela 1 apresenta algumas definies encontradas na literatura.
Grady Booch [1987]:

Mdulo logicamente coerente e fracamente acoplado que denota uma

abstrao nica.
Meta Group [1994]:
Mdulo de software reutilizvel, auto-contido, pr-testado e prfabricado que agrupa conjuntos de dados e procedimentos e
desempenha tarefas especficas.
Johannes Sametinger [1997]: Pedao de software auto-contido, claramente identificvel, que descreve
ou executa funes especficas, tem interfaces claras, documentao
apropriada e um status de reuso.
Component Int. Labs
Pedao de software pequeno o suficiente para implementar e manter,
[Orfali et al, 1995]:
grande o suficiente para distribuir e dar suporte, e com interfaces
padronizadas para oferecer interoperabilidade.
Brown & Wallnau [1996]:
Parte no-trivial de um sistema, praticamente independente e
substituvel, com uma funo clara no contexto de uma arquitetura bem
definida.
Clemens Szyperski
Unidade binria com interfaces contratualmente especificadas e
[1997, pg 34]:
dependncias de contexto explcitas, que pode ser instalado de forma
independente e usado por terceiros sem modificao para compor
aplicaes finais.
DSouza & Wills [1998, pg
Um pacote coerente de software que (a) pode ser desenvolvido e
387]
instalado independentemente como uma unidade, (b) tem interfaces
1

Brinquedo composto por partes encaixveis utilizado para montar construes, veculos, etc.
(http://www.lego.com)

explcitas e bem definidas para os servios que prov, (c) tem interfaces
explcitas e bem definidas para os servios que espera de outros, e (d)
pode ser utilizado para composio com outros componentes, sem
alteraes em sua implementao, podendo eventualmente ser
customizado em algumas de suas propriedades.
Councill & Heineman [2001, Um componente de software um elemento que est em conformidade
pg 7]
com um modelo de componentes e pode ser instalado
independentemente e composto sem modificaes.
Barroca et al. [2005]:
Unidade de software independente, que encapsula, dentro de si, seu
projeto e implementao, e oferece servios, por meio de interfaces bem
definidas, para o meio externo.
Tabela 1. Definies de componente de software

Neste trabalho, adotada a definio proposta por DSouza & Wills [1998], que enfatiza a
possibilidade de customizao e a necessidade de explicitar as interfaces fornecidas e
requeridas. Entretanto, as outras definies so consideradas, principalmente as de Szyperski
[1997], que diz que o componente uma unidade executvel 2 , e a de Councill & Heineman
[2001, pg 7], que diz que o componente segue um modelo de componentes. Apesar destas
duas caractersticas no estarem explcitas na definio proposta por DSouza & Wills [1998],
estes autores seguem esses conceitos ao longo do texto.
Componentes de software so utilizados nas mais diversas reas e com os mais diversos
propsitos. Um exemplo bastante conhecido o uso de plugins nos navegadores Web,
utilizados para dar suporte visualizao de contedos, como animaes flash, documentos
Word e vdeos diversos. Os plugins se comportam como componentes, pois so autocontidos, reutilizveis, substituveis, provem servios especficos de uma maneira coesa e
bem definida, seguem uma padronizao e so disponibilizados como uma unidade
executvel. Vrias aplicaes utilizam o suporte a plugins para estender as funcionalidades
nativas, como o Adobe Photoshop, Eclipse IDE e Apache web server.
Componentes visuais de interface com o usurio (widgets) outro exemplo bastante
difundido de uso de componentes. Alguns ambientes de desenvolvimento integrado (IDEs)
disponibilizam ao desenvolvedor um conjunto de componentes visuais que podem ser
utilizados para compor a interface com o usurio. O programador instancia e posiciona os
componentes, configura suas propriedades e associa mtodos a seus eventos, sem ter acesso
ao cdigo fonte.
Dada a elasticidade e o desgaste do termo componente, apropriado diferenci-lo de outros
conceitos e tecnologias para melhor caracteriz-lo. A seguir, o conceito de componente de
software comparado com os conceitos de mdulo, objeto, classe, biblioteca e API.
O conceito de componente similar ao conceito tradicional de mdulo, presente h bastante
tempo na engenharia de software. A modularidade de fato um pr-requisito para a
tecnologia de componentes [Szyperski, 1997, pg 33], que diferenciada pela existncia de
uma padronizao (component model) e de uma infra-estrutura especfica para seu
gerenciamento e execuo (component framework e container) [DSouza & Wills, 1998, pg
386].
Tambm h uma certa confuso entre componentes e objetos, principalmente porque a
maioria dos componentes implementada utilizando linguagens orientadas a objetos
[DSouza & Wills, 1998, pg 390]. Objetos so instncias identificveis criadas por um
2

Clemens Szyperski, na nova edio de seu livro, passou a caracterizar um componente como executvel, ao
invs de binrio, visto que o que relevante a capacidade de execuo em uma plataforma e no a forma de
empacotamento. O autor afirma que um componente pode ser eventualmente implementado na forma de um
script de cdigo.

sistema em execuo. O componente cria, envia e recebe objetos, e muitas vezes

representado e acessado por meio deles.
Componente e classe tambm so conceitos relacionados. Ambos utilizam polimorfismo e
ligao dinmica, realizam interfaces, podem participar de um relacionamento de dependncia
e composio, admitem instncias e so participantes de interaes [Booch et al., 2000].
Entretanto, classe e componente esto em nveis de abstrao diferentes. Classe pode ser uma
abstrao lgica do domnio (classe conceitual) ou uma estrutura de uma linguagem de
programao utilizada para instanciar objetos (classe de software). Um componente uma
unidade executvel, que pode ser a implementao fsica de uma ou mais classes 3 . Uma
classe s pode pertencer a um nico componente [Szyperski, 1997, pg 32].
Um componente no necessariamente precisa estar na mesma mquina que a aplicao que a
utiliza e nem na mesma linguagem de programao. Diferentemente de classes, um
componente pode estar disponvel somente na forma binria e o nome do componente no
pode ser utilizado para definir o tipo de uma varivel ou parmetro [Weinreich & Sametinger,
2001, pg 36]. As padronizaes para componentes tambm so mais abrangentes do que as
padronizaes para classes, definindo, entre outros fatores, empacotamento, ciclo de vida,
conectores, interfaces providas e requeridas, etc. [DSouza & Wills, 1998, pg 390].
Componentes tambm tm uma gama maior de mecanismos de intercomunicao, como
eventos e workflow, alm das mensagens da orientao a objetos. Por fim, instncias de
componentes tendem a ser mais estticas do que instncias de classes, no tenho sua
configurao alterada ao longo do ciclo de vida [DSouza & Wills, 1998, pg 391]. Mesmo
estando em nveis de abstrao diferentes, por simplificao do discurso, costuma-se chamar
a(s) classe(s) que foram utilizadas na construo do componente de componente.
Biblioteca de funes outro termo que costuma causar confuso com componente. Uma
biblioteca prov servios coesos para um sistema e auto-contida, reutilizvel e substituvel.
Uma biblioteca eventualmente tambm disponibilizada na forma binria e pode ser
orientada a objetos. Entretanto, uma biblioteca normalmente no pressupe uma
padronizao, instalao e configurao (deploy), e nem a existncia de uma plataforma
especfica de execuo.
Um componente, assim como uma biblioteca, prov uma API (Application Program
Interface), que representa parte do contrato de utilizao daquele pedao de cdigo. Uma
API expe o conjunto de operaes, procedimentos, funes, tipos e constantes que um
pedao de cdigo oferece para ser utilizado externamente. Respeitando a API e os requisitos
no-funcionais, possvel trocar o componente ou a infra-estrutura, sem impactar o cdigo
cliente. Por exemplo, o sistema operacional Windows oferece uma API padro que
compatvel entre suas diversas verses, de forma que um software desenvolvido para uma
verso anterior do sistema operacional normalmente continua a funcionar em uma verso
mais recente. Desta forma, pode-se compor o ambiente de trabalho instalando e configurando
os componentes necessrios.
Muitas vezes, o termo componente usado com pouco rigor em diversos nveis de abstrao,
o que pode ser a origem da confuso sobre o termo [DSouza & Wills, 1998, pg. 388]
[Apperly, 2001, pg 29]. Costuma-se chamar de componente: a especificao do componente,
a implementao (cdigo fonte), o executvel que implementa a especificao (deployable
component), a instalao em particular daquele executvel, a execuo especfica daquele
executvel e a instncia do componente. Com relao granularidade, um componente de
3

Um componente no obrigatoriamente precisa conter classes [Szyperski, 1997, pg 31]. Um componente pode
conter cdigo escrito em outras tecnologias.

software pode ser construdo a partir de uma nica classe ou ser to complexo como um
subsistema [Ginenes & Huzita, 2005]. As definies apresentadas na Tabela 1, ajudam a dar
indcios sobre os critrios para considerar um pedao de cdigo como sendo um componente:
ele deve ser passvel de implementar e manter independentemente, coeso, no-trivial e com
uma funo clara no contexto da arquitetura, bem como passvel de separao, distribuio e
reutilizao.
Resumindo, no contexto do DBC, componente de software um elemento arquitetural
mapeado em um arquivo executvel, que segue uma especificao, e foi concebido para ser
auto-contido, reutilizvel, substituvel, alm de prover servios especficos de uma maneira
coesa e bem definida. Portanto, classificar algo como componente depende tambm de como
o cdigo foi concebido e construdo e como ele se relaciona com o restante do sistema, e no
somente da aderncia a uma padronizao. Vale ressaltar que na literatura costuma-se
encontrar alguns sinnimos para componentes, utilizados em contextos especficos, como
plugin, add-on, mdulo, servio e widget.

Benefcios e Dificuldades da Componentizao

Para projetar um sistema baseado em componentes necessrio entender os benefcios e

dificuldades da tecnologia, bem como o ferramental disponvel. Os benefcios da
componentizao esto ligados a manutenabilidade, reuso, composio, extensibilidade,
integrao, escalabilidade, entre outros [DSouza & Wills, 1998, pg 397]. As dificuldades
podem ser separadas em dificuldades do desenvolvimento para componentizao (construo
dos componentes e da infra-estrutura) e dificuldades do desenvolvimento com
componentizao. As primeiras esto ligadas ao esforo inicial de anlise, projeto e
desenvolvimento, enquanto as segundas esto ligadas ao esforo despendido no entendimento
dos componentes e das ferramentas envolvidas, perda de flexibilidade, dependncia de
terceiros e adaptao do processo de desenvolvimento.
Uma das principais motivaes para se desenvolver um software baseado em componentes
melhorar a sua manutenabilidade. Os componentes podem ser substitudos para atualizao ou
correo, muitas vezes sem precisar alterar ou recompilar a aplicao como um todo
[DSouza & Wills, 1998]. Pode-se tambm adicionar, remover ou substituir componentes por
verses mais robustas ou que sejam mais apropriadas ao hardware, ao sistema operacional ou
a produtos legados com os quais o sistema tenha que operar. A modularidade obtida com a
componentizao facilita a localizao do cdigo a ser alterado e o encapsulamento da
alterao. Algumas mudanas nas regras de negcio so resolvidas com uma re-arrumao
nas amarraes entre os componentes ou em sua re-configurao [DSouza & Wills, 1998, pg
397].
O reuso tambm freqentemente citado como um benefcio da componentizao. O reuso
favorece a reduo dos esforos de desenvolvimento e a qualidade do produto final, por
colocar em uso cdigo j utilizado e testado em outras situaes [Krueger, 1992]. Blocos com
granularidade baixa (como uma classe) e alta (como um sistema) so difceis de reusar, pois
so genricos ou especficos demais. A tecnologia de componentes trabalha com blocos com
granularidade mdia, mais propcia para o reuso. A componentizao tambm promove o
reuso nas diversas atividades do desenvolvimento: anlise, projeto, implementao e testes.
Com a componentizao, pode-se adaptar a aplicao para diversas necessidades,
selecionando e configurando os componentes mais adequados. Pode-se tambm
reimplementar um determinado componente para atender a uma necessidade especfica ou
adicionar novos componentes ou interfaces para estender os servios providos, tornando o
software desenvolvido mais adaptvel e extensvel [DSouza & Wills, 1998, pg 397].
5

Uma outra vantagem da componentizao o encapsulamento de conhecimento e uma

programao de alto nvel. Da mesma forma que um mecnico no precisa conhecer o
coeficiente de isolao eltrico da porcelana para substituir uma vela, um desenvolvedor no
precisa conhecer os detalhes de implementao dos componentes para utiliz-los para compor
as aplicaes. Quem integra componentes pode se especializar nesta atividade abstraindo os
detalhes de implementao, ficando com uma viso mais abrangente e mais prxima do
domnio de aplicao.
A componentizao tambm facilita a prototipao, pois mais rapidamente pode-se recompor
o sistema e alterar o seu comportamento para experimentar idias. Esta capacidade
especialmente til quando h presso para liberar produtos no mercado ou em sistemas com
requisitos no-definidos e instveis [Pressman, 2000]. Com a componentizao, possvel
usar um ambiente RAD (Rapid Application Development) ou um toolkit para o desenvolvedor
prototipar sua aplicao. A prototipao e o desenvolvimento iterativo possibilitam colocar o
sistema em produo mais cedo, de forma a refinar gradualmente os requisitos e construir o
sistema com base no aprendizado obtido com a realimentao [Pressman, 2000].
A decomposio do sistema possibilita a definio de componentes independentes, que
podem ser subcontratados ou alocados para outras equipes, o que favorece o desenvolvimento
paralelo e em grupo. Eventualmente, os prprios usurios finais podem recompor e reconfigurar os componentes, de forma a adaptar a aplicao para suas necessidades especficas,
evolu-la para acompanhar as caractersticas das tarefas e prototipar e experimentar
configuraes antes de solicitar um desenvolvimento completo.
O desenvolvedor do componente beneficiado pela infra-estrutura de execuo, que prov
servios bsicos como persistncia, interconexo, escalabilidade, etc., aliviando a necessidade
de implementar estes servios. Algumas infra-estruturas possibilitam a integrao de forma
transparente para o programador de componentes desenvolvidos e disponibilizados em
diferentes linguagens de programao, tecnologias e plataformas [DSouza & Wills, 1998, pg
397].
Com relao s dificuldades, o desenvolvimento baseado em componentes demanda um
esforo inicial maior de projeto e implementao para montar a infra-estrutura do sistema e
construir uma biblioteca robusta de componentes reutilizveis. Projetar e preparar um pedao
de software para futura reutilizao aumenta a necessidade de flexibilidade, documentao,
estabilidade e abrangncia do software [Moore & Bailin, 1991]. O software deve ser bem
documentado, testado e validado, e deve ter um esquema robusto de validao [Pfleeger,
2001]. Os componentes no podem ser nem muito genricos e nem muito especficos
[Oliveira, 2001].
O custo do estudo e entendimento de como usar e instalar os componentes tambm outra
dificuldade associada com a reutilizao. s vezes mais rpido desenvolver um componente
do que procurar por um pronto, estud-lo e adapt-lo [Pfleeger, 2001]. A menos que o custo
de aprendizagem seja amortizado por vrios projetos ou que o ganho de produtividade e
qualidade sejam expressivos, o investimento inicial no se tornar atraente [Oliveira, 2001].
O uso de componentes provenientes de terceiros pode levar a situaes inesperadas, onde se
torna necessrio reimplementar uma grande quantidade de cdigo, quando novos requisitos
levarem a alteraes ou customizaes no possibilitadas pelo componente. Os componentes
introduzem dependncias fora do controle dos desenvolvedores do sistema, impondo um
esforo continuado de atualizao de suas verses e de reconfigurao do sistema. H um
risco de incorporar bugs de terceiros no software. Alm disto, muitas vezes difcil encontrar
um componente que atenda plenamente s funcionalidades desejadas e ainda d suporte aos
requisitos no funcionais da aplicao, como performance, segurana, escalabilidade, etc.,
6

sendo que a maioria dos componentes nem documentam este tipo de requisitos [Gimenes &
Huzita, 2005]. Por fim, o desenvolvimento baseado em componentes tambm demanda uma
adaptao no processo de desenvolvimento, que passa a incluir etapas como anlise de
domnio, busca de componentes, testes especficos, etc.

Utilizao dos Componentes

Uma vez discutidos a definio, os benefcios e as dificuldades do uso de componentes, nesta

seo so definidos alguns termos referentes utilizao de componentes (porta, conector,
interface, adaptador, instncia e deployment). Tambm so discutidas as maneiras de
customizar componentes.
Uma porta um meio identificvel de conexo, por onde um componente oferece seus
servios ou acessa os servios dos outros [DSouza & Wills, 1998, pg 410, 414]. Operao,
propriedade e evento so exemplos de tipos de portas de um componente. Cada porta tem uma
identificao (nome ou nmero pelo qual a porta acessada) e pode ser de entrada ou de sada
de dados. Cada porta define os tipos de valores que so transmitidos ou recebidos e
normalmente implementada por uma operao [DSouza & Wills, 1998, pg 415].
Ao meio por onde feita a conexo entre duas ou mais portas dado o nome de conector
[DSouza & Wills, 1998, pg 414]. O conector pode ser implementado por invocao explcita
de funo, envio de mensagens sncronas ou assncronas, propagao de eventos, stream de
dados, workflow, cdigo mvel, dilogo atravs de uma API, transferncia de arquivo, pipe,
propagao de eventos, buffer, sinalizao, compartilhamento de arquivo via ftp, etc.
[DSouza & Wills, 1998, pg 389, 395] [Wills, 2001, pg 312]. Os tipos de conectores variam
para cada tecnologia e ferramenta adotada. Por exemplo, JavaBeans oferece um conjunto de
conectores diferentes dos oferecidos pelo COM+ [DSouza & Wills, 1998, pg 414].
Tipicamente, os componentes interagem entre si atravs de chamadas de mtodos, em um
estilo cliente/servidor ou publicador/ouvinte [Weinreich & Sametinger, 2001, pg 43]. A
conexo entre os componentes pode ser feita em tempo de codificao, compilao,
inicializao ou execuo. O conector alm do fluxo de informaes define tambm o fluxo
de controle [Wills, 2001, pg 313].
Um conjunto de portas relacionadas chamado de interface. A interface de um componente
define seus pontos de acesso, por meio dos quais outros componentes podem utilizar os
servios oferecidos [Szyperski, 1997, pg 40]. A interface representa o contrato de utilizao
do componente. Respeitando-se este contrato, pode-se alterar a implementao interna do
componente ou substitu-lo 4 por outro, sem modificar quem o utiliza. O contrato pode cobrir
aspectos funcionais e no funcionais [Szyperski, 1997, pg 370]. Aspectos funcionais incluem
a sintaxe e a semntica da interface. Os no funcionais incluem os aspectos referentes
qualidade de servio.
A interface de um componente de software funciona como a especificao dos pinos de um
circuito integrado. Para usar o circuito, basta conhecer o funcionamento de sua interface
externa e prever na arquitetura do circuito, o encaixe para ele. No necessrio o
conhecimento dos detalhes internos de funcionamento do componente (abordagem caixa
preta). Ao estabelecer o contrato de utilizao entre o componente e seus clientes e separar
especificao e a implementao do componente, pode-se desenvolver e substituir
componentes de forma transparente para seus clientes [Szyperski, 1997, pg 34].

Para um componente substituir outro, o substituto precisa prover ao menos os mesmos servios solicitados ao
original e no deve solicitar servios distintos dos que o anterior utilizava [DSouza & Wills, 1998].

A interface especifica os servios que os clientes podem requisitar de um componente e as

restries que devem ser observadas pelos componentes e clientes [Councill & Heineman,
2001, pg 8] [Weinreich & Sametinger, 2001, pg 39]. Um componente apresenta mltiplas
interfaces correspondendo aos conjuntos de servios que visam diferentes necessidades dos
clientes, de modo a facilitar o uso do componente e reduzir o acoplamento entre os
componentes [DSouza & Wills, 1998, pg 397].
Normalmente, um componente possui pelo menos duas interfaces. Uma interface relativa
funcionalidade que o componente oferece a outros componentes e outra conexo com a
infra-estrutura de execuo. Na conexo com a infra-estrutura de execuo so abordados
servios tcnicos, como os relacionados ao ciclo de vida, instalao, persistncia, etc.
Apperly [2001, pg 30] compara componentes com janelas utilizadas na construo civil. As
janelas so entregues como um pacote fechado, so plugadas em uma infra-estrutura, com um
determinado propsito, e suas funcionalidades so utilizadas por seus clientes. H uma
interface que define a utilizao pelos clientes e uma outra interface que determina a juno
da janela com a infra-estrutura (quantos e quais buracos de fixao so necessrios). Tanto o
cliente quanto a infra-estrutura no so dependentes dos detalhes internos de implementao
(tamanho dos pregos, tipo de cola empregada, etc.).
As interfaces podem ser classificadas em dois tipos: interfaces fornecidas (provided
interfaces) e requeridas (required interfaces) [Councill & Heineman, 2001, pg 9]. Um
componente d suporte a uma interface fornecida se contm uma implementao de todas as
operaes definidas por aquela interface. Um componente possui uma interface requerida 5 se
usa uma operao definida naquela interface. Componentes se conectam por meio da interface
requerida de um com a interface fornecida de outro [Barroca et al, 2005 pg 6], conforme
ilustrado na Figura 3. Se um componente for totalmente auto-contido, ele no possui interface
requerida. Um componente pode requerer mais de uma interface e estar em conformidade
com mais de uma interface fornecida. As dependncias de contexto so definidas pelas
interfaces requeridas [Szyperski, 1997, pg 369].
Componente A
Aplicao
InterfaceX
interface
fornecida

Componente B
interface
requerida

InterfaceZ
interface
requerida

InterfaceY

Componente D

interface
fornecida

Componente C

interface
fornecida

Figura 3. Interfaces requeridas e fornecidas

Pode-se utilizar a implementao de interface da orientao a objetos para implementar o

conceito de interface de componente. Propriedade e eventos so mapeados na forma de
mtodos, porm, alguns aspectos da interface, como os aspectos no-funcionais e as interfaces
requeridas, no so passveis de representao [Gimenes & Huzita, 2005]. Uma interface
5

As linguagens de programao orientadas a objetos atuais no oferecem suporte para a representao explcita
das interfaces requeridas [DSouza & Wills, 1998, pg 388].

passa a ser um conjunto de operaes que podem ser invocadas pelos clientes [Szyperski,
1997, pg 40]. Alguns modelos de componentes definem maneiras prprias para representar a
interface, como por exemplo a IDL do Corba.
Um componente pode implementar diretamente uma interface ou pode implementar objetos
que provem interfaces [Szyperski, 1997, pg 41]. Estes objetos so passados de componente
em componente, de modo que um componente no tem cincia da origem do objeto e do
cdigo sendo executado [Szyperski, 1997, pg 42]. Cdigo adicional, conhecido como
conector, pode ser inserido entre componentes para realizar converses simples de modo a
compatibilizar interfaces nos casos em que a substituio de tipos no suficiente.
Chama-se de instncia de componente, o conjunto de objetos pelos quais se manipula o
componente [Szyperski, 1997, pg 370]. Estes objetos so a manifestao do componente em
tempo de execuo [DSouza & Wills, 1998, pg 390]. Em alguns casos, a instncia do
componente serializada em um stream que tratado pelo container [DSouza & Wills, 1998,
pg 392].
Para utilizar um componente necessrio instal-lo (deployment) em uma infra-estrutura de
execuo. Esta instalao no pressupe a modificao do componente, entretanto, ele pode
ser customizado externamente [Heineman, 2000] [DSouza & Wills, 1998, pg 395]. A
customizao a habilidade de adaptar um componente antes de sua instalao ou uso,
normalmente com o objetivo de especializar seu comportamento [Weinreich & Sametinger,
2001, pg 42] [DSouza & Wills, 1998, pg xvii]. Como normalmente componentes so
desenvolvidos no estilo blackbox, revelando o mnimo possvel de sua implementao, as
maneiras mais comuns de customizar um componente atravs da modificao de
propriedades ou da composio com outros componentes que especializam determinados
comportamentos [Weinreich & Sametinger, 2001, pg 42].
Na customizao por composio, um componente passa a conter uma referncia a outro e
repassa a ele as chamadas das operaes. Um componente s depende da interface do outro, o
que caracteriza um reuso blackbox [Szyperski, 1997, pg 137]. No reuso blackbox, nenhum
detalhe, alm dos providos pelas interfaces do componente e por sua especificao,
disponibilizado aos clientes. Outra maneira de customizar o comportamento de um
componente modificando suas propriedades. Tcnicas para isto incluem passagem de
parmetros para seus mtodos, tabelas lidas pelo componente, configurao e opes no
deploy. Uma abordagem comum associar um arquivo descritor a um componente.
O arquivo descritor possibilita que o componente seja configurado sem que seja necessrio
recompil-lo [Szyperski, 1997, pg 33]. O arquivo descritor prov informaes sobre o
contedo do pacote, sobre as dependncias externas e sobre as configuraes do componente.
Esta descrio analisada pela infra-estrutura de execuo e usada para instalar e configurar
o componente adequadamente [Weinreich & Sametinger, 2001, pg 44].
Componentes podem ser blackbox ou whitebox, com as classificaes intermedirias de
graybox ou glassbox [Szyperski, 1997, pg 29]. No reuso whitebox, detalhes do cdigo interno
so liberados, possibilitando, por exemplo, o uso da herana para customizar o
comportamento do componente [Szyperski, 1997, pg 33]. Apesar de no ser recomendada, a
herana que ultrapassa as fronteiras do componente s vezes utilizada [Szyperski, 1997, pg
32]. Entretanto, esta herana cria uma dependncia e acoplamento direto entre as
implementaes das classes, o que vai de encontro s caractersticas de componentes.
[DSouza & Wills, 1998, pg 475] prope uma maneira de transformar heranas em
composies de objetos.

Implementao dos Componentes

Podem existir componentes de software implementados em um paradigma procedural, tais

como rotinas em COBOL e bibliotecas de funes em C, embora, a maior parte dos
componentes seja desenvolvida utilizando-se metodologias e linguagens orientadas a objetos
[Vicenzi et al, 2005, p. 235] [Apperly, 2001, pg 29]. Para um componente o relevante sua
interface externa e no a maneira como foi implementado.
As primeiras APIs para componentes disponibilizavam apenas um conjunto de funes que
componentes externos poderiam invocar, enxergando o componente com um bloco nico.
Atualmente, as APIs possibilitam acessar os objetos que compe o modelo do componente
[DSouza & Wills, 1998, pg 394]. Desta maneira, as interfaces que o componente
disponibiliza ou requer definem o modelo de objetos que compatvel com aquele
componente. Referncias a objetos criados em um componente deixam as fronteiras e se
tornam visveis aos clientes do componente [Szyperski, 1997, pg 31]. Por exemplo, possvel
acessar o objeto clula do componente Planilha Eletrnica, o objeto ponto do Gerenciador
Grfico, etc. [DSouza & Wills, 1998, pg 394]. Desta maneira, o componente deixa de ser
visto como um bloco nico para ser visto como um contexto onde os objetos executam.
Outro fator importante a ser considerado na construo de componentes o empacotamento,
que possibilita que o componente seja instalado como uma unidade [Szyperski, 1997, 276]. O
empacotamento pode conter arquivos, mdulos, cdigo executvel, cdigo fonte, cdigo de
validao, especificaes, testes, documentaes, etc. [DSouza & Wills, 1998, pg 386]. Os
mecanismos para o empacotamento diferem de tecnologia para tecnologia [DSouza & Wills,
1998, pg 387]. Por exemplo, componentes Java so empacotados em arquivos JAR, que
incluem as classes que implementam os servios dos componentes, as classes adicionais, etc.
[DSouza & Wills, 1998, pg 400]. Os diversos fatores que definem as possibilidades de
implementao de um componente so definidos no component model correspondente.

5.1

Modelos de Componentes

Ao comprar um eletrodomstico, podemos plug-lo na tomada de uma casa porque a tomada,

o plug e a energia disponveis so aderentes a uma padronizao. Ao buscarmos a reutilizao
e substitutibilidade de componentes de software, eles tambm devem ser aderentes a um
padro, que na literatura chamado de modelo de componentes (component model 6 ). Assim
como h mais de um padro para tomada, h mais de um modelo para componentes de
software. Um programador pode criar seu prprio modelo, eventualmente sendo uma
especializao de um modelo disponvel. Para compatibilizar componentes de um modelo
para outro, pode-se desenvolver adaptadores.
Um component model define vrios aspectos da construo e da interao dos componentes,
abordando, entre outros fatores: como especificar o componente, como instanciar o
componente, quais os tipos de conectores e portas disponveis, qual o modelo de dados que
entendido por todos os componentes, como as ligaes entre os objetos pertencentes a
componentes diferentes so realizadas, como so feitas transaes distribudas, quais so os
tipos de interface, as interfaces obrigatrias, como so tratados o catlogo e a localizao dos
componentes, o despacho das requisies e respostas, a segurana, o repositrio, o formato, a
nomeao, os meta dados, a interoperabilidade, a documentao, os mecanismos de
customizao, a composio, a evoluo, o controle de verses, a instalao e a desinstalao,
os servios de execuo, o empacotamento, etc. [Councill & Heineman, 2001, pg 7, pg 11]
6

O termo component model equivalente ao termo component architecture definido por DSouza & Wills
[1998].

10

[Weinreich & Sametinger, 2001, pg 37] [Szyperski, 1997, pg 32] [DSouza & Wills, 1998, pg
396, pg 411]. Um component model tambm define padres para o component framework
associado.
O component model define o padro de descrio de interface [Weinreich & Sametinger,
2001, pg 39]. Alguns component models utilizam uma interface description language (IDL)
independente da linguagem de programao, enquanto outros valem-se de conceitos da
prpria linguagem ou da tecnologia para definir a interface, como o caso das interfaces OO.
Dependendo da IDL, interfaces podem incluir as excees que podem ser lanadas, prcondies e ps-condies para cada operao [Weinreich & Sametinger, 2001, pg 39].
Um componente deve ser unicamente nomeado [Weinreich & Sametinger, 2001, pg 40].
Alguns component models definem a existncias de identificadores nicos, como o caso do
COM Component Model. Outros modelos utilizam um espao de nomes hierrquico, como
o caso das tecnologias da Sun Microsystems, que utilizam o nome do domnio invertido.
Um component model deve definir quais so os padres de composio. Os tipos de
acoplamento mais comuns entre dois componentes so o de cliente/servidor e de
publicador/ouvinte [Weinreich & Sametinger, 2001, pg 43]. No primeiro, o cliente
explicitamente chama operaes do servidor e, no segundo, o ouvinte se registra como
tratador de eventos e informaes disponibilizadas pelo publicador. O component model
define tambm os tipos de conectores disponveis, que podem ser herdados da linguagem de
programao correspondente ou serem prprios da tecnologia de componentes, como no caso
do SOAP e IIOP.
Eventualmente, verses antigas e atuais de um componente tm que co-existir no mesmo
sistema. As regras e padres para a evoluo dos componentes e seu versionamento tambm
fazem parte do modelo de componentes [Weinreich & Sametinger, 2001, pg 44]. Um
component model tambm deve descrever como os componentes so empacotados e de forma
que eles podem ser individualmente instalados no sistema.
O component model tambm define o padro de deployment, que especifica a estrutura e a
semntica para os arquivos descritores. O component model define a maneira como feito o
deployment, incluindo o eventual registro do componente e da interface [Weinreich &
Sametinger, 2001, pg 45]. Tipicamente o deployment envolve trs passos: instalao do
componente; configurao do componente e do ambiente de execuo; e instanciao do
componente para uso [Councill & Heineman, 2001, pg 9].
Um projeto pode definir seu prprio component model independentemente ou como uma
especializao de um existente [DSouza & Wills, 1998, pg 411]. Os component models
genricos no provem um modelo de negcio especfico para um domnio. Ao especializar
um component model utiliza-se os servios de infra-estrutura transversais aos diversos
domnios [Weinreich & Sametinger, 2001, pg 37].
Por exemplo, a Object Management Architecture (OMA), definida pela Object Management
Group (OMG), prev a utilizao do CORBA como base para a construo de modelos de
componentes especializados. CORBAservices define a padronizao voltada para servios
gerais de sistemas distribudos, enquanto CORBAfacilities define a padronizao dos servios
horizontais (comuns a vrios domnios) [Weinreich & Sametinger, 2001, pg 46].
Alm da padronizao de servios de infra-estrutura, o modelo de componentes
eventualmente define tambm uma padronizao vertical [DSouza & Wills, 1998, pg 396]. A
padronizao vertical define um modelo de objetos que os componentes inter-operantes
compartilham e manipulam. Este modelo de objetos est ligado a um domnio especfico.
Normalmente, cada projeto define sua prpria padronizao.
11

H um tempo atrs, a OMG definiu padres para alguns domnios, como sistemas mdicos
(http://www.omg.org/docs/corbamed), finanas (http://www.omg.org/docs/finance), entre
outros. No h um padro especfico para o domnio da colaborao.
Corba Component Model (CCM), Microsoft OLE,(D)COM/COM+, Sun EJB, JavaBeans e
Webservice so alguns exemplos de componente models. Alguns modelos, como CORBA e
Webservices, possibilitam a reutilizao de componentes que no foram necessariamente
desenvolvidos na mesma linguagem de programao [Gimenes & Huzita, 2005]. Na subseo
seguinte, so apresentados alguns component models a ttulo de exemplo.

5.2

Exemplos de Modelos de Componentes

O OLE (Object Linking and Embedding) um modelo de componentes proposto pela

Microsoft cujo propsito inicial era integrar em um documento objetos gerados por diversas
aplicaes. Ao instalar no sistema operacional aplicaes compatveis com o modelo, elas
tornam-se automaticamente disponveis para receber e oferecer contedos. O editor de
documento passa a ser um container que pode carregar qualquer tipo de contedo que seja
disponibilizado pelas demais aplicaes, como grficos, sons, vdeo, figuras, etc. No
Microsoft Word, por exemplo, pode-se inserir em um documento, objetos de outras
aplicaes, conforme ilustrado na Figura 4. Ao instalar uma nova aplicao, no necessrio
modificar as demais para que elas possam trocar contedos.

Figura 4. Insero de um objeto OLE em um documento do Microsoft Word

COM, DCOM e ActiveX so outros modelos de componentes utilizados pela Microsoft que
vieram da evoluo das idias do modelo original OLE [Brockschmidt, 1996]. Os modelos
do suporte a diversos nveis de complexidade de componentes e possibilitam a integrao de
aplicaes desenvolvidas por diferentes fabricantes. A soluo enfoca componentes binrios
que inter-operam.
A Microsoft definiu um padro para seus componentes de interface com o usurio (widgets),
disponibilizados atravs da linguagem Visual Basic. O modelo introduzido foi o VBX, que
posteriormente foi substitudo pelo OCX, pelo ActiveX e depois pelo COM. Atualmente, o
modelo de componentes do .NET unifica toda a tecnologia de componentes da Microsoft. A
Borland desenvolveu seu prprio modelo de componentes de interface. O CLX (Component
Library for Cross Platform) possibilita o desenvolvimento de aplicaes para o Microsoft
Windows e para o Linux atravs dos ambientes Kylix, Delphi e C++ Builder.
O CORBA (Common Object Request Broker Architecture) fornece um modelo de
componentes que possibilita a comunicao entre componentes distribudos. O CORBA
utiliza a IDL (Interface Definition Language) para descrever a interface pblica de seus

12

servios. O cliente no dependente da localizao do objeto que est sendo invocado, da

linguagem que o mesmo foi programado ou do sistema operacional que est sendo utilizado.
Webservices um padro para comunicao entre componentes atravs da tecnologia Web.
A aplicao utiliza os servios destes componentes atravs do protocolo SOAP, que encapsula
as chamadas dos servios e os retornos em pacotes XML.
Enterprise Java Beans o modelo da Sun Microsystems para a interconexo de
componentes remotos em aplicaes corporativas. Recentemente a Sun lanou o modelo de
componentes para interface com o usurio Java Server Faces (JSF) e o modelo Portlets (JSR
168) para a reutilizao de componentes em portais na web. Utilizando este modelo possvel
reutilizar um componente desenvolvido para um portal em outro de modo que uma instituio
pode montar seu portal buscando ou adquirindo componentes de terceiros. Cada componente
possui um arquivo descritor que define suas configuraes e implementa uma interface que
define os mtodos ativados durante seu ciclo de vida, conforme pode ser observado nos
trechos de cdigo da Figura 5.

Figura 5. Arquivo descritor de um portlet ( esquerda) e

implementao de um mtodo referente ao ciclo de vida ( direita)

Para rodar estes componentes, necessria uma infra-estrutura de execuo especfica, que
cuida do ciclo de vida, agregao, segurana, configurao, persistncia, etc. Por exemplo, no
caso do Portlets, o container aciona os componentes que geram dinamicamente o contedo
exibido para o usurio, agregando a sada de cada um em uma nica apresentao.

Infra-estrutura de Execuo

Um container um sistema, normalmente desenvolvido por terceiros, com o objetivo de

hospedar e gerenciar componentes de um determinado modelo, provendo a eles servios de
infra-estrutura de execuo. O acesso remoto, o gerenciamento de transaes distribudas, o
pooling de recursos, o acesso concorrente, o clustering, a tolerncia a falhas, a autenticao, a
persistncia, a configurao, o gerenciamento de permisses e de sesso, etc., so exemplos
de servios providos por containers [DSouza & Wills, 1998, pg 401].
O container libera o desenvolvedor de implementar servios tcnicos de sistema de baixo
nvel, direcionando seus esforos para as regras de negcio e para a composio do sistema.
Em alguns casos, o uso de container tambm possibilita alterar aspectos no relacionados com
a lgica do negcio sem ter que alterar a aplicao, bastando re-configurar o container para
mudar aspectos como segurana, permisses, logging, banco de dados, etc.
A mquina virtual Java um container para executar componentes Java (arquivos .class ou
.jar). Algumas arquiteturas estendem o container para gerenciar componentes mais
especializados como servlets ou applets [DSouza & Wills, 1998, pg 460]. Tomcat, JBoss,
Webspheare, Pluto, JetSpeed, etc. so outros exemplos de containers. O container define uma
interface que estabelece a conexo com os componentes. Esta interface chamada de lifecycle
interface [Schwarz et al, 2003]. Esta interface acessada pelo container para gerenciar a
inicializao, execuo e desativao do componente.

13

Figura 6. Container de execuo dos componentes [Schwarz et al, 2003]

Component framework 7 o conjunto de elementos de software, regras e contratos que

governam a execuo de componentes que esto em conformidade com um modelo de
componentes [Szyperski, 1997 pg 369]. O component framework define as invariantes e os
protocolos de conexo entre os componentes, estabelece as condies ambientais para as
instncias dos componentes e regula as interaes entre elas [Szyperski, 1997, pg 276]. O
component framework normalmente roda no topo do container, juntamente com os
componentes [Councill & Heineman, 2001, pg 12] [Szyperski, 1997, pg 275].
O component framework segue e d suporte a um modelo de componentes oferecendo uma
infra-estrutura para apoiar a sua execuo. O framework fornece uma base para a integrao
dinmica dos componentes, at de diferentes fabricantes, de acordo com as necessidades e
preferncias dos usurios e desenvolvedores. O component framework oferece servios de
execuo como: criao de objetos, gerenciamento de ciclo de vida, persistncia de objetos,
licenciamento, acesso a dados, gerenciamento de transaes, balanceamento de cargas, etc.
Component frameworks para sistemas distribudos oferecem servios adicionais, como
formas de conexo e comunicao remota, notificao de eventos, localizao de servios,
segurana, etc. [Weinreich & Sametinger, 2001, pg 45]. Eventualmente, a interface ou o
componente precisa ser registrado no component framework antes de ser utilizado [Councill
& Heineman, 2001, pg 12].
A relao entre um componente e um component framework bem similar relao de um
programa com o sistema operacional, que prov servios de baixo nvel, como acesso a
dispositivos de E/S, gerenciamento de memria, etc. [Weinreich & Sametinger, 2001, pg 34].
Um sistema operacional prov um ambiente de execuo para aplicativos, colocando uma
camada sobre o hardware. O sistema operacional regula o acesso dos aplicativos aos recursos,
oferece servios de infra-estrutura, define os mecanismos de comunicao e
interoperabilidade entre os componentes e d suporte instalao e registro dos componentes
(aplicativos) [Weinreich & Sametinger, 2001, pg 34]. Os componentes so utilizados para
montar diferentes ambientes de trabalho e o sistema operacional define parcialmente a
arquitetura do sistema como um todo [Szyperski, 1997, pg 274].
O conceito de component frameworks est ligado idia de linha de produto [Barroca et al,
2005, pg. 20]. Uma linha de produtos de software um conjunto de produtos que
7

Component framework um termo com diversos entendimentos na literatura. Neste trabalho, est sendo
seguida a definio proposta por [Szyperski, 1997]. Component Framework equivalente ao conceito de
component model implementation definido por [livro cbse, pg 7].

14

compartilham um conjunto de caractersticas visando satisfazer um determinado segmento de

mercado ou uma misso especfica [Clements & Northrop, 2001]. Para reduzir os custos de
desenvolvimento e manuteno, os produtos so gerados de maneira sistemtica a partir de
um ncleo de artefatos.

Kits de Componentes

Um component kit uma coleo de componentes que foram projetados para trabalhar em
conjunto [DSouza & Wills, 1998, pg 404]. Component kits so frequentemente utilizados
para construir interfaces grficas para aplicaes a partir de botes, formulrios, listas, etc. De
um kit de componentes gera-se uma famlia de solues, fazendo diferentes arranjos e
eventualmente desenvolvendo alguns sob medida [Wills, 2001, pg 309]. DSouza & Wills
[1998] ilustram a utilizao de component kits na eletrnica. A partir de um conjunto de
componentes interoperveis e que seguem uma padronizao, pode-se construir circuitos para
os mais variados propsitos.

Figura 7. Desenvolvimento de um kits de componentes

e construo de aplicaes a partir deles [DSouza & Wills, 1998 pg 385]

A Figura 7 ilustra a gerao de um kit de componentes a partir de um conjunto de aplicaes

similares e a posterior construo de novas aplicaes a partir deste kit. Inicialmente, o
desenvolvedor analisa aplicaes similares, identificando e generalizando componentes
comuns, criando um kit de componentes. Tendo o kit, especializa-se os componentes para
montar novas aplicaes da mesma famlia [DSouza & Wills, 1998 pg 385].
Um kit de componentes projetado para um component model especfico, o que favorece a
interoperabilidade entre os componentes [DSouza & Wills, 1998, pg 428]. Um kit no
necessariamente possui um conjunto fixo de componentes, podendo ser adicionado novos,
respeitando a arquitetura definida. Para desenvolver um component kit coerente, deve-se
definir um conjunto de conectores e modelos para que os componentes se comuniquem,
definindo as funes de cada um. As diversas aplicaes compartilham os componentes, que
por sua vez executam na infra-estrutura de execuo, conforme pode ser observado na Figura
8.

15

Aplicao 1

Component A

Aplicao 2

Component B

Aplicao 3

Component C

Component D

Infra-estrutura
de execuo

Figura 8. Aplicaes, componentes e infra-estrutura de execuo

Um toolkit um tipo de SDK (Software Development Kit), que apresenta, alm dos
componentes, um conjunto de ferramentas para criar aplicaes para uma determinada
plataforma, sistema ou framework. Os toolkits so mais comumente encontrados para
componentes de interface com o usurio, tambm chamados de widgets. Alguns exemplos de
toolkits de widgets para a linguagem Java so o AWT (Abstract Windowing Toolkit), Swing e
SWT (Standard Widget Toolkit).
Toolkits possibilitam que programadores desenvolvam software a partir de componentes
prontos, mesmo sem muita experincia de programao, no estilo das ferramentas RAD
(Rapid Application Development). Os toolkits favorecem a criatividade dos desenvolvedores,
o que fundamental para reas no bem estabelecidas. Ao encapsular detalhes de
implementao de baixo nvel, os toolkits liberam os desenvolvedores para pensar em novas
interfaces e mecanismos de interao, e possibilitam uma prototipao rpida para testar,
refinar e validar as idias.

Arquitetura de Software Baseada em Componentes

Uma arquitetura define a estrutura 8 de um software, descrevendo as propriedades, restries e

relacionamentos de suas partes [Stafford & Wolf, 2001, pg 373]. Ela representa o conjunto de
restries e regras da implementao [DSouza & Wills, 1998, pg 481], definindo os
elementos, conectores, protocolos, componentes, propriedades visveis e a interao e a
funo de cada parte no contexto do sistema [Bass, Clements & Kazman, 2003]. A arquitetura
uma representao abstrata de alto nvel do projeto de um software. A granularidade dos
componentes da arquitetura pode variar de pequenos pedaos de cdigo a aplicaes inteiras,
como SGBDs ou servidores de e-mails. As conexes entre os componentes abstraem como
eles de fato interagem, como por exemplo, chamada de mtodo, compartilhamento de dados,
pipes, RPCs (Remote Procedure Calls), sockets, etc. [DSouza & Wills, 1998].
A maneira de reutilizar bons projetos de arquiteturas atravs dos estilos arquiteturais. Um
estilo arquitetural descreve uma famlia de arquiteturas de software que compartilham
propriedades, como por exemplo, os componentes permitidos, as restries e interaes entre
os componentes, as invariantes, o modelo computacional, etc. [Stafford & Wolf, 2001, pg
8

Na literatura, muitas vezes o termo arquitetura tambm usado com outro sentido, para representar a infraestrutura da aplicao, em frases do tipo o componente interage com a arquitetura da aplicao.

16

383]. Fluxo de dados, mquina virtual, chamada de procedimento, MVC (Model View
Controller), cliente-servidor, peer-to-peer, blackboard, camadas e orientao a servios so
exemplos de estilos arquiteturais [Barroca et al., 2005, pg 17]. Cada estilo normalmente
enderea um aspecto especfico do sistema, sendo portanto possvel de utilizar mais de um
estilo na mesma arquitetura. Alm disto, cada componente de um sistema pode ter uma
arquitetura e estilo arquitetural prprios, desde que a parte externa do componente seja
compatvel com a arquitetura da aplicao.
Apesar da arquitetura ser nica, pode-se fornecer vrias vises sobre ela [DSouza & Wills,
1998, pg 483]. Cada viso enfoca um determinado aspecto da arquitetura, omitindo os demais
[Stafford & Wolf, 2001, pg 386]. Algumas vises so mais apropriadas para o
desenvolvimento do sistema, outras para o reuso, outras para o teste e implantao.
O desenvolvimento baseado em componentes considera pelo menos duas vises da
arquitetura: arquitetura de aplicao e arquitetura tcnica [D'Souza & Wills, 1998]. Na
arquitetura de aplicao, a preocupao com a estrutura dos componentes do domnio,
representando um projeto lgico de alto nvel independente da tecnologia de suporte. Nesta
arquitetura so mostradas a funo de cada componente no contexto do sistema e a interao
entre eles. A arquitetura de aplicao consiste de um conjunto de decises sobre a plataforma,
um conjunto de component frameworks e os mecanismos de interoperao entre eles
[Szyperski, 1997, pg 275]. A arquitetura tcnica considera os detalhes da tecnologia de
componentes a ser utilizada e totalmente independente do domnio da aplicao. A
arquitetura tcnica retrata as tecnologias de comunicao entre os componentes (TCP/IP,
ODBC, etc.) e aspectos referentes a escalabilidade e performance.
Representa-se a arquitetura para facilitar o entendimento, implementao, reuso e evoluo do
sistema [DSouza & Wills, 1998, pg 483]. Para isto utiliza-se uma ADL (Architecture
Description Language). Algumas vantagens do uso de uma descrio formal da arquitetura
so [Stafford & Wolf, 2001, pg 378]: melhoria da comunicao entre os envolvidos, que
passam a contar com uma descrio precisa; identificao de similaridades entre diversas
arquiteturas; explicitao das caractersticas e propriedades das arquiteturas; e documentao
e identificao de dependncias e inter-relacionamentos.

Representao dos Componentes

A documentao indispensvel para a reutilizao [Sametinger, 1997]. A documentao

deve ser suficiente para que se possa recuperar um componente, avaliar sua adequabilidade
para o contexto da reutilizao, fazer adaptaes e integr-lo ao seu novo ambiente [Gimenes
& Huzita, 2005]. necessria uma notao comum entre os envolvidos para documentar e
debater sobre o projeto do sistema, reduzindo a chance de m interpretao. A UML (Unified
Modeling Language) a linguagem padro para representar o projeto de sistemas orientados a
objetos.
O conceito de componente adotado na UML mais abrangente do que o adotado no DBC. De
acordo com os autores originais da UML [Booch, Rumbaugh & Jacobson, 2000 pg 341]:
Um componente a parte fsica e substituvel de um sistema ao qual se adapta e
fornece a realizao de um conjunto de interfaces. Os componentes so
empregados para a modelagem de coisas fsicas que podem residir em um n,
como executveis, bibliotecas, tabelas, arquivos e documentos. Um componente
tipicamente representa o pacote fsico de elementos lgicos, como classes,
interfaces e colaboraes.

17

De acordo com este conceito, um arquivo de cdigo fonte, uma tabela do banco de dados, um
documento de ajuda, um arquivo de dados, um arquivo de iniciao, scripts etc., podem ser
considerados componentes. Na UML o propsito mais comum para o qual os componentes
so utilizados a modelagem de componentes de implantao que compe a implementao
do sistema. No DBC o termo componente representa um elemento arquitetural mapeado a um
executvel, que foi concebido visando a substitutibilidade, a reusabilidade e a
interoperabilidade, entre outros fatores. Entretanto, pode-se utilizar e estender a notao da
UML para representar componentes no contexto do DBC. Na Figura 9, a representao de um
componente na UML apresentada. Esta a notao adotada neste trabalho.
agent.class

kernel32.dll

Figura 9. Representao de componente na UML

O diagrama de componentes da UML est em um nvel de abstrao diferente do diagrama de

classes. O diagrama de componentes representa elementos fsicos do sistema. Entretanto, da
mesma maneira que as classes, os componentes realizam e dependem de interfaces. Na Figura
10 so apresentadas as representaes das conexes dos componentes com interfaces, na
forma icnica, onde as operaes so ocultadas, e na forma expandida. O relacionamento de
dependncia utilizado para representar uma interface requerida e o de realizao para uma
interface fornecida.
ComponenteA

ComponenteA

InterfaceX

<< interface >>

InterfaceX

ComponenteB

ComponenteB

+ operacao1() : int
+ operacao2(s : String) : boolean
+ operacao3(s : String) : String

Figura 10. Representao de interfaces na forma icnica e expandida

interligando dois componentes

Para representar as classes que o componente implementa, pode-se utilizar o relacionamento

de dependncia [Booch et al, 2000], conforme exemplificado na Figura 11. Entretanto,
normalmente no necessrio visualizar esta informao na forma de diagrama, sendo
mantida como parte da especificao do componente.

18

Classe1

ComponenteA

Classe2

Figura 11. Representao das classes que o componente implementa

Para representar o componente no contexto do cdigo, pode-se utilizar o smbolo de pacote da

UML, conforme pode ser observado na Figura 12 [Houston & Norris, 2001, pg 257].
<< interface >>

Componente

Componente

Figura 12. Representao da implementao do componente

DSouza & Wills [1998, pg. 84] prope a utilizao de um component type para documentar
um componente. O component type tem duas partes: o modelo esttico que representa o
estado interno e as informaes trocadas nas chamadas de operaes e nas associaes (o que
o componente conhece e entende), e a especificao das aes e seus efeitos no componente,
usando o vocabulrio provido pelo modelo esttico, conforme pode ser observado na Figura
13.
Component Name

BusinessModelObjects

Operations

Figura 13. Representao do component type

Alm da documentao grfica da estrutura e inter-relacionamento entre os componentes,

necessrio descrev-los textualmente. Nesta descrio necessrio englobar aspectos ligados
aos requisitos funcionais e no-funcionais do componente. Memria utilizada e tempo de
resposta so exemplos de aspectos que precisam ser documentados, pois podem criar
dependncias no previstas, em um fenmeno chamado de vazamento de propriedade
[Gimenes & Huzita, 2005]. No h uma notao padro para a descrio dos componentes.
Pode-se valer das maneiras de escrever padres de projetos para descrever componentes,
documentando, por exemplo: nome, inteno, propsito, motivao, aplicabilidade, contexto,
estrutura, participantes, colaboraes, conseqncias, questes de implementao, cdigo de

19

exemplo, usos conhecidos, componentes

propriedades, variabilidade, etc.

relacionados,

requisitos

no-funcionais,

10 Frameworks
O conceito de frameworks est intimamente relacionado ao de componentes, so conceitos
complementares que contribuem para a reutilizao de software [Gimenes & Huzita, 2005].
Um framework uma infra-estrutura reutilizvel de todo ou de parte de um sistema, com o
objetivo de ser instanciado para resolver uma famlia de problemas. As partes invariantes de
um domnio so implementadas no framework e reutilizadas nas instanciaes [Sommerville,
2003]. O framework oferece um arcabouo comum para um domnio de aplicaes,
promovendo a reutilizao do contedo conceitual do domnio de um software ou da soluo
de um problema [Gimenes & Huzita, 2005].
Ao definir uma arquitetura parcialmente implementada e encapsular detalhes de
implementao, o framework libera os desenvolvedores de terem que entender as
complexidades envolvidas com a soluo do problema e com o domnio utilizado [Pree,
1995]. O framework normalmente construdo por especialistas em um domnio particular e
utilizado por leigos naquele domnio [Lajoie & Keller, 1995]. A reutilizao proporcionada
pelo uso de um framework no atinge somente a implementao, se refletindo tambm na
anlise e no projeto do sistema.
Alguns frameworks so voltados para soluo de problemas ligados tecnologia, como
interface com o usurio, persistncia de objetos, suporte a MVC, etc. Outros frameworks so
voltados para um determinado domnio, como, por exemplo, aplicaes bancrias,
relacionamento com o cliente, etc. Estes frameworks so embasados em teorias e modelos do
domnio e definem uma arquitetura orientada para aquela rea de aplicao.
A utilizao de frameworks traz as vantagens associadas ao reuso de cdigo: aumento da
qualidade, reduo do esforo de implementao, direcionamento dos esforos para os
aspectos especficos da soluo, etc. Contudo, conforme discutido anteriormente, o reuso,
principalmente de cdigo proveniente de terceiros, pode trazer complicaes adicionais ao
desenvolvimento. No caso de framework, como muitas vezes ele que assume o fluxo da
aplicao 9 , para alterar os processos de execuo pode ser necessrio alterar o cdigo do
framework.
A construo de um framework no simples, e deve ser planejada para o reuso [Mattsson,
2000]. O framework deve ser: flexvel (reutilizar as abstraes em diversos contextos),
extensvel (permitir a adio ou modificao de funcionalidades) e compreensvel (bem
documentado, seguindo padres e provendo exemplos de utilizao) [Gimenes & Huzita,
2005]. Para desenvolver um framework, deve-se identificar e caracterizar o domnio do
problema e definir a arquitetura, o projeto da soluo e as maneiras de interagir e estender o
framework. Como muito difcil prever em um primeiro momento todas variabilidades e
requisitos de um framework, seu desenvolvimento normalmente feito iterativamente.
Um framework normalmente implementado de forma orientada a objetos, onde o
framework composto de classes abstratas e concretas, interfaces e arquivos de configurao.
Para especializar o framework utiliza-se herana, composio ou configurao. Os pontos de
extenso do framework so chamados hot-spots ou plug points [Johnson, 1997][Govoni,
9

A inverso de controle costuma ser usada em frameworks para reduzir o acoplamento entre a aplicao e o
framework. Este princpio chamado na literatura de princpio de Hollywood: No nos ligue, ns ligamos para
voc [Larman, 2002]. Ao invs da aplicao chamar o framework, o framework chama a aplicao em mtodos
pr-definidos.

20

1999]. Conforme ilustrado na Figura 14, a reutilizao do framework, tambm chamada de

instanciao, consiste em preencher os hot-spots para obter a aplicao final. As partes do
framework que so invariantes so chamadas de frozen-spots.

Figura 14. Instanciao de um framework [Oliveira, 2001, pg 23]

A construo de um framework ou componente pode ser feita independente dos outros

elementos, desde que mantida a interface e as propriedades requeridas pela arquitetura. Desta
maneira, um framework pode instanciado a partir de componentes e um componente pode ser
feito a partir de um framework, o que faz da arquitetura uma estrutura recursiva [Oliveira,
2001]. Muitas vezes frameworks OO so utilizados para gerar uma famlia de componentes.
Da mesma forma, frameworks complementares podem ser utilizados, tanto no nvel de
aplicao quanto no nvel do domnio. Pode-se, por exemplo, utilizar um framework de infraestrutura para a camada de viso, um outro para a camada de persistncia e o componente
estar estruturado de acordo com um framework de domnio.

11 Consideraes Finais
Nas linguagens de programao, o suporte ao reuso de cdigo iniciou-se com a possibilidade
do agrupamento de funcionalidade, onde linhas de cdigo so encapsuladas e rotuladas em
unidades denominadas procedimentos ou funes para serem reutilizadas em diversos pontos
do cdigo [Salus, 1998]. Com o tempo, passou-se a perceber a utilidade de agrupar funes
relacionadas na forma de bibliotecas, para serem reutilizadas entre aplicaes distintas.
Linguagens de programao orientadas a objetos aumentaram a possibilidade de reuso atravs
de unidades denominadas classes, que encapsulam dados e funes e possibilitam a herana
de cdigo e o polimorfismo de objetos. Da mesma maneira que a reutilizao de funes
especficas evoluiu para bibliotecas de funes, a reutilizao de conjuntos relacionados de
classes evoluiu para frameworks e componentes [Oliveira, 2001]. Um framework prov um
conjunto genrico de classes que deve ser completado para instanciar uma aplicao
especfica, enquanto o uso de componentes possibilita construir um sistema compondo-o a
partir de unidades de execuo.
A idia de que o software deveria ser componentizado surgiu na conferncia da NATO, que
lanou o termo engenharia de software, na Alemanha em 1968. Nesta conferncia, Doug
McIlroy [1968], em um artigo intitulado Mass Produced Software Components, levantou a
necessidade de agrupar coerentemente rotinas relacionadas de forma a montar componentes
que poderiam ser reutilizados em diversos sistemas. Esta reutilizao, alm de economizar
esforo de desenvolvimento, possibilitaria a produo de programas a partir de partes j
testadas e amplamente utilizadas [Gimenes & Huzita, 2005]. O surgimento dos componentes
21

para interface com o usurio, popularizado em 1992, com o Visual Basic eXtension, ou VBX,
ajudou a alavancar a utilizao de componentes [Oliveira, 2001]. Diversos estudos apontam a
tecnologia de componentes como promissora para melhorar o reuso e a manutenabilidade de
software [Szyperski, 1997, pg 18]
Componentes de software so auto-contidos (so relativamente independentes, fracamente
acoplados e encapsulam seu projeto e implementao, incluindo dados e funcionalidades);
reutilizveis (podem ser utilizados por terceiros, que no necessariamente precisam ter acesso
ao seu cdigo fonte); substituveis (podem ser trocados por outros componentes compatveis)
e provem servios especficos de uma maneira coesa, bem definida e padronizada. Um
componente de software pode ser desenvolvido e mantido independentemente e interage com
outros componentes ou com a infra-estrutura da aplicao. A orientao a objetos uma das
melhores maneiras de implementar componentes [Szyperski, 1997, pg 13] [DSouza & Wills,
1998].
A montagem de sistemas a partir de componentes est no meio termo entre configurao e
programao [Morch, 1997]. mais alto nvel que a programao, mas no to limitada como
a configurao. A componentizao oferece meios para evoluir e adaptar um sistema de uma
forma no to limitada quanto a customizao e no to complexa quanto a extenso. Atravs
do uso de componentes, o sistema pode evoluir medida que os processos de trabalho, as
necessidades e a experincia com o uso do sistema evoluem. Com componentes, reduz-se as
interdependncias amarradas fortemente no cdigo fonte da aplicao, melhorando a
extensibilidade e facilitando a adaptao e extenso.
Mesmo utilizando uma arquitetura de componentes, a interface da aplicao pode ocultar dos
usurios finais que o sistema foi desenvolvido baseado em componente. A componentizao
fica disponvel apenas aos desenvolvedores, que podem liberar diferentes verses da
aplicao alterando a configurao e o conjunto de componentes. Quando for necessrio
prover flexibilidade para o usurio final, pode-se disponibilizar a ele o conceito de
componente, bem como os mecanismos para instalar e desinstalar componentes da aplicao.
Estes componentes muitas vezes so do estilo plug & play, que imediatamente se tornam
disponveis para uso aps o deploy.
Ao utilizar o software baseado em componentes, o usurio aplica um conjunto de ferramentas
de sua escolha aos documentos e artefatos. Ao invs de apresentar ao usurio uma aplicao
que coloca um prego ou parafuso na parede, ele equipado com uma caixa de ferramentas
contendo, entre outras coisas, martelo, chave de fenda e parafusadeira, de onde ele pode
escolher qual a ferramenta mais adequada s suas preferncias e tarefa em questo.
Adicionalmente, ferramentas existentes podem ser combinadas para formar novas ferramentas
mais complexas para a realizao de tarefas especficas. Entretanto, esta flexibilidade para o
usurio final deve ser utilizada com cautela, pois abre espao para o usurio gerar
aberraes, combinando componentes incompatveis e destoantes.

12 Bibliografia
Apperly, H. (2001) The Component Industry Metaphor, in: Component-Based Software
Engineering: Putting the Pieces Together, Hineman, G.T. & Councill, W.T. (eds), AddisonWesley, ISBN 0-201-70485-4.
Barroca, L., Gimenes, I.M.S. & Huzita, E.H.M. (2005) Conceitos Bsicos, in:
Desenvolvimento Baseado em Componentes, Gimenes, I.M.S. & Huzita, E.H.M. (eds),
Editora Cincia Moderna, Rio de Janeiro, 2005. ISBN 85-7393-406-9, pg. 57-103.

22

Bass, L., Clements, P. & Kazman, R. (2003), Software Architecture in Practice, AddisonWesley 2003. ISBN: 0-321-15495-9
Booch, G. (1987), Software Components with Ada: Structures, Tools, and Subsystems.
Benjamin-Cummings, Redwood City, CA.
Booch, G., Rumbaugh, J. & Jacobson, I. (2000) UML: Guia do Usurio. Editoria Campus,
Rio de Janeiro. ISBN 85-352-0562-4
Brockschmidt, K. (1996) What OLE Is Really About, MSDN Archive, Microsoft
Comporation.
Disponvel
em:
msdn.microsoft.com/archive/
enus/dnarolegen/html/msdn_aboutole.asp
Brown & Wallnau [1996]
Clements, P. & Northrop, L. (2001) Software Product Lines Practices and Patterns.
Readding, Addison-Wesley, 2001.
Councill, B. & Heineman, G.T. (2001) Definition of a Software Component and Its Elements,
in: Component-Based Software Engineering: Putting the Pieces Together, Hineman, G.T. &
Councill, W.T. (eds), Addison-Wesley, ISBN 0-201-70485-4.
DSouza, D.F. & Wills, A.C. (1998) Objects, Components and Frameworks with UML: The
Catalysis Approach. Addison Wesley, ISBN 0-201-31012-0, 1998.
Gimenes, I.M.S. & Huzita, E.H.M. (2005) Desenvolvimento Baseado em Componentes,
Editora Cincia Moderna, Rio de Janeiro, 2005. ISBN 85-7393-406-9.
Govoni, D. (1999) Java Application Frameworks, Wiley & Sons, ISBN 0-471-32930-4.
Griss, M.L. (2001) Product-Line Architectures, in: Component-Based Software Engineering:
Putting the Pieces Together, Hineman, G.T. & Councill, W.T. (eds), Addison-Wesley, ISBN
0-201-70485-4.
Heineman, G.T. (2000), A model for designing adaptable software components, ACM
SIGSOFT Software Engineering Notes archive, Volume 25, Issue 1, January 2000, ISSN
0163-5948, pg 55-56
Houston, K. & Norris, D. (2001) Software Componentes and the UML, in: Component-Based
Software Engineering: Putting the Pieces Together, Hineman, G.T. & Councill, W.T. (eds),
Addison-Wesley, ISBN 0-201-70485-4.
Johnson R. (1997) Components, Frameworks Patterns .Symposium of Software Reusability
1997 USA.
Krueger, C.W. (1992) Software Reuse, ACM Computing Surveys, Volume 4 Issue 2 p131183.
Lajoie, R. & Keller, R.K. (1995). Design and reuse in object-oriented frameworks: Patterns,
contracts, and motifs in concert. In V. Alagar and R. Missaoui, editors, Object-Oriented
Technology for Database and Software Systems, pages 295-- 312, Singapore, 1995. World
Scientific
Mattsson, M. Evolution and Composition of Object-Oriented Frameworks, PhD Thesis,
Department of Software Engineering and Computer Science, University of
Karlskrona/Ronneby, 2000.
McIlroy, M.D. (1968), "Mass Produced Software Components", Software Engineering,
NATO Science Committee, pp. 138-150.

23

Meta Group [1994] pegar trecho da pg 166 Szyperski

Moore & Bailin, 1991
Morch, A.I. (1997) Three Levels of End-user Tailoring: Customization, Integration, and
Extension In: Computers and Design in Context, Edited by M. Kyng and L. Mathiassen,
MIT Press, USA.
Oliveira, T.C. (2001), Uma Abordagem Sistemtica para a Instanciao de Frameworks
Orientados a Objetos, Tese de Doutorado, Departamento de Informtica, PUC-Rio, Rio de
Janeiro, RJ, 2001.
Orfali, R., Harkey, D. & Edwards (1996) The Essential Distributed Objects Survival Guide,
John Wiley & Sons, New York.
Pfleeger, 2001
Pree, W. (1995), Design Patterns for Object-Oriented Software Development, AddisonWesley Publishing Company, 1995.
Pressman, R.S. (2000) Software Engineering : A Practitioner's Approach, McGraw Hill, New
York, NY, June 2000.
Salus, P.H.(1998) "Handbook of Programming Languages: Object-Oriented Programming
Languages". Vol. 1. Macimillian. Indianapolis. 1998.
Sametinger, J. (1997) Software Engineering with Reusable Components. Springer Verlag,
USA, 1997.
Schwarz, J., Sommer, H. & Farris, A. (2003), The ALMA Software System, ASP Conf. Ser.,
Vol. 314 Astronomical Data Analysis Software and Systems XIII, eds. F. Ochsenbein, M.
Allen, & D. Egret (San Francisco: ASP), 643
Sommerville, 2003
Stafford, J.A. & Wolf, A.L. (2001) Software Architecture, in: Component-Based Software
Engineering: Putting the Pieces Together, Hineman, G.T. & Councill, W.T. (eds), AddisonWesley, ISBN 0-201-70485-4.
Szyperski, C. (1997), Component Software: Beyond Object-Oriented Programming, AddisonWesley, ISBN 0-201-17888-5
Vicenzi, A.M.R., Maldonado, J.C., Delamaro, M.E., Spoto, E.S. & Wong, E. (2005)
Software Baseado em Componentes: Uma Reviso sobre Teste, in: Desenvolvimento
Baseado em Componentes, Gimenes, I.M.S. & Huzita, E.H.M. (eds), Editora Cincia
Moderna, Rio de Janeiro, 2005. ISBN 85-7393-406-9, pg. 233-280.
Weinreich, R.& Sametinger, J. (2001) Component Models and Component Services:
Concepts and Principles, in: Component-Based Software Engineering: Putting the Pieces
Together, Hineman, G.T. & Councill, W.T. (eds), Addison-Wesley, ISBN 0-201-70485-4.
Werner, C.M.L. & Braga, R.M.M.B (2005) A Engenharia de Domnio e o Desenvolvimento
Baseado em Componentes, in: Desenvolvimento Baseado em Componentes, Gimenes,
I.M.S. & Huzita, E.H.M. (eds), Editora Cincia Moderna, Rio de Janeiro, 2005. ISBN 857393-406-9, pg. 57-103.
Wills, A.L. (2001) Components and Connectors: Catalysis Techniques for Designing
Component Infrastructures, in: Component-Based Software Engineering: Putting the Pieces
Together, Hineman, G.T. & Councill, W.T. (eds), Addison-Wesley, ISBN 0-201-70485-4.

24