Suporte ao Desenvolvimento e Uso de Componentes

Suporte ao Desenvolvimento e Uso de Componentes Flexíveis
Ricardo Pereira e Silva Eng., M.Sc.
Universidade Federal de Santa Catarina – Depto. de Infomática e Estátistica
Roberto Tom Price Eng., M.Sc., S.Phil.
Universidade Federal do Rio Grande do Sul – Instituto de Informática
Resumo
O artigo apresenta a descrições de como a abordagem de desenvolvimento orientado
a componentes constata-se como um poderoso veículo de reuso. São tratados os aspectos de
descrição de adaptação de componentes. É demonstrada a abordagem de descrição de
componentes no ambiente SEA, que suporta o desenvolvimento e o uso de artefatos de
software reusáveis.
As idéias deste artigo são de fundamental importância, tendo caráter demonstrativo
deste assunto de maior relevância para o bom desenvolvimento de software reusável,
assunto este que não teve condições de ser abordado durante as aulas da disciplina de
Engenharia de Software, e que agora nos será apresentado.
Suporte ao Desenvolvimento e Uso de Componentes Flexíveis
1. Introdução
O objetivo de construir aplicações a partir da composição de artefatos de software já
vem sendo difundido desde o fim da década de 60, durante a “crise do software”. Na
década passada, chegou-se a pensar que a orientação a objetos era o mecanismo adequado
para promover o reuso. Mas verificou-se, posteriormente, que o reuso não é característica
inerente da abordagem OO. A abordagem de desenvolvimento orientado a componentes
determina que uma aplicação seja constituída a partir de um conjunto de módulos
interligados.
Segundo Kozacynski, um dos principais estímulos a abordagem de desenvolvimento
baseado em componentes é a disponibilidade de mecanismos de interconexão de
componentes. Um destes mecanismos é CORBA, que permite interconectar componentes
independente da linguagem, plataforma de execução e localização física dos componentes.
Além de CORBA, tem-se SOM, COM e JavaBeans, como padrões “de fato” de
interconexão de componentes. Estes mecanismos de interconexão, mesmo solucionando a
questão da heterogeneidade entre elementos que necessitam interagir, apresentam queda de
desempenho, exigindo que este aspecto seja avaliado para a sua adoção. Outros problemas
relacionados a componentes são os de busca e seleção de componentes para reuso.
Geralmente, componentes necessitam ser adaptados antes de serem utilizados.
2. Abordagens de descrição da interface de componentes
A forma mais comum de descrever um componente é a descrição de sua interface.
Porém, os mecanismos de descrição de interface, geralmente, produzem apenas uma visão
externa, incapaz de descrever suas funcionalidades e como estes interagem. Em geral, a
interação de um componente com o meio externo pode ser bidirecional, isto é, o
componente pode receber invocações de métodos mas também pode originar invocações.
Murer estabelece três níveis de informação de interoperabilidade de componentes:

Nível de interface: uso de linguagem para descrever como estruturalmente os
componentes podem ser agrupados.

Nível originador: que tipos e versões de componentes podem trabalhar
juntos.

