1
Desenvolvimento de Sistemas de Informação com Objetos de Negócio:
Proposta de um Guia para Análise da Reutilização de Software
Autores: Décio Bittencourt Dolci e João Luiz Becker
Resumo:
A aceitação do Paradigma do Objeto como referência para o desenvolvimento de sistemas de
informação torna-se cada vez mais efetiva. A visão da obtenção de sistemas a partir da
composição de objetos de negócios é aclamada com muitas promessas. Provavelmente, a que
desperta maior atenção é a do incremento da reutilização de software. Este artigo apresenta
um guia para análise do processo de reutilização de software específico para o contexto
orientado a objetos de negócios. O guia compõe-se de um modelo analítico e de grades de
análise, que objetivam classificar e tabular dados obtidos empiricamente. Espera-se que o
instrumental proposto seja útil tanto para o meio acadêmico como para as organizações. Na
academia, pode auxiliar em pesquisas com hipóteses relacionadas ao tema. Nas organizações
que desenvolvem sistemas de informação com a Tecnologia do Objeto, pode facilitar a análise
do processo de reutilização de software realizado pela organização. Para ilustrar o guia, há
um exemplo de uso, em que se demonstram formas de avaliar a reutilização, destacando-se a
questão econômica, pois uma das mudanças prometidas é que, além da liberdade para
comprar e montar a solução, novas escalas de vendas serão atingidas, resultando redução nos
custos dos sistemas.
1. Introdução
A expressão “Crise do Software” tem sido usada para expressar a insatisfação
generalizada com a incapacidade de atendimento à demanda por software e a erros
apresentados pelos softwares após liberados para os clientes (Sohn e Dejnaronk, 1998).
Segundo alguns autores (Martin e Odell, 1992; Tapscott, 1995), a base dos problemas está no
fato de a maioria dos sistemas de informação ainda serem construídos de forma artesanal,
quase sempre inviabilizando o aproveitamento de trabalhos previamente desenvolvidos. Essa
forma não produtiva, além de desperdiçar recursos, ainda propicia pouca confiabilidade aos
softwares.
A saída para tal situação está em desenvolver técnicas semelhantes às utilizadas nas
demais engenharias, em que é construído o todo, extremamente complexo, a partir de
componentes (Tapscott, 1995). Vários autores propoem a adoção de tecnologias, métodos e
metodologias baseados no Paradigma do Objeto (Coad e Yordon, 1991; Jacobson et al., 1992;
Martin e Odell, 1992; Booch, 1994; Rumbauch et al., 1994) como solução para os problemas
citados anteriormente. 1
Embora haja aceitação crescente do Paradigma do Objeto como referência para o desenvolvimento de sistemas de informação, ainda são poucos os casos envolvendo objetos e
componentes de negócio e, mais raros ainda, aqueles em que montadores criam seus
aplicativos a partir de objetos fornecidos por terceiros. De fato, ainda que o boletim do
International Data Corporation (IDC) apresente as estratégias e características de três projetos
1 Embora na literatura recente o termo “Paradigma do Objeto” seja encontrado com freqüência, a expressão Orientado a Objeto (OO) é a mais utilizada, principalmente por
seus precursores. Como uma nova área do conhecimento da Tecnologia da Informação (TI) é denominada Tecnologia do Objeto (TO), abrangendo todo o conhecimento com
princípios científicos, relacionado à Orientação a Objeto (Johnson e Hardgrave, 1998).
2
baseados na arquitetura de componentes - IBM San Francisco, SAP R/3 Component
Architectures e Baan - até a data de sua publicação (março de 1998), apenas os primeiros
aplicativos a partir do IBM San Francisco estavam disponíveis no mercado (Byron, 1998).
Apesar da pouca ocorrência na prática, trabalhos fundamentais na organização da
Tecnologia do Objeto têm sido realizados, especialmente de padronização. Dentre várias
iniciativas, merecem destaque os trabalhos realizados pelo Object Management Group
(OMG) 2, consórcio internacional, com mais de 700 associados. Entre os primeiros segmentos
de negócios a serem organizados estão saúde, finanças, telecomunicações, manufatura,
transporte e comércio eletrônico. No Brasil, o Consórcio de Componentes de Software para
Sistemas de Informação em Saúde (CCS⋅SIS) 3 é o grupo mais consolidado. A definição de
padrões obtidos por consenso em consórcios de entidades provavelmente será seguido em
outras áreas.
O contexto apresentado sinaliza a proximidade da “Revolução Industrial em Software”
referida em Tapscott (1995). Perceber de forma clara e objetiva os avanços que vêm sendo
obtidos em relação à reutilização de software nesse novo processo de desenvolvimento é de
suma importância para a tomada de decisão daqueles que determinam a forma de desenvolver
sistemas, buscam novos espaços na cadeia produtiva ou contratam sistemas de informação.
Com base nesta necessidade, este artigo apresenta um guia para análise da reutilização
de software contextualizado no desenvolvimento de sistemas de informação a partir de
objetos de negócios. O guia compõe-se de um modelo analítico e de grades de análise, que
objetivam classificar e tabular dados obtidos empiricamente. Espera-se que o instrumental
proposto seja útil tanto para o meio acadêmico como para as organizações. Na academia,
pode auxiliar em pesquisas com hipóteses relacionadas ao tema, tornando possível a obtenção
de evidências, com rigor científico e de forma abrangente, que as corroborem ou não. Nas
organizações que desenvolvem sistemas de informação com a Tecnologia do Objeto, pode
facilitar a análise do processo de reutilização de software realizado pela organização.
A idealização do instrumento está baseada na experiência em Tecnologia da Informação
dos autores; em extensa revisão bibliográfica sobre os temas Desenvolvimento de Sistemas,
Tecnologia do Objeto e Reutilização de Software; e do estágio tecnológico atual disponível
no mercado, percebido através da avaliação do projeto IBM San Francisco (IBM, 1998) e do
software Business Object Facility Lite da SSA Inc. (Eeeles e Sims, 1998).
Ao pesquisar tecnologias que prometem incremento na reutilização de software, esperase contribuir de duas maneiras: primeiro, com as organizações usuárias, que necessitam de
sistemas de informação que interajam e se adaptem rapidamente às mudanças do ambiente, para
cumprirem seus objetivos (Freitas et al.,1997); segundo, para o desempenho das empresas de
desenvolvimento de software (Nidumolu e Knotts, 1998).
O trabalho está organizado como segue: na seção 2 do texto subseqüente, expõe-se
resumidamente o referencial conceitual pertinente ao guia. Sua apresentação está na seção 3,
enquanto na seção 4, por meio de exemplificação, faz-se um exercício, demonstrando sua
aplicabilidade. Finalmente, a seção 5 contém as considerações finais, prospectando-se futuras
pesquisas e instrumentos a partir do guia.
2. Referencial Conceitual
Nesta seção apresentam-se os principais conceitos envolvidos com a construção do
guia de análise. São abordados aspectos sobre o processo de reutilização de software, as
tecnologias disponíveis e seus principais benefícios, objetos, componentes e processos de
2 Maiores detalhes podem ser obtidos em WWW:http://www.omg.org
3 Maiores detalhes podem ser obtidos em WWW:http://www.datasus.gov.br/ccssis
3
negócio, além dos padrões, atualmente em fase de definição. Destaca-se, também, como se
estabelecem as relações entre a Tecnologia do Objeto e a Reutilização de Software.
2.1. Reutilização de Software
A reutilização de software apresenta-se como o principal fator crítico de sucesso da
produtividade e qualidade no desenvolvimento de software. Algumas definições em relação ao
tema são encontradas em Hooper e Chester (1991). É necessário distinguir o conceito de
reutilização do conceito conexo de reusabilidade. Em geral, reusabilidade diz respeito à
medida em que o software pode ser usado (com ou sem adaptações) na solução de múltiplos
problemas ou na solução de um problema diferente daquele para o qual ele foi originalmente
desenvolvido. Já reutilização diz respeito à ação de sintetizar a solução para um problema,
decompondo-o em subproblemas para os quais haja soluções pré-definidas. Implementa-se
novos softwares a partir de outros pré- existentes. Percebe-se que, enquanto o termo
reusabilidade está associado a resultados, reutilização está a processo.
Vários são os benefícios percebidos pela reutilização de software. Agresti e McGarry
(1990) salientam benefícios relacionados com o aumento de produtividade (ao usarem-se
componentes já existentes), aumento de confiabilidade (ao usarem-se componentes já
testados), aumento de consistência (ao usarem-se os mesmos componentes em vários lugares)
e maior facilidade de gerenciamento (ao usarem-se componentes já compreendidos pelo
desenvolvedores). Salientam ainda os benefícios obtidos pela padronização.
Ao longo dos anos, pode-se perceber alguns exemplos da prática de reutilização de
software. Alguns exemplos seminais relevantes são bibliotecas de sub-rotinas matemáticas,
funções do sistema operacional e linguagens de quarta geração. Hoje em dia, entretanto, para
contemplar o tamanho e a complexidade dos softwares exigidos, a questão precisa ser
expandida (Hooper e Chester, 1991). Kim e Stohr (1998) observam que as metodologias
tradicionais de desenvolvimento de software não são direcionadas, ao menos de forma
explícita, para aproveitarem fontes reutilizáveis. Os autores apresentam, na forma de
diagrama de fluxo de dados, um modelo para desenvolvimento de sistemas baseado no
processo de reutilização, salientando três tipos de atividades: de preparação para a utilização,
de utilização propriamente dita dos recursos reutilizáveis, e de integração entre recursos (já
existentes e novos) para o desenvolvimento do software.
As metodologias de
desenvolvimento tradicionais focam apenas as atividades de especificação, construção e
integração, não considerando atividades como classificação de fontes reutilizáveis,
recuperação, entendimento e alteração dessas fontes.
As tecnologias empregadas para obtenção da reutilização podem ser classificadas em
duas: tecnologias de geração e tecnologias de composição (Kim e Stohr, 1998). Enquanto a
primeira cria o software a partir de moldes pré definidos, modo utilizado em geradores de
aplicações, a tecnologia de composição utiliza algo previamente desenvolvido e
especialmente armazenado para ser reutilizado. Os recursos armazenados distinguem-se
quanto à visualização de seu conteúdo. Aqueles que têm seu conteúdo encapsulado,
disponibilizam apenas a sua interface, podendo sofrer algumas alterações via configuração.
Em contraste, existem recursos que permitem modificações diretamente em seus conteúdos.
O guia proposto neste artigo focaliza tecnologias de composição, interessando-se tanto
por recursos com conteúdo visível e alterável, como por recursos em que o acesso é feito
apenas pela interface.
Segundo Agresti e McGarry (1990) a reutilização pode ser classificada por produto e
por processo. Enquanto a classificação por produto identifica o que é reutilizado, a
classificação por processo define de que modo o recurso é reutilizado. Tal orientação está
4
apresentada na tabela 1. Seus parâmetros são parcialmente utilizados no guia proposto,
ajustando-se as alternativas ao contexto da tecnologia do presente estudo.
PROCESSO
PRODUTO
Tabela 1 - Classificação da reutilização
Tipo
(Que tipo de recursos são
reutilizados?)
Modo
(Quão formais são os recursos
reutilizados?)
Estágio
(Qual é a abrangência da
reutilização?)
Atividade
(Em que fase ocorre a
reutilização?)
Mecanismo
(Como é efetuada a
reutilização?)
Extensão da mudança
(Quanta mudança é necessária?) Granularidade
(Quanto do produto é
necessário?)
-
Conhecimento (aplicações, etc.)
Documentação (requisitos, código, plano de teste, etc.)
Programas executáveis (ferramentas, bibliotecas, etc. )
Formal (sintaxe e semântica, somente sintaxe, etc.)
Conhecimento institucional (manuais, etc.)
Conhecimento pessoal (favor de um amigo, experiência, etc.)
Em todo o segmento
Em toda a empresa
Em todo o departamento
Em um projeto
No planejamento (previsão de custos, análise de riscos, etc. )
No desenvolvimento (requisitos, especificações, etc. )
Na manutenção (alteração nas funções, correção de erros, etc.)
Literalmente
Parametrizadamente
Com moldes
Sem regras
Nenhuma
Trivial (menos que 5%)
Média (entre 5 e 25%)
Grande(mais que 25%)
Sistema inteiro
Segmento
Pequena parcela
Fonte: Adaptado de Agresti e McGarry (1990, p. 35)
2.2. Sistemas de Informação com Objetos de Negócio
Diversos autores (Coad e Yordon, 1990; Martin e Odell, 1992; Jacobson et al., 1992;
Booch, 1994; Rumbaugh et al., 1994) dedicaram-se a definir e a explicar como pensar e
trabalhar com as tecnologias e metodologias Orientadas a Objeto. O paradigma do Objeto é o
resultado da evolução na forma como os problemas são decompostos. Neste paradigma
focalizam-se os objetos usados para modelar as entidades (aquilo que constitui a essência de
algo). Contrariamente, em outros paradigmas, o foco está nas funções necessárias e
desempenhadas pelo sistema (McGregor e Sykes, 1992). Na medida dos objetivos deste
artigo, salientam-se a seguir os conceitos diretamente relacionados ao contexto de objetos
orientados a negócios. O leitor interessado nos fundamentos e conceitos básicos da
orientação a objeto são referenciados aos autores acima citados ou a Snyder (1993), que
resume os principais termos e conceitos.
O OMG define objeto de negócio como a representação de algo operante no domínio
dos negócios em geral. O objeto de negócio pode representar pessoas, lugares, eventos,
processos de negócio ou conceitos. Exemplos típicos são: um empregado, um produto, uma
fatura, um pagamento, etc. A evolução da modelagem, desde o levantamento dos requisitos
até o objeto em tempo de execução, pode ser vista na figura 1. Inicialmente, um conceito de
negócio é identificado como um objeto de negócio; durante o projeto ele é representado por
uma classe, geralmente na forma de diagrama; e a implementação dá-se através de uma classe
escrita em linguagem de programação.
5
Figura 1 – Evolução da representação do Objeto de Negócio
Fonte: Eeles e Sims (1998, p.6)
Eeles e Sims (1998) citam a necessidade de algo que supere o nível teórico. Sugerem
pensar no objeto de negócio como um componente de software, viabilizando coisas “plugged
and played”. Para os autores, um componente de software é um conjunto especial de código
que, principalmente, tem um “plug” bem definido, podendo ser conectado num soquete
específico, que pode ser usado para conectar diferentes componentes (tantos quantos tiverem
o mesmo “plug”). Quando tais componentes são orientados a negócios, são chamados
componentes de negócio.
Denominam-se componentes de processo de negócio os componentes que têm
características centradas no processo de negócio. Um processo de negócio é formado por um
conjunto de atividades relacionadas. Um exemplo trivial seria o processo realizar venda,
composto pelas atividades receber pedido, checar crédito, verificar estoque, providenciar
embarque, emitir nota fiscal, etc. Pode haver uma seqüência pré-determinada entre as
atividades, sendo possível esta depender de uma decisão associada a alguma condição lógica.
Os objetos de negócio são classificados pelo nível de especialização do objeto, do
mais geral (componentes comuns a vários negócios) ao mais específico (componentes de
processos de negócios para uma determinada aplicação). A figura 2 compara a classificação
utilizada pelo projeto IBM São Francisco e a proposta por Eeles e Sims (1998), oferecendo
alguns exemplos concretos.
Classificação IBM SF
Classificação Eeles e Sims
Applications
Efetua reserva
Aluga moto
Process Business Components
Core Business Processes
produto
cliente
pedido
Entitity Business Components
Common Business Objects
calendário
país moeda
Utility Business Components
Services and Frameworks
Business Object Facility
Foundation and Utilities
Figura 2 – Classificação dos componentes de negócios
2.3. Reutilização de software com a Tecnologia do Objeto em Negócios
Antes de apresentar possíveis casos de reutilização de objetos e processos, dá-se
destaque à padronização, fator determinante para a comunicação entre pesquisadores e
desenvolvedores de sistemas de informação, facilitando a reutilização dos softwares. Visando
à padronização, o OMG coordena um trabalho de especificação bastante amplo. A figura 3
apresenta as especificações desenvolvidas pelo OMG relativas à linguagem de modelagem
Linguagem de
Modelagem
Unificada
FINANÇAS
Outros Domínios
Verticais
Objetos de Negócios Comuns
(BOF) Facilidades p/ operar Objetos de negócio
CORBA Facilidades comuns
CORBA Serviços comuns
Interoperabilidade
opções de empacotamento
Componentes
Intermediário,ling. para a interface
Segurança
UML
Definições Fundamentais
SAÚDE
6
unificada (do inglês “Unified Modeling Language” - UML). As três últimas camadas dizem
respeito aos objetos de negócio. Na última camada situam-se as definições relativas aos
segmentos de negócios, ou domínios verticais, como denominados pelo OMG.
Figura 3 – Especificações da OMG
Fonte: adaptado de Siegel (1998)
Nas grades do anexo 1 a UML 4 assume papel extremamente relevante, pois grande
parte do que é questionado em termos de instrumentos para a reutilização nas fases de análise
e projeto está baseado no que a UML dispõe. Julga-se desnecessário acrescentar outros
métodos, dada a tendência de uso da UML para modelar sistemas (Hardgrave e Douglas,
1998). Os principais usos da UML são: mostrar as fronteiras e principais funções do sistema;
ilustrar as possíveis interações entre seus objetos; representar a estrutura estática do sistema;
modelar o comportamento dos objetos e determinar a arquitetura de implementação física.
Também permite, através de estereótipos, certa expansão da própria linguagem. Pode-se, por
exemplo, criar estereótipos para identificar as classes como: de interface, de controle ou de
entidade. Os tipos de diagramas e indicações de uso são apresentados em Flower e Scott
(1997) e Furlan (1998).
Apresentam-se a seguir alguns cenários de reutilização. A figura 4, representando
parte das classes necessárias em um sistema para reserva de veículos numa locadora, ilustra a
reutilização de objetos relacionada a entidades (objetos de negócios), enquanto a figura 5,
representando o diagrama de atividades que modela o processo de reserva de carro numa
locadora, ilustra a reutilização relacionada a processos (objetos de processos de negócios).
Unid. da Federcão
Veículo
fabricante
dia
modelo
mês
num assentos
nome
ano
Município
de retirada
Carro
sigla
Data
num registro
de devolução
aniversário
Cliente
Reserva
cor
valor diária
nome
num de portas
obterImposto(End))
telefone
local emplacamento
nome
De retirada
Endereço
rua
número
bairro
cep
Figura 4 – Diagrama de Classe para Locação de carros
Fonte: Adaptado de Eeles e Sims (1998)
4
Informações sobre a UML e suas atualizações podem ser encontradas em http://www.rational.com/uml
7
(A)
Atividade
Reserva
de Carro
Formulário
Cliente
Atividade
Reserva
de Carro
(B)
Visualiza
Clientes
Existentes
Especifica
Datas
Visualiza
Carros
Existentes
Localiza
Carro
Cria
Cliente
Localiza
Cliente
Atividade
Reserva
de Carro
Formulário
Cliente
Atividade
Reserva
de Carro
(C)
Visualiza
Clientes
Existentes
Especifica
Datas
Visualiza
Carros
Existentes
Localiza
Carro
Cria
Cliente
Localiza
Cliente
Autoriza
Crédito
Formulário
Atividade
Cliente
Reserva de
Apartamento
Visualiza
Atividade
Clientes
Reserva de
Apartamento Existentes
Especifica
Datas
Visualiza
Hoteis e
Apartamentos
Localiza
Apartamento
Cria
Cliente
Localiza
Cliente
Autoriza
Crédito
Figura 5 – Reutilização visualizada com o Diagrama de Atividade
Fonte: Adaptado de Eeles e Sims (1998)
Com o mecanismo de herança é possível uma especialização, novas classes são
acrescidas ao projeto sem alterar a classe da qual derivam. No exemplo ilustrado na figura 4,
a subclasse carro deriva da superclasse veículo. Em outros projetos que utilizam a mesma
superclasse veículo, poder-se-ia definir outras classe derivadas, como moto ou caminhão. No
mecanismo de herança, qualquer alteração na superclasse (classe de generalização) implicará
na subclasse (classe de especialização). Com o mecanismo de agregação 5, usam-se classes
definidas anteriormente para compor outras de maior granularidade. No exemplo apresentado
na figura 4, as classes endereço e data (previamente definidas) agregam-se à definição, como
atributos, da classe cliente, assim como unidade da federação e município (previamente
definidas) compõem o endereço. Os exemplos apresentados salientam apenas parte dos
benefícios e propriedades dos mecanismos de herança e agregação. O leitor interessado pode
consultar Coad e Mayfield (1998).
Em projetos com componentes de negócio, a reutilização de um componente pode
ocorrer literalmente, sem nenhuma mudança. Exemplificando: componentes de negócio que
representam clientes podem ser utilizados em diversas aplicações. No exemplo apresentado,
o mesmo componente cliente utilizado no sistema de aluguel de carro, pode ser utilizado em
aluguéis de apartamento. Dependendo dos requisitos e forma de projeto e implementação, o
componente pode ser reutilizado mantendo inclusive a interface com o usuário.
Assim como objetos de negócio, objetos de processo de negócio também são passíveis
de reutilização. Por exemplo, partindo do diagrama de atividade que modela o processo de
reserva de carro (figura 5a), pode-se acrescentar a atividade de autorização de crédito (figura
5b) ao processo. De outra parte, dada a semelhança entre os processos reserva de carro e
reserva de apartamento, este pode ser obtido (figura 5c) a partir daquele (localiza apartamento
substituindo localiza carro).
Um último conceito importante a destacar é o de independência do ambiente
operacional em que os objetos serão processados. Para facilitar o processamento em
múltiplos ambientes, Ambler (1998) sugere que o projeto seja organizado em camadas de
classes, possibilitando a substituição em casos de troca de ambiente. As camadas classificamse em: de interface com usuário, de negócio, de persistência e de sistema. As camadas de
persistência e de sistema, por serem estabelecidas para atender características de cunho
técnico, são mais estáveis e com maior propensão de serem encontradas prontas.
5 Nesse estudo não são relevantes distinções entre agregação e composição
8
3. Proposição do Guia
O guia proposto compõe-se de um modelo analítico e de grades de análise, que
objetivam classificar e tabular dados obtidos empiricamente. A estrutura para análise tem sua
origem no relacionamento entre duas dimensões: as etapas do desenvolvimento de sistemas e
as atividades do processo de reutilização. Na primeira dimensão, consideram-se as etapas
normalmente apresentadas nas metodologias de desenvolvimento de sistemas: análise e
projeto 6, e implementação 7. Na outra observam-se as atividades necessárias para atingir a
reutilização de forma sistêmica, a saber: preparação para o consumo, consumo e liberação de
novas fontes reutilizáveis. Tal relacionamento é demonstrado na figura 6, que ilustra os
grupos resultantes. Nesta seção colocam-se as questões relevantes de cada grupo. No Anexo
encontra-se um conjunto de grades que sugere possíveis formas de tabulação dos dados
observáveis, facilitando a análise.
Atividades do Processo de Reutilização de
Software
Análise e
Projeto
Grupo
A
Utilização
Grupo
B
Liberação
Grupo
C
Classificações no
Contexto Objetos
Implementação
Etapas do Desenvolvimento
De Sistemas
Preparação
de Negócio
Grupo
D
Grupo
E
Grupo
F
Figura 6: Grupos de Análise do Guia
Antes de apresentar o guia, destaca-se que a fase de preparação para a reutilização está
adequada à forma como estão acontecendo os primeiros projetos a partir de objetos de
negócios. Normalmente, são fomentados por organizações que possuem um conjunto inicial
de fontes de software reutilizáveis, os quais são transferidos a empresas de software ou
equipes de desenvolvedores, aos quais cabe construir o sistema de acordo com os requisitos
de seus clientes.
GRUPO A: RECEBENDO FONTES DE SOFTWARE REUTILIZÁVEIS RELATIVAS À ANÁLISE E PROJETO
Os indicadores desse grupo têm por objetivo levantar: os tipos de recursos reutilizáveis
liberados para o desenvolvedor, o modo como são transferidos e a facilidade de acesso a esses
recursos. Os possíveis recursos variam desde aqueles que disponibilizam o suficiente para a
incursão do desenvolvedor em um novo segmento, até os que fornecem detalhes da
implantação do sistema, em que os elementos, tanto de software como de hardware, são
modelados. Tomando-se por base os diagramas apresentados na UML obtêm-se as
possibilidades apresentadas na grade 1. Além do vocabulário, que permite a aproximação a
um determinado domínio, os diagramas possibilitam diferentes níveis de aprofundamento no
problema.
6 estão incluídas na fase de análise e projeto as atividades inerentes ao levantamento de necessidades.
7 a fase de implementação estende-se até a liberação de objetos testados.
9
Embora os instrumentos possam ser percebidos na primeira grade, os meios para
ocorrer a transferência, tais como manuais, treinamento, suporte, site, são apresentados na
grade 11. Também nesse grupo estão as investigações quanto aos métodos de classificação e
pesquisa para facilitar o acesso aos recursos reutilizáveis necessários, conforme pode ser visto
na grade 9.
GRUPO B : CONSUMINDO FONTES DE SOFTWARE REUTILIZÁVEIS RELATIVAS À ANÁLISE E PROJETO
A avaliação nesse grupo ocorre principalmente quanto ao mecanismo (literalmente,
acrescentando, substituindo) e à extensão da mudança. Esta avaliação pode ser realizada para
os diferentes diagramas utilizados no projeto do sistema. Os relacionamentos entre os
mecanismos e as funções dos diagramas apresentados na UML podem ser observados na
grade 2. Seu preenchimento permite obter a participação proporcional entre criação e
reutilização.
GRUPO C: LIBERANDO NOVAS FONTES REUTILIZÁVEIS RELATIVAS À ANÁLISE E PROJETO
Neste grupo são observados os resultados gerados internamente, tanto no que se refere
a objetos de negócio, como em processos de negócio. O parâmetro a ser observado é a
amplitude do que está sendo produzido, conforme sugere a grade 3. Tratando-se de
orientação a negócio, espera-se uma especialização dirigida a projetos e se estendendo, no
máximo, a um domínio vertical. A produção de recursos para diversos domínios verticais é
sinal de um estágio ainda embrionário, ou seja, de preparação para a reutilização. Ainda neste
grupo questionam-se o que internamente é disponibilizado para futura reutilização e a
facilidade para classificá-los (grades 10 e 11).
GRUPO D: RECEBENDO FONTES DE SOFTWARE REUTILIZÁVEIS RELATIVAS À IMPLEMENTAÇÃO
As questões nesse grupo dizem respeito, primeiramente, se o que está sendo recebido é
de forma aberta ou fechada e se a granularidade atinge apenas objetos de negócio ou estendese também a processos. Tal tabulação é demonstrada na grade 4. Assim como no grupo A,
aqui também são questionados os meios e facilidades oferecidas para a transferência (grades 9
e 11).
GRUPO E: CONSUMINDO FONTES DE SOFTWARE REUTILIZÁVEIS RELATIVAS À IMPLEMENTAÇÃO
Neste ponto, a análise prevê detectar quais os mecanismos empregados (literalmente,
através de agregação/composição ou através de herança) são mais freqüentes. Ao mesmo
tempo, há preocupação em perceber a granularidade (objetos de negócio ou comuns).
Embora semelhantes, as análises podem ser feitas separando objetos de negócio das de
processos de negócio, conforme mostram as grades 5 e 6.
O resultado da análise para objetos de negócio é o somatório das análises para cada
objeto, podendo este ser formado a partir de outros. Percebe-se a necessidade de um processo
recursivo para a contagem. Para a análise, opcionalmente, o resultado pode ser apresentado
totalizando objetos de negócio direta e indiretamente usados no sistema. Por exemplo, num
sistema de vendas em que é necessário de forma direta o objeto cliente, o qual foi derivado do
objeto empresa, é necessário fazer a análise de mecanismos utilizados nesse último.
No levantamento da obtenção de objetos de processo de negócio também existe a
contagem de forma recursiva, porém objetos de negócios que compõem a solução não são
analisados, somente o são processos com granularidade menor. Por exemplo, ao ser analisado
10
o processo de venda, que pode ser composto dos objetos de processos de negócios cria pedido
(cliente + vendedor + produtos solicitados), cria nota fiscal e imprime nota fiscal, e dos
objetos de negócios pedido, cliente, vendedor, produto e nota fiscal, dispensa-se a avaliação
dos objetos de negócio, visto que já foram avaliados anteriormente; porém, é necessário que
seja feita a análise para todos os processos a partir dos quais o processo principal foi
desenvolvido. Nesse grupo também é observado o fluxo de controle das atividades.
GRUPO F: LIBERANDO NOVAS FONTES DE SOFTWARE REUTILIZÁVEIS RELATIVAS À IMPLEMENTAÇÃO
Inicialmente, o objetivo é perceber a amplitude do que está sendo liberado, assim
como as limitações desses recursos diante de outros fatores, como ambientes operacionais.
Neste último parâmetro, tem-se uma ordem desejada de ajuste, quando não se consegue
aproveitar o objeto literalmente, sendo a melhor alternativa a configuração.
A seguir é apresentado um quadro sinótico das classificações julgadas mais relevantes.
Tabela 2: Quadro Sinótico
Atividades do Processo de Reutilização de Software
Etapas do Desenvolvimento de Sistemas
PR EPA RA Ç ÃO
A
N
Á
L
I
S
E
P
R
O
J
E
T
O
I
M
P
L
E
M
E
N
T
A
Ç
Ã
O
UT I L I ZA ÇÃ O
L IB ER AÇ ÃO
Grupo A
Grupo B
Grupo C
» Quanto ao tipo de conteúdo
recebido: vocabulário, diagramas.
» Quanto ao meio: treinamentos em negócio e meta-modelos, manuais, outras formas de
suporte.
» Quanto à extensão da pesquisa: conteúdo, especificação, palavra-chave.
» Quanto à recuperação: manual, atomatizada.
» Quanto ao mecanismo de
reutilização: reutilizado literalmente, montado a partir de
outros recursos existentes,
derivado a partir de outro
existente.
» Quanto à extensão da
mudança, quando exigida:
trivial, média, grande.
» Quanto à amplitude do
domínio do software liberado: para projetos de diversos
domínios verticais, para projetos de um determinado domínio vertical, neste projeto.
» Quanto à forma de disponibilizar: conteúdo, especificação, palavra-chave.
» Quanto ao meio de divulgar: manuais, treinamento,
outras forma de divulgação.
(Grades 1, 9 e 11)
Grupo D
(Grade 2)
Grupo E
(Grades 3, 10 e 11)
Grupo F
» Quanto ao tipo de conteúdo
da biblioteca recebida: classes
(código fonte), componentes
de negócio, processos de objeto de negócio.
» Quanto à formalidade: sintaxe e semântica, somente sintaxe.
» Quanto ao meio, extensão
da pesquisa e facilidade de
recuperação (idem a grade A).
» Quanto ao mecanismo de
reutilização dos objetos e processos de negócio: literalmente, exige configuração,
deriva de outro objeto, compondo outros objetos de negócio existentes.
» Quanto à amplitude do
domínio do software liberado: domínio horizontal, vertical, apenas no projeto.
» Quanto à amplitude do ambiente: limitada por sistemas
operacionais, BD.
» Quanto à forma de disponibilizar e divulgar (idem
grade C).
(Grades 4, 9 e 11)
(Grades 5 e 6)
(Grades 7,8,10 e 11)
⇒ Principais atividades:
Recebe recursos reutilizáveis
e suporte para uso destes.
⇒ Principais atividades:
recupera, modifica e cria
novos softwares.
⇒ Principais atividades:
classifica e disponibiliza os
novos recursos.
11
4. Exemplo de Uso do Guia
Espera-se que o instrumental proposto seja útil tanto para o meio acadêmico como
para as organizações. Na academia, por ser um tema contemporâneo, pode auxiliar tanto
pesquisas exploratórias com objetivos de identificar comportamentos e quantificar resultados,
como também em pesquisas com hipóteses relacionadas ao tema, tornando possível a
obtenção de evidências, com rigor científico e de forma abrangente, que as corroborem ou
não. Nas organizações que desenvolvem sistemas de informação com a Tecnologia do
Objeto, pode facilitar a análise do processo de reutilização de software realizado pela
organização.
Nesta seção apresenta-se um exemplo sobre a maneira de medir a reutilização e seus
resultados econômicos, no que tange à redução de custos. Com a chegada ao mercado de
novos fornecedores de componentes de negócio (SAP R3, Baan), efetivando-se a nova
indústria de software, caracterizada por fabricantes de componentes e montadores, mais
freqüentes serão as declarações sobre resultados de reutilização, como “...40% do trabalho
desenvolvido numa aplicação típica é aproveitado e 60% desenvolvido...”, conforme citado
por Arnold et. al. (1997, p.438) em relação aos trabalhos desenvolvidos por parceiros do IBM
San Francisco ou outras relativas à redução de custos, como “...80% dos custos de
desenvolvimento de um parceiro seria consumido programando e mantendo o básico, objetos
relacionados a facilidades comuns e a funções centrais que são os mesmos para qualquer
aplicativo...” conforme cita a IBM em relação ao IBM San Francisco, em Byron (1998, p.5).
Embora a primeira declaração enfatize a redução no esforço de desenvolvimento, e a segunda
saliente a redução de custos, nenhuma das duas possibilita visualizar, de fato, a real economia.
Tal economia somente é possível de ser medida se o custo de desenvolver for confrontado
com o custo de comprar pronto (make or buy).
O exemplo a seguir é construído a partir da seguinte situação: suponha a existência de
um sistema conforme figura 7 (diagrama A), para locação de automóveis sem autorização de
crédito, como um componente de processo de negócio. Há necessidade de trocar para locação
de apartamentos e acrescentar autorização de crédito. Para facilitar a exemplificação, não se
consideram métricas para reutilização do fluxo. O diagrama B é resultado de três atividades
reutilizadas literalmente (especifica datas, cria cliente, localiza cliente), uma substituição
(localiza carro por localiza apartamento), e um acréscimo (autoriza crédito). À primeira vista,
a reutilização de forma literal representa 60%, alteração 20% e acréscimo também 20%.
Aprofundando-se o problema, no caso em que autoriza crédito seja composto por outras três
atividades (diagrama C), verifica forma de pagamento, consulta SPC (Serviço de Proteção ao
Crédito), ativada apenas quando a forma de pagamento for em cheque ou crediário, e valida
cartão, quando o pagamento utilizar cartão de crédito. Caso apenas uma das três atividades
não esteja equacionada, resulta em 66,67% de reutilização literal e 33,33% de acréscimo.
Atividade
Reserva
de Carro
Formulário
Cliente
Atividade
Reserva
de Carro
Visualiza
Clientes
Existentes
Visualiza
Carros
Existentes
Atividade
Formulário
Reserva de Cliente
Apartamento
Atividade
Visualiza
Visualiza
Reserva de Clientes
Hoteise
Apartamento Existentes Apartamentos
LF2
LF1
LF3
Especifica
Datas
Localiza
Apartamento
Localiza
Cliente
Cria
Cliente
Especifica
Datas
Localiza
Carro
Cria
Cliente
Localiza
Cliente
Especifica
Datas
Localiza
Apartamento
Cria
Cliente
Localiza
Cliente
LF4
Lê Forma de
Pagamento
LF5
Autoriza
Crédito
Consulta
SPC
(A)
(B)
(C)
Figura 7: Diagramas de Atividade para sistema de locação
LF6
Verifica
Cartão
12
Repare o leitor no problema desta análise. Implicitamente, todos os componentes
foram considerados como se tivessem o mesmo grau de dificuldade, desprezando as
diferenças de granularidade e complexidade existentes entre eles. A conseqüência é a
possível geração de mais de um resultado, dependendo da abordagem e seqüência dada à
análise. Caso se divida o problema observando o nível hierárquico, conforme apresentado na
figura 8b, tem-se um índice de reutilização igual a 0,734 (0,6+0,67×0,2=0,734). No entanto,
observando o resultado do último nível, na mesma figura, chega-se a um índice de reutilização
igual a 5/7, ou seja, 0,714. Qual dos índices é o mais apropriado?
As análises a seguir são feitas com base na avaliação sugerida para o grupo E, mais
especificamente grade 6, aplicando um método recursivo até chegar nos componentes de
negócio de menor granularidade. Procurar-se-á demonstrar que o guia proposto proporciona
uma avaliação de melhor qualidade do que a realizada anteriormente.
Seqüência
Lógica
Aluga
Apartamento
Reutiliza LF1, LF2, LF3 Altera LF4
Componentes
de Processo
Especifica
Datas
Aluga
Apartamento
Especifica
Datas
Literalmente (.6)
Cria
Cliente
Cria
Cliente
Localiza
Cliente
Localiza
Cliente
Substitui (.2)
Localiza
Apartamento
Seqüência
Lógica
Verifica
Crédito
Componentes
de Processo
Literalmente (.67)
Lê Forma de
Pagamento
Acrescenta (.2)
Consulta
SPC
Legenda:
Componente de
processo Reutilizado
Localiza
Apartamento
Cria LF5, LF6
Lê Forma de
Pagamento
Consulta
SPC
Acrescenta (.33)
Verifica
Cartão
Componente de
processo construído
Verifica
Cartão
(A) Reutilização
(B) % com base na hierarquia
Figura 8: Visão geral da reutilização do exemplo
Ciente de que os componentes têm nível de complexidade diferentes, o critério de
comparação mais usual utiliza alguma medida de esforço, normalmente Homem-Hora (HH) de
desenvolvimento. A seguir, na tabela 3, apresenta-se um exemplo quantificando-se os componentes
em HH do último nível.
Tabela 3: Análise por esforço ( tomando como base HH de programação):
Custo
Custo
HH
Medida
Medida
Componentes de
Aquisição
implementação Reutilização implementação
Reutilização:
$
Processo
$
$
interna
HH
R
Especifica Datas
Cria Cliente
Localiza Cliente
Localiza Apart.
Verifica Forma de Pag.
Consulta SPC
Valida Cartão
reutiliza
reutiliza
reutiliza
novo
reutiliza
reutiliza
novo
Totais
3
2
2
1
2
3
300
313
C
3
2
2
1
2
3
12
300
301
R
30
20
20
10
20
30
3000
3130
20
5
10
10
1
1
3000
3047
C
20
5
10
10
1
1
37
3000
3010
Esta segunda análise, quantificando o esforço em HH, mostra que a reutilização seria
de 12/313, ou seja, apenas 3,83%, enquanto 96,17% permanecem sendo criados. Isto se dá
devido ao fato de o desenvolvimento do processo valida cartão ser muito oneroso. Embora
contribua para a tomada de decisão, esta forma de avaliação é válida apenas para o caso de
13
reutilização interna. Neste caso a mão-de-obra correspondente aos processos reutilizados
estaria liberada para atuação em outros projetos.
Na medida em que existe oportunidade de obterem-se tais fontes de software
externamente, a única unidade de medida que pode ser aplicada tanto interna como
externamente, é a valorização econômica do componente, não sendo mais suficiente
trabalhar-se com a unidade HH. Para exemplificar esta forma de perceber o problema,
considerando possibilidades de aquisição de fornecedores externos, um novo estudo é
acrescido na tabela 8, em que se determina a base para a quantificação da implementação em
custo de aquisição ($). Convencionou-se o valor da unidade HH em $10 e para os
componentes em que não há oferta externa (já prontos), manteve-se o mesmo valor interno de
implementação.
Nessa terceira forma de análise, a reutilização representa 37/3047, ou seja, 1,21% do
custo total efetivo do projeto. No entanto, a métrica mais expressiva nesse caso é a da
economia viabilizada pelo processo de reutilização. Nesse exemplo, caso todos os
componentes fossem construídos, resultaria um custo de $3.130, o que equivale a uma
economia de $83 ($3.130 - $3.047). Percentualmente haveria uma redução de custo de
83/3130, ou seja, 2,72%, atribuível ao processo de reutilização.
5. Considerações Finais
Espera-se que tanto pesquisadores como profissionais relacionados à área de sistemas
de informação interessados nesse novo contexto de produção de software, possam encontrar
no guia uma referência para acompanhar suas investigações.
Dada a emergência do tema, muitas questões serão levantadas, havendo necessidade
de desenvolvimento de instrumentos para respondê-las adequadamente. Particularmente, de
imediato, percebe-se a necessidade de dois desdobramentos. Devido à recursividade e
extensão exigidas em alguns grupos de avaliação, é necessária (e viável) a existência de um
software para desempenhar tal tarefa. Este deverá contemplar alguns mecanismos que
favoreçam uma distribuição por autoria, de forma a facilitar o cálculo de royalties de forma
proporcional ao uso dos componentes no projeto.
Bibliografia
AGRESTI, William, McGARRY, Frank. The Minnowbrook On Software Reuse: A Summary Report. In:
TRACZ, Will. Software Reuse - Emerging Technology. Los Alamitos, CA: IEEE Computer Society
Press, 1990. p.33-40.
AMBLER, Scott W. Análise e Projeto Orientados a Objeto, volume II: seu guia para desenvolver sistemas
robustos com tecnologia de objetos. Rio de Janeiro: Infobook, 1998.
ARNOLD, D. et al. IBM Business Frameworks: San Francisco project technical overview. IBM System Journal,
v.36, n.3, p.437-445, 1997.
BOOCH, Grady. Object-Oriented Analysis and Design with Applications. Redwood City, California,USA: The
Benjamin/Cummings Company, Inc., 1994.
BOHRER, K.A. Architecture of the San Francisco frameworks. IBM System Journal, v.37, n.2, p.156-180,
1998.
BYRON, Dennis. Vertical Industry Applications. International Data Corporation. (IDC), v.1, IDC #15907, p.115, mar. 1998.
COAD, Peter; MAYFIELD, Mark. Projeto de Sistemas em Java. São Paulo: Makron Books, 1998.
__________, YORDON, E. Object-oriented Analysis. Englewood Cliffs, NJ: Prentice Hall, 1990.
EELES, Peter; SIMS Oliver. Building Business Objects. USA: John Wiley & Sons, Inc., 1998.
FREITAS, Henrique et al. Informação e Decisão: Sistemas de Apoio e seu Impacto. Porto Alegre: Ortiz, 1997.
FURLAN, José Davi. Modelagem de Objetos através da UML. São Paulo: Makron Books, 1998.
HARDGRAVE, Bill C.; DOUGLAS, David E. Trends in Information System Curricula: Object-Oriented
Topics. Americas Conference on Information Systems. In: Proceedings... Maryland, 1998, p.683-685.
14
HOOPER, James; CHESTER, Rowena. Software Reuse: Guidelines and Methods. New York: Plenum
Press, 1991.
IBM. San Francisco Evaluation Kit (V1R2): Geting Started. Rochester, Minnesota: IBM Corp., 1998.
JACOBSON, I. et al. Object-Oriented Software Engineering. USA: Riverside Printing Co., 1992.
KIM, Yongbeom; STOHR, Edward. Software Reuse: Survey and Research Direction. Journal of Management
Information System, v.14, n.4, 1998, p.113-147.
MARTIN, James; ODELL, James. Object-oriented Analysis and Design.
Englewood Cliffs, New Jersey:
Prentice-Hall, 1992.
McGREGOR, John; SYKES David. Object-Oriented Software Development: Engineering Software for Reuse.
New York: Van Nostrand Reinhold, 1992.
NIDUMOLU, Sarma R.; KNOTTS Gary W. The effects of Customizability and Reusability on Perceived
Process and Competitive Performance of Software Firms. MIS Quarterly, Jun. 1998, p. 105-137.
RUMBAUGH, J. et al. Modelagem e Projetos Baseados em Objetos. Rio de Janeiro: Editora Campus, 1994.
SIEGEL, Jon. OMG Overview: CORBA and the OMA in Enterprise Computing. Communications of the ACM.
v.41, n.10, Oct. 1998,p.37-43.
SNYDER, Alan. The essence of Objects. Concepts and Terms. IEEE Software. jan. 1993, p.31-42
SOHN, Changsoo; DEJNARONK, Apiwan. Object-Oriented Approach as a Potential Silver Bullet. Americas
Conference on Information Systems. In: Proceedings... Maryland, 1998, p.702-704.
TAPSCOTT, Don. Mudança de Paradigma. São Paulo: Makron Books, 1995.
verticais
específico
projeto
100
100
Vocabulário do domínio
Diagrama de Caso de uso
Diagrama de Classe
Diagramas de Interação
Alterando existente
Criando novo
Não usa
Total ( % ): 100 100 100 100 100 100
GRADE 4
Quanto ao tipo de
conteúdo
(implementação)
3 Software tipo workflow
3 apenas neste
F
Acrescentando existente
2 Componentes de negócio
2 domínio vertical
E
Reutilizando literalmente
1 Classes de negócio
1 diversos domínios
Total ( % ):
D
4 Processos de negócio pronto
A
B
não contém
B
C
contém
A
Processos
de egócio
GRADE 3
Quanto a amplitude
do software liberado
1
2
3
4
5
B
Diagramas de estados
Vocabulário comum
Casos de uso e atores
Diagrama de Caso de Uso
Diagrama de Classe
Diagrama de Seqüência
Diagrama de Estado
Diagrama de Colaboração
Diagrama de Atividade
Diagrama de Componente
Diagrama de Implantação
A
GRADE 2
Quanto ao mecanismo
de reutilização.
Como é efetuada e
em que extensão
ocorre?
Diag. de Implementação
B
Objetos
deNegócio
1
2
3
4
5
6
7
8
9
10
A
não contém
GRADE 1
Quanto ao tipo de
conteúdo
(análise e projeto)
contém
ANEXO 1: Modelos de Grades para Tabulação do Dados
1
2
3
diversos domínios verticais
domínio vertical específico
apenas neste projeto
Total ( % )
A
B
Fluxo e interface com
usuário
compondo objetos de
processo de negócio com
menor granularidade
GRADE 8
Limitações dos
componentes de
negócio
Total (100%)
100
100
A
B
C
D
não reutiliza
100 100
Processos
de Negócio
GRADE 7
Quanto a amplitude e
granularidade do
software liberado
2
Objetos
de Negócio
Total ( % ):
1 Objetos para controle do
nova composição
3
B
aj. via configuração
6
Código fonte criado ou alterado
2
B
aproveita literalmente
4
5
em forma de componentes
Literalmente, objetos de negócio
sob a forma de código fonte
Compondo outros objetos de
negócio de menor granularidade
Herdando de outro objeto de negócio
Compondo outros objetos comuns
A
Novo
1 Literalmente, objetos de negócio
GRADE 6
Quanto ao
mecanismo na
obtenção do objetos
de processo de
negócios
Alterado
B
Reutilizado
A
indiretos
GRADE 5
Quanto ao mecanismo na
obtenção de Objetos
de negócios?
diretos
15
1 Mudando o ambiente
operacional do servidor
2 Mudando o ambiente
operacional do cliente
3 Mudando o gerenciador
de banco de dados
100
100
4 Soft desenvolvidos com
outras linguagens
relacionadas
2 especificação (interface)
3 conteúdo do recurso
1 Por palavras chaves
relacionadas
2 Pelo conteúdo da
interface ou espec.
3 Pela análise do conteúdo
do recurso
C
não
existe
B
manual
A
Automatizado
GRADE 10
Quanto a facilidades
de classificação do
recurso reutilizável
1
2
3
4
5
6
7
Manuais
Trein. no negócio
Trein. diagramas
Suporte on line
Forum dediscussão
Site
Espaço de sugestões
Não
fornece
1 palavras chaves
Fornece
GRADE 11
Quanto ao meio de
informação
sem acesso
manual
automatizado
GRADE 9
Quanto a facilidades
para recuperação do
recurso reutilizável,
forma de pesquisa
5 Citar outras mudanças: