XXV Encontro Nac. de Eng.

de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

Uma proposta de um processo prático para apoiar o reuso de software

Rosangela Kronig (UNIP) rkronig.mes.engprod@unip.br

Ivanir Costa (UNIP) icosta@unip.br
Mauro Spínola (UNIP) mspinola@unip.br

Resumo
A evolução da Engenharia de Software tem avançado consideravelmente nas últimas
décadas, principalmente com o uso do paradigma de objetos, permitindo que a proposta de
reutilização de funcionalidades, de regras de negócios ou mesmos de dados levaram à
necessidade de uma nova proposta de processo para apoiar o desenvolvimento de softwares
baseados em componentes.
Esse processo é necessário na aplicação de uma abordagem de reuso de software exige a
construção de um ambiente de informações que suporte a desde a descoberta, definição,
documentação até a distribuição desses componentes.
Palavras-chave: Administração de dados; Reuso de software; Componentes.

1. Introdução
O objetivo deste artigo é apresentar um processo de Administração de Componentes como
apoio ao desenvolvimento estruturado e padronizado de software baseado em componentes,
relacionando suas atividades e um conjunto de tecnologias necessárias para sua efetiva
implementação.
A proposta desse processo baseia-se nas premissas da Administração de Dados, que surgiu
com a finalidade de dar suporte ao desenvolvimento de sistemas baseados em banco de dados,
promovendo a conceituação, segurança, integridade e compartilhamento dos dados
corporativos armazenados.
Inicialmente serão apresentados os fundamentos do processo da Administração de Dados para
embasamento do processo da Administração de Componentes. De acordo com Pall (1987),
um processo pode ser definido como uma organização lógica de pessoas, materiais,
equipamentos, informações e procedimentos em atividades de trabalho orientadas a produzir
um determinado resultado final.
2. Administração de dados
No período de 1980, os conceitos da Engenharia de Informação foram definidos por James
Martin e Clive Finkenstein. A premissa básica da Engenharia da Informação é que os dados
permanecem no centro dos sistemas de informações e formaliza as técnicas pelas quais os
dados são criados. (MARTIN & FINKELSTEIN, 1985).
Neste mesmo período, surgiu a Administração de Dados como “uma função da empresa
responsável por desenvolver e administrar centralizadamente estratégias, procedimentos,
práticas e planos capazes de disponibilizar os dados corporativos necessários, quando
necessário, revestidos de integridade, privacidade, documentação e compartilhamento.”
(BARBIERI, 1994).
3. Processo de administração de dados
O Processo de Administração de Dados corresponde a um conjunto de atividades, cuja missão
é disponibilizar e manter a informação como um diferencial competitivo do negócio.

ENEGEP 2005 ABEPRO 4243

 XXV Encontro Nac. de Eng. de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

As atividades mais evidentes estão diretamente associadas ao desenvolvimento e manutenção

