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
Engenharia de Software Baseada em Componentes (ESBC)
Engenharia de Software Baseada 
em Componentes (ESBC)
 
• Compreender o processo de desenvolvimento a partir da definição de requisitos de sistema, 
análise de arquitetura e seleção dos componentes;
• Avaliar as vantagens e desvantagens na utilização de componentes.
OBJETIVOS DE APRENDIZADO 
• Desenvolvimento Baseado em Componentes.
UNIDADE Engenharia de Software Baseada 
em Componentes (ESBC)
Desenvolvimento Baseado 
em Componentes
Já conhecemos os motivos que impulsionaram o paradigma de construção de sis-
temas, usando princípios de engenharia e em especial a adoção de metodologias que 
utilizassem componentes.
Vamos entender como o processo de construção de sistemas usando componen-
tes foi adotado e veremos que não se trata apenas de conectar peças para obter um 
sistema ao final.
Anteriormente, usamos uma imagem de peças de Lego e outra que mostra a cons-
trução de algo complexo. Essas imagens representam uma analogia para introdução aos 
conceitos iniciais desta disciplina, mas sempre devemos ter cuidado com as analogias 
para não extrair mais informações do que elas pretendem transmitir.
Você Sabia?
Eli Whitney, de New Haven Connecticut, EUA, recebeu um pedido de muitas armas em 1789. 
Em vez de contratar muitos armeiros individuais, ele projetou peças intercambiáveis e fa-
bricou gabaritos e acessórios para que pessoas não qualificadas pudessem fazer as peças. 
Ele perdeu o cronograma de entrega, mas é creditado por ter inventado a abordagem de 
peças e montagens com peças reutilizáveis, os princípios e técnicas das peças e montagens. 
Desde então, essa abordagem tornou-se conhecida e o suporte automatizado para a 
documentação existe em todo o setor (NEIGHBORS,1980 apud EDWARDS, 1974, p. 612).
O projeto de sistemas reutilizando componentes adota uma metodologia conhecida 
como Engenharia de Domínio (ED).
Arango descreve o conceito de ED como o método que “trata da identificação siste-
mática, aquisição e a transformação de informações reutilizáveis em domínios de proble-
mas restritos” (ARANGO, 1988).
Na Engenharia de Software:
• Domínio: é o conjunto de “características” que descrevem problemas, necessi-
dades e soluções em um campo específico para o qual uma aplicação de software 
é utilizada;
• Artefato: é um dos vários tipos de subprodutos produzidos durante o desenvol-
vimento de software. Alguns artefatos (por exemplo, casos de uso, diagramas 
de classes, requisitos e documentos de projeto) ajudam a descrever a função, 
arquitetura e o design do software.
Essa metodologia é resultado da união de conhecimento empírico, que é quando 
aprendemos os fatos através das experiências vividas e presenciadas, com a aplicação de 
técnicas formais e científicas para construir, melhorar e/ou operar artefatos.
8
9
No estudo mais aprofundado da ED, vamos encontrar metodologias que se aplicam 
quando o objetivo é a construção de software para reuso; e quando tratamos de cons-
truir software com reuso, usamos a expressão Engenharia de Aplicação. Software para 
reuso trata de construir os componentes. Software com reuso trata de utilizar compo-
nentes para construir sistemas.
Engenharia de Domínio e Engenharia de Aplicação se completam em suas etapas, 
como pode ser observado na Figura 1.
Sistema
Modelo de
 domínio
Análise de
 domínio
Projeto de 
 domínio
Implementação
 de domínio
 Requisitos de 
 análise
 Projeto de 
 sistemas
Implementação 
 de sistema
Requisitos de
 sistema
Arquitetura 
 de domíno 
Componentes 
 de domínio 
Engenharia de Domínio
Engenharia de Aplicação
 Novo 
