Engenharia de Software Baseada em Componentes

Prévia do material em texto

Engenharia de 
Software Baseada 
em Componentes
Responsável pelo Conteúdo:
Prof. Me. Eduardo Kerr
Revisão Textual:
Prof.ª Esp. Kelciane da Rocha Campos
Projeto Baseado em Componentes
Projeto Baseado em Componentes
 
 
• A partir dos componentes padronizados, conhecer os graus de utilização e expansão possíveis 
na construção de um sistema;
• Abordar a utilização de componentes com características caixa preta, caixa branca e variações;
• Conhecer ferramentas para gerenciamento de projetos e repositório.
OBJETIVOS DE APRENDIZADO 
• Introdução;
• Desenvolvendo Software com Reuso;
• Tipos de Repositórios;
• Manutenção de Software Baseado em Componentes.
UNIDADE Projeto Baseado em Componentes
Introdução
Nesta unidade, vamos estudar com mais detalhe o processo de implementação de um 
sistema ou aplicação.
Quando concluímos os processos de Análise e Projeto de Domínio, precisamos sele-
cionar quais repositórios de componentes serão usados. A escolha de repositório precisa 
levar em consideração, basicamente, dois fatores:
• Se o projeto pertence a um domínio vertical ou horizontal;
• Se serão usados somente repositórios comerciais, somente repositórios públicos ou 
até mesmo uma combinação dos dois.
Esses fatores influenciam diretamente na implementação do projeto e em sua homo-
logação através dos testes.
Projeto
 Único
Repositório
 Multi
Repositórios
 Comercial
 Comercial
