Engenharia De Componentes

FACULDADE ANHANGUERA DE PIRACICABA

Bacharelado em Ciência da Computação

Engenharia de Software

Engenharia de Componentes

05 de Junho de 2013

Índice

Introdução 03

Objetivo 04

História 05

O que é um componente? 06

Processo de ESBC 07

O DBC 08

Adaptação de um componente 09

Encapsulamento/Empacotamento 10

Colagem de Componentes 12

Tecnologia de componentes 13

Conclusão 15

Bibliografia 16

Introdução

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 e compartilham estados comunicam-se por troca de mensagens contendo dados.

Objetivo

O objetivo é estabelecer um mecanismo em que engenheiros de software possam partilhar estes componentes os usando em sistemas futuros.

O Reuso é o objetivo principal da engenharia de software baseada em componentes. Não se trata somente de reutilização de código, pois abrange também os artefatos envolvidos durante todas as etapas de desenvolvimento.

História

Surgiu-se a ideia de utilizar componentes na engenharia de software em uma conferência na OTAN em 1968, por Douglas Mcilory. O intuito era reutilizar os componentes, integrando-os no software. Após essa primeira etapa, em 1976, DeRemer propôs um paradigma de desenvolvimento, onde o sistema é desenvolvido como um conjunto de componentes produzidos separadamente e depois interligados. A ideia foi fortalecida na década de 80, com o surgimento da orientação à objetos.

Segundo Sommerville: "O componente é uma entidade executável independente. O código-fonte não está disponível, de modo que o componente não é compilado com outros componentes do sistema. Os componentes publicam suas interfaces e todas as interações são feitas por meio destas. A interface de um componente é expressa em termos de operações parametrizadas e seu estado interno nunca é exposto".

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 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.

ESBC

O processo de ESBC (Engenharia de Software Baseada em Componentes) é muito parecido com o processo de engenharia de software convencional ou orientada à objetos. Há levantamento de requisitos, análise, e design da arquitetura, porém, a partir desse ponto, ao contrário do método convencional, passa-se a fazer essas perguntas:

• Há COTS¹ disponíveis para implementar o requisito?

• Componentes reusáveis desenvolvidos