Sistema
Figura 1 – Software Technology for Adaptable, Reliable Systems
Fonte: Adaptada de Eletronic Systems Center et al., 1994
Vamos ver as definições formais desses processos:
Importante!
Engenharia de Domínio:
• se preocupa com a identificação e modelagem de características comuns e das va-
riáveis das aplicações em um determinado domínio. Como resultado, geramos os 
modelos de domínio (e.g. casos de uso de domínio, classes do domínio) que podem 
ser reutilizados em aplicações específicas (PRIETO-DIAZ & ARANGO, 1991).
Engenharia de Aplicação:
• é o processo de construção de sistemas a partir dos resultados obtidos na engenha-
ria de domínio. Na engenharia de aplicação, aplicações são instanciadas a partir da 
seleção de um subconjunto de artefatos reutilizáveis que foram desenvolvidos na 
engenharia de domínio. Os processos de engenharia de domínio e engenharia de 
aplicação são paralelos, e existem pontos em que os resultados da engenharia de 
domínio alimentam a engenharia de aplicação (LOBO; RUBIRA, 2009).
Nesta unidade, vamos ver as etapas do processo de engenharia de domínio, quando 
queremos produzir componentes para serem utilizados, e os processos de engenharia de 
aplicação, quando temos um projeto baseado em reuso de componentes.
Engenharia de Domínio
O objetivo da Engenharia de Domínio (ED) é fornecer reutilização entre sistemas de 
software semelhantes, ela mostra que a maioria dos sistemas de softwares desenvolvidos 
9
UNIDADE Engenharia de Software Baseada 
em Componentes (ESBC)
não são novos, mas variantes de outros sistemas dentro do mesmo campo. Como resul-
tado, através do uso da engenharia de domínio, as empresas podem maximizar lucros 
e reduzir o tempo para colocação da solução no mercado, usando os conceitos e imple-
mentações de sistemas de software legados e aplicando-os nas novas soluções.
ED é uma metodologia sistemática para fornecer uma arquitetura comum para desen-
volvimento de sistemas. Czarnecki, em sua tese de doutorado, Generative Programming, 
considera que ED é formada por três processos:
• Análise de domínio: identificar fontes de informações e mapeamento de necessi-
dades, organização e documentação;
• Projeto de domínio: construção do modelo abstrato e modelo de infraestrutura;
• Implementação de domínio: formação de um conjunto de componentes que 
satisfaça o domínio.
Essa classificação em três processos é consagrada na literatura acadêmica; no en-
tanto, nas últimas três décadas a ED tem sido objeto de abordagens distintas, principal-
mente pelas características dos domínios. Com isso, os três processos nem sempre são 
identificados facilmente nas metodologias existentes. As características de um domínio, 
suas funcionalidades, atributos e relacionamentos motivaram a criação de ED com dife-
rentes processos. Vejamos alguns dessas Metodologias:
• Organization Domain Modeling: com Planejamento de Domínio, Modelagem de 
Domínio e Engenharia de artefatos básicos;
• Feature Oriented Domain Analysis com Análise de Contexto, Modelagem de 
Domínio e Modelagem de Arquitetura;
• Reuse Method Software Engineering for Business com Análise de Domínio, 
Projeto de Modelo e Definição de Arquitetura;
• Domain Specific Software Architecture: com Análise de Requisitos e Modelagem 
de Arquitetura;
• Domain Analysis Reuse Environment com Análise de Domínio e Implementação 
de Domínio.
Como podemos notar, algumas metodologias usam nomenclaturas diferentes para os 
processos da metodologia ED; vamos adotar no nosso curso a nomenclatura consagrada 
descrita por Czarnecki e amplamente utilizada no meio acadêmico, independentemente 
de como é referenciada nas diferentes metodologias.
Análise de domínio
No processo de análise, os domínios podem ser classificados em dois tipos:
• Horizontais: É quando o domínio está presente em vários sistemas; sendo assim, 
os componentes de um domínio horizontal podem estar presentes em sistemas de 
funcionalidades distintas. Os componentes de um domínio horizontal com funções 
matemáticas, por exemplo, podem ser usados em um sistema de cálculo de enge-
nharia civil e em sistemas de contabilidade. Esses sistemas certamente necessitam 
de componentesde outros domínios horizontais para completar as funcionalidades. 
Outros exemplos de domínios horizontais: interfaces gráficas do usuário, acesso ao 
sistema de arquivos, acesso a banco de dados;
10
11
• Verticais: É quando o domínio possui elementos específicos para um modelo de 
negócio, significa que esse domínio possui a estrutura completa e os componentes 
para atender a sistemas que possuam o mesmo modelo de negócio. Os componen-
tes de sistema de registros médicos, por exemplo, serviriam para sistemas em vá-
rios consultórios, todos os componentes necessários para implantar um sistema em 
um consultório seriam configurados com dados específicos, mas seriam os mesmos 
componentes e estrutura que seriam usados em outros consultórios. O sistema de 
registros médicos é um exemplo típico do que costumamos chamar de “software
de prateleira”. Outros exemplos de domínios verticais: aviação, telecomunicações, 
direito tributário.
Importante!
Em uma pesquisa realizada pelo Standish Group, em 350 empresas, com dados de 8000 
projetos de software, foi apurado que quase 2300 projetos fracassaram. As causas de 
25% dos insucessos ocorreram na etapa de análise, onde requisitos incompletos e falta 
de participação adequada dos usuários-chave causaram o cancelamento dos projetos.
Essa etapa é muito semelhante à engenharia de requisito, já conhecida das metodo-
logias tradicionais, requer participação ativa por parte dos usuários do domínio, pois é 
necessário conhecer os requisitos funcionais e não funcionais, junto com os profissionais 
experientes em desenvolvimento de componentes. Mas o levantamento das informações 
para documentação do processo de análise entra em muito mais detalhes.
Destacamos ainda outras necessidades para mapeamento nessa fase de análise:
• informações operacionais (usuários, infraestrutura, sistemas atuais);
• documentos.
Vamos detalhar cada um desses tópicos.
• Requisitos funcionais: descrevem as necessidades ou funcionalidades esperadas 
em um processo que podem ser atendidos pelo software. De forma geral, um re-
quisito funcional expressa uma ação que deve ser realizada através do sistema. Ex.: 
registro de vendas, calcular total, gerar relatório, processar pagamento por cartão 
de crédito, capturar código de produto com leitora de código, exibir tela de consul-
ta com preço e estoque de produto. Em especial, os dados referentes à interface de 
entrada e saída precisam ser detalhados. Anteriormente, vimos que as informações 
disponíveis para aplicar o reuso de software se restringe às informações de entrada 
e saída dos componentes; na prática, é muito raro ter acesso ao código fonte dos 
componentes. Essas informações funcionam como contrato entre as partes en-
volvidas no desenvolvimento e os usuários. Sendo assim, é importante incluir nos 
requisitos funcionais as expectativas quanto à interface de entrada e saída ;
• Requisitos não funcionais: são aqueles que não interferem diretamente no de-
senvolvimento do sistema propriamente dito, ou seja, não são um requisito que 
podemos codificar, no entanto estabelecem como o sistema se comportará em 
determinadas situações. Ex.: tempo de resposta, confiabilidade, usabilidade, porta-
bilidade, memória ocupada ;
11
UNIDADE Engenharia de Software Baseada 
em Componentes (ESBC)
• Informações operacionais: fornecem informações que servem como diretrizes ge-
renciais, qualificação dos usuários, ambiente ou sistemas, que são necessárias para 
realizar operações. Ex.: procedimentos gerenciais, tipos de usuários que terão acesso 
ao sistema, tipo de perfil de cada usuário com regras de acesso, plataforma de har-
dware, forma de integração com sistemas integrados;
• Documentos: documentação de sistema, manuais, legislação pertinente. O conjun-
to de informações existente vai se somar aos dados que serão coletados junto aos 
usuários através de entrevista e consultas aos especialistas do domínio.
No final da etapa de análise, a documentação produzida deve incluir informações que 
caracterizam o Modelo do Domínio. Essa descrição deve conter:
• Modelo abstrato do domínio: geralmente, utilizando UML e usando os diagramas 
de casos de uso e os modelos de entidade-relacionamento;
• Modelo de característica: com descrição de atributos e das características classifica-
das como obrigatórias, opcionais (ou alternativas) e restrições. Esse modelo permite 
criar relações entre as características e composição, combinando duas ou mais 
características, possibilitando descrições complexas dos sistemas que fazem parte 
de um domínio. Algumas metodologias desenvolveram linguagem e padrões de 
diagramação para descrever essas informações;
• Modelo funcional: com identificação das funcionalidades comuns e variáveis do 
domínio. Os diagramas comportamentais (ver figura 2.2) da UML podem ser usa-
dos para documentar esse modelo;
• Dicionário: com definição clara dos vocabulários e termos utilizados no domínio.
Vamos imaginar que ocorram falhas durante a coleta de informações na análise de 
domínio. As consequências serão refletidas na qualidade ou na disponibilidade dos com-
ponentes; dessa forma, podem inviabilizar um projeto no futuro, produzindo um sistema 
de baixa aceitação pelos usuários, provocando erros de processamento devido requisitos 
ambíguos, demandando esforços adicionais de integração com outros sistemas, enfim, 
desperdícios de tempo e dinheiro, no mínimo, podendo custar vidas humanas, depen-
dendo do domínio da aplicação.
O Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE), criado em 1963, promove co-
nhecimento no campo da engenharia elétrica, eletrônica e computação e desempenha um 
importante papel no estabelecimento de padrões para formatos de computadores e dis-
positivos e qualidade de serviços e produtos, baseado em consenso e associado a outros 
organismos não governamentais.
Visando dar mais garantia de qualidade no processo de análise e documentação de 
projetos de software, o IEEE publicou a norma de recomendação IEEE Std 830-1998, 
IEEE Recommended Practice for Software Requierents Specifications, as característi-
cas desejáveis de requisitos, mas que se aplicam às informações que devemos coletar na 
etapa de análise. Vamos resumir essas características:
• Correção: devemos verificar a coerência entre os vários documentos do processo;
• Precisão: as informações não devem apresentar ambiguidades, devem ser compreen-
didas por todos os envolvidos, assegurando que todos tenham uma única interpretação;
12
13
• C ompletude: considerar o conjunto de informações completo, quando não existir 
decisões de especificação pendentes;
• Consistência: quando os requisitos e seus subconjuntos não apresentam ne-
nhum conflito;
• Priorização: para as informações, que devem atender a uma classificação de im-
portância, identificadas como: obrigatória, opcional e flexível (indicando as chances 
de ser modificada);
• Verificabilidade: as informações devem evitar termos subjetivos como “resposta 
rápida” ou “alto índice de processamento”, podendo ser substituídos por métricas 
objetivas, como “tempo de resposta < 5 segundos”, 20 mil acessos simultâneos;
• Modificabilidade: é uma característica desejável, embora nem sempre possível, 
que possibilita alterar requisitos sem comprometer funções críticas;
• Rastreabilidade: permite que os antecedentes e consequências de um requisito, ou 
uma informação, possam ser determinados, auxiliando em possíveis correções e/ou 
avaliações causadas por alterações na especificação.
 FAZER A
 ANÁLISE 
 DE 
 DOMÍNIO
 Métodos de Análise
 de Domínio
