Reutilização de Componentes

Caroline Batista Spencer Holanda
Clarissa Angélica de Almeida de Souza

Walcélio L. Melo
Agradecimentos
Gostaríamos de agradecer a todos aqueles que nos apoiaram, de alguma

forma, para a realização deste trabalho. Em especial:
A Deus pelo Seu amor, dando-nos a oportunidade de conhecimento, a benção

da inteligência, força para enfrentar as dificuldades do caminho e superar
nossas próprias limitações.
Ao professor Fernando Albuquerque pelo apoio técnico e disponibilidade
prestados sempre que nos foram necessários.
Aos nossos amigos Ari, Marília, Élcio, Roberto Carlos e Alexandre Viana
pelos auxílios e conselhos indispensáveis nos momentos de dificuldade.
Por fim, e não menos importantes, agradecemos às nossas famílias,
namorados e amigos pela compreensão nos momentos em que estivemos
ausentes.
2
Resumo
ProReuso: Um Repositório de Componentes para Web
Alcançar o máximo de qualidade, produtividade e eficiência no

desenvolvimento de sistemas é um dos objetivos fundamentais da
Engenharia de Software. O reuso de software de forma sistematizada, ou
seja, direcionada para as metas do negócio, através de uma estratégia técnica
e gerencial, torna possível a realização destes objetivos. Nesse contexto, um
repositório, atuando como um mecanismo de armazenamento e recuperação,
contribui para se alcançar as metas propostas. Objetivando o incentivo da
prática do reuso de software nos processos de desenvolvimento e visando
demostrar a sua viabilidade, é apresentado neste projeto um modelo de
repositório para web, denominado ProReuso, onde é possível o
armazenamento, a análise, a classificação e a recuperação contextualizada
de componentes e documentos relativos ao processo de construção de
softwares.
3
Sumário
Agradecimentos......................................................................................................................... 2
Resumo ...................................................................................................................................... 3
Sumário...................................................................................................................................... 4
Capítulo 1 - Introdução............................................................................................................ 8
1.1 - MOTIVAÇÃO ................................................................................................................................................8
1.2– OBJETIVOS ...........................................................................................ERROR! BOOKMARK NOT DEFINED.
1.3 – DESCRIÇÃO ...............................................................................................................................................10
1.4 – METODOLOGIA UTILIZADA .................................................................ERROR! BOOKMARK NOT DEFINED.
1.5 – ORGANIZAÇÃO DO TRABALHO ..................................................................................................................12
Capítulo 2 - Reuso de Software ............................................................................................. 14
2.1 – INTRODUÇÃO ............................................................................................................................................14
2.2 - O QUE SE PODE REUSAR ...........................................................................................................................17
2.3- OPORTUNIDADES DE REUSO .......................................................................................................................20
2.4 - CLASSIFICAÇÃO DOS ATIVOS .....................................................................................................................22
2.5 - CARACTERÍSTICAS DE UM ATIVO REUSÁVEL .............................................................................................24
2.6 – FORMAS DE REUSO ...................................................................................................................................26
2.7 – IMPORTÂNCIA DO REUSO ..........................................................................................................................28
2.8 – SUCESSO E FALHAS NO REUSO..................................................................................................................30
2.9 – CONSIDERAÇÕES FINAIS ...........................................................................................................................32
Capítulo 03 - Tecnologias de Reuso ...................................................................................... 34
3.1 – TÉCNICAS ORIENTADAS A OBJETOS ..........................................................................................................34
3.2 – PADRÕES DE PROJETO ..............................................................................................................................36
3.3 - FRAMEWORKS DE APLICAÇÃO ....................................................................................................................39
3.3.1- Arquitetura CORBA...........................................................................................................................41
3.4 - DESENVOLVIMENTO BASEADO EM COMPONENTES ...............................................................................44
3.4.1 - Active X.............................................................................................................................................49
3.4.2 - JavaBeans.........................................................................................................................................51
3.4.3 - Enterprise JavaBeans (EJB) .............................................................................................................53
3.5 – VANTAGENS E DESVANTAGENS ................................................................................................................55
Capítulo 4 - Repositório: Reutilização de Componentes..................................................... 58
4.1 – INTRODUÇÃO ............................................................................................................................................58
4.2- CARACTERÍSTICAS DE UM REPOSITÓRIO .....................................................................................................61
4.3 – GERENCIAMENTO .....................................................................................................................................65
4.4 – MERCADO DE REPOSITÓRIOS ....................................................................................................................66
4.4.1- Repositórios na Internet.................................................................................................................66
4
4.4.2- Outros Repositórios .......................................................................................................................67
Capítulo 5 - Fundamentos da Tecnologia XML .................................................................. 70
5.1 – INTRODUÇÃO A XML ...............................................................................................................................70
5.2- DOCUMENTO XML ....................................................................................................................................71
5.2.1- Definição do Tipo de Documento ......................................................................................................75
5.3 – IMPORTÂNCIA DO XML ............................................................................................................................77
Capítulo 6 - ProReuso: Um Repositório de Componentes.................................................. 80
6.1 – MOTIVAÇÃO .............................................................................................................................................80
6.2 – DESCRIÇÃO E FUNCIONALIDADES .............................................................................................................81
6.3 - ARQUITETURA ...........................................................................................................................................83
6.4 – PROCESSOS ...............................................................................................................................................84
Capítulo 7 - Conclusões........................................................................................................ 100
Apêndice A - Modelagem do Sistema.................................................................................. 102
DEFINIÇÃO DE REQUISITOS ..............................................................................................................................102
MODELO DE CASOS DE USO .............................................................................................................................118
TELAS DO PROREUSO ......................................................................................................................................121
DIAGRAMA HIERÁRQUICO DE FUNÇÕES...........................................................................................................136
MODELO ENTIDADE-RELACIONAMENTO (MER)..............................................................................................138
DICIONÁRIO DE DADOS ....................................................................................................................................138
DEFINIÇÃO DE TIPO DE DOCUMENTO XML (DTD)… … … … … … … … … … … … … … … … … … … … … … ...139
Glossário ................................................................................................................................ 144
Referências Bibliográficas ................................................................................................... 146
5
Lista de Figuras
FIGURA 2.1- MODELO DE ATIVO.............................................................................................................................19
FIGURA 3.1 - ARQUITETURA CORBA.....................................................................................................................43
FIGURA 3.2 - ARQUITETURA DA TECNOLOGIA EJB.................................................................................................54
FIGURA 4.1 - UM MODELO DE REPOSITÓRIO ...........................................................................................................60
FIGURA 5.1 – EXEMPLO DE DOCUMENTO XML .....................................................................................................72
FIGURA 5.2 – EXEMPLO DE DECLARAÇÃO DE DTD INTERNA.................................................................................76
FIGURA 6.1 - ARQUITETURA DO PROREUSO ...........................................................................................................83
FIGURA 6.2 – PROCESSO DE APROVAÇÃO DE COMPONENTES .................................................................................91
FIGURA 6.3 – PROCESSO NOTIFICA SUPERIOR ........................................................................................................93
FIGURA 6.4 – PROCESSO SOLICITA COMENTÁRIO ...................................................................................................94
FIGURA 6.5 – PROCESSO VERIFICA QUALIDADE .....................................................................................................96
FIGURA 6.6 – PROCESSO VERIFICA DOCUMENTO ...................................................................................................97
FIGURA 6.7 - PROCESSO NOTIFICA APROVAÇÃO COM CORREÇÃO ..........................................................................98
FIGURA A.1 – TELA DE ABERTURA ......................................................................................................................121
FIGURA A.2 – TELA DE OPÇÕES ...........................................................................................................................122
FIGURA A.3 – FORMULÁRIO DE SUBMISSÃO DE COMPONENTES ...........................................................................123
FIGURA A.4 – FORMULÁRIO DE SUBMISSÃO DE DOCUMENTOS ............................................................................124
FIGURA A.5 – FORMULÁRIO DE ENTRADA DE CARACTERÍSTICAS DO ATIVO ........................................................125
FIGURA A.6 – TELA DE PROCESSOS......................................................................................................................126
FIGURA A.7 – TELA DE ACOMPANHAMENTO ........................................................................................................127
FIGURA A.8 – PASTA DO COMPONENTE................................................................................................................128
FIGURA A.9 – FORMULÁRIO DE PESQUISA ............................................................................................................129
FIGURA A.10 – TELA DE RESULTADO DE PESQUISA .............................................................................................130
FIGURA A.11 – TELA DE DETALHAMENTO ...........................................................................................................131
FIGURA A.12 – FORMULÁRIO DE INSERÇÃO DE COMENTÁRIOS ............................................................................132
FIGURA A.13 – FORMULÁRIO DE RE-SUBMISSÃO DE ATIVO .................................................................................133
FIGURA A.14 – FORMULÁRIO DE INSERÇÃO DE DOCUMENTO DE CORREÇÃO .......................................................134
FIGURA A.15 – TELA DO CATÁLOGO ....................................................................................................................135
6
Lista de Tabelas
TABELA 2.1 - EXEMPLOS DE ATIVOS VERTICAIS ....................................................................................................22

TABELA 2.2 - EXEMPLOS ATIVOS HORIZONTAIS TÉCNICOS ....................................................................................23
TABELA 2.3 - EXEMPLOS DE ATIVOS HORIZONTAIS GENÉRICOS ............................................................................23
TABELA 2.4 - ESTRATÉGIA DE IMPLEMENTAÇÃO DE UM ATIVO DE ACORDO COM SUA FORMA ..............................27
TABELA 3.1 - BENEFÍCIOS DO USO DE COMPONENTES ............................................................................................48
TABELA 3.2 - COMPARAÇÃO ENTRE A TÉCNICAS ...................................................................................................56
TABELA A.1 - CASO DE USO SUBMETER ATIVO ...................................................................................................104
TABELA A.2 - CASO DE USO ACOMPANHAR PROCESSO .......................................................................................106
TABELA A.3 - CASO DE USO RE-SUBMETER ATIVO ..............................................................................................107
TABELA A.4 - CASO DE USO INSERIR INFORMAÇÕES PARA PESQUISA ..................................................................108
TABELA A.5 - CASO DE USO VALIDAR ENTRADA DE DADOS ...............................................................................109
TABELA A.6 - CASO DE USO AVALIAR ATIVO ......................................................................................................110
TABELA A.7 - CASO DE USO ANALISAR QUALIDADE DO ATIVO ...........................................................................111
TABELA A.8 - CASO DE USO INSERIR CORREÇÕES ...............................................................................................112
TABELA A.9 -CASO DE USO PESQUISAR ATIVO ....................................................................................................113
TABELA A.10 - CASO DE USO CONSULTAR CATÁLOGO ........................................................................................114
TABELA A.11 - CASO DE USO LISTAR COMENTÁRIOS ..........................................................................................115
TABELA A.12 - CASO DE USO INSERIR COMENTÁRIOS .........................................................................................116
TABELA A.13 - CASO DE USO RECUPERAR ATIVO ...............................................................................................117
7
Capítulo 1
Introdução
Este capítulo apresenta, inicialmente, os fatores que motivaram a realização deste

trabalho. Em seguida, é descrita brevemente a composição deste documento e apresentados
os objetivos gerais e específicos. Finalmente, apresenta-se a metodologia utilizada e como o
trabalho foi organizado para se alcançar os objetivos definidos.
1.1 - Motivação
Por muitos anos, tem-se vivido um verdadeiro caos no desenvolvimento de projetos de

sistemas de software. É frequente encontrar empresas de software desenvolvendo e
entregando aos seus clientes softwares imensos, complexos, cheios de defeitos, mal-
estruturados, consumidores de recursos de máquina e, principalmente, que não atendem, por
completo, às necessidades reais dos usuários. Há trinta anos, nomeou-se esse caos de crise do
software.
Entretanto, recentemente, empresas começaram a tomar consciência da necessidade
emergente de sair do caos e entrar numa era quando o produto final atenderá às exigências de
mercado, cada dia mais competitivo, e o lucro ainda existirá. Sonhando com essa nova era e
desejando torná-la realidade, as empresas estão buscando, desesperadamente, formas de se
atingir vários objetivos que são de difícil alcance e, muitas vezes, conflitantes, tais como:
- aumento e alcance máximo de qualidade;
- redução de prazos de entrega;
- aumento de produtividade;
- redução de custos de desenvolvimento e manutenção;
- aumento de satisfação do cliente;
- redução de defeitos e de riscos;
- alavancagem de perícia técnica;
- aumento de integração entre seus produtos;
8
Em virtude disso, empresas têm investindo quantias significativas com soluções
unicamente tecnológicas, como introdução de tecnologias orientadas a objetos e uso de
ferramentas CASE. Porém, sem o cuidado necessário no que tange a uma estratégia gerencial
ou direcionamento necessários. A ausência de retorno desse tipo de investimento conduz,
muitas vezes, ao pensamento de que os objetivos acima citados são inatingíveis.
Todavia, o reuso sistemático de software, ou seja, direcionado para as metas do
negócio, através de uma estratégia técnica e gerencial, pode colaborar de forma significativa a
realização destes objetivos.[FAVARO et al., 1998] e [BASILI et al., 1996]
O reuso propõe o desenvolvimento de sistemas a partir de produtos de software
preexistentes, de modo que semelhanças entre requisitos e arquiteturas de diversos sistemas
possam ser melhor exploradas. A identificação dessas semelhanças pode resultar, entre outras
coisas, significativas reduções de custo e tempo, isto é, aumento de produtividade para as
empresas desenvolvedoras. Além disso, a cada uso do produto, sua eficiência e validade são
verificadas, garantindo, assim, maior qualidade e redução de erros nos produtos finais.
Um repositório de componentes, por sua vez, representa uma ferramenta em potencial
para a prática do reuso dentro das organizações. Quando os componentes nele armazenados
são bem organizados, divulgados e gerenciados, esse potencial torna-se realidade. Através de
um repositório sustentando as políticas de reuso dentro da empresa, tendo em vista os
benefícios dessa prática, consequentemente haverá aumento nos níveis de produtividade e
qualidade no processo de desenvolvimento da organização que o utiliza. Ou seja, reuso de
software é uma estratégica de negócio que deve ser sustentada, do ponto de visto tecnológico,
por um repositório de componentes corporativos.
O grupo de empresas inicialmente citadas como desejosas de melhoria da qualidade
de software e aumento da produtividade não fica restrito a grandes empresas internacionais.
Essas buscas têm sido amplamente explorados no Brasil, podendo-se destacar os programas
de exportação de software, como o Softex 2000. Esses programas visam mercados lucrativos,
mas para isso é necessário que a qualidade seja boa o suficiente para que produtos brasileiros
sejam atrativos e competitivos.
Por outro lado, empresas de diversos países, como NASA, HP, AT&T e Toshiba, nos
últimos anos têm apresentado casos de sucesso no uso de uma estratégia de reuso de software.
Apesar desses relatos estarem se tornando frequentes, eles ocorrem em sua grande maioria em
grandes empresas. Poucas são as pequenas e médias empresas que puderam perceber ou ter
acesso ao potencial da prática de reuso.
9
Assim, diante dessas considerações e levando-se em conta o mercado cada vez mais
competitivo no qual essas empresas estão inseridas, a implementação de um repositório de
componentes de software que viabilize o processo de reuso torna-se um fator diferencial que
permite a elas entrar para o grupo daquelas que têm acesso aos benefícios trazidos pelo reuso.
1.2 – Descrição
Este trabalho pode ser dividido logicamente em duas partes: uma parte trata da
fundamentação teórica do trabalho enquanto a segunda parte apresenta a proposta de um
repositório de componentes, sua arquitetura e principais características ligadas a sua
implementação.
A fundamentação teórica consiste em um estudo sobre a teoria do reuso de software,
destacando-se a importância de um repositório para a viabilização da prática do reuso. Com
essa pesquisa, adquire-se conhecimento do conceito de reuso de software, do que se pode
reusar, das implicações existentes no processo de reuso e principalmente, quais os benefícios
que essa prática pode promover a uma organização que inicia, seriamente, um processo
interno de reuso.
Define-se, nesse trabalho, que o reuso é uma prática sistemática de desenvolver novas
aplicações a partir de ativos de software pré-construídos que apresentam similaridades de
requisitos e/ou arquiteturas com o que está sendo desenvolvido [KRUEGER,1992]. Por se
tratar de uma prática sistemática requer disciplina e envolvimento de todos os membros da
empresa. Além disso, requer um processo de conscientização interno, para que todos
entendam o potencial de aumento de produtividade, qualidade dos produtos, economia em
relação aos custos e tempo de desenvolvimento que essa prática representa.
Na definição de reuso, é introduzida a palavra ativo de software e, portanto, vale
ressaltar que, no trabalho, discute-se a validade desse termo. Ativo de software foi definido
como aquilo que se pode reusar, que consiste em qualquer produto de software reusável, de
qualquer fase do desenvolvimento [EZRAN et al., 1999]. Essa escolha ocorreu pelo fato do
termo trazer com ele a idéia de valor e investimento para a empresa. Como essas idéias
correspondem ao conceito de software reusável que se deseja deixar claro nesse projeto, o
termo ativo está bem empregado.
Em relação ainda ao termo ativo, é importante esclarecer que na fase de
implementação do repositório esse termo foi substituído por componente de software. Essa
10
substituição não representa o esquecimento ou até contradição do que foi dito no parágrafo
anterior. Ela ocorreu pelo fato da empresa que motivou a construção desse repositório, Oracle
do Brasil, ter a intenção, inicial, de construir um repositório focado em componentes
executáveis e documentos relacionados a eles, tais como, manual de usuário, diagramas UML
[BOOCH et al., 1999], apresentações técnicas, etc., que atendesse principalmente a sua área
de desenvolvimento. Pode-se citar outro fator menos relevante, que consiste no fato do termo
componentes ser mais familiar para as pessoas, em geral, quando se refere a reuso de
software. Assim, apesar da substituição, ainda pode-se pensar em ativos de software sendo
armazenados no repositório.
Nesse trabalho, também é dissertado o valor agregado de um repositório de ativos ao
processo de reuso. Todavia, o sucesso na implantação de um repositório engloba decisões
importantes quanto às funcionalidades que serão implementadas. A pesquisa e a recuperação
de ativos são consideradas como as principais, apesar de não haver desconsideração de outras,
tais como, certificação de qualidade dos componentes, segurança, distribuição, etc..
Em virtude de entender a importância de um repositório, não se restringindo apenas ao
armazenamento de ativos, mas também de poder representar uma ferramenta de auxílio à
prática do reuso, foi implementado um repositório com características que possibilitam a
realização desse potencial.
O ProReuso é o resultado da parte de implementação do trabalho. Ele é um repositório
de componentes de software reusáveis, que consiste numa aplicação para web, disponibilizado
para funcionários da Oracle do Brasil, através da Intranet da empresa.
Com o ProReuso, o funcionário pode tanto alimentar o repositório com novos
componentes e/ou documentos relacionados a eles como localizar e recuperar outros já
disponibilizados. Para permitir a alimentação, o ProReuso disponibiliza as funcionalidades de
submissão de componentes e de documentos, que disponibiliza a entrada de características
dos mesmos para que possam ser armazenados dentro de uma organização definida.
A fim de implementar um processo de gerenciamento daquilo que está sendo
disponibilizado no repositório, é implementado no ProReuso um processo de aprovação de
componentes1, através de um workflow. Esse processo representa um crivo de gerentes de
projeto e especialistas de qualidade, pelo qual todo componente ou documento submetido ao
repositório deve passar. Tem-se, portanto, uma garantia de que aquilo que está disponibilizado
1
Nesse processo, o termo componente é usado também para se referir a documentos, com intuito de ter uma
11
já foi verificado e aprovado por especialistas.
Para a eficiência na pesquisa de ativos disponibilizada no ProReuso, utilizou-se os
recursos de estruturação textual oferecida pela tecnologia XML(eXtensible Markup
Language) [GRAHAM, 1999]. Cada ativo possui um documento XML associado, que é
alimentado durante a submissão, que armazena as informações do mesmo de forma
estruturada, correspondendo às características do ativo. A indexação desses documentos é
feita através de uma ferramenta (Oracle Intermedia) disponibilizada pelo banco de dados,
utilizando-se a estruturação feita segundo as facilidades fornecidas pelo XML.
Assim, considera-se essas duas últimas funcionalidades diferenciais importantes
disponibilizados no ProReuso. Dessa forma, acredita-se que o ProReuso representa um
exemplo de repositório que serve, de fato, como ferramenta auxiliar para a prática de reuso
dentro de uma organização.
1.5 – Organização do Trabalho
No capítulo 2, apresenta-se a teoria do reuso de software. Nele são introduzidos os

conceitos de reuso e ativos de software (seções 2.1 e 2.2, respectivamente), os diferentes tipos
de classificação existentes para os mesmos( seção 2.4) , sobre quais critérios os ativos devem
ser construídos e analisados para serem reusáveis (seção 2.5) e , ainda, quando e como os
ativos podem ser reusados no processo de desenvolvimento (seções 2.3 e 2.6,
respectivamente). Finaliza-se o capítulo, demonstrando a importância do reuso e atitudes que
permitem o sucesso ou o fracasso do processo de reuso numa organização (seções 2.7 e 2.8).
No capítulo 3, são apresentadas as principais técnicas de reuso: técnica orientada a
objetos (seção 3.1), padrões de projeto (seção 3.2), frameworks (seção 3.3) e técnicas de
componentização (seção 3.4). Essas técnicas representam formas de reuso de software, além
disso exemplificam a possibilidade de haver reuso em várias fases do processo de
desenvolvimento. Tecnologias disponíveis no mercado para cada técnica foram brevemente
descritas como uma forma de demonstração prática de como o reuso pode ocorrer.
coerência com o nome da aplicação.

12
No capítulo 4, são apresentadas os principais aspectos relacionados a repositórios de
componentes, aplicações responsáveis pela organização e armazenamento de ativos de
software. Durante o capítulo, objetiva-se, principalmente, mostrar que um repositório de
componente tem potencial para se tornar uma ferramenta de auxílio à prática de reuso dentro
de uma organização. Para isso, são apresentadas as funcionalidades que um repositório deve
ter, sendo as principais a pesquisa e recuperação de ativos, além das vantagens que ele pode
oferecer. É anotado nesse capítulo a necessidade de se haver um processo de gerenciamento,
para um melhor controle da quantidade e qualidade de ativos disponíveis, da localização e
principais características dos mesmos.
No capítulo 5, é apresentada a tecnologia XML com o intuito de introduzir uma
tecnologia relativamente recente, que foi usada na implementação de um repositório, que
consiste no resultado final desse trabalho. A XML agregou valor na estruturação de
informações, localização e recuperação dos componentes disponíveis no repositório. O
capítulo apresenta fundamentos da tecnologia e qual a sua importância para as aplicações web
atuais.
No capítulo 6, apresenta-se o ProReuso, um repositório de componentes para a web,
implementado como resultado final do estudo dirigido nesse trabalho. É apresentada a
motivação para a construção dessa aplicação, uma descrição das suas funcionalidades, a
arquitetura baseada na qual foi implementada e por fim, um processo de validação dos
elementos, iniciado quando esses são submetidos ao repositório.
Finalmente, no capítulo 7, é feita uma conclusão sobre o projeto desenvolvido.
13
Capítulo 2
Reuso de Software
Pesquisadores e profissionais que se encontram envolvidos com a área de Engenharia de

Software, certamente, já se depararam com o termo reuso de software. Desde 1967, quando,
pela primeira vez, a construção de catálogos de componentes de software, a partir dos quais,
partes de sistemas poderiam ser montadas foi proposta, esse termo vem se desenvolvendo
como um novo paradigma dessa área de estudo.
Com o passar do tempo a importância do reuso vem sendo reconhecida pelas empresas
desenvolvedoras de software, que se preocupam com a competitividade , uma vez que a
aplicação de reuso aumenta a sua produtividade, a qualidade dos seus produtos e reduz custos
e prazos de entrega. No entanto, é válido lembrar que esses resultados só serão alcançados se
além de utilização de reuso houver, por parte das empresas, muita disciplina e prática.
Neste capítulo, portanto, são vistos esses e outros aspectos relacionados à teoria do
reuso de software.
2.1 – Introdução
Reuso de software é a prática sistemática de desenvolver ou atualizar novas aplicações

