6

O Processo de Desenvolvimento Baseado em

Componentes Atravs de Exemplos
Ns, seres humanos, os componentes mais complexos do
Universo - um dia haveremos de permitir que o nosso
poder de abstrao e realizao tornem os componentes de
software uma realidade.

Itana Maria de Souza Gimenes1

Leonor Barroca2
Elisa Hatsue Moriya Huzita 3
Adriana Carniello4

Resumo:
A tcnica de desenvolvimento baseado em componentes visa fornecer um
conjunto de procedimentos, ferramentas e notaes que possibilitem que, ao longo do
processo de software, ocorra tanto a produo de novos componentes quanto a
reutilizao de componentes existentes. Este captulo apresenta aspectos relevantes a
serem considerados no processo de desenvolvimento de software baseado em
componentes. O processo apresentado tem por base o mtodo Catalysis. A aplicao
utilizada como ilustrao um Gerenciador de Obras de construo civil.

Professora Associada, Universidade Estadual de Maring*

Departamento de Informtica
Av. Colombo, 5790 87020-900 Maring-PR, Brasil
itana@din.uem.br
http://www.din.uem.br/~itana
2

Lecturer, Department of Computing

The Open University
Milton Keynes MK7 6AA, Inglaterra
l.barroca@open.ac.uk
http://mcs.open.ac.uk/lmb3
3

Professora Associada, emhuzita@ din.uem.br

http://www.din.uem.br/~emhuzita
4

Mestranda, DCA-FEE-Unicamp

6.1 Introduo
A engenharia de software tem por objetivo tanto a melhoria da qualidade dos produtos e
processos de software quanto o aumento da produtividade e reduo dos custos e
esforos para produo de software. Assim, a definio de tcnicas de desenvolvimento
de software que enfatizem princpios como extensibilidade, flexibilidade e
principalmente reutilizao, dentre outros, de grande relevncia no contexto da
engenharia de software.
A reutilizao um princpio importante uma vez que permite a construo de software
por meio de unidades bem especificadas e testadas. possvel pensar, tambm, na
reutilizao em nvel de artefatos resultantes do processo de desenvolvimento de
software (processo de software), como idias, conceitos, requisitos e projetos adquiridos
ou construdos.
A tcnica de desenvolvimento baseado em componentes visa fornecer um conjunto de
procedimentos, ferramentas e notaes que possibilitem que ao longo do processo de
software ocorra tanto a produo de novos componentes quanto a reutilizao de
componentes existentes.
Este captulo apresenta aspectos relevantes a serem considerados no Processo de
Desenvolvimento de Software Baseado em Componentes P(CBD5 ). Embora ainda seja
difcil especificar precisamente um PCBD, alguns modelos de processo tm surgido na
literatura. Particular ateno tem sido dada a abordagens mais recentes como o Processo
Unificado[JAC 99] e o Catalysis [DSO 99] [WIL 99]. Essas abordagens tm a
vantagem de utilizar, UML6 [RUM 99] [BOO 99] como notao bsica. Neste texto
exploramos um PCBD baseado nas idias do Catalysis.
A aplicao utilizada como ilustrao um Gerenciador de Obras de construo civil. O
objetivo do texto mostrar um PCBD guiado pelo Catalysis [DSO 99]7 , porm
destacando tambm os fundamentos bsicos de CBD, no necessariamente associados a
este mtodo. Ao longo do processo destacamos um subconjunto mnimo dos modelos
do Catalysis, por questes de simplicidade e espao.
A seo 6.2 apresenta o conceito de componente. A seo 6.3 apresenta uma descrio
sumria do sistema exemplo. A seo 6.4 apresenta um PCDB baseado no Catalysis. As
sees seguintes seguem as fases definidas no PCDB, apresentado na seo 6.4, que
so: especificao de requisitos, especificao do sistema, projeto da arquitetura e
projeto interno dos componentes. Finalmente, na seo 6.9, apresentamos os
comentrios finais.

Component Based Development.

Unified Modelling Laguage.
7
[DSO99] a referncia bsica para o mtodo Catalysis. Informaes sobre o mtodo tambm podem
ser encontradas em http://www.catalysis.org.
6

6.2 Componentes
Um componente definido como uma unidade de software independente, que encapsula
dentro de si seu projeto e implementao, e oferece interfaces bem definidas para o
meio externo. Por meio destas interfaces, um componente pode se unir a outros
componentes e dar origem aos sistemas baseados em componentes [DSO 99]. Um
componente apresenta interfaces que separam sua especificao da implementao.
Essas interfaces no permitem que os usurios conheam os detalhes de implementao
do componente. A especificao de um componente , normalmente, publicada
separadamente de seu cdigo fonte por meio da especificao das interfaces oferecidas
por ele.
Componentes podem variar desde componentes construdos pelo cliente, ou
componentes adquiridos para um domnio especfico, at componentes Commercial
Off-The-Shelf (COTS). Componentes COTS so componentes genricos que podem ser
prontamente adquiridos no mercado (de prateleira). Existe uma grande motivao para o
uso de componentes COTS, mas para que o uso efetivo desses componentes se realize
ainda necessrio o desenvolvimento de mtodos mais precisos para sua produo e
utilizao [CAR 97].
Componentes de software podem ser constitudos por componentes mais simples, assim
o processo de construo de componentes pode ser considerado como recursivo. Nesse
contexto, um componente pode ser no apenas cdigo pronto para reutilizao mas
tambm unidades de projeto que tm significado prprio. A exemplo, frameworks
podem ser vistos como componentes flexveis, em nvel de projeto.
Para que a reutilizao de componentes seja possvel preciso que estes sejam
adaptveis. O projeto de um componente deve ser conduzido de tal forma que alm de
tornar a sua execuo correta e eficiente, deve ser genrico para que se torne adaptvel a
vrios propsitos e no somente ao propsito ao qual ser primeiramente aplicado
[DSO 99].
Muitas vezes pode ser til entender a distino entre objeto, no contexto do paradigma
de orientao a objetos, e componente. Um componente geralmente trabalha com outros
para apoiar uma particular ao em nvel de negcio (caso de uso) enquanto um objeto
geralmente representa uma instncia de um conceito do negcio[DSO 99]. A princpio,
o nvel de granulosidade de um componente maior do que o de um objeto.
Para uma ilustrao simples, a figura 6.10 mostra um sistema baseado em componentes
construdo a partir da paleta de beans (componentes) do VisualAge [ITE 99]. A
aplicao tem uma lista de partes e uma entrada para adicionar partes lista. Para
construir a aplicao so selecionados da paleta de componentes do VisualAge os
seguintes componentes: um campo de texto, dois botes, uma lista e dois rtulos. Estes
componentes so selecionados e adicionados na rea de projeto, podendo ser adequados
as suas cores, tamanhos e fontes, como o projetista desejar. Em seguida, os
componentes so associados s funes que devem realizar. Assim, o boto Exit e a
Janela da aplicao so associados ao mtodo dispose(), indicando que ao acionar o
boto ou o X no canto superior direito da janela, esta dever ser fechada. Da mesma

forma o boto Add associado a um mtodo add(string) da List of Parts, tomando como
entrada o string contido na caixa de texto com o rtulo Part.
Caixa de texto

Order Entry Window

Part
Add
List of Parts
Botes

Rtulos

Exit

dispose()

dispose()
Lista

Figura 6.1: Exemplo de um sistema desenvolvido com componentes[ITE 99].

6.3 O Sistema Exemplo: Gerenciador de obras em