Procedimentos
de Gerência
Modelos de
 Domínio
Taxonomias
Padrões
(P . E. , padrões de interface)
(P . E. , arquiteturas genéricas)
Modelos Funcionais
Linguagens de domínio
Analista de Domínio
Especialista 
do Domínio
Engenheiro 
de Domínio
Fonte de
Conhecimento 
do Domínio Literatura Técnica
Implementações 
Existentes
Entrevistas
Consultas as 
Especialistas
Requisitos 
atuais e futuros
Figura2
Fonte: Adaptada de PRIETO-DIAZ, 1991
Na Figura 2, temos um resumo visual da análise de domínio, com foco nas fontes das 
informações que mencionamos e com os resultados servindo de entrada para constru-
ção do projeto do domínio, onde os modelos serão criados.
Projeto de domínio
O modelo de domínio auxilia na escolha de arquitetura da aplicação e definição de 
quais componentes podem compor a solução, criando as bases sobre a qual um projeto 
será desenvolvido.
13
UNIDADE Engenharia de Software Baseada 
em Componentes (ESBC)
O Projeto de Domínio refina o modelo criado na etapa de análise. A ferramenta 
mais adotada para trabalhar tem sido a UML, com utilização dos diagramas estruturais; 
os especialistas de domínio entram em detalhes mais específicos, como, por exemplo, 
diagramas de classe, diagramas de objetos e diagramas de componentes.
A modelagem de domínio, documentada e validada, serve de entrada para a próxima 
etapa, a implantação.
Diagrama
 Diagrama de 