a partir de ativos de software pré-construídos nos quais são identificados similaridades de
requisitos e/ou arquiteturas com o que está sendo desenvolvido. Além disso, representa um
instrumento para se evitar duplicações e se alcançar benefícios na produtividade, qualidade,
custos, tempo e esforço ao se desenvolver ou manter um sistema.
Essa prática consiste numa mudança revolucionária na maneira de se construir
software. Entretanto, o seu sucesso depende da sua sistematização, que é citada na definição
apresentada acima. Isso não significa dizer que o reuso não sistematizado não caracterize
reuso, no entanto, vale destacar que a aplicação desordenada do reuso torna os procedimentos
sem resultados efetivos e requer que a empresa seja bem gerenciada e madura. O reuso
caracteriza-se pela simplicidade, dependência de conhecimento e iniciativas individuais,
14
ausência de envolvimento da empresa como um todo e pequena presença ou quase
inexistência de gerenciamento ou controle.
Três ações são consideradas relevantes no reuso sistematizado: o planejamento, a
disciplina e o envolvimento. Planejamento refere-se à compreensão de como o reuso pode
contribuir para se atingir os objetivos da organização como um todo, à preparação dos
trabalhadores envolvidos para executar o reuso, à definição de medidas para mensurar e
controlar o sucesso do reuso e ao estabelecimento de suporte organizacional, técnico e
orçamentário apropriados.
Disciplina refere-se à necessidade de existir na empresa, de forma geral, uma contínua
consciência e organizada procura por oportunidades de reuso nos produtos gerados em todas
as fase do processo de desenvolvimento. Oportunidades de reuso são como defeitos: quanto
mais cedo eles forem encontrados, melhor [EZRAN et. al, 1999].
O envolvimento se refere ao grau de interesse e organização da empresa com relação à
prática de reuso. Nesse contexto, [ARANOW, 1994?] classifica dois tipos de empresas:
Tipo 01 - Organizações que desejam implantar o reuso tão seriamente que se dispõem
a investir em disciplina, infra-estrutura, arquitetura e planejamento
necessários para obter bons resultados.
Tipo 02 - Organizações que não levam o reuso tão a sério. Elas investem, basicamente,
em tecnologia, linguagens, ambientes de desenvolvimento e treinamento
voltado para tecnologias. Elas esperam que os resultados do reuso sejam
alcançados com o seu investimento tecnológico.
A grande diferença entre esses dois tipos de organização está no grau de paciência
quanto à espera de resultados. As do primeiro tipo encaram o reuso como um investimento a
longo prazo, enquanto as do tipo 02 investem em esforços que venham trazer resultados em
seis meses ou menos. Certamente, empresas que encaram o reuso como um investimento a
longo prazo, que requer disciplina, têm mais chances de apresentar casos de sucesso, pois sua
prática é sistemática.
Quanto ao custo desse investimento, como geralmente é muito alto e o retorno não é
imediato, leva a supor que empresas sem recursos suficientes não podem praticar o reuso.
Todavia, existem muitos caminhos para a utilização do reuso de software. Segundo o
[ARANOW, 1994?], diretor do The Reuse Group, existem quatro modelos distintos de reuso;
com diferentes benefícios em potencial: reuso ad-hoc, reuso intra-projeto, reuso inter-projeto
15
e reuso organizacional. Ele alerta que as empresas devem ser realistas ao escolherem qual
deles podem ser executados.
Reuso Ad-hoc - Nesse modelo completamente descentralizado e circunstancial, o
reuso é encarado como um objetivo abstrato, mas sem nenhum planejamento, coordenação ou
suporte da organização como um todo. Para alcançá-lo é fácil, mas ele não gera diferenças
visíveis. Além disso, esse é o único nível que não requer um comprometimento financeiro
mais longo do que seis meses. Pode-se concluir, portanto, que esse modelo representa o reuso
não sistematizado citado no início dessa sessão.
Reuso Intra-Projeto - Aqui o reuso ocorre dentro dos projetos e é encorajado de
forma mais ativa pela organização, podendo até existir pessoal especializado para ajudar a
motivar, educar e assistir projetos que tenham iniciativas de reuso. O modelo exige um pouco
mais de esforço e com isso se pode obter projetos que representam casos isolados de sucesso
de reuso. Nas empresas tipo 02, mencionada anteriormente, esse modelo pode ter alguma
chance de ocorrer, particularmente, quando os ativos que estão sendo reusados tenham sido
produzidos fora do projeto.
Reuso Inter-Projeto – Nesse caso, o reuso é encorajado entre os projetos e tem um
suporte central para isso. Existem pessoas para coordenar e colocar os projetos juntos para
facilitar o reuso. Esse modelo exige ainda mais esforço e disciplina, mas em compensação os
benefícios não são restritos a projetos isoladamente.
Reuso Organizacional – Nesse modelo, os ativos reusáveis são vistos como ativos
corporativos. Uma organização que suporta esse modelo de reuso provê uma coordenação de
arquitetura e o gerenciamento de bibliotecas de ativos de software. Seu pessoal trabalha para
garantir que a biblioteca continue suportando as necessidades dos projetos da organização,
apresentando também um envolvimento total da empresa.
Muitas empresas, hoje em dia, não estão preparadas para alcançar o nível de
comprometimento exigidos pelos dois últimos modelos. No entanto, quando elas conseguem
chegar a esse ponto, podem alcançar todos os benefícios que as atraíram para começar a fazer
reuso de software no primeiro momento. Exemplos desses benefícios são: incorporação de
automatização, redução de tempo e custo de desenvolvimento, aumento na qualidade do
software, na produtividade, redução de erros, maior facilidade e menos gastos na manutenção,
dentre outros.
16
2.2 - O Que se Pode Reusar
Na definição de reuso de software, encontra-se a palavra ativos de software pré-

construídos, assim, entender em que consiste esses ativos, torna-se essencial para se melhor
compreender o conceito de reuso.
Vale destacar que quando o termo ativos de software for mencionado neste trabalho se
refere a elementos de software pré-construídos e que são reusáveis. Embora alguns autores
substituam esse termo por componentes de software, neste trabalho, componente
corresponderá a uma unidade de programa executável, o que será melhor explicado no
capítulo seguinte.
Geralmente, quando se pensa em reuso, reporta-se apenas a módulos de código-fonte,
no entanto, ativo de software reusável pode ser qualquer artefato de software produzido em
qualquer fase do processo de desenvolvimento.
Assim, pretendendo-se defender a idéia de que esses artefatos representam a captura de
conhecimentos importantes para a organização e ,portanto, carregam valor em potencial e,
ainda, que o reuso constitui um meio poderoso de se explorar esse valor, o termo ativo torna-
se apropriado para definir esses elementos. Além disso, chama-se a atenção para que as
empresas dêem a mesma importância para esse tipo de ativo que dão aos outros tipos.
Em busca de uma definição mais formal, [EZRAN et al., 1999] propõem que ativos de
software reusáveis são compostos por uma coleção de produtos de software que podem ser
reusados de uma aplicação para outra. A seguir, uma lista de exemplos de ativos reusáveis é
apresentada:
1- Especificações
2- Requisitos de aplicações
3- Definições da fase de projeto
4- Descrições de domínio
5- Arquiteturas de software (incluindo as interfaces de componentes, interconexões
entre eles e plataforma de configuração)
6- Modelos de dados
7- Fragmentos de código de programas
17
8- Documentações
9- Experiências e competências
De fato, [EZRAN et al., 1999] sugerem um modelo que define a composição dos
ativos. Nele é demonstrado a importância de se empacotar os ativos anexando meta-
informações, que os descrevem, para que esses se tornem reusáveis. Dentre essas informações,
pode-se citar:
• informações quanto à classificação que facilitam uma rápida recuperação de ativos
necessários;
• descrição para facilitar a compreensão das funcionalidades do ativo;
• documentação para facilitar na compreensão de como usar o ativo e se necessário
como customizá-lo;
• informações quanto à qualidade e testes para facilitarem na avaliação e em testes
do ativo;
• informações sobre a origem do ativo para se obter informações de suporte ou
adicionais.
O modelo de ativo sugerido pode ser apresentado com um diagrama que usa a notação
UML dessa forma, como mostra a figura 2.1:
18
0..* 0..*
Ativo
Origem : Feito, Comprado
Granularidade
Uso : Vertical, Horizontal

0..*
Identificador
1
1
Descrição
Corpo +Parte Reusável Artefatos do de Software
1..*
1 1
Informação Administrativa Informação de Ambiente Modelo de Análise Código-Fonte Código Executável Cenários de Teste
Autor Ambiente de Desenvolvimento

Creação Ambiente de Execução
Data Ambiente de Teste
Modelo de Projeto Documentação de Usuário Relatório de Teste Programa de Teste
1 Informação de Qualidade
Informação de Classificação Nível de Desenvolvimento
Nível de Reusabilidade
Palavra-Chave
Papel1
Papel2
1
Uso do Ativo
Histórico
Contexto
0..* Resultado
Figura 2.1- Modelo de Ativo
Como se pode ver na figura 2.1, o ativo é composto de duas partes: seu corpo
(constituindo de um ou mais produtos resultantes do processo de desenvolvimento) e sua
descrição (informações necessárias para o suporte do processo de reuso).
Além disso, existem dois possíveis tipos de relacionamento de um ativo com outros,
que são:
. Composição - ativos podem ser aninhados, ou seja, um ativo pode ser composto por
um ou mais ativos reusáveis. De fato, como já mencionado anteriormente, um ativo é
composto por um ou mais produtos de fases do ciclo de vida do software e esses produtos são
ativos reusáveis em potencial. Quem reusar esse ativo, tem a chance de escolher se reusará o
ativo como um todo (e consequentemente, todos os seus ativos componentes) ou apenas uma
parte componente.
19
. Dependência(uso) - um ativo pode utilizar funcionalidades de um ativo pré-
construído para executar as suas. Quem o reusa, pode escolher entre também reusar os ativos
relacionados ou fazer uma nova implementação para eles.
O modelo sugerido pode ser customizado de acordo com as necessidades da empresa e
como se pretende praticar o reuso nela. Uma customização desse modelo poderá ser visto
no capítulo 6 desse trabalho, onde se apresenta a implementação de um repositório.
2.3- Oportunidades de Reuso
Uma vez entendido em que consistem os ativos de software reusáveis, faz-se

necessário identificar onde se encontram as oportunidades de reusá-los. Encontrar essas
oportunidades significa, de fato, identificar similaridades nas demandas de duas aplicações.
Os ativos em comum servirão como solução para satisfazer essas necessidades.
A fonte dessas similaridades entre as aplicações pode ser encontrada em dois aspectos
do problema: os requisitos e a arquitetura definidos. Isso não contradiz o que foi dito
anteriormente quanto à definição de ativo de software, onde se afirma que qualquer artefato de
qualquer fase do processo de desenvolvimento pode ser um ativo reusável. Aqui, os termos
definição de requisitos e arquitetura não se referem a uma fase do processo, mas a um aspecto
da aplicação. Serão apresentados a seguir os conceitos de requisitos e arquitetura nesse
contexto. Assim, pretende-se possibilitar uma melhor compreensão do emprego desses
termos.
Requisitos especificam o problema, quais os objetivos da aplicação, ou seja, qual
conjunto de características a solução específica deve contemplar. O processo de definição de
requisitos inicia-se no começo do desenvolvimento do software e pode continuar, com maior
ou menor intensidade, até perto do seu final. Aqueles definidos nas etapas iniciais do processo
são chamados de requisitos de alto nível.
De acordo com [EZRAN et al., 1999], os requisitos podem endereçar quase todas as
dimensões do espaço da solução, que incluem funcionalidade, performance, confiabilidade,
manutenabilidade, interface do usuário, custos, prazo de entrega, plataforma operacional
(hardware ou software), plataforma de desenvolvimento (métodos, linguagens e ferramentas),
portabilidade, tempo de vida, interações com outros sistemas e assim por diante. A própria
adoção de uma arquitetura específica, em algumas circunstâncias, pode ser considerada uma
20
definição de requisito de alto nível. De outra forma, essa adoção representará uma decisão de
projeto decorrente da necessidade de atender-se a outros requisitos. No entanto, a escolha de
uma determinada arquitetura, em ambos os casos, influenciará a definição de requisitos nas
fases seguintes. De certa forma, quer-se dizer que esses dois aspectos da aplicação podem não
ser totalmente independentes um do outro.
Quanto à arquitetura, pode-se dizer que se trata da especificação de uma estrutura para
a aplicação. Além disso, pode ser entendida como uma categoria generalizada ou um modo de
solução para as seguintes dimensões: funcionalidade, interface de usuário e plataforma
operacional.
Arquiteturas funcionais dizem respeito aos domínios de aplicação, isto é, áreas
funcionais de aplicação que contêm sistemas que compartilham decisões de projeto. Com isso,
são frequentemente referenciadas como arquiteturas de domínio. Representam elemento
importantíssimo para o reuso.
As arquiteturas de interface de usuário e as de plataforma operacional são
referenciadas como domínios técnicos. As primeiras definem elementos de interface, como
menus, formulários, linhas de comando, botões e etc., e como eles se combinam . As outras,
também conhecidas como arquiteturas de implementação, definem modelos comuns nos quais
o hardware, os sistemas operacionais, outros utilitários de software e ferramentas de camada
intermediária são configurados para prover suporte de infra-estrutura usados pelo software da
aplicação.
A identificação dessas similaridades, entretanto, deve ocorrer em níveis mais altos do
processo de desenvolvimento. O reuso, como será visto mais adiante, diminui a ocorrência de
erros. Assim, quando o reuso ocorre em níveis maiores, ele se torna mais eficiente, pois erros
nas fases de definição de requisitos e arquitetura são mais caros do que os de programação ou
codificação, e portanto, significará potencialmente menores gastos e benefícios
[CHOUDHURY, 1995].
Diz-se potencialmente, pois para se alcançar por inteiro os benefícios, não basta
apenas identificar prematuramente as similaridades e suas correspondentes oportunidades de
reuso. Para tanto, exige-se que se ocorra no sistema anterior um bom registro do fluxo
seguido, partindo-se das decisões de requisitos e arquiteturas em direção às decisões
subsequentes. Isso aumenta a possibilidade de que esse fluxo seja re-executado na nova
aplicação, o que significa mais ativos sendo reusados em todas as fases do processo e,
consequentemente, maior alavancagem alcançada.
21
2.4 - Classificação dos Ativos
Os ativos de software são classificados quanto ao tipo de reuso em ativos verticais e

horizontais [EZRAN et al.1999].
Ativos Verticais - são aqueles reusados entre aplicações do mesmo domínio.
Representam o know-how da organização e a sua vantagem competitiva, pois capturam
conhecimentos específicos do negócio. Exemplos são dados em Tabela 2.1.
Tabela 2.1
Exemplos de Ativos Verticais

1. Projeto e código de um módulo de gerenciamento de
pacientes(área de saúde)
2. Modelos de objetos financeiros
3. Modelo genérico de objetos do domínio de Controle
de Tráfego Aéreo
Ativos Horizontais - são aqueles reusados entre aplicações de domínios diferentes.

São mais fáceis de serem identificados, pois representam repetições de elementos de
arquitetura. Para que ocorra o reuso, é necessário que as escolhas referentes à arquitetura
sejam compatíveis com as do ativo. Dentre os horizontais, pode-se diferenciar ativos técnicos,
que são tecnicamente necessários para a implementação de camadas mais baixas do sistema
de software, de ativos genéricos, que representam serviços genéricos úteis para mais de um
domínio de aplicação. Exemplos desses ativos são dados em Tabela 2.2 e Tabela 2.3.
22
Tabela 2.2
Exemplos Ativos Horizontais Técnicos

1. Objetos de Interface Gráfica de Usuários (formulários,
planilhas)
2. Classes containers, estruturas de dados, algoritmos
básicos
3. Bibliotecas de acesso a banco de dados
4. Bibliotecas de comunicação de redes
Tabela 2.3
Exemplos de Ativos Horizontais Genéricos

1. Serviço de relatório
2. Serviço de autenticação
3. Serviço de log e rastreamento
4. Framework de gerenciamento de erros
É importante ressaltar que essa classificação é subjetiva, pois um ativo vertical pode
ser transformado em horizontal caso o domínio, anteriormente definido, seja dividido em mais
de um. Isso ocorre porque domínios podem estar aninhados, ocorrendo a definição de
domínios mais precisos pertencentes a outros mais genéricos. Por exemplo, pode-se ter o
domínio de gerenciamento de performance de redes pertencente ao de gerenciamento de redes.
Outra classificação para ativos é quanto ao seu tamanho e granularidade. Como já
mencionado, eles podem estar aninhados, e com frequência estão. Porém, quem os está
reusando tem a liberdade de reusar o ativo como um todo ou suas partes individualmente.
Ativos que representam o todo são conhecidos como de granularidade grande, aqueles que
constituem partes são conhecidos como de granularidade pequena. Em ordem crescente de
granularidade, os ativos podem ser assim exemplificados:
• uma função ou um procedimento
23
• uma classe
• um grupo de classes, um pacote
• um subsistema, um framework ou um serviço
• uma aplicação ou um produto
Vale ressaltar que quanto maior a granularidade do ativo, mais cedo ele deve ser
considerado no processo de desenvolvimento da aplicação [EZRAN et al., 1999].
2.5 - Características de um Ativo Reusável
Para se determinar a reusabilidade de um ativo, esse deve passar por um processo de

avaliação de qualidade segundo alguns critérios pré-definidos. Esses critérios dividem-se em
três tipos:
. Critérios Gerais
- Conformidade com padrões, roteiros e regras pré-definidas no que diz
respeito a projeto, codificação e documentação (por exemplo, modelos de
documentação, política de nomes).
- Conformidade do processo de engenharia do ativo com padrões e melhores
resultados detectados de práticas anteriores, respeitando as fases definidas pela
engenharia de software, documentando e rastreando cada passo, respeitando métodos
de projeto, processos de validação e de teste.
- Simplicidade e possibilidade de compreensão.
- Modularidade.
- Completude dos artefatos e informações providas e sua conformidade com o
modelo de ativo definido.
. Critérios Funcionais
Esses critérios cabem mais a ativos verticais. Aqui, apenas serão apresentadas
características funcionais gerais para qualquer ativo, pois esse tipo de ativo é
específico para cada domínio. Cada empresa deve definir critérios mais específicos de
acordo com o seu particular domínio.
- A função do ativo é acelerar ou simular, parcial ou totalmente, um processo
24
do negócio.
- O ativo provê serviços e consegue priorizar chamadas, agendar e gravar suas
execuções.
- O ativo deve se manter disponível para seus clientes e deve ser capaz de
executar atividades em paralelo.
- O ativo pode delegar serviços para ativos aninhados ou para outros ativos.
- O ativo deve estar de acordo com os padrões praticados no domínio da
aplicação.
- O ativo deve implementar o dilema entre ser muito específico(assim menos
reusáveis) e ser mais genérico (mais reusável).
. Critérios Técnicos
Esses critérios servem para facilitar que o ativo seja reusado e integrado. A
maioria desses critérios são mais aplicáveis a componentes que são desenvolvidos
usando tecnologias de componentização, como JavaBeans e ActiveX, que serão
melhor explicadas no capítulo seguinte.
- Interoperabilidade: Capacidade de se comunicar e integrar com outros ativos
numa aplicação, que podem ser implementados em linguagens diferentes e podem
estar rodando em máquinas diferentes com diferentes plataformas.
- Portabilidade: Capacidade de rodar em plataformas diferentes. [EZRAN et
al.1999] alerta para o fato de que ativos verticais não devem se conectar diretamente
com serviços de implementação, como interfaces gráficas ou banco de dados. Ele
aconselha a definição de interfaces lógicas para prover esses serviços e assim, garantir
a portabilidade e independência do software em relação ao computador que o serviço
está implementado.
- Separar a interface da implementação: como o ativo é usado ou reusado e
como ele é implementado devem ser coisas distintas, pois elas podem evoluir
separadamente.
- Composição: ativos podem ser agrupados para formar ativos de maior

granularidade e podem ser decomposto em vários ativos de menor granularidade. No
entanto, devem respeitar os critérios de reusabilidade em qualquer nível de
granularidade.
25
- Auto-descritivo: componentes devem fornecer suas interfaces bem definidas,
que correspondem ao que podemos chamar de protocolo de uso, para que quem quiser
reusá-lo possa compreendê-lo sem que seja necessário recorrer aos artefatos de
software gerados no seu desenvolvimento, nem consultar suas interfaces e
propriedades profundamente.
- Localização transparente: componentes podem rodar em diferentes máquinas,

sem que gere impacto no restante do sistema.
- Segurança: como componentes correspondem a códigos executáveis e são

usados pela comunidade de desenvolvedores como caixas pretas, seus usuários devem
poder controlar a origem do ativo (assinatura digital) e controlar o acesso do ativo a
determinados recursos.
- Plug and Play : a portabilidade do componente não é exigida apenas quando

esse está sendo construído, mas também em tempo de execução, como ocorre com um
componente Java, cujo código pode ser executado em diferentes plataformas.
2.6 – Formas de Reuso
Quando o ativo é reusado, pode-se classificar esse reuso quanto à necessidade ou não
de haver adaptações para se atender às requisições do sistema e nos casos em que se façam
necessárias essas adaptações, como elas foram feitas.
. Reuso Caixa Preta (black box reuse) - Quando os ativos são inseridos ao sistema
sem qualquer modificação.
. Reuso Caixa Branca (white box reuse) - Quando há necessidade de reengenharia, ou
seja, quando for necessário a modificação do corpo do ativo para se obter as propriedades
requeridas pelo sistema.
. Reuso Caixa Cinza ou Cinzento (grey box reuse) – Intermediário dos dois
anteriores, quando as alterações são feitas via configuração de parâmetros.
. Reuso Transparente (glass box reuse) – Em situações nas quais não se faz
necessário fazer alterações, mas para descobrir as propriedades do ativo é preciso olhar dentro
dele, pois a descrição disponível não traz informações adequadas dessas propriedades.
26
Além dessa classificação, é possível analisar as formas possíveis de reuso de uma ativo
de acordo com a forma que o mesmo se apresenta. Essa forma ainda influencia como o ativo
será implementado na nova aplicação. A Tabela 2.4 mostra as estratégias de implementação
de um ativo de acordo com a sua forma, no entanto não constituem todas as estratégias
possíveis. [EZRAN et al., 1999]
Tabela 2.4
Estratégia de Implementação de um Ativo de Acordo com sua Forma

Forma de Ativo Descrição Forma de Reuso
Modelos de Modelos de requisitos, sobre o qual o produto foi Comparação

Requisitos construído, pode ser mantido e comparado com
requisitos de novos clientes a fim de se avaliar se o
produto atende a todas as suas necessidades.
Modelos de Constituem a linha de base sobre a qual os modelos Construir a partir
Domínio das aplicações (dentro desse domínio) são de
construídos.
Gerador de Ele permite a construção de uma nova aplicação, Geração
Aplicação ou parte dela, a partir de sua especificação.
Frameworks Aplicações são construídas customizando e Customização
adaptando o framework de acordo com o seu estilo
e regras de arquitetura.
Padrão(Pattern) Consistem em soluções de modelagem Imitação
identificadas, que podem ser aplicadas a vários
problemas quando se está modelando diferentes
sistemas.
Biblioteca Conjunto de classes ou procedimentos que podem Integração
ser integrados a ou chamados por várias aplicações.
Componente Pode ser executado separadamente. Aplicações o Invocação
Executável reusam invocando-o ou fazendo chamadas a seus
serviços em tempo de execução.
Linha de base de Consiste de todas os artefatos de software estáveis Extração
Produto que estão contidos em diferentes versões do
produto. Qualquer produto novo é construído a
partir de todos ou alguns desses pedaços de
software.
Vale destacar que algumas dessas formas de ativo serão melhor explicadas no capítulo
seguinte.
27
2.7 – Importância do Reuso
Uma vez introduzida a idéia do que se trata reuso, o que são os ativos de software
reusáveis, quais as classificações possíveis e como identificá-los, faz-se necessário entender
quais os benefícios de se adotar a prática do reuso. Assim, com uma lista de benefícios que
será apresentada a seguir, pode-se perceber a importância dessa prática para as empresas
desenvolvedoras:
- simplificação do desenvolvimento de software;

- redução de custos, prazos de entrega e esforço para se desenvolver e manter o
software;
- aumento de produtividade;
- desenvolvimento de softwares de maior qualidade, e portanto, de maior
confiabilidade;
- redução de erros;
- conhecimentos sobre sistemas e como construí-los podem ser compartilhados;
- facilidade em aprender sobre arquiteturas de sistemas;
- aprendizado sobre como construir sistemas bons;
- compartilhamento de conhecimentos adquiridos com a experiência, ou seja,
compartilhamento de melhores práticas;
Muitos desses benefícios são consequências de outros e um resumo deles foi

