Um Processo para Construo de Frameworks a partir

da Engenharia Reversa de Sistemas de Informao

Baseados na Web: Aplicao ao Domnio dos Leiles

Virtuais

Reginaldo R

Dissertao de Mestrado apresentada ao Instituto

de Cincias Matemticas e de Computao

- ICMC/USP, para a obteno do ttulo de

Mestre na rea de Cincias de Computao e

Matemtica Computacional.

Orientador: Prof. Dr. Paulo Cesar Masiero

Agosto/2002

Agradecimentos

Agradeo primeiramente a DEUS, pelo dom da vida e por permitir conviver com pessoas to

maravilhosas.

Ao meu orientador, Prof. Dr. Paulo Cesar Masiero, pelos ensinamentos, constante apoio e

extremo profissionalismo na orientao durante todo o perodo deste trabalho.

Aos meus familiares, em especial aos meus pais Aldecir e Cidinha, minha irm Regiani e minha

av Luzia, porque me amam muito mais do que eu possa am-los.

minha colega e amiga do grupo de pesquisa Rosana Teresinha V. Braga e ao Prof. Dr. Ferno

Stella R. Germano, pelas contribuies durante este trabalho.

Prof. Dr. Maria da Graa C. Pimentel e ao Prof. Dr. Jos Carlos Maldonado, pelas sugestes

apresentadas no exame geral de qualificao.

s professoras Prof. Dr. Renata P. M. Fortes, Prof. Dr. Rosely Sanches e Prof. Dr. Sandra

C. P. F. Fabri.

Aos meus amigos: Ades, Andria, Ana Cludia, Aline, Auri, Camilo, Cssio, Dbora, Elisa,

Ellen, Emerson, Enzo, Erika, Fernando Tranquilo, Gelza, Erald o Holands, Flvia, Juliana, Ktia,

Ludimila, Lu, Luciano, Marcelo, Mrio, Maris, Mayb, Matheus, Marisa, Monique, Percy, Bulco,

Rejane, Richard, Rogrio, Rudinei, Sandro, Sandro KLB, Silvio, Simone, Simone Rocio, Thaise,

Tati, Valria, Vangrei, Vivi e Willie.

Aos amigos e companheiros: Maluquinho, Amebo, Kleber, Mininim e Cabeo, pelos bons

momentos que passamos juntos e que sempre sero parte importante da minha vida.

Aos amigos de Junqueirpolis, por, apesar da minha ausncia, ainda serem meus amigos.

Aos professores e funcionrios do ICMC, pela disposio e ateno.

A todos aqueles que, de certa forma, me apoiaram neste trabalho.

FAPESP pelo apoio financeiro.

i

Sumrio

1 Introduo 11.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Organizao da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Reviso da Literatura 42.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Padres de Software e Linguagens de Padres . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Componentes de um Padro . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Classificao de Padres . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Linguagens de Padres . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Exemplos de Linguagens de Padres . . . . . . . . . . . . . . . . . . . . . 92.2.5 A Linguagem de Padres para Gesto de Recursos de Negcio . . . . . . . 10

2.3 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1 Classificao dos Frameworks . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Frameworks Caixa Branca e Frameworks Caixa Preta . . . . . . . . . 142.3.3 Documentao de Frameworks . . . . . . . . . . . . . . . . . . . . . . . . 152.3.4 Exemplos de Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.5 O Framework para Gesto de Recursos de Negcio . . . . . . . . . . . . . 16

2.4 Sistemas de Informao baseados na Web . . . . . . . . . . . . . . . . . . . . . . 172.5 Leiles Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.1 Classificao de Leiles Virtuais . . . . . . . . . . . . . . . . . . . . . . . 192.5.2 Aspectos de Segurana . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.3 Exemplos de Leiles Virtuais . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 O Subprocesso de Criao de um Modelo do Domnio da Aplicao para Sistemas deInformao Baseados na Web 263.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 O Processo de Modelagem do Domnio Proposto: Contextualizao . . . . . . . . 273.3 Criar um Modelo do Domnio da Aplicao . . . . . . . . . . . . . . . . . . . . . 29

ii

3.3.1 Escolher Trs Sistemas do Domnio . . . . . . . . . . . . . . . . . . . . . 293.3.2 Engenharia Reversa dos Sistemas-base . . . . . . . . . . . . . . . . . . . 313.3.3 Criao dos Modelos de Classes dos Sistemas-base . . . . . . . . . . . . . 393.3.4 Criao do Modelo do Domnio . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Criar uma Linguagem de Padres a partir do Modelo de Classes de um Domnio . . 543.5 A Linguagem de Padres para Leiles Virtuais . . . . . . . . . . . . . . . . . . . . 62

3.5.1 Exemplo de um Padro da Linguagem de Padres LV . . . . . . . . . . . . 633.6 Exemplo de Uso da Linguagem de Padres para Leiles Virtuais . . . . . . . . . . 663.7 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4 O Subprocesso de Construo e o Framework Qd+ 754.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.2 O Processo de Construo do Framework Qd+ . . . . . . . . . . . . . . . . . . . . 76

4.2.1 Identificao dos Pontos Variveis . . . . . . . . . . . . . . . . . . . . . . 764.2.2 Projeto do Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.2.2.1 Arquitetura do Framework . . . . . . . . . . . . . . . . . . . . 814.2.2.2 Projeto das Classes do Framework . . . . . . . . . . . . . . . . 84

4.2.3 Implementao do Framework . . . . . . . . . . . . . . . . . . . . . . . . 864.2.3.1 Implementao das Classes da Aplicao . . . . . . . . . . . . . 864.2.3.2 Implementao das Classes de Interface com o Usurio . . . . . 884.2.3.3 Documentao do Framework . . . . . . . . . . . . . . . . . . . 90

4.2.4 Validao do Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.3 Exemplo de Instanciao do Framework . . . . . . . . . . . . . . . . . . . . . . . 92

4.3.1 Processo de Instanciao . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.4 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5 Concluso 1015.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2 Resultados e Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Referncias 104

Apndice A Linguagem de Padres LV 110

Apndice B Lista de Pontos Variveis 127

Apndice C Hierarquia de classes do Framework Qd+ 130

iii

Lista de Figuras

2.1 Linguagem de Padres para Gesto de Recursos de Negcios. . . . . . . . . . . . 112.2 Exemplo de um Padro da Linguagem de Padres GRN. . . . . . . . . . . . . . . 122.3 Arquitetura do Framework GREN. . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Utilizao de Leiles no Comrcio Eletrnico. . . . . . . . . . . . . . . . . . . . . 202.5 Tipos de Leiles Segundo o Esquema de Reck. . . . . . . . . . . . . . . . . . . . 21

3.1 Alternativas para o Desenvolvimento de Sistemas de Informao Baseados na Web. 283.2 Processo de Criao do Modelo do Domnio da Aplicao de SIbWebs. . . . . . . 303.3 Engenharia Reversa dos Sistemas-base. . . . . . . . . . . . . . . . . . . . . . . . 313.4 Grafo de Navegao do Sistema-base Arremate.com. . . . . . . . . . . . . . . . . 343.5 Pgina de Venda do Sistema-base Arremate.com. . . . . . . . . . . . . . . . . . . 373.6 Criao dos Modelos de Classe dos Sistemas-base. . . . . . . . . . . . . . . . . . 403.7 Parte do Modelo Inicial de Classes do Sistema-base Arremate.com. . . . . . . . . . 453.8 Parte do Modelo de Classes Refinado do Sistema-base Arremate.com. . . . . . . . 463.9 Criao do Modelo do Domnio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.10 Criao de uma Linguagem de Padres. . . . . . . . . . . . . . . . . . . . . . . . 553.11 Modelo de Classes Contendo os Elementos que Compem os Padres da Linguagem. 573.12 Exemplo da Estrutura dos Padres HABILITAR FAVORITOS e GERENCIAR A EM-

PRESA LEILOEIRA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.13 Grafo de Fluxo de Aplicao dos Padres da Linguagem de Padres LV. . . . . . . 593.14 Exemplo da Aplicao dos Padres 1 e 3 da Linguagem de Padres LV. . . . . . . 683.15 Exemplo da Aplicao dos Padres 4,5 e 6 da Linguagem de Padres LV. . . . . . 703.16 Exemplo da Aplicao dos Padres 7,9 e 10 da Linguagem de Padres LV. . . . . . 72

4.1 Abordagem para Construo e Instanciao de Frameworks. . . . . . . . . . . . . 774.2 Processo para Construo de frameworks Baseado em Linguagem de Padres. . . . 774.3 Arquitetura do Framework Qd+. . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4 Exemplo do Componente Estrutura do Padro IDENTIFICAR O RECURSO. . . . . 854.5 Exemplo de Classes do Framework Qd+ que Representam o Padro IDENTIFICAR

O RECURSO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.6 Arquitetura Simplificada do Framework Qd+. . . . . . . . . . . . . . . . . . . . . 874.7 Hierarquia de Classes do Modelo de Classes do Framework Qd+. . . . . . . . . . . 88

iv

4.8 Pgina de Registro de Novos Usurios do Sistema Referente a uma Instanciaodo Framework Qd+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.9 Instanciao do padro IDENTIFICAR O RECURSO. . . . . . . . . . . . . . . . . . 944.10 Parte dos Mtodos e Atributos da classe UserForm. . . . . . . . . . . . . . . . . . 964.11 Pgina Principal do Sistema de Leiles Virtuais Instanciado. . . . . . . . . . . . . 974.12 Pgina de Login do Usurio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.13 Pgina de Criao de um Leilo Normal. . . . . . . . . . . . . . . . . . . . . . . . 99

v

Lista de Tabelas

3.1 Atividades Bsicas do Processo de Negociao por Intermdio de Leiles Virtuais. 323.2 Listagem de Pginas do Sistema-base Arremate.com. . . . . . . . . . . . . . . . . 333.3 Conjunto de Requisitos do Sistema-base Arremate.com. . . . . . . . . . . . . . . . 363.4 Exemplo de Glossrio do Sistema-base Arremate.com. . . . . . . . . . . . . . . . 393.5 Listagem de Potenciais Classes do Sistema-base Arremate.com. . . . . . . . . . . 413.6 Decises de Anlise/Projeto Referentes aos Requisitos do Sistema-base Arrema-

te.com. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.7 Parte da Listagem de Classe X Sistema. . . . . . . . . . . . . . . . . . . . . . . . 52

4.1 Lista Parcial dos pontos variveis do Framework Qd+ . . . . . . . . . . . . . . . . 794.2 Lista Parcial do Histrico de Aplicao dos Padres da Linguagem de Padres LV

ao iBazar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.3 Lista Parcial dos Atributos da Instanciao do iBazar. . . . . . . . . . . . . . . . . 93

