Engenharia de Componentes - Parte 1

Este estudo descreve assuntos relacionados à componentização, que devem ser analisados antes de um estudo mais aprofundado neste universo da componentização de software. Os conceitos tratados serão a Engenharia de software, engenharia web e engenharia de componentes.

por Jean Wagner Kleemann

1. INTRODUÇÃO

No processo de desenvolvimento de software, uma questão muito discutida é a produtividade. Os sistemas estão a cada dia mais complexos e muitos padrões de desenvolvimento e gerenciamento de processos não atendem as expectativas desejadas.

Na busca de novas metodologias e práticas de desenvolvimento de software, algumas soluções, como a orientação a objetos e padrões de projeto, ainda deixam distante da sonhada reutilização e rápida implementação de sistemas complexos. Contudo a componentização é uma alternativa capaz de lidar com problemas ligados ao reaproveitamento, não somente de código, mas também de funcionalidades e interfaces, independentemente de plataforma, diminuindo custos e tempo de desenvolvimento.

Com o desenvolvimento baseado em componentes, surge a idéia de "crie uma vez, use onde quiser". Neste conceito não é necessário escrever uma nova aplicação codificando linha a linha, mas consiste em montar sistemas utilizando componentes já implementados. Proporcionando assim o rápido desenvolvimento, facilidade de manutenção e maior qualidade dos sistemas.

Entretanto, encontrar componentes que se encaixam em domínios de negócios distintos é algo difícil, sendo sugerida então a implementação de seus próprios componentes. Para isso é essencial à utilização de padrões em todo processo de desenvolvimento de componentes de software.

Este estudo descreve assuntos relacionados à componentização, que devem ser analisados antes de um estudo mais aprofundado neste universo da componentização de software. Os conceitos tratados serão a Engenharia de Software, Engenharia Web e Engenharia de Componentes, bem como a tecnologia Java, Design Patterns, PostgreSQL, RUP e Sistemas Distribuídos.

2. ESTUDO SOBRE A ENGENHARIA DE COMPONENTES

2.1 Engenharia de Software

Segundo Friedrich Ludwig Bauer (1969, p. 231), "Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais".

2.1.1 Conceitos

A engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade.

Essas práticas e tecnologias envolvem linguagens de programação, banco de dados, ferramentas, plataformas, bibliotecas, padrões, processos e qualidade de software, entre outros.

Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema de informação Sistema Computacional, pois ambos se confundem.

O fundamento da engenharia de software é a camada de processo. O processo de engenharia de software mantém unidas as camadas de tecnologia e permite o desenvolvimento racional e oportuno de software para computador (PRESMMAN, 2002).

2.1.2 Fases e Atividades Principais e de Apoio

Indiferente do escopo a ser aplicada, a engenharia de software divide o processo de desenvolvimento em três fases distintas: Definição (Análise do sistema, planejamento do projeto de software e análise de requisitos), Desenvolvimento (projeto de software, codificação e realização de testes do software), Manutenção (correção, adaptação e melhoramento funcional).

Estas fases ainda são complementadas por Atividades de apoio, como por exemplo: Controle de Configuração, Controle de Qualidade, Verificação e Validação, Auditorias, Gerenciamento de Riscos, Acompanhamento e Controle do Projeto de Software.

2.1.3 Qualidade de Software

Segundo o Software Engineering Body of Knowledge (SWEBOK, 2004), a qualidade de software pode ser dividida em três tópicos para melhor entendimento, sendo eles:

· Fundamentos de qualidade de software: Cultura e ética de engenharia de software, Valores e custos de qualidade, Modelos e características de qualidade, Melhoria da qualidade.

· Gerência do processo de qualidade de software: Garantia de qualidade de software, Verificação e validação, Revisões e auditorias,

· Considerações práticas: Requisitos de qualidade para aplicações, Caracterização de defeitos, Técnicas de gerência de qualidade de software, Medidas de qualidade de software.

Ao contrário de alguns autores que se apóiam em testes de software para garantir qualidade, o SWEBOK esclarece que essa área não exige a execução do software para avaliá-lo, em contraposição á área de conhecimento teste de software.