apresentado ao se definir reuso, no início deste capítulo. Assim, para facilitar a compreensão
de como a prática do reuso, feita de forma sistemática, possibilita o alcance desses benefícios,
eles serão agrupados em três tipos de melhorias: na produtividade, qualidade e desempenho
do negócio.
Em termos de produtividade, pode-se destacar o fato de que o reuso significa menos
esforço da equipe porque significa menos escrita, ou seja, não há “reinvenção da roda”. É
importante lembrar que essa reinvenção não se prende a códigos de programas, consiste
28
também numa reinvenção de conceitos. Quando se evita que conceitos sejam reinventados e
se permite que sejam reaproveitados, há um diminuição substancial no tempo inicial gasto
para se compreender como a nova aplicação deve funcionar, pois se buscam semelhanças
entre as aplicações e não se perde tempo tentando imaginar uma solução que já foi descoberta.
Em consequência dessa diminuição de esforço, pode-se perceber que também há redução de
custos e tempo necessários para se desenvolver um sistema.
A melhoria da qualidade pode até ser considerada como uma consequência do que foi
dito no parágrafo anterior, pois se os esforços num projeto são substancialmente reduzidos,
possivelmente existirão menos defeitos. Além disso, dado que quantidades menores de
esforço são mais fáceis de serem previstas do que quando maiores, melhores orçamentos e
estimativas também poderão ser feitos.
Outro aspecto que conduz ao aumento de qualidade é quando se considera que uma
vez o ativo tenha qualidade comprovada em um projeto, ela poderá ser carregada para outros.
No entanto, deve-se ter o cuidado de não se assumir que projetos de contextos diferentes
obrigatoriamente têm os mesmos referenciais de qualidade. Além disso, reduções substanciais
de esforço não devem conduzir os desenvolvedores que farão o reuso à falta de cuidado no
desenvolvimento.
Por último, o aumento de qualidade gera menores custos de manutenção e serviços.
Quanto à melhoria de desempenho do negócio pode-se incluir os já citados aspectos de
redução de custos, menor tempo para o mercado, melhor capacidade de previsão e entrega de
produtos de maior qualidade. A esses benefícios ainda se pode acrescentar maior
lucratividade, crescimento, capacidade de competição e entrada em novos mercados.
Após a análise desses aspectos, pode-se concluir que talvez o maior benefício que a
prática de reuso sistemático possibilita é uma maior satisfação dos clientes, afinal prazos de
entregas menores, produtos e serviços de maior qualidade são algumas exigências constantes
do mercado.
Todavia, é importante lembrar que esses benefícios não serão alcançados sem grandes
esforços. O reuso sistemático constitui uma grande mudança na forma de encarar o
desenvolvimento de software e como qualquer outra grande mudança, demanda grandes e
contínuos esforços. Por não terem muita consciência disso é que muitas empresas têm falhado
nos seus processos de transição para a prática de reuso. Essas falhas, assim como orientações
para alcançar o sucesso, serão destacadas na próxima seção.
29
2.8 – Sucesso e Falhas no Reuso
Como já foi dito na seção anterior, coisas grandes e valiosas só são conseguidas com
grandes esforços. Mais do que tudo é necessário muita disciplina para não falhar ao iniciar um
processo de adesão ao reuso. As empresas precisam se conscientizar disso e colocar a teoria
em prática. Assim, torna-se essencial nesse momento a apresentação das falhas mais comuns
cometidas pelas empresas em suas tentativas, juntamente com soluções de sucesso.
Os aspectos que aqui serão apresentados têm como referência o resultado de um
trabalho realizado com algumas empresas européias que desenvolvem projetos industriais.
Esse trabalho consiste numa pesquisa baseada em reuso, realizada através de entrevistas
estruturadas com gerentes de projetos dessas empresas2.
Alguns fatores que podem ser considerados como determinantes de fracassos no
processo de reuso são:
- Não envolvimento e comprometimento por parte da alta gerência das empresas.
- Não introdução de processos de reuso, como análise de domínio3, qualificação e
classificação.
- Inalteração de processos diferentes do de reuso, como análise de requisitos, de
projeto .
- Nenhuma preocupação ou direcionamento para fatores humanos, como treinamento e
motivação para a prática do reuso.
- Entendimento da empresa que repositório ou tecnologia orientada a objetos tratados
isoladamente, sem ações complementares, significam reuso.
Para se evitar que essas falhas venham a acontecer, pode-se elaborar uma orientação,
no sentido de apresentar questões que devem ser consideradas quando a empresa está
2
Maiores detalhes sobre a pesquisa podem ser encontrada em [MOURIZIO et al., 2000].
3
Atividade que determina os requisitos comuns dentro de um domínio, com o propósito de identificar
oportunidades de reuso entre sistemas de um domínio. Ao final da atividade, é construído um modelo de
arquitetura de domínio representando as semelhanças e diferenças nos requisitos de um domínio.
30
iniciando seu programa de reuso. As empresas entrevistadas que obtiveram sucesso em seus
projetos estavam alertas para o que vai ser apresentado a seguir.
1. Potencial de Reuso
Avalie o potencial de reuso, o qual é maior quando as empresas desenvolvem
produtos de software similares que evoluem com o tempo e são mais ou menos
adaptados para cada cliente.
2. Capacidade de Reuso
Consiga um comprometimento da alta gerência para obter recursos necessários e
poder para:
• Mudar processos de desenvolvimento
• Adicionar processos de reuso
• Trabalhar fatores humanos
• Instalar um repositório
• Definir pessoas chaves para o reuso
A ordem em que esses itens aparecem não é importante, todos esses aspectos
devem ser executados. Se dois ou mais deles não forem direcionados, o fracasso é bem
provável de acontecer.
Segundo [MOURIZIO et al., 2000], os conceitos errados que muitas empresas
acreditam, como orientação a objeto sozinha provê reuso, instalação de um repositório
isolada sem nenhum mecanismo de controle de qualidade, gerenciamento de versão ou
divulgação interna provê reuso, tendem ao entendimento superficial da importância de
se endereçar todos os itens acima.
3. Implementação de Reuso
O endereçamento dos itens anterior geram outras escolhas de níveis mais baixos.
• Mudança nos processos de desenvolvimento: definição e análise de requisitos,
projeto de alto nível e teste requerem mudanças específicas para se levar em
conta a disponibilidade dos ativos. O gerenciamento de projeto também é
impactado, assim como aspectos de cronograma, custos e produtividade.
• Adição de processos de reuso: análise de domínio pode ou não ser usada para
direcionar a identificação de ativos reusáveis. Ativos podem ser menores ou
maiores, incluindo ou não projeto e requisitos. Podem ser produzidos e
mantidos por um grupo específico ou por projeto, antes de serem necessários
ou no momento que forem requisitados pela primeira vez.
31
• Trabalhar fatores humanos: uma ou mais técnicas podem ser usadas, como
treinamento, eventos de conscientização, grupos de discussões e notícias.
Premiações isoladas não são suficientes.
• Instalação de repositório: como será implementado, quais os processos que
serão usados, como qualidade e gerenciamento de configuração. Pode ser
usado uma ferramenta específica ou um add-on para implementar um sistema
de gerenciamento de configuração.
Por fim, vale ressaltar que a disponibilização de recursos na empresa, geralmente
relacionado ao seu tamanho, deve ser considerada com cuidado para se fazer escolhas que
possam ser sustentadas.
2.9 – Considerações Finais
Nesse capítulo foram apresentados aspectos relacionados ao reuso de software.

Inicialmente, definiu-se reuso de software como uma prática sistemática de desenvolver ou
atualizar novas aplicações a partir de ativos de software pré-construídos nos quais são
identificados similaridades de requisitos e/ou arquiteturas com o que está sendo desenvolvido.
Além disso, mostrou-se que quando o reuso é feito de forma sistemática significa um
instrumento para se evitar duplicações e se alcançar benefícios na produtividade, qualidade,
custos, tempo e esforço ao se desenvolver ou manter um sistema.
Apresentou-se que ativos de software podem ser produtos gerados em qualquer fase do
desenvolvimento, que atendam certos critérios. Foram apresentadas classificações para os
ativos quanto ao tipo de reuso e sua granularidade. Foi visto, ainda, que o reuso pode ser
classificado quanto à necessidade do ativo ser atualizado ou não para atender aos requisitos do
novo sistema.
Ao final foi ressaltada a importância do reuso por permitir que empresas reduzam os
seus custos e prazos de entrega, ainda aumentando a qualidade dos seus produtos. No entanto,
para isso ocorrer se faz necessário que haja uma série de mudanças e esforços internos da
empresa, como o envolvimento total da organização com o processo de reuso.
O capítulo seguinte apresenta as principais técnicas que viabilizam o reuso na empresa.
O capítulo tem como objetivo mostrar as reais possibilidades de reuso em diferentes fases do
desenvolvimento do software.
32
33
Capítulo 03
Tecnologias de Reuso
No capítulo anterior foi mostrado aspectos relacionados ao reuso de software e sua

importância. Neste capítulo, são apresentadas as principais técnicas desenvolvidas para a
realização e maximização do reuso de componentes, de arquiteturas de projeto e de
experiências de projetistas através de soluções para problemas comuns de contextos
específicos. As ténicas apresentadas serão: Ténicas Orientadas a Objeto, Padrões de Projeto,
Frameworks e Desenvolvimento Baseado em Componentes.
Nos últimos anos, várias técnicas de reuso têm surgido e todas procuram mostrar uma
visão ou solução para problemas relacionados a apenas uma ou algumas fases do processo de
desenvolvimento de software. À medida que as técnicas forem sendo apresentadas, neste
capítulo, serão também descritos exemplos de tecnologias que as habilitam com o intuito de
propocionar uma melhor compreensão de seus conceitos. Dessa forma, será possível mostrar
como reusar em diferentes fases do desenvolvimento, de acordo com o que foi abordado no
capítulo anterior.
3.1 – Técnicas Orientadas a Objetos
As técnicas orientadas a objeto (TOO) representam estratégias para organizar sistemas

como coleções de objetos que se interagem. Os objetos correspondem aos conceitos do
domínio do problema que serão representados em modelos e implementados em códigos de
programa. Cada objeto é identificado pelos seus atributos, comportamento e relacionamentos
com os outros objetos.
Essas técnicas permitem a construção de sistemas menos monolíticos, ou seja, mais
modularizados. A aplicação não é mais vista como uma função complexa que precisa ser
decomposta em sub-rotinas. Ao invés disso, os projetistas identificam entidades do domínio
da aplicação, suas responsabilidades e relacionamentos e projetam as aplicações tendo em
mente quais os objetos que podem ser reusados.
34
As TOO abrangem análise (análise OO, AOO), projeto (design OO, DOO) e
implementação (programação OO, POO). Em cada uma dessas vertentes, encontram-se
princípios que representam mecanismos para a reusabilidade, tais como: abstração de dados,
encapsulamento, herança e agrupamento de objetos em classes.
A AOO apresenta métodos que provêem componentes e relacionamentos para a
modelagem do sistema. Esses métodos correspodem à aplicação dos princípios de abstração,
herança e agrupamento de objetos em classes. A abstração encoraja os desenvolvedores a
descreverem e representarem os sistemas da mesma forma como eles são percebidos, sem
qualquer referência à maneira como seus objetos e as operações executadas neles são
implementados. Objetos que compartilham as mesmas propriedades e comportamento são
agrupados em classes. Os objetos individualmente são chamados de instâncias da classe. As
classes, por sua vez, são organizadas hierarquicamente através de relacionamentos. O
princípio da herança seria uma técnica de representação de um relacionamento onde uma
classe deriva da outra, no entanto apresentam certas diferenças. Com isso, classes podem ser
reusadas.
O projeto orientado a objetos (DOO) se refere à transformação dos modelos gerados na
AOO em modelos de projeto que apresentem propriedades necessárias para essa fase. A
linguagem UML, utilizada para especificar, visualizar, construir e documentar os artefatos de
software gerados nas fases de desenvolvimento, consiste em um exemplo de definição de
métodos para AOO e DOO. Hoje, a UML vem sendo considerada uma metodologia padrão.
A programação orientada a objetos (POO) se baseia no conceito de que os objetos são
unidades de programa que encapsulam tanto dados como algoritmos. Aqui, se percebe a
aplicação do princípio de encapsulamento, o qual garante que o acesso aos objetos e a
manipulação de seus dados sejam realizados em uma única localização e de forma
transparente, ou seja, a implementação das operações são escondidas. Isso também facilita o
reuso, visto que objetos podem ser usados como caixas-pretas caso as interfaces, definidas
como forma de acesso às operações, não sejam alteradas. O reuso nesse caso é suportado na
forma de bibliotecas de classes. Isso é feito por meio de uso de objetos de classes já existentes
nas que estão sendo desenvolvidas ou através de especialização de classes.
Como se pode ver, as técnicas orientadas a objetos suportam a reusabilidade, no
entanto não podem garanti-la, pois conforme já foi dito anteriormente, a utilização dessas
técnicas de forma isolada, sem considerar questões como cultura e envolvimento da empresa,
não garantem o alcance de sucesso no reuso.
35
3.2 – Padrões de Projeto
Originalmente nomeados no inglês de design patterns, padrões de projeto significam

soluções, identificadas por especialistas em projeto de sistemas orientados a objeto, para
problemas comuns em um determinado contexto [GAMA et al.,1995]. Eles surgiram como
uma técnica de documentação de soluções de projeto. Cada padrão de projeto, entretanto, é
uma solução para apenas um problema.
Essas soluções são concretas e podem ser reusadas, pois correspondem a soluções para
problemas que ocorrem com frequência. No entanto, para que o reuso seja possível, um
padrão de projeto deve apresentar uma descrição completa da solução. Essa descrição
corresponde a um formulário composto de certos elementos. Cada autor da comunidade que
estuda e define esses padrões define formulários diferentes, no entanto eles entram em acordo
quanto a certos elementos essenciais que um padrão deve conter. A seguir, esses elementos
são descritos:
- Nome
Deve ser um nome significativo, que transmita a idéia daquilo a que se propõe o
padrão. Nomes de padrões se transformam em elementos do vocabulário dos
projetistas. Esses nomes permitem o uso de uma simples palavra ou pequena frase para
referenciar o padrão, conhecimento e estrutura que ele descreve. Às vezes, existe mais
de um nome sendo usado e reconhecido na literatura para um mesmo padrão. Quando
isso ocorre, é comum documentar esses sinônimos sob os títulos de Pseudônimos ou
Também Conhecido Como. Existem alguns autores que acrescentam uma
classificação ao nome do padrão.
- Problema
Uma declaração da situação problema descrevendo quais as suas intenções, ou
seja, seus objetivos em um dado contexto e sob determinadas condições.
- Contexto
36
São as pré-condições sob as quais o problema e sua solução são aplicáveis. Pode-
se entender como a configuração inicial do sistema, antes do padrão ser aplicado a ele.
- Aspectos Motivadores
Descrição de como as estruturas de classes e objetos no padrão conseguem
solucionar o problema. Descreve-se quais e como os aspectos tomados em
consideração na solução se interagem ou entram em conflito para alcançarem o
resultado esperado.
- Solução
Descrição dos elementos que compõem a solução desse problema de projeto,
juntamente com as suas responsabilidades, relacionamentos e colaborações. Consiste
em representações de regras estruturais e dinâmicas, que descrevem um guia de
instruções de como realizar o resultado desejado. Para representar essas regras são
anexados diagramas que identificam a estrutura do padrão, seus participante e suas
colaborações necessárias para que a solução do problema seja aplicada. Segundo
[APLLETON, 2000], não se deve esquecer, entretanto, a descrição do seu
comportamento dinâmico, pois isso geralmente é o que dá sentido à existência do
padrão.
- Exemplos
Exemplificação de uma ou mais aplicações do padrão, objetivando ilustrar um
contexto inicial específico, como o padrão é aplicado a esse contexto e como o
transforma, além do resultado(configuração final) alcançado. Esses exemplos ajudam
os leitores a compreenderem melhor o uso e a aplicabilidade do padrão.
- Consequências
Descrição das pós-condições e efeitos colaterais gerados depois da aplicação do
padrão, ou seja, o estado ou configuração do sistema no novo contexto alcançado.
Além disso, também devem ser descritos outros problemas ou padrões que podem
surgir com esse novo contexto. Portanto, deve-se incluir consequências boas e más,
representando pontos de decisão do tipo custo-benefício que são gerados. Essa
37
documentação ajuda na identificação dos próximos padrões que podem ser seguidos a
esse, pois o contexto atual pode ser o inicial de outro padrão.
- Justificativas
Justificação sobre a eficiência do padrão, porque ele funciona e resolve o
problema.
- Implementação
Descrição de técnicas para a implementação do padrão. Algumas vezes são
apresentados códigos-fontes, representando uma implementação concreta da solução.
- Padrões relacionados
Existem alguns padrões que se relacionam entre si. Pode-se citar aqueles que são
predecessores, cuja aplicação conduz a esse padrão; sucessores, cuja aplicação segue a
desse; alternativos, que apresentam soluções diferentes para o mesmo problema, mas
sob condições diferentes; por fim, co-depedentes que podem ser aplicados
simultaneamente a esse.
- Usos conhecidos
Descrevem aplicações concretas do padrão em sistemas já existentes. Isso
possibilita a validação do padrão, mostrando que trata-se de uma solução
comprovadamente eficiente para um problema recorrente.
Dá-se o nome de linguagem de padrão para uma coleção estruturada de padrões de

projeto para um domínio específico de aplicação. A estrutura dessa linguagem é representada
através de relacionamentos de dependência entre cada um dos padrões.
Os padrões e as linguagens de padrão são representações concretas de conhecimentos
de peritos num determinado domínio, portanto significam um avanço no nível de
comunicação entre projetistas que trabalham juntos.
38
Vale dizer que os padrões se aplicam em diferentes níveis de abstração e não apenas a
projeto. Existem ainda padrões de arquitetura e de implementação (idiomas). Um exemplo de
padrão de arquitetura será apresentado na próxima seção.
3.3 - Frameworks de Aplicação
Como foi citado anteriormente, os padrões abrangem outros níveis de abstração

diferentes de projeto. Um framework consiste num padrão de arquitetura que provê um
modelo de sistema ou subsistema customizável para atender às necessidades de aplicações
pertencentes a um domínio.
Essa arquitetura corresponde a um conjunto integrado de elementos de software
reusáveis que trabalham em conjunto para resolver um problema. O framework especifica a
estrutura e o comportamento genéricos desses elementos, acrescentando suas
responsabilidades e regras de organização de relacionamentos entre eles.
Assim, pode-se afirmar que o framework especifica o esqueleto de uma aplicação, não
correspondendo, portanto, a uma aplicação completa. Ao contrário, esse esqueleto precisa ser
preenchido de modo a se construir uma aplicação que atenda às funcionalidades específicas do
cliente. O sistema concreto será gerado a partir de customizações nos vários aspectos do
framework.
Para permitir essa adaptação e extensão, frameworks codificam o contexto da
aplicação numa espécie de “máquina virtual” e implementam suas abstrações de forma aberta,
permitindo que sejam finalizadas de acordo com as necessidades específicas de cada
aplicação. Segundo [APPLETON, 2000], os pontos dessas abstrações onde ocorrem
customizações podem ser vistos como pontos de plug, entendendo que neles serão plugados
componentes que implementam as funcionalidades variantes.
Segundo [EZRAN et al., 1999], as customizações podem ser efetuadas de duas formas:
. Customização Caixa-Preta: são definidas interfaces para os componentes que
serão plugados no framework via composição de objetos. O reuso de uma funcionalidades
existente é feito através da definição de componentes que implementam uma interface
específica.
39
. Customização Caixa-Branca: os componentes que serão plugados são
especializações do que foi definido no framework. É provido implementações genéricas para
os aspectos variáveis, assim através de relacionamentos de herança essas funcionalidades são
reusadas e extendidas. Aqui, tem-se uma maior flexibilidade na customização, mas requer um
entendimento profundo do projeto e implementação do framework.
Comparando essa técnicas com as anteriormente apresentadas, biblioteca de classes e
padrões de projeto, frameworks consistem tanto em reuso de código quanto de projeto. De
fato, um framework pode ser visto como a implementação de um sistema de padrões de
projeto. Além disso, a diferença entre padrões de projeto e frameworks refere-se ao fato de
que os primeiros representam especificações para um conjunto de classes, enquanto
frameworks especificam aspectos de um sistema como um todo. Os padrões de projeto podem
ser empregados tanto no projeto como na documentação de um framework. Assim, percebe-se
que aplicações construídas a partir de um framework, não são projetos partidos do “zero”,
contrariamente, o projeto do framework é usado como ponto de partida.
No entanto, construir um framework não é tarefa fácil, pois isso requer um
conhecimento profundo do domínio de aplicação que está sendo considerado em termos de
entidades e relacionamentos que podem ser capturados e reusados [EZRAN et al., 1999].
Além disso, deve-se atentar ao fato de que quanto mais concreto for o elemento de software,
quer dizer, quanto mais específica for a sua implementação, também mais específicas serão
suas interações, o que trará dificuldade em atender requisitos de aplicações futuras. A
flexibilidade nos padrões de interações entre elementos de software são essenciais para a
reusabilidade do framework. Assim, pode-se perceber porque frameworks são construídos de
acordo com vários padrões de projeto.
Frameworks de aplicação orientados a objetos podem ser classificados em duas
categorias:
. Framework de Aplicação Corporativa: corresponde a uma aplicação semi-
completa, que serve como guia para o desenvolvimento de uma família de aplicações
corporativas similares de um domínio específico. A característica que os diferenciam de
bibliotecas de classes, é a inversão de fluxo, isto é, o framework provê a arquitetura da
aplicação e o fluxo de controle principal, o qual define como o componente provido pelo
usuário é executado.
. Framework de Infra-estrutura de Sistema: arquitetura que simplifica a construção
de infra-estrutura de sistemas eficientes e portáteis, tais como sistemas operacionais e
40
interfaces de usário. Eles, de forma geral, são usados internamente nas organizações
desenvolvedoras de software e não são vendidos a clientes diretamente.[FAYAD, 1997]
. Framework de Middleware4: consiste em uma arquitetura que descreve um conjunto
integrado de componentes, os quais oferecem serviços específicos, que são comumente usados
em aplicações distribuídas pertencentes a uma determinada família de aplicações. São
projetados para aumentar a capacidade dos desenvolvedores de modularizar, reusar e extender
suas infra-estuturas de software a trabalharem, de forma incomparável, num ambiente
distribuído. Como exemplo, pode-se pensar num framework que oferece serviços para
aplicações de telecomunicações, como autenticação de usuários, controle de sessão,
gerenciamento de conexão e de configuração de recursos. Esses serviços podem ser reusados
por aplicações, como de multi-conferência, que são construídas em cima desse framework
middleware. Nesse tipo, em contraste com os de aplicação, o desenvolver precisa prover o
projeto de alto-nível do sistema e escrever os fluxos de controle principal e de informação
entre os elementos do framework.
A tenologia CORBA (Common Object Request Broker Architecture) é um padrão de
arquitetura de middleware, definido pelo Object Management Group (OMG), que é um
consórcio de mais de setecentas organizações, incluindo indústrias de software como Sun, HP,
IBM e Rational.
DCOM (Distributed Component Object Model) consiste também num framework
middleware desenvolvido pela Microsoft, representando uma alternativa para o CORBA. O
DCOM é uma versão extendida do Modelo de Objetos Componentes (COM - Component
Object Model), também da Microsoft. Eles se diferenciam pelo fato de que componentes
COM rodam numa máquina, enquanto componentes DCOM podem estar distribuídos numa
rede.
Pelo crescente uso da tecnologia CORBA e por não ser limitado à plataforma
Windows, alguns detalhes dessa tecnologia serão apresentados.
3.3.1- Arquitetura CORBA
4
Middleware: denominação do software responsável pela comunicação e/ou interoperabilide de em um ambiente
computacional distribuído. Algumas formas de middleware são Monitores de Transações, como CICS;
Ferramentas de Trabalho em Grupo, como Lotus Notes; Middleware Orientado a Mensagens, como MQSeries;
41
O desenvolvimento de aplicações distribuídas tem aumentado a cada dia. Segundo
[MONTEZ ,1997], a importância de sistemas distribuídos também tem se tornado cada vez
maior devido, principalmente, a tendências organizacionais, tais como, downsizing, que
demandam o intercâmbio de informação dentro da própria organização e entre organizações
cooperantes.
Esses sistemas apresentam várias vantagens advindas da distribuição, tais como,
disponibilidade, desempenho e otimização de custos. No entanto, apresentam características
que precisam ser controlados, tais como, concorrência, afastamento, heterogeneidade,
assincronismo e mobilidade.
Para o controle dessas características, são impostas algumas condições de estrutura e
funcionamento das arquiteturas dos sistemas distribuídos. A característica de heterogeneidade,
por exemplo, impõe a necessidade de especificações abertas, com interfaces padronizadas e
públicas, levando ao desenvolvimento de middlewares abertos5. Esse tipo de sistemas permite
uma crescente interoperabilidade, escalabilidade e portabilidade, permitindo sistemas
diferentes conviverem juntos e software desenvolvido em uma plataforma poder executar em
outra com adaptações mínimas.
Com o objetivo de apresentar conceitos e especificações que tragam soluções para
lidar com essas características, vários modelos e arquiteturas distribuídas vêm sendo
desenvolvidas. A OMG, já citada na seção anterior, apresentou a arquitetura CORBA como
solução para o desenvolvimento de sistemas baseados em ambientes distribuídos
heterogêneos, de forma a aproveitar todos as vantagens da distribuição e ao mesmo tempo
tentar neutralizar os efeitos causados pelas características acima citadas, e com isso, alcançar
características de reusabilidade, portabilidade e interoperabilidade
A arquitetura CORBA especifica um middleware aberto composto de objetos
distribuídos. Esses objetos são empacotados como componentes binários que clientes remotos
podem acessar via invocação de métodos. De fato, os objetos são abstrações, sendo visíveis
através de seus métodos, que são definidos por uma interface. Invocações a essas operações
ocorrem através de referências ao objeto.
SGBDs, como Oracle e Sybase e ORBs, como Orbix, Visibroker e DCOM.

5
O conceito de sistemas abertos aborda um significante leque de tecnologias e especificações, envolvendo a
questão de interoperabilidade de uma variedade de sistemas baseados em padrões formais ou de facto. De
forma diversa aos ambientes proprietários, ambientes de sistemas abertos permitem aos usuários escolherem de
um vasto grupo de computadores e tecnologias, quais se adequam mais as suas necessidades[MONTEZ ,1997].
42
CORBA possui quatro elementos principais:
• ORB (Object Request Broker) é o middleware responsável por todos os

mecanismos básicos requeridos para encontrar o objeto, preparar a implementação de objeto
para receber a requisição, e executar a requisição. O objeto cliente vê a requisição de forma
independente de onde o objeto servidor esteja localizado, qual linguagem de programação ele
foi implementado, ou qualquer outro aspecto que não esteja refletido na interface do objeto. O
ORB é o elemento principal da arquitetura.
• Serviços de Objetos são coleções de serviços (interfaces e objetos) que suportam