Público
Público
Figura 1
Sobre repositórios verticais e horizontais
Quando um projeto tem características para utilizar repositórios verticais, significa que a 
busca dos componentes será feita em repositórios que são específicos ao domínio do pro-
jeto - por exemplo: componentes para sistemas bancários ou transporte de cargas. Nesses 
casos, não significa que o projeto não necessita de código desenvolvido internamente (in-
-house), significa apenas que os componentes estão em repositórios que são especializados 
no domínio em que o novo sistema está classificado.
Os repositórios horizontais possuem componentes que podem ser utilizados em vários tipos 
de aplicações, independentemente do domínio a que pertencem - por exemplo: componen-
tes de edição de texto, geração de gráficos ou acesso a bancos de dados. 
Sobre repositórios comerciais e públicos
Quando os desenvolvedores utilizam repositórios comerciais, significa que o código-fonte 
dos componentes não está disponível, o projeto tem características de Caixa Preta. Embora 
o uso inicial atendesse à área de governo americano, em especial projetos da área militar, 
em pouco tempo os repositórios estavam presentes em todos os segmentos de mercado.
Se forem utilizados repositórios públicos, em geral, o projeto tem características de Caixa 
Branca. Os repositórios públicos foram abastecidos com contribuições de centros de pesqui-
sas e universidades; com a popularização da internet, milhares de colaboradores voluntários 
passaram a contribuir com conteúdo de código aberto. Muitas aplicações são construídas 
com componentes de repositórios públicos e vendidas no mercado.
Os repositórios Verticais e Horizontais estão presentes de forma comercial e pública.
8
9
A combinação de repositórios depende das necessidades requeridas pelos projetos 
e resultaram em algumas variações dos modelos de caixa preta e caixa branca. Vamos 
entender as variações, com suas características, vantagens e desvantagens.
Importante!
Na seção de Material Complementar, você pode encontrar uma grande quantidade e 
variedade de informações para esses repositórios, públicos e comerciais.
Desenvolvendo Software com Reuso
A partir das propostas de construir sistemas com componentes de software “pré-
-fabricados”, várias formas de aplicar esses conceitos, que são conhecidos nas indústrias, 
foram sendo elaboradas. Com ênfase nos últimos 20 anos, o reuso de software tomou 
novas dimensões. Para melhor entender essas dimensões, podemos dividir o reuso de 
software agrupando as metodologias em pelo menos 4 divisões. Sommervile, no capí-
tulo 15 de seu livro, na 10ª edição. Utiliza as seguintes classificações:
• Reuso de sistema: quando um sistema é desenvolvido para executar diversas funcio-
nalidades e o mesmo sistema pode ser reutilizado em diferentes organizações;
• Reuso de aplicação: quando uma aplicação desenvolvida pode ser incorporada ou 
conectada em outras aplicações, sem necessidade de ter seu código-fonte alterado, 
ou quando uma aplicação pode ser criada com componentes que foram utilizados 
para uma família de aplicações;
• Reuso de componentes: quando um componente de software pode ser utilizado 
em diferentes módulos;
• Reuso de objeto: quando um componente que executa uma função de baixa comple-
xidade pode ser usado ou combinado com outros objetos, criando módulos funcionais 
em um sistema.
Com a utilização de reuso para vários objetivos, novas metodologias foram propostas 
e adotadas. O ponto de partida é o reuso. A Figura 2 representa um panorama mais 
amplo das principais técnicas que aplicam conceitos de reuso de software.
Engenharia Baseada em Componentes Engenharia Dirigida a Modelos
Padrões de Projeto Padrões de Arquitetura
Sistemas de Aplicação Con�gurável
Integração de Aplicações Sistemas de ERP Sistema Orientado a Aspectos
Framework de Aplicações Linhas de Produtos de Software
Empacotamento de Sistemas Legados Sistemas Orientados a Serviços
Geradores de Programas Biblioteca de ProgramasSistemas de Sistemas
Figura 2 – Panorama de reuso
9
UNIDADE Projeto Baseado em Componentes
A busca por eficiência, velocidade e qualidade no desenvolvimento de software pro-
duziu uma variedade de abordagens para as necessidades, diversidade de aplicação e 
características específicas dos projetos. Vamos ver esses paradigmas de reusabilidade:
• Padrões de Projeto: Soluções genéricas que aplicamos aos problemas repetitivos 
em projetos;
• Padrões de Arquitetura: Soluções genéricas para um problema que ocorre 
com frequência em arquitetura de software dentro de um determinado contexto. 
São semelhantes aos padrões de projeto de software, mas possuem um escopo 
mais amplo;
• Framework de Aplicações: Utiliza extensão e adaptação de um conjunto de classes 
concretas e abstratas para implementar uma aplicação;
• Linhas de Produtos de Software: Família de sistemas que têm um conjunto de 
funcionalidades em comum, do mesmo segmento de mercado ou missão, desen-
volvido com um núcleo comum;
• Integração de Aplicações: Dois ou mais sistemas de aplicação são integrados para 
fornecer funcionalidade estendida;
• Sistemas de ERP: Dois ou mais sistemas de aplicação são integrados para fornecer 
funcionalidade com alto grau de parametrização;
• Sistema Orientado a Aspectos: Técnica de modularização de código para apoiar 
a reutilização. Essa técnica não é específica para desenvolver aplicações com reuso, 
mas para desenvolver componentes para reuso;
• Engenharia Baseada em Componentes: Módulos de software (podem ser de 
funcionalidade simples às mais complexas) que são integrados para criação da 
aplicação ou sistema;
• Engenharia Dirigida a Modelos: Geração de código a partir de modelos de domínio 
e modelos de implementação;
• Empacotamento de Sistemas Legados: Sistemas desenvolvidos para comparti-
lhar funcionalidades de sistemas já existentes;
• Sistemas Orientados a Serviços: Sistemas desenvolvidos em que aplicativos ou 
módulos de software são disponibilizados como serviços em uma rede de compu-
tadores de forma independente e se comunicando através de padrões abertos;
• Geradores de Programas: Geram aplicações no domínio específico de conheci-
mento a partir de uma linguagem de especificação. O reuso das especificações de 
sistemas de uma linha;
• Biblioteca de Programas: Classes e funções que implementam abstrações comu-
mente usadas como coleção de objetos;
• Sistemas de Sistemas: São uma coleção de sistemas orientados a tarefas ou dedi-
cados que reúnem seus recursos e capacidades para criar um sistema novo e mais 
complexo,que oferece mais funcionalidade e desempenho do que simplesmente a 
soma dos sistemas constituintes;
• Sistemas de Aplicação Configurável: Os sistemas de um mesmo domínio são 
projetados para que possam ser configurados de acordo com as necessidades 
de clientes.
10
11
As abordagens mencionadas possuem níveis diferentes de reuso:
• Nível abstrato: Neste nível, você não reutiliza o software diretamente, mas usa o 
conhecimento de abstrações, modelos bem-sucedidos que se aplicam a tipos de 
problemas já conhecidos;
• Nível de objetos: Neste nível, você reutiliza objetos diretamente de uma biblioteca 
ou repositório, em vez de escrever o código por conta própria. Não existem defini-
ções claras quanto ao tamanho ou às funções desses objetos;
• Nível de componentes: Componentes são coleções de objetos e classes de obje-
tos que você reutiliza em sistemas de aplicação; em geral, executam funções mais 
complexas que os objetos;
• Nível de sistema: Neste nível, você reutiliza sistemas de aplicativos inteiros.
 No Quadro a seguir, agrupamos as abordagens de reuso quanto ao nível de reuso.
 Quadro 1 – Nível de reuso
