unidade1

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
Introdução à Engenharia de Software Baseada em Componentes
Introdução à Engenharia de Software 
Baseada em Componentes
 
 
• Compreender o paradigma da utilização de componentes no desenvolvimento de software;
• Compreender conceitos de componentes de software;
• Compreender as vantagens da engenharia de software baseada em componentes.
OBJETIVOS DE APRENDIZADO 
• Paradigma do Desenvolvimento Baseado em Componentes;
• Crise do Software;
• Engenharia de Software;
• Desenvolvimento Baseado em Componentes.
UNIDADE Introdução à Engenharia de Software 
Baseada em Componentes
Paradigma do Desenvolvimento 
Baseado em Componentes
Antes de começarmos, paradigma?
Parece grego, não é mesmo? Como muitas palavras no português, herdadas de ou-
tros idiomas, paradigma vem do grego. É um termo muito usado na filosofia, mas com 
aplicações em vários outros contextos, inclusive na computação. Significa um modelo, 
ou um padrão, de como executar tarefas ou se comportar em determinadas situações.
No nosso caso, a Engenharia de Software nasce como resposta ao que foi chamado 
de “crise do software”. O desenvolvimento de software baseado em componentes apa-
rece como uma nova proposta dentro da engenharia de software, um novo paradigma, 
que buscava resolver problemas que assombravam desenvolvedores, clientes e usuários. 
Dentro da engenharia de software, muitas ideias foram propostas, como, por exemplo, 
modelos estruturados, modelos interativos, reuso de código, projetos orientados a objetos, 
orientados a serviços e vários outros. Propriedades como: coesão, encapsulamento, acopla-
mento, análise de domínio, composição de componentes, etc...
Neste curso, vamos entender como esses conceitos estão interligados; então, come-
çando do começo...
Crise do Software
O termo Crise do Software começa a ser debatido em conferências e publicações 
técnicas no fim da década de 1960. O termo Crise passa a ser oficializado alguns anos 
depois, 1971, por Dijkstra, durante seu discurso intitulado The Humble Programmer, ao 
receber o prêmio Turing Award. Vamos ver um conjunto de características, que várias 
publicações destacaram, para justificar a expressão que disparou o alarme da crise.
• Imprecisão das estimativas de custo e prazo: Frequentemente, os cronogramas 
estavam atrasados e os custos eram muito mais altos que as estimativas iniciais;
• Insatisfação do cliente com sistemas concluídos: Recursos “imaginados” pelos 
clientes não estavam disponíveis. As expectativas que os clientes tinham, os requisi-
tos formalizados e o produto entregue causavam frustrações e reclamações;
• Dificuldade de manutenção: Falta de documentação. Quando havia necessidade 
de modificar e, em alguns casos, corrigir um sistema, era mais “prático e rápido” 
fazer um novo;
• Qualidade do software questionada: Sistemas ineficientes, falta de definições e 
padrões de qualidade. Não existia um conjunto de métricas e procedimentos que 
pudesse garantir e verificar a qualidade dos produtos desenvolvidos.
Nesse quadro preocupante e com um avanço significativo na construção de hardware 
mais rápidos e com custos menores, o desenvolvimento de software se torna uma “dor 
de cabeça” para quem o desenvolve e para quem o utiliza. Mas, segundo alguns filósofos, 
é nas crises que surgem as oportunidades. O desenvolvimento de sistemas precisava de 
novos paradigmas...
8
9
Nesse contexto e durante as conferências que reuniam desenvolvedores e pesqui-
sadores da área, surge a ideia de tratar a criação de software como um processo de 
engenharia, que já era consagrado e validado nas áreas de construção civil, mecânica e 
nas grandes indústrias. Era o nascimento da Engenharia de Software.
Na seção de Material Complementar, assista a um vídeo de 12 minutos que trata da Crise do 
Software e do nascimento da Engenharia de Software.
Engenharia de Software
Baseado nas experiências bem-sucedidas em outras áreas da engenharia, ao longo 
das décadas de 70, 80 e 90, tivemos o surgimento de conceitos, práticas e ferramentas 
que seriam incorporados aos projetos de desenvolvimento de software.
A engenharia de software passa a ter livros, periódicos e conferências dedicadas a 
esses temas. Surgem também a formalização de metodologias de desenvolvimento, con-
ceitos do que é qualidade de software e uma variedade de métricas que quantificassem 
os indicadores desses padrões estabelecidos.
Entre as metodologias que surgiram, vamos destacar:
• Cascata: Com fases sequenciais e distintas desde a especificação, na elaboração 
do projeto e desenvolvimento. Sommervile destaca que “seu maior problema é a 
divisão inflexível do projeto em estágios distintos. Os compromissos devem ser 
assumidos no estágio inicial do processo, o que torna difícil reagir às mudanças 
de requisitos”;
• Prototipação: Utilizado quando não há requisitos detalhados pelos usuários; uma 
grande vantagem é permitir uma construção rápida para avaliação, formalizando 
requisitos que não eram claros. Sobre esse método, Sommervile adverte que o 
processo de gerenciamento e objetivos estabelecidos podem levar à incompreensão 
dos gestores e usuários da função do protótipo;
• Espiral: Modelo de desenvolvimento baseado em ciclos repetitivos que elaboram 
objetivos, avaliam alternativas e riscos, implementam, validam e planejam as próxi-
mas fases do ciclo. A dificuldade dessa metodologia é a exigência de que gerentes e 
técnicos tenham muita experiência na detecção de riscos e no controle paralelo de 
partes do projeto em etapas distintas, dificultando um cronograma sincronizado e 
indicadores de custo adequados;
• Métodos formais: São técnicas baseadas em um formalismo matemático para espe-
cificar, desenvolver e verificar sistemas. Possui alta complexidade de utilização, princi-
palmente em sistemas com um conjunto grande de casos especiais; e apesar de várias 
linguagens e ferramentas criadas para essa metodologia, ainda hoje não possui uma 
notação padrão para descrição formal de sistemas;
• Métodos Ágeis: No início da década de 1990, mesmo com os avanços em metodo-
logia na engenharia de software, os métodos de desenvolvimento eram considerados 
9
UNIDADE Introdução à Engenharia de Software 
Baseada em Componentes
burocráticos, lentos e, pior, continuavam a produzir sistemas com os mesmos tipos 
de problemas que motivaram a busca por novos paradigmas. Esses métodos eram 
classificados como “pesados”, de baixa produtividade e frequentemente de alto custo. 
Algumas novas técnicas de desenvolvimento foram propostas e ficaram conhecidas 
como métodos “leves”. A partir de 2001, com a publicação do Manifesto Ágil e a 
criação da Aliança Ágil, os “métodos leves” passaram a ser conhecidos como parte 
da metodologia Ágil. Os métodos apresentam características próprias, mas mantêm o 
conceito defendido no Manifesto Ágil, de forma simplificada; os pontos principais são:
 » Entrega rápida, cliente satisfeito;
 » Entregas parciais, sempre em curto prazo;
 » Cooperação diária com cliente e equipe;
 » Receber eventuais mudanças de funcionalidade e escopo, como etapa possível 