funções básicas para usar e implementar objetos. São serviços necessários para que todas as
tarefas de interoperabilidade entre os objetos sejam executadas, pois o ORB só oferece os
mecanismos básicos. A OMG está padronizando-os para que objetos de aplicação possam
utilizá-los. Exemplos: serviços de nomes (localização de objetos), de controle de
concorrência, de eventos, de mercado(publicação de serviços que os objetos estão dispostos a
realizar e oferta de trabalho para outros objetos), entre outros.
• Facilidades Comuns são coleções de serviços que muitas aplicações de usuários
finais podem compartilhar, mas que não são tão fundamentais como os serviços de objetos.
Exemplos: interface de usuários, gerenciamento de sistemas, tarefas e informação.
• Objetos de Aplicação correspondem a objetos específicos para aplicações de
usuários finais que, por esse motivo, não são padronizados pelo OMG.
Figura 3.1 - Arquitetura CORBA
43
A interação de objetos clientes e servidores com o ORB é feita através de interfaces
dos objetos de aplicação, que são definidas usando a Linguagem de Definição de Interfaces da
OMG (IDL - Interface Definition Language). A interface IDL define os métodos e
parâmetros. É importante ressaltar que a IDL é apenas uma linguagem declarativa, ou seja, os
objetos podem ser implementados em qualquer linguagem de programação. Na verdade,
existe uma restrição para essas linguagens, pois deve ser uma para qual exista um
mapeamento dos conceitos da IDL. No entanto, isso não é um problema, pois já existe
mapeamento para as linguagens mais populares, tais como C, C++, Java, COBOL, Ada,
Smalltalk e Lisp.
A arquitetura CORBA possui outros elementos mais complexos, mas o detalhamento
da tecnolgia está fora do escopo desse trabalho, e assim, espera-se ter alcançado o objetivo de
se ilustrar um framework através de uma especificação que vem sendo amplamente usada por
várias organizações.
3.4 - Desenvolvimento Baseado em Componentes
O desenvolvimento de sistemas baseado em componentes consiste na técnica de

construção de sistemas a partir da montagem de componentes de software pré-existentes. Para
desenvolver esse assunto, faz-se importante se fixar nos conceitos e idéias relacionadas a
componentes.
Quando se pensa em componentes, dois conceitos chaves devem estar bem claros:
• Componentes são unidades de programa modulares e reusáveis, ou seja, são
unidades de implementação e não lógicas;
• Componentes são reusados através de interfaces claramente definidas,
disponibilizadas pelos desenvolvedores dos componentes;
Esses dois conceitos ressaltam características importantes de qualquer componente:
sua modularidade, reusabilidade e interfaces.
Modularidade do Componente
Um componente é modular, ou auto-contido, porque desempenha uma tarefa isolada
ou discreta ou um conjunto de tarefas relacionadas. Por exemplo, um componente que
44
representa um botão na tela pode gerenciar sua aparência e as condições de seus estados, tratar
interações de usuários e retornar resultados.
O isolamento de tarefas traz uma vantagem: condições de erros específicos podem ser
identificadas e tratadas mais facilmente dentro dos componentes. No momento da construção
da lógica geral das aplicações não é necessário se preocupar com identificação e tratamento de
erros, o que facilita a manutenção e extensão da aplicação.
Reusabilidade do Componente
Um componente é reusável porque desempenha tarefas genéricas e cuidadosamente
definidas, que podem ser aplicadas de formas similares entre aplicações. Ele é desenvolvido
com um objetivo específico, mas para qualquer aplicação que tenha esse objetivo. Voltando
ao exemplo do componente botão, ele se comporta do mesmo modo em qualquer aplicação
que ele for empregado. Por exemplo, um usuário pode clicá-lo para obter uma ação e o botão
responder executando a ação definida para ele no momento em que foi projetado.
Assim, ao se escrever um componente, deve-se ter o cuidado de projetá-lo procurando
atender a requisitos comuns de uma variedade de aplicações de um domínio específico. Isso
significa identificar comportamentos comuns dentre as aplicações. Esses comportamentos
serão expostos através de interfaces.
Segundo [KIRBY, 1999], existem algumas técnicas para se projetar um componente
que facilitam o reuso de uma determinada função dentro do próprio sistema, que são:
• Procure por comportamento comum que existe em mais de um lugar no sistema.
• Tente generalizar o comportamento tal que ele seja reusável.
• Planeje interfaces de fachada6 controladoras, que farão uso de componentes
generalizados.
No entanto, deve-se estar atento para não se construir soluções que são reusáveis, mas
que não significam nada. O projeto de uma solução que é reusável requer mantê-la o mais
simples possível. Se o componente for muito complicado, uma destas duas coisas vai
acontecer: ele vai se tornar inútil ou apenas uma parte dele será reusado, porque o componente
terá sido projetado para tratar muito mais coisas do que o consumidor realmente precisa.
6
Interface de fachada é um tipo de interface que passa controle para outra. Ela provê muitos dos seus serviços
consumindo serviços de outra interface. Sua especificação não indica para quem a consome que existe outra
interface sendo consumida.
45
Interface do Componente
Como mencionado anteriormente, uma aplicação se comunica com o componente
através de uma interface claramente definida. A interface define como o componente recebe
informações e qual resultado ele retorna. Quando um componente pré-existente é reusado, o
seu consumidor só precisa conhecer sua interface, e não, o seu funcionamento interno. Assim,
se a interface não for alterada, a implementação do componente pode ser mudada sem atingir
as aplicações que o usam.
A interface de um componente representa pontos de entrada sofisticados que oferecem
elementos de tempo de projeto e de execução. Elementos de projeto permitem que haja
customização de aspectos do componente quanto à aparência e comportamento durante o
desenvolvimento da aplicação. Os de execução habilitam a aplicação a interagir com o
componente, em resposta tanto a ações de iniciativa do usuário como certas condições pré-
determinadas da aplicação, configuradas em tempo de projeto [NETSCAPE, 1998].
Uma interface geralmente possui três elementos: suas propriedades, métodos e
eventos.
- Propriedades
São como variáveis na visão dos desenvolvedores de aplicação. Elas podem ter
seus valores setados e lidos como variáveis de funções, mas elas são mais poderosas
que variáveis por dois motivos [NETSCAPE, 1998]:
. Seus valores podem ser configurados em tempo de projeto: diferentes de
métodos que só estão disponíveis em tempo de execução, propriedades permitem
que componentes sejam customizados enquanto se constrói a aplicação.
. Propriedades podem esconder detalhes de implementação: através de
propriedades os desenvolvedores de componentes podem atachar efeitos
complexos para atribuições exteriormente simples. O que parece uma atribuição
a uma variável pode ser uma chamada para um método que implementa um
processamento elaborado.
- Métodos
Um método é um elemento de execução da interface. Eles operam sobre dados do
componente e são usados para que o componente desempenhe uma ação ou retorne um
valor ainda não armazenado nas suas propriedades. Métodos executam código, assim
só estão disponíveis em tempo de execução. Segundo [NETSCAPE, 1998], eles são
46
úteis porque:
. Encapsulam a funcionalidade de um componente no mesmo objeto em que os
dados residem.
. Podem esconder procedimentos complexos sob interfaces simples e consistentes.
Uma chamada a um método pode ser feita sem que se saiba como ele funciona.
. Permitem atualizar várias propriedades com uma simples chamada.
- Eventos
São métodos especiais que ligam um componente com uma aplicação que o está
usando. Eventos mandam informações ou requisições de uma instância do componente
para a aplicação.
Tratadores de eventos podem desempenhar dois tipos de ações, internas e externas.
As internas são as mesmas para todas as instâncias do componente, enquanto as
externas são diferentes por aplicação ou até mesmo por invocação dentro de uma
aplicação. Por exemplo, supondo que uma aplicação instancie dois botões. A ação
interna de cada botão em resposta ao evento onClick pode ser mostrá-lo,
momentaneamente, no seu estado de visitado antes de remostrá-lo no seu estado
normal. A ação externa desse evento para um dos botões pode ser a chamada a uma
rotina que submete os dados correntes, que estão num formulário, para um banco de
dados; para o outro pode ser fechar a aplicação.
Com se pode ver a técnica de desenvolvimento baseado em componentes representa

uma poderosa técnica de reuso. Ela traz muitos benefícios, sendo o mais visível referente à
melhoria no desenvolvimento de software, fundamentalmente por reduzir a quantidade de
código a ser escrito pelo desenvolvedor. A tabela 3.1 apresenta alguns benefícios em se
usar componentes nas visões da Tecnologia da Informação (TI) e do negócio como um
todo, apresentada em [ORACLE, 1999].
47
Tabela 3.1
Benefícios do uso de componentes

Benefício Benefícios para a TI Benefícios para o Negócio
Reusabilidade Aumento de produtividade Cumprimento de prazos de
para a TI através do reuso, entrega exigidos pelo
não apenas de código, mas mercado.
também de interfaces. Redução de custos.
Proteção e capitalização de
Reuso de código legado investimentos em ativos
através de empacotamento. legados.
Manutenabilidade Problemas de software são Redução de custos com
localizados. manutenção.
Claridade Uma especificação rigorosa Consistência corporativa e
da interface permite a desenvolvimento de capital
aplicação de técnicas de intelectual.
certificação e autenticação
para garantir o uso de
interface correta.
Capacidade de Substituição Diferentes implementações Redução de custos em
para os componentes podem migrações para tecnologias
substituir outras anteriormente futuras.
aplicadas, caso não se altere a
interface, sem causar
alterações na aplicação que os
estão usando.
Interoperabilidade Independência de sistemas Exploração dos benefícios
integradores para implementar trazidos pelas novas
soluções híbridas. tecnologias para o negócio,
tal como comércio eletrônico.
Robustez Componentes usados em Redução de custos.
vários sistemas por diferentes
desenvolvedores, ganham Entrega de produtos de maior
48
Benefício Benefícios para a TI Benefícios para o Negócio
credibilidade , pois já foram qualidade.
testados anteriormente.
Menos tempo gasto para testar

as novas aplicações.
Adaptabilidade Sistema é facilmente Resposta a mudanças
extensível e adaptável para fundamentais de negócio,
atender a novos requisitos. como fusões e mudança de
diretoria.
Performance Instalação flexível em um Habilidade de atender
único ou múltiplos nodos, eficientemente as
permitindo melhorias com necessidades de negócio em
respeito à disponibilidade e horários de rush, quando o
tempo de resposta. volume de transações possui
carga máxima.
Apesar de todos esses benefícios, o desenvolvimento baseado em componente requer

certas habilidades técnicas e de gerenciamento por parte dos projetistas de sistemas para
executar a integração dos componentes. De fato, a integração consiste no maior esforço para
esse tipo de desenvolvimento. Isso ocorre porque os responsáveis por ela só podem contar
com a documentação disponível do componente como fonte de informações quanto ao
comportamento e propriedades do mesmo.
Componentes aderem a especificações definidas nos chamados modelos de
componentes. Nesses modelos, se especifica as interfaces, como as propriedades, eventos e
métodos serão expostos e convenções que uma classe deve atender para se transformar num
componente do modelo.
Existe alguns modelos disponíveis no mercado e são conhecidos como tecnologias de
componentização. Como exemplo, pode-se citar Active X, JavaBeans (JB)e Enterprise Java
Beans (EJB).
3.4.1 - Active X
Active X é a solução da Microsoft para componentes reusáveis. Ela é construída em

cima da estrutura COM, citada na seção de framework, também da Microsoft. Essa estrutura
permite o desenvolvimento de componentes reusáveis, escritos em diferentes linguagens e que
podem ser compartilhados entre si para construir aplicações maiores e mais complexas.
49
Objetos Active X podem expor suas interfaces em tempo de execução e permitem que
outros objetos invoquem os métodos dessas interfaces após esse conhecimento. Na verdade,
objetos Active X podem apresentar dois tipos de interface: v-table e dispatch.
O nome v-table deriva do mecanismo da linguagem C++ para implementar funções
virtuais, representa resumidamente tabela de função virtual. Essas interfaces são mais úteis
quando os objetos usados estão escritos na linguagem C++, apesar de outras linguagens
poderem utilizar esse tipo de interface. Elas consistem em interfaces que são vinculadas ao
componente em tempo de compilação e são mais rápidas em tempo de execução.
As interfaces dispatch são vinculadas ao componente em tempo de execução.
Programas que usam objetos Active X através de interfaces desse tipo podem criar o objeto no
tempo de execução e requisitar suas interfaces programaticamente. Elas são mais lentas em
tempo de execução, uma vez que se faz necessário uma certo número de negociações a cada
chamada de função. No entanto, a grande vantagem de se usar esse tipo de interface é o fato
de facilitarem a atualização de componentes, adicionando novas funções e propriedades, sem
que seja necessário recompilar os programas que dependem dela.
Para utilizar um objeto Active X , especialmente quando é associado em tempo de
execução a outro objeto, faz-se necessário instalá-lo no computador onde ele irá rodar. Essa
instalação, tipicamente, significa copiar o arquivo de extensão DLL, EXE ou OCX para o
disco rígido e adicionar algumas entradas no registro do Windows. No caso dos objetos
dependerem de outros objetos Active X ou DLLs (Dynamic Link Library) é preciso que esses
últimos também sejam instalados.
Em aplicações Web, componentes Active X podem ser usados para fazerem duas
coisas: incrementar interfaces de usuário e implementar lógica de negócio. Eles geralmente
são usados como controladores de interface de usuário. Componentes Active X ou
controladores podem capturar as entradas do usuário em situações difíceis de se fazer isso,
como caixas de texto padrão e listas de seleção.
Uma característica chave que torna objetos Active X cabíveis para a Web é que os
componentes podem ser baixados automaticamente quando necessários. Lembrando, esses
componentes geralmente são módulos de programa instalados no computador cliente. Eles
podem ser invocados e usados por navegadores Web e outros programas.
50
3.4.2 - JavaBeans
JavaBeans consiste no modelo de componentes padrão desenvolvido para construção
de componentes em Java, que podem ser manipulados visualmente por uma ferramenta de
construção de aplicações [SUN 1997]. Um componente que adere à especificação JavaBeans
é conhecido como bean. Eles podem ser visuais (ex. botão com comportamento especial,
gráficos) ou não visuais(ex. timer), mas esses últimos ainda podem ser manipulados
visualmente, usando ferramentas de construção.
Interações com beans ocorrem em três níveis: propriedades, métodos e eventos.
Propriedades definem as características do bean e possibilitam a configuração de sua
aparência e comportamentos. Elas podem ser acessadas (lidas ou escritas) através de métodos
públicos do bean, visualmente em janelas apropriadas da ferramenta de desenvolvimento ou
recuperando o estado do bean tornado persistente.
Métodos são exportados e definem o que pode ser feito com o bean. São usados para
ler e escrever o valor de uma propriedade em particular. Eles podem ser invocados por outros
componentes. Por default, métodos públicos de um bean vão ser exportados, mas pode-se
escolher para exportar apenas um subconjunto de seus métodos públicos.
Eventos provêem um meio de componentes se comunicarem com outros sobre a
ocorrência de algo que os interessa.
Como se pode notar esses conceitos estão de acordo com os apresentados quando se
definiu os elementos de uma interface do componente.
Todo bean apresenta as seguintes características:
1) Gerência de Propriedades e Customizações: responsáveis por todas as

interações associadas com propriedades. As propriedades podem ser vinculadas –
notificam uma parte interessada (applet7, bean, aplicação) conforme alterações no
seu valor – ou validadas – permitem uma parte interessada validar o novo valor da
propriedade antes de aceitar a modificação.
2) Introspecção: mecanismo pelo qual componentes tornam sua estrutura

interna disponível externamente, e assim, se consegue descobrir as características
7
Applets são aplicações gráficas escritas em Java que rodam em um navegador.
51
dos componentes em tempo de execução. A identificação da estrutura é possível
através da adoção de padrões (convenções) para nomes de métodos e assinaturas.
Esse serviço é projetado para as ferramentas de desenvolvimento, que irão
funcionar como “introspector”. As ferramentas podem indagar o bean quanto as
suas propriedades e comportamento. A introspecção pode ser dividida em duas
partes, baixo nível (acesso completo à estrutura interna do bean) e alto nível
(acesso limitado à estrutura interna, geralmente apenas métodos e propriedades
públicas).
3) Tratamento de Eventos: o projeto de um modelo de eventos torna-se

necessário para se definir as interações entre os componentes e a aplicação. Um
modelo de eventos é baseada nos conceitos de fontes e receptores de eventos. Os
primeiros são os beans geradores de evento, que ao gerar um, ativa um método do
receptor, aplicação ou outro bean capaz de responder ao evento. Para responder ao
evento, o receptor precisa se registrar como interessado. Fontes de evento podem
ser unicast ou multicast. Nas primeiras, apenas um receptor pode se registrar e nas
outras, múltiplos receptores são suportados.
4) Persistência: já que um bean deve ser customizável, é imprescindível que

se possa armazenar e recuperar as informações referentes ao seu estado interno e
aparência(valores customizados). O mecanismo mais usado para isso é o de
serialização padrão de Java, ou seja, um bean deve implementar a interface
Serializable. Ocorre o armazenamento e restauração de todas as propriedades
públicas, algumas propriedades internas, dependendo do bean, no entanto não se
armazena referências para beans externos e registros referentes a eventos. Também
pode ser usado serviços de empacotamento (arquivos JAR) e distribuição de beans
para torná-lo persistente.
5) Suporte para Ferramentas de Desenvolvimento: todo bean deve apresentar

facilidades necessárias para editar e manipular beans com ferramentas de
programação visual. Essas facilidades são necessárias apenas em tempo de
programação. Um exemplo consiste na folha de propriedades (property sheet) –
interface visual com editores para as propriedades públicas, cada tipo de
52
propriedade exportada deve ter um editor associado.
3.4.3 - Enterprise JavaBeans (EJB)
Enterprise JavaBeans é o modelo(ou arquitetura) de componentes para a plataforma

Java, onde os componentes são destinados a executar no lado servidor da aplicação. Tem
como objetivo facilitar a construção de aplicações de negócio críticas, orientadas a objetos
distribuídos, seguras e escaláveis, abstraindo para os desenvolvedores os detalhes de baixo
nível. Desta forma, o desenvolvedor pode focar apenas em escrever a lógica do negócio, que
corresponde aos componentes.
Essa arquitetura define uma estrutura que trata todas as tarefas de programação ao
nível de sistema, como monitoração de transações, segurança, criação de processos,
nomeação, ciclo de vida de objetos, acesso remoto e persistência. Ainda, define as
responsabilidades de clientes, servidores e componentes.
A característica chave da tecnologia EJB é o suporte que ela oferece para transações
distribuídas, tendo em vista que escrever aplicações transacionais consiste em uma das tarefas
mais complexas que o desenvolvedor de aplicações tem que executar.
Outra característica importante consiste em EJB ser neutro em relação ao protocolo de
comunicação de objetos, usado para a chamada de métodos remotos. Isso traz o benefício do
programador ter a liberdade de implementar a parte cliente da aplicação usando o protocolo de
sua preferência. Além disso, permite que construtores de servidores EJB8 possam implementar
protocolos que são mais importantes para a base de seus compradores. Por exemplo, um
vendedor ORB pode implementar apenas os protocolos CORBA, enquanto um provedor de
sistema UNIX pode escolher RMI e CORBA. Em qualquer caso, isso é transparente para o
desenvolvedor de bean já que escreve apenas para a plataforma Java.
A plataforma Java traz, ainda, o benefício de que uma aplicação baseada em bean, uma
vez escrita, pode rodar em qualquer lugar onde o servidor EJB da empresa esteja rodando.
Existem dois tipos de componentes EJB:
- Beans de sessão: são objetos que representam uma conversação transiente
com um cliente, executam leituras e escritas em banco de dados para esse cliente.
8
Esse termo será explicado mais adiante.
53
Os atributos de um bean desse tipo contém o estado da conversação, e assim,
esses componentes são transientes9. Quando ocorre alguma falha tanto no cliente
como no servidor, eles são destruídos.
- Beans de entidade: representam dados armazenados em um banco de
dados, juntamente com os métodos que agem sobre esses dados. Consistem em
componentes persistentes, pois são participantes de transações e existem
enquanto o dado permanecer no banco. Num contexto de banco de dados
relacional, para cada linha de uma tabela existe um bean associado. Falhas no
servidor são transparentes ao cliente.
Para se entender a arquitetura de componentes Enterprise JavaBeans (Figura 3.2), faz-

se importante o conhecimento de alguns termos, que representam elementos participantes
dessa estrutura. À medida que esses termos forem sendo explicados, deseja-se que a
arquitetura EJB seja compreendida.
Figura 3.2 - Arquitetura da Tecnologia EJB
Cliente: não precisa ser escrito em linguagem Java, pois a especificação EJB não
obriga nenhum protocolo de ligação de objetos remotos, permitindo que o servidor
suporte múltiplos protocolos como RMI, IIOP (CORBA) e DCOM. Já que o cliente
enxerga um bean como um objeto remoto, ele não necessita usar um protocolo
específico para se comunicar com os beans, que se encontram dentro de um container.
9
Componentes transientes são componentes não-persistentes.
54
O cliente se comunica com um bean através das interfaces home e remota, que serão
explicadas posteriormente.
Servidor EJB: consiste numa coleção de serviços que implementa detalhes de baixo
nível, como o gerenciamento de transações e de objetos distribuídos, invocações
distribuídas a métodos desses objetos, entre outros serviços de baixo nível do sistema.
Resumidamente, o servidor EJB gerencia os recursos necessários para suportar os
componentes EJB. Os provedores de servidores podem prover a implementação de um
container e também podem prover API para vendedores terceiros acoplar novos
containers EJB.
Container EJB: onde os componentes (beans) são armazenados e executados. Pode
existir mais de uma instância de um bean no container. É responsável pela criação e
destruição dessas instâncias. Oferece serviços para os componentes e a interação entre
ele e os componentes é feita através de um conjunto definido de interfaces. É
transparente para o cliente.
Interface Home: uma das interfaces que o container implementa quando um
componente é instalado nele. Define um contrato entre eles, que consiste em uma lista
de métodos para localização, criação, remoção de instâncias de beans e
questionamento de informações ou metadados a respeito do bean.
Interface Remota: outra interface implementada ao se instalar um componente.
Consiste numa lista de métodos de negócio de um bean disponibilizadas para o cliente.
O objeto EJB é quem implementa essa interface, e não o bean. O objeto EJB serve
como um proxy, interceptando as invocações a objetos remotos e chamando os
métodos apropriados na instância do bean [Roth, 1999].
3.5 – Vantagens e Desvantagens
Após descrito algumas das tecnologias de reuso existentes, vale ressaltar que não
existe uma melhor do que a outra. Cada uma delas apresenta suas vantagens e desvantagens, e
seu uso se tornará mais adequadas de acordo com o tipo e contexto de desenvolvimento da
aplicação, além do nível de conhecimento da equipe de desenvolvimento. Pode-se, assim,
apresentar um quadro comparativo entre elas, sugerido por [EZRAN et. al., 1999], mostrando
as vantagens e desvantagens de cada uma (Tabela 3.2).
55
Tabela 3.2
Comparação entre a Técnicas

Técnica Vantagens Desvantagens
TOO Aumenta a modularidade e Requer um esforço
abstração de informação. significativo para
modelagem.
Padrões de Projeto Facilita a recuperação de Implementação parte do
soluções de projeto, provê zero.
um guia para o processo de
desenvolvimento.
Frameworks Representam aplicações Requer perícia e
semi-completas de um conhecimento profundo
domínio específico para do projeto do
serem customizadas. framework.
Permite o reuso do modelo
de objeto mais arquitetura.
Componentes Especialização técnica e do Apenas aspectos de
domínio da aplicação. aparência são
Permite desenvolver um customizáveis.
mercado consumidor
externo.
Nesse capítulo foram apresentadas as principais técnicas desenvolvidas para a

realização e maximização do reuso. As técnicas apresentadas foram: Técnicas Orientadas a
Objeto, Padrões de Projeto, Frameworks e Desenvolvimento Baseado em Componentes.
Na apresentação das técnicas orientadas a objeto, mostrou-se sua importância como
um meio de se alcançar sistemas mais modularizados e mais simples de se entender. Essas
facilidades decorrem de fatores como os sistemas serem modelados de forma a abstrair os
detalhes de implementação, descrevendo e representando o sistema da mesma forma como são
percebidos.
Com a apresentação de padrões de projeto, mostrou-se a possibilidade de reusar
experiências de peritos e soluções alcançadas para problemas comuns em sistemas orientados
a objeto. Além disso, foi descrito os principais elementos que a descrição de um padrão de
projeto deveria apresentar .
Os frameworks foram apresentados como uma forma de facilitar a construção de um
sistema como um todo, pois consiste numa aplicação semi-completa, cujos elementos
56
precisam ser customizados para atender às necessidades específicas do cliente. Mostrou-se
que frameworks representam o ponto de partida para a construção de aplicações,
possibilitando não mais se partir do zero. Como exemplo do que existe no mercado foi
apresentada a arquitetura CORBA.
Por último se apresentou a técnica de desenvolvimento baseado em componentes, que
representa a possibilidade de se construir sistemas a partir de componentes preexistentes. Para
usar esses componentes basta conhecer as interfaces que eles implementam. No entanto,
verificou-se que customizações só podem ser realizadas ao nível de aparência externa do
componente, nenhuma adaptação pode ser feita na sua implementação. Como exemplo dessa
técnica foram apresentadas as tecnologias ActiveX , JavaBeans e Enterprise JavaBeans.
Nesse capítulo, procurou-se esclarecer a possibilidade de ocorrer reuso em qualquer
fase do desenvolvimento. Além disso, percebeu-se que existem várias alternativas para
colocá-lo em prática, algumas mais simples, outras mais complexas. A escolha de qual
tecnologia está relacionada ao tipo de aplicação, contexto em que ela está sendo desenvolvida
e o nível da equipe de desenvolvimento.
No próximo capítulo, serão discutidos aspectos relacionados aos repositórios de
componentes. Um repositório de componente consiste de uma forma eficiente, quando bem
empregada, para se alcançar o reuso dentro de uma empresa.
57
Capítulo 4
Repositório: Reutilização de Componentes
Em virtude da importância do reuso nos processos de desenvolvimento e do crescente

