Engenharia de Software II - Aula 3

Prévia do material em texto

3ºAula
Engenharia de software 
baseada em componentes
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de:
• conhecer os projetos de software e o reuso de componentes;
• entender como realizar o desenvolvimento de componentes.
Olá, pessoal, tudo bem?
Chegamos à terceira aula. Agora, discutiremos a 
engenharia de software baseada em componentes (CBSE, 
do inglês component-based software engineering). Sabemos que, 
na maioria dos projetos de software, há reuso de algum 
software. Isso ocorre porque, ao trabalhar com diversos 
software, começa-se a conhecer os diferentes projetos e os 
códigos que sejam similares. Assim, procuram-se esses 
produtos, que são modificados e incorporados ao novo 
sistema. Esse processo economiza tempo e dinheiro na 
elaboração do projeto.
Pessoal, nesta aula, vislumbraremos assuntos 
relacionados à questão.
Vamos lá?
Bons estudos!
20Engenharia de software II
1 – Projetos de software e reuso de componentes
2 – O que é um componente?
3 – Desenvolvimento de componentes
Seções de estudo
1 - Projetos de software e reuso de 
componentes
As discussões relacionadas ao aproveitamento de 
software passam a ser fortalecidas na década de 1990, 
devido ao surgimento da engenharia de software baseada 
em componentes. Seu surgimento ganhou fôlego devido 
à frustração dos projetistas quando ao desenvolvimento 
orientado a objetos não ser feito por meio de amplo reuso, 
como feito anteriormente. Nesse momento, passa-se a focar 
nos objetos individuais, em cada classe, para que se fizesse 
o aproveitamento. Certamente, devido a isso, era necessário 
possuir o código-fonte do componente, o que dificultou a 
ideia de que objetos eram componentes reusáveis. Assim, 
não houve mercado significativo para a elaboração de objetos 
individuais. Para começarmos a discussão, vejamos a definição 
de componentes, por Yan Sommerville (2011):
Os componentes são abstrações de nível 
mais alto do que objetos e são defi nidos 
por suas interfaces. Geralmente, eles são 
maiores que objetos individuais e todos os 
detalhes de implementação são escondidos 
de outros componentes. CBSE é o processo 
de defi nir, implementar, integrar ou compor 
componentes independentes, pouco 
acoplados em sistemas. Essa se tornou uma 
importante abordagem de desenvolvimento 
de software porque os sistemas de software 
estão fi cando maiores e mais complexos. 
Os clientes exigem softwares mais confi áveis, 
entregues e implantados mais rapidamente 
(SOMMERVILLE, 2011, p. 315).
Passa-se a perceber, assim, que as possibilidades de 
entregar um software de modo rápido e com qualidade ao 
cliente quando se trabalha com o aproveitamento de software. 
Além disso, é preciso ocorrer a primeira interação do 
projeto arquitetural para que o projeto aconteça no nível de 
componentes. Aí, a estrutura global dos dados e programas 
do software foi estabelecida. O objetivo é traduzir o modelo de 
projeto no software operacional (PRESSMAN, 2006).
Sabe-se, então, que a engenharia de software baseada em 
componentes busca desenvolver componentes reusáveis, 
portanto, padronizados, e que tenha base em um modelo 
de componentes com foco nos sistemas de aplicação. 
Como é uma área em expansão, é possível, hoje, encontrar, 
principalmente em empresas que trabalham com sistemas 
corporativos e comerciais, entidades reusáveis desde pequenas 
funções até sistemas inteiros de aplicação.
Como cada software dentro do projeto não será, 
necessariamente, “novo”, evitam-se uma série de erros, pois a 
engenharia de software baseada em reuso também trabalha com 
a previsão de erros em produtos que sejam reutilizáveis. 
Vejamos, agora, os pontos essenciais da engenharia de 
software baseada em componentes:
Componentes independentes completamente 
especifi cados por suas interfaces. Deve haver 
uma clara separação entre a interface do 
componente e sua implementação de maneira 
que a implementação de um componente possa 
ser substituída por outra sem mudança no 
sistema;
Padrões de componentes que facilitam a 
integração de componentes. Esses padrões são 
incorporados em um modelo de componente 
e defi nem, no mínimo, como as interfaces de 
componentes devem ser especifi cadas e como 
os componentes devem se comunicar. Alguns 
modelos defi nem interfaces que devem ser 
implementadas por todos os componentes 
em conformidade com os padrões. Se os 
componentes estiverem em conformidade com 
os padrões, a operação será independente de 
sua linguagem de programação. Componentes 
escritos em linguagens diferentes podem ser 
integrados em um mesmo sistema;
Middleware1 que fornece apoio de software para 
integração de componentes. Para fazer com 
que componentes independentes e distribuídos 
trabalhem juntos, é necessário o apoio de um 
middleware que manipule as comunicações 
entre componentes;
Processo de desenvolvimento voltado 
à engenharia de software baseada em 
componentes. Ao tentar adicionar uma 
abordagem baseada em componentes em 
um processo de desenvolvimento voltado à 
produção de software original, você descobrirá 
que suposições inerentes no processo limitam 
o potencial do CBSE (SOMMERVILLE, 2011, 
p. 316).
Nessa perspectiva, o desenvolvimento baseado em 
componentes torna-se uma alternativa bastante válida, tendo 
em vista que a CBSE de base “apoia-se em um dos princípios 
de projeto na construção de softwares compreensíveis e passíveis 
de manutenção” (SOMMERVILLE, 2011, p. 317). Para o 
autor, em relação à área, pode-se afirmar que: 
1. Componentes são independentes, então eles 
não interferem na operação uns dos outros. 
Detalhes de implementação são ocultados. 
Implementação dos componentes pode ser 
alterada sem afetar o restante do sistema.
2. Os componentes comunicam-se por 
meio de interfaces bem defi nidas. Se essas 
interfaces forem mantidas, um componente 
poderá ser substituído por outro, que forneça 
funcionalidade adicional ou aumentada.
3. As infraestruturas dos componentes oferecem 
uma gama de serviços-padrão que podem 
ser usados em sistemas de aplicações, o que 
reduz a quantidade de códigos novos a serem 
desenvolvidos (SOMMERVILLE, 2011, p. 317).
21
2 - O que é um componente?
Devido ao fato de se tratar de reuso de produtos, é 
fundamental ter alguns cuidados para certificar a qualidade 
do produto a ser adquirido. Entre tais questões, é importante 
observar:
Confiabilidade de componentes: os componentes 
são unidades “caixa-preta” de programa, e o código-fonte do 
componente pode não estar disponível aos usuários. Assim, 
como um usuário saberá que um componente é confiável? O 
componente pode ter modos de falha não documentada que 
comprometem o sistema em que é usado. Seu comportamento 
não funcional pode não ser o esperado e, mais seriamente, o 
componente caixa-preta pode ser um cavalo de Troia e ocultar 
um código maléfico que abre uma brecha na proteção do 
sistema;
Certificação de componentes: relacionada à 
confiabilidade está a questão da certificação. É necessário que 
avaliadores independentes certifiquem que os componentes 
assegurem se são confiáveis. Contudo, não está claro como isso 
pode funcionar. Quem pagaria pela certificação, quem seria 
responsável se o componente não operar como certificado 
e como poderia o certificador limitar sua responsabilidade? 
A solução é se certificar de que os componentes estejam em 
conformidade com uma especificação formal. Contudo, a 
indústria não parece interessada em pagar por isso;
Previsão de propriedade emergente: todos os 
sistemas têm propriedades emergentes e a tentativa de prever 
e controlar essas propriedades é necessária no processo de 
desenvolvimento do sistema. Quando os componentes são 
interligados, o sistema resultante tem propriedades indesejáveis 
que limitam seu uso;
Compromissos de requisitos: geralmente, é necessárioter compromissos entre requisitos ideais e componentes 
disponíveis no processo de especificação e projeto do sistema. 
É necessário um método de análise estruturado e sistemático 
de compromissos para ajudar os projetistas a selecionar e 
configurar componentes.
O CBSE tem, em sua atuação, a função de construir 
sistemas de e-commerce, tendo em vista que os componentes 
reusados, ou são desenvolvidos internamente, ou são 
comprados. No segundo caso, ainda há resistência na compra, 
tendo em vista a relutância em confirmar em componentes 
binários que sejam adquiridos externamente.
Nesta seção, refletiremos acerca do conceito de 
componente. Vamos debruçarmo-nos, portanto, sobre esse 
conceito, tão importante para nossa aula.
O componente pode ser entendido como um bloco 
construtivo modular para software de computador. Pode 
ser definido também como parte modular possível de ser 
implantada e substituível de um sistema que encapsula 
implementação e exibe conjunto de interfaces.
Sommerville (2007) define componente como:
[...] uma unidade de software cuja funcionalidade 
e dependências são completamente defi nidas 
por um conjunto de interfaces públicas. Os 
componentes podem ser combinados com 
outros componentes sem referência à sua 
implementação e podem ser implantados como 
uma unidade executável (SOMMERVILLE, 
2007, p. 331).
Convencionalmente, na engenharia de software, o 
componente é um elemento do programa que incorpora 
lógica de processamento, estruturas de dados internas que 
são necessárias para implementar a lógica de processamento 
e uma interface que possibilita ao componente ser chamado 
e dados serem passados para ele. Como o componente 
interage com o mundo exterior, as especificações devem ser 
claras no que tange ao que o componente requer e fornece. 
Na tecnologia de software baseada em componentes, importa 
também conhecer o framework. Vejam a citação:
Uma outra peça chave na tecnologia de software 
baseada em componentes é o framework de 
componente. Segundo C. Szyperski [Szy98], 
no mundo orientado a objetos, um framework 
é um conjunto de classes, algumas delas 
abstratas, que cooperam entre si para constituir 
um projeto reutilizável para uma classe de 
software específi ca. Freqüentemente, um 
framework fornece algumas implementações 
default e os clientes do framework precisam 
apenas substituir ou complementar aquelas 
implementações que não estão adequadas ao 
seu problema específi co. Ainda na visão de 
C. Szyperski, um framework de componente 
é um software que suporta o acoplamento 
de componentes que se adequam a certos 
padrões. Este framework estabelece as 
condições ambientais de funcionamento para 
as instâncias dos componentes e regula as 
interações entre essas instâncias. O framework 
de componente pode, portanto, ser visto 
como uma espécie de sistema operacional de 
propósito específi co, que gerencia os recursos 
compartilhados pelos componentes e fornece 
os mecanismos básicos de comunicação entre 
eles. Um framework de componente é específi co 
para determinados tipos de componentes. Isso 
faz com que o framework seja uma peça um 
tanto quanto infl exível, já que os componentes 
que podem ser acoplados a ele devem seguir 
determinados padrões, porém aumenta 
as chances de sucesso na composição dos 
componentes (FARIAS, 2003, p. 23).
Então, no mundo orientado a objetos, um framework é um 
conjunto de classes, algumas delas abstratas, que cooperam 
entre si para constituir um projeto reutilizável para uma classe 
de software específica. 
O framework possibilita o fornecimento de 
implementações default. Os clientes precisam somente 
substituir ou, então, complementar possíveis implementações 
que não estejam adequadas ao problema. 
O componente atua como provedor de serviços de 
modo independente. Assim, caso o sistema necessite de 
algum serviço, o componente atuará de modo a responde 
à solicitação do sistema, independentemente de onde esteja 
sendo executado ou qual seja a linguagem de programação. 
22Engenharia de software II
Assim, um componente em um sistema de biblioteca, por 
exemplo, pode fornecer um serviço de busca que permita 
ao usuário buscar catálogos distintos. Já o componente que 
faça a conversão de um formato gráfico a outro, fornece um 
serviço de conversão de dados.
Como um componente pode ser visto como um 
provedor de serviços, há duas características importantes de 
um componente reusável:
• O componente é uma entidade executável e 
independente, portanto, o código-fonte não está 
disponível. Então, o componente não tem que 
ser compilado antes de ser usado com outros 
componentes do sistema;
• Os serviços possibilitados pelo componente estão 
disponíveis por meio de interface, e as interações 
ocorrerão sempre por meio da interface. Assim, seu 
estado interno nunca é exposto, e as operações são, 
sempre, parametrizadas.
3 - Desenvolvimento de componentes
Em nossa terceira e última seção, veremos conteúdos 
relacionados ao desenvolvimento de componentes.
Bom, como percebemos, houve um grande aumento no 
interesse pela engenharia de software baseada em componentes. 
Contudo, nos setores industriais, esse alcance é mais lendo, 
tendo em vista os processos e metodologias sistemáticos para 
qualquer ação relacionada aos sistemas.
De modo geral, pode-se dizer que o componente deve 
atuar como uma “caixa preta” em relação aos consumidores. 
Deve obedecer a convenções pré-estabelecidas em um 
modelo de componentes para poder interagir com outros 
componentes de forma transparente. Um componente deve 
ser desenvolvido de forma completamente independente, pois 
um mesmo componente pode ser reutilizado em diferentes 
contextos:
Como toda implementação de software, um 
componente é desenvolvido para exercer 
um determinado papel dentro do sistema 
onde ele será inserido. Dentro do sistema, o 
componente não permanece isolado e deve, 
portanto, fornecer meios para que as outras 
partes do sistema possam se comunicar com 
ele. Isso é feito através de interfaces. As 
interfaces implementadas por um componente 
descrevem as propriedades que o componente 
oferece para seus clientes. Entretanto, para 
que a interação entre componentes e clientes 
se dê de forma harmoniosa, é necessário 
especifi car também o que os clientes 
precisam fazer para usar o componente. 
A especifi cação das obrigações recíprocas 
entre as partes envolvidas na interação é 
feita através de contratos. Os contratos 
portanto, na engenharia de software baseada 
em componentes, declaram o que o cliente 
precisa fazer para usar uma interface e o que 
os fornecedores devem implementar para 
atender os serviços prometidos na interface 
(FARIAS, 2003, p. 12-13).
Nessa perspectiva, para desenvolver os componentes, os 
seguintes critérios devem ser observados:
• O objetivo é promover quebra de blocos monolíticos 
em componentes interoperáveis;
• A proposta é reutilizar os componentes em diferentes 
aplicações;
• O componente provê um conjunto de serviços que 
sejam acessíveis por meio de interface bem definida.
Os componentes são produzidos, geralmente, seguindo 
uma abordagem orientada a objetos. Contudo, há diversas 
diferenças importantes:
• Componentes são entidades implantáveis: não 
são compilados em um programa, mas instalados 
diretamente em uma plataforma de execução. 
Métodos e atributos podem ser acessados por outros 
componentes.
• Componentes não definem tipos: um componente é 
uma instância e não um template usado para definir 
uma instância, assim, uma definição de classe irá 
definir um tipo abstrato de dados.
• Implementações de componentes são opacas: 
componentes são definidos pela especificação de 
interface. Assim, a implementação não está acessível 
aos usuários do componente. Estes, por sua vez, são 
entregues como unidades binárias,e o comprador 
não acessa a implementação.
• Componentes são independentes da linguagem: 
devem-se seguir as regras de uma linguagem de 
programação orientada a objetos. As classes de objeto, 
portanto, operarão somente naquela linguagem, 
como, por exemplo, o Java.
• Componentes são padronizados: diferentemente das 
classes de objetos, que podem ser implementadas, 
os componentes devem estar de acordo com um 
modelo, que irá restringir sua implementação.
Finalizando a explicação acerca do assunto, leiam o excerto 
abaixo para conhecerem mais um pouco sobre a engenharia de 
software baseada em componentes.
A engenharia de software baseada em componentes é uma abordagem 
baseada no reuso para defi nição, implementação e composição de 
componentes independentes, fracamente acoplados em sistemas.
• Um componente é uma unidade de software cuja funcionalidade e 
dependências são completamente defi nidas por um conjunto de 
interfaces públicas. Os componentes podem ser compostos com 
outros componentes sem o conhecimento de sua implementação 
e podem ser implantados como uma unidade executável.
• Os componentes podem ser implementados como unidades de 
programa que são incluídas em um sistema ou como serviços 
externos que são referenciados a partir de dentro de um sistema.
• Um modelo de componente defi ne um conjunto de padrões 
para componentes, incluindo normas de interface, normas de 
uso e normas de implantação. A implementação do modelo de 
componente fornece um conjunto de serviços comuns que 
podem ser usados por todos os componentes.
• Durante o processo CBSE, você precisa intercalar os processos de 
23
Retomando a aula
É hora de relembrarmos os pontos estudados nesta aula. 
Vamos lá!
engenharia de requisitos e projeto de sistemas.
• Você precisa negociar os requisitos desejáveis pelos serviços que 
estão disponíveis a partir dos componentes reusáveis existentes.
• A composição do componente é o processo de ‘conexão’ 
dos componentes para a criação de um sistema. Os tipos de 
composições incluem a composição sequencial, a composição 
hierárquica e a composição aditiva.
• Ao compor componentes reusáveis que não foram escritos para 
sua aplicação, você talvez precise escrever adaptadores ou ‘glue 
code’ para reconciliar as diferentes interfaces de componentes.
• Ao escolher as composições, você deve considerar a funcionalidade 
requerida para o sistema, os requisitos não funcionais e a facilidade 
com que um componente pode ser substituído quando o sistema 
é alterado. (SOMMERVILLE, 2007, p. 337).
Pessoal, chegamos ao final da terceira aula. Espero que 
tenha sido produtiva a nossa discussão!
De qualquer modo, partilhem as impressões no quadro 
de avisos.
1 – Projetos de software e reuso de componentes
Vimos que a engenharia de software baseada em 
componentes busca desenvolver componentes reusáveis, 
portanto, padronizados, e que tenha base em um modelo de 
componentes com foco nos sistemas de aplicação. Como é uma 
área em expansão, é possível, hoje, encontrar, principalmente 
em empresas que trabalham com sistemas corporativos e 
comerciais, entidades reusáveis desde pequenas funções até 
sistemas inteiros de aplicação.
2 – O que é um componente?
Nesta seção, refletimos acerca do conceito de componente. 
Vamos debruçarmo-nos, portanto, sobre esse conceito, tão 
importante para nossa aula.
O componente pode ser entendido como um bloco 
construtivo modular para software de computador. Pode 
ser definido também como parte modular possível de ser 
implantada e substituível de um sistema que encapsula 
implementação e exibe conjunto de interfaces.
3 – Desenvolvimento de componentes
Na seção III, percebemos que o componente deve atuar 
como uma “caixa preta” em relação aos consumidores. Deve 
obedecer a convenções pré-estabelecidas em um modelo de 
componentes para poder interagir com outros componentes 
de forma transparente. Um componente deve ser desenvolvido 
de forma completamente independente, pois um mesmo 
componente pode ser reutilizado em diferentes contextos.
FARIAS, Carina Machado de. Um método de teste funcional 
para verificação de componentes. Dissertação de Mestrado, 
Universidade Federal de Campina Grande, Centro de 
Ciências e Tecnologia, Coordenação de Pós-Graduação em 
Informática, Campina Grande, PB, Fevereiro de 2003.
Vale a pena
Vale a pena ler
Minhas anotações