de sistemas. Dentro deste contexto é necessário caracterizar os papéis desempenhados e as
principais atividades.
Os seguintes papéis estão envolvidos com o processo de Administração de Dados:
− Administrador de dados (A.D.), responsável pelo planejamento, integração, segurança e
disponibilização da informação como um recurso necessário aos processos de negócio.
Gerencia o armazenamento e utilização dos dados nos aspectos relacionados à integridade,
reutilização e segurança dos mesmos, assegurando uma documentação íntegra e de fácil
acesso;
− Administrador de Banco de Dados (D.B.A.), responsável pelo mapeamento do modelo de
dados em projetos de implementação, criação, manutenção, administração e otimização do
SGBD (BARBIERI. 1994);
− Analistas de sistemas, envolvidos com as atividades de análise, modelagem e projeto de
banco de dados. As atividades são apoiadas e executadas através de técnicas, ferramentas,
normas e procedimentos estabelecidos no processo de Administração de Dados;
− Analistas de negócio, envolvidos com o levantamento dos requisitos de negócios,
identificando as informações necessárias para dar suporte aos objetivos corporativos.
Destacamos as atividades relacionadas com as funções do Administrador de Dados,
responsável pelo trabalho metodológico e conceitual dos dados (BARBIERI, 1994):
− Identificar e compreender as necessidades de informação: presentes e futuras;
− Definir responsabilidades sobre os dados: geração, atualização e consulta;
− Definir critérios de segurança, proteção, integridade e privacidade dos dados;
− Desenvolver e implementar políticas, procedimentos e padrões para a criação e
manipulação dos modelos de dados;
− Acompanhar, orientar e homologar os modelos de dados;
− Orientar no uso das técnicas, ferramentas de apoio à modelagem de dados, conceitos
corporativos etc;
− Estabelecer o controle centralizado dos dados: dicionário de dados.
O Processo de Administração de Dados utiliza-se dos seguintes recursos:
− Uma metodologia de desenvolvimento de sistemas, alinhada com as premissas da
Administração de Dados;
− Um conjunto de técnicas para o desenvolvimento de sistemas em todas as fases, entre elas:
JAD para levantamento de dados, modelagem de dados para análise e projeto de banco de
dados, análise por pontos de função, entre outras;
− Uso de padrões para a incorporação de conceitos de dados, através de um glossário de
termos,
− Ferramenta para apoio às técnicas utilizadas, destacando-se as ferramentas CASE,
− Repositório de dados para o armazenamento, a busca e a recuperação de modelos e todas
as informações relacionadas.
Com a estruturação do processo de Administração de Dados, os seguintes produtos são
implementados:
− Fluxo do processo de administração de dados com a descrição detalhada das atividades;
− Roteiros de execução e responsabilidades das atividades;
− Check-list das atividades;
− Manual de normas e padronização;

ENEGEP 2005 ABEPRO 4244

 XXV Encontro Nac. de Eng. de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

− Manual técnico de modelagem de dados;

− Guia de utilização de ferramentas.
A figura 1 apresenta uma macro-visão do Processo de Administração de Dados, em um
ambiente de desenvolvimento de sistemas clássico.

Figura 1. Visão macro do Processo de Administração de Dados

4. Administração de componentes
A seguir, serão apresentados os fundamentos da Administração de Componentes necessários
para o entendimento da proposta.
5. Ambiente de desenvolvimento baseado em componentes
A solução de um problema, muitas vezes, é baseada na aplicação de uma solução similar que
já foi desenvolvida ou adaptada para resolver um outro problema. O mesmo raciocínio pode
ser aplicado na Engenharia de Software, para solução de um problema computacional. Desta
forma, partes de software já desenvolvidas podem ser utilizadas novamente para auxiliar na
solução de um novo problema (ROSSI, 2004).
O desenvolvimento baseado em componentes (CBD) ou a Engenharia de Software baseada
em componentes (CBSE), consolidou-se no final de 1990 com uma abordagem baseada no

ENEGEP 2005 ABEPRO 4245

 XXV Encontro Nac. de Eng. de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