aumento da disponibilidade dos ativos de software, pesquisadores e profissionais se
depararam com o problema do armazenamento e recuperação desses ativos. Observou-se que
para melhor se obter os benefícios do reuso era necessário, sobretudo, que esses ativos
pudessem ser facilmente identificados e recuperados dentro de um repositório.
Este capítulo apresenta uma análise das principais características de um repositório e
dos produtos disponíveis no mercado com o objetivo de expor os aspectos mais importantes a
serem considerados nessa ferramenta de auxílio ao processo de reuso.
4.1 – Introdução
Com a crescente importância atribuída ao reuso de software e informações, muito se

tem discutido a respeito da organização e centralização desses valores. O repositório surge
como uma solução para se resolver um paradoxo observado nas organizações: sabe-se que o
compartilhamento de experiências e informações pode proporcionar grandes vantagens
competitivas, entretanto muitas empresas ficam impossibilitadas de aproveitar tais benefícios
porque não conseguem lidar com a variedade e a distribuição ineficiente das informações
desejadas e, muitas vezes, sequer têm conhecimento das informações disponíveis.
Segundo [EZRAN et al., 1999] as empresas que não fazem uso de um repositório
geralmente não sabem o que têm, quando sabem, não conseguem encontrar o que desejam e,
provavelmente, quando encontram, percebem que não era o que estavam procurando.
O termo repositório pode ser utilizado para diversos propósitos. Entre eles destacam-
se:
1- Armazenamento de modelos – um processo de desenvolvimento envolve a
geração de vários artefatos que normalmente são armazenados em locais diferentes.
58
Um repositório possibilita a centralização do armazenamento desses artefatos e o
controle de cada uma das suas versões.
2- Integração de ferramentas – muitas vezes os modelos gerados durante um
processo de desenvolvimento originam-se de ferramentas distintas. Assim, para a
troca de informações entre elas é necessário que haja uma “linguagem” comum
através da qual as mesmas possam se comunicar. O repositório pode servir para um
armazenamento temporário e para a intermediação entre as ferramentas, ou seja,
pode transformar o modelo de entrada de uma delas num modelo compatível para a
outra.
3- Manutenção de sistemas legados – um repositório pode ser útil também para
o armazenamento de dados relacionados a sistemas antigos. Esses dados podem
posteriormente ser analisados para se determinar os possíveis impactos gerados por
modificações.
Analisadas tais funcionalidades, observa-se que o repositório é utilizado para o

armazenamento de metadados. Essa restrição, conforme destaca [BABCOCK, 1998] é o que
os diferenciam dos banco de dados.
Para o propósito deste trabalho, um repositório será considerado como o local onde os
ativos de software estarão armazenados e classificados de modo a facilitar a correta utilização
e recuperação dos mesmos. Assim, baseado no modelo de ativo apresentado no capítulo 2
pode-se representar o modelo de um repositório conforme apresentado na figura 4.1:
59
Repos itório
C atálogo Ativo
Des c rição Corpo
Figura 4.1 - Um modelo de repositório
O modelo da figura 4.1 indica que é um repositório é composto por uma coleção de
ativos juntamente com um catálogo que apresenta as descrições desses elementos. Cada um
desses ativos é formado por um corpo e uma descrição conforme apresentado anteriormente.
Adaptações desse modelo podem ser aplicadas de acordo com a necessidade
identificadas para cada situação.
As vantagens proporcionadas por um repositório num processo de reuso são
compartilhadas por todos os pesquisadores da área. Há, entretanto, uma divergência no modo
de utilização do repositório. O modo mais comum corresponde à formulação de parâmetros
para pesquisa que são submetidos ao repositório e, como consequência, obtém-se um conjunto
de ativos que satisfaçam tais parâmetros. Uma outra abordagem, adotada por [YE, 199? ],
defende não ser eficiente a formulação da pesquisa pelo usuário formule pesquisas. Para ele,
as intenções do usuário raramente são mapeadas em parâmetros adequados para uma pesquisa
eficiente. Com isso, propõe que, integrado ao ambiente de desenvolvimento, exista uma
ferramenta capaz de capturar informações desse ambiente e, após uma análise, sugerir alguns
componentes que se adequem ao que o usuário está fazendo.
Conforme mencionado anteriormente, o que se tem observado é que para se obter os
reais benefícios do reuso não basta apenas tomar conhecimento de suas vantagens. Ele deve
ser incentivado e, principalmente, praticado. A mesma observação pode ser aplicada para o
uso de um repositório. Para que o mesmo possa auxiliar no processo de reuso é de
60
fundamental importância o treinamento e a prática da sua utilização de modo a familiarizar os
usuários com as funcionalidades disponíveis e as características presentes para a pesquisa.
Isso torna possível a rápida localização dos ativos adequados e a consequente minimização
do tempo de desenvolvimento.
4.2- Características de um Repositório
Conforme visto anteriormente, as principais funcionalidades de um repositório são as

pesquisas e a recuperação dos ativos de software. No entanto, a presença de algumas outras
funcionalidades pode facilitar e, com isso, incentivar a sua utilização. Conforme proposto por
[EZRAN et al., 1999], serão apresentadas, a seguir, algumas das principais funções que um
repositório pode disponibilizar a seus usuários. Vale ressaltar que essas funções não são
obrigatórias e variam dependendo do contexto no qual ele está inserido e das necessidades da
organização ao utilizar um repositório [EZRAN et al., 1999].
- Identificação e descrição: para se descrever um ativo é possível que a ele seja

atribuído um conjunto de características tais como, nome, domínio, palavras-chave,
dentre outras que os identificam e os diferenciam dos demais ativos que compõem esse
mesmo repositório. Para cada um dos ativos armazenados deve ser possível identificá-
lo homogeneamente dentro de um repositório, ou seja, os ativos de um mesmo tipo
devem apresentar o mesmo conjunto de características. Isso não significa, contudo, que
ativos diferentes devam ter o mesmos valores para esse conjunto de características.
- Inserção: um repositório deve permitir que usuários autorizados insiram novos
ativos ou, ainda, novas versões dos mesmos. A inserção significa adicionar ao
repositório o corpo e a descrição do ativo, conforme apresentado no capítulo dois.
- Exploração do catálogo: aos usuários de um repositório deve ser permitido que
explorem o catálogo de ativos para que possam conhecer e analisar as características
dos ativos disponíveis. Essa funcionalidade torna-se suficiente para localizar ativos
desejados quando o repositório possui uma pequena quantidade desses (normalmente
em torno de dez) [EZRAN et al., 1999].
- Pesquisa textual: um repositório deve permitir que seus usuários façam pesquisas
61
mais específicas na descrição dos ativos. Como resultado da pesquisa serão obtidos um
ou mais ativos que satisfaçam as condições desejadas. Observados os resultados, pode-
se decidir por um maior detalhamento ou generalização dos critérios anteriores.
- Recuperação: após a identificação do ativo desejado, um repositório deve permitir
que seus usuários recuperem esse ativo para que possam posteriormente utilizá-lo num
processo de reuso.
- Organização e pesquisa: como visto anteriormente, a funcionalidade de
exploração de catálogos não é suficiente à medida que a quantidade de ativos
disponíveis aumenta. Além disso, a pesquisa textual, muitas vezes, demanda muito
tempo. Devido a esses fatores, alguns repositórios podem adotar novas formas de
organizar as características dos ativos de modo a permitir que a pesquisa no repositório
seja baseada em outros critérios. Dentre os possíveis tipos de organização [EZRAN et
al., 1999] destaca:
1. Palavras-Chave: cada um dos ativos é descrito por um conjunto de
palavras-chave que poderão ser utilizados como critérios de pesquisa.
2. Classificação por facetas: essa classificação permite que sejam
atribuídos aos diversos ativos um conjunto de facetas (atributos) às quais
poderão ser associados diversos valores. Assim, a pesquisa no
repositório poderá ser feita a partir do relacionamento “faceta=valor”.
Por exemplo, pode-se definir para um determinado ativo a faceta
“linguagem de programação” e a ela ser atribuída, durante uma pesquisa,
valores como “Java”, “C++” ou outros. Vale ressaltar que as facetas
também podem ser definidas em forma hierárquica. Assim, conforme
exemplifica [EZRAN et al., 1999], a faceta “linguagem de programação”
pode receber valores como “procedural” ou “orientada a objetos” e, por
sua vez, a faceta “procedural” valores como “Pascal” ou “C”. Como
numa estrutura hierárquica, a pesquisa é feita percorrendo-se toda essa
estrutura. Ao se procurar no repositório por “linguagem de
programação=procedural”, obtém-se o conjunto de ativos que
apresentam, além do atributo “linguagem de programação”, a faceta
“procedural” independentemente do valor a ela atribuído.
3. Thesaurus: um thesaurus é uma organização de diversos sinônimos para
um conjunto de palavras. Ele muitas vezes é utilizado em áreas
62
específicas onde existe um vocabulário bastante especializado. No
contexto do repositório, pode-se observar que determinados ativos estão
relacionados a outros através de uma associação de similaridade ou
identidade. Nesses casos, um thesaurus torna-se bastante útil para a
pesquisa à medida em que permite localizar sinônimos, ou seja, ativos
similares àqueles identificados.
- Histórico: é importante para o gerenciamento de um repositório que ele possa
armazenar informações de uso, modificações, criação e exclusão de cada um dos
ativos disponíveis. Essas informações devem montar uma base histórica que facilitará
a análise e a reutilização dos mesmos. O histórico de uso é particularmente importante,
já que possibilita aos usuários de um determinado ativo analisar diversas informações
sobre a sua utilização tais como, contexto de uso, falhas, práticas de sucesso, dentre
outras . Essas informações muitas vezes servirão como base para se optar pela
reutilização de quaisquer dos ativos. Com isso, muitos autores consideram de extrema
importância que seja difundido pela empresa a cultura de se incluir observações de uso
quando da reutilização de um ativo.
- Mensuração: um repositório pode coletar estatísticas que facilitem o seu
gerenciamento. Algumas das principais estatísticas que podem ser adotadas são:
frequência de acesso ao repositório, quantidade de ativos disponíveis, taxa de
recuperação, porcentagem de pesquisas bem-sucedidas, frequência com que um
determinado ativo é analisado ou modificado, dentre outras.
- Controle de acesso: um repositório pode adotar uma política de segurança para
que determinadas funcionalidades só estejam acessíveis a pessoas autorizadas. Por
exemplo, pode-se definir para uma empresa específica uma política de segurança onde
a pesquisa textual esteja disponível para todos os funcionários, mas a recuperação de
ativos esteja disponível apenas aos funcionários da área de desenvolvimento.
- Gerenciamento de versões: um repositório pode conter várias versões de um
mesmo ativo e, sendo assim, é recomendável que haja algum mecanismo para
controlar essas versões e estabelecer o relacionamento entre elas.
- Controle de modificações: é recomendável que sejam providas algumas
funcionalidades para se fazer o gerenciamento de modificações dos ativos num
repositório. Essas funcionalidades incluem procedimentos para solicitação de
alterações, discussões e permissão para as mesmas. É de extrema importância para a
63
manutenção da consistência de uma repositório que quaisquer intenções de modificar
os ativos sejam comunicadas àquele responsável pela sua administração para que o
mesmo, juntamente com outros responsáveis, possam analisar as alterações solicitadas
e manter a coerência entre os diversos ativos de software.
- Notificação de mudanças: é possível que a qualquer momento um ativo seja
modificado ou, até mesmo, que o próprio repositório sofra algumas alterações em suas
principais funcionalidades. Sendo assim, um repositório pode prover funções que
notifiquem os seus usuários das modificações recentemente ocorridas tais como,
inserção ou exclusão de ativos, alterações em documentos, disponibilização de novas
funcionalidades, novas políticas de segurança, entre outras.
Apresentadas as principais funcionalidades de um repositório faz-se necessário

analisar alguns dos aspectos não-funcionais que o caracterizam. Esses aspectos podem
também, se adequadamente utilizados, possibilitar maiores incentivos para a utilização do
repositório.
- Quantidade: o repositório pode ser único ou pode existir um conjunto deles

[EZRAN et al., 1999]. O único é indicado para organizações pequenas onde não há
uma grande divisão departamental e, assim, os tipos de ativos não são completamente
distintos e são compreendidos por todos os seus usuários. Para organizações maiores
ou geograficamente distribuídas sugere-se o uso de vários repositórios, cada um
relacionado a uma área de atuação da empresa. Nesse caso é importante que haja um
gerenciamento centralizado e eficiente para evitar inconsistência nas duplicações
existentes entre alguns repositórios. A utilização de vários deles é defendida por
aqueles que consideram que informações desnecessárias para um determinado grupo
de usuários, mas de grande valia para um outro, prejudicam e desestimulam a prática
do reuso nas organizações.
- Acesso pela rede: como a maioria das empresas estão migrando seus modelos
computacionais para modelos centralizados, um requisito típico é que o repositório
possa ser acessado de qualquer ponto numa rede [EZRAN et al., 1999]. Isso é
particularmente importante quando seus usuários estão distribuídos geograficamente.
O que normalmente se tem observado na implementação dos repositórios é a utilização
de modelos cliente-servidor em 3 (três) ou mais camadas. No modelo de 3 camadas
64
uma é a responsável pelo armazenamento dos ativos, a outra pelo processamento das
principais funcionalidades do sistema tais como, pesquisa e recuperação e a terceira
corresponde à aplicação cliente, por onde o repositório poderá ser acessado. A
quantidade de camadas é o modo de implementação das mesmas poderão variar entre
as diversas organizações.
4.3 – Gerenciamento
O gerenciamento de ativos representa descobrir, identificar e gerenciar cada ativo

como uma oportunidade de reuso [UREP, 2000]. Conforme apresentado anteriormente muitas
empresas possuem informações espalhadas por toda a organização. Cabe ao gerente de um
repositório identificar aquelas que agregam valores à organização e incluí-las nesse
repositório para que possam ser por todos compartilhadas.
Como o repositório representa uma coleção de ativos é necessário que haja um processo
de gerenciamento para que se possa melhor controlar a quantidade e qualidade de ativos
disponíveis, as suas localizações e as principais características desses elementos. Além disso,
no caso de repositórios não-centralizados é importante que haja um rígido controle para se
evitar inconsistências entre os diversos repositórios existentes.
O controle do catálogos de ativos é uma atividade imprescindível no gerenciamento de
um repositório. Nele poderão ser encontradas referências para cada um dos ativos que o
compõe e que serão fundamentais para a prática do reuso sistematizado. Sua ausência pode ser
a maior contribuição para o caos [EZRAN et al., 1999].
Como se pôde observar o real valor de um repositório está em conseguir localizar aquilo
que se está procurando ou o que se adeque às necessidades do usuário. Assim, o
gerenciamento deve contribuir para manter informações coerentes e adequadas a um
determinado grupo de usuários. Isso inclui, como apresentado na seção anterior, controle de
versões, controle de modificações e classificação adequada de cada um dos ativos disponíveis
num repositório.
Outro ponto importante a ser observado no gerenciamento de um repositório é o
controle de qualidade que deve ser imposto aos ativos que o constituirão. Finalmente, não
basta que os ativos estejam disponíveis e possam ser localizados, mas é necessário, também,
que eles possam ser compreendidos para, com isso, poderem ser reutilizados. Neste ponto
65
destaca-se a importância da definição de padrões para os ativos e o papel dos gerentes na
validação desses padrões.
4.4 – Mercado de Repositórios
Com a crescente motivação para o reuso de ativos de software nos processos de

desenvolvimento, diversas empresas estão investindo na construção de repositórios que
suportem o reuso. Algumas delas desenvolvem seus repositórios para uso interno enquanto
outras produzem-nos com propósitos comerciais. Com base nesse mercado é possível avaliar
os produtos disponíveis e analisar os principais requisitos apresentados na seção anterior.
4.4.1- Repositórios na Internet
Como a Internet tornou-se nos últimos tempos o maior e mais eficiente meio para o
compartilhamento de informações, é esperado que torne-se também uma grande fonte de
reuso para as organizações e desenvolvedores em geral. É possível encontrar por toda a rede
diversos repositórios, sendo a grande maioria deles repositório de componentes de software. A
seguir serão apresentados, juntamente com suas principais características, alguns repositórios
encontrados de domínio público.
ComponentSourceTM (http://www.componentsource.com) – ComponentSource.com é

um mercado de opções destinado àqueles responsáveis por especificar, localizar e obter
componentes de software [CS, 2000]. Esse mercado está aberto, através de uma política
própria, à inserção dos mais diversos componentes independentemente de autores e de
plataforma. O site disponibiliza a seus usuários algumas vantagens, tais como, avaliação
gratuita de versões, suporte técnico, atendimento em vários idiomas, centro de soluções para
construção de componentes e para comércio eletrônico. O catálogo de componentes pode ser
explorado através de categorias, autores ou em ordem alfabética. A pesquisa, realizada através
de palavras-chave, pode ser restringida a um determinado tipo de componente (Java, COM,
Visual Basic, Delphi ou Business). Para cada componente existem informações técnicas de
utilização, preço, compatibilidade, pré-requisitos, licença de uso, descrição, dentre outras.
Developer.com (http://developer.earthweb.com/) – A missão do developer.com é
66
atender às necessidades dos profissionais de tecnologia da informação em todo o mundo
[DEV, 2000]. Os site apresenta material para os mais diversos tipos de tecnologia, entre eles:
ActiveX, ASP, C++, Cobol, Java, JavaScript, XML e muitas outros. Permite-se a inclusão de
novos recursos e a exploração de catálogos pelos tipos de tecnologia existentes. A pesquisa
pode ser feita por palavras-chaves no repositório como um todo ou em algumas seções do site
pré-definidas. Essas pesquisas permitem também que seja especificado um intervalo de tempo
no qual deseja-se fazer a procura. O resultado obtido a partir da exploração por tipos de
tecnologia é, ainda, subdividido em categorias como educação, finanças, jogos, gráficos, etc.
Para cada um dos recursos encontrados há uma breve descrição do mesmo, uma referência
para o autor e um link para a página do produto onde poderão ser encontradas informações
mais detalhadas.
Outros repositórios disponíveis na Internet podem ser encontrados em:
http://www.flashline.com ; http://www.partbank.com/ ;
4.4.2- Outros Repositórios
Conforme citado anteriormente a prática do reuso possibilita a obtenção de benefícios

na produtividade, qualidade, custos, tempo e esforço ao se desenvolver um sistema. Com isso,
muitas organizações desejam manter os ativos por elas desenvolvidos somente para utilização
interna para que possam futuramente ser beneficiadas em suas estratégias de negócio. Isso
impossibilita a divulgação dos mesmos em repositórios de domínio público. Baseadas nessa
necessidade é que diversas empresas estão investindo na construção de repositórios que
sirvam somente aos interesses internos de uma organização. A seguir serão apresentados
alguns desses produtos10.
Microsoft Repository – Esse repositório provê para os ambientes de desenvolvimento
Microsoft um local onde é possível integrar metadados para o desenvolvimento de aplicações
[MSR, 2000]. Assim como nos outros repositórios o maior objetivo dessa tecnologia é
compartilhar informações que facilitem e estimulem a prática do reuso. De modo a permitir a
compreensão dos ativos reusáveis por todos os seus usuários a Microsoft, juntamente com
outras empresas, desenvolveu um padrão para os metadados do repositório chamado de Open
10
As características e funcionalidades dos produtos apresentados foram obtidas através das suas páginas
67
Information Model (OIM). Para a troca de informações entre vários repositórios o formato
adotado pela empresa foi o formato XML Assim, para a comunicação entre eles, todas as
informações presentes na descrição de um ativo, que estão de acordo com o padrão OIM, são
inseridos em elementos pré-definidos de um documento XML. O repositório oferece ainda
funcionalidades como controle de versões, controle dos relacionamento entre ativos e controle
de acesso aos mesmos. Outros tipos de informações sobre o produto podem ser encontradas
em http://msdn.microsoft.com/repository/ .
Unisys Universal Repository - O repositório produzido pela Unisys, também
conhecido como UREP, é um sistema de informação para definir, integrar e gerenciar
metadados e informações de negócio [UREP, 2000]. As principais funcionalidades oferecidas
pelo repositório são: controle de versões, definição e gerenciamento de metadados, suporte a
padrões como UML e ActiveX, interoperabilidade com outras ferramentas e disponibilização
de serviços para navegadores de Internet (browsers). Maiores informações podem ser obtidas
em http://www.unisys.com/marketplace/urep.
Component CapitolTM 11 - O Component CapitolTM é um repositório desenvolvido pela
Objects Components Corporation (OCC) para o armazenamento de componentes
implementados em linguagens orientada a objetos tais como, Java, C++, Eiffeil e SmallTalk.
Equipes que necessitam diminuir o tempo de desenvolvimento e aumentar a qualidade de suas
aplicações podem pesquisar nesse repositório para encontrar componentes que se adequem às
suas necessidades [CC, 1999]. As funcionalidades disponíveis são: pesquisa e inserção de
componentes, exploração dos seus catálogos e exploração de catálogos de vendedores,
categorias, plataformas e tecnologias. Outras informações podem ser obtidas em
http://www.object-components.com/ComponentCapitol/
Nesse capítulo foram apresentados os principais aspectos relacionados aos repositórios

de ativos. Definiu-se repositório como o local onde os ativos de software estarão armazenados
e classificados de modo a facilitar a correta utilização e recuperação dos mesmos. Foi
comercias. Nenhum desses produtos foi instalado e testado.

11
Atualmente existe um projeto sendo estudado pela Objects Components Corporation para transformar o
Component CapitolTM num repositório para a Internet.
68
abordada, também, a importância de um repositório para as empresas como o principal meio
de organizar seus ativos e, com isso, incentivar a prática do reuso. Em seguida foram
apresentadas algumas utilidades atribuídas aos repositórios e foi sugerido um modelo para a
sua construção
O capítulo mostrou ainda as principais características funcionais e não-funcionais que
um repositório pode apresentar e sugestões de gerenciamento.
O capítulo é finalizado uma breve análise dos principais produtos disponíveis no
mercado e na internet
O capítulo seguinte irá apresentar os fundamentos da tecnologia XML, usada na
implementação do repositório ProReuso que será apresentado no capítulo 6. Essa tecnologia
consiste numa linguagem de marcas que permite a estruturação de documentos textuais.
Assim, essa estruturação possibilitou se realizar uma pesquisa mais apurada dos componentes
disponíveis no repositório ProReuso.
69
Capítulo 5
Fundamentos da Tecnologia XML
Como foi visto anteriormente, na seção 4.4.2 , XML é uma tecnologia que vem sendo
usada como suporte a repositórios no que tange à comunicação entre eles. Em vista de
facilidades fornecidas por essa tecnologia, ela também foi utilizada na implementação do
ProReuso, um repositório de componentes que será descrito com detalhes no capítulo 6.
Assim, neste capítulo, serão apresentadas as principais características da tecnologia, deixando
para o próximo capítulo uma melhor detalhamento de como a XML foi utilizada neste projeto.
5.1 – Introdução a XML
XML significa eXtensible Markup Language e consiste em uma linguagem de

marcação(tags). XML é um subconjunto da SGML (Standard Generalized Markup
Language), que foi definida em 1986 como um padrão internacional de linguagem de marcas.
Todavia, SGML trata-se de uma linguagem de marcas bastante complexa com funcionalidades
interessantes. Assim, a linguagem XML foi desenvolvida com o objetivo de prover algumas
das funcionalidades da SGML, mas de uma forma simplificada, que permitisse facilidade na
compreensão e construção dos seus documentos.
O HTML também tem como origem a SGML, aliás, essa linguagem foi escrita (sua
sintaxe e regras) em SGML. Realmente, HTML e XML possuem alguns aspectos
semelhantes. Ambas são representantes do paradigma das linguagens de marcação12, o que
significa que tratam-se de texto com marcas embebidas, que qualificam cada unidade de
informação (também referidas como entidades, elementos, ou objetos) contida no texto. As
12
Esse paradigma permite tratar cada unidade de informação como um objeto (ou entidade) ao qual pode-se
atribuir características específicas, o que possibilita maior poder de estruturação da informação.
70
duas foram concebidas para armazenar e transmitir dados, porém XML traz mais efetividade
na transmissão dos dados por prover maior flexibilidade.
A grande diferença entre HTML e XML refere-se ao fato de que as marcas(tags) na
XML podem ser criadas pelo desenvolvedor para melhor qualificar as informações do texto.
Além disso, a HTML fica restrita ao formato de apresentação do dado, enquanto a XML no
que ele significa.
Houve uma tentativa da HTML trazer essas novas funcionalidades, que passaram a ser
exigidas pelas organizações à medida que a utilização da Web expandiu-se, através de
extensões. Porém, essas extensões começaram a transformar uma linguagem que
originalmente era simples em algo complexo. Além disso, percebeu-se que o conjunto fixo de
tags era a grande limitação da HTML e que uma nova linguagem precisava surgir. Essa
necessidade ficou ainda mais clara ao se desejar processar informações distribuídas em
aplicações distribuídas de negócio; o conjunto de tags oferecido pela HTML não era
suficiente, por exemplo, para descrever uma requisição de compra.
Assim, em fevereiro de 1998 a W3C (World Wide Web Consortium) publicou a versão
1.0 da Recomendação XML.
5.2- Documento XML
Um documento XML é uma sequência de caracteres que compreende o

texto(conteúdo) do documento, mais a estrutura lógica e meta-informações dessa estrutura.
Estruturalmente, o documento divide-se em duas partes:
- Prolog: provê informações gerais do documento, como este deve ser
interpretado(ex. versão XML e a qual tipo de documento se refere).
- Instância do Documento : corresponde ao conteúdo organizado numa
estrutura de marcação(tags).
Para exemplificar, segue um documento XML simples (Figura 5.1):
71
Figura 5.1 – Exemplo de Documento XML
O prolog, portanto, apresenta duas partes: uma declaração da XML e declaração de

tipo de documento.
A declaração da XML refere-se a primeira linha do documento e pode ser composta
das seguintes informações:
1. Versão XML: representa a versão XML que o documento está usando. Hoje só
existe a versão 1.0, mas quando saírem as futuras, essa informação garantirá que o
browser interpretará corretamente o seu documento.
2. Declaração de Codificação: descrição de qual conjunto de caracter que está sendo
usado no documento. Essa informação pode ser omitida, como no exemplo dado,
quando o documento está codificado no tradicional conjunto 7-bit-ASCII, que é
um subconjunto do Unicode, chamado de UTF-8, que qualquer processador XML
pode detectar automaticamente e usar.
3. Declaração de Documento Standalone: declaração de quais componentes da
definição de tipo de documento (DTD, que será melhor explicado mais adiante)
serão necessários para o completo processamento do documento. Na verdade,
indica se elementos que são externo e estão declarados no DTD13 serão utilizados
ou não. O valor Yes significa que não serão utilizados partes externas e no, o
contrário.
13
DTD significa document type definition. Apesar de se referir a uma definição, palavra feminina, nesse
trabalho, será usado o artigo masculino junto a DTD, pois a idéia de que essa definição, de certa forma, está
contida num arquivo é mais facilmente assimilada. Será visto mais adiante que ela pode, inclusive, estar no
72
A segunda linha do prolog refere-se à declaração de tipo de documento. Declara-se,
nesse momento, qual tipo de documento que a instância está usando. No exemplo, é
informado que o documento corresponde a uma mensagem, cuja estrutura (Mensagem,
Importante, De, Para, Corpo) está definida no arquivo mensagem.dtd. Como essa estrutura é
definida será mostrado mais adiante.
A instância do documento é simplesmente o conteúdo propriamente dito, que
corresponde a informações estruturadas. A estruturação é feita através das marcações ou tags,
que podem ser de seis tipos: elementos, referências a entidades, comentários, instruções de
processamento, seções marcadas e declarações de tipo de documento.
Antes de iniciar o detalhamento desses tipos, vale dizer que todos os nomes dados a
essas marcações devem começar por letras ou um de alguns possíveis caracteres de pontuação,
exceto “.”, seguidos de letras, dígitos, hífens, underscores, dois pontos ou ponto final.
Espaços em branco e caracteres especiais, portanto, não são permitidos.
Elementos
Cada bloco de texto num documento XML deve ser descrito por um elemento
para se identificar a natureza(função) do seu conteúdo. O conteúdo de um elemento
pode ser caracteres, outros elementos ou ambos. É possível existir elementos vazios,
ou seja, que não possuem conteúdo, usados geralmente para marcar uma localização
particular no documento.
Elementos com conteúdo são delimitados por duas tags, a de início <nome
do_tipo_de_elemento> e de fim </nome_do_tipo_de_elemento>. Na figura 5.1, pode-
se observar o elemento “corpo”. Um processador XML irá acusar erro caso uma dessas
tags não seja fornecida. Além disso, se a caixa estiver diferente, também será acusado
ausência de tag, pois XML é sensível ao caso.
Elementos vazios possuem uma sintaxe diferente. Eles não apresentam a tag de
fim e são indicados da seguinte forma: <nome_do_tipo_de_elemento/>. No exemplo
dado, <importante/> corresponde a um elemento vazio.
Atributos
Além de conteúdo, elementos podem ter atributos. Eles são uma forma de
mesmo arquivo do documento.

73
acrescentar características e propriedades aos elementos de um documento. Atributos
possuem nome e valores. A diferença entre elementos e atributos é que esses não
possuem propriedades.
No exemplo dado, email é um atributo do elemento De e Para. Como se pode
perceber, valores de atributos são escritos entre aspas, que podem ser duplas ou
simples. O tipo desses valores deve ser declarado em um DTD.
Referências a Entidades
Entidades são usadas para representar caracteres reservados da linguagem
XML, como ‘<’,´>´, ´&´, dentro do conteúdo do documento. Também são usadas para
fazer referência a texto repetitivos dentro do documento (entidades internas) e para
incluir conteúdo de unidades físicas, como arquivos e recursos acessados via URL
(entidades externas).
Comentários
Comentários são informações a respeito do documento ou de suas tags que são
ignoradas pelos processadores. Em documentos XML, comentários podem conter
qualquer dado, exceto a string --, pois eles são inseridos começando com . Comentários não são passados para as aplicações pelo
processador XML.
Seções CDATA
Consiste de uma forma mais simples de indicar ao processador para ignorar
caracteres de tags, reservados na linguagem. Úteis, por exemplo, quando se quer
inserir códigos-fonte, que frequentemente possuem caracteres como ‘<’e ‘&’.
Entre o início da seção, <![CDATA[ e o seu final, ]]>, todos os dados são
passados para as aplicações, sem qualquer interpretação. A única string que não pode
ocorrer numa seção CDATA é ]]>.
Instruções de Processamento
Essas instruções representam uma forma de prover informações para uma
aplicação. Como comentários, elas não fazem parte do texto do documento, mas
diferentemente deles, devem ser passadas para uma aplicação pelo processador XML.
74
Elas têm a seguinte forma: <? Nome_da_instrução?>. Esse nome identifica a
instrução para as aplicações e essas só processam instruções que ela reconhece, as
outras são ignoradas.
Instruções que começam com xml são reservadas para a padronização XML.
No exemplo, a declaração da XML representa uma instrução desse tipo.
A declaração de tipo de documento será comentada na próxima seção.
5.2.1- Definição do Tipo de Documento
No início deste capítulo, foi ressaltada a característica marcante da linguagem XML

