Engenharia+de+software+baseada+em+componentes+-+SQ+-+SR

Prévia do material em texto

Engenharia de software baseada em componentes 
Engenharia de Software Baseada em componentes é um ramo de Engenharia de Software, com ênfase na decomposição dos 
sistemas, em componentes funcionais e lógicos com interfaces bem definidas, usadas para comunicação entre os próprios 
componentes. Componentes são considerados como estando num nível de abstração mais alto que do que Objetos e, como tal, 
não compartilham estado e comunicam-se por troca de mensagens contendo dados. 
 
História 
Durante a Conferência de Engenharia de Software da OTAN realizada em 1968, Mcilory expõe a idéia de que o desenvolvimento 
de software deve empenhar-se em produzir componentes reusáveis com o intuito de proporcionar aos desenvolvedores a 
possibilidade de escolher quais componentes utilizar, conforme as suas necessidades. Nasce aí o interesse em desenvolver 
software através da integração de componentes de software. 
Em 1976, DeRemer propôs um paradigma de desenvolvimento onde o sistema seria construído como um conjunto de módulos 
independentes e depois interligados. Já na década de 80, com o surgimento da orientação a objetos e a possibilidade de 
reutilização, fortaleceu ainda mais a proposta de produzir componentes. 
O que é um componente? 
Brown e Wallnau descrevem um componente como "uma não-trivial, quase independente, e substituível parte de um sistema 
que cumpre uma função clara no contexto de uma arquitetura bem definida". Em muitos sentidos, esta descrição é similar a de 
um objeto em programação orientada a objetos (POO). Componentes possuem uma interface. Eles empregam regras de 
herança. 
Já para Szyperski, o componente não é necessariamente uma tecnologia implementada especificamente e nem a aplicação, mas 
sim um dispositivo de software que possua uma interface bem definida. 
Mas para Krutchen, o componente é um elemento independente, que pode ser substituído, contudo, ele é significativo, pois 
tem uma função clara no contexto em que foi definido. 
Mas a definição é levada ainda além. Componentes são definidos para oferecer um certo nível de serviço. No caso dos 
componentes "comerciais de prateleira" ( ou commercial off-the-shelf - COTS), o engenheiro de software sabe pouco ou nada 
sobre o funcionamento interno de um componente. Ao invés disso, ao engenheiro de software é dada apenas uma interface 
externa bem-definida a partir da qual ele deve trabalhar. O nível de serviço é portanto crucial e precisa ser acurado se quiser 
que a integração do componente ao sistema de software seja bem sucedida. Brown e Wallnau descrevem um componente de 
software como “uma unidade de composição contratualmente especificada e somente com dependências contextuais 
explícitas”. Ao contrário de objetos em POO, os componentes são usualmente construídos a partir de muitos “objetos” de 
software (embora a construção não seja confinada a POO) e fornecem uma unidade de funcionalidade coerente. Os assim 
chamados “objetos” trabalham em conjunto para realizar uma tarefa específica em um dado nível de serviço. Componentes 
podem ser caracterizados com base em seu uso no processo de ESBC: Como mencionado acima temos os COTS. São 
componentes que podem ser comprados, pré-fabricados, com a desvantagem de que, no geral, não há código fonte disponível, 
e sendo assim, a definição do uso do componente dada pelo fabricante(desenvolvedor), e os serviços que este oferece, precisam 
ser confiavelmente testadas, como podem ou não ser acuradas. A desvantagem, entretanto, é que estes tipos de componentes 
deveriam(em teoria) ser mais robustos e adaptáveis, pois foram usados e testados( e reusados e re-testados) e muitas 
diferentes aplicações. Adicionalmente aos COTS, a ESBC almeja: 
• Componentes qualificados 
• Componentes adaptados 
• Componentes aglutinados 
• Componentes atualizados 
Processo de ESBC 
A Engenharia de Software Baseada em Componentes (ESBC) é, em muitos sentidos, similar a engenharia de software 
convencional ou orientada a objetos. Uma equipe de desenvolvedores define requisitos para o sistema ser construído, usando 
técnicas de elicitação de requisitos convencionais. Um design da arquitetura é estabelecido. Neste ponto contudo, o processo 
difere. Ao invés de um detalhando design, a equipe examina os requisitos, para determinar qual subconjunto é diretamente 
moldável ao esquema de composição, em detrimento de um esquema de construção. Para cada requisito, a equipe se 
perguntará: 
• Há COTS disponíveis para implementar o requisito? 
• Componentes re-usáveis desenvolvidos internamente( a software-house) estão disponíveis para implementar o 
requisito? 
• As interfaces para os componentes disponíveis são compatíveis dentro da arquitetura do sistema a ser construído? 
A equipe tentará modificar ou remover os requisitos de sistema que não puderem ser implementados com componentes COTS. 
Isso nem sempre é possível ou prático, mas reduz o custo geral do sistema. Freqüentemente pode ser útil priorizar os requisitos, 
senão desenvolvedores podem se encontrar codificando componentes que já não sejam mais necessários, por já terem sido 
eliminados dos requisitos. 
O processo ESBC identifica não somente possíveis componentes, mas também qualifica a interface de cada componente, adapta 
o componente para remover incongruências arquitetônicas, monta os componentes dentro de um estilo de arquitetura 
selecionado, e atualiza componentes como requisitos para a mudança no sistema. Dois processos ocorrem em paralelo durante 
o processo de ESBC. São: 
1) Engenharia de Domínio 
Objetiva identificar, construir, catalogar e disseminar um conjunto de componentes de software que tenham 
aplicabilidade para software existentes e futuros, dentro de um domínio de aplicação específico. Um domínio de 
aplicação é como uma família de produtos - aplicações com funcionalidade(ou intenção de funcionalidade) similar. O 
objetivo é estabelecer um mecanismo em que engenheiros de software possam partilhar estes componentes usando-os 
em sistemas futuros. 
2) Desenvolvimento Baseado em Componentes 
O Desenvolvimento Baseado em Componentes (DBC) aborda a criação de sistemas de software que envolva a 
composição de componentes permitindo a adição, adaptação, remoção e substituição de partes do sistema sem a 
necessidade de sua completa substituição. Isso auxilia na manutenção dos sistemas uma vez que, permite a integração 
de novos componentes e/ou a atualização dos já existentes. A abordagem é criar ou adaptar os componentes para que 
sejam utilizados em diversos sistemas. Essa idéia vem ao encontro da reutilização que busca flexibilizar o 
desenvolvimento. 
O DBC 
O DBC possui duas perspectivas: 
1) Desenvolvimento de componentes consiste na criação de novos componentes, desde a especificação (análise, documentação) 
até a implementação. A documentação é o fator mais importante, pois é ela que possibilitará a reutilização desse componente 
em outros sistemas, caso haja a necessidade de alterações. 
2) Já o desenvolvimento com componentes consiste na criação de sistemas com um conjunto de componentes interligados. 
Levando em conta que esse componentes já existam é que estejam disponíveis para uma seleção e reutilização. 
Segundo Brown, há cinco estágios neste processo: Seleção, Qualificação, Adaptação, Composição e Atualização. 
A etapa da Seleção de Componente consiste em buscar e selecionar componentes que tem potencial para serem usados na 
construção do sistema. A busca por componente envolve tanto COTS quanto componentes que foram usados em outros 
sistemas desenvolvidos anteriormente. 
A etapa de Qualificação do Componente examina componentes reusáveis, para averiguar se, e em que proporção, se adequam 
aos requisitos do estilo arquitetural do sistema. Há três importantes aspectos considerados: performance, confiabilidade e 
usabilidade. 
A etapa de Adaptação do Componente modificará aspectos do componente. É um passo necessário pois, raramente um 
componente se adaptará de pronto ao sistema. Dependendo do tipo decomponente(e.g. COTS ou in-house[feito na própria 
empresa]) diferentes estratégias de adaptação (também conhecidas como wrapping (encapsulamento)) podem ser empregadas. 
A Composição integra os componentes no sistema, por meio de uma infra-estrutura feita para aglutinar os componentes em um 
sistema operacional. A infra-estrutura geralmente é, em si mesma, uma biblioteca especializada de componentes e serviços que 
habilita coordenação entre os componentes e realização de tarefas. 
Já a Atualização, sendo a última atividade, tem-se a atualização dos componentes, onde versões antigas serão substituídas ou 
novos componentes, com comportamento e interface similares, serão incluídos. 
Em suma, se componentes reusáveis existem para um dado caso, precisarão ser qualificados e adaptados. Se novos 
componentes são necessários, precisarão ser criados. Lembrando que a existência de componentes reusáveis não garante sua 
integração fácil ou mesmo efetiva. 
 