Tendo em vista que a qualidade não é incorporada ao produto depois de concluído, essa atividade é aplicada durante todas as etapas de desenvolvimento, pois os fatores relacionados ao produto dependem diretamente e indiretamente do processo.

A qualidade de software também pode ser definida como a integração entre os requisitos funcionais, requisitos de desempenho, padrões de desenvolvimento claramente documentados e demais características implícitas.

Podemos citar algumas práticas características de qualidade de software:

· Prototipação.

· Testes de Aceitação como Especificação.

· Testes Unitários.

· Revisão de Código.

· Integração Contínua.

· Análise de Risco.

· Análise Estática.

· Automação de Processos.

2.2 Engenharia de componentes

A Engenharia de componentes é uma derivação da engenharia de software, focada na decomposição dos sistemas, em componentes funcionais e lógicos com interfaces bem definidas, usadas para comunicação entre os próprios componentes, que estão em um nível mais elevado de abstração do que os objetos, com isso a comunicação se dá por meio de mensagens.

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 reutilizáveis (PRESMMAN, 2002).

A prática da tecnologia de software baseado em componentes baseia-se no desenvolvimento através de componentes reutilizáveis, levando a redução de tempo de desenvolvimento, e facilitando as mudanças e a implantação de novas funcionalidades.

Dessa forma, o processo de engenharia de software baseada em componentes tem mudado o modo pelo qual sistemas são desenvolvidos, pois desloca a ênfase da programação do software para a composição de sistema de software com base em componentes (PRESMMAN, 2002).

2.2.1 Histórico

Durante a Conferência de Engenharia de Software da OTAN, realizada em 1968, Mcilory sob o titulo "Mass Produced Software Components" (Produção de Componentes de Software em Massa), expõe a idéia de que o desenvolvimento de software deve empenhar-se em desenvolver 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 seguida, como primeira implementação da infraestrutura de sua idéia, incluiu pipes (para comunicação entre processos) e filtros no sistema operacional Unix.

Em 1976, DeRemer propôs um paradigma de desenvolvimento, que consistia na idéia do sistema ser 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 desenvolver componentes.

Podemos citar alguns componentes bastante conhecidos atualmente, como: CMM (CORBA Component Model) do OMG (Object Management Group), DCOM (Distributed Component Object), COM/COM+ (Component Object Model) da Microsoft, e JavaBeans e Enterprise JavaBeans (EJB) da Sun.

2.2.2 Conceitos

A engenharia baseada em componentes possui as etapas de coleta de requisitos e passa por um projeto arquitetural, da mesma forma que a engenharia de software tradicional. Porém a partir desse ponto começa a se diferenciar, pois começa a ser analisado os requisitos com objetivo de buscar módulos que sejam mais adequados à composição, ao invés de iniciar a construção e partir para tarefas de projeto mais detalhadas.

Ao fazer essa análise dos subconjuntos ou módulos do sistema, pode se fazer o uso de componentes já existentes, sendo componentes próprios ou comerciais.

Segundo Desmond D"Sousa (1998) um componente é um pacote coerente de artefatos de software que pode ser desenvolvido independentemente e entregue como unidade e que pode ser composto, sem mudança, com outros componentes para construir algo maior.

2.2.3 Reuso

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.

Dentro da engenharia de componentes, são observadas algumas características positivas e outras nem tanto, mas que valem ser destacadas:

· Os riscos são menores ao usar um componente já existente em relação ao desenvolvimento de algo a partir do zero.

· O aumento da produtividade, tendo em vista a redução de esforços pela equipe de desenvolvimento. Seguindo a idéia “Crie uma vez, use onde quiser”.

· A qualidade e confiabilidade do produto são maiores, pois o componente reutilizado já foi testado e aprovado.

· No caso de componentes comercias, pode-se não ter acesso ao código fonte ou depender de direitos autorais e licenças.

· Resistência da parte das equipes de desenvolvimento, pois exige forte padronização (investimento de tempo e controle de qualidade) e documentação (investir mais tempo nos artefatos). A adoção de novas práticas de desenvolvimento geralmente encontra forte resistência a mudanças por parte da equipe.

2.2.4 Design Patterns

Design Patterns, ou padrões de projeto, significa um grupo de práticas para definir o problema, a solução e em qual situação aplicar esta solução e suas conseqüências no desenvolvimento de software.

