AUMENTANDO A PRODUTIVIDADE NA ENGENHARIA DE SOFTWARE
BASEADA EM COMPONENTES
Marcelo Nogueira
Resumo: O reuso, no contexto da engenharia de software,
nem é uma idéia velha, nem nova. Os desenvolvedores têm
usado idéias, abstrações e processos desde os primeiros dias
da computação, mas as primeiras abordagens ao reuso eram
as da prática corrente. Hoje, sistemas complexos e de alta
qualidade precisam ser desenvolvidos em períodos de tempo
muito curtos. Isso implica na utilização de componentes.
Palavras-chave: Reuso,Componentes, Engenharia
Software.
INTRODUÇÃO
A engenharia de software baseada em componentes
(component-based software engineering, CBSE) é um
processo que enfatiza o projeto e a construção de sistemas
baseados em computador usando “componentes” de software
reusáveis. [3]
ENGENHARIA DE SOFTWARE
Engenharia de Software é a metodologia de desenvolvimento
e manutenção de sistemas modulares, com as seguintes
características [5]:
• Adequação aos requisitos funcionais do negócio do
cliente e seus respectivos procedimentos pertinentes;
• Efetivação de padrões de qualidade e produtividade em
suas atividades e produtos;
• Fundamentação na tecnologia da informação disponível,
viável e oportuna;
• Planejamento e gestão de atividades, recursos, custos e
datas.
Como conclusão, pode-se relatar que engenharia de software
é um conjunto de práticas para desenvolvimento de soluções
de software, ou seja, roteiro que pode utilizar diversas
técnicas.
OBJETIVOS DA ENGENHARIA DE SOFTWARE
De um modo geral, considera-se que os objetivos primários
da Engenharia de Software são o aprimoramento da
qualidade dos produtos de software e o aumento da
produtividade dos engenheiros de software, além do
atendimento aos requisitos de eficácia e eficiência, ou seja,
efetividade [1].
Com base nos objetivos da Engenharia de Software, fica
evidente a necessidade da adoção de um modelo sistêmico
para padronizar e gerenciar os processos de desenvolvimento
de software.
Segundo Rezende [5], pode-se resumir que a anticrise é a
união e trabalho conjunto e harmonioso de três elementos:
Empresa (Alta Administração), Cliente e/ou usuário e a
unidade de informática (Desenvolvedores de soluções).
de QUALIDADE DE SOFTWARE
Atingir um alto nível de qualidade de produto ou serviço é o
objetivo da maioria das organizações. Atualmente não é mais
aceitável entregar produtos com baixa qualidade e reparar os
problemas e as deficiências depois que os produtos foram
entregues ao cliente. [6]
Abordagens importantes como as normas ISO 9000 e a ISO /
IEC 12207, o modelo CMM (Capability Maturity Model) e o
SPICE (Software Process Improvement and Capability
dEtermination) sugerem que melhorando o processo de
software, podemos melhorar a qualidade dos produtos.
ENGENHARIA DE SOFTWARE BASEADA EM
COMPONENTES
A CBSE, superficialmente parece bastante semelhante à
engenharia de software convencional ou orientada a objetos.
O processo começa quando uma equipe de software
estabelece os requisitos para um sistema a ser construído
usando técnicas de coleta de requisitos convencionais. Um
projeto arquitetural é estabelecido, mas ao invés de passar
imediatamente a tarefas de projeto mais detalhadas, a equipe
examina os requisitos para determinar que subconjunto é
mais adequado à composição, do que à construção. Isto é, a
equipe formula as seguintes questões para cada requisito do
sistema: [2]
• Componentes comerciais prontos para uso (commercial
off-the-shelf, COTS) estão disponíveis para implementar
o requisito?
• Componentes reusáveis, internamente desenvolvidos,
estão disponíveis para implementar o requisito?
• As interfaces dos componentes disponíveis são
compatíveis com a arquitetura do sistema a ser
construído?
A equipe tenta modificar ou remover os requisitos do sistema
que não podem ser implementados com COTS ou com
componentes próprios. Se os requisitos não puderem ser
mudados ou descartados, os métodos convencionais ou de
orientação a objetos de engenharia de software são aplicados
para desenvolver aqueles componentes novos, que precisam
ser trabalhados pela engenharia para satisfazer os requisitos.
Mas para aqueles requisitos que podem ser atendidos com
componentes disponíveis, um conjunto diferente de
atividades de engenharia de software começa: [2]
• Qualificação de componentes: Os requisitos e a
arquitetura do sistema definem os componentes que
serão necessários. Os componentes reusáveis (seja
COTS ou próprios) normalmente são identificados pelas
características de suas interfaces. Isto é, os serviços
fornecidos e os meios pelos quais os consumidores tem
acesso a esses serviços são descritos como parte da
interface do componente. Mas a interface não fornece
um panorama completo do grau em que o componente
vai satisfazer a arquitetura e os requisitos. O engenheiro
de software precisa usar um processo de exploração e
análise para adequar cada componente.
• Adaptação de componente: A arquitetura do software
representa padrões de projeto que são compostos de
componentes (unidades de funcionalidade), conexões e
coordenação. De fato, a arquitetura define as regras de
projeto para todos os componentes, identificando os
modos de conexão e coordenação. Em alguns casos, os
componentes reusáveis existentes podem estar em
desacordo com as regras de projeto da arquitetura. Esses
componentes devem ser adaptados para satisfazer às
necessidades da arquitetura ou descartados e substituídos
por outros componentes, mais adequados.
• Composição de componentes: O estilo arquitetural
desempenha novamente um papel importante no modo
pelo qual os componentes de software são integrados
para formar um sistema em funcionamento.
Identificando os mecanismos de conexão e de
coordenação ( ex.: propriedades do projeto em tempo de
execução), a arquitetura determina a composição do
produto final.
• Atualização de componentes: Quando são
implementados sistemas com componentes COTS, a
atualização é complicada pela necessidade de terceiros
(a empresa que desenvolveu o componente reusável
pode não estar à disposição da empresa de engenharia de
software).
O termo componente foi usado repetidamente, no entanto,
uma descrição definitiva do termo é imprecisa. Existem as
seguintes possibilidades: [2]
• Componente – uma parte não-trivial de um sistema,
praticamente independente é substituível, que preenche
uma função clara no contexto de uma arquitetura bem
definida.
• Componente de software em execução – um pacote
dinamicamente constituído de um ou mais programas,
geridos como uma unidade, ao qual se tem acesso
2
através de interfaces documentadas, que podem ser
descobertas durante a execução.
• Componente de software – uma unidade com
dependências de contexto apenas explícita e
contratualmente especificadas.
• Componente de negócio – implementação, em software,
de um conceito de negócio ou processo de negócio
“autônomo”.
Além dessas descrições, os componentes de software podem
também ser caracterizados com base no seu uso, no processo
CBSE. Além de componentes COTS, o processo CBSE
produz: [2]
• Componentes qualificados – avaliados por engenheiros
de software para garantir que não apenas a
funcionalidade, mas também o desempenho, a
confiabilidade, a usabilidade e outros fatores de
qualidade satisfazem os requisitos do sistema ou do
produto a ser construído.
• Componentes adaptados – adaptados para modificar
características não requeridas ou indesejáveis (também
chamado mascarar ou empacotar).
• Componentes montados – integrados no estilo
arquitetural e interconectados com uma infra-estrutura
adequada para permitir que os componentes sejam
coordenados e geridos efetivamente.
• Componentes atualizados – para substituir o software
existente à medida que novas versões de componentes se
tornam disponíveis.
Como a CBSE é uma disciplina em evolução, é improvável
que uma definição unificadora surja a curto prazo.
O PROCESSO CBSE
O processo CBSE deve ser caracterizado de um modo que
não identifique apenas candidatos a componente, mas
também qualifique a interface de cada componente, adapte
componentes para remover discordâncias arquiteturais,
monte componentes num estilo arquitetural selecionado e
atualize os componentes, à medida que os requisitos do
sistema se modifiquem. [2]
O modelo de processo para a engenharia de software baseada
em componentes enfatiza caminhos paralelos, nos quais a
engenharia de domínio ocorre simultaneamente com o
desenvolvimento baseado em componentes. A engenharia de
domínio realiza o trabalho necessário para estabelecer um
conjunto de componentes de software que podem ser
reusados pelo engenheiro de software. Esses componentes
são então transportados através da “fronteira” que separa a
engenharia de domínio do desenvolvimento baseado em
componentes.
ENGENHARIA DE DOMÍNIO
O objetivo da engenharia de domínio é identificar, construir,
catalogar e disseminar um conjunto de componentes de
software que tem aplicabilidade a software existente e futuro,
num particular domínio de aplicação. A meta global é
estabelecer mecanismos que permitam aos engenheiros de
software compartilhar esses componentes, reusá-los, durante
o trabalho com sistemas novos e existentes. [2] [4]
A engenharia de domínio inclui três principais atividades:
análise, construção e disseminação. Pode ser alegado que o
reuso vai desaparecer, não por eliminação, mas por
integração do contexto da prática de engenharia de software.
À medida que o reuso tem uma maior ênfase, alguns
acreditam que a engenharia de domínio vai se tornar tão
importante quanto a engenharia de software durante a
próxima década.
O PROCESSO DE ANÁLISE DE DOMÍNIO
Os passos do processo de análise de domínio no contexto da
engenharia de software orientada a objetos foram definidos
como: [2] [3] [4]
1. Defina o domínio a ser investigado.
2. Categorize os itens extraídos do domínio.
3. Colete uma amostra representativa das aplicações do
domínio.
4. Analise cada aplicação da amostra.
5. desenvolva um modelo de análise para os objetos.
É importante notar que a análise de domínio é aplicável a
qualquer paradigma de engenharia de software e pode ser
aplicada tanto para o desenvolvimento convencional quanto
para o orientado a objetos.
A expansão do segundo passo da análise de domínio, sugere
uma abordagem de oito passos para a identificação e
categorização de componentes reusáveis: [2]
1. Selecione funções ou objetos específicos
2. Abstraia funções ou objetos.
3. Defina uma taxonomia.
4. Identifique as características comuns
5. Identifique as relações específicas
6. Abstraia as relações
7. Crie um modelo funcional
8. Defina uma linguagem de domínio
Uma linguagem de domínio permite a especificação e
posterior construção de aplicações dentro do domínio.
Apesar de os passos mencionados fornecerem um modelo
útil para a análise de domínio, não fornecem diretrizes para
decidir que componentes de software são candidatos a reuso.
Abaixo um conjunto de questões pragmáticas como guia para
identificar componentes de software reusáveis: [2]
• A funcionalidade do componente é necessária em
implementações futuras?
• Quão comum é a função do componente dentro do
domínio?
• Há duplicação da função do componente dentro do
domínio?
• O componente é dependente de hardware?
• O hardware permanece imutável entre implementações?
• As especialidades do hardware podem ser removidas
para outro componente?
• O projeto é suficientemente otimizado para a
implementação seguinte?
• Podemos adicionar parâmetros a um componente não-
reusável de modo que se torne reusável?
• O componente é reusável em várias implementações
apenas com pequenas modificações?
• O reuso pela modificação é exeqüível?
• Um componente não-reusável pode ser decomposto para
produzir componentes reusáveis?
• Quão válida é a decomposição de componente para
reuso?
CONCLUSÃO
É importante que os desenvolvedores de software
reconheçam que não é possível desenvolver sistemas com
qualidade, cumprir prazos e custos e atender às expectativas
dos usuários sem ter um processo de desenvolvimento por
componentes definido, compreendido e utilizado por toda a
equipe.
O nível de complexidade da sua implementação pode ser
dimensionada de acordo com o porte do sistema,
viabilizando para as pequenas organizações desenvolvedoras
de software. Possibilita então ser um dos fatores críticos para
o sucesso no desenvolvimento de software.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] MAFFEO, BRUNO, Engenharia de Software e Especificação de
Sistemas, Rio de Janeiro, Ed. Campus, 1992.
[2] FILHO, WILSON DE PÁDUA PAULA, Engenharia de Software, Rio
de Janeiro, Ed. LTC, 2003.
[3] PETERS, JAMES F. et al. Engenharia de Software,Rio de Janeiro, Ed.
Campus,2001.
[4] PRESSMAN, ROGER S., Engenharia de Software, Rio de Janeiro, Ed.
McGraw-Hill, 2002.
[5] REZENDE, DENIS ALCIDES, Engenharia de Software e Sistemas de
Informações, Rio de Janeiro, Ed. Brasport, 1999.
[6] SOMMERVILLE, IAN, Engenharia de Software, São Paulo, Ed.
Pearson Education, 2003.