Comportamentos
 Diagrama de 
 Estruturas
 Diagrama de 
 Classes
 Diagrama de 
 Componente
 Diagrama de 
 Objetos
 Diagrama de 
 Implantação
 Diagrama de 
 Pacotes
 Diagrama de 
 Per�l
 Diagrama de 
Estruturas Compostas
 Diagrama de 
 Atividades
 Diagrama de 
 Casos de Uso
 Diagrama de 
 Interação
 Diagrama de 
 Sequências
 Diagrama de 
 Comunicação
 Diagrama de Visão
 geral de interação 
 Diagrama de 
 Interação
 Diagrama de 
Máquina de Estados
 
Figura 3 – Diagramas padronizados para UML
Fonte: Adaptada de OMG Unified Modeling LanguageTM, p. 694
A Figura 3 mostra os vários diagramas utilizados na documentação para modelagem 
de domínio. Os diagramas de comportamentos são utilizados nos modelos abstratos, 
onde o propósito é organizar e estruturar o material coletado na fase de análise. Os diagra-
mas estruturais ajudam na modelagem da aplicação, onde as estruturas de dados ficam 
mais evidentes, visando ao processo de seleção de componentes.
Implementação de domínio
O processo de implementação envolve o desenvolvimento dos componentes que foram 
identificados nos processos anteriores. Podemos classificar esses componentes que serão 
desenvolvidos em três grandes grupos, que estão presentes na maioria de dos domínios.
• Componentes de interface: ex.: botões, campos de texto, ícones, janelas e listas;
• Componentes de serviços: ex.: serviços comuns a diversos tipos de sistemas, 
acesso a banco de dados, acesso a serviços de mensagens, transações e integração 
de sistemas;
• Componentes específicos do domínio: ex.: são os componentes mais difíceis de 
desenvolver, requerem especialistas que analisem as informações levantadas para 
determinar a prioridade e grau de reusabilidade.
Observação: uma das áreas de desenvolvimento que mais tem crescido no mercado 
atual é o desenvolvimento orientado a serviços.
14
15
Análise de Domínio
Características 
 do Domínio
 Arquitetura 
 do Domínio
 Modelo de 