permitir aos autores de documentos XML criar e configurar o seu próprio conjunto de tags.
Essa definição é possível através de uma definição de tipo de documento, conhecida como
DTD. Essa sigla já foi bastante citada durante o capítulo, assim percebe-se sua importância.
Pode-se entender por DTD uma gramática para uma classe de documentos, onde são
descritas regras de sintaxe para elementos, atributos, declarações de entidades e notações do
documento. São definidas quais sequências, ordem e aninhamentos de tags são permitidas,
valores, tipos e valores default de atributos, nomes de arquivos externos que podem ser
referenciados, se eles contêm ou não XML e entidades que podem ser encontradas no
documento.
A declaração de um DTD pode ser feita interna ou externamente ao documento XML.
A declaração, entretanto, em ambos os casos é feita entre as tags <!DOCTYPE e ]>. A figura
5.2 corresponde a um exemplo de declaração interna de DTD.
<?xml version=“1.0”standalone=“yes”?>
<!DOCTYPE Mensagem[
<!ELEMENT Mensagem (Importante, De, Para, Corpo)>
<!ELEMENT Importante EMPTY>
<!ELEMENT De (#PCDATA)>
<!ATTLIST De e-mail CDATA #REQUIRED>
<!ELEMENT Para (#PCDATA)>
<!ATTLIST Para e-mail CDATA #REQUIRED>
<!ELEMENT Corpo (#PCDATA)>
]>
<Mensagem>
<Importante/>
<De Email=”cholanda@br.oracle.com”> Caroline Holanda </De>
75
<Para Email=”casouza@br.oracle.com”> Clarissa Angélica de Souza
</Para>
<Corpo> Esse é um mail de teste .
Obrigada
</Corpo>
</Mensagem>
Figura 5.2 – Exemplo de Declaração de DTD Interna
Na figura 5.1, o DTD foi declarado externamente no arquivo “mensagem.dtd”. Como

foi dito anteriormente, indica-se a qual DTD o documento se refere no prolog. Essa declaração
consiste numa referência a uma entidade externa.
Nesse momento, torna-se importante apresentar uma classificação que documentos
XML podem receber. Um documento XML não precisa ter um DTD, mas para serem
validados por um XML parser, faz-se obrigatório a declaração de um. Assim, documentos são
classificados quanto a sua validade em relação ao DTD a que se referem. Documentos válidos
são aqueles cuja toda estrutura, valores de elementos e atributos estão de acordo com seus
DTDs. Contrariamente, os documentos são inválidos.
Outra classificação existente é quanto à conformidade do documento com as regras da
especificação da linguagem XML. Documentos que estão de acordo recebem o nome de bem-
formados, aliás, documentos que não são bem-formados, por definição, não são documentos
XML.
Por último, na figura 5.2, pode-se verificar como os tipos de elemento são definidos e
declarados, assim como a lista de seus atributos. A declaração de elementos tem as seguinte
estrutura <!ELEMENT nome_do_tipo_elemento content-model >, onde content-model define
o que um elemento desse tipo pode conter. Elementos podem conter outros elementos,
caracteres (indicado por #PCDATA), nenhum (indicado por EMPTY) ou qualquer conteúdo
(indicado por ANY).
A declaração de atributos de um tipo de elemento segue esta estrutura :
<!ATTLIST nome_do_tipo_elemento definições_do atributo>,
onde declarações_do_atributo é uma sequência definindo o nome, tipo e o valor

default, se tiver algum.
76
Atributos podem ser do tipo string (indicado por CDATA) ou lista de enumeração, que
é uma lista de valores pré-definidos, onde o valor do atributo pode ser apenas um deles. A
lista é declarada dessa forma (valor1 | valor2 | valor3).
As definições para valor default podem ser:
#REQUIRED – um valor deve ser dado para esse atributo em todos os elementos do
tipo declarado; não há valor default.
#IMPLIED – um valor pode ser dado para esse atributo nos elementos do tipo
declarado; não há valor default.
“attr-value” – o valor default é o fornecido entre as aspas.
#FIXED “attr-value” – todo elemento terá o valor fornecido entre aspas para esse
atributo e não poderá haver alteração.
As declarações de entidades e de notações requereriam um detalhamento maior da

linguagem. Assim, como nesse trabalho se pretende apenas uma introdução à tecnologia
XML, essas declarações não serão expostas .
Uma vez exposto alguns aspectos de como criar um DTD, pretende-se que tenha sido
possível entender como a XML torna viável a criação de tags para melhor representar as
informações contidas num documento.
5.3 – Importância do XML
Após essa explicação sobre linguagem XML, passa-se a ressaltar as característica que
trazem vantagens ao utilizá-la. De certa forma, a apresentação dessas vantagens reflete, em
muitos itens, uma comparação com a linguagem HTML.
XML, como o próprio nome diz, é uma linguagem extensível, assim traz flexibilidade
na criação dos documentos e permite trazer maior significado para as informações contidas no
texto.
A linguagem XML permite separar o conteúdo do documento do seu formato, e assim,
permite que haja tratamento diferenciado dos dados. O mesmo documento pode ser
apresentado de forma diferente, de acordo com o conhecimento, interesse e necessidade do
77
seu público alvo. Isso não ocorre no HTML, que representa apenas a apresentação dos dados.
Rigorosamente, a linguagem XML é uma maneira textual de representar a estrutura
inserida nos dados. Por causa dessa estruturação, pode-se realizar pesquisas mais acuradas no
ambiente Web.
Para finalizar, por atender à flexibilidade exigida nas aplicações de negócio atuais,
como comércio eletrônico e aplicações business-to-business, XML tem se tornado um padrão
universal para a troca eletrônica de dados.
Nesse capítulo foi apresentada a tecnologia XML. Mostrou-se que se trata de uma
linguagem de tags, assim como o HTML, mas que traz muita flexibilidade na criação dos
documentos.
Isso se dá devido ao fato da linguagem XML permitir que o autor de um documento
crie seu próprio conjunto de tags, para melhor representar os dados contidos no documento.
Apresentou-se os possíveis tipos de tags na linguagem, que são elementos, referências a
entidades, comentários, instruções de processamento, seções marcadas e declaração de tipo de
documento.
Salientou-se, ainda, que para ser validado, um documento XML precisa se referir a um
DTD (Document Type Definition). O DTD representa uma gramática para uma classe de
documentos, onde são definidas regras de sintaxe para os elementos do documento e seus
atributos, declaração de entidades e de notações.
Finalmente, são apontandas as vantagens em utilizar a linguagem XML nas aplicações.
Como exemplo, pode-se citar a flexibilidade na criação dos documentos, tratamento
diferenciado para os dados e pesquisas mais acuradas no ambiente Web, devido à estruturação
textual permitida pela linguagem.
O próximo capítulo apresenta um repositório de componentes, com o intuito de
mostrar a aplicação de um dos aspectos que viabiliza o reuso nas organizações. O capítulo
pretende, ainda, demonstrar quais decisões foram tomadas para permitir que esse repositório
se transformasse numa verdadeira ferramenta para o processo de reuso de uma empresa. Uma
das decisões foi a disponibilização de uma pesquisa feita em documentos XML para facilitar
na localização e recuperação dos ativos.
78
79
Capítulo 6
ProReuso: Um Repositório de Componentes
Neste capítulo, é apresentado e descrito o ProReuso - um repositório que permite o

armazenamento, a pesquisa e a recuperação de componentes e de documentos a eles
relacionados. O ProReuso é dirigido por um processo descrito via uma ferramenta de
workflow e, assim sendo, a inserção de ativos no repositório é fruto de um processo de
avaliação e validação do qual participam gerentes de projetos e especialistas em qualidade. A
pesquisa é efetuada a partir de características pré-definidas e organizadas num documento
XML.
6.1 – Motivação
A idéia da construção de um repositório surgiu com a necessidade de se criar um local

para o armazenamento dos componentes desenvolvidos por uma empresa de software, no
caso deste trabalho a Oracle do Brasil, que pudesse estar disponível via web a todos
envolvidos no processo de desenvolvimento e manutenção de software.
Observou-se que a prática do reuso pode trazer grandes benefícios à uma organização.
Para isso, é necessário que todos os seus membros tenham conhecimento dos componentes
outrora desenvolvidos para que possam avaliá-los e, possivelmente, optar pelas sua
reutilizações em novos projetos.
A principal intenção é possibilitar que no futuro todos os projetos sejam compostos de
pequenos componentes diminuindo, assim, o prazo de entrega ao cliente e aumentando a
produtividade e a qualidade desses projetos.
Outra intenção é permitir que o repositório sirva, também, como um banco de
conhecimentos visto que um componente de software é o fruto de tarefas baseados no uso
intensivo de conhecimento. Além de artefatos de software, como o código fonte dos
componentes, um repositório pode também ser chamado a gerenciar outros tipo de
documentos, como por exemplo, propostas, especificação de requisitos, memorando, etc., ou
80
seja, toda a informação utilizada como insumos e como sub-produtos das diferentes atividades
de desenvolvimento de software.
Para se atingir os objetivos acima citados, considerou-se fundamental que os ativos os
quais constituiriam o repositório pudessem ser inspecionados seguindo regras de validação e
controle de qualidade. Existiria, então, um rígido controle do que seria inserido para que não
houvesse ativos desnecessários ou de baixa qualidade que pudessem desmotivar a utilização
do repositório devido a falta de credibilidade das informações ali armazenadas.
Esses requisitos podem ser atendidos através da implementação de uma rotina de
workflow permitindo a avaliação desses ativos por pessoas especializadas.
Por fim, a possibilidade de organizar as características dos ativos em formato XML
permite não só uma pesquisa mais eficiente, mas possibilita, também, futuras adaptações ao
repositório. Entre elas destacam-se a integração de ferramentas através da comunicação no
padrão XML e a contextualização de interfaces através da definição de folhas de estilo
apropriadas a cada grupo de usuários.
O conjunto de todas as características acima identificadas motivou a construção do
ProReuso como sendo uma ferramenta capaz de auxiliar a organização no seu desafio de
instituir a prática do reuso como uma prática cotidiana na vida dos desenvolvedores de
software.
6.2 – Descrição e Funcionalidades
O ProReuso é um repositório desenvolvido para o ambiente web que permite o

armazenamento, a pesquisa e a recuperação de componentes e de documentos a eles
relacionados. Um componente é representado por um JavaBeans, Enterprise JavaBeans ou .
Por sua vez, documentos representam casos de uso, diagramas de interação, diagramas de
classes, JavaDoc, apresentações, interfaces e manuais de usuário, white papers e outros.
A inserção dos ativos é aprovada após um processo de avaliação e validação do qual
participam gerentes de projetos e especialistas em qualidade. Cada um dos participantes desse
workflow analisa o documento segundo critérios pré-definidos e pode aprovar, rejeitar, ou
aprovar com correções cada um dos ativos submetidos. O descrição desse processo será
apresentada na próxima seção.
81
Cada documento submetido deve estar relacionado a um componente e cada
componente possui uma página no site com uma referência a todos os seus documentos. Nessa
página é também possível visualizar as características de todos os ativos bem como os
comentários que forem inseridos pelos usuários a respeito do componente em questão. Após a
submissão uma referência para o ativo já é inserida na página correspondente com uma
observação indicando que o mesmo ainda não foi aprovado.
Cada ativo apresenta um conjunto de características que são agrupadas num
documento XML. Esse documento servirá como base para a rotina de pesquisa e recuperação
de ativos do ProReuso. As características definidas para os ativos estão especificadas no XML
que encontra-se no apêndice B.
Para a pesquisa o usuário pode especificar em quais campos do documento XML ele
deseja que ela seja efetuada. Assim, o usuário pode eliminar informações desnecessárias e
mais facilmente localizar os ativos desejados.
O ProReuso pode ser acessado por usuários públicos (dentro da intranet) ou por
usuários cadastrados através do fornecimento de login e senha. Sendo assim, o sistema oferece
um controle de segurança da seguinte forma: Apenas os usuários cadastrados podem submeter
componentes e documentos, visualizá-los e recuperá-los. Os usuários públicos podem fazer
pesquisas, mas não podem recuperar os ativos encontrados. A eles só é permitido o acesso a
documentos informativos tais como readme, white papers e manuais do usuário.
O repositório disponibiliza, ainda, um catálogo com todos os componentes
disponíveis. Essa catálogo traz a descrição dos mesmos e uma referência à sua página para os
usuários cadastrados.
Por fim, através do ProReuso, é possível compartilhar experiências através da inserção
de comentários. Um usuário que já tenha utilizado um componente pode inserir dados
relevantes sobre sua experiência com o mesmo e esses dados estarão disponíveis a todos os
outros usuários para que eles sigam as suas recomendações.
As principais funcionalidades disponíveis aos usuários do ProReuso são:
• Submissão de Componentes e Documentos – responsável por iniciar o processo de
aprovação de ativos. Na submissão, o usuário fornece as principais características
do componente ou do documento as quais irão compor o documento XML.
• Acompanhamento de Processos – possibilita a um usuário acompanhar
graficamente todos os processos por ele iniciados. O usuário pode a qualquer
momento identificar em que ponto do processo se encontra o ativo submetido.
82
• Pesquisa – permite a procura pelos componentes e documentos que compõe o
repositório. Essa pesquisa pode ser contextualizada, ou seja, é permitido ao usuário
que identifique em quais campos do documento XML ele deseja que a pesquisa seja
feita.
• Exploração do Catálogo – mostra ao usuário todos os componentes que fazem parte
do repositório juntamente com suas descrições.
• Inserção de Comentários – permite que uma pessoa que já tenha utilizado um
componente ou um documento insira comentários sobre aquele ativo de modo a
compartilhar experiências.
6.3 - Arquitetura
Para a construção do ProReuso foi adotada uma arquitetura que baseia-se,

principalmente, na estrutura de um banco de dados relacional e integra, a essa estrutura, 3
ferramentas conforme mostra a figura 6.1.
Figura 6.1 - Arquitetura do ProReuso
83
Como se pode observar, o ProReuso corresponde a uma instância de banco que é
acessada por estações clientes através de um listener de interface para web. Toda a sua lógica
está armazenada no banco na forma de procedimentos PL/SQL, que geram páginas HTML
para serem visualizadas através de um navegador nas estações clientes. O acesso a esses
procedimentos é feito através de um servidor web representado por um listener HTTP
agrupado a um gateway PL/SQL
Os elementos presentes nessa arquitetura são:
Oracle WebDB [WEBDB, 2000] - Ferramenta utilizada para o desenvolvimento de
aplicações para a Internet. Disponibiliza aos desenvolvedores funções como monitoração de
aplicações e controle de acesso. Encontra-se armazenada no banco de dados e todas a suas
funcionalidades são representadas por pacotes PL/SQL.
Oracle WorkFlow [WF, 2000] - Ferramenta utilizada para a definição e automação de
processos. Assim como o WebDB, encontra-se completamente armazenada no banco. É
composta por um mecanismo gerenciador que controla a execução do processo e por um
sistema de notificação responsável pelo envio de mensagens e pelo processamento de suas
respostas.
Oracle Intermedia [INTER, 2000]- Ferramenta utilizada para a pesquisa de
documentos armazenadas no banco.
Listener e PL/SQL gateway [WEBDB, 2000]- Esses elementos fazem parte do
WebDB e atuam como a camada intermediária entre o protocolo HTTP utilizado pelo
navegador e o protocolo NET8 utilizado pelo banco. Isso permite que links no site sejam
requisições de procedimentos PL/SQL.
6.4 – Processos
Nessa seção, será explicada a rotina de workflow modelada para o processo de

aprovação de um componente14. Todo componente submetido ao repositório passará por esse
processo, que corresponde a uma crivo de gerentes especializados, que se encontram numa
hierarquia, e de uma grupo de qualidade, que avalia a corretude do componente em relação a
14
No contexto desse processo, a palavra componente estará representando tanto um componente como um
84
padrões pré-definidos.
Processo Aprovação de Componentes
Processo principal. Apresenta em nível mais alto todos os passos definidos para a
aprovação de um componente. O processo se inicia quando o requisitante submete um
componente no repositório. Os passos do processo são:
1. Verifica-se se o requisitante corresponde ao último nível da hierarquia (f15: Verifica

Nível).
2. Se for o último, o fluxo seguirá diretamente para o subprocesso de análise do grupo de
qualidade (p: Verifica Qualidade- segue passo 11).
3. Se estiver em nível intermediário, verificar-se-á na hierarquia quem é o superior imediato
(f: Verifica Superior).
4. Inicia o subprocesso de notificação desse superior quanto à submissão do componente,
que requer sua aprovação (p16: Notifica Superior) e o requisitante é notificado de que o seu
pedido foi enviado para esse superior.
5. Aguarda-se o retorno do processo anterior, que corresponde à resposta do superior,
podendo esse aprovar, aprovar com maiores ou menores correções ou rejeitar o
componente.
6. Caso o pedido seja aprovado, será verificado qual é o nível na hierarquia do superior
avaliador (f: Verifica Nível) e se ele corresponder ao último nível, então o requisitante
será notificado quanto à aprovação e dará início ao subprocesso de notificação do grupo de
qualidade quanto à necessidade de avaliação do componente submetido (p: Verifica
Qualidade- segue passo 11). Se o superior estiver em um nível intermediário na hierarquia,
será verificado quem é o superior imediato na hierarquia e ,em seguida, inicia o
subprocesso de notificação desse superior quanto à submissão do componente, que requer
sua aprovação (p: Notifica Superior).
documento submetido ao repositório.

15
Representa uma função definida no processo.
16
Representa um subprocesso do processo principal.
85
7. Nos casos em que o pedido for aprovado com correções ou rejeitado, será cobrado do
superior avaliador a inserção de comentários, justificando o resultado de sua avaliação.
Verifica-se se comentários foram inseridos e em caso negativo, inicia-se o subprocesso
que notifica o superior quanto à necessidade de inserir comentários (p: Solicita
Comentário). Quando o superior inserir os comentários ou se já os tiver inserido
anteriormente, verifica-se o resultado (f: Verifica Resultado) e notifica o requisitante do
resultado da aprovação.
8. Caso o pedido seja aprovado com maiores correções, o requisitante terá a opção de alterar
o componente e o re-submeter ao seu superior imediato. O requisitante também terá a
opção de finalizar o processo caso não queira continuar. Se fizer essa opção, o processo é
finalizado.
9. Caso o pedido seja aprovado com menores correções, o requisitante terá a opção de alterar
o componente e o re-submeter ao último superior que analisou o componente. O
requisitante também terá a opção de finalizar o processo caso não queira continuar. Se
fizer essa opção, o processo é finalizado.
10. Caso o pedido seja rejeitado, o requisitante é notificado e o processo encerrado.
11. No caso de aprovação do último superior da hierarquia , será iniciado o subprocesso que
solicita ao grupo de qualidade a avaliação do componente (p: Verifica Qualidade). O
grupo poderá aprovar, aprovar com correções ou rejeitar o componente.
12. Caso o componente seja aprovado pelo grupo de qualidade, o componente é publicado no
site do repositório (f: Publicação de Componente na Web), o requisitante notificado da
publicação e o processo encerrado.
13. Caso o componente seja rejeitado, o requisitante é notificado e o processo encerrado.
14. Caso o componente seja aprovado com correções, será cobrado do analisador que ele
informe as correções necessárias. Verifica-se se ele realizou essa tarefa e em caso
negativo, a sua efetivação é cobrada (p: Verifica Documento). O processo só seguirá
quando as correções forem inseridas. Quando isso ocorrer, o requisitante será notificado
do resultado e terá a opção de corrigir o componente ou desistir do pedido, finalizando o
processo. Caso escolha continuar, após corrigir o componente e o re-submeter, o
subprocesso de notificação do grupo de qualidade solicitando a avaliação do componente
é reiniciado (p: Verifica Qualidade).
As notificações tanto para o requisitante como para os superiores e analisadores do grupo

86
de qualidade são feitas via e-mail. Naquelas que exigem resposta, a própria mensagem possui
uma área reservada para tal.
87
Alteracao
Finalizar
Fim (Rejeitado) Verifica Documento Notifica Aprovacao Fim (Rejeitado)
<Default> com Correcao
Rejeitado
Ultimo Aprovado
Verifica Qualidade Publicacao do Notificacao de Fim (Aprovado)

Componente na Publicacao de
Web Componente
Intermediario Intermediario Ultimo
Inicio Verifica Nivel Verifica Superior Verifica Nivel Notificacao

Componente
Aprovado
Aprovado
<Default>
Notificacao de Envio Notifica Superior Verifica Comentario

para Superior Presente
Alteracao
Aprovado com Menores correcoes
Ausente
Finalizar
Notificacao de Verifica Resultado
Componente
Aprovado com
Fim (Rejeitado) Menores Correcoes
Rejeitado Solicita Comentario
Finalizar
Aprovado com Maiores Correcoes
Alteracao
Notificacao de
Componente Notificacao Fim (Rejeitado)
Aprovado com
Componente
Maiores Correcoes Rejeitado
Figura 6.2 – Processo de Aprovação de Componentes
Processo Notifica Superior
Subprocesso do aprovação de componentes que corresponde à notificação de um

superior quanto à submissão de um componente que requer sua aprovação. Os passos
correspondentes a este sub-processo são descritos abaixo:
1. O superior recebe a notificação com os dados da submissão: nome e tipo do componente,
nome do requisitante e o link para o arquivo do componente. No caso da submissão ser de
um documento, o nome do componente a que esse documento está associado também é
fornecido.
2. Na própria notificação, o superior responde ao pedido de aprovação com o resultado da
sua avaliação. O resultado pode ser: aprovado, aprovado com maiores correções, aprovado
com menores correções e rejeitado.
3. Quando o superior responder, o processo será encerrado.
Fim (Aprovado com

Menores correcoes)
Fim (Aprovado)
Aprovado
Rejeitado
Inic io Pedido de Fim (Rejeitado)

Aprovacao
Fim (Aprovado com

Maiores Correcoes)
Figura 6.3 – Processo Notifica Superior
93
Processo Solicita Comentário
Subprocesso do aprovação de componentes que corresponde à solicitação de inserção

de comentários por parte do superior, quando esse rejeitar ou aprovar com correções um
pedido de aprovação de componente. Antes já foi verificado que ele não havia fornecido
nenhum comentário (f: Verifica Comentário). Os passos do processo são:
1. O superior recebe a notificação, lembrando-o do resultado por ele fornecido para
determinado componente e quanto à necessidade de se fornecer comentários, justificando
resultados desse tipo.
2. O superior responderá a notificação inserindo no lugar reservado para tal o comentário.
3. Verifica-se se o comentário foi fornecido (f: Verifica Comentário).
4. Caso não tenha fornecido, será enviada nova cobrança e continuará aguardando a inserção.
5. Quando a inserção tiver realmente ocorrido, o processo será encerrado.
Cobranca de
Comentario
Ausente
Presente
Inic io Pedido de Inc lusao Verifica Comentario Fim
de Comentario
Figura 6.4 – Processo Solicita Comentário
94
Processo Verifica Qualidade
Subprocesso do aprovação de componentes que corresponde ao processo de análise da

qualidade do componente, depois dele ter sido aprovado pelo(s) superior(s).
1. É verificado qual o analisador corresponde ao tipo do componente que está sendo
submetido, pois para cada tipo de componente um determinado membro do grupo de
qualidade é responsável pela análise (f: Seleciona Analisador).
2. Esse analisador recebe a notificação, solicitando a análise da qualidade para o componente
e alertando da necessidade de se inserir um documento de correções caso se aprove com
correções.
3. Na notificação são fornecidos o nome e tipo do componente, o requisitante e o link para o
arquivo do componente. Caso tenha sido feita a submissão de um documento, também
será fornecido o nome do componente ao qual o documento está associado.
4. Na notificação, ainda será lembrado ao analisador que para resultados do tipo aprovado
com correções, faz-se necessário a inserção de um documento com as correções que
devem ser feitas. Na mensagem da notificação, existe um link para o formulário onde esse
documento pode ser submetido.
5. Na própria notificação, o analisador responde ao pedido com o resultado da sua análise. O
resultado pode ser: aprovado, aprovado com maiores correções, aprovado com menores
correções e rejeitado.
6. Quando o analisador responder, o processo será encerrado.
95
Fim (Aprovado) Notificacao de
Aprovacao do Grupo
de Qualidade
Fim (Aprovado com

Menores correcoes)
Aprovado
Inicio Seleciona Analisador Notificacao para o

grupo de qualidade
Rejeitado
Fim (Aprovado com
Maiores Correcoes)
Fim (Rejeitado) Notificacao de

Rejeicao do grupo
de qualidade
Figura 6.5 – Processo Verifica Qualidade
96
Processo Verifica Documento
Subprocesso do aprovação de componentes que corresponde ao processo de

verificação e cobrança da inserção de um documento de correção por parte do analisador do
grupo de qualidade, quando este aprova um componente com correções.
1. É verificado se o documento de correções foi inserido.
2. Em caso afirmativo, o processo será encerrado.
3. Em caso negativo, o analisador recebe a notificação, lembrando-o da necessidade de
inserir um documento de correção quando se aprova com correções e solicita que o faça,
devido ao resultado fornecido por ele para o componente em questão.
4. Na notificação são fornecidos o nome e tipo do componente, o requisitante, o link para o
arquivo do componente e o link para o formulário de inserção do documento de correções.
No caso de submissão de documento, será fornecido também o nome do componente ao
qual ele está associado.
5. Na própria notificação, o analisador responde à notificação, após inserir o documento
através do formulário indicado, informando que o documento já foi inserido.
6. Quando o analisador responde, será verificado se o documento foi realmente inserido e
volta-se ao passo 1 do processo.
Fim
Presente
Ausente
Inicio Verifica Documento Pedido de Inclusao

de Correcoes de Documento
Sim
Figura 6.6 – Processo Verifica Documento
97
98
Processo Notifica Aprovação com Correção
Subprocesso do aprovação de componentes que corresponde ao processo de

verificação com qual tipo de correções, maiores ou menores, o componente foi aprovado pelo
analisador do grupo de qualidade e a notificação do requisitante quanto a esse resultado. Os
passos desse subprocesso são descritos abaixo:
1. Verifica-se qual tipo de resultado foi dado ao componente, aprovação com maiores
ou menores correções.
2. O requisitante é notificação informando qual foi o tipo do resultado da análise do
grupo de qualidade. Na mensagem será fornecido o link para o arquivo do
documento de correções submetido pelo analisador.
3. Em qualquer dos casos, maiores ou menores correções, o requisitante poderá optar
por alterar o componente e re-submetê-lo ao grupo de qualidade, ou por desistir da
submissão, finalizando o processo. No caso de escolher alterar, após responder à
notificação será reiniciado o processo de solicitação de análise de componente ao
grupo de qualidade (p: Verifica Qualidade).
Finalizar
N o tific a c a o d e Fim (Fina liza r)

A p ro v a c a o c o m
M a io res Corre c o e s Alterac a o
A p ro v a d o c o m M a io res Corre c o e s
do GQ
Fim (A lte ra c a o )
Inic io V e rific a R e s u lta d o

A lte rac a o
A p r o v a d o c o m M e n o res c o rre c o e s
Fin a lizar
N o tific a c a o d e
Aprovacao com
M e n o res Corre c o e s
do GQ
Figura 6.7 - Processo Notifica Aprovação com Correção
99
Nesse capítulo foram apresentados os principais aspectos relacionados ao ProReuso.

Inicialmente, dissertou-se a motivação para se construir um repositório de componentes para
Web e fez-se uma descrição dessa ferramenta, apresentando suas características e suas
principais funcionalidades. Em seguida, foi mostrada a arquitetura adotada para a construção
do repositório e que possibilitou o armazenamento, a pesquisa contextualizada, a recuperação
e a validação dos ativos. Por fim, apresentou-se o processo de aprovação de componentes
utilizado pelo ProReuso para garantir a qualidade dos ativos disponibilizados a seus usuários.
Para a apresentação desse processo foi feita uma representação gráfica juntamente com uma
descrição detalhada de cada uma de suas etapas.
No próximo capítulo serão apresentadas as conclusões obtidas com a presente pesquisa
e com a construção do repositório de componentes.
100
Capítulo 7
Conclusões
O mercado cada vez mais competitivo em que as empresas desenvolvedoras de

software se encontram atualmente exige dessas um comportamento bastante diferente daquele
praticado durante muitos anos. Softwares grandes e complexos que apresentam vários defeitos
e que não satisfazem às necessidades dos usuários não são mais aceitos por seus clientes.
Devido a essas exigências, as empresas que se preocupam em sobreviverem no mercado
buscam alcançar objetivos que exigem bastantes esforços e requerem tempo para se
realizarem, tais como: aumento de qualidade, satisfação do cliente, melhoria técnica, redução
de prazos de entrega, aumento da produtividade e redução de defeitos e de riscos. Além disso,
com o crescente avanço da tecnologia, essas empresas precisam se adaptar para melhor
atender a todas as expectativas de seus clientes.
Para atender a essas necessidades o reuso propõe o desenvolvimento de sistemas a
partir de produtos de software preexistentes, de modo que semelhanças entre requisitos e
arquiteturas de diversos sistemas possam ser melhor exploradas. Com a identificação das
semelhanças é possível se reduzir o tempo de entrega e o custo de desenvolvimento e
aumentar a produtividade e qualidade do produto final.
De modo a potencializar a prática do reuso nas organizações, muitas empresas têm
feito uso de um repositório de onde é possível recuperar ativos pré-construídos que poderão
simplificar o processo de desenvolvimento e auxiliar na disseminação de experiências e
práticas comuns no ambiente corporativo. Sendo assim, um repositório é um fator técnico que
torna possível uma estratégia de reuso adotada por uma organização. Entretanto, outros fatores
como o gerenciamento, o incentivo à utilização e o treinamento de uso de repositório são
também fundamentais para possibilitar essa estratégia de negócio.
A implementação do ProReuso levou em consideração fatores que podem ser
determinantes para o êxito no processo de reuso. Entre eles destacam-se: o processo de
análise, validação e aprovação de componentes que possibilita garantir a qualidade do que está
sendo inserido no repositório; a pesquisa contextualizada que permite uma recuperação mais
apurada dos ativos e a disponibilização em ambiente web a qual possibilita o acesso remoto a
101
todos os funcionários da empresa.
Tendo em vista a intenção inicial da empresa na construção de um repositório de
componentes executáveis, o ProReuso foi focado no armazenamento desses componentes e
dos documentos relacionados a cada um deles. Entretanto, observou-se que é possível e
interessante ampliá-lo para um repositório de conhecimentos gerais onde seria permitido a
inserção não só de ativos de software, como também de procedimentos inerentes a um
determinado processo, regras da organização para a execução de atividades, materiais para
treinamentos e tudo o mais que representar o patrimônio informativo de uma empresa. Isso é o
que propõe os pesquisadores do Gerenciamento do Conhecimento (Knowledge Management).
Outro fator a ser considerado como uma futura adaptação é permitir que os próprios autores
dos ativos possam modificar as características dos mesmos devido às constantes mudanças
presenciadas pela área tecnológica.
Para finalizar, destaca-se que a implementação do ProReuso mostrou ser viável a
construção de um repositório por aquelas organizações que desejam alcançar os benefícios
obtidos com o reuso. Isso possibilitará que as pequenas empresas também participem do
grupo de grandes empresas que se já se beneficiaram dessa prática, e que caminhem, junto à
Engenharia de Software, rumo à excelência no desenvolvimento de sistemas.
102
Apêndice A
Modelagem do Sistema
A modelagem do sistema foi dividida em três partes. A primeira corresponde à definição de

requisitos na qual foi utilizado o modelo de casos de uso definido na metodologia UML
(Unified Modeling Language). Em seguida, foram identificadas as principais funções do
sistema e as mesmas foram organizadas em um diagrama hierárquico de funções. Como o
repositório e todas as suas funções encontram-se armazenados em um banco de dados
relacional, foi também elaborado o modelo entidade-relacionamento. Finalmente, é
apresentada a definição de tipo de documento XML (DTD) explicada no capítulo 5 e usada
para os documentos XML que guardam as informações dos ativos submetidos ao repositório.
Optou-se por utilizar o modelo de casos de uso para a definição de requisitos já que eles
proporcionam um fácil entendimento das principais funcionalidades do sistema e podem tanto
ser utilizados em um método de desenvolvimento de software estruturado ou em um orientado
a objetos. Nas etapas seguintes, optou-se em seguir o método tradicional da metodologia de
desenvolvimento de software estruturada. Essa decisão deve-se, em parte, ao fato do sistema
não ter sido desenvolvido numa linguagem orientada a objetos e, com isso, o mapeamento de
uma modelagem nesse contexto para um código procedural não seria facilmente realizado.
Ainda, a empresa que suportou a construção do ProReuso adota a modelagem estruturada
como metodologia padrão para o desenvolvimento de software.
Definição de Requisitos
A seguir serão apresentados os principais atores encontrados, a descrição de cada uma

das funcionalidades com as quais os mesmos poderão interagir e o modelo de casos de uso
identificados para o sistema. Para a descrição dos casos de uso utilizou-se o padrão
especificado em [SOUZA, 1999]
103
Atores
Requisitante – Representa o usuário que inicia e acompanha o processo de submissão

de componentes ou documentos. É também o responsável pela modificação dos mesmos
quando ela for solicitada por avaliadores ou analisadores de qualidade.
Avaliador – Representa os superiores do requisitante os quais são responsáveis por
avaliar o ativo submetido, aprová-lo, rejeitá-lo ou sugerir alterações para o mesmo
Analisador de Qualidade – Representa aquele responsável por analisar a qualidade do
ativo submetido no que diz respeito a padrões, clareza e validade do mesmo. O analisador de
qualidade, assim como o avaliador, pode rejeitar, aprovar ou sugerir modificações para o
ativo.
Pesquisador – Representa aquele que utiliza o repositório para fazer pesquisas sobre os
ativos disponíveis. Essas pesquisas podem ser feitas através de uma interface própria ou
através da exploração de catálogos
Usuário de Ativos – Representa o usuário que recupera e faz uso de um ativo.
Descrição do Casos de Uso
Cada um dos casos de uso será descrito através de uma tabela que contém as seguintes
informações:
1. Caso de Uso - Nome do caso de uso.
2. Descrição – breve descrição do caso de uso.
3. Pré-condições – Especificam as condições que devem ser válidas para o caso de
uso ser realizado.
4. Pós-condições – Especificam o estado do sistema depois da realização do caso de
uso.
5. Atores Primários – Representam os atores que disparam o caso de uso.
6. Atores Secundários – Especificam os atores que colaboram para a realização do
caso de uso.
7. Cenário Principal – Especificam os passos necessários para a realização do caso de
uso (fluxo principal).
8. Extensões – Passos que podem ocorrer na realização do caso de uso sob
determinada condição.
104
9. Inclusões – Passos necessários para a realização deste caso de uso e que são
comuns a outros casos de uso.
10. Cenários Secundários – Especificam os fluxos secundários para a realização do
caso de uso.
Tabela A.1
Caso de Uso Submeter Ativo

CASO DE USO 1 Submeter Ativo
Descrição O requisitante submete um ativo para aprovação e posterior inserção do
mesmo no repositório
Pré-condições O requisitante deve estar logado no site
Pós-condições O caso de uso termina quando o requisitante consegue submeter o ativo
e iniciar o fluxo de aprovação ou quando cancela a operação
Atores Primários Requisitante
Atores Secundários
Cenário Principal Passo Ação
1 O requisitante seleciona a opção “Submeter Componentes” ou
“Submeter Documentos” na tela de entrada.
2 O sistema apresenta ao requisitante um formulário de
submissão.
3 O requisitante preenche os seguintes campos: nome, versão,
tipo e descrição do ativo. Para a opção submeter documentos
o requisitante deve preencher também o campo com o nome
do componente ao qual o documento está associado.
4 Após preencher os campos o requisitante solicita a inclusão do
ativo no repositório
5 Include (Validar Entrada de Dados)
6 Estando válidas as informações o sistema inicia o fluxo de
aprovação, apresenta o formulário de informações para
pesquisa e o caso de uso é finalizado
Extensões Passo Ação de Desvio
Inclusões Nome do Caso de Uso

Validar Entrada de Dados
Cenários O requisitante pode cancelar a operação a qualquer momento
Secundários finalizando assim a execução do caso de uso.
105
No passo 6, caso as informações não estejam válidas, o sistema irá
comunicar ao requisitante qual o campo inválido e irá reapresentar o
formulário para que ele possa validá-lo e solicitar uma nova inclusão.
106
Tabela A.2
Caso de Uso Acompanhar Processo

CASO DE USO 2 Acompanhar Processo
Descrição O requisitante acompanha o andamento do processo de aprovação de
um ativo.
Pré-condições O requisitante deve estar logado no site e ter anteriormente submetido
um ativo para aprovação.
Pós-condições O caso de uso termina quando o requisitante visualiza o processo ou
quando ele cancela a operação
Atores Secundários
1 O requisitante seleciona a opção “Acompanhar Processos” na
tela de entrada.
2 O sistema apresenta ao requisitante um formulário com todos
os processos por ele iniciados.
3 O requisitante escolhe qual o processo deseja acompanhar.
4 O sistema apresenta ao requisitante o acompanhamento gráfico
do processo desejado e o caso de uso é finalizado.
Inclusões Número e nome do Caso de Uso

No passo 2, caso o requisitante não tenha submetido nenhum processo,
o sistema irá informá-lo que não existem fluxos de aprovação para
serem acompanhados.
107
Tabela A.3
Caso de Uso Re-submeter Ativo

CASO DE USO 3 Re-submeter Ativo
Descrição O requisitante re-submete um ativo para aprovação após ter feito as
correções sugeridas durante o processo de aprovação por um avaliador
ou analisador de qualidade.
Pré-condições O requisitante já deve ter iniciado o processo de aprovação do ativo e
esse deve ter sido “aprovado com maiores correções” ou “aprovado
com menores correções” por algum avaliador ou analisador de
qualidade.
Pós-condições O caso de uso termina quando o ativo é re-submetido e o processo
segue seu fluxo ou quando a operação é cancelada
Atores Secundários
1 O requisitante abre o formulário de re-submissão após receber
uma notificação para alterar o ativo.
2 O requisitante preenche o campo do formulário com o nome
do arquivo onde foram feitas as modificações solicitadas
3 O requisitante solicita uma nova análise do ativo.
4 O sistema atualiza o ativo e continua o processo de aprovação.
Caso o ativo tenha sido “aprovado com maiores correções” o
fluxo seguirá para o superior imediato. Caso contrário, seguirá
para o avaliador que fez as últimas correções.
Inclusões Caso de Uso

No passo 4, caso o ativo tenha sido aprovado com maiores ou menores
correções pelo analisador de qualidade, o fluxo retornará para esse
analisador.
108
Tabela A.4
Caso de Uso Inserir Informações para Pesquisa

CASO DE USO 4 Inserir Informações para Pesquisa
Descrição O requisitante fornece algumas características do ativo submetido que
poderão auxiliar na pesquisa
Pré-condições O requisitante deve ter submetido um ativo para aprovação
Pós-condições O caso de uso termina Quando o requisitante forneceu as características
solicitadas ou quando a operação é cancelada
Atores Secundários
1 O requisitante preenche os seguintes campos do formulário:
autor, data de criação, área de Domínio, sugestões de uso, pré-
requisitos, serviços oferecidos e palavras-chave. Os campos
nome, versão, tipo, nome do componente associado e
descrição já vêm preenchidos com os dados indicados no
formulário de submissão.
2 Após preencher os campos o requisitante solicita a inclusão
das informações de pesquisa
3 O sistema cria o documento XML e o caso de uso é finalizado

No passo 6, caso as informações não estejam válidas, o sistema irá
comunicar ao requisitante qual o campo inválido e irá reapresentar o
formulário para que ele possa validá-lo e solicitar uma nova inclusão.
109
Tabela A.5
Caso de Uso Validar Entrada de Dados

CASO DE USO 5 Validar Entrada de Dados
Descrição O sistema valida os dados que foram preenchidos num determinado
formulário
Pré-condições
Pós-condições O caso de uso termina quando todos os dados que foram submetidos
forem validados
Atores Primários
Atores Secundários
1 O sistema recebe os dados do formulário que deverão ser
validados
2 Para cada um dos dados recebidos o sistema verifica se estão
preenchidos com valores permitidos para os respectivos
campos.
3 Após validadas as informações o caso de uso é finalizado
Cenários
Secundários
110
Tabela A.6
Caso de Uso Avaliar Ativo

CASO DE USO 6 Avaliar Ativo
Descrição O avaliador recebe um ativo para avaliação e atribui a ele um status de
aprovação.
Pré-condições O ativo já deve ter iniciado o seu fluxo de aprovação e, caso o
avaliador não seja o superior imediato do requisitante, o ativo já deve
ter sido aprovado pelo avaliador imediatamente abaixo na hierarquia.
Pós-condições O caso de uso termina quando o avaliador atribui ao ativo um status de
aprovação e o processo segue seu fluxo.
Atores Primários Avaliador
Atores Secundários
1 O avaliador analisa o ativo após receber uma notificação de
aprovação de ativos.
2 O avaliador atribui um status de aprovação ao ativo
3 Caso o status seja “aprovado”, o ativo passará para a avaliação
do superior imediato na hierarquia de avaliadores. Se o
avaliador for o último nessa hierarquia, o fluxo segue para o
analisador de qualidade e o caso de uso é finalizado.
Cenários Caso o status seja “rejeitado”, o avaliador deverá fornecer um

Secundários comentário, o requisitante será notificado e o fluxo finalizado.
Caso o status seja “aprovado com maiores correções” ou “aprovado
com menores correções”, o avaliador deverá fornecer um comentário, o
requisitante será notificado e poderá posteriormente re-submeter o
ativo para aprovação.
111
Tabela A.7
Caso de Uso Analisar Qualidade do Ativo

CASO DE USO 7 Analisar Qualidade do Ativo
Descrição O analisador de qualidade recebe um ativo para análise e atribui a ele
um status de aprovação.
Pré-condições O ativo já deve ter iniciado o seu fluxo de aprovação e ter sido
aprovado por todos os avaliadores que compõe a hierarquia do
requisitante.
Pós-condições O caso de uso termina quando o analisador de qualidade atribui ao
ativo um status de aprovação e o processo segue seu fluxo.
Atores Primários Analisador de Qualidade
Atores Secundários
1 O analisador de qualidade analisa o ativo após receber uma
notificação de aprovação de ativos.
2 O analisador de qualidade atribui um status de aprovação ao
ativo
3 Caso o status seja “aprovado”, o ativo será publicado no site e
o caso de uso é finalizado.
3 Caso o status seja “aprovado com maiores correções” ou
“aprovado com menores correções”, (Inserir Correções)
Cenários Caso o status seja “rejeitado”, o requisitante será notificado e o fluxo

Secundários finalizado.
112
Tabela A.8
Caso de Uso Inserir Correções

CASO DE USO 8 Inserir Correções
Descrição O Analisador de Qualidade insere as correções a serem feitas no ativo
que está sendo analisado para que ele possa ser publicado.
Pré-condições O ativo deve estar sendo avaliado pelo Analisador de Qualidade e deve
ter sido “aprovado com maiores correções” ou “aprovado com menores
correções”
Pós-condições As correções são enviadas para o requisitante.
Atores Primários Analisador de Qualidade
Atores Secundários
1 O Analisador de Qualidade insere as correções feitas no
formulário de qualidade apresentado pelo sistema.
2 Após preencher o campo o requisitante solicita a inclusão do
ativo no repositório.
3 O sistema notifica o requisitante e apresenta as correções que
devem ser efetuadas para o ativo ser aprovado pelo Analisador
de Qualidade. O caso de uso é finalizado.
Cenários
Secundários
113
Tabela A.9
Caso de Uso Pesquisar Ativo

CASO DE USO 9 Pesquisar Ativo
Descrição O pesquisador procura por ativos que satisfaçam as características
fornecidas como parâmetro
Pré-condições
Pós-condições O caso de uso termina quando o pesquisador recupera um conjunto de
zero ou mais ativos que satisfazem as características desejadas ou
quando ele cancela a operação
Atores Primários Pesquisador
Atores Secundários
1 O pesquisador seleciona a opção “Pesquisar” na tela de
entrada
2 O sistema apresenta ao requisitante um formulário de pesquisa
3 O pesquisador preenche os campos com os parâmetros
desejados para cada uma das possíveis características dos
ativos.
4 Após preencher os campos o requisitante solicita ao
repositório que efetue a pesquisa de acordo com os parâmetros
fornecidos
5 O sistema procura pelos ativos que satisfaçam as
características fornecidas.
6 O sistema apresenta ao pesquisador os ativos encontrados e o
caso de uso é finalizado.
Cenários
Secundários
114
Tabela A.10
Caso de Uso Consultar Catálogo

CASO DE USO 10 Consultar Catálogo
Descrição O sistema apresenta ao pesquisador todos os ativos disponíveis no
repositório
Pré-condições
Pós-condições O use case termina quando o sistema apresenta ao pesquisador todos os
ativos disponíveis no repositório
Atores Secundários
1 O pesquisador seleciona a opção “Catálogo” na tela de entrada
2 O sistema apresenta ao usuário todos os ativos disponíveis no
repositório e o caso de uso é finalizado.
Cenários
Secundários
115
Tabela A.11
Caso de Uso Listar Comentários

CASO DE USO 11 Listar comentários
Descrição O pesquisador procura por comentários a respeito de um determinado
ativo.
Pré-condições
Pós-condições O caso de uso termina quando o pesquisador obtém os comentários
sobre um determinado ativo.
Atores Secundários
1 O pesquisador seleciona a opção comentários na página do
componente ou no catálogo de componentes.
2 O sistema mostra ao pesquisador todos os comentários que
foram inseridos sobre o componente indicado é o caso de uso
é finalizado
Cenários
Secundários
116
Tabela A.12
Caso de Uso Inserir Comentários

CASO DE USO 12 Inserir Comentários
Descrição O usuário de ativo insere algum comentário sobre um ativo que tenha
utilizado.
Pré-condições
Pós-condições O caso de uso termina quando o usuário de ativo insere algum
comentário ou quando a operação é cancelada.
Atores Primários Usuário de Ativo
Atores Secundários
1 O usuário de ativo seleciona a opção “Inserir Comentários” na
tela de entrada.
2 O sistema apresenta ao usuário de ativo um formulário para a
inserção de comentários.
3 O usuário de ativo seleciona o ativo desejado e preenche o
campo de comentário.
4 Após preencher os dados o usuário solicita a inclusão do
comentário no repositório.
5 O sistema valida as informações, insere o comentário no
repositório e o caso de uso é finalizado.
Cenários O usuário de ativo pode cancelar a operação a qualquer momento

No passo 5, caso as informações não estejam válidas o sistema irá
reapresentar ao usuário de ativo o formulário para que ele possa validá-
las e solicitar uma nova inclusão.
117
Tabela A.13
Caso de Uso Recuperar Ativo

CASO DE USO 13 Recuperar Ativo
Descrição O usuário de ativo tem acesso e consegue baixar um ativo
Pré-condições O usuário deve estar logado no sistema e já ter localizado o ativo
desejado.
Pós-condições O caso de uso é finalizado Quando o usuário recupera o ativo ou
quando a operação é cancelada
Atores Primários Usuário de Ativo
Atores Secundários
1 O seleciona a opção de visualização do ativo
2 O usuário pode visualizar este ativo ou gravá-lo em seu
computador, finalizado o caso de uso.
Cenários
Secundários
118
Modelo de Casos de Uso
Pacote Processo
Acompanhar Processo Inserir Informações para Pesquisa
Requisitante
<<include>> <<include>>
Re-submeter Ativo
Submeter Ativo
<<include>>
Inserir Correções
<<extend>>
Avaliar Ativo
Avaliador
Analisador de
Qualidade
Analisar Qualidade de Ativo
119
Pacote Pesquisa
Pesquisar Ativo
Listar Comentários
Pesquisador
Consultar Catálogo
120
Pacote Uso de Componente
Inserir Comentários
Usuário de Ativos
Recuperar Ativo
121
Telas do ProReuso
1. Tela de Abertura
Esta tela representa a tela de abertura do ProReuso. Ela é apresentada quando o

endereço do site é acessado. Nela, o usuário pode se logar para acessar mais funcionalidades
do repositório ou caso não seja cadastrado, poderá procurar por componentes disponibilizados
no ProReuso. Além disso, é possível acessar o catálogo de componentes existentes no
repositório.
Figura A.1 – Tela de Abertura
122
2. Tela de Opções
O usuário acessa essa tela após ter se logado no site. A partir desse momento, ele
poderá acessar as funcionalidades disponibilizadas antes de se logar e todas as outras
implementadas no ProReuso.
Nessa tela, o usuário, através do menu principal, tem as opções de submeter um
componente ou um documento ao repositório , acompanhar um processo de submissão
iniciado por ele, procurar por ativos disponibilizados no repositório ou inserir comentários
sobre algum componente disponibilizado que ele tenha usado.
Figura A.2 – Tela de Opções
123
3. Formulário de Submissão de Componentes
O usuário tem acesso a esse formulário quando ele seleciona a opção “Submeter
Componentes” no menu principal da tela de opções. Nesse formulário, o usuário deverá entrar
com as características básicas do componente que deseja submeter, que são: nome, versão,
tipo (que pode ser: Javabeans, Enterprise Javabeans ou Package), arquivo (componente em
si) e descrição do componente.
Ao submeter o componente, será iniciado um processo de aprovação do mesmo. Caso
o componente seja aprovado, esse será publicado no site e ficará disponível para os usuários
do ProReuso.
Figura A.3 – Formulário de Submissão de Componentes
124
4. Formulário de Submissão de Documentos
O usuário tem acesso a esse formulário quando ele seleciona a opção “Submeter
Documentos” no menu principal da tela de opções. Nesse formulário, o usuário deverá entrar
com as características básicas do documento, que deve ser associado a um componente já
armazenado no ProReuso e que o usuário deseja submeter. Essas características são: nome,
versão, tipo (que pode ser: diagramas de classe, de sequência, de estados, casos de uso,
interface do usuário, manual do usuário, javadocs, apresentação técnica, white paper ou
outros), nome do componente associado, arquivo (documento em si) e descrição do
documento.
Ao submeter o documento, será iniciado um processo de aprovação do mesmo. Caso o
documento seja aprovado, esse será publicado na área reservada do site para o componente ao
qual ele é associado (pasta do componente) e ficará disponível para os usuários do ProReuso.
Figura A.4 – Formulário de Submissão de Documentos
125
5. Formulário de Entrada de Características do Ativo
O preenchimento desse formulário é opcional. Ele é apresentado após a submissão de

um componente ou documento ao ProReuso. Ele serve para acrescentar informações sobre o
ativo, que irão facilitar a localização e recuperação do mesmo quando da realização de uma
pesquisa no ProReuso.
Figura A.5 – Formulário de Entrada de Características do Ativo
126
6. Tela de Processos
Essa tela é acessada quando o usuário seleciona a opção Acompanhar Processos no

menu principal da tela de opções. Caso o usuário tenha iniciado algum processo, ou seja,
tenha submetido algum componente, será apresenta a lista de processos que ele iniciou e que
poderão ser monitorados. A lista de processos corresponde aos nomes dos ativos submetidos
pelo usuário.
Figura A.6 – Tela de Processos
127
7. Tela de Acompanhamento
Essa tela é acessada quando o usuário seleciona um processo na lista oferecida na tela
de processos para monitorar. Nessa tela, o usuário toma conhecimento em que passo do
processo de aprovação se encontra o ativo submetido por ele.
Figura A.7 – Tela de Acompanhamento
128
8. Pasta de um Componente
Cada componente armazenado no ProReuso tem uma pasta onde podem ser acessados
o próprio componente, as suas características, os documentos associados a ele e comentários
feitos por outros usuários que já tenham reusado esse componente em seus projetos.
Figura A.8 – Pasta do Componente
129
9. Formulário de Pesquisa
O usuário tem acesso a esse formulário quando seleciona a opção Pesquisar. Nela, o
usuário poderá pesquisar em campos específicos, que correspondem a características do ativo,
ou em todos os campos. No caso da pesquisa ser realizada em campos específicos, a procura
será feita buscando ativos que possuem todas as características solicitadas.
Figura A.9 – Formulário de Pesquisa
130
10. Tela de Resultado de Pesquisa
Essa tela é apresentada quando existe algum componente ou documento no ProReuso

com as características solicitadas na pesquisa. Nela, são mostrados o nome e a descrição dos
componentes que foram encontrados no ProReuso.
Figura A.10 – Tela de Resultado de Pesquisa
131
11. Tela de Detalhamento
Essa tela é apresentada quando for solicitado o detalhamento das características de um

componente ou documento. As características disponibilizadas são aquelas fornecidas no
formulário de características do ativo pelo usuário que o submeteu ao ProReuso. Entretanto,
quando o ativo for um componente, será apresentada uma lista dos documentos associados a
ele. Quando houver o detalhamento dos documentos, será apresentada uma tela de
detalhamento semelhante a de um componente, porém não haverá lista de documentos
associados.
Figura A.11 – Tela de Detalhamento
132
12. Formulário de Inserção de Comentários
O usuário tem acesso a esse formulário quando seleciona a opção “Inserir

Comentários” no menu principal da tela de opções. Nesse formulário, o usuário poderá inserir
um comentário a respeito de um ativo, armazenado no ProReuso, que ele já tenha usado.
Figura A.12 – Formulário de Inserção de Comentários
133
13. Formulário de Re-submissão de Ativo
O usuário tem acesso a esse formulário quando recebe uma notificação do processo de
aprovação, informando que determinado avaliador aprovou o componente com correções e
caso queira alterar o componente ou documento, poderá fazê-lo o re-submetendo nesse
formulário. O usuário fornecerá um novo arquivo com as alterações indicadas.
Figura A.13 – Formulário de Re-submissão de Ativo
134
14. Formulário de Inserção de Documento de Correção
Esse formulário é apresentado ao analisador do grupo de qualidade quando esse deseja

inserir um documento com correções para um ativo que foi por ele analisado e que contém
erros. O analisador fornece o arquivo que descreve as correções necessárias para o ativo
determinado.
Figura A.14 – Formulário de Inserção de Documento de Correção
135
16. Tela do Catálogo
Essa tela é acessada quando o usuário visita o link ‘Catálogo’ na barra de navegação
do site. Nela são apresentados todos os componentes armazenados no ProReuso com a
descrição de cada um deles. A partir dela, o usuário poderá acessar a pasta de cada
componente.
Figura A.15 – Tela do Catálogo
136
Diagrama Hierárquico de Funções
137
138
Modelo Entidade-Relacionamento (MER)
ASSET FILE
# NAME
o MIME_TYPE
o DOC_SIZE
* CREATOR
o CONTENT
CONTENT corresponde
# ID
* NAME
* ITEMTYPE
o CORNERID compõe
* TYPE
o TOPICID possui
o TITLE
o AUTHOR ASSET
o DESCRIPTION # ID
o KEYWORDS corresponde o NAME é composto TYPES
o FILENAME o VERSION # ID
* ACTIVE é representado * NAME
o DOC_ID
* CREATEDATE o CMP_ID o IS_DOC
o EXPIREDATE corresponde
o XML
* SEQ
o CONTEXT_URL
classifica
é é é analisado
representa
representa
DOCUMENT
# ID está associado COMPONENT
o CMP_ID # ID
possui o IMAGE
USER
# NAME
* DISPLAY_NAME
o NOTIFICATION_PREFERENCE
o LANGUAGE
o EMAIL_ADDRESS
participa o EXPIRATION_DATE analisa
é composta pode ser ANALYSER

# TYPE
corresponde * ANALYSER
HIERARCHY
# NAME
o SUPERIOR
Dicionário de Dados
139
140
141
142
143
Definição de Tipo de Documento XML (DTD)
<!DOCTYPE ATIVO [
<!ELEMENT NOME (#PCDATA)>
<!ELEMENT VERSAO (#PCDATA)>
<!ELEMENT TIPO (#PCDATA)>
<!ELEMENT COMPONENTE_ASSOCIADO (#PCDATA)>
<!ELEMENT PALAVRAS_CHAVE (#PCDATA)>
<!ELEMENT DESCRICAO (#PCDATA)>
<!ELEMENT AUTORES (#PCDATA)>
<!ELEMENT DATA_CRIACAO (#PCDATA)>
<!ELEMENT AREA_DOMINIO ()>
<!ELEMENT SUGESTOES_USO (#PCDATA)>
<!ELEMENT PRE_REQUISITOS (#PCDATA)>
<!ELEMENT SERVICOS_OFERECIDOS (#PCDATA)>
]>
144
Glossário
API (Application Programming Interface) – Interface de Programação de Aplicações.

Conjunto de serviços oferecidos por uma biblioteca ou componente para os seus usuários.
Define o ‘protocolo’requerido para usar o componente.
Aprovado com Maiores Correções - Tipo de resultado de uma avaliação de um componente,

usado no processo definido no repositório ProReuso, apresentado no capítulo 6. Esse
resultado é fornecido quando o avaliador acredita que há erros graves no componente que
precisam ser corrigidos.
Aprovado com Menores Correções - Tipo de resultado de uma avaliação de um

componente, usado no processo definido no repositório ProReuso, apresentado no capítulo 6.
Esse resultado é fornecido quando o avaliador acredita que há erros simples no componente
que precisam ser corrigidos.
Avaliador – Funcionário da empresa responsável pela avaliação de componentes submetidos

ao repositório. Um componente pode passar por um ou mais avaliadores durante o processo de
avaliação, porém essa passagem é feita de forma sequencial, não havendo, portanto, mais de
um avaliador o avaliando num mesmo instante. Assim, a palavra aprovador refere-se aquele
que no momento está avaliando o componente.
Processo – série de etapas específicas que devem ser executadas para a realização de um
determinado objetivo. A ordem e a natureza das etapas se alteram de acordo com as
condições.
Status de aprovação – Resultado de avaliação de componentes fornecido por um avaliador. O
resultado pode ser de quatro tipos: Aprovado, Aprovado com Maiores Correções, Aprovado
com Menores Correções e Rejeitado.
Superior Imediato – Funcionário imediatamente acima de outro determinado na hierarquia

145
da empresa. Palavra utilizada no contexto do processo de aprovação de componentes
implementado no repositório ProReuso, apresentado no capítulo 6; pode representar o chefe
do requisitante ou chefe de outro chefe.
Reusabilidade – grau no qual um módulo de software ou outros produtos gerados no

desenvolvimento podem ser usados em mais de um programa de computação ou sistema de
software [IEEE, 1990].
Workflow – Basicamente, é uma sequência de ações ou etapas utilizadas em processos

corporativos ou comerciais. O workflow automatizado aplica a tecnologia do correio
eletrônico ao processo de workflow, para a notificação de participantes do processo. No
repositório ProReuso tem uma implementação de um workflow automatizado.
146
Referências Bibliográficas
[ALBUQUERQUE 2000] ALBUQUERQUE, Fernando. JavaBeans & Enterprise

JavaBeans. Notas de aula. Disponível na Internet.
Error! Bookmark not defined., 2000
[ANTHES 1998] ANTHES, Gary H. Learning How to Share. Revista

ComputerWorld, 23 -fev-1998. Disponível na Internet.
Error! Bookmark not defined.,1998.
[APPLETON 2000] APPLETON, Brad. Patterns and Software: Essencial Concepts

and Terminology. Disponível na Internet.
[ARANOW 1994?] ARANOW, Eric. Software Reuse: Because the Waters are Rising.
Disponível na Internet.
Error! Bookmark not defined., [1994?]
[BADCOCK 1998] BADCOCK, Charles. Repositories Reap E-Commerce Role.

[BASILI et al., 1996] BASILI, Victor R., et al.. How Reuse Influences Productivity in
Object-Oriented Systems. In: Communication of the ACM No 10,
outubro de 1996. v. 39.
[BAY 1998] BAY, Marcelo Peixoto. Introdução às “Markup Languages”.

[CHOUDHURY 1995] CHOUDHURY, Islam. A Perspective on Software Reuse.

[EZRAN et al. 1999] EZRAN, Michel, et al.. Practical Software Reuse: The Essencial
guide.[s.l : s.n],1999.185 p
[FAVARO et al. 1998] FAVARO, John M., et al.. Value Based Software Reuse
Investment. In: Annals of Software Engeneering, 1998. v.5, p.5-52
[FAYAD 1997] FAYAD, Mohamed E., SCHMIDT, Douglas C.. Object-Oriented

Application Frameworks. In: Communications of ACM. No 10,
outubro 1997. v. 40, p. 32-38.
147
[FONSECA 1999] FONSECA, Nuno. Corba - Um suporte para a Computação
Distribuída. Disponível na Internet.
[GAMMA et al. 1995] GAMMA, Erich et al..Design Patterns: Elements of Reusable

Object-Oriented Software. Addison Wesley, 1994. 416p.
[GONSALVES 1998] GONSALVES, Antone. Component Boom Matures Repositories.

[GRAHAM 1999] GRAHAM, Ian, QUIN Liam XML Specification Guide [s.l]:
Willey Computer Publishing,1999. 431p.
[GRISS 1998] GRISS, Martin L..What next, now that we solved all reuse
problems? Disponível na Internet.
[KRUEGER 1992] KRUEGER, Charles W. Software reuse. In: ACM Computing

Surveys. No 2, junho 1992. v. 24, p.131-183.
[HENNINGER 1997] HENNINGER, Scott. An Evolutionary Approach to Constructing

Effective Software Reuse Repositories. In: : ACM Transactions on
Software Engineering and Methodology No 2, abril 1997. v. 6,
p.111-140.
[IEEE 1990] INSTITUTE OF ELECTRICAL AND ELETRONIC ENGINERS.

IEEE Standard Computer Dictionary: A Compilation of IEEE
Standard Computer Glossaries. Nova York: [s.n], 1990
[INTER 2000] ORACLE CORPORATION. Oracle Intermedia.

[KIRBY 1999] KIRBY, Castek McInnis. Component-based Desugn and Reuse.

[KWON et al. 1997] [KWON,Oh Cheon, et al.. Integration of Reuse Process and
Maintenance Process within a Software Configuration
Manegement Environment . Disponível na Internet.
[LEUNEN 2000] LEUNEN, Hans Van. Embedded Component Object Model put in
Perspective. Disponível na Internet.
148
[MSR 2000] MICROSOFT CORPORATION. Microsoft Repository. Disponível
na Internet.
[MONTEZ 1997] MONTEZ, C. Um Modelo de Programação para Aplicações de

Tempo Real em Sistemas Abertos, Monografia do Exame de
Qualificação de Doutorado, DAS, UFSC, Julho de 1997
[MOURIZIO et al., 2000] MOURIZIO, Morisio, et al.. Success and Failure in Software
Reuse, 25p, 2000. Trabalho não publicado.
[NETSCAPE 1998] NETSCAPE COMMUNICATIONS CORPORATION.Netscape

Component Developer’s kit. Chapter 2: About the CDK.
[OLIVEIRA 1999] OLIVEIRA, Rômulo Silva de. Linguagem Java: JavaBeans.

[OMG 1995] OBJECT MANAGEMENT GROUP. Corba Overview

[ORACLE 1999] ORACLE CORPORATION. Application Development Advisor.

10 Benefits of Using Components. Disponível na Internet.
[POULIN 1998] POULIN, Jeffrey S.. The Foundation of Reuse. Disponível na

Internet.
[ROTH 1999] ROTH, Bill Introduction to Enterprise JavaBeans Technology.

[SEACORD et al. 1998] SEACORD, Robert, et al.. Agora: A Search Engine for Software
Components. Disponível na Internet.
[SOUZA 1999] SOUZA, Clarissa de. Use Case and Class Documentation
Templates.1999 WhitePaper
[SUN 1997] SUN MICROSYSTEMS. JavaBeans API Specification.

[sl] : Graham Hamilton,1997. Capítulo 2: Fundamentals, p.9-11
149
[TRUMP 1997] TRUMP, Daniel. Using the WWW and the Internet to Support
Corporate Reuse. Disponível na Internet.
[BOOCH et al. 1999] BOOCH, Grady, et al.. The Unified Modeling Language User
Guide. 1.ed.Massachetts: Addison-Wesley, 1999.512p
[UREP 2000] UNISYS. Unisys Universal Repository. Disponível na Internet.

[WALSH 1998] WALSH, Norman. What Do XML Documents Look Like?.

[WEBDB 2000] ORACLE CORPORATION. Oracle WebDB 2.2.

Error! Bookmark not defined. , 2000
[WF, 2000] ORACLE CORPORATION. Oracle WebDB 2.2.

Error! Bookmark not defined. , 2000
[YE 199?] YE, Yunwen. Supporting Reuse-within-Development with Active

Reuse Repository Systems Boulder- Colorado,[199?]. 51p.
Proposta de dissertação (Mestrado em Ciência da Computação),
Universidade do Colorado, Boulder.
150

Reutilização de Componentes

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Reutilização de Componentes

Enviado por

Direitos autorais:

Formatos disponíveis

Caroline Batista Spencer Holanda

Clarissa Angélica de Almeida de Souza

Gostaríamos de agradecer a todos aqueles que nos apoiaram, de alguma

A Deus pelo Seu amor, dando-nos a oportunidade de conhecimento, a benção

ProReuso: Um Repositório de Componentes para Web

Alcançar o máximo de qualidade, produtividade e eficiência no

TABELA 2.1 - EXEMPLOS DE ATIVOS VERTICAIS ....................................................................................................22

Este capítulo apresenta, inicialmente, os fatores que motivaram a realização deste

Por muitos anos, tem-se vivido um verdadeiro caos no desenvolvimento de projetos de

1.5 – Organização do Trabalho

No capítulo 2, apresenta-se a teoria do reuso de software. Nele são introduzidos os

coerência com o nome da aplicação.

Pesquisadores e profissionais que se encontram envolvidos com a área de Engenharia de

Reuso de software é a prática sistemática de desenvolver ou atualizar novas aplicações

Na definição de reuso de software, encontra-se a palavra ativos de software pré-

Origem : Feito, Comprado

Uso : Vertical, Horizontal

Autor Ambiente de Desenvolvimento

Data Ambiente de Teste

Modelo de Projeto Documentação de Usuário Relatório de Teste Programa de Teste

Informação de Classificação Nível de Desenvolvimento

Figura 2.1- Modelo de Ativo

2.3- Oportunidades de Reuso

Uma vez entendido em que consistem os ativos de software reusáveis, faz-se

Os ativos de software são classificados quanto ao tipo de reuso em ativos verticais e

Exemplos de Ativos Verticais

Ativos Horizontais - são aqueles reusados entre aplicações de domínios diferentes.

Exemplos Ativos Horizontais Técnicos

Exemplos de Ativos Horizontais Genéricos

2.5 - Características de um Ativo Reusável

Para se determinar a reusabilidade de um ativo, esse deve passar por um processo de

- Composição: ativos podem ser agrupados para formar ativos de maior

- Localização transparente: componentes podem rodar em diferentes máquinas,

- Segurança: como componentes correspondem a códigos executáveis e são

- Plug and Play : a portabilidade do componente não é exigida apenas quando

2.6 – Formas de Reuso

Estratégia de Implementação de um Ativo de Acordo com sua Forma

Modelos de Modelos de requisitos, sobre o qual o produto foi Comparação

- simplificação do desenvolvimento de software;

Muitos desses benefícios são consequências de outros e um resumo deles foi

2.9 – Considerações Finais

Nesse capítulo foram apresentados aspectos relacionados ao reuso de software.

No capítulo anterior foi mostrado aspectos relacionados ao reuso de software e sua

3.1 – Técnicas Orientadas a Objetos

As técnicas orientadas a objeto (TOO) representam estratégias para organizar sistemas

Originalmente nomeados no inglês de design patterns, padrões de projeto significam

Dá-se o nome de linguagem de padrão para uma coleção estruturada de padrões de

3.3 - Frameworks de Aplicação

Como foi citado anteriormente, os padrões abrangem outros níveis de abstração

3.3.1- Arquitetura CORBA

SGBDs, como Oracle e Sybase e ORBs, como Orbix, Visibroker e DCOM.

• ORB (Object Request Broker) é o middleware responsável por todos os

• Serviços de Objetos são coleções de serviços (interfaces e objetos) que suportam

Figura 3.1 - Arquitetura CORBA

3.4 - Desenvolvimento Baseado em Componentes

O desenvolvimento de sistemas baseado em componentes consiste na técnica de

Com se pode ver a técnica de desenvolvimento baseado em componentes representa

Benefícios do uso de componentes

Menos tempo gasto para testar

Apesar de todos esses benefícios, o desenvolvimento baseado em componente requer

Active X é a solução da Microsoft para componentes reusáveis. Ela é construída em

1) Gerência de Propriedades e Customizações: responsáveis por todas as

2) Introspecção: mecanismo pelo qual componentes tornam sua estrutura