Os padrões são desenvolvidos a partir de experiências práticas em projetos reais. É resultado da experiência de arquitetos, que aplicam estes padrões e experimentam o resultado em seus próprios problemas. A experiência desses arquitetos certamente proporciona a abordagem correta para um problema específico, da forma mais indicada.

Fazendo uso de tais padrões, temos como resultado uma qualidade de código, permitindo a reutilização de forma flexível e expansível. Por se tratar de questões que nasceram de um problema real, e a solução foi testada e documentada, os padrões aumentam de forma significativa a produtividade e qualidade, pois a solução já está definida.

2.2.5 UML Components

A UML pode ser definida como uma linguagem de diagramação da metodologia orientada a objetos, que serve de apoio à análise de sistemas, desde o levantamento dos requisitos até a implantação de um sistema.

É composta por diversos elementos básicos que representam as diferentes partes de um sistema, como por exemplo: Classe, Interface, Nota, Pacote, Caso de Uso, Atividades, dentre outros. Além disso, a UML permite a criação de elementos próprios através dos estereótipos, valores de etiqueta e restrições, de acordo com Melo (2004).

A UML na versão 2.0 é composta por treze diagramas, divididos nas categorias estruturais (características que não mudam com o tempo) e dinâmicos (mostram como o sistema evolui durante o tempo), conforme mencionado por Melo (2004) e representado abaixo pela Figura 1.

Figura 1 – Diagramas da UML 2.0.

A UML possui uma série de diagramas para representação de componentes e suas especificações, interações e integração com demais sistemas. Segundo RUBIRA (2008), a UML Components, atende todas as fases de elaboração de componentes de software, desde o levantamento de requisitos até o sistema em funcionamento, conforme a Figura 2, abaixo representada.

Figura 2. Processo UML Components.

Na fase de especificação dos requisitos, que é independente de tecnologia a ser utilizada, ocorre a modelagem lógica do negócio. O processo UML Components mostra os artefatos envolvidos nesta fase, mas não descreve como devem ser produzidos, sendo eles:

· Processo do Negócio (Business Process): Se trata de uma representação gráfica, através de um diagrama de atividades, descrevendo as atividades que representam o funcionamento do negócio em si. Serve para melhor compreensão do domínio, envolvendo várias funcionalidades do sistema e mostrando a relação entre elas, e separando as atividades manuais e automáticas.

· Modelo Conceitual do Negócio (Business Concept Model): Representa as entidades do negócio de uma forma geral. Serve para entender o papel do sistema, contextualizando os desenvolvedores a partir de entidades e relacionamentos.

· Modelo de Casos de Uso (Use Cases Model): É o detalhamento das funcionalidades do sistema e seu relacionamento com os atores. Representa graficamente as principais funcionalidades e o relacionamento entre elas através de diagramas de casos de uso.

Na Fase seguinte, de especificação dos componentes, também independe de tecnologia, e nesta fase são levantadas as interfaces de sistema e de negócio, bem como o detalhamento da seqüência de atividades para desenvolver os componentes. Essas atividades São descritas em três etapas, sendo elas: a identificação dos componentes, interação entre os componentes e especificação final.

O processo de Identificação dos componentes é baseado nas interfaces do sistema, através de um procedimento intuitivo. Também é feito o uso de diagramas de casos de uso específicos e diagramas de fluxo e operação. O modelo de tipos do negócio (Business Type Model) é indicado nesta fase, pois restringe as entidades relevantes para o domínio da solução, focado nas responsabilidades do sistema e não dos atores.

Na Interação entre os componentes é necessário descobrir as operações de negócio que estão ligadas ao relacionamento entre os componentes, através de diagramas dinâmicos, como de colaboração, de seqüência ou de atividades.

Na especificação final dos componentes, cabe o Modelo de Informação das Interfaces (Interface Information Model), que provê a relação entre cada interface e as entidades do modelo de negócio. Dessa forma ajuda o entendimento do contexto de cada interface e auxilia na troca de conhecimento entre a equipe de desenvolvimento.

Já a fase de provisionamento dos componentes depende diretamente de tecnologia, pois define como os componentes serão adquiridos, localizados, reutilizados ou implementados. O processo UML Components lista possíveis maneiras de criar os componentes de software, mas não detalha cada uma delas.