Nível semântico: descrição completa da funcionalidade do componente.
As propostas mais recentes ressaltam a necessidade da descrição de uma
interface não ser feita exclusivamente através da relação de assinaturas de métodos
fornecidos e requeridos, mas também da definição da dinâmica da interação. Reuse contract
é uma descrição de interface para um conjunto de componentes participantes que
colaboram entre si.
Várias das propostas de descrição de interface de componentes carecem de
formalismo, o que é necessário para descrever precisamente a interação entre componentes,
tais como formalismos algébricos, que tem sido usados para descrever protocolos de
comunicação e sistemas distribuídos. De acordo com Canal, o uso da álgebra é adequado a
abordagem de componentes, pois permite a avaliação de propriedades, como equivalência,
inexistência de deadlock e outras.
3. A necessidade de descrever a funcionalidade de componentes
Dois componentes a serem interconectados são estruturalmente compatíveis se o
conjunto de métodos invocados através da interface de um está disponível na da interface
do outro. A conexão destes componentes, todavia pode produzir resultados não previstos.
Além de compreender a estrutura e o comportamento da interface de um
componente, é necessário compreender-se exatamente o que o componente faz, como
opera, antes de qualificá-lo como adequado para o reuso.
4. Abordagens de adaptação de componentes
Raramente os componentes são reutilizados da mesma maneira como foram
desenvolvidos, geralmente eles necessitam ser adaptados para se moldarem aos requisitos
do sistema a que serão acoplados. Têm-se utilizado duas abordagens de adaptação de
componentes: alteração ou empacotamento. O empacotamento cria uma visão externa
diferente para o componente, ao invés de modificá-lo. Outra alternativa é interconectar
componentes antes incompatíveis através de um componente intermediário denominado
cola.
O relacionamento de cola é isolado dos componentes e definido separadamente. A
definição deste componente intermediário consiste na criação de objetos ponto de vista, que
são observadores de componentes existentes, sendo que:

mais de um ponto de vista pode ser associado a um componente.

o estado de um ponto de vista é alterado, quando ocorre a alteração do
estado do componente observado.

um ponto de vista atua como interface entre o componente e o meio com que
ele interage, permitindo alteração e adaptação da interface original, bem
como a extensão de funcionalidades.

pontos de vista podem ser criados, destruídos, acoplados ou desacoplados
dinamicamente.
A alteração de um componente pode se tornar uma tarefa menos árdua se o
componente for desenvolvido para ser alterado, como os arcabouços de componente, um
componente que prevê o acoplamento de outros componentes e que é modificado a partir da
troca dos componentes a ele acoplados.
5. Abordagem proposta de descrição de componentes
A abordagem de descrição de componentes apresentada neste artigo é utilizada no
ambiente SEA, onde o paradigma OO foi adotado para desenvolver frameworks,
componentes e aplicações. Desta forma, os componentes são definidos como estruturas de
classes, que reutilizam uma interface, selecionada de uma biblioteca de interfaces de
componentes. Esta interface possui uma especificação individual que descreve sua estrutura
e sua dinâmica comportamental. Esta especificação de interfaces em separado permite que
a interface seja reusada em vários componentes, produzindo uma família de componentes
compatíveis comportamental e estruturalmente.
5.1. Especificação estrutural de interface de componente
Um componente possui uma interface única, que pode prever a conexão a mais de
um componente, onde cada conexão utiliza um canal. A especificação estrutural de uma
interface de componente relaciona os métodos fornecidos e os requeridos, e a associação
destes a cada canal da interface. No ambiente SEA, a estrutura de uma interface é
produzida através do relacionamento de assinaturas de métodos e canais, e da definição do
relacionamento entre estes. O ambiente embute na classe que implementa a interface esta
estrutura, mais precisamente nos seus atributos.
5.2. Especificação comportamental de interface de componente
O que deve-se saber neste item é se existem ou não restrições associadas a ordem
em que são invocados os métodos, em caso positivo, devem fazer parte da modelagem da
interface. Para que fosse majorada a compreensibilidade e com a necessidade de
formalismo, adotou-se o uso de redes de Petri para a modelagem do comportamento da
interface de componentes, pois apresenta o formalismo algébrico e notação gráfica. O
comportamento de um conjunto de componentes interligados é obtido a partir da união das
redes de Petri que descrevem suas interfaces. Outras vantagens da adoção de redes de Petri:
permite analisar propriedades de interfaces individuais e arquiteturas de componentes
(possibilidade de avaliar a existência de deadlock ou de transições que nunca são
disparadas).
6. Aplicação da abordagem de frameworks para a produção de componentes
flexíveis
Caso um componente seja projetado prevendo futuras modificações, e havendo
suporte para modificá-lo, existe a possibilidade de diminuir-se a complexidade da alteração
da estrutura de componentes, viabilizando-se a criação de componentes flexíveis.
Um framework OO é uma estrutura de classes que estão inter-relacionadas,
constituindo uma implementação inacabada, para um domínio de aplicações. A principal
vantagem dos frameworks é a reutilização de projeto, além do reuso do código, sendo
necessário conhecer apenas parte das classes envolvidas. Como desvantagem tem-se a
complexidade de desenvolvimento e de utilização.
Um framework desenvolvido para produzir componentes corresponde a uma
estrutura de classes que apresenta partes mantidas flexíveis, para que se adapte a diferentes
requisitos. A vantagem desta abordagem é que pode-se obter componentes distintos a partir
de um esforço menor que o necessário para desenvolver cada um de maneira isolada.
7. Suporte ao desenvolvimento e uso de componentes flexíveis no ambiente
SEA
Este ambiente possui funcionalidades que facilitam o desenvolvimento de
componentes flexíveis e a produção de novos a partir de sua alteração.
7.1. SEA, um ambiente para o desenvolvimento e uso de artefatos reutilizáveis
de software
SEA é um ambiente que suporta o desenvolvimento e o uso de artefatos reutilizáveis
de software, considerando os seguintes requisitos:
Suporte a edição gráfica de modelos – facilitam a compreensão de especificações
de software.
Suporte a edição semântica – a geração de código exige que um ambiente assegure
consistência semântica das especificações. Esta garantia, vem da adoção dos seguintes
meios:
o Define-se um metamodelo par cada tipo de especificação, que estabelece os
elementos da especificação e as relações semânticas entre eles.
o Cada editor do ambiente sujeita-se as restrições do metamodelo associado.
SEA dispõe de algumas funcionalidades de suporte a edição semântica, como:
o Ações de refatoração.
o Propagação de efeitos das ações de edição.
Suporte ao reuso de artefatos de software – suporte ao reuso de frameworks, de
componentes, de interfaces de componentes, estruturas de projeto pré-elaboradas e
mantidas em biblioteca, etc.
Flexibilidade – possibilita a evolução de um ambiente. Inclusão de novas
características e funcionalidades com menor esforço e sem efeitos colaterais inesperados.
7.2. A estrutura de uma especificação de componente
SEA utiliza as seguintes técnicas de modelagem propostas em UML:

Diagrama de casos de uso.

Diagrama de atividades.

Diagrama de classes.

Diagrama de seqüência.

Diagrama de estados.

Diagrama de corpo de método (este não previsto em UML).
Extensões de SEA em relação a UML:

Representação de conceitos do domínio de frameworks.

Suprimento de lacunas semânticas, como nos estados e na ordem dos casos
de uso.

Possibilidade de descrição do corpo dos métodos na especificação de
projeto.

Expressão da ligação semântica entre elementos de uma especificação.

Possibilidade das especificações serem tratadas como hiperdocumentos.
7.3. O desenvolvimento e uso de componentes flexíveis no ambiente SEA
O ambiente SEA dispõe de um conjunto de editores que possibilitam especificar
componentes como estruturas de classes. Dá suporte a adaptação de frameworks, e ao
desenvolvimento de hiperdocumentos de orientação ao uso de frameworks. Suporta a
especificação de interfaces de componentes e de arquiteturas de componentes, e permite a
verificação de consistência de especificações de projeto e geração semi-automática de
código.
8. Conclusão
Este artigo apresentou a abordagem adotada no ambiente SEA para o
desenvolvimento e uso de componentes. Foi apresentado o uso da abordagem de
frameworks para o desenvolvimento de componentes. Neste ambiente, componentes e
arquiteturas de componentes são produzidos como especificações de projeto que são
submetidas a verificação de consistência e traduzidas para linguagem de programação. O
suporte disponível atualmente traz soluções para alguns dos problemas identificados na
abordagem de desenvolvimento orientado a componentes.