Construo civil
A fim de ilustrar um PCDB, ser utilizado um sistema Gerenciador de Obras em
construo civil, em um nvel de abstrao simplificado. Portanto, alguns detalhes so
omitidos enquanto a nfase colocada na ilustrao dos vrios estgios do processo.
O domnio principal a ser analisado de uma construtora. Um cliente que esteja
interessado em construir um imvel procura a construtora para realizar a cons truo.
Um cliente possui, por um lado, determinadas expectativas (desejos) em relao a seu
futuro imvel, tais como posio dos cmodos, distribuio, tipo (se sobrado ou trrea),
ter uma piscina e formato dessa piscina. Por outro lado, tem-se tambm que analisar as
condies do terreno para verificar a viabilidade de construir com as caractersticas
desejadas pelo cliente (por exemplo, se a rea do terreno for restrita, provavelmente no
haver espao para piscina).
Uma vez entendida as caractersticas desejadas pelo cliente, deve-se elaborar o projeto
correspondente. A elaborao do projeto constitui-se de vrias etapas como: elaborar o
projeto arquitetnico, estrutural, eltrico e hidrulico. Note que diferentes profissionais
podem estar envolvidos, cada um em sua especialidade (ex. o engenheiro civil, o
arquiteto e o engenheiro eltrico). Ao projeto elaborado estar associada uma obra a ser
construda, que na verdade consistir na execuo de vrias tarefas. Dentre as tarefas
(normalmente j predefinidas no caso da construo civil), podem ser destacadas: fazer
a terraplanagem, madeiramento, levantar paredes, azulejar, efetuar pintura, entre outros.

Essas tarefas so executadas por mestre de obras, pedreiro, azulejista e eletricista. Para a
execuo dessas tarefas, deve-se definir e alocar os recursos materiais e humanos
necessrios, agendar essas tarefas, alm de monitorar a execuo destas tarefas.

6.4 Processo de Desenvolvimento de Componentes Baseado

em Catalysis
Um PCBD tanto tem caractersticas comuns aos processos de software convencionais
quanto contm caractersticas peculiares. Essas caractersticas peculiares se refletem na
adio de estgios tcnicos ao processo convencional, bem como numa maior nfase em
prticas j realizadas nesses processos, sejam eles processos que seguem a abordagem
funcional ou orientada a objetos.
Um PCBD, geralmente, inclui a definio de estratgias para:
separao de contextos a partir do modelo de domnios;
particionamento do sistema em unidades independentes (compone ntes);
identificao do comportamento interno dos componentes;
identificao das interfaces dos componentes;
definio de um kit de arquitetura, que inclua princpios e elementos que
facilitam a conexo de componentes (ex. kits de GUI, incluindo janelas,
scrollbars, buttons, etc.); e
manuteno de um repositrio de componentes.
Prticas j realizadas em processos convencionais como ciclos de vida rpidos, ciclos de
vida incremental, iteraes e feedbacks, tm uma grande nfase em um PCBD. A
exemplo, se existir uma inteno prvia de reutilizao de componentes na construo
de um sistema importante ter uma especificao preliminar do sistema e tentar
estabelecer, previamente, um possvel projeto interno dos componentes. Em seguida,
pode-se retroceder para encontrar como os componentes integrados podem atender as
necessidades do sistema. No processo de desenvolvimento baseado em componentes a
experincia do projetista conta muito, a percepo de uma possvel reutilizao pode
guiar o desenvolvimento para tornar esta reutilizao mais fcil.
O mtodo Catalysis incorpora conceitos importantes para o desenvolvimento de
software baseado em componentes. O mtodo utiliza-se de UML [RUM 99], com
algumas alteraes, para especificao dos diferentes artefatos (diagramas) que so
elaborados durante o processo de desenvolvimento.
Os princpios fundamentais do mtodo Catalysis so:
construo de um modelo de domnio do sistema, baseado em tipos, objetos
e aes, que enfatizam a independncia entre o domnio, a possvel soluo
de software e sua implementao;
forte nfase nos conceitos de abstrao e refinamento para representar os
relacionamentos essenciais entre os artefatos do sistema obtidos durante o
processo de desenvolvimento. A nfase no refinamento dos artefatos cria

uma srie de fatoraes, extenses e transformaes que visam o

rastreamento dos requisitos at o cdigo;
nfase na especificao de pr-condies, ps-condies e invariantes;
procedimentos e diagramas que apoiam o particionamento do sistema, e o
projeto e a conexo de componentes;
forte articulao do processo de desenvolvimento com os conceitos de
arquitetura de software, padres e frameworks;
uso de ciclos de vida rpido, iterativo e incremental.

Com relao seqncia de estgios tcnicos que constituem o processo de

desenvolvimento baseado em Catalysis, importante ressaltar que Catalysis no define
um processo nico de desenvolvimento, mas contm um conjunto de idias, conceitos e
procedimentos que possibilitam aos projetistas escolher o melhor processo para o seu
projeto.
comum buscarmos uma correspondncia entre o processo de software clssico
(especificao de requisitos, especificao do sistema, projeto da arquitetura,
implementao e teste) [GIM 94] para entender o processo de software do Catalysis.
Reproduzimos na figura 6.2 [DSO 99] um processo desenvolvimento tpico de um
sistema de informao baseado no Catalysis. Este processo envolve uma interface com
o usurio e um banco de dados. Os estgios que compem este processo so similares
queles do processo de software clssico. Esses estgios so representados esquerda
da figura: especificao de requisitos, especificao do sistema, projeto da arquitetura e
projeto interno dos componentes. Para cada estgio so representados, direita, os
modelos do Catalysis. O dicionrio contm os conceitos utilizados ao longo do
processo.
A especificao de requisitos visa entender e representar o problema definindo o
contexto do sistema envolvido e produzindo um modelo do domnio. A especificao do
sistema trata a soluo de software extrada do modelo do domnio representando-se os
tipos e operaes do sistema e seu comportamento exterior. O projeto da arquitetura
pode ser visto em duas partes, denominadas arquitetura da aplicao e arquitetura
tcnica. A arquitetura da aplicao representa a estrutura lgica do sistema como uma
coleo de componentes cooperantes com os tipos e operaes obtidos na especificao
distribudos atravs dos componentes. A arquitetura tcnica inclui as partes do sistema
independentes do domnio como a infra-estrutura de comunicao de componentes (ex.
CORBA ou Java/RMI), a plataforma de hardware e a plataforma de software. O Projeto
interno dos componentes envolve a definio das classes e interfaces dos componentes,
a construo (cdigo) e teste dos componentes. Esses estgios so detalhadas nas sees
seguintes.

Modelos de domnio
Especificao de
Requisitos
Contexto do sistema

Entender o problema, o contexto do sistema,

a arquitetura e os requisitos no funcionais

Cenrios
Projeto de interface
do usurio

Especificao do
sistema
Modelo de tipos e
especificaes de operaes

Fluxo de dilogo,
prottipo, usabilidade

Descrever o comportamento externo do sistema

atravs do modelo de domnio do problema
Dicionrio

Plataforma,
arquitetura fsica
Projeto da arquitetura
Arquitetura de
aplicao lgica

Separar os componentes arquiteturais tcnicos dos de aplicao

e os seus conectores para se alcanar os objetivos de projeto

Projeto interno dos

componentes

Especificaes de
classe e interface

Projeto de
banco de dados

Mapeamento de classes,
transaes, etc.

Implementao e teste

Projetar interfaces e classes para cada componente;

construir e testar

Figura 6.2: Principais fases do desenvolvimento de um sistema de

informao[DSO 99].
Embora a figura 6.2 apresente a nfase nos componentes a partir do estgio de projeto
da arquitetura, isto pode variar dependendo do projeto da aplicao objetivo. Catalysis
permite o desenvolvimento de um sistema por meio de vrias possveis rotas. Cada rota
envolve a seqencia de atividades e artefatos que melhor se adapta s caractersticas do
projeto. Para ilustrar esses conceitos reproduzimos na figura 6.3 dois exemplos de rotas
apresentados em [DSO 99]: a rota construir e a rota montar 8 . A rota construir
adequada para um projeto no qual os requisitos devem ser definidos antecipadamente e
precisamente. Esta rota envolve a seguinte seqncia:

Montar utilizado como traduo de to assemble. A semntica desejada a de montar componentes

de forma similiar a como montamos quebra-cabeas.

1. Construir1 construir o modelo do domnio para captar termos, regras e

tarefas do domnio.
2. Construir2-3 refinar o modelo do domnio para especificar o sistema
construindo o modelo de tipos do domnio. O mapa de recuperao
definido de maneira top-down.
3. Construir4-5 particionar e refinar para construir os modelos de projeto.
Novamente, o mapa de recuperao definido a partir do modelo de tipos do
sistema, que distribudo atravs dos componentes de projeto encontrados.

Modelo de domnio: termos do

negcio, regras, aes

Rota Construir

Construir 1

Refinamento:
mapeando da
especificao ao
domnio

Rota Montar

Montar 1

Construir 2

Montar 5

Especificao do sistema :
comportamentos e modelo de tipos

Modelo de domnio
do sistema

Refinamento, recuperao:
mapeamento dos componentes
internos para especificao do
sistema

Construir 3

Montar 4

Construir 4

Montar 3

Montar 2

Construir 5

Figura 6.3: Exemplo de rotas de aplicao do Catalysis [DSO 99].

A rota montar se adapta ao caso de um sistema construdo a partir de componentes
heterogneos em um projeto em que os requisitos podem ser adaptados para facilitar a
montagem do sistema com os componentes existentes. Esta rota inclui:

compem uma ao maior podem ocorrer, em paralelo ou em seqncia utilizado um

diagrama de seqncia, conforme ilustra a figura 6.4e.

Tipo de ao

Construir

Construir

Contratar
servio

Construtora

Realizar
obras

Pagar
servio

Cliente

Obra
Tipo de objeto

Construtora

Obra

Cliente

Gerente

Figura 6.4: Ilustrao de alguns diagramas de especificao de requisitos do Catalysis.

Alternativamente, pode-se utilizar o diagrama de casos de uso da UML para representar

a colaborao entre objetos e aes [RUM 99] [SCH 98]. O domnio da aplicao
exemplo envolve uma construtora, assim o diagrama de casos de uso da construtora
apresentado na figura 6.5. Os objetos representados no diagrama so o cliente, o
fornecedor, e os departamentos da construtora: gerncia comercial, gerncia de

construo civil, gerncia financeira, gerncia de pessoal e gerncia de materiais. As

aes so Contratar servio, Requisitar oramento, Realizar pagamento, Contratar obra,
Informar andamento, Gerenciar obra, Estudar viabilidade e Solicitar material. O
diagrama esttico de tipos correspondente ao domnio da construtora apresentado na
figura 6.6.

Informar Andamento

Cliente

Gerncia de
Construo Civil
Estudar Viabilidade

Contratar Servio

Gerncia
Comercial
Gerenciar Obra

Requisitar Oramento

Realizar Pagamento

Gerncia
Financeira

Gerncia
Pessoal

Gerncia de
Materiais
Solicitar Material

Fornecedor

Figura 6.5: Diagrama de casos de uso da Construtora.

Paga
1..*
Possui

Possui

Cliente

Servio

Fatura

1..*
1..*

1..*

Administra

Reponsvel por

Contrata

Controla
1..*

1..*
Fornece

1..*

1..*

Utiliza

Material

Gerncia Financeira

Gerncia Comercial

Gerncia de Materiais

Viabilidade

Possui

Obra
1..*

1..*

1..*

Responsvel por

Aloca pessoas
Gerncia de Construo Civil

Fornecedor
Gerncia Pessoal

Figura 6.6: Modelo esttico de tipos da Construtora.

Cada tipo neste diagrama corresponde a um objeto do domnio, no estando

representados ainda eventuais tipos que venham a ser includos como parte da soluo
do problema. Note que, a documentao do sistema deve conter um glossrio com todos
os tipos que aparecem nos modelos. As aes tambm devem ser descritas com as pr e
ps-condies associadas a elas.
A construtora usa um sistema de software para gerenciar as obras. A partir desse ponto
passa-se a pensar no comportamento do software a ser desenvolvido, pois at agora foi
tratada a modelagem do domnio no qual o software est inserido. Assim, refinando a
ao Gerenciar obras do domnio apresentado na figura 6.5, obtemos o diagrama de
casos de uso mostrado na figura 6.7.

Projetar Arquitetura

Arquiteto

Elaborar Projeto
Hidrulico

Elaborar Projeto Eltrico

Engenheiro
Eltrico

Projetar Estrutura

Rebocar
Engenheiro
Civil

Construir Alicerce
Levantar Paredes
<<inclui>>
<<inclui>>
<<inclui>>

Terraplanar e Alinhar
Terreno

<<inclui>>

<<inclui>>

Colocar Teto
Construir

<<inclui>>
<<estende>>

<<inclui>>

Telha de Fibra

Construir Telhado
Mestre de
Obras

Fazer Madeiramento

<<estende>>

Telha de Cermica
Pedreiro
Carpinteiro
Eletricista

Encanador

Figura 6.7: Diagrama de Casos de Uso do Gerenciador de Obras.

As principais aes do gerenciador de obras, representadas no diagrama de casos de uso
so: Projetar Arquitetura, Elaborar Projeto Hidrulico, Elaborar Projeto Eltrico,

Projetar Estrutura e Construir. A ao Construir uma ao complexa que incorpora

aes menores como Construir alicerce, Rebocar e Levantar paredes. Esse
relacionamento entre as aes representado por uma dependncia com o esteretipo
<<inclui>> entre os respectivos casos de uso, dos diagrama de casos de uso da UML9 .
Este relacionamento de dependncia (<<inclui>>) pode ser utilizado tambm para
representar aes compartilhadas. Nesta situao, mais de um caso de uso pode
convergir para um caso de uso compartilhado. Um relacionamento de dependncia,
portanto, representado por uma seta tracejada 10 que, neste caso, parte do caso de uso
base para o caso de uso includo. Neste exemplo o caso de uso base Construir.
O relacionamento de dependncia com o esteretipo <<estende>> representa casos de
uso ampliados (estendidos) a partir de um casos de uso base. Note que pode haver vrias
extenses de um caso de uso base as quais adicionam semntica a este. o caso de uso
base que instanciado e, dependendo da situao, as extenses so acionadas. Por
exemplo, Construir Telhado de Fibra e Construir Telhado de Cermica so aes que
estendem a ao Construir Telhado, dependendo do tipo de telhado desejado. Este
relacionamento de dependncia (<<estende>>) representado por uma seta tracejada
que parte do caso de uso estendido para o caso de uso base10 . Neste exemplo o caso de
uso base Construir Telhado. A figura 6.8 representa o diagrama esttico de tipos do
domnio do software a ser construdo. Nesse nvel, so considerados apenas os tipos que
representam as abstraes do domnio, portanto esse diagrama ainda no inclui
representaes de software.

Figura 6.8: Modelo esttico de tipos do domnio do Gerenciador de Obras.

9

Note que o esteretipo <<inclui>> substitui o relacionamento esteretipo <<usa>> na verso mais
recente de UML. Veja [Rum99] e [Boo99] para detalhes e exemplos de utilizao.
10
O diagrama correspondente no contm a seta tracejada pois usamos uma verso anterior da ferramenta
Rational Rose que no suporta a seta tracejada.

O diagrama de casos de uso no representa a seqncia das aes. Esta representao