vi

Lista de Quadros

3.1 Partes dos Glossrios do Domnio e dos Sistemas-base. . . . . . . . . . . . . . . . 513.2 Exemplo de Descrio Geral do Padro GERENCIAR EMPRESA LEILOEIRA. . . . 593.3 Parte da Descrio do Participante Taxa. . . . . . . . . . . . . . . . . . . . . . . . 603.4 Componente Prximos Padres do Padro GERENCIAR REPUTAES. . . . . . 603.5 Parte dos Requisitos do Sistema de Leiles Virtuais iBazar. . . . . . . . . . . . . . 68

4.1 Parte da Descrio do Participante Categoria. . . . . . . . . . . . . . . . . . . . 794.2 Parte do Componente Variantes do Padro IDENTIFICAR O RECURSO. . . . . . . 804.3 Exemplo da Hierarquia de Parte de uma Instanciao. . . . . . . . . . . . . . . . . 894.4 Exemplo com Parte do Cdigo do Arquivo UserForm.ssp. . . . . . . . . . . . . 914.5 Hierarquia da classe Product na Instanciao. . . . . . . . . . . . . . . . . . . . 934.6 Exemplo com Cdigo Fonte Parcial de Alguns Scripts dos Objetos Persistentes. . . 95

vii

Resumo

Um processo para o desenvolvimento de frameworks para sistemas de in-

formao baseados na Web proposto. Esse processo composto pelos

subprocessos de engenharia reversa de sistemas baseados na Web, de cri-

ao de uma linguagem de padres e de construo e instanciao do fra-

mework. O subprocesso de engenharia reversa utiliza sistemas presentes na

Web para derivar um modelo do domnio de aplicao. O desenvolvimento

da linguagem de padres baseado no modelo do domnio e a construo

do framework utiliza essa linguagem de padres como base de todo o pro-

cesso. Os produtos resultantes do uso desse processo para o domnio dos

leiles virtuais, a Linguagem de Padres LV e o Framework Qd+, tambm

so apresentados.

viii

Abstract

A process for the development of web-based information systems frame-

works is proposed. This process comprises a reverse engineering for web-

based information systems , a pattern language creation, and a framework

instantiation subprocesses. The reverse engineering subprocess uses exist-

ing WISs to derive an application domain model. The pattern language is

created from the application domain model and the framework is developed

from this pattern language. The deliverables of the application of this pro-

cess to the online auctions domain, the Pattern Language for Online Auc-

tions and the Qd+ Framework, are also presented.

ix

CAPTULO

1Introduo

1.1 Contextualizao

A abordagem de desenvolvimento de software orientado a objetos enfatiza o reuso de software.

Com essa perspectiva, padres de software (Boyd, 1998; Coad, 1992; Coad et al., 1997; Coplien

e Schmidt, 1995; Fowler, 1997; Gamma et al., 1994; Martin et al., 1998; Vlissides et al., 1996)

vm sendo coletados e propostos na ltima dcada como uma forma promissora de reuso, no

somente de cdigo mas tambm de projeto, anlise, arquitetura e processo de desenvolvimento.

Por intermdio dos padres podem ser documentadas solues para diferentes tipos de problemas

que ocorrem ao longo do processo de desenvolvimento de software. Essas solues, quaisquer que

sejam seus nveis de abstrao, podem ser reusadas por outros desenvolvedores ao confrontarem-se

com problemas similares.

Uma linguagem de padres um sistema de padres organizado em uma estrutura que guia

sua aplicao (Kerth e Cunningham, 1997). tambm uma coleo estruturada de padres que se

apiam uns nos outros para transformar requisitos e restries numa arquitetura (Coplien, 1998).

Os padres que constituem uma linguagem de padres cobrem todos os aspectos importantes de

um dado domnio.

Framework um conjunto de classes abstratas e concretas que fornece uma infra-estrutura ge-

nrica de solues para um conjunto de problemas (Johnson e Foote, 1998). Essas classes podem

fazer parte de uma biblioteca de classes ou podem ser especficas de um certo domnio de aplica-

1

1.2 Motivao 2

o. Frameworks possibilitam reutilizar no somente componentes isolados, mas tambm toda a

arquitetura de um domnio especfico.

Essas trs tecnologias padres de projeto, linguagens de padres e frameworks so base

sobre a qual este trabalho est assentado. As trs so incorporadas em um processo para construo

de frameworks a partir da engenharia reversa de sistemas de informao baseados na Web.

1.2 Motivao

Como parte das pesquisas do grupo de engenharia de software do ICMC existe um grande inte-

resse em estudar a relao e aplicao de linguagens de padres e frameworks em sistemas de

informao, bem como desenvolver tcnicas que apiem o desenvolvimento dessas linguagens de

padres e frameworks. Visando a fornecer subsdios para a aplicao de linguagens de padres e a

utilizao de frameworks, dentre outros trabalhos envolvendo frameworks e linguagens de padres

(Braga et al., 1998, 1999; Braga e Masiero, 2000, 2002a), Braga e Masiero (2002b) propem um

processo para a criao de frameworks com base em uma linguagem de padres. O processo utiliza

o conhecimento sobre um determinado domnio existente na linguagem de padres para o desen-

volvimento de frameworks. Utilizando esse processo o grupo que pesquisa padres de software e

frameworks no ICMC/USP (Instituto de Cincias Matemticas e de Computao Universidade de

So Paulo) props uma Linguagem de Padres para Gesto de Recursos de Negcios (Linguagem

de Padres GRN) (Braga et al., 1999). Com base nessa linguagem de padres foi desenvolvido

um framework para Gesto de REcursos de Negcios (GREN) com o objetivo de apoiar as apli-

caes que a linguagem de padres abrange. Nesse contexto, torna-se importante complementar

esse processo proposto fornecendo subsdios para a aprendizagem sobre domnios de aplicao de

sistemas de informao e a criao de linguagens de padres que apiem o desenvolvimento desses

sistemas.

Com o crescimento da utilizao da Internet como meio de comercializao tambm torna-se

importante o desenvolvimento de frameworks que apiem sistemas de informao que utilizam

essa tecnologia, os sistemas de informao baseados na Web (Web-based Information Systems).

Dentre as vrias formas de comercializao pela Internet existem os leiles virtuais, que so um

tipo alternativo de comercializao com vrios motivos para serem utilizados, dentre os quais a

capacidade de aumentar o pblico consumidor e oferecer produtos a um baixo preo. Esse tipo

alternativo de comercializao, os leiles, se integra e complementa o Framework GREN.

Adicionalmente, com a forte tendncia em utilizar a interface Web para todos os sistemas de

informao relevante estender a Linguagem de Padres GRN e o Framework GREN para apoiar

o desenvolvimento de sistemas de informao baseados na Web.

1.3 Objetivos 3

1.3 Objetivos

Este trabalho tem como objetivo propor um processo para construo de frameworks de sistemas

de informao baseados na Web. Utiliza-se como base o processo de construo e instanciao

de frameworks proposto por Braga e Masiero (2002b), com uma adaptao e uma extenso. Neste

trabalho, o subprocesso de criao da linguagem de padres estendido e detalhado e o subproces-

so de modelagem do domnio da aplicao adaptado para ser baseado em requisitos recuperados

por um processo de engenharia reversa de sistemas baseados na Web.

Usa-se como exemplo para ilustrar o processo proposto, o domnio dos leiles virtuais na

Web e para esse domnio so criados uma linguagem de padres e um framework. A linguagem

de padres resultante da aplicao do processo proposto pode ser considerada uma extenso da

Linguagem de Padres GRN, complementando-a com uma forma alternativa de comercializao.

Analogamente, o framework obtido por meio da aplicao do processo apresentado por Braga

e Masiero (2002b) desenvolvido de forma a poder ser, futuramente, integrado ao Framework

GREN, dotando-o de uma interface Web.

1.4 Organizao da Dissertao

O Captulo 2 apresenta os conceitos de padres, de frameworks e uma breve introduo aos sis-

temas de informao baseados na Web, inclusive os leiles virtuais. O Captulo 3 apresenta o

subprocesso de criao de um modelo do domnio da aplicao para sistemas de informao base-

ados na Web e o de criao de uma linguagem de padres. Ainda nesse captulo apresentada a

linguagem de padres para gesto de leiles virtuais, resultado da aplicao dos dois subprocessos

propostos. Apresenta-se no Captulo 4 o subprocesso de construo do frameworks que baseia-se

em uma linguagem de padres, no caso especfico a Linguagem de Padres LV, como proposto por

Braga e Masiero (2002b). Nesse captulo apresentado tambm, o subprocesso de instanciao do

frameworks que, da mesma forma que o subprocesso de construo, baseia-se na Linguagem de

Padres LV. Finalizando, o Captulo 5 apresenta as concluses do trabalho e sugestes de trabalhos

futuros.

CAPTULO

2Reviso da Literatura

2.1 Consideraes Iniciais

Linguagens de padres e frameworks tm sido utilizados como uma forma de reuso no somente de

cdigo mas de anlise e projeto. Existe um relacionamento prximo entre linguagens de padres

e frameworks que torna benfica sua utilizao conjunta no desenvolvimento de software. Neste

captulo so apresentados conceitos relativos a ambos para que se possa entender a Linguagem

de Padres GRN e o Framework GREN e as vantagens de utiliz-los em gesto de recursos de

negcio. Visando a complementar o Framework GREN e, futuramente, estend-lo, foi utilizado

neste trabalho o domnio dos leiles virtuais. Os leiles virtuais so um bom exemplo de Sistemas

de Informao baseados na Web (SIbWebs), pois podem atingir um pblico consumidor maior que

aplicaes cliente/servidor tradicionais e so uma forma alternativa de comercializao de recursos

adequada quando outras formas convencionais no so aplicveis.

A Seo 2.2 apresenta conceitos sobre padres e linguagens de padres, juntamente com alguns

exemplos de linguagens de padres e suas aplicaes. Ainda nessa seo mostrado com um pouco

mais de detalhes a Linguagem de Padres para a Gesto de Recursos de Negcios. Na Seo 2.3

so discutidos de forma sucinta alguns aspectos e caractersticas dos frameworks, bem como alguns

exemplos, entre os quais o Framework GREN. Apresenta-se na Seo 2.4 uma introduo aos

SIbWebs. Finalizando o captulo, a Seo 2.5 apresenta uma introduo sobre os leiles virtuais e

suas caractersticas e alguns exemplos de leiles virtuais em funcionamento na Web.

4

2.2 Padres de Software e Linguagens de Padres 5

2.2 Padres de Software e Linguagens de Padres

O reuso de software um objetivo comum nas organizaes produtoras de software, devido ne-

cessidade de melhorar a produtividade, a manutenibilidade e a qualidade tanto do software como