· Aquisição dos componentes: Reutilização de componentes prontos ou a utilização de novos componentes.

· Localização de componentes prontos: buscar por serviço fornecido pelo componente, considerando a semelhança de seus conteúdos.

· Reutilização de componentes: Pode ser necessário adaptar os componentes reutilizados ou até mesmo as funcionalidades do sistema (renegociação dos requisitos).

· Implementação dos Componentes: Deve-se utilizar um modelo de componente já existente, tais como: EJB, COM+, etc.

Por ultimo, na montagem do sistema, também dependente da tecnologia, é feita a implementação dos conectores e a ligação entre os componentes e os conectores do sistema. Nessa fase é observada a adaptação e comportamento dos componentes, requisitos de qualidade, disponibilidade, escalabilidade, confiabilidade, entre outros.

2.3 Engenharia Web

MURUGESAN (1999) define a engenharia Web como o estabelecimento e uso de princípios de engenharia e abordagens disciplinadas para o desenvolvimento, implantação e manutenção de aplicações baseadas na Web.

O ambiente Web possui diversas características, valendo destacar a concorrência, carga imprevisível, disponibilidade, sensibilidade ao conteúdo, evolução dinâmica, imediatismo, segurança e estética, que impulsionaram uma nova dinâmica aos processos já existentes, dando origem a uma nova subárea da Engenharia de Software, a Engenharia Web (PRESSMAN, 2005).

Os websites podem variar de páginas estáticas até verdadeiros sistemas baseados na Web (lojas virtuais, ambientes cooperativos, sistemas de gerência empresarial, etc.). Este tipo de website é definido como Sistemas de Informação Web (Web-based Information Systems - WISs) e ao conjunto amplo de todas as aplicações Web como Web Applications (WebApps).

O capítulo seguinte apresenta uma visão geral das metodologias e práticas da UML que podem ser aplicadas na modelagem de sistemas WEB.

2.2.3.1 Modelagem de Aplicações Web com UML

A metodologia Engenharia Web Baseada em UML (UML-based Web Engineering – UWE) (KOCH, 2002) define um conjunto de modelos a serem construídos no desenvolvimento de uma aplicação Web, uma linguagem de modelagem para a elaboração desses artefatos e um processo para construção dos modelos.

As principais atividades no processo de modelagem são: análise de requisitos, projeto conceitual, projeto de navegação, projeto de apresentação, modelagem de tarefas e modelagem de implantação.

A abordagem UWE apóia o desenvolvimento de aplicações Web com foco especial na sistematização, personalização e geração automática de código. Indica também a utilização de casos de uso para a especificação de requisitos e, baseado nos casos de uso especificados, o projeto conceitual produz um modelo conceitual do problema, definido em termos de classes e associações entre classes relevantes do domínio.

O projeto de navegação utiliza o modelo conceitual como base e é definido em duas etapas: definição do modelo de espaço de navegação e construção do modelo de estrutura de navegação. O primeiro modelo mostra quais objetos podem ser vistos através da navegação pela aplicação Web e é, portanto, um modelo de análise. O segundo modelo é baseado no primeiro e define como os objetos são visitados, sendo construído na fase de projeto.

O projeto de apresentação consiste na modelagem de interfaces com o usuário abstratas, mostrando como a estrutura de navegação definida anteriormente é apresentada ao usuário.

Ele é dividido em uma parte estática e outra dinâmica. A parte estática é representada por uma forma particular de diagrama de classes que usa uma notação de composição de classes. Elementos de apresentação são representados por classes estereotipadas e suas partes internas são representadas graficamente dentro do elemento de modelo “classe”, podendo ter vários níveis de “aninhamento de elementos gráficos”.

Para refinar os casos de uso, diagramas de atividade podem ser utilizados, modelando de forma mais detalhada a interação com o usuário. Por fim, diagramas de implantação podem ser usados para documentar a distribuição dos componentes da aplicação Web.