pode ser obtida por meio de diagramas de seqncia, que mostram os vrios cenrios
em que as aes podem ocorrer. As barras horizontais representam as ocorrncias das
aes e as barras verticais representam instncias de objetos. A figura 6.9 mostra o
arquiteto Jonas numa ao iterativa de projetar a arquitetura, em seguida o engenheiro
civil Paulo realiza o projeto estrutural e hidrulico para ento o engenheiro eltrico
Rogrio realizar o projeto eltrico. Aps isso, o engenheiro civil Paulo envia mensagem
ao mestre de obras Srgio para terraplanar, que em seguida envia mensagem ao pedreiro

associao dessas aes com os tipos. Porm, neste estgio de modelagem a

preocupao ainda no est em como esses tipos e aes sero implementados.
O modelo esttico de tipos para o software Gerenciador de Obras, obtido a partir dos
diagramas de casos de uso, diagrama de tipos e diagramas de seqncia, desenvolvidos
na seo anterior, representado na figura 6.10.

Viabilidade
Implementa

0..*
Atende
Possui

Projeto

Arquitetnico

Necessidade_Cliente
1..*

1..*

1..*

Estrutural

Hidrulico

Eltrico
Telhado Cermica

Obra

Telhado Fibra

1..*

Terraplanagem

Alicerce

Paredes

Teto

Madeiramento

Desempenho
Avalia
Possui

Custo

1..*

Utiliza

Material

1..*

0..*

Registra

Reboco

arquiteto

Estima

Tarefa

1..*

Telhado

Emprega

Agenda

engenheiro eltrico
engenheiro civil

Registro de Execuo
mestre de obras

1..*

Possui

Pessoa
0..*

Cargo
0..*

pedreiro

eletricista

encanador

carpinteiro

Figura 6.10: Modelo Esttico de Tipos do Software Gerenciador de Obras.

Pode-se notar que o modelo j inclui uma srie de refinamentos de objetos encontrados
nos modelos anteriores, bem como tipos adicionais, que tornam as abstraes desejadas
mais precisas, j incluindo ento representaes de software. A obra relacionada ao
Construir foi associada s tarefas que a realizam. As tarefas esto associadas a pessoas
que ocupam cargos. Esses cargos representam aqueles objetos reconhecidos no
diagrama de casos de uso (ex. engenheiro civil, eltrico, etc.). Tambm foi includa uma
agenda para representar a atribuio de tarefas s pessoas. Esto associadas s tarefas
tipos que facilitam a representao de sua execuo como Desempenho e Registro de
execuo.

Juntando as especificaes das aes externamente visveis do sistema com o modelo

esttico de tipos podemos chegar especificao completa do sistema, conforme
apresentado na figura 6.11. Este modelo representa o comportamento externamente
visvel do sistema, incluindo os atores que direta ou indiretamente possam interagir com
o sistema. Ainda no h, necessariamente, uma correspondncia entre os tipos e a
implementao do sistema. A partir deste modelo sero introduzidas as questes de
particionamento do sistema para definio de sua arquitetura interna.
As aes do sistema especificam o comportamento externamente visvel do sistema,
estabelecendo o que qualquer implementao fornecer para o usurio,
independentemente de como ser realizada a implementao. a especificao que
deve formar as bases para verificar o mapeamento entre o que requerido e o que j
existe. Muitos sistemas so desenvolvidos com partes existentes j implementadas. Uma
implementao aceitvel para uma parte de um sistema aquela que satisfaz sua
especificao. A especificao das aes deve ser feita de uma forma rigorosa,
nomeadamente, usando pr e ps-condies.
Gerenciador de Obras
Viabilidade

Arquiteto

Projetar
Arquitetura

Implementa

Atende 0..*
Possui

Projeto

Arquitetnico

Necessidade_Cliente

Estrutural

Auxiliar
Pedreiro
na construo

1..*

1..*

1..*

Hidrulico

Eltrico
TelhadoCermica

Obra

TelhadoFibra

1..*

Terraplanagem

Elaborar
Engenheiro Eltrico Projeto
Eltrico

Alicerce

Paredes

Teto

Madeiramento

Desempenho
Avalia
Possui

Custo
1..*

Utiliza

Material

1..*

0..*

Registra

arquiteto

Estima

Tarefa

1..*

Telhado

Emprega

Agenda

Reboco

Realizar
Instalao
Eltrica

Eletricista

engenheiroeltrico
engenheiro civil

RegistrodeExecuo

Projetar e
Monitorar
Engenheiro Civil
a Construo

mestre de obras

1..*

Possui

Pessoa
0..*

Cargo
0..*

pedreiro

Realizar
Instalao
Encanador
Hidrulica

eletricista

encanador

carpinteiro

Conduzir
Mestre de Obras a Construo

Fazer
Madeiramento Carpinteiro
do Telhado

Figura 6.11: Especificao de tipos do Gerenciador de Obras.

Exemplos de aes associadas ao Gerenciador de Obras so Iniciar obras e Agendar
tarefa. Essas aes fazem parte do refinamento do caso de uso Projetar e Monitorar a
Obra.

A ao iniciar obra pode ser representada como:

action Obra::Iniciar(p: projeto)
Pr-condio: os projetos arquitetnico, estrutural, eltrico e hidrulico devem
estar prontos.
Ps-condio: um objeto Obra criado e associado ao objeto Projeto que a
Obra implementa.
A ao agendar tarefa pode ser representada como:
action (o:obra, t:tarefa, p: pessoa, c: cargo, a: agenda)::Agendar_tarefa(t:tarefa,
p: pessoa, c: cargo, a: agenda)
Pr-condio: devem existir os objetos tarefa, pessoa, cargo, agenda e uma
obra da qual a tarefa faz parte.
Ps-condio: a agenda contm as ligaes entre tarefa, pessoa e cargo que
ocupa.
A cada um dos tipos do modelo de tipos esto associados atributos e aes inerentes a
estes. A figura 6.12 ilustra exemp los de atributos e aes dos tipos
Necessidade_Cliente, Obra e Custo.
type
Necessidade_cliente
-tipo_casa : enumerate = (plana, sobrado)
-custo_limite : Real
+estabelece_custo(valor : Real)

type
Custo
-custo_final : Real
-padro : enumerate = (A, B, C, D)
+estabelece_padro(padro_escolhido : enumerate)
+estabele_custo_individual(valor : Real)

type
Obra
-nome : String
-custo_total : Real
+insere_tarefa(nova_tarefa : Tarefa)

Figura 6.12: Exemplos de atributos de aes.

Ao sistema como um todo tambm podem estar associadas invariantes, que so
predicados que devem ser verdadeiros em qualquer estado que o sistema estiver.
Exemplos de invariantes aplicadas ao Gerenciador de Obras so:
o custo de uma Obra sempre o somatrio do custo de todas as tarefas.
o custo da obra deve ser sempre menor do que o custo limite estabelecido pelo
cliente.
o prazo final (deadline) da obra deve ser sempre maior que a data de
encerramento da ltima tarefa do caminho crtico da obra.
As pr e ps-condies e invariantes, descritas acima de forma textual, podem ser
escritas em uma linguagem rigorosa. Pode-se utilizar OCL (Object Constraint
Language) da UML[WAR 99]. A vantagem de usar OCL [WIL 99] que ela possibilita
a especificao de sentenas bem definidas nos primeiro estgios do processo de
desenvolvimento. As especificaes em OCL servem ento de base para teste do
software.

6.7 Projeto da Arquitetura