do processo de desenvolvimento. Programadores experientes reusam seus projetos, mas o pro-

blema central do reuso de informaes de projeto como captur-lo e express-lo (Biggerstaf e

Richter, 1987). Padres de software vm tendo destaque em reuso de software em vrios nveis

de abstrao, no somente de cdigo mas tambm de projeto, anlise, arquitetura e processo de

desenvolvimento. Padres de software permitem que sejam evidenciadas caractersticas comuns

que podem ser reusadas em novos projetos e aplicaes.

A origem dos padres vem do trabalho do arquiteto Christopher Alexander no fim da dca-

da de 1970. Dentre seus trabalhos destacam-se os livros A Pattern Language: Towns, Buildings,

Construction (Alexander et al., 1977) e The Timeless Way of Building (Alexander, 1979) que exem-

plificam e apresentam seu mtodo de documentao de padres. Apesar do trabalho de Alexander

ser voltado para a arquitetura, possui fundamentao bsica que pode ser abstrada para vrias

reas, incluindo o processo de desenvolvimento de software.

Padres de software descrevem o desenvolvimento de solues que obtiveram sucesso em pro-

blemas que ocorrem recorrentemente em certos contextos. Pode-se descrever padres como um

esquema que composto por contexto, problema e soluo. O contexto a situao que d origem

a um problema, que por sua vez ocorre recorrentemente nesse contexto. A soluo uma maneira

comprovada e consistente de resolver o problema. O padro tenta obter a essncia do problema e

tornar-se a soluo do problema, podendo ser aplicado a novos contextos. Essa forma importante

porque permite a definio de padres como uma soluo para um problema em contexto, uma

definio que fixa seus limites como um simples par problema-soluo (Buschmann et al., 1996).

No entanto, um padro mais que apenas uma soluo comprovada para um problema recorren-

te. O problema ocorre em um certo contexto e com a influncia de diversos fatores. A soluo

proposta deve apresentar uma estrutura que equilibre esses fatores ou foras.

Projetistas familiarizados com certos padres podem aplic-los imediatamente a problemas

sem ter que redescobri-los (Gamma et al., 1994). Alm disso, desenvolvedores passam a utilizar

uma linguagem prpria de comunicao baseada em padres que facilita a comunicao de equipes

de desenvolvimento, por fornecer uma mesma linguagem ou vocabulrio comum (Schmidt et

al., 1996). Pode-se observar que padres no apenas identificam solues mas tambm explicam

porque as solues so necessrias (Appleton, 1997).

2.2 Padres de Software e Linguagens de Padres 6

2.2.1 Componentes de um Padro

Um padro fornece a possibilidade de reuso de experincia, j que uma soluo comprovada.

Geralmente no so expressos em uma linguagem de programao especfica e para que possam ser

utilizados de maneira eficiente devem ser documentados de forma a proporcionar uma recuperao

fcil e rpida. Se o padro no for apresentado claramente, o desenvolvedor no ir utiliza-lo

pelo simples fato de no saber que existe uma soluo que seja adequada. Visando a resolver tal

problema existem diversos padres sobre padres (patterns on patterns), que fornecem as diretrizes

necessrias para uma boa documentao de padres. Porm, existem componentes essenciais que,

segundo Appleton (1997) devem ser claramente identificveis ao ler-se um padro:

nome: todo padro deve possuir um nome significativo. Pode ser uma simples palavra ou

uma frase curta que faa referncia ao padro e conhecimento ou estrutura descritos por

ele. Se o padro possuir mais que um nome comumente usado ou reconhecvel na literatura,

subsees conhecido como ou nome alternativo devem ser criadas;

problema: estabelece o problema a ser resolvido pelo padro, descreve a inteno e objetivos

do padro perante o contexto e as foras especficas;

contexto: precondies dentro das quais o problema e sua soluo costumam ocorrer e para

as quais a soluo desejvel, o que reflete a aplicabilidade do padro. Pode tambm ser

considerado como a configurao inicial do sistema antes da aplicao do padro;

foras: descrio dos impactos, influncias relevantes para o problema e como eles intera-

gem ou so conflitantes entre si e com os objetivos a alcanar. Um cenrio que serve como

motivao para o padro;

soluo: relacionamentos estticos e regras dinmicas que descrevem como obter o resultado

desejado. Equivale a dar instrues que descrevem como o problema resolvido, podendo

para isso utilizar texto, diagramas e figuras. So possveis as seguintes subsees:

estrutura: revela a forma e a organizao esttica;

participantes: descreve os componentes do padro;

dinmica: exibe o comportamento dinmico do padro;

implementao: mostra detalhes de implementao;

variantes: apresenta possveis variaes e especializaes da soluo;

exemplos: uma ou mais aplicaes do padro que ilustram, num contexto inicial especfico,

como o padro aplicado e transforma aquele contexto em um contexto final;

contexto resultante: o estado ou configurao do sistema aps a aplicao do padro, po-

dendo ter uma subseo conseqncias, que podem ser boas ou ruins. Descreve as ps-

condies e os efeitos colaterais do uso do padro;

2.2 Padres de Software e Linguagens de Padres 7

justificativa: uma explicao das regras ou passos do padro que mostra como e porque ele

trata suas influncias contrrias, definidas em foras, para alcanar os objetivos, princpios

e filosofia propostos. Mostra como o padro funciona, porqu funciona e porqu ele til;

padres relacionados: os relacionamentos estticos e dinmicos desse padro com outros

dentro da mesma linguagem ou sistema de padres. Padres relacionados geralmente com-

partilham as mesmas influncias. So possveis os seguintes tipos de padres relacionados:

padres predecessores: cuja aplicao conduza ao padro atual;

padres sucessores: que devem ser aplicados aps o padro atual;

padres alternativos: que descrevem uma soluo diferente para o mesmo problema

mas diante de influncias e restries diferentes; e

padres co-dependentes: que podem, ou devem, ser aplicados simultaneamente com o

padro atual; e

usos conhecidos: descreve ocorrncias conhecidas do padro e sua aplicao em sistemas

existentes. Isso ajuda a validar o padro, mostrando que ele realmente uma soluo provada

para um problema recorrente.

2.2.2 Classificao de Padres

Conforme mencionado na Seo 2.2, padres de software abrangem diferentes nveis de abstrao

e, portanto, podem ser classificados em diversas categorias, de modo a facilitar sua recuperao e

uso. Porm, essa classificao no rigorosa, podendo haver padres que se encaixem em mais

do que uma categoria. A seguir algumas categorias importantes so apresentadas, porm existem

outras categorias de padres que so discutidas por Coplien e Schmidt (1995), Vlissides et al.

(1996) e Martin et al. (1998):

padres de processo: definem solues para os problemas encontrados nos processos envol-

vidos na engenharia de software, por exemplo: desenvolvimento, controle de configurao,

testes, etc;

padres arquiteturais: expressam o esquema ou organizao estrutural fundamental de siste-

mas de software ou hardware;

padres de anlise: descrevem solues para problemas de anlise de sistemas, embutindo

conhecimento sobre o domnio de aplicao especfico;

padres de projeto: definem solues para problemas de projeto de software;

padres de interface: definem solues para problemas comuns no projeto da interface de

sistemas. um caso particular dos padres de projeto;

2.2 Padres de Software e Linguagens de Padres 8

padres de programao: descrevem solues de programao particulares de uma determi-

nada linguagem ou regras gerais de estilo de programao;

padres de persistncia: descrevem solues para problemas de armazenamento de informa-

es em arquivos ou bancos de dados;

padres para hipertexto: descrevem solues para problemas encontrados no projeto de hi-

pertextos;

padres para hipermdia: descrevem solues para problemas encontrados no desenvolvi-

mento de aplicaes hipermdia; e

padres sobre padres: descrevem como um padro deve ser escrito, ou seja, que padronizam

a forma como os padres so apresentados aos seus usurios;

Comparando-se as vrias categorias de padres, os padres de projeto so os padres que mais

recebem ateno na comunidade de software, talvez pelo fato do livro de Gamma et al. (1994) ter

feito com que padres fossem utilizados no desenvolvimento de software e, portanto, tornarem-

se um marco referencial na utilizao de padres para esse fim. No entanto, o termo padro de

projeto tem sido utilizado para denominar qualquer padro que trate de arquitetura de software,

projeto ou implementao. Buschmann et al. (1996) prope a classificao das vrias categorias

de padres em trs nveis:

padres arquiteturais: expressam uma organizao estrutural fundamental para sistemas de

software. Fornecem um conjunto predefinido de subsistemas, especificando suas responsa-

bilidades e incluindo regras e diretrizes para organizar o relacionamento entre eles;

padres de projeto: fornecem um esquema para refinar subsistemas ou componentes de um

sistema de software ou relacionamento entre eles, que descrevem a estrutura de comunicao

dos componentes; e

idiomas: so padres de baixo nvel para linguagens de programao especficas, que des-

crevem como implementar aspectos particulares de componentes ou relacionamentos entre

eles utilizando caractersticas da linguagem.

2.2.3 Linguagens de Padres

Uma linguagem de padres (pattern language) uma coleo estruturada de padres que se api-

am uns nos outros para transformar requisitos e restries numa arquitetura (Coplien, 1998). Os

padres que constituem uma linguagem de padres cobrem todos os aspectos importantes de um

dado domnio. Pelo menos um padro deve estar disponvel para cada aspecto da construo e

implementao de um sistema de software: no pode haver vazios ou brancos.

2.2 Padres de Software e Linguagens de Padres 9

Diferentemente de catlogos ou colees de padres, uma linguagem de padres inclui regras

e diretrizes que explicam como e quando aplicar seus padres para resolver um problema que,

geralmente, um padro no resolver sozinho. Uma linguagem de padres uma forma de sub-

dividir um problema geral e sua soluo complexa em um nmero de problemas relacionados e

suas respectivas solues. Cada padro da linguagem resolve um problema especfico no contexto

comum compartilhado pela linguagem (Appleton, 1997; Schmidt et al., 1996). importante notar

que cada padro pode ser usado separadamente ou com um certo nmero de padres da linguagem.

Isso significa que um nico padro considerado til mesmo se a linguagem no for usada em sua

plenitude.

2.2.4 Exemplos de Linguagens de Padres

Aarsten et al. (1995) propuseram uma linguagem de padres para manufatura integrada ao com-

putador denominada G++. O problema abordado por essa linguagem o projeto de sistemas de

informao concorrentes e provavelmente distribudos, com aplicaes na manufatura integrada

ao computador. O objetivo do trabalho aumentar o reuso de projeto orientado a objetos desde o

nvel de componentes at o nvel arquitetural, oferecendo um modelo conceitual para arquiteturas

concorrentes e distribudas.