reuso, motivada pela frustração de que o desenvolvimento orientado a objetos não tinha
conduzido a um efetivo reuso, como originalmente foi sugerido (SOMMERVILLE, 2003).
Segundo Vitharana et al (2003), várias abordagens de desenvolvimento, da estruturada a
orientada a objetos, tinham como propósito reduzir o risco e o custo de desenvolvimento. O
desenvolvimento baseado em componentes é uma evolução dessas abordagens, pois tem
como conceito construir um todo integrado a partir de partes padronizadas e independentesO
artigo deve ser escrito no programa Word for Windows, em versão 6.0 ou superior. Se você
está lendo este documento, significa que você possui a versão correta do programa.
6. Componentes
O conceito de componente é extremamente abrangente, pois componente pode ser algo tão
simples quanto um elemento de uma interface gráfica ou tão complexo como uma
funcionalidade completa de um sistema. Os princípios que definem a tecnologia orientada a
objetos são elementos importantes para a evolução do conceito de componentes de software.
Segundo Costa (2003), “o paradigma da orientação a objetos traz enormes benefícios ao
desenvolvimento de software, pois ela torna o desenvolvimento e a manutenção muito mais
fáceis. A aplicação correta do paradigma de objetos, com uso de encapsulamento de
componentes, dos mecanismos de herança e polimorfismo tem produzido softwares cada vez
mais simples, possibilitando a aplicação intensiva do reuso”.
Um componente é uma unidade de composição e deve ser especificado de tal forma, que é
possível compô-lo com outros componentes e integrá-los nos sistemas de uma maneira
previsível. Deve ter suas interfaces claramente documentadas e a sua implementação
encapsulada (CRNKOVIC et al.,2003).
7. Reuso de Software
O reuso de software tem sido praticado há muitos anos, à medida que estes sistemas de
software são implementados em uma série de máquinas e adaptados para diferentes ambientes
(SOMMERVILLE, 2003).
Muitos dos sistemas de software que construímos são semelhantes. Há características comuns
entre sistemas com propósitos semelhantes. Portanto, deve-se considerar estes sistemas,
avaliar seus componentes e determinar suas adaptações ou até mesmo reutilizá-los por
completo na construção de um novo sistema (PFLEEGER, 2004).
Entende-se por reuso, o uso de um artefato na solução de problemas diferentes (IEEE-Std
1517–1999) e por reuso de software, um artefato de software desenvolvido em outro lugar -
em outro projeto ou em outra companhia e utilizado em mais de um contexto, com ou sem
modificações (MORISIO et al, 2000).
Um outro conceito importante é o de reusabilidade, que estabelece o grau para o qual um
artefato de software pode ser utilizado em mais de um sistema de software ou na construção
de outros artefatos de software (IEEE-Std 1517–1999).
Paralelamente a abordagem de reuso, temos o conceito da análise de domínio, que segundo
Pressman (2000), tem por objetivo identificar, analisar e especificar os requisitos comuns de
um domínio de aplicação específico, para reuso em vários projetos dentro do domínio da
aplicação.
Sommerville (2003), usa o conceito de “famílias de aplicações”, ou linha de produtos, para
caracterizar um conjunto de aplicações relacionadas e que têm uma arquitetura de domínio
específico em comum. O núcleo em comum da família de aplicações é reutilizado cada vez
que uma nova aplicação é requerida.

ENEGEP 2005 ABEPRO 4246

 XXV Encontro Nac. de Eng. de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

8. Infra-estrutura para especificação, controle e armazenamento de componentes

No processo de desenvolvimento de sistemas através da utilização de componentes, é
necessário descrever, compreender e identificar como integrá-los com outros componentes.
Uma forma de representar este conjunto de informações é através de uma linguagem padrão
de modelagem, como a UML (Unified Modeling Langauge), que define como modelar
componentes através de seu metamodelo (HOPKINS, 2000).
A UML é uma linguagem para especificação, visualização, construção e documentação de
sistemas de softwares, bem como para modelagem de negócios e outros sistemas não ligados
a softwares (FOWLER & SCOTT, 2000).
Embora o UML seja uma linguagem de modelagem e não um método de software, ela fornece
um conjunto de notações (principalmente gráficas) que podem ser usadas nas várias fases no
ciclo de vida de um software (KOBRYN, 2000).
Ainda segundo Kobryn (2000), os componentes na UML são modelados tipicamente nos
diagramas de implementação, tais como diagramas de componentes e diagramas de utilização
(deployment diagram). Um diagrama de componentes mostra a organização e as dependências
dos componentes, e um diagrama de utilização mostra como os componente são acessados
em nós computacionais.
A UML suporta a modelagem de componentes, desde a modelagem lógica, através do
diagrama de classes, passando pela modelagem física, através dos diagrama de componentes e
diagrama de utilização ou deployment diagram. Desta forma, conforme Hopkins (2000), ela
permite a rastreabilidade do componente através destes diagramas, desde a especificação
lógica, passando pela definição do componente, até a execução.
Um outro aspecto a ser considerado é o controle sobre as mudanças do componente durante o
desenvolvimento e as possíveis manutenções. Uma gerência de configuração deve garantir a
integridade do componente ao longo de seu ciclo de vida, identificando, organizando,
rastreando e controlando as suas modificações.
Para Pressman (2002), uma relação de recursos deve fazer parte da infra-estrutura de um
ambiente de apoio à reutilização de componentes de software, que são:
− Base de dados de componentes capaz de armazenar os componentes de software e
classificar a informação necessária para recuperá-los;
− Sistema de gerência de biblioteca que forneça acesso à base de dados de componentes;
− Sistema de recuperação de componentes de software que possibilite uma aplicação cliente
recuperar os componentes e os serviços a partir do servidor de biblioteca;
− Ferramentas de engenharia de software baseada em componentes que forneçam suporte à
integração de componentes reutilizáveis em um novo projeto ou implementação.