de acontecer;
 » Buscar soluções de alta qualidade e o mais simples possível.
A engenharia de software baseada em componentes (component-based software 
engineering, CBSE) busca a decomposição dos sistemas em componentes funcionais e 
lógicos com interfaces bem definidas. Na prática, a tecnologia de software baseado em 
componentes baseia-se no desenvolvimento através de componentes reutilizáveis, levando 
à redução de tempo de desenvolvimento e facilitando as mudanças e a implantação de 
novas funcionalidades. Vamos conhecer melhor essa metodologia.
Desenvolvimento Baseado 
em Componentes
Em uma conferência, no final dos anos 60, mediante o quadro de insatisfação de usuários 
e desenvolvedores, McIlroy lançou a ideia de que o desenvolvimentode software pudesse 
seguir modelos de sucesso, aplicados em muitas indústrias, construindo diferentes compo-
nentes, otimizados e testados, e a partir desses componentes, construir sistemas complexos.
De componentes:
Figura 1
Fonte: Getty Images
10
11
Até sistemas complexos:
Figura 2 
Fonte: Freepik
Alguns dos benefícios esperados seriam:
• Evitar que partes dos códigos fontes fossem reescritas inúmeras vezes, a cada novo 
sistema, uma vez que faziam as mesmas funções;
• Ter certeza de que os componentes utilizados foram testados;
• Economizar tempo de desenvolvimento e testes;
• Reduzir custos inesperados durante os projetos;
• Obter produtos com qualidade.
Esses benefícios fazem parte do conceito de Reuso de software. A característica de 
reuso é fundamental para o paradigma de desenvolvimento baseado em componentes.
O desenvolvimento de componentes de software tem sido objeto de pesquisa no 
campo da engenharia de software por várias décadas, mas não obteve êxito até a década 
de 90. Havia, claramente, ausência de ferramentas e de metodologia que implementasse 
esses conceitos na prática.
Uma das primeiras novidades na engenharia de software foi a formalização da meto-
dologia de desenvolvimento em Cascata e, percorrendo a linha do tempo, ainda tivemos 
as metodologias Interativa/Incremental, Prototipação e Espiral.
As linguagens de programação utilizadas eram conhecidas como linguagens estrutu-
radas. Embora houvesse algumas linguagens de programação orientadas a objetos (que 
estavam restritas aos centros de pesquisa e aos ambientes acadêmicos), como, por exem-
plo, Simula, que depois foi aprimorada pela linguagem Smalltalk, essas linguagens com 
orientação a objetos utilizavam os conceitos de encapsulamento, herança e polimorfismo. 
As metodologias para criação e desenvolvimento das classes e objetos incluíam também 
as propriedades de coesão e acoplamento. Essas propriedades também são importantes 
para o desenvolvimento de componentes, pois estão relacionadas à capacidade de reuso 
dos componentes de software.
11
UNIDADE Introdução à Engenharia de Software 
Baseada em Componentes
Você se lembra dos conceitos de programação orientada a objetos?
Na seção de Material Complementar, você pode revisar os principais conceitos em dois vídeos; 
faça uma pausa e assista.
No início da década de 90, com a linguagem C++, seguida de perto pela linguagem 
Java, a programação orientada a objetos ganha projeção não só nos meios acadêmicos, 
mas também nos grandes centros de desenvolvimento de software. A partir da dissemi-
nação dessas poderosas ferramentas de programação orientada a objetos, foi desenvol-
vido o paradigma de projetos de desenvolvimento de software orientado a objetos, onde 
os conceitos eram aplicados não só na fase de desenvolvimento, mas também nas fases 
de análise de requisitos, modelagem lógica e nas etapas de testes.
Décadas depois da proposta de McIlroy, surgia a esperança de que o desenvolvimento 
de software, finalmente, passaria a ter a propriedade de reuso. Contudo, Sommerville 
observou que “apesar das previsões iniciais otimistas, nenhum mercado significativo 
para objetos individuais se desenvolveu”. Vejamos alguns dos motivos:
• Classes de objetos muito especificas: Codificação atendia, na grande maioria das 
vezes, somente aos detalhes do projeto para o qual foi codificado;
• Dependência de tecnologia dos objetos: Na maioria dos casos, os objetos tinham 
que ser ligados às aplicações no momento de compilação;
• Necessidade de conhecer código fonte: Para integrar os novos componentes, era 
necessário conhecer o código do objeto para ter sucesso na composição.
No fim da década de 90, motivado pela frustração de baixa capacidade de reuso que 
o desenvolvimento orientado a objetos proporcionou, surgiu a proposta de paradigma 
de desenvolvimento baseado em componentes.
Componentes
Podemos afirmar, sem entrar em conflito com os vários pesquisadores do assunto, 
que apresentam definições distintas, que um componente é um módulo de software, 
criado de acordo com um padrão bem definido e documentado, que pode ser implan-
tado de forma independente, isto é, não depende de outros componentes presentes na 
biblioteca (também chamada de repositório).
O uso de componentes na construção de sistemas induz o reaproveitamento de 
software, incorpora benefícios da tecnologia de orientação a objetos, possibilita compor 
módulos com componentes básicos e componentes complexos. O reflexo desse para-
digma na produtividade, reduzindo prazos e custos no desenvolvimento de sistemas, é 
um marco importante na engenharia de software.
Sommerville define, formalmente, que um componente precisa ser:
• Padronizado: a padronização de componentes significa que um com-
ponente usado em um processo precisa estar de acordo com algum 
modelo padronizado de componente. Esse modelo pode definir inter-
faces de componentes, metadados de componentes, documentação, 
composição e implantação;
12
13
• Independente: um componente deve ser independente – deve ser pos-
sível compô-lo sem precisar usar outros componentes específicos. Em 
situações em que o componente necessita de interface ‘requires ’;
• Passível de composição: para um componente poder ser composto, 
todas as interações externas devem ocorrer por meio de interfaces publi-
camente definidas. Além disso, deve fornecer acesso externo às informa-
ções sobre si próprio, como seus métodos e atributos ;
• Implantável: para ser implantável, um componente precisa ser auto-
contido e deve ser capaz de operar como uma entidade independente 
sobre uma plataforma de componente que implementa o modelo de 
componente. Isso geralmente significa que o componente é binário e 
não precisa ser compilado antes de ser implantado ;
• Documentado: componentes precisam ser completamente documen-
tados de maneira que os usuários possam decidir se eles atendem 
ou não às suas necessidades. A sintaxe e, idealmente, a semântica 
de todas as interfaces de componentes precisam ser especificadas. 
(SOMMERVILLE, 2009, p. 317)
Na definição dada por Sommerville, vamos entender alguns pontos ainda não abordados.
As formas de comunicação de um componente com o restante de um sistema são 
feitas pelas interfaces. T emos dois tipos de interfaces: Oferecidas (Provides) e Solici-
tadas (Requires.)
• Provides: são os pontos de saída de um componente ;
• Requires: são os pontos de entrada de um componente.
A s interfaces dos componentes funcionam na prática como se fossem um contrato 
do que o componente se propõe a fazer, pois são as únicas partes visíveis e contêm 
informações de quais entradas são esperadas e quais saídas serão oferecidas. Os com-
ponentes, em geral, atuam como caixas pretas, com relação aos algoritmos e estru-
tura utilizada.
Componente autocontido significa que um componente precisa ter propriedades já 
conhecidas por nós na programação orientada a objetos:
• Coesão: A coesão é uma medida de quanto uma classe executa uma função do 
início ao fim; por exemplo, uma classe possui coesão forte se fica bem claro o 
que deve fazer e não tem necessidade de outras classes. Uma classe com coesão 
fraca executa partes de uma função que precisa ser concluída por outras, ou uma 
que realiza muitas funções distintas, em vez de um conjunto pequeno de ações 
de mesma natureza. Por exemplo, uma coesão fraca de uma classe que registra 
pagamento no sistema contábil, realiza baixa de estoque no sistema de produção e 
atualiza crédito no sistema financeiro é um convite a desastre se precisar ser modi-
ficada, pois teria reflexos em vários outros componentes do sistema. Para aumentar 
a coesão, deveria haver classes específicas para cada uma das funções ;
• Acoplamento: O acoplamento pode ocorrer com dados, classes e interfaces. Na 
interface, o acoplamento forte exige que os dois componentes tenham conheci-
mento da definição dos dados, exigindo uma personalização específica, dificultando 
manutenção ou modificação dos componentes. Umaforma de tornar flexíveis as 
13
UNIDADE Introdução à Engenharia de Software 
Baseada em Componentes
interfaces entre componentes e sistemas é utilizar formato pro XML ou Jason, 
evitando modificar as interfaces dos componentes. No caso de acoplamento de 
classes, ele é forte quando uma classe depende de outra. Por exemplo, quando 
ocorre herança, tornamos a manutenção mais complexa. Os componentes para 
serem independentes, um dos requisitos já mencionados, precisam de conexões 
flexíveis, o que indica acoplamento fraco.
Sendo assim, quando buscamos as propriedades de reusabilidade, os componentes, sendo 
autocontidos, possuem coesão forte e acoplamento fraco. Além de poder se conectar a um 
sistema, ou a outros componentes, os componentes podem ser substituídos com mais 
facilidade, facilitar manutenção, simplificar documentação e clareza de cada componente.
Você pode notar as semelhanças entre objetos e componentes e, mais ainda, entre 
Desenvolvimento Orientado a Objetos e Desenvolvimento Baseado em Componentes?
Teremos a oportunidade de ver esses detalhes no nosso curso, mas veja esta lista:
• A construção de componentes pode ser feita em qualquer linguagem;
• A construção de objeto utiliza linguagens orientadas a objetos;
• Usamos um componente como se fosse uma caixa preta;
• Usamos os objetos conhecendo as classes e métodos;
• Um componente não é instanciado;
• Um objeto é instanciado;
• As funções de um componente são construídas visando à flexibilidade;
• As funções de um objeto são construídas com detalhes específicos;
• Em geral, a documentação de componentes faz uso intenso de UML;
• Em geral, a documentação dos objetos faz uso intenso de UML;
• Utilização de componentes se beneficia, usando e aplicando vários conceitos, da orientação 
a objetos, para reutilização de software;
• Utilização de orientação a objetos não produziu a esperada reusabilidade.
Você ainda está confuso(a) com as diferenças?
Componentes têm forte influência da tecnologia de Orientação a Objetos, mas são diferentes.
Benefícios e desafios
A reutilização de software não é o único benefício atrativo que justifica o interesse 
no desenvolvimento de software baseado em componentes. Outros fatores impor-
tantes incluem:
• Para sobreviver no mercado competitivo de software, as empresas de software pre-
cisam oferecer qualidade mais alta e softwares mais confiáveis em menos tempo e 
dentro de um período limitado de despesas;
• O mercado de software demanda, cada vez mais, em larga escala e complexidade 
os novos projetos de software. Tecnologias e metodologias tradicionais de desen-
volvimento de software se mostram inadequadas para gerenciar projetos que nor-
malmente envolvem várias empresas de software;
14
15
• Os usuários esperam que o software seja fácil de manter, a fim de diminuir a manu-
tenção e despesas operacionais ;
• Os usuários exigem que softwares de diferentes fornecedores trabalhem juntos. 
Tal integração exige estrita adesão aos padrões, criando dificuldades extras para 
desenvolvedores de software. A integração pode ser equacionada com desenvol-
vimento baseado em componentes.
Como consequência, o desenvolvimento de software baseado em componentes oferece 
as seguintes vantagens sobre o desenvolvimento de software tradicional:
• O desenvolvimento de software baseado em componentes pode aumentar a pro-
dutividade dos softwares desenvolvedores. O software baseado em componentes 
é construído através da montagem de componentes reutilizáveis. Esse processo é 
muito mais rápido do que escrever um novo código do “zero” ;
• O desenvolvimento de software baseado em componentes oferece maior qualidade 
e mais confiabilidade. A principal razão é que os componentes reutilizáveis foram 
testados e, portanto, sua qualidade pode ser garantida ;
• A tecnologia de componentes pode facilitar a manutenção do software. Software
baseado em componentes significa que um aplicativo de software grande pode 
ser feito de muitos componentes pequenos. A tarefa de manter um aplicativo de 
software grande pode ser dividida em partes menores, facilitando a manutenção ;
• A tecnologia de componentes facilita o gerenciamento do desenvolvimento de 
software, permitindo o desenvolvimento paralelo e possibilitando que várias orga-
nizações sejam envolvidas no desenvolvimento de sistemas com alta complexidade.
Podemos construir um conjunto básico de componentes para serviços, infraestrutura, 
modelos de negócios – por exemplo: loja virtual, geradores de relatórios, blogs, websites
e jogos. Utilizando componentes padronizados economizamos, consideravelmente, tem-
po e dinheiro.
Desafios para utilizar componentes? Temos sim, vejamos:
• N ão temos um único padrão para componentes, os padrões podem ser estabeleci-
dos de várias formas; entre os candidatos temos, por exemplo: CORBA, JavaBeans
e COM;
• Existem barreiras culturais por parte dos desenvolvedores em adotar componentes 
de software que eles não construíram e testaram;
• M uitas vezes um componente é superdimensionado para a função que precisa rea-
lizar dentro do sistema;
• Nem todos os tipos de sistemas são adequados para a construção com componentes. 
Alguns sistemas precisam ter funcionalidades extremamente específicas, não sendo 
viável construir componentes de software que seriam utilizados somente uma única 
vez – por exemplo: sistema de segurança de instalações militares e monitoramento 
de tempo real;
• Clientes que adotam componentes largamente empregados no mercado por outras 
empresas tendem a mostrar pouco diferencial.
15
UNIDADE Introdução à Engenharia de Software 
Baseada em Componentes
A busca por produtos de qualidade de software, aderência aos padrões, redução de 
custos de desenvolvimento, independência de tecnologia e facilidade de manutenção 
enfrenta desafios que requerem atenção permanente dos desenvolvedores.
• Todos os requisitos funcionais testados e documentados;
• Comportamento dos requisitos não funcionais, como desempenho, disponibilidade, 
segurança, usabilidade;
• Facilidade de seleção e configuração;
• Certificação dos componentes.
No caso de um sistema composto por diferentes componentes, certamente devemos 
considerar a aplicação prática de um dito popular inglês do sec. XVIII, que traduzido na 
nossa língua ficou conhecido como: “uma corrente é tão forte quanto o seu elo mais 
fraco”. Quando utilizamos componentes de origens diferentes para compor um sistema 
complexo, precisamos determinar a confiabilidade do sistema como um todo, anali-
sando não somente os componentes individualmente, mas todo o conjunto conectado, 
considerando os desafios apresentados.
Nas próximas unidades, vamos descrever com detalhes a metodologia para desenvolver 
software baseado em componentes, os tipos de projetos e as técnicas para composição de 
componentes em sistemas complexos.
Afinal, a crise passou?
Respondendo diretamente, com base no conteúdo dos artigos publicados e em resultados de 
mercado divulgados, podemos concluir que muitos avanços foram feitos na engenharia de 
software baseada em componentes, mas os fantasmas de 50 anos atrás continuam rondando 
desenvolvedores e usuários nas últimas 5 décadas. Analise você mesmo(a) nas tabelas a seguir.
Na Tabela 1, veja uma amostra de sistemas de software que fracassaram.
Tabela 1 – Sistemas de software que fracassaram
Início Cancelado Nome Tipo País Problemas principais
Custo 
(Orçado)
1980 1993 Taurus Mercado de ações Grã-Bretanha
• Escopo;
• Custo.
75M – £
1982 1994 FAA Controle aéreo EUA
• Custo;
• Atraso.
3-6B – US$
1984 1990 Risp Serviços Grã-Bretanha
• Escopo;
• Custo.
63M – £
(29M)
1997 2000 Bolit ERP, CRM Suécia
• Custo;
• Rejeitado pelos 
usuários.
300M – 
SEK (35M)
1999 2006 CSIO Financeiro Canadá
• Rejeitado 
pelos usuários;
• Atraso;
• Custo.
15M – Can$
2002 2011 NHS Sistema de saúde nacional Grã-Bretanha
• Atraso;
• Custo.
12B – £
(2.3B)
2005 2012 ECSS Força aérea EUA
• Atraso;
• Custo.
1.1B – Us$ 
2012 2014 Cover Sistema de saúdeestadual EUA
• Atraso;
• Custo.
200M – Us$
Fonte: Adaptada de Wikimedia Commons
16
17
Na Tabela 2, veja alguns casos de sistemas que, por problemas de implantação, especifica-
ção ou testes insuficientes, causaram prejuízo e morte.
Tabela 2 – Sistemas que causaram prejuízo e morte
Sistema Soft Ano Falha principal Consequências
Hartfor Coliseum 1978 Especificação requisitos Teto desabou. Prejuízo de US$ 70 M
Sistema de 
defesa soviético
1983 Bug de software
Emitiu falso alerta de ataque de 
mísseis americanos, quase defla-
grando uma guerra.
Therac-25 1985 Erro de configuração Equipamento de radioterapia cau-sando 3 pacientes mortos.
Míssil Patriot 
americano
1991 Erro de operação aritmética 28 soldados americanos mortos.
Foguete Ariane V 1996 Cálculos com variáveis de 64 bits e 16 bits
4 satélites perdidos. Prejuízo de 
US$ 500 M.
EDS child support 2004 Implantação de novo sistema precipitado 1B - £
Fonte: Adaptada de DevTopics
Em Síntese
Na engenharia de software, não há uma posição final de qual paradigma é o melhor. Na 
verdade, eles não são mutuamente exclusivos, e não é rara a combinação de caracterís-
ticas de mais de um método nos desenvolvimentos atuais, dependendo das característi-
cas do projeto, da equipe e das ferramentas disponíveis. Podemos ter desenvolvimento 
em Cascata, ou Espiral, com uso de componentes; podemos também usar Scrum com 
componentes; e podemos concluir também que a utilização de componentes pode ser 
inadequada para alguns sistemas.
Uma visão de uma prática ideal da Engenharia de Software Baseada em Componentes 
(ESBC) é essencial para entendermos a tecnologia dos componentes de software e as manei-
ras pelas quais essa tecnologia contribui para boa prática de engenharia de software. ESBC 
enfatiza a montagem rápida de componentes e estruturas certificadas em sistemas cujas 
propriedades podem ser previstas antecipadamente, possibilitando:
• Reduzir o tempo de entrega final, usando um repositório de componentes;
• Liberar os usuários dos custos de manutenção, essa tarefa fica com os proprietários 
do repositório;
• Apresentar taxa baixa de bugs por utilizar componentes submetidos a um proto-
colo de testes;
• Diminuir custos na implantação, consequências dos itens acima.
17
UNIDADE Introdução à Engenharia de Software 
Baseada em Componentes
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Component software, beyond object-oriented programming
Szyperki, C. Component software, beyond object-oriented programming. 
ACM Press, 1998.
 Vídeos
Introducao a Engenharia de Software e Crise Software
https://youtu.be/VlReKuKvqho
Programação Orientada a Objetos (POO) // Dicionário do Programador
https://youtu.be/QY0Kdg83orY
 Leitura
Breve Estudo Sobre Engenharia de Componentes
https://bit.ly/3wEbQ7m
18
19
Referências
IVAR, J. Object-oriented software engineering: a use case driven approach. 4 
ed. ACM Press, 1997.
SOMMERVILLE, I. R. Engenharia de software. 9ª ed. São Paulo: Pearson Addison 
Wesley, 2010 . (e-book)
19