A arquitetura de um sistema de software engloba a definio de suas estruturas gerais,
descrevendo os elementos que compem os sistemas e as interaes entre estes [GAR
95], [SHA 96], [BUS 96], [BAS 98] e [BAR 99a]. Alm de descrever esses elementos e
suas interaes, uma arquitetura de software apoia tambm questes importantes de
projeto, tais como: a organizao do sistema como composio de componentes, as
estruturas de controle globais, os protocolos de comunicao, a composio dos
elementos do projeto e a designao da funcionalidade dos componentes do projeto.
Catalysis [DSO 99] sugere que o projeto da arquitetura de um sistema de software seja
dividido em duas partes relacionadas:
arquitetura de aplicao diz respeito a como particionar a prpria aplicao
em um conjunto de componentes que colaboram entre si. Nesse aspecto esto
relacionados as questes de adoo de um estilo de arquitetura (ex.
elementos, portas e conectores) e de utilizao de componentes heterogneos;
arquitetura tcnica descreve a estrutura de pacotes considerando uma infraestrutura de comunicao entre os pacotes, tomando os componentes em um
nvel de granulosidade maior. A arquitetura tcnica define, alm de eventuais
detalhes de hardware e protocolos, o mecanismo de comunicao entre os
componentes a ser utilizado (ex. CORBA, Java/RMI e COM) [ORF 96, PRI
99].

6.7.1 Particionamento de Modelos e Projetos

A unidade de decomposio de mais alto nvel do Catalysis o pacote. Um pacote
representa uma parte do sistema que pode ser tratada de maneira independente com o
explcito estabelecimento de dependncias do restante do sistema. A estrutura de
pacotes e seus relacionamentos representada por meio do diagrama de pacotes.
O principal relacionamento entre pacotes o de importao. Este um relacionamento
de dependncia, portanto representado por uma seta tracejada do pacote que importa
para o pacote importado. Por exemplo, na figura 6.14 o pacote Elaborando Projetos
importa o pacote Definindo Projetos para Obra. Quando um pacote importado por
outro, todas as definies do pacote importado podem ser vistas pelo importador. Um
pacote importador tambm pode estender o pacote importado.
O diagrama de pacotes obtido no processo de refinamento do modelo de negcios.
Catalysis [DSO 99] sugere alguns mtodos de particionamento do sistema e dos
pacotes, dentre os quais destacamos:
diviso vertical - visa refletir o fato de que usurios diferentes tm diferentes
vises de um sistema ou negcio. Essas vises podem representar diferentes
categorias de usurios;
diviso horizontal visa organizar os pacotes em camadas horizontais desde
as aes de mais alto nvel at as de infra-estrutura. A diviso deve buscar a
otimizao da importao de pacotes;

 domnios diferentes visa separar domnios de funcionalidades diferentes tais

como interface com o usurio, persistncia ou domnios do prprio problema.
No caso do Gerenciador de Obras, realizamos uma diviso vertical do modelo de
negcios, analisando, principalmente, o diagrama de casos de uso, apresentado na figura
6.7. A diviso vertical destaca as vises das vrias categorias de usurio, conforme
mostra o diagrama de colaborao em alto nvel apresentado na figura 6.13.
Gerenciador de Construes Civis

Elaborando
Projetos
Arquiteto e Engenheiro
Eltrico

Definindo e
Alocando
Recursos

Engenheiro Civil

Agendando
Tarefas

Monitorando
Tarefas
Executando
Tarefas
Mestre de Obras

Construtores

Figura 6.13: Modelo de colaborao em Alto Nvel do Gerenciador de Obras.

As vises so construdas com base nas aes principais das vrias categorias de
usurio. O engenheiro civil, o arquiteto e o engenheiro eltrico elaboram projetos. O
engenheiro civil define e aloca recursos para execuo das tarefas, agenda as tarefas e
monitora a sua execuo. Os Construtores representam o pedreiro, eletricista,
encanador, etc.
As grandes aes representadas no modelo de colaborao induzem ao particionamento
do sistema em fatias verticais. Assim, pode-se modelar ou agrupar os tipos e aes a
partir de diferentes perspectivas. Os vrios pacotes obtidos so estruturados em fatias
verticais mostrando a importao de pacotes ao longo das camadas horizontais. As
camadas horizontais vo desde os servios de mais alto nvel at os servios de infraestrutura. comum a identificao de um pacote central contendo as definies bsicas
que so importadas pelos demais pacotes.
Uma diviso vertical mais refinada do Gerenciador de Obras mostrada na figura 6.14,
que toma como base o modelo de colaborao obtido anteriormente. A elaborao
desses diagramas oferece uma outra abstrao do sistema forando o projetista a refletir
sobre as perspectivas externas de diferentes categorias de usurios (ou subsistemas) e
sobre como melhor agrupar os servios do sistema para atender essas perspectivas.

Elaborando Projetos

Definindo e Alocando Recursos

Definio dos requisitos

e viabilidade de um obra

Definio e alocao de recursos

humanos e materiais para tarefas

Agendando Tarefas
Seleo e execuo
de tarefas

Executando Tarefas

Execuo de tarefas

Monitorando Tarefas
Acompanhamento da
execuo de tarefas

Definindo Tarefas

Definio das caractersticas das tarefas a serem executadas em uma obra

Definindo Projetos para Obra

Definio dos projetos bsicos para a construo de uma obra: projetos arquitetnico, estrutural, hidrulico e eltrico

Figura 6.14: Modelo de Camadas Verticais de Alto Nvel do Gerenciador de

Obras.
A figura 6.15 mostra o diagrama de camadas verticais agregando os tipos do modelo
esttico.
Apesar dos refinamentos serem realizados tendo em mente a decomposio do sistema
em componentes e a independncia entre especificao e implementao, o
particionamento adequado do sistema, na maioria das vezes, s surge medida que o
desenvolvimento evolui. As vezes chega-se implementao para em seguida
retroceder e obter um particionamento mais adequado.
Da mesma forma que separamos um sistema em partes, precisamos de regras para
efetuar a composio de partes, definidas no prprio projeto do sistema, ou importadas
de outros projetos. No Catalysis, a composio tratada no somente em nvel de
cdigo mas tambm em nveis mais altos tais como especificaes, pacotes e projetos.
A composio de pacotes, por exemplo, envolve a anlise dos tipos e aes importadas
de diferentes pacotes para verificar a compatibilidade e como se pode dar a juno
desses de modo a obter um resultado consistente. [DSO 99] apresenta algumas regras
de composio de modelos, porm esse problema complexo e demanda estudos mais
detalhados. O problema , de certa forma, similar ao problema de integrao de objetos
ou dados [SPA 94, GIM 97].

Agendando Tarefas

Elaborando Projetos

Cargo
Projeto

Executando Tarefas

Definindo e Alocando Recursos

arquiteto

Tarefa

Monitorando Tarefas

Tarefa

Viabilidade

Tarefa
engenheiro eltrico

Custo

Agenda

Pessoa
engenheiro civil
Pessoa

Necessidade_Cliente

Registro de Execuo

Cargo

Desempenho

mestre de obras
Tarefa
pedreiro

eletricista

Material

encanador

carpinteiro

Definindo Tarefa
Telhado Cermica

Terraplanagem

Alicerce

Paredes

Teto

Madeiramento

Telhado Fibra

Telhado

Tarefa

Definindo Projeto para Obra

Obra

Projeto

Arquitetnico

Estrutural

Hidrulico

Eltrico

Figura 6.15: Diagrama de Camadas Verticais do Gerenciador de Obras com Tipos

Reboco

6.7.2 Framework de Modelos