As Extensões de Aplicações Web (Web Application Extensions – WAE) (CONALLEN, 2002) são extensões ao meta-modelo da UML para a modelagem de características específicas de aplicações Web. A WAE define extensões apropriadas para modelar diversos componentes típicos do desenvolvimento de aplicações Web, usando elementos do meta-modelo da UML adicionados de estereótipos pré-definidos para simbolizar os conceitos necessários.

Além dos estereótipos, a WAE prevê a definição de valores etiquetados (tag values), representados entre colchetes, e restrições (constraints), representadas entre chaves, para alguns elementos.

A WAE é voltada para apoiar a elaboração de modelos de projeto, tendo em vista que essa fase é mais suscetível à tecnologia. A fase de projeto é dividida em duas visões: a visão lógica, que está em um nível mais alto de abstração, definindo classes e associações, e a visão de componentes, que trata dos arquivos que efetivamente comporão o sistema implementado (páginas e diretórios).

Para a visão lógica, são definidos três estereótipos principais aplicados sobre o elemento classe do meta-modelo da UML e diversos estereótipos de associação, como mostram as tabelas 1 e 2, respectivamente. Tais estereótipos podem ser utilizados para a criação de diagramas de classes que representem os elementos Web que compõem o sistema, chegando a um nível de detalhes maior do que os diagramas de classe da fase de análise (pois já incluem informações da plataforma de desenvolvimento), mas ainda num nível de abstração lógico.

Estereótipo	O que a classe estereotipada representa
<<server page>>	Uma página Web dinâmica que efetua processamento no servidor e gera um resultado possivelmente diferente a cada requisição. Suas operações representam funções do script e seus atributos representam variáveis visíveis no escopo da página.
<<client page>>	Uma página Web estática que é simplesmente retornada ao cliente quando requisitada, sem gerar processamento. Pode conter scripts do lado do cliente (client-side), portanto seus atributos e operações referem-se a tais scripts.
<<HTML form>>	Formulários HTML para entrada de dados. Seus atributos representam os campos do formulário. Tais formulários não possuem operações. Qualquer operação que interaja com o formulário deve ser propriedade da página que o contém.

Tabela 1: Estereótipos de classe utilizados na visão lógica do projeto

Além desses elementos básicos, para o que Conallen chama de “Projeto Avançado”, existem estereótipos para representação de outros elementos da visão lógica da camada Web, a saber: conjunto de quadros (classe com estereótipo <<frameset>>), alvo de link (classe com estereótipo <<target>>), link de destino (associação múltipla com estereótipo <<target link>>), bibliotecas de script (classe com estereótipo <<script library>>) e objeto de script (classe com estereótipo <<script object>>).

Estereótipo	O que a associação estereotipada representa
<<link>>	Um link normal entre páginas, representado em HTML pela tag <a>. Parâmetros codificados como parte da URL segundo o protocolo http podem ser representados como atributos da associação.
<<build>>	Relacionamento direcional entre uma server page e uma client page que indica que a saída HTML do processamento da página do servidor é a página do cliente.
<<submit>>	Relacionamento direcional entre um html form e uma server page, representando o envio dos dados dos campos do formulário para a página do servidor para processamento.
<<redirect>>	Ação de redirecionamento de uma página para outra.
<<forward>>	Ação de delegação de uma página para outra. Difere do redirecionamento por manter o contexto da requisição feita à primeira página.
<<object>>	Relacionamento de confinamento entre uma página e um objeto, como uma Applet ou controle ActiveX.
<<include>>	Uma associação direcional entre uma server page e uma outra página que indica que o conteúdo desta última será processado (somente no caso de uma página do servidor) e incluído na primeira.

Tabela 2: Estereótipos de associação utilizados na visão lógica do projeto

Para a visão de componentes, são definidos três estereótipos para o elemento de modelo componente da UML: <<static page>>, componente que representa páginas estáticas, ou seja, sem processamento no lado do servidor; <<dinamic page>>, componente que representa páginas dinâmicas; e <<physical root>>, pacote de componentes representando uma abstração de uma hierarquia de arquivos que contém recursos disponíveis à solicitação no servidor Web.

Por meio de diagramas de componentes, a visão de componentes busca modelar o mapeamento entre os arquivos físicos (representados pelos componentes com os três estereótipos citados) e as representações lógicas apresentadas na visão lógica (representadas por classes estereotipadas, conforme discutido anteriormente).