Componentes
 Respositório de
Componentes Reusáveis
 Projeto de Domínio Implementação
Figura 4
Fonte: Adaptada de GEROSA; STEINMACHER, 2019
A Figura 4 resume a Engenharia de Domínio. O processo de Análise de Domínio 
produz um conjunto de características do domínio analisado, que permite uma modela-
gem. Na sequência, o Projeto de Domínio permite refinar o modelo gerado no processo 
anterior e desenvolve a arquitetura e modelo dos componentes para serem desenvolvi-
dos na etapa final. O processo de Implementação desenvolve os componentes que serão 
disponibilizados no repositório.
Importante ! 
Embora não esteja nos diagramas apresentados, nem nas descrições do processo, expli-
citada, uma etapa obrigatória que faz parte do processo da Implementação é a execu-
ção de testes e validação (homologação) dos componentes. Na engenharia de software, 
entendemos que nenhuma implementação ou desenvolvimento pode ser concluída sem 
uma etapa interna de testes e homologação.
Engenharia de Aplicação
Na Engenharia de Aplicação, pode haver variações nos processos, que vamos apre-
sentar em função do que pretendemos construir com os componentes.
Podemos ter os seguintes casos:
• Construir um sistema pertencente a um domínio: nesse caso, vamos aplicar a En-
genharia de Aplicação, voltada a desenvolver sistemas para uma Linha de Produtos, 
onde o domínio foi estudado, mapeado e modelado (essa será a nossa abordagem) ;
• Construir um sistema pertencente a uma família de sistemas: implica desen-
volver sistema muito similar a alguns já existentes, é claro que alguns conceitos de 
domínio são aplicados, mas em vez de considerar o domínio, a análise é feita sobre 
um produto já existente, o que certamente vai reduzir o volume de informações. 
Podemos dizer que se trata de um subconjunto de um domínio ;
• Construir um sistema com um conjunto de componentes de um repositório:
não implica compromisso com análise de domínio, sem diretrizes de modelagem, 
apenas com propósito de acelerar um desenvolvimento; se for conduzido sem su-
pervisão adequada corre o risco de criar uma “colcha de retalhos”.
Aprendendo o caso genérico (voltado para o domínio), com os cuidados de observar 
os pontos-chaves, eventualmente, podemos aplicar nos casos mais específicos.
15
UNIDADE Engenharia de Software Baseada 
em Componentes (ESBC)
Pronto(a) para no nosso objetivo? Vamos entender melhor a estreita relação com a 
Engenharia de Domínio, o conceito de Linha de Produto de Software e aplicação 
prática do reuso de componentes.
Começamos com uma definição padrão usada pelo Instituto de Engenharia de Software, 
na Universidade Carnegie Mellon: “Engenharia de Aplicação é o processo de engenharia 
de linha de produto de software no qual os aplicativos da linha de produto são criados 
reutilizando artefatos de domínio e explorando a diversificação da linha de produto”.
Linha de Produtos de Software: é um conjunto de sistemas em software que compar-
tilham um conjunto comum e gerenciado de características, que satisfazem as neces-
sidades específicas de um segmento ou missão de mercado específico e que são de-
senvolvidas a partir de um conjunto comum de ativos principais de maneira prescrita.
Os processos da Engenharia de Aplicação são:
• Requisitos de aplicação: são utilizados os métodos tradicionais de Engenharia de 
Software. Mas não exatamente igual, pois como o modelo de característica e outras 
informações já foram coletadas na Análise de Domínio, é necessário destacar as 
possíveis variações relacionadas com a aplicação que está sendo trabalhada e os 
resultados da Análise de Domínio;
• Projeto da aplicação: são utilizados os métodos tradicionais de Engenharia de 
Software, considerando os resultados do processo anterior e detalhando informações 
de arquitetura, plataforma, interface etc., mas o diferencial está em analisar, principal-
mente, as variações entre o Projeto de Domínio e a aplicação sendo projetada;
• Implementação da aplicação: esse processo é, na verdade, o que executa o de-
senvolvimento baseado em componentes, por isso vamos tratá-lo de maneira deta-
lhada a seguir.
Implementação da aplicação
Vamos assumir que não houve falhas na Engenharia de Domínio, nem nos proces-
sos de Requisitos de Aplicação e Projeto de Aplicação. O êxito da implementação está 
totalmente vinculado ao bom trabalho realizado pelos especialistas e usuários que parti-
ciparam das etapas anteriores. Proximos passos:
Busca dos componentes
Seria ótimo se houvesse uma ferramenta do tipo Google ou Bing, que pudesse listar 
os componentes candidatos para reuso, a partir das informações do projeto, mas... não 
é bem assim. Algumas ferramentas para operação da seleção são disponibilizadas em 
alguns frameworks de projeto, mas independentemente da disponibilidade desse recur-
so, os repositórios precisam estar bem documentados e segmentados e de acordo com 
o domínioque ele foi criado.
Trocando Ideias...
Podemos usar uma analogia na Figura 5; nesse caso, qual seria o padrão escolhido para 
as cores das peças?
16
17
Figura 5
Fonte: GEROSA; STEINMACHER, 2019
Precisamos considerar se o componente atende aos requisitos e funcionalidades da apli-
cação. Além disso, verificar compatibilidade com recursos de hardware e sistema operaciona 
Integração dos componentes
Como um componente vai se conectar com outros componentes ou sistemas ou ser-
viços? Se as interfaces forem flexíveis ou do tipo “plug and play”, caso resolvido.
Contudo, essa questão pode não ter uma solução dentro do repositório; nesse caso, é 
necessário considerar um middleware, que funciona como uma ponte entre componen-
tes que não se conversam diretamente. As funções de um middleware podem ser muito 
variadas e, em último caso, pode ser que precisem ser desenvolvidas, por não estarem 
disponíveis para a função necessária.
As informações sobre as interfaces dos componentes, flexibilidade de formatação e re-
gras do protocolo de interação entre os componentes desempenham importância crítica 
para o sucesso da integração e quando feitas com completude e precisão, previnem os 
desenvolvedores permitindo antecipar um conjunto de soluções.
Mas, supondo que tudo deu certo, vem, então, a última etapa da implementação: os 
Testes da Aplicação.
Teste da aplicação
Mesmo que nossos componentes tenham sido exaustivamente testados em suas fun-
cionalidades, estejam livres de bugs e estejam conectados corretamente, a etapa de teste 
da aplicação pode trazer imprevistos, principalmente nos requisitos não funcionais. A 
validação pode indicar a necessidade de rever alguns dos componentes usados.
Antes de encerar esse processo, vamos examinar a Figura 6. Resumido os pontos 
principais da Engenharia de Aplicação, nos deparamos com um possível cenário alter-
nativo no processo de Implementação.
17
UNIDADE Engenharia de Software Baseada 
em Componentes (ESBC)
Quando os especialistas de domínio identificam um problema sem solução, uma 
funcionalidade específica sem componente, mas ao mesmo tempo uma oportunidade 
de negociar a revisão nos requisitos rígidos, de forma a compatibilizar com as funciona-
lidades dos componentes existentes, é hora de voltar alguns passos atrás.
A análise por especialistas pode envolver mudanças nos requisitos, produção de có-
digo personalizado ou até mesmo a construção de novos componentes, ou seja, de volta 
a Engenharia de Domínio e implementação de componentes.
Ninguém disse que a vida era fácil...
 Análise
 Integração e Teste
 Adaptação de
 Componentes
 Projeto da
 Aplicação 
