engenharia de componentes - parte 1

Desenvolvimento - Java

Engenharia de Componentes -Parte 1Este estudo descreve assuntos relacionados à componentização,que devem ser analisados antes de um estudo mais aprofundadoneste universo da componentização de software. Os conceitostratados serão a Engenharia de software, engenharia web eengenharia 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

Publicidade

26 0 0 8

DESENVOLVIMENTO FRONT-END BANCO DE DADOS LOGIN

Anuncie | Fale Conosco | Publique

Copyright 2015 - todos os direitosreservados para Web03

Seja o primeiro de seus amigos a curtir isso.

Engenharia de Componentes - Parte 1 http://www.linhadecodigo.com.br/artigo/3119/engenharia-de-compone...

1 de 14 07/12/2015 16:40

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



2 de 14 07/12/2015 16:40

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.



3 de 14 07/12/2015 16:40

· 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



4 de 14 07/12/2015 16:40

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



5 de 14 07/12/2015 16:40

· 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



6 de 14 07/12/2015 16:40

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.



7 de 14 07/12/2015 16:40

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.



8 de 14 07/12/2015 16:40

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



9 de 14 07/12/2015 16:40

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



10 de 14 07/12/2015 16:40

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).



11 de 14 07/12/2015 16:40

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 ht

podem ser representados como atributos da associação.



12 de 14 07/12/2015 16:40

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).

Jean Wagner Kleemann - Atuo no desenvolvi

mento Web desde 2008 com nas plataformas

java , .net e php. Participação no desenvolvi

mento de sistemas web nas áreas de EAD, I

SSQN, Factoring, e-commerces, sites internacionais, entr

e outros.

Bacharel em Ciência da Computação, pela UNIDERP. Pó

s-Graduado em Engenharia de Componentes Utilizando J

ava, pela TNT Educacional.

Twitter: @jeankleemann

Leia também

Conhecendo a interface Map do JavaJava

Trabalhando com a Interface Set no JavaJava

Classes Wrappers em JavaJava

ComboBoxModel em JavaJava

26 0 0 8



13 de 14 07/12/2015 16:40



14 de 14 07/12/2015 16:40

engenharia de componentes - parte 1

Documents