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 ^[1] expõe a ideia 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 ^[2] 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.

Definição e características de um componente

Brown e Wallnau^[3] 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,^[4] 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,^[5] 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 ^[6]
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. Frequentemente 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 ideia 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,^[7] 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 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.

A Composição integra os componentes no sistema, por meio de uma infraestrutura feita para aglutinar os componentes em um sistema operacional. A infraestrutura 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 Bosch,^[8] 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.
JavaBeans e Entreprise JavaBeans (EJB) da Sun.

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.

Ligações externas

https://web.archive.org/web/20070217074759/http://www.smb.uklinux.net/reusability/
Praxis (engenharia de software) - Processo de desenvolvimento de software com enfoque educacional

Ver também

Referências

↑ Mcilroy, M. D. (1968). Mass-produced Software Components. [S.l.]: In North Atlantic Treaty Organization Conference on Software Engineering, Garmisch-Partenkirchen
↑ DeRemer, F. (1976). Programming-in-the-large versus programming-in-the-small. [S.l.]: IEEE Transactions on Software Engineering ;
↑ Brown, A.W.; K.C Wallnau (1996). Component-Based Software Engineering. [S.l.]: IEEE Computer Society Press ; Pags. 7-15
↑ Szyperski, C. (1997). Sumary of the Second International Workshop on Component Oriented Programming. [S.l.]: 2º WCOP Finland
↑ Krutchen, P. (1998). Modeling Component with the Unified Modeling Language. [S.l.]: International Workshop on Component-Based Software Engineering line feed character character in |publicado= at position 14 (ajuda)
↑ Pressman, Roger S. Engenharia de Software. [S.l.]: McGraw-Hill. ISBN 8586804576 ; Pag 471
↑ Brown, A.W.; Keith Short (1997). On Components and Objects: The Foundation of Component-Based Development. International Symposiumn Assessment of Software Tools and Technologies (sast 97): IEEE Computer Society Press ; Pags. 112-121
↑ Bosch, Jan. (1999). Information and Software Technology. [S.l.: s.n.] ; Pags. 257-273

[1] Mcilroy, M. D. (1968). Mass-produced Software Components. [S.l.]: In North Atlantic Treaty Organization Conference on Software Engineering, Garmisch-Partenkirchen

[2] DeRemer, F. (1976). Programming-in-the-large versus programming-in-the-small. [S.l.]: IEEE Transactions on Software Engineering ;

[3] Brown, A.W.; K.C Wallnau (1996). Component-Based Software Engineering. [S.l.]: IEEE Computer Society Press ; Pags. 7-15

[4] Szyperski, C. (1997). Sumary of the Second International Workshop on Component Oriented Programming. [S.l.]: 2º WCOP Finland

[5] Krutchen, P. (1998). Modeling Component with the Unified Modeling Language. [S.l.]: International Workshop on Component-Based Software Engineering line feed character character in |publicado= at position 14 (ajuda)

[6] Pressman, Roger S. Engenharia de Software. [S.l.]: McGraw-Hill. ISBN 8586804576 ; Pag 471

[7] Brown, A.W.; Keith Short (1997). On Components and Objects: The Foundation of Component-Based Development. International Symposiumn Assessment of Software Tools and Technologies (sast 97): IEEE Computer Society Press ; Pags. 112-121

[8] Bosch, Jan. (1999). Information and Software Technology. [S.l.: s.n.] ; Pags. 257-273

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]