Um framework pode ser descrito como uma arquitetura de software semi-definida que
consiste de um conjunto de unidades individuais e de interconexes entre elas, de tal
forma a criar uma infra-estrutura de apoio pr- fabricada para o desenvo lvimento de
aplicaes de um ou mais domnios especficos [LEW 95].
Um framework orientado a objeto um conjunto de classes que so integradas e
interagem de uma maneira bem definida para fornecer um conjunto de servios que
fornea uma soluo total ou parcial para um problema[BAR 96], [BAR 97]. Portanto,
um framework mais do que uma hierarquia de classes, uma aplicao genrica que
possui estruturas estticas e dinmicas e que pode ser reutilizada por muitas outras
aplicaes. Utilizando a tecnologia de orientao a objetos, o desenvolvedor pode
especializar, instanciar, ou reutilizar as classes abstratas do framework, respeitando os
relacionamentos j definidos.
O mtodo Catalysis [DSO 99] considera que descries de mais alto nvel como
especificaes e projetos tambm podem ser particionadas e reutilizadas, ao contrrio da
convencional reutilizao de cdigo. Esses elementos reutilizveis de mais alto nvel
so chamados de frameworks de modelos11 . Frameworks so representados como
pacotes genricos 12 que podem ser importados substituindo-se os elementos genricos
pelos elementos especficos da aplicao, quando apropriado.
Um framework de modelo possui a estrutura de um pacote genrico, que contm alguns
tipos e as suas caractersticas. Esses tipos e caractersticas podem ser definidos por meio
de placeholders, que consistem em definies genricas a serem substitudas pelas
definies especializadas da aplicao. Quando um framework de modelo aplicado, os
placeholders so substitudos para que se possa obter uma verso do framework
especializada para a aplicao objetivo.
No diagrama de pacotes do Gerenciador de Obras, o pacote Agendando Tarefas contm
um conjunto de tipos, relacionamentos e comportamentos a partir do qual deduz-se que
podemos reutilizar o framework de agenda de tarefas Tanaka[TAN 99] o qual foi
tambm desenvolvido seguindo o mtodo Catalysis.
O framework de agenda de tarefas, apresentado na figura 6.16, foi obtido por meio de
uma anlise comparativa entre gerenciadores de sistemas de workflow e gerenciadores
de processo de software, tomando como base um padro de gerenciadores de processo
desenvolvido anteriormente[GIM 99]. No contexto destes sistemas, o diagrama de
pacotes para o gerenciador de processos de software foi desenvolvido identificado-se
tambm o pacote Agendando Tarefas. As anlises realizadas mostraram o potencial de
reutilizao desse pacote, assim ele foi especificado e projetado, seguindo os conceitos
de framework de modelos, para que pudesse ser reutilizado em outros sistemas como
estamos fazendo para o Gerenciador de Obras.
11

Framework de Modelo consiste na traduo, utilizada neste trabalho, para o termo Model Framework
apresentado pelo mtodo Catalysis.
12
Esse pacote genrico chamado no Catalysis de Framework ou Template Package.

PKG_AG_TAREFAS

FrSenha

Gerente de
Projeto

<FrCargo>

Engenheiro de
Software

-Car_Nome : String
+Valida()

+Car_Remove()
+Car_Cria()
+Car_Altera()

Utiliza

Visualizar agenda
individual

0..n
0..n

Possui

<FrProjeto>

<FrIntAgenda>
<FrAtor>

Agendar tarefas

Visualizar todas as
tarefas agendadas

-TFAtor : String
-TFCargo : String
-TFPai : String
-TFTarefa : String
-TFProjeto : String
-TFData_Ini : String
-TFAndamento : String
-TFData_Ter : String
-TFStatus : Slider
+Aplicar()
+Cancelar()
+Remover()
+Adiar()
+Agendar()
+Ver_Alteracoes()
+Visualizar()
+Status()
+Atualiza_Pai()
+Desabilita()
+Inicia()
+Restaura()
+Sair()

-Ator_Nome : String
-Ator_Login : String
-Ator_Senha : String
+Ator_Remove()
+Ator_Cria()
+Ator_Altera()

1..n

Possui

-Pro_Nome : String
+Pro_Remove()
0..n
+Pro_Cria()
+Pro_Altera()
1..n

1..n

Possui

1
Possui
<FrAgenda>
-Ag_Status : Int
-Ag_Data_Inicio : String
1..n -Ag_Data_Termino : String
-Ag_Andamento : Int
-/Ag_Duracao : Int
+Get_ID_Ator()
+Get_ID_Processo()
+Get_ID_Cargo()
+Get_ID_Tarefa()

0..n

1..n

<FrTarefa>
-Tar_Nome : String
+Tar_Remove()
+Tar_Cria()
+Tar_Altera()

Figura 6.16: Diagrama de pacotes do framework de modelo da agenda de tarefas.

Em um PCDB existe sempre o objetivo de que, durante o desenvolvimento de
aplicaes sejam identificados os componentes que podem ser generalizados, criandose, eventualmente, uma biblioteca de componentes que podem ser especializados e
conectados em outras aplicaes. O framework de agenda foi concebido segundo este
ponto de vista e reutilizado no Gerenciador de Obras. A figura 6.17 mostra a aplicao
do framework de agenda de tarefas ao Gerenciador de Obras.
Os pacotes se conectam com as aplicaes dependendo da abordagem de
implementao utilizada. Em uma abordagem orientada a objetos por exemplo a
conexo pode ser obtida tomando-se os placeholders como classes abstratas que podem
ser especializadas em classes concretas da aplicao

6.7.3 Padres de Projeto

Os padres permitem que a experincia de desenvolvedores de software seja
documentada e reutilizada, registrando-se solues de projeto para um determinado
problema ou contexto particular [GAM 95]. Padres podem ser vistos como uma

experincia reutilizvel pois eles catalogam problemas recorrentes e comuns, dentro de

um contexto, que os projetistas e analistas tm enfrentado e encontrado uma soluo,
conhecida como bem sucedida [BAR 99b].
Vrios autores propem diferentes formas de se descrever um padro [ALE 77],[GAM
95], e [BUS 96]. Como abordado em [BUS 96] e [SHA 96], padres podem ser
aplicados na descrio de arquiteturas de software. Segundo [BUS 96], os padres
podem ser classificados em: (i) padres arquiteturais ou arquitetnicos (architectural
patterns), que mostram as abstraes e interaes dos elementos essenciais de uma
arquitetura; (ii) padres de projeto, que descrevem de forma mais refinada os
subsistemas, componentes e seus relacionamentos; e (iii) padres em nvel de idioma,
que descrevem a formulao de solues em nvel de implementao.
importante que frameworks, como o de agenda de tarefa, apresentado na seo
anterior, sejam documentados por meio de um padro, pois uma das grandes
dificuldades de reutilizao de framework a falta de conhecimento preciso sobre o
problema tratado, a soluo proposta, as funcionalidades, a estrutura, o contexto e usos
conhecidos do framework. [TAN 99] contm o padro que documenta o framework de
agenda de tarefas.

Cargo

Obra

FrCargo

FrProjeto
PKG_AG_TAREFA

refa
FrTa
Tarefa

FrIntAgenda

AgendaConsCivil

Agenda

FrAgenda

FrAtor
Pessoa

Figura 6.17: Aplicao do framework de agenda de tarefas ao Gerenciador de

Obras.

6.8 Projeto Interno dos Componentes

Neste estgio os componentes individuais da aplicao so refinados at o nvel de
interfaces, classes ou componentes pr-existentes em uma linguagem de programao.
Para tal, a implementao deve satisfazer os requisitos funcionais e no funcionais
definidos na especificao do sistema, assim como seguir a arquitetura definida.

Um componente, neste nvel, um pacote de implementao de software que:

a) pode ser desenvolvido e entregue independentemente;
b) tem interfaces explcitas e bem especificadas para os servios que oferece
outros componentes ou produtos de software que utilizem o componente devem
faz-lo apenas a partir do conhecimento da especificao dessas interfaces, no
fazendo, assim, suposio alguma sobre a implementao do componente;
c) tem interfaces bem especificadas para os servios que espera de outros
componentes;
d) interage com outros componentes ou produtos de software apenas atravs de
suas interfaces a unio com outros componentes pode requerer algumas
adaptaes;
e) garante o encapsulamento de dados e de processo.

