---

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.

O que é um componente?

Brown e Wallnau [1] 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 . 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 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 contractualmente especificada
e somente com dependências contextais 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 re-usados e re-testados) e
muitas diferentes aplicações. Adicionalmente aos COTS, a ESBC almeja:

Componentes qualificados [2]

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 eliciaçã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 implementer o requisito?

Componentes re-usáveis devesenvolvidos internamente( a software-house) estão disponíveis para implementar o requisito?

As interfaces para os components 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 indentifica 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 processo 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 Há três estágios neste
processo: Qualificação, Adaptação e Composição (todos no contexto de
Componentes):

A etapa de Qualificação do Componente examina componentes
re-usá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
adptará de pronto ao sistema. Dependendo do tipo de componente(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. 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 mascaramente 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 determiner 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 checar a
compatibilidade para integração e realizar-se testes para tentar
antecipar quais comportamentos inesperados que surjam devido as
modificações realizadas.

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.

Em suma, se componentes re-usá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 re-usáveis não garante sua integração fácil ou mesmo
efetiva.

Sumário

A ESBC introduz grandes mudanças nas práticas de design e
desenvolvimento, o que introduz também custos extras. Engenheiros de
Software precisam empregar novos processos e formas de pensamento -
isto também introduz custo em treinamento e educação. Contudo, estudos
iniciais sobre o impacto da ESBC na qualidade do produto, qualidade do
desenvolvimento e custo, demonstram um ganho geral, e tudo indica que a
continuação destas práticas melhorarão o desenvolvimento de software no
futuro. Ainda não está claro como a ESBC amadurecerá, mas está claro
seu potencial de auxílio no atual desenvolvimento de sistemas de larga
escala, e também no futuro desenvolvimento de sistemas, além de ser
considerada a plataforma perfeita para orientar os requisitos de
negócio modernos.

DISALLOWED (DmRelatedItem)