Nível Abstrato
• Geradores de Programa;
• Engenharia Dirigida a Modelo;
• Padrões de Projeto;
• Padrões de Arquitetura.
Nível de Objetos
• Framework de Aplicação;
• Biblioteca de Programas.
Nível de Componentes
• Engenharia Baseada em Componentes;
• Sistemas Orientados a Serviços;
• Linhas de Produto de Software;
• Sistema Orientado a Aspectos.
Nível de Sistemas
• Sistema de Aplicação Configurável;
• Sistema de Sistemas;
• Empacotamento de Sistemas Legados;
• Integração de Aplicações;
• Sistemas de ERP.
As abordagens de Nível de Objetos e Nível de Componentes são muito semelhantes. 
Os processos de Análise e Projeto, que antecedem a implementação, são similares, pois 
o processo de escolha e validação dos componentes depende da boa execução desses 
processos, de forma que os componentes candidatos para reuso possam atender às es-
pecificações e funcionalidades documentadas.
A construção de uma aplicação pode ser feita com módulos de software simples ou 
complexos; em muitos casos, é necessário o uso de uma “cola” para compatibilizar os 
componentes/objetos. Nesses casos, ocorre desenvolvimento de código que atue como 
“cola” de objetos dos repositórios ou uso de software do tipo middleware.
A Figura 3 é um exemplo de implementação para essas abordagens.
11
UNIDADE Projeto Baseado em Componentes
Componentes/ Objetos
Aplicação
Saída
Processamento
Entradas
Usuários
Figura 3 – Nível de Objetos/ Nível de Componentes
A reusabilidade no Nível de Sistemas utiliza programas de suporte com funções que 
visam configurar, inicializar bases de dados com regras de negócio e parametrização de 
acordo com cada módulo/sistema a ser integrado.
Muitas vezes, é necessário utilizar um conversor de formato de dados entre aplica-
ções, realizar monitoramento do status de processamento ou sincronizar a comunicação 
de processos entre aplicações. Esses programas são conhecidos como Configurador, 
Conversor ou Integrador.
Existe uma variedade de produtos que realizam integração de sistemas, em especial 
uma classe que oferece funcionalidades complexas e abrangendo diversas tecnologias. 
Os produtos comerciais líderes mundiais nesse mercado são o Data Integration Hub, 
desenvolvido pela Informatica, e o BizTalk, desenvolvido pela Microsoft. No segmento 
de software livre, o destaque é para o Cenit.IO. Esses produtos são conhecidos como 
Integradores de Plataforma, classificados como produtos de IpaaS.
Importante! 
Fatores críticos no desenvolvimento com componentes
Processos de Análise e Projeto executado por equipe especializada, de forma a permitir 
a correta seleção dos componentes, avaliação de custo-benefício, manutenção, tempo 
de desenvolvimento e mudança de cultura gerencial.
Tipos de Repositórios
O desenvolvimento de sistemas com reuso utiliza repositórios comerciais ou públicos.
A sigla COTS (Comercial Of The Self), traduzida como “Produtos de Prateleira”, é 
utilizada para se referir a produtos comerciais adquiridos e prontos para uso. Os COTS 
são oferecidos como arquivo executável binário, descrições de funcionalidade e detalhes 
das interfaces de entrada e saída do componente.
Um projeto que utiliza repositório do tipo COTS pode enfrentar dificuldades quando 
um ou mais componentes não atendem completamente aos requisitos funcionais, embora 
sejam do tipo “quase”. Surge, então, uma nova modalidade para contornar a rigidez do 
modelo COTS. Nesse novo modelo, os usuários analisam a possibilidade de contratar a 
modificação do componente junto aos desenvolvedores. Logicamente, depois de analisar 
12
13
tempo e custo para adotar essa alternativa e na hipótese de os desenvolvedores estarem 
dispostos a construir uma versão modificada. Essa modalidade ficou conhecida como 
MOTS (Modified Of The Self). Essas modificações geram um componente específico 
para o projeto, mas acabam com o paradigma de reusabilidade, se for utilizado somente 
uma vez. Os custos podem não compensar e dependendo da negociação, o componente 
terá ou não código aberto. Se o código se tornar propriedade do usuário, acaba a respon-
sabilidade de manutenção. É uma decisão importante.
MOTS também é usado como abreviação de componentes de software para indús-
tria militar, Military of The Self, onde o domínio é específico para esse mercado, e 
raramente componentes desse tipo são oferecidos para mercado aberto.
Entre os sistemas que são classificados como COTS temos os exemplos do pacote 
Office da Microsoft e de software de ERP.
O pacote do MS Office é composto por programas como Word, Excel, Power Point, 
entre outros. Dentro desses programas, podemos estender algumas funcionalidades, 
incorporando código-fonte e plug-in(s).
Pacotes de ERP têm complexidades maiores, mas também oferecem recursos mais 
sofisticados de configuração e integração em plataformas diferentes.
A Figura 4 auxilia a compreensão das características.
Compras Vendas Logística CRM
Processos Processos Processos Processos
De�nição de Regras de Negócios
Base de Dados do ERP
Figura 4 
Fonte: Adaptada de PRESSMAN, 2016 
Na aquisição de um sistema comercial de ERP, a organização pode decidir quais 
módulos serão implementados, reduzindo custo de aquisição, e eventualmente integrar 
um ou mais módulos já existentes. Os módulos do produto, em geral, são independentes 
e permitem um alto grau de personalização. Além de configurações feitas na base de 
dados, disponibilizam recursos para integração, importação e exportação das informa-
ções. Permitem definir um conjunto de processos de negócios, associados a cada módu-
lo, que se relacionam às atividades nesse módulo.
Aplicativos turn-key – São os aplicativos ou sistemas com vários módulos. Os pacotes de 
ERP e Office são exemplos desses sistemas, oferecendo uma variedade de configuração 
e empacotados de formas variadas.
A utilização de repositório com componentes gratuitos se tornou muito popular nas úl-
timas décadas. A ideia de sistemas com código-fonte aberto começou na década de 1960, 
13
UNIDADE Projeto Baseado em Componentes
restrita ao ambiente universitário; hoje, no entanto, existem diferentes modelos de negócio e 
licenciamento de sistemas com código publicado em repositórios. Várias empresas oferecem 
serviços para os componentes, pacotes e sistemas que têm o código-fonte disponível em re-
positórios públicos. Dentro dessa modalidade, vamos citar dois exemplos muito populares: a 
família de sistema operacional Unix (Linux, BSD, etc.) e o sistema para construção de sites e 
loja virtual Magento. Embora haja o código aberto desses sistemas, várias empresas exploram 
a comercialização de serviços, movimentando um negócio bilionário. Como acontece em 
muitos casos, um sistema de código aberto pode ser comprado por uma empresa e passar a 
oferecer serviços, aprimoramentos e funcionalidades especiais que não estarão mais cobertos 
pela licença de código aberto. Dessaforma, o sistema passa a oferecer versões paralelas, uma 
com código aberto e outra com código fechado, ou parcialmente fechado. A Adobe comprou 
a Magento em 2018 e oferece uma versão diferenciada do sistema no mercado.
Você sabia?
• 70% dos sistemas operacionais de servidores são da família Linux;
• 240 mil lojas vituais usam a plataforma Magento.
Fonte: https://red.ht/3xbbs0m
Projeto Caixa Preta
Os projetos que são desenvolvidos com COTS visam usufruir o máximo dos benefícios 
da reusabilidade, reduzindo o tempo de entrega e custos de desenvolvimento, e das vanta-
gens de utilizar componentes e objetos que tenham sido testados. As vantagens são muito 
atrativas, mas antes de decidir precisamos conhecer um pouco mais esse paradigma.
Os efeitos resultantes do uso extensivo de produtos COTS devem ser bem conhecidos 
e considerados na tomada de decisão:
• Independentemente da quantidade de componentes que um sistema pode ter, 
existe uma alta probabilidade desse sistema ainda precisar de desenvolvimento 
interno; usar COTS sempre vai requerer investimentos adicionais, além da aqui-
sição dos componentes;
• O uso de COTS modifica profundamente a elaboração dos custos de construção de 
softwares tradicionais;
• A utilização de COTS exige uma mudança de paradigma em muitos setores, além 
da contabilização de custos: especificação, usabilidade, manutenção, documentação, 
controle de versão e gestão estratégica.
O fato de haver desenvolvimento interno para integrar componentes COTS não altera 
classificação de projeto Caixa Preta. Algumas métricas definem qual porcentagem de 
projeto utiliza reusabilidade.
Projeto Caixa Branca
Com a quantidade de código-fonte disponível em repositório, dos mais variados seto-
res, a prática de usar componentes ou sistemas inteiros se tornou uma atividade muito 
popular. Um dos locais mais utilizados para abrigar essas atividades é o GitHub.
14
15
O repositório GitHub surgiu em 2007 visando oferecer um repositório para colaboração em 
desenvolvimento de software, com mecanismo que auxilia a controlar versões dos códigos 
armazenados. Teve um crescimento explosivo até ser adquirido pela Microsoft em 2018. 
Hoje pode ser utilizado como repositório público e privado, com inúmeras funcionalidades 
que foram sendo incorporadas no decorrer dos anos. Dados de 2020 apontam para:
• 40 milhões de usuários;
• 100 milhões de repositórios;
• 28% dos repositórios são de software de código aberto.
Fonte: https://bit.ly/3g8XLcC
Usar componentes com código-fonte disponível resolve muitos problemas técnicos 
de desempenho e especificação, principalmente quando há necessidade de conhecer 
e analisar algoritmos utilizados, modificar interface ou estender funcionalidades de 
um componente.
A variedade de componentes disponíveis em repositórios é impressionante. O volume 
de objetos, componentes e sistemas com código aberto disponível para reusabilidade, 
em diferentes plataformas, inclui, por exemplo:
• Sistemas operacionais, compiladores de linguagem de programação;
• Sistemas gerenciadores de conteúdo, CRM, gestão de projetos;
• Aplicativos de escritório (editores e planilhas), aplicativos financeiros;
• Módulos de workflow de tarefas, monitoramento no campo de IoT;
• Gerenciamento de interface gráfica, conversão e compactação de arquivos;
• Classes e objetos de botões, menus, caixa de texto e algoritmos de ordenação.
Projeto Caixa Cinza
Como alternativa ao modelo MOTS, alguns repositórios de componentes oferecem 
a possibilidade de tratar as possíveis incompatibilidades de interfaces, pois os compo-
nentes podem precisar interagir com interfaces que não são compatíveis. Essa incom-
patibilidade ocorre devido a assinaturas de métodos diferentes ou por heterogeneidade 
dos componentes (diferença na linguagem de programação, na plataforma de execução 
e localização física).
Assinatura: É a forma de identificar um método de forma única. Em linguagens onde vários 
métodos podem ter o mesmo nome, você precisa ter uma outra forma de evitar a ambigui-
dade. O compilador precisa saber qual dos métodos com mesmo nome você está chamando. 
Então, você precisa se valer de informações extras disponíveis no método para tomar uma 
decisão. O mais comum é analisar os parâmetros. Se todos os parâmetros forem iguais, por 
igual entenda que a ordem também é importante, dizemos que os métodos possuem a 
mesma assinatura; se apenas um desses parâmetros for diferente, assinaturas diferentes. 
As linguagens de programação Java e C#, por exemplo, utilizam o critério de análise dos 
parâmetros para determinar a assinatura de um método.
15
UNIDADE Projeto Baseado em Componentes
No caso de incompatibilidade de interfaces, a adaptação é possibilitada com a utilização 
de uma linguagem de extensão do componente ou API que possibilite a remoção ou mas-
caramento de conflitos. Embora ofereça flexibilidade no que diz respeito a resolver eventuais 
incompatibilidades de interfaces, o código-fonte do componente também não é conhecido.
Projeto Híbrido
Os projetos de aplicações e sistemas que combinam uso de COTS e componentes 
de repositórios públicos, ou mesmo módulos desenvolvidos internamente (in-house), são 
projetos híbridos. Esse modelo é muito comum principalmente em projetos que não se 
encaixem em um domínio vertical. Até mesmo aplicações com reusabilidade no nível 
de sistemas – por exemplo, um sistema de ERP – podem necessitar de componentes 
adicionais que façam integrações com outros módulos de software.
As métricas para análise de custo-benefício ajudam a tomada de decisão por uma 
organização quanto à opção de desenvolvimento. A economia de custo pelo reuso é 
estimada em quanto se economiza em termos de construir aplicações com COTS, 
comparando-se a uma estimativa de desenvolver toda a aplicação. Essa análise não é 
simples, envolve custo de desenvolvimento (computadas todas as etapas de especifi-
cação, codificação e testes), comparando-se com custo de aquisição de componente e 
custo de integração feita internamente.
Outros fatores indiretos podem influir no tempo estimado de entrega do produto em 
função do tempo necessário para ter o sistema operacional.
Manutenção de Software 
Baseado em Componentes
A manutenção de sistemas é uma atividade muito conhecida e estudada pelos desenvol-
vedores de software. Fatores que influenciam diretamente a execução de manutenção são 
conhecidos, mas nem sempre possíveis de controlar.
Os custos de manutenção e suporte são oferecidos no mercado com valores que variam 
entre 10% e 25% do custo de aquisição dos sistemas.
Para os autores Lientz e Larssen (2006), ações ligadas à atividade de manutenção de 
software foram classificadas em três categorias:
• Corretiva: são modificações necessárias para corrigir ou prevenir erros. Quando um 
produto de software apresenta erros durante o funcionamento ou quando a manuten-
ção precisa ser feita para evitar situações que, embora ainda não apresentem erros, 
podem causar falhas efetivas;
• Adaptativa: modificação de um produto de software realizada após a entrega para 
manter um produto de software utilizável em um ambiente alterado ou em mudança. 
Por exemplo, troca de plataforma de hardware, evolução tecnológica;
• Manutenção evolutiva (perfectiva): modificação de um produto de software após 
a entrega para melhorar o desempenho ou a facilidade de manutenção.
16
17
Dependendo do tipo de projeto adotado, o processo de manutenção apresenta as 
seguintes características:
• Projeto Caixa Preta :
» Manutenção corretiva é feita pelo fabricante dos componentes, quando o usuário 
detecta o erro. A previsão de correção de erro não pode ser prevista;
» Manutenção adaptativa e evolutiva: pode ocorrer a pedido do usuário ou eventu-
almente ser oferecida pelo fabricante do componente. No caso de ser solicitada 
pelo usuário, pode não haver estimativa de prazo ou, ainda pior, o fabricante 
não oferecer esse tipo de manutenção. Ainda nesse caso, o contrato comercial 
de aquisição pode nãocobrir esse tipo de manutenção/modificação, provocando 
custos não estimados/previstos na contratação.
• Projeto Caixa Cinza : Possui o mesmo conjunto de características do projeto Caixa 
Preta, embora a linguagem de extensão, ou API, permita criar um grau de empacota-
mento que pode reduzir as necessidades de alteração e manutenção, quando estiver 
relacionada à compatibilização das interfaces.
• Projeto Caixa Branca : As três categorias de manutenção podem acontecer de três 
formas distintas:
» Por parte dos desenvolvedores ou da comunidade que adota uso dos componentes 
e publica correções de forma voluntária;
» Por terceiros, que terão que ser contratados para dar suporte e manutenção ao 
pacote utilizado;
» Pelos usuários do pacote.
• Projeto Híbrido : Pode ter a soma das características de Caixa Preta e Caixa Branca.
Segundo Lientz e Larssen (2006), a proporção do esforço de manutenção é de 20% 
para corretivas, 25% para adaptativas e 50% para evolutivas. Embora esses dados tenham 
mais de duas décadas, as publicações atuais apontam para estimativas semelhantes. 
A maioria dos sistemas é considerada um organismo “vivo” em constante modificação; 
portanto, manutenção é parte do ciclo de vida.
Quando lidamos com manutenção de componentes, não importa se provenientes 
de repositórios comerciais ou públicos, cresce a importância de adotar um sistema que 
controle e documente a versão de cada componente utilizado em uma aplicação. Vamos 
entender melhor essa importância na próxima unidade.
Em Síntese
A reutilização no nível de sistemas fornece muitas funcionalidades e pode reduzir radical-
mente os custos e o tempo de desenvolvimento.
O reuso pode acontecer com unidades de tamanhos muito diferentes:
• Os sistemas podem ser desenvolvidos configurando-se um sistema de aplicativos 
único e genérico ou integrando-se dois ou mais sistemas de aplicativos;
• Reuso de componentes: componentes de software de tamanho variado;
• Reuso de objetos e funções que implementam funcionalidades simples;
• Reuso de conceitos e abstrações de modelos bem-sucedidos que se aplicam a tipos 
de problemas já conhecidos.
17
UNIDADE Projeto Baseado em Componentes
Fatores-chave a considerar para o reuso:
• O cronograma de desenvolvimento do software;
• A expectativa de duração do software;
• O conhecimento, as habilidades e a experiência da equipe de desenvolvimento.
Problemas potenciais com a reutilização do sistema de aplicativos:
• Falta de controle sobre funcionalidade e desempenho;
• Falta de controle sobre a evolução do sistema;
• Necessidade de suporte de fornecedores externos;
• Dificuldades em garantir que os sistemas possam interoperar.
18
19
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Component Source
Um marketplace de COTS, com grande variedade de fornecedores.
https://bit.ly/3g75TdB
 Leitura
História do software livre
https://bit.ly/3a4wzrq
As 12 melhores bibliotecas de gráficos para desenvolvedores web
https://bit.ly/3g8iCfS
O Impacto do COTS no Processo de Engenharia de Requisitos
https://bit.ly/3e2pgBB
19
UNIDADE Projeto Baseado em Componentes
Referências
LIENTZ, B.; LARSSEN, L. Risk management for IT projects. London: Routledge, 2006.
PRESSMAN, R. MAXIM, B. Engenharia de Software, uma abordagem profissio-
nal. 8ª edição. Porto Alegre: AMGH, 2016.
SOMMERVILLE, I, Engenharia de Software. 10ª edição. São Paulo: Pearson, 2019.
20