6.8.1 Composio de Componentes

Os principais aspectos envolvidos na composio de componentes incluem: standards
de colaboraes, kit de componentes e componentes heterogneos., conforme descritos
a seguir. Esses aspectos no so exclusivos, pode-se construir um componente baseado
em um kit de componentes, por exemplo, para em seguida usar um standard de
colaborao (ex. CORBA ou COM) para disponibiliz- lo de acordo com aquele
standard.
Standards de Colaborao
Para se construir sistemas a partir de componentes necessrio a existncia de uma
standardizao com a qual os desenvolvedores devem estar de acordo, assim como
existem standards para os componentes de hardware. Esses standards definem como os
componentes podem interoperar. Os standards podem ser classificados como
segue[DSO 99]:
horizontais: incluem mecanismos e servios tais como: request broker,
segurana, transaes, diretrios, repositrios de interface. CORBA e COM
[ORF 96, PRI 99] um exemplo de standard que oferece esses mecanismos;
verticais : incluem uma terminologia comum em relao aos conceitos
relacionados ao domnio para o qual o componente se aplica. Por exemplo, um
engenheiro civil deve ter o mesmo rtulo e significado para que componentes
que usam esses conceitos faam sentido juntos;
inter-componentes: definem os tipos de mecanismos de interao entre os
componentes. Por exemplo: conectores que apoiam operaes de call and return
sncrono ou assncrono e conectores com propagao implcita de eventos.
Kit de Componentes
Um kit de componentes uma coleo de componentes projetados para trabalharem em
conjunto. Um kit de componentes construdo a partir de um conjunto de princpios que
forma o tipo de arquitetura de software do kit.
Catalysis [DSO 99] aborda uma arquitetura de componentes que contm o seguinte
conjunto de princpios:

componentes: qualquer elemento que realiza uma tarefa bem definida, como
definido anteriormente;
portas: as interfaces expostas que definem os plugs (tomadas) e soquetes dos
componentes, locais por meio dos quais os componentes oferecem acesso aos
seus servios e a partir dos quais eles acessam os servios de outros. Um plug
pode ser conectado a qualquer soquete do tipo compatvel usando um conector
adequado;
conectores: as conexes entre portas que permitem a montagem de uma
coleo de componentes para construir um produto de software ou um
componente maior. Conectores conectam portas.
Componentes Heterogneos
Componentes heterogneos so componentes que no foram projetados para trabalhar
em conjunto e que, no, foram necessariamente especificados para trabalhar em um
outro software que no aquele para o qual ele empregado. Esse tipo de componente
pode ser utilizado em um sistema que no segue um tipo de arquitetura como definido
no item anterior pois ele no tem portas e conectores standardizados.
O projeto de um sistema com componentes heterogneos mais complexo devido s
dificuldades inerentes insero de um componente em uma arquitetura para o qual ele
no foi projetado. No exemplo apresentado na figura 6.3, a rota montar pode ser seguida
no projeto desse tipo de sistema, fazendo assim uma definio preliminar de requisitos
para depois encontrar os componentes heterogneos adequados para atender, o mais
prximo possvel, os requisitos definidos.
O ponto chave neste tipo de composio encontrar uma arquitetura ad hoc que permita
a interoperao dos componentes. Componentes adicionais (glue components) podem
ser incorporados para executar funes complementares ou melhorar os servios
oferecidos pelos componentes conectados.

6.8.2 Exemplos
A figura 6.18 [DSO 99, WIL 99] ilustra a composio de um kit componentes por meio
de um sistema de componentes que simula uma coleo de peas de hardware.
O motor tem duas portas incia e para que recebem informaes dos botes aos quais
esto conectadas. Alm disso, tem uma porta de sada velocidade que est conectada a
um medidor. A conexo entre os botes e o motor indica um tipo de conector em que a
ocorrncia gerada por um compone nte ativa um mtodo de outro componente enquanto
a conexo entre motor e medidor indica um tipo de conector por meio do qual um par de
valores mantido continuamente em sincronizao.

apertado
Boto

inicia

velocidade

valor

Motor

Medidor

para

Boto

apertado

Figura 6.18: Exemplo de um kit de componentes[DSO 99].

importante observar que os componentes da figura 6.18 podem ser utilizados para
outros propsitos. Por exemplo os botes podem ser utilizados para representaes de
outras aes liga e desliga enquanto medidor pode ser utilizado para medir valores de
um sensor de temperatura.
A construo de um sistema pode tambm ser vista a partir de componentes maiores
como mostra a 6.19 por meio de um sistema de compras. Neste exemplo as conexes
so realizadas com conectores do tipo transferncias de workflow por meio do qual
informaes se movem de um emissor para um receptor. Outros tipos de conectores
podem ser considerados, alm deste e daqueles mencionados no exemplo anterior, como
conectores que alimentam streams. Neste tipo de conector produtores inserem
continuamente valores ou objetos em um stream onde eles permanecem at serem
consumidos.

Departamentos

Pedidos de compras

Crdito disponvel

Materiais Comprados
Oramentos
solicitados

Finanas

Compras

Oramento escolhido

Fornecedores

Faturas

Pagamentos
Vaor gasto

Figura 6.19: Exemplo da composio de um sistema de compras.

A agenda apresentada na seo anterior pode ser vista como um componente, conforme
ilustra a figura 6.20. Nesta viso uma aplicao qualquer envia solicitaes de
agendamento que so controladas pela agenda. A agenda utiliza os servios de um
gerenciador de banco de dados para armazenar as informaes do projeto. Alm disso, a
agenda pode prover interfaces adicionais para plug-ins que adicionam ou adaptam o
comportamento das interfaces primrias.
Uma das vantagens do desenvolvimento baseado em componentes est na possibilidade
de reutilizao em vrios nveis, desde a especificao at ao cdigo. No entanto, para
tornar um componente reutilizvel necessrio que o projeto dele seja desenvolvido de
forma a torn- lo ao mesmo tempo genrico e adaptvel. A generalizao necessria
para capturar aspectos comuns de diferentes contextos, enquanto a possibilidade de
adaptao importante para permitir a especializao necessria do componente,
Ambas as propriedades aumentam assim o potencial de reutilizao do componente.
A reutilizao pode-se dar tanto em nvel de componentes como em nvel de
frameworks. Na reutilizao de componentes sabe-se unicamente a especificao das
interfaces, desconhecendo-se o que quer que seja de sua implementao. No entanto, a
reutilizao em nvel de framework requer adaptaes e instanciaes. A vantagem
que este tipo de framework pode ser adaptado a vrias aplicaes ainda em nvel de
projeto.
A possibilidade de reutilizao de frameworks reconhecida a partir do estgio de
projeto da arquitetura do software. Assim, como mencionado na seo 4, deve-se iniciar
com a modelagem do domnio e especificao de requisitos, e reconhecida a
possibilidade de reutilizao, deve-se retroceder para realizar possveis ajustes nos
requisitos decorrentes da reutilizao.

plug-ins
Solicitaes de
Agendamento

Aplicao

Agenda de
Tarefas
Solicitaes de
armazenamento e
recuperao de dados

Servidor de
Banco de
Dados

Figura 6.20: Agenda utilizada como um compone nte.

A seo anterior mostrou a reutilizao do framework de modelos da agenda de tarefas.

Este framework tambm, pode ser utilizado para produzir um componente agenda de
tarefas. Para tal necessrio fazer o mapeamento dos tipos definidos no framework para
as classes na linguagem de programao a ser utilizada assim como definir as interfaces
por meio das quais a agenda oferecer seus servios e obter servios de outros
pa

6.9 Comentrios finais