Cunningham (1995) apresenta uma linguagem de padres chamada The CHECKS Pattern

Language of Information Integrity, que mostra como fazer checagem nas entradas de dados para

separar dados invlidos de dados vlidos e assegurar que o menor nmero possvel de dados invli-

dos seja registrado. O objetivo fazer essa checagem sem complicar os programas e comprometer

a flexibilidade futura.

Kerth (1995) prope uma linguagem de padres chamada Caterpillars Fate: A Pattern Lan-

guage for Transformation from Analysis to Design. Ela usada para apoiar a transformao dos

documentos de anlise em um projeto inicial de software. O nome da linguagem (destino da la-

garta) vem da analogia que feita entre a transio da anlise para o projeto com a lagarta que se

transforma em uma borboleta. A linguagem tenta captar a experincia adquirida durante o desen-

volvimento de solues de projeto a partir de modelos de anlise, documentando o que deve ser

feito durante a transio.

Tambm existem vrias outras linguagens de padres como, por exemplo, A Pattern Language

for Tool Construction and Integration Based on the Tools and Materials Metaphor (Riehle e Zul-

lighoven, 1995), EPISODES: A Pattern Language of Competitive Development (Cunningham,

1996), Evolving Frameworks - A Pattern Language for developing object-oriented frameworks

(Roberts e Johnson, 1998), A Pattern Language for Pattern Writing (Meszaros, 1998), A Pattern

Language for Developing Form Style Windows (Bradac e Fletcher, 1998), A Pattern Language

of Transport Systems (Point and Route) (Zhao e Foster, 1998). Pode-se notar que essas lingua-

2.2 Padres de Software e Linguagens de Padres 10

gens de padres possuem diferentes nveis de abstrao e esto distribudas segundo as vrias

classificaes apresentadas na Seo 2.2.2.

2.2.5 A Linguagem de Padres para Gesto de Recursos de Negcio

A Linguagem de Padres para Gesto de Recursos de Negcios (Gesto de REcursos de Negcio)

o resultado de uma evoluo de mais de dez anos de prtica no desenvolvimento de sistemas para

pequenas e mdias empresas no domnio de gesto de recursos de negcios (Braga et al., 1998,

1999). formada por quinze padres de anlise, alguns dos quais so aplicaes ou extenses de

padres recorrentes propostos na literatura. Ela oferece a desenvolvedores inexperientes material

substancial para desenvolvimento de novos sistemas, juntamente com solues alternativas, quan-

do necessrio. A linguagem de padres foi concebida para auxiliar os engenheiros de software

a desenvolver aplicaes que lidem com gesto de recursos de negcios, ou seja, nas quais seja

necessrio registrar transaes de aluguel, comrcio ou manuteno de recursos. Uma transao

um evento relevante que deve ser lembrado ao longo do tempo (Coad et al., 1997). O aluguel de

recursos enfoca principalmente a utilizao temporria de um bem ou servio, como por exemplo

uma fita de vdeo ou o tempo de um especialista. O comrcio de recursos enfoca a transferncia

de propriedade de um bem, como por exemplo uma venda ou leilo de produtos. A manuteno de

recursos enfoca a manuteno de um determinado produto, utilizando mo-de-obra e peas para

execuo, como o exemplo de uma oficina de reparo de eletrodomsticos. A Figura 2.1 contm

um diagrama que mostra as dependncias entre os padres da Linguagem de Padres GRN e a

ordem na qual eles so geralmente aplicados. Essas dependncias so tambm apresentadas e,

eventualmente, complementadas, em um elemento especfico de cada padro, o elemento Prxi-

mos Padres. Os principais padres da linguagem so indicados por uma linha mais espessa. So

eles: LOCAR O RECURSO, COMERCIALIZAR O RECURSO e MANTER O RECURSO.

Os padres esto agrupados de acordo com seu propsito, como pode ser visto na Figura 2.1.

O grupo 1 possui trs padres: IDENTIFICAR O RECURSO, QUANTIFICAR O RECURSO e ARMA-

ZENAR O RECURSO, que dizem respeito identificao e possvel qualificao, quantificao e

armazenagem dos recursos gerenciados pelo negcio. O grupo 2 contm os padres relacionados

manipulao dos recursos de negcio pelo sistema. Existem sete padres nesse grupo: LOCAR O

RECURSO, RESERVAR O RECURSO, COMERCIALIZAR O RECURSO, COTAR O RECURSO, CON-

FERIR A ENTREGA DO RECURSO, MANTER O RECURSO e COTAR A MANUTENO. O grupo

3 contm cinco padres que cuidam de detalhes das transaes efetuadas com o recurso. Os trs

primeiros, ITEMIZAR TRANSAO DO RECURSO, PAGAR PELA TRANSAO DO RECURSO e

IDENTIFICAR O EXECUTOR DA TRANSAO, so aplicveis a quaisquer das transaes do grupo

2. Os dois ltimos, IDENTIFICAR AS TAREFAS DA MANUTENO e IDENTIFICAR AS PEAS

2.2 Padres de Software e Linguagens de Padres 11

Q UANTIFICAR O R ECURSO (2)

RESERVAR O R ECURSO (5)

L OCAR O R ECURSO (4) C OMERCIALIZAR O R ECURSO (6)

C ONFERIR A E NTREGA DO R ECURSO (8)

M ANTER O R ECURSO (9)

P AGAR PELA T RANSAO DO R ECURSO (12 )

I TEMIZAR T RANSAO DO R ECURSO (11)

I DENTICAR O E XECUTOR DA T RANSAO (13)

C OTAR O R ECURSO (7)

C OTAR A MANUTENO (10)

I DENTIFICAR AS T AREFAS DA M ANUTENO (14)

I DENTIFICAR AS P EAS DA M ANUTENO (15)

I DENTIFICAR O R ECURSO (1)

Grupo 2 Transaes de Negcio

Grupo 1 Identificao do Recurso de Negcio

Grupo 3 Detalhes da

Transao de Negcio

A RMAZENAR O R ECURSO (3)

Figura 2.1: Linguagem de Padres para Gesto de Recursos de Negcios.

DA MANUTENO, so aplicveis s transaes contidas nos padres MANTER O RECURSO e

COTAR A MANUTENO.

A Figura 2.2 apresenta parte do padro QUANTIFICAR O RECURSO extrado da Linguagem de

Padres GRN. Pode-se observar que esse padro possui quatro alternativas de soluo, dependendo

de como o recurso do negcio quantificado. Esse padro faz parte do grupo 1, mencionado

anteriormente.

O resultado da utilizao da Linguagem de Padres GRN o diagrama de classes para uma

aplicao especfica, composto de classes, relacionamentos, atributos e mtodos. Esse diagrama

pode ser utilizado como documento de anlise, podendo ser refinado na etapa subseqente de

projeto do sistema.

2.3 Frameworks 12

Padro 2: Quantificar o Recurso Contexto

Voc identificou o recurso gerenciado por sua aplicao e suas qualidades relevantes. Uma questo importante a ser considerada agora a forma de quantificao do recurso. Existem certas aplicaes nas quais necessrio ter controle sobre instncias especficas do recurso, porque elas so negociadas individualmente. Por exemplo, em uma biblioteca um livro pode possuir diversas cpias, cada qual emprestada a um leitor diferente. Outras aplicaes lidam com uma certa quantidade do recurso ou com lotes de recursos. Em tais aplicaes, no necessrio saber que instncia particular do recurso foi negociada. Por exemplo, uma certa quantidade de ao foi vendida. Em outras aplicaes, o recurso nico, como por exemplo um carro que sofre manuteno ou um mdico que examina um paciente.

Problema

Como a aplicao quantifica o recurso de negcio?

Influncias muito importante saber, j na fase de

anlise do sistema, exatamente qual a forma de quantificao do recurso adotada. Uma deciso errada nesse ponto pode comprometer a evoluo futura.

Se necessrio controlar instncias especficas do recurso, ento informaes redundantes podem ser armazenadas para as diversas instncias do mesmo recurso. Porm, essa redundncia indesejvel.

Para evitar redundncia, uma nova classe pode ser criada, na qual as informaes comuns a todas as instncias do mesmo recurso podem ser armazenadas apenas uma vez. Mas um preo tem que ser pago por lidar com duas classes ao invs de uma: por exemplo, o tempo de processamento ser provavelmente maior.

Estrutura

...

Figura 4: Sub-padro Recurso Instancivel

Figura 5: Sub-padro Recurso Mensurvel

Figura 6: Sub-padro Recurso Simples

Figura 7: Sub-padro Recurso em Lotes

Participantes ...

Exemplo ...

Prximos Padres ...

Recurso codigoId descrio calcular qtd. instancias disponveis

Instncia do Recursonumero localizao status estDisponvel

tem

1 *

Recurso codigoId descrio quantidade em estoque nvel de reabastecimento !*lista de recursos a serem reabastecidos

Unidade de Medida codigoId descrio

tem

* 1

Recurso codigoId descrio status

Recurso codigoId descrio quantidade em estoque nvel de reabastecimento calcular quantidade disponvel!*lista de recursos a ser reabastecidos

Lote do Recursos codigoId data quantidade em estoque

tem

1 *

Unidade de Medida codigoId descrio

tem *

1

Figura 2.2: Exemplo de um Padro da Linguagem de Padres GRN.

2.3 Frameworks

No incio da dcada de 1980, paralelamente s bibliotecas de classes, comearam a ser construdos

frameworks de aplicao, que acrescentam s bibliotecas de classes os relacionamentos e intera-

es entre as diversas classes que compem o framework. Essas classes podem fazer parte de uma

biblioteca de classes ou podem ser especficas da aplicao. Frameworks possibilitam reutilizar

no somente componentes isolados, mas tambm toda a arquitetura de um domnio especfico. Se-

gundo Fayad e Schmidt (1997) as caractersticas de um framework que proporcionam benefcios

aos desenvolvedores so:

modularidade: melhoram a modularidade por encapsular os detalhes da implementao vi-

svel apenas pela interface. Melhoram a qualidade do software por localizar o impacto das

alteraes tanto no projeto como na implementao, reduzindo o esforo de manuteno;

2.3 Frameworks 13

reusabilidade: as interfaces proporcionam aos frameworks aumento de reusabilidade por

definir componentes genricos que podem ser reutilizados para criar novas aplicaes;

extensibilidade: proporciona extensibilidade devido aos mtodos adaptveis (hook methods)

que permitem a extenso das interfaces; e

inverso de controle: os mtodos definidos pelo usurio para especializar o framework so

chamados dentro do prprio framework, ao invs de serem chamados do cdigo de aplicao

do usurio. O framework geralmente faz o papel de programa principal, coordenando e

seqenciando as atividades da aplicao.

Um framework reusa anlise, projeto e cdigo. Ele reusa anlise porque descreve os tipos de

