Embed Size (px)
Citation preview
1
Categoria de Assunto
INFORMÁTICA – ENGENHARIA DE SOFTWARE
Título
Componentes - Vantagem competitiva no
desenvolvimento de software (PIC*)
Autores
Carlos Renato Rocha Bueno, 27, é analista de sistemas com 8 anos de experiência em
desenvolvimento de Softwares na GTCON, ATT/PS e Commitment Informática. Cursa o 5º semestre de
Tecnologia em Informática no Centro Universitário Radial, onde é integrante do Programa de Iniciação
Científica. [email protected]
Regina Sélia de Almeida Rodrigues Bueno, 28, é analista de sistemas com 7 anos de experiência
em desenvolvimento de Softwares na IBM, Hospital Sírio Libanês e Network1. Cursa o 5º semestre de
Tecnologia em Informática no Centro Universitário Radial, onde é integrante do Programa de Iniciação
Científica. [email protected]
Paulo Sergio Borba, 40, é mestre em Engenharia da Computação com ênfase em Engenharia de
Software pelo IPT da USP. Gerente de Projetos de Software na Alcoa Alumínio, Banco AGF e Banco
Itaú. Professor da FIAP e do Centro Universitário Radial, onde coordena os cursos de graduação
tecnológica de Informática e conduz dois projetos de iniciação científica. [email protected].
(*) Este artigo foi gerado a partir do Programa de Iniciação Científica (PIC) da
UniRadial, sob o título: “Um Processo de Desenvolvimento de Software
facilmente aplicável”
Resumo
O desenvolvimento de Software tem se tornado uma indústria. O software tem sido
padronizado em muitos segmentos de negócio. Cada vez mais os softwares são mais
padronizados e menos específicos.
Empresas produtoras de software têm buscado padronizar seu desenvolvimento tanto quanto
2
possível, a fim de ganhar escala e aumentar sua produtividade e seus lucros.
Um dos trunfos da Engenharia de Software para aumentar a produtividade e a qualidade dos
softwares desenvolvidos é a utilização de tecnologia de componentes no processo de
desenvolvimento de software. Há ganhos reais com a utilização de componentes de
software, mas a complexidade também aumenta, exigindo um ambiente controlado e
gerenciado com padrões profissionais.
Palavras-chave:
componentes, desenvolvimento baseado em componentes, redução de custos, manutenção
de software, produtividade, engenharia de software, desenvolvimento de software, pacotes
de software.
Abstract:
Software development have become a industry. Software have been standardized in many
business segments. Each time more softwares are standardized and less specific.
Software companies look for standardization in software development as so as possible to
maximize their scale profit, productiveness and gains.
A significant resource of software engineering to increasing software development
productiveness is the utilization of Component Technology in software development process.
There are real gains with use of software components but complexity also it increases,
demanding a control and managed development environment with professional patterns.
Key-Words:
components, component-based development, cost reduction, software maintenance,
productiveness, software engineering, software development, COTs
Glossário
Caixa Preta: Termo aplicado a uma estrutura de programação para a qual conhecemos apenas
seus efeitos exteriores, sem conhecer detalhes internos de sua implementação.
CPMF Sigla de um imposto do sistema financeiro nacional.
DIRF Arquivo gerado por uma empresa com informações de receitas para a receita federal.
DBC: Desenvolvimento Baseado em Componentes
ESBC: Sigla de Engenharia de Software baseada em Componentes.
OO: Orientação a Objetos / Orientado a Objetos
3
1. Introdução
Um dos maiores desafios do mundo moderno é saber como reciclar,
reutilizar coisas para que exista economia de matéria prima, tempo e
dinheiro. Esse é um desafio também para a Engenharia de Software: aplicar
o reuso a fim de obter benefícios como menor custo e tempo de
desenvolvimento e mais agilidade, com o conseqüente aumento da
produtividade.
A engenharia de software baseada em componentes (ESBC) é uma
abordagem baseada na reutilização de código no desenvolvimento de
software. Surgiu, dentre outros motivos, da necessidade de se produzir mais
software em menos tempo, aumentando a produtividade do desenvolvimento.
Componentes de software é uma parte de engenharia de software que
materializa mais claramente este reaproveitamento de código. A utilização de
componentes traz vantagens mas, ao mesmo tempo, requer cuidados
adicionais na produção de software.
2. Reaproveitamento de Código – Sub-Rotinas
As sub-rotinas já eram uma forma de reaproveitar código. A figura 1
apresenta duas situações, uma sem a utilização de sub-rotinas e outra com o
uso de sub-rotina. Imagine um sistema de informação que calcule uma folha
de pagamentos de uma empresa. O cálculo de impostos é parte integrante do
sistema e pode ser exigido mais de uma vez.
Na situação 1 da figura citada, temos três módulos do sistema (Tela de
Cálculo, Relatório e o gerador de arquivo de DIRF) efetuando o mesmo
cálculo. Nesta situação, o código é repetido nos três módulos. Isso acarreta
dois riscos ao sistema:
• cálculos diferentes: se os códigos não forem replicados de forma
idêntica, pode haver diferenças nos cálculos;
• manutenção: caso seja necessário alterar a rotina de cálculo, a
manutenção deve ser feita nos três módulos, aumentando a carga
de trabalho e gerando novamente o risco descrito no item anterior.
4
SITUAÇÃO 2
SITUAÇÃO 1
TELA DE CÁLCULO
Cálculode Imposto
RELATÓRIO
Cálculode Imposto
GERA ARQUIVO DIRF
Cálculode Imposto
SUBROTINACálculo
de Imposto
TELA DE CÁLCULO RELATÓRIO GERA ARQUIVO DIRF
chamasubrotina
chamasubrotina
chamasubrotina
Figura 1 – Exemplo de Aplicação de Sub-rotina
Na situação 2, os módulos são os mesmos, todavia, dentro deles não
está descrita a rotina de cálculo, mas apenas uma “chamada” para esta rotina
(sub-rotina) que é desenvolvida separadamente.
Este artifício de construção de sistema elimina os dois problemas
descritos para a situação 1, pois o trecho de programa que efetua os cálculos
é único, garantindo que não haverá diferenças entre os cálculos efetuados
em cada rotina, além da manutenção, se necessária, ocorrer em um ponto
único do código.
O conceito de reaproveitar o código tem claras vantagens. O uso de
componentes no desenvolvimento de software busca essas vantagens, entre
outras.
As linguagens mais antigas já permitiam a criação deste artifício. Com
o advento da orientação a objetos o conceito de reuso evoluiu, chagando aos
componentes de software.
5
3. Funções – implementação de sub-rotinas
Muitas linguagens de programação implementam o recurso de sub-
rotina como funções (functions). Essas funções, ao serem invocadas,
geralmente recebem uma ou mais informações de entrada e executam um
trabalho. Geralmente, retornam um ou mais valores ao final.
Por exemplo, uma função que calcula a raiz quadrada de um número,
deve receber como input (informação de entrada) o número para o qual se
deseja calcular sua raiz quadrada. O retorno, ao final, será o valor da raiz
quadrada, calculado pela função.
Esse tipo de função, geralmente já está implementada nas linguagens
de programação e em vários softwares como planilhas eletrônicas.
É possível criar-se funções específicas na produção de software. Por
exemplo, em um sistema de Folha de Pagamento, uma função que calcule o
imposto de renda a descontar. A partir de informações de entrada como o
valor do salário e a quantidade de dependentes, a função efetua os cálculos e
retorna o valor do imposto.
4. Componentes
Componente é a evolução natural de sub-rotinas e funções, gerados a
partir do paradigma da Orientação a Objetos.
Um componente pode ser descrito como pedaços pré-definidos de
software com interfaces (entrada e saída) e comportamento bem delineados,
que podem ser usados e reutilizados em diferentes aplicações.
Essencialmente, são objetos em um alto nível de abstração que podem se
comportar efetivamente como soluções “caixa preta” para as necessidades
de um sistema específico, fornecendo serviços para uma arquitetura de
aplicações bem definida.
Um componente implementa partes de um sistema.
6
Uma vez invocado, o componente pode retornar um valor ou produzir
um trabalho determinado, mas com muito mais autonomia e alcance que as
sub-rotinas discutidas acima.
Por ter potencial maior, é possível implementar partes de sistema em
um componente. Teremos um exemplo disso mais adiante.
4.1. Melhores Práticas de Desenvolvimento de
Software
A utilização das melhores práticas de desenvolvimento de software
traz mais qualidade para o desenvolvimento do projeto, pois são práticas de
aplicação comprovada no desenvolvimento de software. Entre as melhores
práticas listadas abaixo, conforme a Rational [8] está o uso de componentes:
• Use arquitetura baseada em componentes
• Desenvolva software iterativamente
• Gerencie requisitos
• Modele o software visualmente (use UML)
• Verifique a Qualidade do software continuamente
• Controle as mudanças do software
4.2. Desenvolvimento Baseado em Componentes
(DBC)
No DBC, uma aplicação é construída a partir da composição de
componentes de software que já foram previamente especificados,
construídos e testados, o que proporciona um ganho de produtividade e
qualidade no software produzido. Esse aumento da produtividade é
decorrente da reutilização de componentes existentes na construção de
novos sistemas. Já o aumento da qualidade é uma conseqüência do fato dos
7
componentes utilizados já terem sido empregados e testados em outros
contextos. Porém, vale à pena ressaltar que apesar desses testes prévios
serem benéficos, a reutilização de componentes não dispensa a execução
dos testes no novo contexto onde o componente está sendo reutilizado.
Um aspecto muito importante é sempre ressaltado na literatura: um
componente deve encapsular dentro de si seu projeto e implementação, além
de oferecer interfaces bem definidas para o meio externo. Ou seja, uma vez
que o trabalho a ser realizado é implementado em um componente, não é
necessário que se conheça seus detalhes de implementação para se poder
utilizá-lo.
Basta conhecer quais informações devem ser enviadas ao
componente para sua execução e qual o retorno esperado deste
componente.
5. Reuso e componentização
O que motiva o uso de componentes é a grande possibilidade do reuso
de software ou parte dele. O reuso possibilita um aumento considerável na
produção de software. Assim, os custos de produção por unidade de produto
tendem à redução, com possíveis ganhos de produtividade associados. A
ESBC é um passo a mais no reuso de código, exatamente por possibilitar o
reuso “como ele é”, ou seja, o componente é reutilizado sem alteração de sua
implementação, sem custos de desenvolvimento, apenas de “montagem”.
Para melhor compreensão, pode-se dividir o reuso de software em quatro
categorias (Szyperski, 1999):
a) Reuso de código fonte: trechos de código reutilizável são usados
durante a fase de desenvolvimento de um novo software (copiados e
colados);
b) Reuso de partes de software: reuso de arquitetura e
implementação de fragmentos de software em diferentes projetos.
Exige um processo de desenvolvimento mais elaborado. O reuso
ocorre durante o desenho da arquitetura do projeto e da
8
implementação do código. Assim como no caso acima, não existe
componente como uma parte identificável na aplicação final, não
sendo substituído com facilidade;
c) Integração dinâmica de componentes de diversas fontes: o
reuso não ocorre na fase de desenvolvimento do software. A
aplicação já está desenvolvida e novas funcionalidades são
acrescentadas a partir de softwares plug-ins. São exemplos deste tipo
de componente os plug-ins adicionados aos browsers para que estes
consigam visualizar arquivos em formato PDF;
d) Componentização: esta categoria é a mais complexa. É o objeto
principal deste artigo. É sua característica que a atualização, a
extensão do sistema e a integração possam acontecer
dinamicamente. Isto permite que os componentes sejam utilizados
além das fronteiras das organizações. É nesta categoria que estão
concentradas as pesquisas do momento e, também, a revolução
potencial que pode ser proporcionada pela tecnologia de
componentes.
6. Benefícios da componentização
A utilização de componentes traz vários benefícios ao desenvolvimento
e manutenção de software. Muitas empresas têm adotado o DBC para
controlar a complexidade e os riscos do desenvolvimento de software,
utilizando a sua abordagem centrada na arquitetura e reuso.
O DBC influencia na forma como o software é construído, montado,
disponibilizado, testado, evoluído e vendido. DBC não é uma abordagem de
desenvolvimento somente, mas também é uma abordagem de distribuição
(deployment), que leva a novos caminhos para vender e comprar soluções de
software. O uso de unidades quase autônomas para estruturar os sistemas
de informação traz novos desafios e oportunidades no que tange o
desenvolvimento, os testes e a distribuição, feitos de forma concorrente. Em
abordagens tradicionais (sistema modularizado), uma modificação em um
módulo do sistema acaba afetando outros módulos, fazendo com que tanto o
9
módulo modificado quanto os demais módulos afetados tenham que ser
redistribuídos. Utilizando DBC, somente o componente modificado precisa ser
redistribuído.
Podemos resumir os principais benefícios na tabela abaixo:
Funcionalidade:
Uso de componentes pré-existentes permite entregar mais
funcionalidade em menos tempo.
Melhores índices de produtividade e redução de custos.
Manutenibilidade:
A estrutura modular de uma solução baseada em componentes permite
a substituição de componentes individuais, permitindo alteração em um
ponto único da aplicação, sem a necessidade de alterá-la em vários
pontos.
Usabilidade:
Substituição de componentes em tempo de execução permite boa
customização. Uso de componentes padronizados uniformiza a
interface GUI
Confiabilidade:
Componentes reutilizáveis já foram testados em outros contextos e
são, portanto mais robustos e confiáveis.
Produtos de melhor qualidade, consistentes e padronizados.
Portabilidade:
A especificação de um componente independe da plataforma.
Reimplementar um componente para outra plataforma não deve afetar
a arquitetura ou solução final.
7. Exemplo de um sistema baseado em componentes
Os benefícios são mais fáceis de se entender com um exemplo
prático. Na figura 2, temos um sistema bancário que controla a conta corrente
dos clientes de um banco.
Atualmente, é muito comum o correntista acessar informações de sua
conta corrente através de vários canais (internet, máquinas de auto-
atendimento, telefone, celular, pocket...).
A figura mostra uma aplicação em 3 camadas, com 3 níveis do
sistema.
Para exemplificar, tomemos com exemplo uma funcionalidade de
Consulta de Saldo.
O saldo do cliente encontra-se gravado em um dos bancos de dados
(Nível 1 da aplicação, ou camada de persistência).
10
Caixa Eletrônico Navegador
Internet
PDA
Celular
PC em Rede
Banco 4
Banco 1 Banco 3Cadastro Clientes
Conta Corrente
InvestimentosTransferências
Extrato da Conta
Aplicações Empréstimos
Promoções
Integração Facilitada
Integração Facilitada
Funcionalidades Unificadas
Funcionalidades Unificadas
Caixa Eletrônico Navegador
Internet
PDA
Celular
PC em Rede
Banco 4
Banco 1 Banco 3
Banco 4
Banco 1 Banco 3Cadastro Clientes
Conta Corrente
InvestimentosTransferências
Extrato da Conta
Aplicações Empréstimos
Promoções
Cadastro Clientes
Conta Corrente
InvestimentosTransferências
Extrato da Conta
Aplicações Empréstimos
Promoções
Integração Facilitada
Integração Facilitada
Funcionalidades Unificadas
Funcionalidades Unificadas
Há um componente de software específico para a consulta desta
informação, situado no nível 2 da aplicação: “Extrato de Conta”. Chamamos
esta camada de “regras de negócio”, uma vez que é o componente o
responsável por encapsular as regras que o negócio impõe.
Figura 2 – Exemplo de Sistema desenvolvido com componentes
Este componente é o responsável por apurar o saldo cliente. Há
algumas regras para a apuração deste saldo, como cheques depositados que
não foram compensados, débitos futuros, ... Esta é a regra de negócio
definida pelo usuário principal do sistema.
A consulta do saldo pode ser disparada por vários canais indicados no
nível 3 (camada de apresentação): um micro conectado à internet, um celular
waap, um pocket, uma linha telefônica, um caixa de auto-atendimento (ATM).
A interface com o usuário é diferente em cada um dos canais de consulta.
Todavia, o componente responsável por produzir a informação do saldo para
o correntista é sempre o mesmo: “Extrato de Conta”.
Nível 1 - Persistência
Nível 2 - Regras de Negócios
Nível 3 - Apresentação
11
CAMADADE
APRESENTAÇÃO
CAMADADE
PERSISTÊNCIA
CAMADADE REGRASNEGÓCIOS
Interfacecom
usuário
Regras deNegócio
Acesso aoBanco de
Dados
Independência de Plataforma!
Esse componente recebe uma informação da camada de
apresentação (agência, conta, senha) e dispara a pesquisa no banco de
dados. Uma vez tendo as informações do banco de dados, o componente,
segundo as regras, calcula o saldo do cliente e o envia para a camada de
apresentação que o exibirá para o correntista.
A regra para a formação do saldo é a mesma, independente a partir de
qual canal o cliente a está consultando. Assim, não se justifica a
implementação da regra de formação do saldo em cada um dos canais.
Fosse assim, cada um dos programas que faz interface com o cliente
deveria saber como formar o saldo.
Fica clara a vantagem de se utilizar um componente nesta situação,
quando pensamos que, uma vez que haja uma mudança na regra de
formação do saldo (por exemplo, a criação ou suspensão de um imposto
como a CPMF), seria necessária a alteração apenas em um local, o
componente, caso este esteja sendo utilizado, enquanto que, se a
implementação da regra fosse feita em cada programa de interface com o
usuário, a alteração deveria ser feita em cada um dos programas, ainda com
o risco de, havendo falha na alteração, apresentar saldos diferentes nos
canais de interface com o usuário.
7.1. Mudança parcial de plataforma
Outra vantagem clara da componentização é
permitir a troca parcial de plataforma. No exemplo dado
na figura 2, supondo que haja necessidade de se trocar
o banco de dados utilizado, a alteração necessária é
feita apenas nos componentes que acessam o Banco de
Dados, não sendo necessário alterar as camadas de
negócio nem a camada de apresentação.
A figura 3 apresenta um esquema de 3 camadas
para um sistema baseado em componentes.
Figura 3 – Camadas de Componentes
12
Da mesma forma, poderia ser trocado um dos programas (ou
componentes) que faz interface com o usuário, sem a necessidade de se
alterar os demais componentes da aplicação (da camada de negócios e da
camada de persistência).
8. Classificação de componentes de software
Podemos classificar os componentes, do ponto de vista de seu uso e
especificidade, da seguinte maneira:
Componentes genéricos: são aqueles de uso comum em muitos
sistemas, tais como os componentes de interface com os usuários (GUI).
Componentes de serviços: são componentes que fornecem serviços
especializados, mas que não são específicos do ponto de vista de domínio de
aplicação, como componentes para tratamento de erros em comunicação de
dados, criptografia, segurança, geração de gráficos, etc.
Componentes de domínio: são componentes específicos para
domínios definidos, que implementam regras de negócio (de simples a
complexas), como por exemplo, regras do setor financeiro ou de construção
civil.
9. DBC e Desenvolvimento Orientado a Objeto
Embora o Desenvolvimento Baseado em Componentes (DBC) e o
Desenvolvimento OO (Orientado a Objetos) busquem os mesmos resultados
(desenvolvimento mais rápido, fácil e altamente produtivo de aplicações) e
dividam algumas similaridades, o DBC pode ser considerado uma evolução
da Orientação a Objetos pura.
Os componentes de software não precisam ser necessariamente
implementados em uma linguagem orientada a objeto. O principal requisito
envolve apenas a definição da interface, não importando se o código
encapsulado pelo componente é orientado a objeto ou não. No entanto, o
atual sucesso da abordagem de desenvolvimento de software baseado em
13
componentes deve-se, principalmente, ao paradigma da orientação a objetos
pois, essencialmente, Componentes são totalmente baseados em na
abordagem OO.
10. Mercado de Componentes
A tecnologia de Componentes virou um negócio próprio no mercado de
desenvolvimento de software, de forma que há empresas, principalmente no
exterior, especializando-se em ofertar ao mercado soluções de componentes
que implementam parcialmente um sistema.
Fazendo um paralelo com empresas de software que oferecem ao
mercado sistemas em forma “pacotes” de software, especializados em
determinado assunto, como Contabilidade, Contas a Pagar, Folha de
Pagamento etc, temos que esses pacotes implementam regras de negócio
comuns a quase todas as empresas, dentro de seu assunto principal. Quando
da implantação desse tipo de sistema em uma empresa, ajusta-se aqui ou ali,
customizando a solução conforme as necessidades da empresa, mas o core
do sistema, que representa a essência da necessidade do negócio, não é
alterado, ao menos substancialmente.
Ou seja, é possível afirmar que um “pacote” é uma solução de
software semi-pronta para atendimento parcial das necessidades de uma
empresa e que pode ser adaptado ou complementado para atendimento
pleno das necessidades de negócio, sem a necessidade de se investir na
construção completa de uma solução de software.
10.1. Componentes como “pacotes”
Nessa linha, os componentes entram como possibilidade de grande
ganho, uma vez que se pode implementar uma solução quase completa, com
o mesmo “espírito” do pacote, e customizar apenas, por exemplo, a camada
de apresentação.
14
Site daInstituição
"A"
ACESSO ABANCO DE
DADOS
REGRAS DENEGÓCIOS
Camada dePersistência
Camada deNegócio
"PACOTE" DE COMPONENTES VENDIDOPELA EMPRESA DE SOFTWARE
Camada deApresentação
Site daInstituição
"B"
Site daInstituição
"C"
Como exemplo, imagine uma empresa financeira que necessite
fornecer a seus clientes consultas sobre suas aplicações financeiras em
fundos de investimento, disponibilizando-as na Internet.
No mercado nacional, há várias empresas que oferecem esse tipo de
serviço. Uma empresa de software poderia oferecer, como solução, a
implementação parcial do sistema nas camadas de regras de negócio e de
acesso a banco de dados, como implementado nos níveis 1 e 2 da figura 2,
podendo a camada de apresentação ser personalizada com cores, logotipos
e padrões de apresentação da empresa.
Figura 4 – Exemplo de Sistema bancário implementado parcialmente com um pacote
de componentes
Como demonstrado na figura 4, uma empresa de software que
comercializa um pacote de componentes que implementa parcialmente um
site de consulta de informações de investimentos de cliente em fundos de
investimentos, pode vender essa solução a várias instituições financeiras.
15
A instituição financeira pode personalizar a camada e apresentação,
mas o software que está instalado “por trás” do site da Instituição “A”, é o
mesmo que os instalados nas instituições “B” e “C”.
11. Cuidados com Complexidade
A utilização de componentes em larga escala, em um ambiente de
desenvolvimento, pode trazer os benefícios já discutidos anteriormente.
Todavia, é necessário que se cuide de alguns aspectos importantes para o
sucesso do uso desta tecnologia.
Primeiramente, é necessário manter-se um catálogo de componentes,
rigorosamente documentado e com controle claro e atualizadíssimo de seu
funcionamento (assinatura, seu trabalho e seu retorno), de suas versões e
onde é utilizado.
Sem esse controle, há o risco de se utilizar versões obsoletas ou de se
alterar um componente utilizado em outros sistemas, com impactos não
previstos.
Em grande parte, esse controle deve ser feito pelo Gerenciamento de
Configuração e Mudanças.
12. Conclusão
A evolução das tecnologias trouxe uma nova perspectiva de
desenvolvimento através do DBC. A reutilização de componentes promete
trazer muitas vantagens, tais como: redução dos custos, tempo de produção
de software e o aumento da confiabilidade dos produtos. Todavia, estes
resultados dependem do gerenciamento efetivo do projeto, documentação
apropriada, padronização e forte controle de versão dos componentes.
Apesar de os primeiros conceitos sobre reutilização de software terem
sido idealizados no final da década de 1960, somente nos últimos anos, esse
tipo de tecnologia tornou-se uma vantagem competitiva para as empresas
que a empreguem, desde que estejam dispostas a mudar filosofias e formas
de trabalho tradicionais.
16
Referências
[1] BORBA, Paulo S. Proposta de um Processo Ágil de desenvolvimento de software utilizando Processo Unificado e Extreme Programming. São Paulo, 2004. Dissertação (Mestrado) – Universidade de São Paulo – Instituto de Pesquisas Tecnológicas. 2004
[2] BRERETON, P.; BUDGEN, D. Component-Based Systems: a classification of issues. Computer. v. 33, nº 11, Nov. 2000, pp. 54-62. 2000.
[3] CI&T. Soluções Componentizadas de Software para e-Business www.cit.com.br [10.03.2004]
[4] HOPKINS, J. Component Prime”. Communications of the ACM. v. 43, nº 10, Oct. 2000, pp. 27-30. 2000.
[5] KROLL, Per The Spirit of RUP The Rational Edge, dez-2001 www.therationaledge.com/content/dec_01/f_spiritOfTheRUP_pk.html 2001
[6] MARI, Matinlassi; EILA, Niemelä The Impact of Maintainability on Component-based Software Systems IEEE 29th Euromicro Conference set-2003, Belek-Antalya, Turkey 2003
[7] PARSONS, Rebecca Components and the World of Chaos IEEE Software mai/jun-2003 Vol 20 Issue 3 2003
[8] RATIONAL CORPORATION INC. Rational Unified Process – Best Practices for Software Development Teams A Rational Software Corporation White Paper 1998
[9] ROTHENBERGER, Marcus A.; Dooley, Kevin J.; Kulkami, Uday R.; Nada, Nader Strategies for Software Reuse: A Principal Component Analysis of Reuse Practices IEEE Transactions on Software Engineering set-2003 Vol 29 No. 9 2003
[10] SAMETINGER, J. Software Engineering with Reusable Components. Germany: Springer, 1997
[11] SOMMERVILLE, Ian Engenharia de Software (tradução da 6a edição) Addison Wesley 2003
[12] SZYPERSKI, C. Component Software: beyond object-oriented programming. Harlow: Addison-Wesley, 1999.
[13] WERNER, C.M.L.; BRAGA, R.M. Desenvolvimento Baseado em Componentes. In: Simpósio Brasileiro de Engenharia de Software- Minicursos/Tutoriais. João Pessoa: UFRJ, CEFET-PB, 2000, pp. 297-329. 2000
[14] WALLNAU,K.; HISSAM, S.; SEACORD, R.C. Half Day Tutorial in Methods of Component-Based Software Engineering Essential Concepts and Classroom Experience. In: ACM SIGSOFT Software Engineering Notes, Volume 26 , Issue 5 (September 2001), Pages: 314 – 315. 2001.