Cada um destes recursos interage ou está incorporado a uma biblioteca de reutilização.

9. Processo de Administração de Componentes
Semelhante ao processo de Administração de Dados, o processo de Administração de
Componentes também é composto por um conjunto de atividades, ferramentas, papéis e
responsabilidades, cuja missão é apoiar e promover o reuso de componentes de software,
permitindo a redução do custo e do tempo de desenvolvimento de sistemas.
No processo de Administração de Componentes destacam-se os seguintes papéis:
− Administrador de componentes, responsável por gerenciar o conjunto de informações e
artefatos relacionados aos componentes reutilizáveis;

ENEGEP 2005 ABEPRO 4247

 XXV Encontro Nac. de Eng. de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

− Administrador de configuração de componentes, responsável por armazenar, catalogar e

divulgar os componentes reutilizáveis para construção de novos sistemas;
− Analistas de sistemas, responsáveis pelas atividades de análise, modelagem e projeto de
componentes. As atividades são apoiadas e executadas através de técnicas, ferramentas,
normas e procedimentos estabelecidos no processo de Administração de Componentes;
− Analistas de negócio, envolvidos com o levantamento dos requisitos de negócios,
identificando as informações necessárias para dar suporte aos objetivos corporativos;
− Programação, área responsável pela codificação e teste dos componentes.

Destacamos as principais atividades relacionadas da Administração de Componentes,

responsável pelo trabalho metodológico e conceitual dos componentes:
− Definir responsabilidades sobre os componentes: construção, manutenção e consulta;
− Definir critérios de segurança, proteção, integridade, certificação e privacidade dos
componentes;
− Desenvolver e implementar políticas, procedimentos e padrões para a construção,
manutenção, classificação, catalogação e certificação dos componentes;
− Orientar a confecção de componentes, através de padrões;
− Apoiar quanto ao uso de componentes reutilizáveis;
− Homologar a implementação de novos componentes;
− Estabelecer o controle centralizado dos componentes: biblioteca ou repositório de
componentes.
− Infra-estrutura
− O Processo de Administração de Componentes deve ser apoiado pelos seguintes recursos:
− Uma metodologia de desenvolvimento de sistemas baseada em componentes, alinhada com
as premissas da Administração de Componentes;
− Um conjunto de técnicas para o desenvolvimento de sistemas baseado em componentes
para todas as fases, entre elas: JAD para levantamento de requisitos, UML, Use Case
points, entre outras;
− Uso de padrões;
− Ferramentas para apoio às técnicas utilizadas, destacando-se as ferramentas CASE;
− Um repositório ou uma biblioteca para armazenamento, busca e recuperação de
componentes e toda a informação relacionada. Uma biblioteca inclui uma base de dados,
um dicionário de sinônimos e as ferramentas para consultas e recuperação dos
componentes.

Com a estruturação do processo de Administração de Componentes, os seguintes produtos são

implementados:
− Fluxo do processo de administração de componentes com a descrição detalhada das
atividades;
− Roteiros de execução e responsabilidades das atividades;
− Check-list das atividades;
− Manual de normas e padronização;
− Manual técnico;
− Guia de utilização de ferramentas.

A figura 2 apresenta uma macro-visão do Processo de Administração de Componentes.

ENEGEP 2005 ABEPRO 4248

 XXV Encontro Nac. de Eng. de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

Figura 2. Visão macro do Processo de Administração de Componentes

10. Conclusão
O ambiente de desenvolvimento baseado em componentes (CBD) está se tornando o principal
modelo de desenvolvimento de software, com uma abordagem voltada para a produtividade e
benefícios da reutilização. Porém, a implementação da reutilização de software exige
mudanças conceituais, culturais e tecnológicas no processo de desenvolvimento de sistemas.
Neste cenário, consolida-se a importância de implementar um ambiente estruturado,
padronizado e um conjunto de atividades e recursos organizados logicamente em um processo
denominado Administração de Componentes, para apoiar o estabelecimento e o
desenvolvimento de software baseado em componentes.

ENEGEP 2005 ABEPRO 4249

 XXV Encontro Nac. de Eng. de Produção – Porto Alegre, RS, Brasil, 29 out a 01 de nov de 2005

Utilizando-se como base as premissas da Administração de Dados, espera-se obter os

seguintes benefícios com a implementação de um processo de Administração de
Componentes:
− Padronização, facilitando a construção de novos sistemas;
− Redução no tempo de desenvolvimento, com uma administração centralizada dos artefatos
de softwares homologados e catalogados em uma biblioteca;
− Redução dos custos, com a utilização de artefatos de software reutilizáveis;
− Integração no desenvolvimento de sistemas; identificando os papéis e responsabilidades
envolvidas no processo.

A proposta do processo de Administração de Componentes, apresentada neste artigo, será

implementada e testada no ambiente de fábrica de software do Laboratório de Pesquisa de
Software do programa de Mestrado em Engenharia de Produção da UNIP – Universidade
Paulista.
Referências
BARBIERI, C. (1994) - Modelagem De Dados. Rio de Janeiro: Infobook.
COSTA, I. (2003) - Contribuição para o Aumento da Qualidade e Produtividade de uma Fábrica de Software
através da Padronização do Processo de Recebimento de Serviços de Construção de Softwares. São Paulo.Tese
de Doutorado – Escola Politécnica da Universidade de São Paulo
CRNKOVIC, I. et al. (2002) - Specification, implementation, and deployment of components. Communications
of the ACM, v. 45, n. 10, p.35-40.
FOWLER, M.; SCOTT, K. (2000) - UML Essencial, Brasil: Bookman, Porto Alegre.
HOPKINS, J. (2000) - Component Primer.Communications of the ACM, v..43, n. 10, p.27-30.
IEEE-Std 1517 (1999) - IEEE Standard for Information Technology—Software Life Cycle Processes—Reuse
Processes.
KOBRYN, C. (2000) - Modeling components and frameworks with UML. Communications of the ACM, v.
43, n.10, p.31-33.
MARTIN, J.; FINKELSTEIN, C. (1985) - Engenharia da Informação. São Paulo: Compucenter Sistemas,
Fascículo 1-3.
MORISIO, M.; TULLY, C.; EZRAN, M..(2000) - Diversity in reuse processes. IEEE Software, v. 17, n.4, p.56-
63.
PALL, G.(1987) - Quality Process Management. Prentice Hall.
PFLEEGER, S. L.(2004) - Engenharia de Software: Teoria e Prática. 2º ed. São Paulo: Prentice Hall.
PRESSMAN, R.S. (2002) - Engenharia de Software. 5º.ed.. Rio de Janeiro: McGraw-Hill.
ROSSI, A.C. (2004) - Representação do Componente de software na FARCSoft: ferramenta de apoio à
reutilização de componentes de software. São Paulo. Tese de dissertação - Escola Politécnica, Universidade de
São Paulo. São Paulo.
SOMMERVILLE, I.(2003) - Engenharia de Software. 6ed., São Paulo: Addison Wesley.
VITHARANA, P; ZAHEDI, F.M.; JAIN, H.(2003) - Knowledge-based repository scheme for storing and
retrieving business components: a theoretical design and an empirical analysis. IEEE Transactions on Software
Engineering, v.29, n.7, p.649-664.

ENEGEP 2005 ABEPRO 4250