objetos importantes e como um problema maior pode ser dividido em problemas menores. Ele

reusa projeto porque contm algoritmos abstratos e descreve a interface que o programador deve

implementar e as restries a serem satisfeitas pela implementao. Ele reusa cdigo porque torna

mais fcil desenvolver uma biblioteca de componentes compatveis e porque a implementao de

novos componentes pode herdar grande parte de seu cdigo das super-classes abstratas. Apesar

de todos esses tipos de reuso serem importantes, os reusos de anlise e de projeto so os que mais

compensam a longo prazo (Johnson, 1997; Johnson e Russo, 1991).

2.3.1 Classificao dos Frameworks

Os frameworks podem ser classificados, segundo seu escopo, em trs grupos (Fayad e Schmidt,

1997; Fayad et al., 1999): frameworks de infra-estrutura do sistema, frameworks de integrao

middleware e frameworks de aplicao.

Os frameworks de infra-estrutura do sistema simplificam o desenvolvimento da infra-estrutura

de sistemas portveis e eficientes, como por exemplo, sistemas operacionais, sistemas de comu-

nicao, interfaces com o usurio e ferramentas de processamento de linguagem. Em geral so

usados internamente em uma organizao de software e no so vendidos diretamente a clientes.

Os frameworks de integrao middleware so usados, em geral, para integrar aplicaes e com-

ponentes distribudos. Eles so projetados para melhorar a habilidade de desenvolvedores em

modularizar, reutilizar e estender sua infra-estrutura de software para funcionar em um ambiente

distribudo.

Os frameworks de aplicao esto voltados para domnios de aplicao mais amplos e so

a pedra fundamental para atividades de negcios das empresas, como por exemplo sistemas de

telecomunicaes, aviao, manufatura e engenharia financeira. Frameworks dessa classe so mais

caros para desenvolver ou comprar, mas podem dar um retorno substancial do investimento, j que

permitem o desenvolvimento de aplicaes e de produtos diretamente (Fayad et al., 1999; Fayad e

Johnson, 2000).

2.3 Frameworks 14

2.3.2 Frameworks Caixa Branca e Frameworks Caixa Preta

Desconsiderando o escopo dos frameworks, eles tambm podem ser classificados pelas tcnicas

utilizadas para estend-los, que permitem estender continuamente de um framework caixa branca

at um framework caixa preta (Fayad e Schmidt, 1997; Johnson e Foote, 1998). O comporta-

mento especfico de um framework de aplicao geralmente definido adicionando-se mtodos s

subclasses de uma ou mais de suas classes.

No framework caixa branca o reuso provido por herana, ou seja, o usurio deve criar subclas-

ses das classes abstratas contidas no framework para criar aplicaes especficas. Para tal, ele deve

entender detalhes de como o framework funciona para poder us-lo. As aplicaes instanciadas

freqentemente requerem a criao de muitas subclasses novas, dificultando a aprendizagem do

projeto da aplicao. Dessa forma, aprender a us-lo o mesmo que aprender a como construi-lo

(Johnson e Foote, 1998). J no framework caixa preta o reuso por composio, ou seja, o usu-

rio combina diversas classes concretas existentes no framework para obter a aplicao desejada.

Assim, ele deve entender apenas a interface para poder us-lo.

Um aspecto varivel de um domnio de aplicao chamado de ponto de especializao ou

ponto varivel ou parte varivel (Buschmann et al., 1996). Diferentes aplicaes dentro de um

mesmo domnio so distinguidas por um ou mais pontos variveis. Os pontos variveis so proje-

tados para serem genricos, podendo ser adaptados s necessidades da aplicao. Pontos Fixos ou

partes fixas definem a arquitetura geral de um sistema de software (seus componentes bsicos e os

relacionamentos entre eles). Os pontos fixos permanecem sem mudar em todas as instanciaes

do framework de aplicao.

Resumindo, um framework caixa branca mais fcil de projetar, pois no h necessidade de

prever todas as alternativas de implementao possveis. J o framework caixa preta mais difcil

de projetar por haver a necessidade de fazer essa previso. Em contrapartida, o framework caixa

preta mais fcil de usar, pois basta escolher a implementao desejada, enquanto no caixa branca

necessrio completar a implementao.

Frameworks caixa branca podem evoluir para se tornar cada vez mais caixa preta (Johnson,

1997). Isso pode ser conseguido de forma gradativa, implementando-se vrias alternativas que de-

pois so aproveitadas em instanciaes do framework. Ao mesmo tempo no se fecha totalmente o

framework, permitindo ao usurio continuar usando-o como caixa branca. Aps um certo tempo,

estaro disponveis diversas alternativas e ento pode-se decidir tornar o framework caixa preta de

fato. Pode-se tambm construir ferramentas de apoio que ajudem a especificar as aplicaes. Es-

sas ferramentas tm como objetivo facilitar a instanciao do framework, usando-se componentes

visuais que facilitam o trabalho do usurio.

2.3 Frameworks 15

2.3.3 Documentao de Frameworks

Um framework um projeto reusvel de um programa ou parte de um programa que expresso

como um conjunto de classes. Frameworks so projetos reusveis e no apenas cdigo, so mais

complexos de desenvolver do que softwares, tornando sua documentao mais difcil.

A documentao de um framework deve atender a diversos requisitos. Estes requisitos podem

ser alcanados estruturando a documentao como um conjunto de padres ou uma linguagem de

padres. O principal propsito desse conjunto de padres mostrar como utilizar um framework,

no apenas mostrar como ele funciona. Padres podem descrever o propsito de um framework,

podem permitir a programadores utilizar um framework sem ter a necessidade de conhecer os

detalhes de seu funcionamento e podem mostrar muitos detalhes de projeto que esto incorporados

em um framework.

Geralmente a documentao dos frameworks descreve primeiramente como um framework

trabalha e em seguida como utiliz-lo. No entanto, no possvel entender completamente um

framework at que ele tenha sido usado efetivamente. Exemplos so um bom modo de comprovar

se a utilizao foi ou no entendida corretamente pelo usurio, alm de tornar os frameworks mais

completos e facilitarem o entendimento do fluxo de controle (Johnson, 1992).

Padres podem ser empregados tanto para projeto de um framework como documentao de um

framework, pois possuem um certo relacionamento (Brugali e Sycara, 2000; Johnson, 1992, 1997).

Um framework engloba diversos padres, podendo ser visualizado como a implementao de um

sistema ou linguagem de padres. Apesar de serem relacionados dessa maneira, importante

reconhecer que frameworks e padres de projeto so elementos distintos.

2.3.4 Exemplos de Frameworks

A maioria dos frameworks existentes aplica-se a domnios tcnicos (ou bsicos), tais como in-

terfaces com o usurio ou distribuio, como por exemplo os frameworks MacApp, especficos

para aplicaes Macintosh, o Lisa Toolkit, o Interviews e o Smalltalk Model-View-Controller. O

Model-View-Controller foi o primeiro framework amplamente utilizado. Foi inicialmente imple-

mentado em Smalltalk-80, mas atualmente conta com implementaes em todas as verses existen-

tes de Smalltalk, como o VisualWorks, VisualAge, Dolphin, Squeak, etc. O MVC (Model-View-

Controller) usado pelo Smalltalk como interface com o usurio, tendo mostrado a adequao da

orientao a objetos para implementao de interfaces grficas com o usurio. Outro exemplo o

HotDraw, que um framework grfico bidimensional para editores de desenho estruturado, escrito

no VisualWorks Smalltalk. Ele tem sido usado para criar diversos editores diferentes. Pode-se

facilmente criar novas figuras e ferramentas especiais de manipulao para seus desenhos.

2.3 Frameworks 16

Muitos frameworks de aplicao no so de domnio pblico. Exemplos so o ET++, ACE, Mi-

crosoft Foundation Classes (MFC) e DCOM, JavaSofts RMI, implementaes do OMG CORBA

e o IBM San Franciso. O IBM San Francisco um framework de aplicao para domnios espec-

ficos de negcio. Seu propsito ajudar a criar aplicaes de negcio que sejam apropriadas para

uma grande variedade de aplicaes nesse domnio. Ele utiliza padres de projeto para gerenciar

e organizar sua documentao, alm de se beneficiar das caractersticas que os padres proporcio-

nam (Carey et al., 2000). O San Francisco apia aplicaes de gerenciamento de armazenamento,

gerenciamento de pedido, livro razo, contas a pagar, contas a receber etc.

2.3.5 O Framework para Gesto de Recursos de Negcio

Com base na Linguagem de Padres GRN (detalhes na Seo 2.2.5), foi construdo o Framework

GREN (Gesto de REcursos de Negcios) (Braga e Masiero, 2002b). O Framework GREN permite

criar aplicaes no domnio de sistemas de gesto de recursos de negcios. Foi implementado com

a linguagem Smalltalk, mais especificamente o ambiente VisualWorks Non-Commercial 5i.31. A

base de dados (relacional) utilizada na persistncia dos objetos a MySQL2. A Figura 2.3 mostra

a arquitetura do Framework GREN. A camada de persistncia possui trs classes para cuidar da

conexo com a base de dados, gerenciamento dos identificadores dos objetos e persistncia dos

objetos. A camada de aplicao comunica-se com a camada de persistncia sempre que precisa

persistir um objeto. Dentro da camada de aplicao existem diversas categorias como a GREN-

Application, que contm as classes derivadas diretamente dos padres de anlise que compem

a Linguagem de Padres GRN; a GREN-Wizard, que contm as classes que implementam o ins-

tanciador do GREN; e a GREN-Report Writer, que contm as classes especficas para impresso

de relatrios. As aplicaes especficas construdas a partir do GREN situam-se numa camada

mais externa, pois podem fazer uso de todas as camadas mais internas. A camada de interface

com o usurio contm todas as classes relacionadas a formulrios de interface, janelas e menus.

Comunica-se com a camada de aplicao para obteno de objetos a serem mostrados na interfa-

ce com o usurio e para devolver informaes a serem processadas pelos mtodos da camada de

aplicao.

Uma caracterstica marcante das aplicaes geradas a partir do Framework GREN sua in-

terface com o usurio, que foi elaborada de maneira convencional, ou seja, para ser executada

em micro-computadores com Windows 98 (ou superior) que possuam instalado o software Vi-

sualWorks. Portanto, no pode ser executada em navegadores do tipo Netscape ou Explorer. A

interface atual supe que o usurio do sistema um funcionrio da empresa, que tem acesso

1VisualWorks NonCommercial, Release 5i.3, 1999 Copyright Cincom Systems, Inc. disponvel na URL: http://www.cincom.com.

2MySQL Database, Release 3.23.25-beta, Copyright MySQL disponvel na URL: http://www.mysql.com.

http://www.cincom.comhttp://www.cincom.comhttp://www.mysql.com

2.4 Sistemas de Informao baseados na Web 17

Aplicaes Especficas

GREN - Camada de InterfaceGrfica com o Usurio GREN - Wizard

GREN - Camada de Aplicao

GREN - Camada de Persistncia

MySQL Smalltalk

Figura 2.3: Arquitetura do Framework GREN.

base de dados e pode efetuar quaisquer operaes disponveis. Est prevista uma segunda verso

do Framework GREN na qual haver diferentes usurios, com senhas especiais, que podero exe-

cutar apenas algumas operaes, de acordo com diferentes nveis de permisso cadastrados pelo

supervisor do sistema.

A criao das aplicaes por meio do framework guiada pela aplicao da Linguagem de Pa-

dres GRN. Aps a aplicao da linguagem de padres so obtidos diagramas de classes da apli-

cao desejada. Com base nesses diagramas utilizam-se classes pr-programadas do Framework

GREN para criar o cdigo da nova aplicao.

2.4 Sistemas de Informao baseados na Web

A Web transformou-se em poucos anos de apenas um modo de fazer propaganda para uma plata-

forma que pode apoiar grande parte do trabalho organizacional. Como resultado, so crescentes os

esforos para que sistemas de informao possam explorar os benefcios dessa plataforma, condu-

zindo assim ao desenvolvimento de sistemas de informao baseados na Web, os WIS (Web-based

Information Systems). Estes sistemas se tornaro mais comuns e usados que os sistemas clien-

te/servidor existentes e causaro grande impacto na economia e na vida das pessoas, pelo fato de

que a Web possui um maior potencial de alcance de audincia do que os sistemas cliente/servidor

baseados em redes de propriedade privada. Pode-se identificar quatro tipos gerais de sistemas

baseados na Web:

Intranet: apiam o trabalho interno de uma empresa;

sites de presena na Web: sites que so ferramentas de propaganda para conseguir aumentar

o nmero de consumidores;

2.5 Leiles Virtuais 18

Extranets: uma mistura de sistemas externos e internos que apiam a comunicao empresa-

empresa; e

comrcio eletrnico: sistemas que apiam as negociaes com o consumidor.

Existe uma diferena clara entre um conjunto de pginas na Web e os SIbWebs. Os SIbWebs

apiam o trabalho e, usualmente, so fortemente integrados com sistemas que no so baseados na

Web como, por exemplo, base de dados e sistemas de processamento de transao.

As aplicaes tradicionais cliente/servidor normalmente utilizam a arquitetura fat client, j as

aplicaes para a Web que implementam processos de negcios geralmente requerem a arquitetura

thin client, para no sobrecarregar a mquina cliente, para permitir que no seja necessrio mais

do que um navegador para sua execuo e para no exigir que os navegadores possuam recursos

especficos, como plug-ins, para a utilizao da aplicao.

SIbWebs tambm so diferentes de sistemas de informao tradicionais, pois atingem um maior

nmero de usurios e necessitam de novas abordagens para projeto e desenvolvimento. Essas

diferenas introduzem um maior desafio gerencial e tcnico.

2.5 Leiles Virtuais

Um dos tipos de comrcio eletrnico existentes na Web a intermediao, que so mercados

caracterizados por trazerem at si compradores e vendedores e assim facilitarem as transaes

entre eles. Dentre os vrios tipos de negcios existentes na Web, os leiles virtuais vm crescendo

e movimentando uma considervel soma financeira. As vantagens so significativas tanto para

compradores como para vendedores. Economias so feitas pela reduo dos custos de transao,

aumento do crculo potencial de consumidores, bem como melhoria da capacidade de procurar e

encontrar de todas as partes interessadas (Heck e Vervest, 1998).

Os leiles virtuais so basicamente processos de comercializao quando outros procedimentos

de comercializao no tm sucesso ou um processo de determinao de preo torna-se necessrio.

Do ponto de vista econmico existem dois principais motivos para utilizao de leiles (Engebret-

sen, 1999):

leiles so mecanismos para determinao de preo, estabelecendo um equilbrio de preos

de mercado; e

leiles so um mecanismo de distribuio de recursos, comercializam produtos que so dif-

ceis de encontrar em mercados normais devido a:

produtos com tempo de vida limitado, como passagens de avio ou flores;

2.5 Leiles Virtuais 19

produtos que esto em estoque e precisam ser comercializados separadamente de novos

lanamentos.

Da perspectiva dos compradores e vendedores existem trs diferentes pares de partes envolvi-

das na comercializao que podem ser observados em leiles virtuais (Engebretsen, 1999; Rappa,

2000):

consumidor-consumidor (C2C, do ingls consumer-to-consumer): representam nos leiles

a verso moderna dos anncios de classificados, exigindo que as duas partes estejam lo-

calizadas prximas uma da outra de forma que o custo do transporte no torne o negcio

invivel;

empresa-consumidor (B2C, do ingls business-to-consumer): podem ser identificados como

empresas que tentam comercializar estoques excedentes ou estabelecer preos para novos

produtos ou criar novos canais de venda; e

empresa-empresa (B2B, do ingls business-to-business): so usadas principalmente por em-

presas e entidades governamentais para vender contratos pblicos e bens. Leiles B2B ten-

dem a ser fechados a empresas identificadas e qualificadas como potenciais compradoras.

Os processos dos leiles so definidos por seus eventos significativos. Os lances so controla-

dos pelos participantes e a revelao do lance vencedor e o fechamento do leilo so controlados

pelo prprio leilo. Saber quando um evento ocorre pode ser to importante quanto saber o que

acontece, e por isso essencial que os leiles mantenham uma certa consistncia temporal duran-

te sua operao. A Internet tem algumas limitaes particulares quando se trata de consistncia

temporal. Portanto claro que o leilo no tem controle sobre o tempo de resposta das trans-

misses e, conseqentemente, mensagens contendo os lances e notificaes de preos podem ter

tempo arbitrrio. Alm disso, o processamento do leilo pode ser complexo, dependendo do n-

mero, tamanho e regras dos leiles, j que devem permanecer disponveis o tempo todo (Wellman

e Wurman, 1998).

2.5.1 Classificao de Leiles Virtuais

Vrios so os tipos de leiles virtuais e a Figura 2.4 apresenta como eles podem ser divididos

segundo o nmero de participantes:

leiles de venda: existe um vendedor e vrios compradores, vrios produtos so oferecidos

e os vencedores so escolhidos pela ordem de preo, quantidade e cronologia;

2.5 Leiles Virtuais 20

Figura 2.4: Utilizao de Leiles no Comrcio Eletrnico (Heck e Vervest, 1998).

leiles de compra3: um comprador declarando o interesse em algum produto necessrio e

vrios fornecedores tentando fornec-lo; e

leiles do tipo muitos para muitos: muitos fornecedores oferecendo para muitos potenciais

compradores.

Pode-se tambm classificar os leiles existentes na Internet de maneira mais detalhada para que

se possa identificar claramente o seu funcionamento segundo algumas caractersticas, tais como:

nmero de lances e ofertas de cada lado do mercado;

a forma dos lances;

o nmero de itens comprados e vendidos por transao;

as regras do leilo; e

o mecanismo de ordenao e o modo da ocorrncia da transao.

Observando-se esses atributos foi possvel desenvolver a taxonomia mostrada na Figura 2.5.

Existem vrios tipos de leilo e, segundo Kumar e Feldman (1998b), uma aplicao para leiles

virtuais deve apoiar esses vrios tipos. No entanto, possvel identificar alguns dos leiles mais

utilizados na Web e que, portanto, merecem maior ateno (Engebretsen, 1999; Wellman e Wur-

man, 1998):

3Esse tipo de leilo freqentemente chamado na Internet de leilo reverso.

2.5 Leiles Virtuais 21

Figura 2.5: Tipos de Leiles Segundo o Esquema de Reck (Reck, 1994).

leilo ingls: um dos formatos mais comuns de leilo, tambm conhecido como leilo de

lance aberto ou leilo de preo ascendente. A princpio no possui limite de tempo, e o

leiloeiro inicia pelo preo de reserva4, continuando enquanto os lances forem dados. Os

concorrentes so freqentemente annimos, interagindo principalmente por meio eletrnico;

leilo holands: possui limite de tempo e conhecido tambm como leilo de preo descen-

dente. O preo inicial extremamente alto e, em intervalos predefinidos, o preo decresce

em pequenos montantes at que algum comprador interessado arremate o produto. Quando

existirem vrios itens do mesmo produto a serem leiloados, diferentes consumidores podem

4Preo mnimo preestabelecido pelo leiloeiro ou pelo proprietrio do bem que est sendo leiloado.

2.5 Leiles Virtuais 22

arremat-los por diferentes valores. Esse tipo de leilo mais indicado para itens perecveis,

por exemplo, flores;

leilo de preo oculto e primeiro lance: esse tipo de leilo dividido em duas fases: os lances

e a resoluo. Durante a primeira fase os lances so coletados secretamente. Posteriormente,

na segunda fase, so abertos, e o vencedor determinado. Os lances so organizados do

valor mais alto para o valor mais baixo e dessa forma, se apenas um item for leiloado o lance

mais alto o vencedor. Caso existam vrios itens a serem leiloados eles so distribudos pela

ordem de lances. Esse tipo de leilo conhecido como leilo de preo oculto discriminatrio;

e

leilo Vickrey: Semelhante ao leilo de preo oculto e primeiro lance. Difere apenas no fato

de que quem ofereceu o lance mais alto vencedor, porm no paga o valor oferecido no

lance mais alto, e sim o do segundo lance mais alto.

Apesar de existirem todos esses tipos de leilo, usualmente na Internet os tipos de leiles

so adaptados s necessidades impostas pela classe de usurios, por deciso de negcio, ou pelas

prprias implicaes da Web. Alguns dos detalhes que podem variar dos tipos apresentados so

(Kumar e Feldman, 1998a):

anonimato das partes interessadas;

restries quanto ao montante do lance, de forma que os lances somente podem ser ofereci-

dos com a soma de incrementos predefinidos baseados no valor de reserva do produto, assim

torna-se proporcional ao montante total do item que est sendo leiloado;

regras de fechamento do leilo;

regras de avaliao e desempate de lances; e

servios fornecidos para vendedores e compradores, tais como: certificao de qualidade do

produto, coleta de pagamento e remessa do bem leiloado.

Independentemente do tipo de leilo virtual, algumas atividades bsicas podem ser observadas

na quase totalidade das formas de leiles virtuais (Kumar e Feldman, 1998b):

registro inicial do comprador e do vendedor;

configurao dos eventos de um leilo particular;

programao e anncio;

os lances;

avaliao dos lances e fechamento do leilo; e

determinao da venda.

2.5 Leiles Virtuais 23

2.5.2 Aspectos de Segurana

A Internet implica em adotar polticas de segurana que so indispensveis para o comrcio eletr-

nico. Mecanismos de segurana baseados em mtodos de criptografia e auditorias so necessrios

como preveno contra sabotagem de hackers, ou compradores e vendedores que tentem fraudar

ou interromper os leiles. Mecanismos eficientes de notificao dos ltimos lances para os parti-

cipantes so indispensveis.

A poltica do leilo, juntamente com as instrues do vendedor, ditam se um leilo ampla-

mente acessvel ao pblico, ou somente a compradores/vendedores registrados, ou ainda apenas a

compradores registrados para participar de um leilo especfico. Mecanismos de controle de aces-

so so necessrios para reforar as regras de funcionamento do leilo. Mecanismos de segurana

so necessrios para garantir que o anncio do leilo e as regras no sejam sabotadas por invasores.

Essa preveno inclui postagens no autorizadas e alteraes, bem como preveno de ataques aos

servios disponveis (Kumar e Feldman, 1998b).

2.5.3 Exemplos de Leiles Virtuais

Atualmente existem vrios sistemas de leiles virtuais em funcionamento na Web. Esses leiles

podem ser encontrados por qualquer engenho de busca ou em sites que possuem listas especficas

com endereos de sistemas desse tipo. Alguns exemplos so encontrados em:

http://br.cade.dir.yahoo.com/compras_e_servicos/Leiloes;

http://www.aonde.com/indicacao/compras/15012.htm; e

http://www.internetauctionlist.com.

Os sites citados possuem o endereo de vrios sistemas de leiles virtuais cujo foco vai desde

a prestao de servios de leiles para empresas de equipamentos eletrnicos at leiles de gado.

Como exemplo pode-se citar o sistema do site SuperBid (http://www.leilao.superbid.

com.br), o sistema do site Nosso Leilo (http://www.nossoleilao.com.br) e o siste-

ma do site BanLeilo (http://www.banleilao.com.br). O SuperBid um site de leiles

virtuais leiles pblicos oficiais que presta servio para empresas em geral (Banco HSBC, Mo-

torola, Compaq e Natura, entre outros), avaliando e comercializando, segundo consta no prprio

site da empresa, ativos industriais, excedente de inventrio e resduos, isto , imveis, autom-

veis, peas de veculos para servios pesados e equipamentos eletrnicos, entre outros. Esse site

fornece apoio para essas empresas comercializarem os bens tanto para pessoas fsicas como jurdi-

cas, que devem ser identificadas previamente pois so leiles pblicos oficiais. Portanto, esse leilo

classificado como um comrcio eletrnico do tipo empresa-consumidor e empresa-empresa.

http://br.cade.dir.yahoo.com/compras_e_servicos/Leiloeshttp://www.aonde.com/indicacao/compras/15012.htmhttp://www.internetauctionlist.comhttp://www.leilao.superbid.com.brhttp://www.leilao.superbid.com.brhttp://www.nossoleilao.com.brhttp://www.banleilao.com.br

2.6 Consideraes Finais 24

O site Nosso Leilo tambm presta servios para bancos e seguradoras para comercializao de

imveis, veculos mquinas e equipamentos, de forma semelhante ao SuperBid. O BanLeilo um

leilo especfico para agrongocios, especialmente a agropecuria. Nesse site so comercializados

touros reprodutores, bezerros, vacas matrizes e doses de smen provenientes de criadores e fazen-

das reconhecidas. Obviamente, esse sistema de leiles possui detalhes especficos sua atividade

de negcio, assim como o SuperBid e o Nosso Leilo.

Outros sistemas de leiles, no to especficos como o BanLeilo, podem ser utilizados por um

pblico maior na internet. So leiles do tipo consumidor-consumidor, no qual so comerciali-

zados itens pessoais, como cds, livros e itens de coleo. Qualquer tipo de produto, usado ou no,

pode ser encontrado nesses sites de leiles virtuais. No Brasil, o primeiro sistema de leiles virtu-

ais a entrar em funcionamento foi o Arremate.com (http://www.arremate.com), mas logo

em seguida outras empresas disponibilizaram seus servios para o pblico interessado nesse tipo

de comercializao, como por exemplo, o iBazar (http://www.ibazar.com.br), o Lokau

(http://www.lokau.com), o Mercado Livre (http://www.mercadolivre.com.br)

e o Yahoo Leiles (http://br.auctions.yahoo.com). Esses sistemas de leiles tm ba-

sicamente as mesmas funes, no apresentando grandes diferenas em sua funcionalidade.

Semelhantes a esses sistemas brasileiros, os sites americanos eBay (http://www.ebay.

com) e o Yahoo Shopping Auctions (http://auctions.shopping.yahoo.com/) possu-

em sistemas de leiles virtuais direcionados para o mesmo tipo de pblico alvo, sendo o eBay um

dos sites mais conhecidos e utilizados do mundo.

O leilo reverso um tipo peculiar de leilo no qual os clientes declaram o interesse por um

produto ou servio e vrios fornecedores oferecem lances, que visam a atender s necessidades do

cliente por um certo preo. Dessa forma, so os fornecedores que competem para poder vender

seus bens. Alguns exemplos desse tipo de leilo, todos do tipo empresa-empresa, so o australiano

LowestBid (http://www.lowestbid.com.au/), o americano Commonwealth of Kentucky

Division of Purchases (http://purch.state.ky.us) e o brasileiro Bolsa Eletrnica de

Compras do Governo do Estado de So Paulo (http://www.bec.sp.gov.br/).

2.6 Consideraes Finais

Mostrou-se nesse captulo de reviso bibliogrfica o relacionamento prximo entre as linguagens

de padres e os frameworks, bem como os benefcios por eles proporcionados no desenvolvimen-

to de sistemas de informao tradicionais. Ainda neste captulo, foram discutidos os SIbWebs,

especialmente um tipo especfico desses sistemas, os leiles virtuais. Visando a oferecer ao pro-

cesso de desenvolvimento de SIbWebs os mesmos benefcios proporcionados por linguagens de

padres e frameworks no desenvolvimento de sistemas de informao tradicionais, torna-se rele-

http://www.arremate.comhttp://www.ibazar.com.brhttp://www.lokau.comhttp://www.mercadolivre.com.brhttp://br.auctions.yahoo.comhttp://www.ebay.comhttp://www.ebay.comhttp://auctions.shopping.yahoo.com/http://www.lowestbid.com.au/http://purch.state.ky.ushttp://www.bec.sp.gov.br/

2.6 Consideraes Finais 25

vante pesquisar solues que apiem a criao e aplicao de linguagens de padres e frameworks

no desenvolvimento de SIbWebs. A reviso bibliogrfica, por outro lado, permitiu constatar a au-

sncia de propostas de linguagens de padres para o domnio dos sistemas de leiles virtuais na

Web e de frameworks para apoiar o desenvolvimento desse tipo de sistema.

Nos prximos captulos apresentado um processo genrico para redesenvolvimento de

SIbWebs. Esse processo composto por trs subprocessos interdependentes: um processo de

engenharia reversa para elicitao dos requisitos, um processo de criao de uma linguagem de

padres e um processo de desenvolvimento e instanciao de frameworks baseado em uma lingua-

gem de padres. Este ltimo subprocesso baseado na proposta de Braga e Masiero (2002b). O

processo ilustrado com o desenvolvimento de uma linguagem de padres e um framework para

o domnio dos sistemas de gesto de leiles virtuais na Web.

CAPTULO

3O Subprocesso de Criao de um

Modelo do Domnio da Aplicao para

Sistemas de Informao Baseados na

Web

3.1 Consideraes Iniciais

O modelo do domnio de uma aplicao pode ser constitudo de vrios elementos, como casos

de uso, diagramas de classe, diagramas de estado, etc. Neste trabalho usa-se uma linguagem de

padres para modelar o domnio. Este captulo apresenta o processo geral de desenvolvimento de

uma linguagem de padres a partir de um modelo de classes do domnio e como essa linguagem

pode ser usada para criar modelos de anlise que possibilitam implementar sistemas baseados na

Web. O processo geral toma como entrada pelo menos trs sistemas do domnio, chamados de

sistemas-base. Um processo de engenharia reversa baseada na interface Web conduzido para

esses sistemas-base, visando a produzir a especificao de requisitos e, por intermdio dessa es-

pecificao, criar um modelo de classes do domnio. Neste captulo apresenta-se, ainda, como

o processo de desenvolvimento de uma linguagem de padres tomando como base um modelo de

classes do domnio, exemplificando esse processo por meio da Linguagem de Padres para Leiles

Virtuais (Linguagem de Padres LV) e um exemplo de sua utilizao.

26

3.2 O Processo de Modelagem do Domnio Proposto: Contextualizao 27

Apresenta-se na Seo 3.2 a contextualizao do processo proposto neste captulo para o desen-

volvimento de sistemas de informao baseados na Web, o qual constitudo por um subprocesso

de criao de um modelo do domnio da aplicao de SIbWebs, apresentado na Seo 3.3, e pelo

subprocesso de criao da linguagem de padres a partir do modelo de classes do domnio presente

na Seo 3.4. Na Seo 3.5 apresentada em detalhes a Linguagem de Padres LV. Na Seo 3.6

apresenta-se um exemplo do uso da Linguagem de Padres LV em um sistema de leiles virtuais

existente na Web.

3.2 O Processo de Modelagem do Domnio Proposto:

Contextualizao

O objetivo final deste trabalho a proposio de um processo que facilite o desenvolvimento

de frameworks orientados a objetos para o domnio dos Sistemas de Informao baseados na Web.

Como objetivo do trabalho quer-se usar o processo proposto por Braga e Masiero (2002b), em que

isso feito usando-se como passo intermedirio uma linguagem de padres de um subdomnio

especfico dos SIbWebs. No caso deste trabalho o subdomnio escolhido foi o de leiles virtuais.

Esses autores mostram que o uso de uma linguagem de padres facilita o desenvolvimento do fra-

mework e tambm a instanciao de aplicaes, agindo como um elemento integrador e como uma

alternativa de modelagem de domnio. Alm disso, o subdomnio escolhido, de leiles virtuais,

complementa a linguagem de padres criada por Braga et al. (1999) e o framework correspondente

pode ser integrado ao framework desenvolvido por Braga e Masiero (2000).

Esse processo possui trs grandes fases: na primeira deve-se criar um modelo de classes genri-

co do domnio de aplicaes, na segunda cria-se a linguagem de padres e na terceira desenvolve-se

o framework. As duas primeira fases so apresentadas neste captulo e a terceira apresentada no

Captulo 4. A primeira fase baseia-se fortemente na engenharia reversa de aplicaes do subdom-

nio escolhido1. No difcil encontrar aplicaes do domnio para usar como base da engenharia

reversa, j que o subdomnio de SIbWebs. Esse processo de engenharia reversa fortemente ba-

seado na interface do sistema disponvel na Web, mas pode contar com o apoio de outras tcnicas,

como a anlise de documentos relativos ao domnio (livros, artigos, etc) e conhecimento prprio

do domnio. possvel tambm definir os requisitos do sistema usando mtodos tradicionais de

anlise de sistemas. A segunda fase envolve a criao de uma linguagem de padres para repre-

sentar o subdomnio escolhido, a partir do modelo de classes genrico criado na fase anterior. As

duas primeiras fases so propostas originais desta dissertao. As duas fases seguintes, de desen-

volvimento do framework e de instanciao de aplicaes do subdomnio, seguem a proposta de

1Quando no houver necessidade de diferenciar a hierarquia, os termos domnio e subdomnio sero usados comosinnimos.

3.2 O Processo de Modelagem do Domnio Proposto: Contextualizao 28

Braga e Masiero (2002a,b), com adaptaes para o domnio de SIbWebs. Esse processo geral

descrito na Figura 3.1 e cada fase descrita em detalhes nas prximas sees.

Modelo do Subdomnio

Criar um Modelo de um Subdomniode Aplicao dos Sistemas deInformao baseados na Web

Criar umaLinguagem de

Padres

Linguagem de Padres

Desenvolver umFramework

Modelos de Classesde Anlise

FrameworkInstanciar

Aplicaes doDomnio

Aplicaces do Domnio

ImplementarAplicaes do

Domnio

Criar Modelos deAnlise

Atividade

Resultado/Produto

Legenda

Figura 3.1: Alternativas para o Desenvolvimento de Sistemas de Informao Baseados na Web.

Obviamente, aplicaes genricas podem ser desenvolvidas diretamente do modelo de classes

ou da linguagem de padres, que so apoiadas pelas duas primeiras fases do processo geral. Essas

aplicaes genricas no so, portanto, frameworks, mas poderiam servir de base para um processo

de generalizao, como proposto por Pree (1999), Roberts e Johnson (1998) e Schmid (1997,

1999).

Deve-se notar que o processo de criao da linguagem de padres genrico, isto , no de-

pende do processo inicial, j que os modelos de classes dos sistemas escolhidos como base para a

engenharia reversa poderiam ter sido projetados de diferentes modos. O uso de engenharia reversa

3.3 Criar um Modelo do Domnio da Aplicao 29

adequado para SIbWebs porque a interface est publicamente disponvel e torna-se uma alterna-

tiva interessante elicitar os requisitos do sistema dessa maneira. O resultado da engenharia reversa

pode ser complementado com informaes obtidas de forma tradicional. Neste trabalho, optou-se

por obter os requisitos por meio da engenharia reversa pelo interesse acadmico em explorar-se

esse tipo de atividade.

3.3 Criar um Modelo do Domnio da Aplicao

Vrias definies descrevem o processo de engenharia reversa como um esforo para criar uma re-

presentao em um nvel de abstrao mais alto que o cdigo fonte (Chikofsky e Cross, 1990; Pres-

sman, 2000; Sage, 1995; Sommerville, 1996; Stephen e Lynn, 1995; Waters e Chikofsky, 1994).

Um sistema pode ser visualizado em diferentes nveis de abstrao (Costa, 1997). O processo de

engenharia reversa baseado na interface de SIbWebs trata das vises funcionais do domnio e tem

seu foco no contexto em que o sistema est inserido e nas relaes lgicas entre as funes que

compem o sistema.

O processo proposto para a criao de um modelo do domnio de aplicao de SIbWebs

apresentado na Figura 3.2. Esse processo constitudo de quatro atividades principais: escolher

trs SIbWebs do domnio que sero chamados de sistemas-base, conduzir a engenharia reversa dos

sistemas-base, criao dos modelos de classes dos sistemas-base e criao do modelo do domnio.

O objetivo do processo obter um modelo genrico do domnio referente aos SIbWebs analisados.

O conhecimento adquirido pela anlise desse domnio a base para o desenvolvimento de novos

SIbWebs que pertenam a essa mesma famlia de sistemas, como por exemplo, comrcio eletrnico

de livros ou CDs, leiles virtuais ou sistemas de reservas de passagens.

3.3.1 Escolher Trs Sistemas do Domnio

A primeira atividade deste processo a escolha de trs SIbWebs do domnio. Roberts e Johnson

(1998) sugerem que para desenvolver frameworks devem ser desenvolvidas primeiramente trs

aplicaes concretas que iro fornecer conhecimento suficiente para gradativamente permitir a

generalizao dessas aplicaes. Ao desenvolver e generalizar os trs sistemas possvel aprender

sobre o domnio em que essas trs aplicaes se inserem. necessrio que no mnimo trs SIbWebs

sejam escolhidos para que se possa obter um conjunto bsico de funes que represente uma parte

considervel da funcionalidade de SIbWebs desse domnio. A escolha dos sistemas-base uma

atividade humana e no determinstica. Algumas sugestes podem auxiliar nessa escolha:

Escolher sistemas o mais heterogneos possveis, pois quanto mais heterogneos forem os

sistemas-base maior ser o nmero de funes diferentes elicitadas;

3.3 Criar um Modelo do Domnio da Aplicao 30

Processo de criao do modelo do domnio da aplicao de sistemas de informao baseados na Web

2EngenhariaReversa dos

Sistemas-base

3Criao dos Modelos

de Classe dosSistemas-base

4Criao do Modelo

de Classes doDomnio

Sistemas-base Conhecimentosobre odomnio

Decises deAnlise/Projeto

Mtodo deDocumentaode Requsitos

Web Documento deRequisitos dosSistemas-base

Mtodo deModelagem

(UML)

Modelos deClasses dos

Sistemas-base

Mtodo deModelagem

(UML)

Padres deAnlise/Projeto

Modelo deClasses do

Domnio

Conhecimentosobre odomnio

Decises deAnlise/Projeto

1Escolher trsSIbWebs do

Domnio

Web

Conhecimentosobre odomnio

Aplicaes Glossrio

Glossrio

Documentao

Figura 3.2: Processo de Criao do Modelo do Domnio da Aplicao de SIbWebs.

Analisar sistemas que so lderes de mercado, isto , sistemas muito usados e outros menos

conhecidos para obter vises mais complexas e mais simples de sistemas do domnio;

SIbWebs provenientes de pases diferentes podem indicar funes que atendam a diferentes

caractersticas culturais, econmicas e tecnolgicas;

Organizaes que possuam diferentes fins, ramos e objetivos de negcio possuem funes

relacionadas sua prpria natureza e podem fornecer uma gama variada de funes; e

Se possvel, analisar sistemas que funcionam em Intranet, pois podem ser mais completos e

apresentarem outras funes, como as relacionadas com segurana, por exemplo.

O acesso ao contedo dos sistemas-base importante para a aplicao dessa atividade j que

existem SIbWebs que so totalmente pblicos, enquanto outros restringem de alguma maneira

o acesso mediante a exigncia de cadastramento ou fornecimento de informaes. O resultado

da aplicao do processo diretamente ligado s interfaces utilizadas. O processo aplicvel a

qualquer SIbWeb desde que as condies de acesso sejam atendidas.

No caso deste trabalho foram escolhidos trs sistemas-base do domnio de leiles virtuais: o

Arremate.com, o iBazar e o eBay. Esses trs sistemas-base ofereceram as condies mnimas

para a execuo da primeira atividade do processo, ter acesso a interface pblica e rastrear suas

funes. A escolha dos sistemas-base seguiu as sugestes anteriormente apresentadas, sistemas

de diferentes pases (EUA e Amrica do Sul), sistemas-base conhecidos (eBay) e com diferentes

objetivos de negcio (o iBazar oferece seus servios gratuitamente). Poderiam ter sido escolhidos

sistemas-base que tratam de assuntos governamentais ou, que fossem dirigidos a um pblico alvo

especfico como colecionadores de antigidades ou ainda, leiles filantrpicos.

3.3 Criar um Modelo do Domnio da Aplicao 31

3.3.2 Engenharia Reversa dos Sistemas-base

O objetivo geral desta atividade rastrear e documentar de maneira rigorosa e o mais completa

possvel as funes dos sistemas-base escolhidos. Assim, aps serem escolhidos os trs sistemas

como base da engenharia reversa deve-se, para cada um desses sistemas, executar todas as suba-

tividades apresentadas na Figura 3.3. A fase de engenharia reversa dos sistemas-base deve ser

executada completamente para cada sistema-base escolhido.

2.2Identificar asPginas do

Sistema-base

2.3Exercitar o

Sistema-base 2.4Refinar osRequisitos

Sistemas-base

Listagem dePginas

Grafo deNavegao

Mtodo deDocumentaode Requisitos

Conjunto deRequisitos doSistema-base

GlossrioDocumento deRequisitos dosSistemas-base

Glossrio

2 - Engenharia Reversa dos Sistemas-base

Web

Web

2.1Analisar

Informaesdo Sistema-base

DocumentosDocumentos

Figura 3.3: Engenharia Reversa dos Sistemas-base.

Costa (1997) props um mtodo de engenharia reversa baseado na interface de sistemas que,

embora no tenha sido desenvolvido para SIbWebs nem tampouco para a obteno do modelo do

domnio da aplicao, possui atividades com fins semelhantes atividades aqui propostas. A pri-

meira etapa desse mtodo constituda de dois passos: obter informaes do sistema e de tcnicas

relacionadas aos conceitos pertinentes e recuperar o modelo de objetos do sistema. Dessa forma,

algumas informaes relacionadas aos passos da primeira etapa do mtodo proposto por Costa

(1997) foram utilizadas em alguns pontos da atividade 2 e da atividade 3 do processo proposto.

A atividade 2.1 tem o objetivo de coletar e analisar informaes do sistema (manuais, livros,

artigos, etc...) e informaes tcnicas (domnio, aplicao, tecnologia, etc...) que so importantes

para o entendimento e aprendizado do domnio da aplicao. Essas informaes ajudam o analista

a familiarizar-se com os conceitos do sistema e do domnio, facilitando decises que devem ser

tomadas ao longo do processo. No trabalho proposto foi utilizado o conhecimento tcito sobre os

leiles, bem como teoria de sistemas de informao e artigos sobre sistemas de leiles virtuais, tais

como os de Kumar e Feldman (1998b) e de Wellman e Wurman (1998). A Tabela 3.1 mostra parte

das atividades bsicas de um processo de negociao por meio de leiles, apresentadas por Kumar

e Feldman (1998b). Essas at