Implementação
Aplicação
 Teste de
Componentes
 Desenvolvimento de novos 
Componentes (Engenharia de Domínio)
+
Seleção de componentes Características
 do Domínio
 Arquitetura
 do Domínio
 Repositório de
Componentes Reusáveis
Figura 6
Fonte: Adaptada de GEROSA; STEINMACHER, 2019
Custo x benefício na utilização de componentes
Quando estudamos o desenvolvimento de software baseado em componentes, sem-
pre encontramos na lista de benefícios a menção à redução de tempo e custo.
Em pesquisas realizadas pelo Instituto de Engenharia de Software da Universidade 
Carnegie Mellon, os indicadores nessa “dobradinha” são realmente atraentes.
• Produtividade 10 x;
• Qualidade de produto 10 x;
• Redução de custo até 60%;
• Redução de pessoal 87%;
• Capacidade de entrar em um novo mercado, de anos, caiu para meses.
São números impressionantes!
Mas... e os custos?
• A mesma pesquisa mostra, embora sem indicadores, que os custos de desenvolver 
com componentes são maiores que no processo tradicional; até que um número de 
sistemas tenha sido desenvolvido, a partir de determinado ponto, é mais lucrativo;
• Suporte na arquitetura dos componentes, para atender aos sistemas de um Domí-
nio, o custo de manutenção e atualização dos componentes precisa ser feito por 
equipe especializada, para evitar mudança de comportamento dos componentes;
18
19
• Componentes precisam ser desenvolvidos sem prejuízo de desempenho e suportar 
variações de requisitos funcionais ;
• Investimento na elaboração dos planos de teste e análise de resultados ;
• Investimento em treinamento de especialistas em desenvolvimento de componente.
O gráfico da Figura 7 não apresenta indicadores, pois demonstra tendências, basea-
do nas pesquisas feitas com diferentes domínios.
 Nas próximas unidades, vamos considerar outros aspectos que ainda não foram 