A reutilizao de componentes de, certa forma, um princpio praticado, ainda que de
forma no rigorosa, desde os primrdios da engenharia de software[BAR 99b]. O
interesse por ampliar, cada vez mais, os benefcios da reutilizao induziu a busca de
novos conceitos, mtodos e notaes. Este captulo abordou esses conceitos por meio de
um exemplo desenvolvido com base no mtodo Catalysis[DSO 99, WIL 99] cuja
linguagem de modelagem utilizada a UML [RUM 99]. Em particular, foram
destacados os conceitos de componentes, arquitetura de software, frameworks e padres
de software, os quais so inerentes a um PCBD.
Catalysis um mtodo que incorpora em seu processo de desenvolvimento, conforme
discutido na seo 6.4, conceitos, procedimentos e notaes que facilitam a
identificao e generalizao de componentes (developing for reuse) e aproveitamento
de componentes existentes (developing with reuse). O processo discutido na seo 6.4
enfatiza os estgios tcnicos de especificao de requisitos, especificao do sistema,
projeto da arquitetura e projeto interno dos componentes. Ao longo dessas fases a
reutilizao de componentes aplicada de acordo com a rota de desenvolvimento que
melhor convier aplicao e ao projetista. importante destacar a forte nfase do
Catalysis na definio dos modelos de domnio e especificao de requisitos e na
separao das especificaes de suas possveis implementaes, mesmo nos projetos em
que j se sabe antecipadamente que a construo do sistema reutilizar componentes
pr-existentes. Como destacamos ao longo deste captulo ciclos de vida incremental,
iteraes e feedbacks, tm uma grande nfase em um PCBD.
A reutilizao de componentes , as vezes, contrastada como a reutilizao por meio de
orientao a objetos. Componentes e objetos, conforme abordado na seo 6.2, so
conceitos diferenciados. Catalysis [DSO 99] considera a tecnologia de orientao a
objetos como um meio que facilita a reutilizao de componentes.
Os benefcios da reutilizao de componentes so efetivamente a reduo dos custos e
tempo de produo de software, e o aumento da confiabilidade dos produtos de
software, uma vez que esses produtos podem ser construdos a partir de partes bem
especificadas e testadas. A obteno desses benefcios depende ainda do tratamento de
questes pendentes como: a formao de polticas gerenciais e organizacionais que
incentivem e permitam a reutilizao de componentes; a disseminao de arquiteturas
de software que facilitem o mercado e o intercmbio de componentes; tcnicas que
facilitem a identificao dos componentes adequados s necessidades das aplicaes
(ex. biblioteca de componentes e boa documentao); tcnicas que evidenciem a
confiabilidade dos componentes; e educao e treinamento do engenheiros de software
para que esses se conscientizem e incorporem o princpio de reutilizao no processo de
produo de software.
Alm dessas questes mais tcnicas importante abordar as questes de mercado
relevantes para disponibilizao de COTS, como: as formas de empacotamento (ex.
mdia, custo, propaganda, etc.) e a certificao da qualidade de COTS.

6.10 Bibliografia
[ALE 77] ALEXANDER C. et al., A Pattern Language, Oxford University Press,
1977.
[BAR 96] BARROCA, L., HENRIQUES, P. R., A framework and Patterns for the
Specification of Reactive Systems, in the Proceedings of the EuroPLoP96, July
1996.
[BAR 97] BARROCA, L., HENRIQUES, P. R., Frameworks for the Application of
Development Methods . Dept of Computing, The Open University, Inglaterra, 1997.
[BAR 99a] BARROCA, L., HALL, J., HALL, P., Ed., Software Architectures
Advances and Applications , Springer-Verlag, Londres, 1999.
[BAR 99b] BARROCA, L., HALL, J., HALL, P., An Introduction and History of
Software Architectures, Components, and Reuse, in [BAR 99a].
[BAS 98] BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in
Practice, Addison-Wesley, 1998.
[BOO 99] BOOCH, G., RUMBAUGH, J., JACOBSON, I., The Unified Modeling
Language Users Guide , Addison-Wesley Publishing Company, 1999.
[BUS 96] BUSCHMANN, F., et al., Pattern-Oriented Software Architecture - A
System of Patterns , John Wiley & Sons, 1996.
[CAR 97] CARNEY, D., Assembling Large Systems from COTS Components:
Opportunities, Cautions, and Complexities, SEI Monographs on the Use of
Commercial Software in Government Systems, http://www.sei.cmu.edu/cbs/papers,
ltimo acesso: 16/11/1999.
[DSO 99] DSOUZA, D., WILLS, A., Objects, Components and Frameworks with
UML The Catalysis Approach, Addison-Wesley Publishing Company, 1999.
[GAM 95] GAMMA, E., HELM, R., JOHNSON, R, VLISSIDES, J., Design Patterns:
Elements of Reusable Object-Oriented Software , Addison-Wesley, 1995.
[GAR 95] GARLAN, D., PERRY, D. E., Introduction to Special Issue on Software
Architecture , IEEE Transaction on Software Engineering, April, 1995.
[GIM 94] GIMENES, I. M. S. Uma Introduo ao Processo de Engenharia de Software.
XII Jornada de Atualizao em Informtica. XIV Congresso de Sociedade
Brasileira de Computao., Julho, 1994.
[GIM 97] GIMENES, I. M. S., CIFERRI, C. D. A., NANNI, E. L., SABIO, S. B., An
Object Oriented Method for Designing Sharable Data Schemas in Software
Engineering Environments, Revista UNIMAR, Cincias Exatas e da Terra ,19 (4),
ISSN: 0100-9354, pags. 937-953, 1997.
[GIM 99] GIMENES, I. M. S. WEIS, G. M. HUZITA, E. H. M., Um Padro para
Definio de um Gerenciador de Processos de Software, in Proceedings of the II
Workshop Ibero Americano de Engenharia de Requisitos e Ambientes de Software,
San Jos, Costa Rica, Maro, 1999.

[ITE 99] ITEC ITAUTEC CENTRO EDUCACIONAL, As/400 Java Programming

Workshop Lab Exercises, 1999.
[JAC 99] JACOBSON, I., BOOCH, G., RUMBAUGH, J., The Unified Software
Development Process, Addison-Wesley Publishing Company, 1999.
[LEW 95] LEWIS, T., et al., Object-Oriented Application Frameworks, Manning
publications Co, 1995.
[ORF 96] ORFFALI, H. E., The Essencial Distributed Object Survival Guide , John
Wiley & Sons, 1996.
[PRI 99] PRITCHARD, J., COM and CORBA Side by Side, Architectures,
Strategies, and Implementations , Addison Wesley Longman, Inc, 1999.
[RUM 99] RUMBAUGH, J., JACOBSON, I., BOOCH, G., The Unified Language
Reference Manual, Addison-Wesley Publishing Company, 1999.
[SCH 98] SCHNEIDER, G. WINTERS, J. P., Applying Use Cases a Practical Guide .
Ed. Addison Wesley. USA 1998.
[SHA 96] SHAW, M., GARLAN, D., Software Architecture: Perspectives on an
Emerging Discipline , Editora Prentice-Hall, Inc, 1996.
[SPA 94] SPACCAPIETRA, S., PARENT, C., View Integration: A Step Forward in
Solving Structural Conflicts, IEEE Transactions on Knowledge and Data
Engineering, 6(2):258-274, 1994.
[TAN 99] TANAKA, S. A., Um Framework de Agenda de Tarefas para
Gerenciadores de Processos , Dissertao de Mestrado (em fase de concluso),
PPGCC, Instituto de Informtica, UFRGS, 2000.
[WAR 99] WARMER, J., KLEPPE, A., The Object Constrint Language Precise
Modeling with UML, Addison Wesley Longman, Inc, 1999.
[WIL 99] WILLS, A. C., Designing Component Kits and Architectures with Catalysis,
in [BAR 99a]