A Adaptação de um Componente 
Conforme pesquisas realizadas, segundo Booch, têm mostrado que raramente um componente é reutilizado como foi 
originalmente desenvolvido e que geralmente necessita de alguma forma de alteração para se adequar à arquitetura da 
aplicação ou aos demais componentes. 
As abordagens mais comuns são: 
• Encapsulamento caixa-branca(White box wrapping) – aqui, a implementação do componente é diretamente modificada 
para resolver incompatibilidades. Isso é, obviamente, possível apenas se o código-fonte do componente estiver 
disponível, algo extremamente improvável no caso de COTS. 
• Encapsulamento caixa-cinza(Grey box wrapping) – Neste caso, a adaptação é feita por uso de uma biblioteca do 
componente fornecendo uma linguagem de extensão do componente ou API que possibilite a remoção ou 
mascaramento de conflitos. 
• Encapsulamento caixa-preta(Black box wrapping) – Caso mais comum, onde não é possível o acesso ao código-fonte, e 
a única maneira de adaptar o componente é por pré/pós processamento a nível de interface. 
É responsabilidade do engenheiro de software determinar se os esforços para encapsular um componente adequadamente são 
justificados, se seria menos custoso criar um componente que solucione os conflitos. Também, uma vez que um componente foi 
adaptado é necessário verificar a compatibilidade para integração e realizar-se testes para tentar antecipar quais 
comportamentos inesperados que surjam devido as modificações realizadas. 
Encapsulamento/Empacotamento 
O encapsulamento/empacotamento consiste em produzir uma visão externa para um componente, isto é, uma interface, 
diferente de sua interface original com vista a adaptá-lo a requisitos específicos. 
Principais finalidades: 
• Incompatibilidade de interfaces (componentes que podem interagir, porém as interfaces não são compatíveis). 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); 
• Alterar a funcionalidade original do componente. Isso é, incluir novas funcionalidades, como também alterar o 
tratamento original a determinadas invocações de métodos. 
Colagem de Componentes 
A colagem de componentes (glueing) trata o mesmo problema do empacotamento, isto é, viabilizar a operação conjunta de 
componentes originalmente incompatíveis. A diferença neste caso é que o tratamento dado ao problema é a inclusão de um 
novo elemento, a cola (glue), entre os componentes incompatíveis, possibilitando sua operação conjunta. 
O elemento cola nada mais é que um terceiro componente, cuja interface possibilita sua conexão aos componentes 
Componente um e Componente dois e cuja funcionalidade consiste em compatibilizar a operação conjunta destes 
componentes. Seja a situação de colagem representada e considere-se que o Componente um seja implementado em Smalltalk 
e Componente dois, em Java. Com isto, o componente cola deve solucionar a heterogeneidade entre os outros dois 
componentes (que também pode envolver localização física e plataforma de execução), bem como eventuais incompatibilidades 
sintáticas e funcionais. Suponha-se que a questão da heterogeneidade seja resolvida com o uso de CORBA. Neste caso o 
componente cola mascararia o tratamento da heterogeneidade. A figura ilustra uma visão mais refinada do componente cola, 
considerando esta situação. 
A cola é uma prática totalmente transparente para o usuário, uma vez que ele não sabe que três tecnologias diferentes foram 
utilizadas. 
Tecnologia de componentes 
Atualmente, os principais modelos de componentes disponíveis são: 
• CMM (CORBA Component Model) do OMG (Object Management Group); 
• DCOM (Distributed Component Obejct) e COM/COM+ (Component Object Model) da Microsoft; e 
• JavaBeans e Entreprise JavaBeans (EJB) da Sun.