abordados, referentes a repositórios comerciais, repositórios públicos e componentes 
como serviç os.
Método tradicional
Baseado em 
 Componentes
Números de Produtos
Cu
sto
s a
cu
m
ul
ad
os
Figura 7
Fonte: Adaptada de WEISS; LAI, 1999
19
UNIDADE Engenharia de Software Baseada 
em Componentes (ESBC)
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Sistemas colaborativos
PIMENTEL, M.; FUKS, H. Sistemas colaborativos. Rio de Janeiro: Elsevier, 2011.
Software reuse: the Brazilian industry scenario.
https://bit.ly/3dJVEsI
 Vídeos
Tutorial de caso de uso UML
https://youtu.be/ab6eDdwS3rA
Tutorial de diagramas de classe UML
https://youtu.be/rDidOn6KN9k
 Leitura
Reúso de software
https://bit.ly/39Uo95I
20
21
Referências
ARANGO, G. Domain engineering for software reuse. PhD thesis, University of 
California at Irvine, 1988.
CLEMENTS, P.; NORTHROP, L. et al. A framework for software product line 
practice. V. 5.0, SEI 2012.
CZARNECKI, K.; EISENECKER, U. Generative programming: methods, tools, and 
applications. Addison-Wesley, 2000.
EDWARDS, N. P.; TELLIER, H. A look at characterizing the design of information 
systems. In: Proceedings of the ACM National Conference, ACM, 1974.
ELETRONIC SYSTEMS CENTER et al. Software Technology for Adaptable, 
Reliable Systems (Stars) Program. Disponível em: <https://apps.dtic.mil/sti/pdfs/
ADA284770.pdf>. Acesso em: 26/01/2021.
 GEROSA, M. A.; STEINMACHER, I. Livro da SBC – Capítulo 2: Componentes de 
software para sistemas colaborativos. Disponível em: <https://sistemascolaborativos.
uniriotec.br/wp-content/uploads/sites/18/2019/06/SC-cap22-componentes.pdf>. 
Acesso em: 26/01/2021.
NEIGHBORS, J. Software construction using components. University of California 
at Irvine, 1980.
WEISS, D. M. & LAI, C. T. R. Software Product-Line Engineering: a family-based 
software development process reading, MA: Addison-Wesley, 1999.
21