Você está na página 1de 171

Ps-Gr adua o em Ci nc i a da Comput a o

Uma Ex t enso do Fl ux o de Anl i se e Pr oj et o do


RUP par a o Desenvol vi ment o de Apl i c a es Web

Por

Ri c ar do Andr Caval c ant e de Souza


Di sser t a o de Mest r ado




Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
http://www.cin.ufpe.br/~posgraduacao

RECIFE, ABRIL/2002

UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMTICA



Ricardo Andr Cavalcante de Souza



Uma Extenso do Fluxo de Anlise e Projeto do RUP
para o Desenvolvimento de Aplicaes Web



Trabalho apresentado Ps-Graduao em Cincia da
Computao do Centro de Informtica da Universidade
Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre em Cincia da Computao.



ORIENTADOR:

Prof. Alexandre Marcos Lins de Vasconcelos



Recife, Abril de 2002

v
Agradecimentos

A Deus nosso criador por me iluminar e permitir mais esta conquista.
Ao meu saudoso pai Manoel Andr (in memoriam), eterno amigo e incentivador, por todos os
ensinamentos.
A minha amada me Rosilene por todos os sacrifcios e pela educao que me proporcionou.
Aos meus irmos Andr e Rosila pelo carinho e apoio.
A minha Aninha pelo companheirismo, por me ouvir, apoiar e por estar presente nas horas
mais difceis.
Aos meus conterrneos e grandes amigos Alexandre Macedo e Marco Fagundes que me
acompanham desde os tempos da graduao ainda no nosso querido estado do Par.
A equipe do projeto SIG@UFPE, da qual tenho orgulho de fazer parte, por toda a colaborao
e amizade.
Ao professor Alexandre Vasconcelos pela valiosa orientao na elaborao do trabalho. Ao
professor Daniel Schwabe pela grande colaborao e avaliao do trabalho. Ao professor
Augusto Sampaio pela avaliao do trabalho.

vii
Resumo
A Internet tem se mostrado como um dos mais efetivos e atrativos meios para realizao
de transaes comerciais, possibilitando tanto a divulgao, quanto a negociao e
disponibilizao de bens e servios. Alm disto, devido em grande parte a globalizao da
economia mundial, cada vez mais as empresas esto migrando seus sistemas corporativos para
plataformas baseadas principalmente na Web. Diante deste panorama, hoje em dia existe uma
demanda bastante significativa pelo desenvolvimento de aplicaes para Web.
Entretanto, do ponto de vista da Engenharia de Software, as aplicaes Web possuem
caractersticas especficas que as diferenciam das aplicaes tradicionais, e que precisam ser
tratadas no processo de desenvolvimento de uma forma disciplinada. Para tanto, fazem-se
necessrias adaptaes em processos de desenvolvimento de software j existentes para um
melhor atendimento na construo de aplicaes Web.
Visando atender as necessidades de desenvolvimento especficas para aplicaes Web,
este trabalho apresenta uma adequao da metodologia genrica de desenvolvimento de
software RUP (Rational Unified Process), mais especificamente no fluxo de Anlise e
Projeto, tendo em vista que a etapa de anlise e projeto onde h uma maior diferena no
desenvolvimento de aplicaes Web com relao a aplicaes tradicionais.
Este trabalho apresenta tambm um estudo de caso para validao da efetividade da
proposta de extenso do fluxo de Anlise e Projeto do RUP para o desenvolvimento mais
apropriado de aplicaes Web.

ix
Abstract
The Internet has shown to be one of the most effective and attractive ways for the
accomplishment of business, making possible diffusion, negotiation and delivery of products
and services. Furthermore, mostly due to the globalization of the worlds economy, more
companies are migrating their corporate systems to Web-based plataforms mainly. In such a
panorama, there is a significant Web-based applications development demand.
However, from the Software Engineering point of view, Web-based applications have
specific characteristics that must be handled in the development process. For this reason, it is
necessary to do some adjustments in existing software development process.
Aiming at the solution of Web-based applications development related issues, this work
presents a RUP (Rational Unified Process) Analisys & Design workflow extension and a case
study to validate it.


xi
ndice

1 Introduo ....................................................................................................................... 17
1.1 Motivao............................................................................................................................ 18
1.2 Escopo do Trabalho ........................................................................................................... 19
1.3 Objetivos ............................................................................................................................. 20
1.4 Estrutura do Trabalho....................................................................................................... 21
2 Engenharia de Software para Web............................................................................... 23
2.1 Viso Geral.......................................................................................................................... 24
2.2 Consideraes sobre a Web............................................................................................... 24
2.3 Aplicaes Web................................................................................................................... 25
2.4 Aplicaes Web versus Aplicaes Tradicionais.............................................................. 25
2.5 A Necessidade de uma Metodologia.................................................................................. 27
2.6 Adoo Tecnologia Web ................................................................................................. 28
2.6.1 Exemplos de Tecnologias de Implementao.................................................................. 30
2.7 Desenvolvimento de Software atravs da Web................................................................ 32
2.8 Consideraes Finais.......................................................................................................... 33
3 Extenses de UML para Aplicaes Web..................................................................... 35
3.1 Viso Geral.......................................................................................................................... 36
3.2 Extenses de UML.............................................................................................................. 36
3.3 WAE Web Application Extension................................................................................... 37
3.4 Extenso de UML para Modelagem Navegacional ......................................................... 41
3.4.1 Esteretipos para Modelagem Navegacional ................................................................... 46
3.5 O Framework W2000......................................................................................................... 47
3.6 Consideraes sobre as Extenses de UML..................................................................... 49
3.7 Consideraes Finais.......................................................................................................... 51
4 O RUP - Rational Unified Process ................................................................................ 53
4.1 Viso Geral.......................................................................................................................... 54
4.2 Conceitos Chaves do RUP ................................................................................................. 54
4.3 Caractersticas do RUP...................................................................................................... 55
4.3.1 Dirigido a Casos de Uso .................................................................................................. 55
4.3.2 Centrado na Arquitetura................................................................................................... 55
4.3.3 Iterativo e Incremental ..................................................................................................... 56
4.4 Ciclo de Vida do Software no RUP................................................................................... 57
4.5 Fluxos do RUP.................................................................................................................... 59
4.5.1 Fluxo de Modelagem de Negcio.................................................................................... 60
4.5.2 Fluxo de Requisitos.......................................................................................................... 61
4.5.3 Fluxo de Anlise & Projeto.............................................................................................. 63
4.5.4 Fluxo de Implementao.................................................................................................. 64
4.5.5 Fluxo de Teste.................................................................................................................. 66

xii
4.5.6 Fluxo de Implantao....................................................................................................... 67
4.5.7 Fluxo de Gerenciamento de Configurao e Mudanas .................................................. 68
4.5.8 Fluxo de Gerenciamento de Projeto................................................................................. 68
4.5.9 Fluxo de Ambiente........................................................................................................... 69
4.6 Consideraes Finais.......................................................................................................... 69
5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de
Aplicaes Web....................................................................................................................... 71
5.1 Viso Geral.......................................................................................................................... 72
5.2 Fluxo de Anlise e Projeto do RUP Estendido................................................................. 72
5.3 Subfluxos do Fluxo de Anlise e Projeto Estendido........................................................ 74
5.3.1 Definir uma Arquitetura Candidata.................................................................................. 74
5.3.2 Refinar a Arquitetura ....................................................................................................... 76
5.3.3 Analisar Comportamento................................................................................................. 77
5.3.4 Projetar Camada de Apresentao ................................................................................... 78
5.3.5 Projetar Componentes...................................................................................................... 79
5.3.6 Projetar Componentes de Tempo-Real ............................................................................ 80
5.3.7 Projetar Banco de Dados.................................................................................................. 81
5.4 Atividades do Fluxo de Anlise e Projeto Estendido....................................................... 82
5.4.1 Analisar Arquitetura......................................................................................................... 82
5.4.2 Identificar Mecanismos de Projeto .................................................................................. 82
5.4.3 Identificar Elementos de Projeto...................................................................................... 83
5.4.4 Incorporar Elementos de Projeto Existentes .................................................................... 83
5.4.5 Descrever a Arquitetura em Tempo de Execuo............................................................ 84
5.4.6 Descrever a Distribuio.................................................................................................. 84
5.4.7 Revisar a Arquitetura ....................................................................................................... 85
5.4.8 Analisar Caso de Uso....................................................................................................... 85
5.4.9 Projetar Caso de Uso........................................................................................................ 85
5.4.10 Projetar Subsistema.......................................................................................................... 86
5.4.11 Projetar Classe ................................................................................................................. 86
5.4.12 Projetar Navegao.......................................................................................................... 86
5.4.13 Projetar GUI (Graphic User Interface)............................................................................. 86
5.4.14 Projetar Banco de Dados.................................................................................................. 87
5.4.15 Projetar Cpsula............................................................................................................... 87
5.4.16 Revisar o Projeto.............................................................................................................. 87
5.5 Consideraes Finais.......................................................................................................... 87
6 Detalhamento do Subfluxo Projetar Camada de Apresentao ................................ 89
6.1 Viso Geral.......................................................................................................................... 90
6.2 O Subfluxo Projetar Camada de Apresentao .............................................................. 90
6.2.1 A Atividade Projetar Navegao...................................................................................... 92
6.2.2 A Atividade Projetar GUI (Graphic User Interface) ........................................................ 94
6.3 O Mtodo para Criao do Modelo Navegacional .......................................................... 95
6.3.1 Primeiro Passo: Identificar as Classes Navegacionais..................................................... 95
6.3.2 Segundo Passo: Identificar os Caminhos Navegacionais................................................. 96
6.3.3 Terceiro Passo: Criar os Caminhos Navegacionais ......................................................... 98
6.4 Consideraes Finais........................................................................................................ 105
7 Estudo de Caso A Aplicao Web SIG@UFPE...................................................... 107
7.1 Viso Geral........................................................................................................................ 108

xiii
7.2 Preparao do Ambiente ................................................................................................. 108
7.3 A Aplicao Web SIG@UFPE........................................................................................ 109
7.3.1 Objetivos da Aplicao.................................................................................................. 109
7.3.2 Usurios da Aplicao ................................................................................................... 110
7.3.3 Principais Funes da Aplicao ................................................................................... 111
7.4 A Execuo do Subfluxo Projetar Camada de Apresentao ...................................... 112
7.4.1 Artefatos Base para Execuo do Subfluxo................................................................... 112
7.4.2 Realizao da Atividade Projetar Navegao ................................................................ 116
7.4.3 Realizao da Atividade Projetar GUI........................................................................... 119
7.5 Consideraes Finais........................................................................................................ 122
8 Concluso ...................................................................................................................... 123
8.1 Consideraes Gerais e Contribuies ........................................................................... 124
8.2 Trabalhos Relacionados................................................................................................... 126
8.3 Perspectivas e Trabalhos Futuros................................................................................... 128
Referncias Bibliogrficas ................................................................................................... 129
Apndice A - Guia de Projeto Navegacional ...................................................................... 133
Apndice B - A Extenso de UML WAE............................................................................ 139
Apndice C - Framework de Anlise e Projeto para Aplicaes Baseadas na Web ...... 147


xv
ndice de Figuras

Figura 1-1 Padro Arquitetural em Camadas ........................................................................................ 20
Figura 2-1 Barreiras de conhecimento na adoo de tecnologias Web ................................................. 30
Figura 3-1 Construo de uma pgina Cliente....................................................................................... 38
Figura 3-2 Redirecionamento de processamento para uma pgina Servidor......................................... 38
Figura 3-3 Link entre pginas Web ....................................................................................................... 38
Figura 3-4 Uso de Formulrios em aplicaes Web.............................................................................. 39
Figura 3-5 Uso de Frames em aplicaes Web...................................................................................... 40
Figura 3-6 Modelo Conceitual da aplicao Controlador de Servios............................................... 41
Figura 3-7 Modelo do Espao Navegacional da aplicao Controlador de Servios......................... 42
Figura 3-8 Padro de Projeto para Estrutura Navegacional................................................................... 43
Figura 3-9 Modelo da Estrutura Navegacional da aplicao Controlador de Servios...................... 44
Figura 3-10 Partes do Modelo de Apresentao Esttico da aplicao Controlador de Servios...... 45
Figura 3-11 Atividades do framework W2000...................................................................................... 47
Figura 3-12 Aspectos atendidos pelas extenses de UML para aplicaes Web .................................. 50
Figura 4-1 Ciclos e Fases do RUP......................................................................................................... 57
Figura 4-2 Fluxos do RUP..................................................................................................................... 59
Figura 4-3 Fluxo de Modelagem de Negcios....................................................................................... 60
Figura 4-4 Fluxo de Requisitos.............................................................................................................. 62
Figura 4-5 Fluxo de Anlise & Projeto.................................................................................................. 63
Figura 4-6 Fluxo de Implementao...................................................................................................... 65
Figura 4-7 Fluxo de Teste...................................................................................................................... 66
Figura 4-8 Fluxo de Implantao........................................................................................................... 67
Figura 5-1 Fluxo de Anlise e Projeto do RUP Estendido para Aplicaes Web ................................. 73
Figura 5-2 Subfluxo Definir uma Arquitetura Candidata...................................................................... 74
Figura 5-3 Subfluxo Refinar a Arquitetura............................................................................................ 76
Figura 5-4 Subfluxo Analisar Comportamento ..................................................................................... 77
Figura 5-5 Subfluxo Projetar Camada de Apresentao........................................................................ 78
Figura 5-6 Subfluxo Projetar Componentes .......................................................................................... 79
Figura 5-7 Subfluxo Projetar Componentes de Tempo Real ................................................................. 80
Figura 5-8 Subfluxo Projetar Banco de Dados ...................................................................................... 81
Figura 6-1 Detalhamento do Subfluxo Projetar Camada de Apresentao ........................................... 91
Figura 6-2 Padro de Projeto Navegacional para Classes Navegacionais............................................. 96
Figura 6-3 Exemplo de parte de um Modelo de Anlise ....................................................................... 97
Figura 6-4 Padro de Modelagem Navegacional para operao de Incluso ........................................ 99
Figura 6-5 Padro de Modelagem Navegacional para operaes de Pesquisa, Alterao e Excluso 100
Figura 6-6 Exemplo de Modelo Navegacional .................................................................................... 104
Figura 7-1 Modelo de Casos de Uso da funcionalidade Criao de Turmas e Subturmas .............. 113
Figura 7-2 Realizaes do Caso de Uso Criar Turmas e Subturmas................................................ 115
Figura 7-3 Modelo de Anlise ou Conceitual da funcionalidade Criao de Turmas e Subturmas. 116
Figura 7-4 Exemplo de Modelo Navegacional gerado automaticamente............................................ 117
Figura 7-5 Modelo Navegacional da funcionalidade Criao de Turmas e Subturmas................... 118
Figura 7-6 Interface Grfica Especificar Turma ........................................................................... 119
Figura 7-7 Interface Grfica Pesquisar Turma............................................................................. 120
Figura 7-8 Interface Grfica ndice Turma ................................................................................... 120
Figura 7-9 Interface Grfica Detalhamento Turma....................................................................... 121
Figura 7-10 Interface Grfica ndice Docentes Ministrantes ........................................................ 121

17
Captulo 1
1 Introduo
O crescimento e a popularizao da Internet como meio de comunicao e divulgao
de notcias e produtos possibilitou o surgimento de novas formas de transaes comerciais e,
cada vez mais, a comunidade de negcios tem migrado seus sistemas crticos para uma
plataforma baseada na Web, o que tem ocasionado uma grande demanda no desenvolvimento
de aplicaes Web.
As aplicaes Web possuem caractersticas especficas que as diferenciam de aplicaes
tradicionais, e que precisam ser tratadas no processo de desenvolvimento. Diante deste
panorama, este trabalho apresenta uma proposta de extenso do fluxo de Anlise e Projeto do
RUP (Rational Unified Process) para o desenvolvimento mais apropriado de aplicaes Web.
Neste captulo, so apresentados a motivao, o escopo e os objetivos deste trabalho,
bem como sua estruturao em termos de captulos e apndices.
Captulo 1 Introduo
18
1.1 Motivao
Devido ao grande crescimento da Internet, uma nova forma de comrcio surgiu e, cada
vez mais, os negcios esto sendo direcionados para o mundo virtual, isso se d nas mais
diversas reas comerciais, desde livrarias at bancos virtuais. Entre as principais vantagens
dessa nova forma de comunicao com o cliente est a desburocratizao, a comodidade e a
diminuio de custos operacionais. Alm disto, as empresas esto migrando seus sistemas
corporativos e departamentais para plataformas baseadas na Web, devido em grande parte
globalizao da economia mundial, tendo em vista que o espao geogrfico de atuao de
uma empresa pode ser em mbito mundial.
A Internet e, conseqentemente, as aplicaes Web esto a cada dia mais presentes em
nossas vidas e, se por um lado essa popularizao possibilita uma maior disseminao do
conhecimento e outras inmeras vantagens, por outro lado, do ponto de vista da Engenharia
de Software, nos deparamos com preocupaes que antes no tnhamos com as aplicaes
tradicionais.
As fases do ciclo de um sistema de informao necessitam ser adaptadas para melhor
atenderem o desenvolvimento de aplicaes Web, desde os requisitos (com grande ateno
aos requisitos no-funcionais), at tratar questes como audincia da aplicao e
compatibilidade de ferramentas, alm de preocupao excessiva com segurana.
As aplicaes Web esto tornando-se cada vez mais complexas devido aos vrios
aspectos adicionais e especficos que devem ser observados para construo deste tipo de
aplicao, alm da complexidade natural do negcio. Diante deste panorama, faz-se
necessrio adaptaes em processos de desenvolvimento de softwares j existentes, para
melhor atenderem s necessidades do desenvolvimento de aplicaes Web.
Captulo 1 Introduo
19
1.2 Escopo do Trabalho
O enfoque deste trabalho sobre a Engenharia de Software para Web cujo propsito o
estabelecimento e uso de princpios de engenharia, gerenciamento e tcnicas sistemticas e
disciplinadas para o desenvolvimento, implantao e manuteno de aplicaes Web de alta
qualidade, bem como a incorporao de princpios bem sucedidos da Engenharia de Software
tradicional.
Mais especificamente, este trabalho consiste na adaptao da metodologia de
desenvolvimento de software RUP Rational Unified Process, para construo de aplicaes
Web. As vantagens do uso de uma metodologia [Bennett 99] so: ajuda a produzir um
produto de melhor qualidade, em termos de padres de documentao, aceitao do usurio,
manutenibilidade e consistncia do software; ajuda a garantir que os requisitos do sistema
sejam completamente atendidos; ajuda a gerenciar o projeto, pois possibilita um melhor
controle da execuo do projeto e a reduo de custos de desenvolvimento; promove a
comunicao entre participantes do projeto, pela definio dos participantes essenciais e
interaes, bem como pela estruturao do processo como um todo.
A metodologia RUP foi escolhida devido sua generecidade e por ser adaptvel, bem
como por reunir o melhor de vrias tcnicas modernas de desenvolvimento de software e ser
bem aceita tanto no meio comercial como no meio acadmico.
O RUP, como metodologia, atende todo o ciclo de vida do desenvolvimento de
software, entretanto, a etapa que mais diferencia o desenvolvimento de aplicaes Web com
relao as aplicaes tradicionais a de anlise e projeto [Arajo 01]. Desta forma, o foco
deste trabalho est na extenso do fluxo de Anlise e Projeto do RUP para o desenvolvimento
mais apropriado de aplicaes Web.
A extenso do fluxo de Anlise e Projeto do RUP consiste da criao de novas
atividades e modificaes de atividades j existentes, e visa tratar caractersticas especficas
de aplicaes Web, com nfase nos aspectos de navegao e de apresentao.
Captulo 1 Introduo
20
1.3 Objetivos
Este trabalho visa atender o processo de desenvolvimento de aplicaes Web que
seguem o padro arquitetural Layers (Camadas) Figura 1-1.
Apresentao
Comunicao
Negcio
Dados

Figura 1-1 Padro Arquitetural em Camadas
Em [Borba 00], so definidos os propsitos das camadas apresentadas na Figura 1-1. A
camada de Apresentao, tambm chamada Interface com o Usurio, responsvel pela
apresentao da aplicao ao usurio. A camada de Comunicao permite o acesso remoto
aos servios da aplicao. A camada de Negcio possui responsabilidades inerentes
aplicao. A camada de Dados responsvel pelo acesso e manipulao de dados, bem como
por efetuar o interfaceamento da aplicao com o banco de dados.
A camada de apresentao a que mais se diferencia entre as aplicaes Web e as
aplicaes tradicionais, devido ao fato de que em aplicaes Web alguns aspectos especficos
devem ser levados em considerao como a navegao, a organizao e apresentao das
interfaces grficas. As demais camadas (comunicao, negcio, dados) de aplicaes Web so
similares as de qualquer aplicao distribuda.
Desta forma, o objetivo principal deste trabalho estender o fluxo de Anlise e Projeto
do RUP para incorporar o projeto da Camada de Apresentao de aplicaes Web, que
consiste na criao do Modelo Navegacional com o propsito de identificar os caminhos
navegacionais da aplicao, ou seja, como o usurio caminha (navega) pela aplicao para
utilizar as funcionalidades e, baseado nas necessidades navegacionais, projetar as interfaces
grficas para interao do usurio com a aplicao. Este trabalho tambm prope um mtodo
para criao do Modelo Navegacional, bem como recomendaes para o desenvolvimento
mais apropriado de aplicaes Web.
Captulo 1 Introduo
21
A proposta de extenso do fluxo de Anlise e Projeto do RUP incorpora algumas
atividades do framework de Anlise e Projeto para aplicaes Web proposto por A.Arajo
[Arajo 01] e define novos artefatos com base nas extenses de UML propostas por
J.Conallen [Conallen 99b] e por N.Koch [Koch 01].
1.4 Estrutura do Trabalho
Alm deste captulo introdutrio, o trabalho consiste de mais sete captulos e trs
apndices.
O Captulo 2 introduz a Engenharia de Software para Web e apresenta caractersticas
especficas das aplicaes Web que as diferenciam das aplicaes tradicionais.
O Captulo 3 apresenta o estado da arte de extenses de UML para aplicaes Web, bem
como um estudo comparativo sobre quais aspectos so atendidos por cada uma das extenses
de UML apresentadas.
O Captulo 4 traz um resumo da metodologia de desenvolvimento de software RUP,
atravs da apresentao de suas caractersticas, fases e fluxos.
O Captulo 5 apresenta uma proposta de extenso do fluxo de Anlise e Projeto do RUP
para o desenvolvimento mais apropriado de aplicaes Web.
O Captulo 6 apresenta o detalhamento das atividades e artefatos do subfluxo proposto
para o projeto da Camada de Apresentao de aplicaes Web, bem como o mtodo proposto
para criao do Modelo Navegacional.
O Captulo 7 apresenta a validao do subfluxo proposto para o projeto da Camada de
Apresentao, atravs de sua aplicao a um estudo de caso realizado sobre a aplicao Web
SIG@UFPE (Sistema de Informaes e Gesto Acadmica da UFPE).
O Captulo 8 apresenta as concluses do trabalho realizado, ressaltando as contribuies
e trabalhos correlatos e futuros.
O Apndice A apresenta o Guia de Projeto Navegacional, onde so definidas regras para
a criao do artefato Modelo Navegacional.
Captulo 1 Introduo
22
O Apndice B apresenta, por completo, a extenso de UML WAE (Web Application
Extension) proposta por J.Conallen [Conallen 99b].
O Apndice C apresenta um resumo do framework de Anlise e Projeto para aplicaes
Web proposto por A.Arajo [Arajo 01].


23
Captulo 2
2 Engenharia de Software para Web
Nos dias de hoje, a Web est sendo utilizada pelas empresas na implementao de
processos de negcio para seus funcionrios, comunicao com seus parceiros, conexo e
integrao de seus sistemas, e efetuao de transaes. Diante deste panorama, uma nova
disciplina chamada de Engenharia de Software para Web est sendo desenvolvida, a qual trata
do estabelecimento e uso de abordagens cientficas, de engenharia, e gerenciamento para dar
suporte ao processo de desenvolvimento de aplicaes Web [Weippl 00].
Neste captulo so descritas as aplicaes Web e so feitas comparaes com as
aplicaes tradicionais. Alm disso, apresentada a Engenharia de Software para Web, cujo
propsito estabelecer e usar princpios de engenharia e gerenciamento para o
desenvolvimento de aplicaes baseadas na Web.
Captulo 2 Engenharia de Software para Web
24
2.1 Viso Geral
Da perspectiva da Engenharia de Software a Web um novo domnio de aplicao,
devido s caractersticas especficas das aplicaes deste ambiente [Vasudevan 96], que as
diferenciam das demais.
Diante deste panorama, neste captulo so descritas as caractersticas especficas de
aplicaes Web e a necessidade de uma metodologia para orientar o processo de
desenvolvimento deste tipo de aplicao, bem como o potencial que a Web tem para fornecer
a infra-estrutura necessria evoluo de um produto de software.
2.2 Consideraes sobre a Web
A Internet uma rede de redes, atravs da qual programas e informaes so
intercambiados, quaisquer que sejam suas plataformas ou protocolos [Beveridge 98]. O
principal servio para busca de informao na Internet o World Wide Web ou simplesmente
Web. A Web baseada no paradigma de hipertexto [Rossi 99], entretanto, foi introduzida
uma tecnologia mais abrangente, chamada hipermdia, que manipula textos e multimdia de
uma forma mais poderosa e intuitiva.
Segundo [Hanneghan 96], entre os aspectos que fazem a Web importante esto: sistema
de hipertexto em rede, arquitetura distribuda sobre a qual a portabilidade de aplicaes pode
ser baseada, crescimento global exponencial, e rede aberta que pode ser acessada com custo
relativamente baixo por grandes e pequenas empresas.
Alm disso, destacam-se os seguintes motivos pelos quais as organizaes esto
adotando a Web [Hanneghan 96]: meio de comunicao interno e externo, fcil integrao
com logsticas corporativas, obteno e manuteno de vantagem competitiva, meio para
colaborao e desenvolvimento, recuperao e utilizao de informao, marketing e vendas,
transmisso de dados, e criao de uma presena corporativa.
A popularidade da Web, como infra-estrutura de suporte a aplicaes, deve-se a vrios
fatores, entre os quais esto: a reduo de custo de treinamento de pessoal, j que muitas
pessoas esto habituadas a utilizar um browser (navegador) Web e correio eletrnico; e a
comodidade de clientes/usurios efetuarem transaes, atravs de acesso remoto.
Captulo 2 Engenharia de Software para Web
25
2.3 Aplicaes Web
Uma aplicao Web um sistema que usa a Internet como meio de comunicao
primrio entre os usurios e o sistema. A distino entre aplicaes Web e Web sites sutil, e
consiste em: a aplicao que permite o usurio efetuar uma transao de negcio no servidor
considerada uma aplicao Web, caso contrrio um Web site.
Desenvolver uma aplicao Web no somente uma questo tecnolgica, mas tambm
uma questo organizacional, poltica e cultural. O desenvolvimento destas aplicaes envolve
uma mudana na estruturao e apresentao da informao [Arajo 01].
Aplicaes Web podem ser disponibilizadas para uma grande quantidade de usurios
dentro de uma mesma organizao (Intranet), atravs de vrias organizaes (Extranet) e
sobre a Internet, diferentemente de aplicaes tradicionais.
As tendncias indicam alto interesse da maioria das organizaes em desenvolver ou
portar seus sistemas para a plataforma Web. H trs razes principais para isto: alta
popularidade da tecnologia entre clientes em potencial, baixo custo de investimento, e alta
possibilidade de alcance dos objetivos pretendidos. Em muitas organizaes, uma das
principais funes dos CIOs (Chief Information Officers) explorar a Web procura de
benefcios comerciais e oportunidades de negcios [Hech 98].
Apesar da grande penetrao da Web em uma variedade de mercados, est se tornando
claro que a estrutura atual no est bem projetada para o acesso customizado informao.
Para tanto, projetista de aplicaes Web tm de resolver questes de autoria, navegao,
organizao, gerenciamento e entrega de uma grande quantidade de informao via Web
[Arajo 01].
2.4 Aplicaes Web versus Aplicaes Tradicionais
As principais diferenas entre aplicaes Web e aplicaes tradicionais referem-se a
questes sobre navegao, organizao da interface e implementao [Rossi 99]. Nos
pargrafos a seguir, algumas dessas questes so apresentadas.
Captulo 2 Engenharia de Software para Web
26
Referentes Navegao
O que constitui uma unidade de informao com respeito navegao?
Como estabelecer o que so links significantes entre unidades de informao?
Onde o usurio inicia a navegao?
Como organizar o espao de navegao, isto , estabelecer as seqncias possveis
de unidades de informao, atravs das quais o usurio ir navegar?
Se uma interface Web est sendo adicionada para um sistema existente, como
mapear os objetos de dados existentes sobre unidades de informao, e quais
relacionamentos no domnio do problema devem ser mapeados em links?
Referente Organizao da Interface
Quais objetos de interface o usurio ir perceber? Como relacionar estes objetos aos
objetos de navegao?
Como a interface se comportar quando usada pelo usurio?
Como operaes de navegao sero distinguidas das operaes de interface e de
processamento de dados?
Como o usurio estar hbil a perceber sua localizao no espao de navegao?
Referente Implementao
Como as unidades de informao so mapeadas sobre pginas?
Como operaes de navegao so implementadas?
Como outros objetos de interface so implementados?
Como base de dados existentes so integradas aplicao?

Captulo 2 Engenharia de Software para Web
27
As aplicaes Web provavelmente se tornaro mais universais do que as aplicaes
cliente/servidor se tornaram a uma dcada atrs, com um impacto exponencialmente maior em
nossas vidas, simplesmente porque a Web tem potencialmente uma audincia muito mais
ampla do que as aplicaes cliente/servidor baseadas em redes proprietrias.
Apesar das diferenas, muitos dos problemas relacionados a aplicaes Web seguem
estratgias de aplicaes tradicionais [Clemons 91]. Desta forma, muitas das solues
relacionadas a aplicaes tradicionais tambm so aplicadas a aplicaes Web.
2.5 A Necessidade de uma Metodologia
O crescimento da Web tem tido um impacto significativo sobre os diversos setores de
negcios, bem como nas reas de educao, governo, entretenimento e sobre nossa vida
pessoal e profissional. As empresas esto desenvolvendo ou migrando seus sistemas
corporativos para a plataforma Web, devido em grande parte globalizao da economia,
tendo em vista que a rea de atuao de uma empresa pode ser em mbito mundial.
Entretanto, na maioria dos casos, as tcnicas de desenvolvimento usadas para produzir
aplicaes Web tm sido ad hoc. Dificilmente, qualquer ateno dada para mtodos e
processos sistemticos de desenvolvimento, tcnicas de medio e avaliao de qualidade e
para o planejamento e gerenciamento de projetos. A maior parte dos esforos de
desenvolvimento de aplicaes Web atuais e das prticas de gerenciamento tm se baseado no
conhecimento e experincia dos desenvolvedores e de suas prprias prticas de trabalho.
Na ausncia de um processo disciplinado para desenvolvimento de aplicaes Web,
srios problemas podem acontecer no processo de desenvolvimento, implantao, operao e
manuteno destas aplicaes. Aplicaes desenvolvidas sem tcnicas mais rigorosas tm
uma alta probabilidade de falhar. Caso ocorra uma falha muito grave, a confiana na Web
pode ser irreparavelmente abalada, causando uma grave crise [Zelnick 98]. Uma potencial
crise na Web seria mais sria e difundida do que a tradicional crise de software [Gibbs 94].
Captulo 2 Engenharia de Software para Web
28
Para evitar uma possvel crise na Web e alcanar maior sucesso no desenvolvimento de
aplicaes Web complexas, h uma presso por tcnicas disciplinadas, novos mtodos e
ferramentas para desenvolvimento, implantao e avaliao destas aplicaes. Tais tcnicas
devem levar em considerao as caractersticas especiais da nova mdia, os ambientes
operacionais, os cenrios e multiplicidade de perfis de usurios e o tipo, experincia e
conhecimento das pessoas envolvidas no processo de construo das aplicaes. Em [Koch
99] feito um estudo comparativo entre vrios mtodos de desenvolvimento de aplicaes
hipermdia, entre as quais as aplicaes Web podem ser inseridas.
A Engenharia de Software para Web deve se preocupar com o estabelecimento e uso de
princpios de engenharia, gerenciamento e de tcnicas sistemticas e disciplinadas, de modo a
alcanar aplicaes Web de alta qualidade. Alm disso, devem ser incorporados alguns dos
princpios bem sucedidos da engenharia de software tradicional, adaptando-os para a natureza
mais aberta e flexvel da Web e de suas aplicaes.
Desta forma, o ncleo de Engenharia de Software para Web [Hansen 99] deve incluir:
especificao e anlise de requisitos; metodologias e tcnicas de desenvolvimento; integrao
com sistemas legados; migrao de sistemas legados para ambientes Web; desenvolvimento
de aplicaes de tempo real para a Web; teste, verificao, avaliao, controle e garantia de
qualidade; configurao e gerenciamento de projetos; mtricas para estimativa dos esforos de
desenvolvimento; especificao e avaliao de performance; atualizao e manuteno;
aspectos humanos e culturais; desenvolvimento centrado no usurio, incluindo modelagem,
envolvimento e feedback para/do o usurio; educao e treinamento.
2.6 Adoo Tecnologia Web
Apesar da enorme difuso e euforia associada utilizao da tecnologia Web, tem se
tornado claro que esta tecnologia no to fcil de usar quanto muitas organizaes
supunham. Muitas organizaes ainda tm encontrado dificuldade em resolver algumas
questes bsicas relacionadas adoo da tecnologia Web [Vasudevan 96], tais como, seleo
de tecnologias e padres apropriados, planejamento de oramento de projetos para a Web e
treinamento de pessoal nestas novas tecnologias.
Captulo 2 Engenharia de Software para Web
29
A emergncia de novas tecnologias, como Web Data Warehousing, levantam questes
de que no somente necessria a inteno em se adotar uma tecnologia, precisa-se estar
capacitado para tal. Cada potencial usurio tem que criar o conhecimento necessrio para se
beneficiar do uso desta tecnologia em seu contexto de negcios.
Em geral, trs nveis de tecnologia Web so identificados [Nambisan 99]: acesso
informao (nvel 1), trabalho colaborativo (nvel 2) e transaes de negcio (nvel 3).
Nvel 1 Acesso Informao: este o nvel mais baixo, onde a tecnologia usada
como ferramenta para disseminao de informao sobre produtos e servios,
polticas organizacionais, misso corporativa e para partes internas e externas
(clientes, empregados e investidores). Exemplos deste nvel so Web sites
corporativos e Intranets.
Nvel 2 Trabalho Colaborativo: este o nvel intermedirio, onde a tecnologia
facilita a comunicao interna e externa, compartilhamento e localizao de
documentos em tempo real. Exemplos deste nvel so Intranets e Extranets
corporativas, e videoconferncia.
Nvel 3 Transaes de Negcios: este o nvel mais alto, onde a tecnologia
fornece suporte direto para transaes e processos de negcios dentro e fora da
organizao. Exemplos deste nvel so comrcio eletrnico e ERP (Enterprise
Resource Planning) estendido para Internet.
Estudos recentes indicam que a maior parte das organizaes ainda est usando a Web
primariamente para a disseminao de informao, ou seja, adotando tecnologia no nvel 1. A
adoo de tecnologia nos nveis mais altos pode ser considerada uma barreira de
conhecimento. Estas barreiras de conhecimento podem ser classificadas em trs categorias,
relacionadas tecnologia, ao projeto e aplicao [Nambisan 99].
Relacionadas Tecnologia: falta de infra-estrutura apropriada de software e
hardware, caractersticas tecnolgicas, segurana e padres. Estas barreiras so
intensificadas pelo fato de que muitas das tecnologias Web no so maduras,
fazendo com que a escolha de uma alternativa tecnolgica seja um verdadeiro
desafio.
Captulo 2 Engenharia de Software para Web
30
Relacionadas ao Projeto: falta de conhecimento relativo a recursos financeiros e
humanos, durao do processo de desenvolvimento e liderana do projeto.
Relacionadas Aplicao: falta de conhecimento relativo aos objetivos de
negcios especficos que sero implementados pela aplicao, o potencial de
integrao da aplicao com aplicaes de TI existentes, e o impacto da aplicao
Web nos sistemas e estrutura atuais da organizao.
A Figura 2-1 apresenta a relao entre as barreiras de conhecimento e os nveis de
adoo de tecnologia Web.
Barreira de
Conhecimento


Nvel 1

Nvel 2

Nvel 3
Relacionada
Tecnologia
- Seleo de tecnologias e
padres apropriados.

- Introduo de flexibilidade
tcnica para acomodar futuros
planos de integrao.
- Obrigao de padres
tecnolgicos atravs de
unidades.
- Adaptao a mudanas
na tecnologia sem impacto
nos negcios.

- Garantia da
conformidade com
regulamentos

Relacionada ao
Projeto
- Identificao dos requisitos
do projeto.

- Resoluo de questes de
liderana de projeto.
- Seleo de metodologias
de desenvolvimento
apropriadas.

- Resoluo dos custos do
projeto Web.

- Compartilhamento do
custo/lucro para projetos
Web com outros times de
aplicaes de IS.
Relacionada
Aplicao
- Elaborao de polticas de
propriedade de dados
corporativos.

- Compartilhamento de
informao/polticas de
regulao de contedo.

- Avaliao de requisitos de
segurana.
- Estabelecimento de
ligaes entre negcios e
aplicaes Web.

- Avaliao do impacto
sobre a estrutura
organizacional e sistemas.
- Reengenharia de
processos de negcio para
explorar a tecnologia Web.

- Redefinio de
relacionamentos intra-
organizacionais.

Figura 2-1 Barreiras de conhecimento na adoo de tecnologias Web
2.6.1 Exemplos de Tecnologias de Implementao
Para serem dinmicas e com interoperabilidade total com banco de dados, as aplicaes
Web utilizam tecnologias de implementao especficas. A seguir, algumas dessas tecnologias
so apresentadas.
Captulo 2 Engenharia de Software para Web
31
Java: linguagem de programao de propsito geral, dinmica, multi-thread,
independente de plataforma e orientada a objeto [Sun 01]. Estas caractersticas a
tornam uma das linguagens de programao que melhor se adaptam ao
desenvolvimento de aplicaes Web.
Applets: programas Java que incluem funcionalidades especficas em pginas Web,
como animao.
Servlets: programas Java usados nos servidores Web para processar solicitaes
recebidas dos browsers clientes.
Java Server Pages (JSP): usadas para encapsular a apresentao dos dados
processados pelos servlets. O objetivo separar a lgica do programa que
implementada como um servlet da apresentao feita pela JSP.
Java Script: linguagem baseada em scripts, utilizada em aplicaes Web para
validar informaes no cliente antes do processamento no servidor.
Java Beans: componente de software reusvel, tais como botes, que pode ser
manipulado em uma ferramenta de desenvolvimento.
Enterprise Java Beans (EJBs): objeto remoto e no visual, independente de
plataforma, projetado para executar no servidor e ser invocado pelos clientes.
Active Server Page (ASP): aplicao para construo de pginas dinmicas e
interativas.
Common Gateway Interface Script (script CGI): programa que pode ser executado
em um servidor Web para responder a uma requisio.
Common Object Request Broker Architecture (CORBA): padro que fornece uma
variedade de servios que capacitam componentes reusveis a se comunicarem com
outros componentes, independente de localizao e/ou plataforma.
Java Database Connectivy (JDBC): especificao de conectividade com banco de
dados para a linguagem Java.
Captulo 2 Engenharia de Software para Web
32
2.7 Desenvolvimento de Software atravs da Web
A Web tem potencial para fornecer a infra-estrutura necessria a um ambiente de
engenharia de software global que suporte a evoluo de um produto de software,
independente de sua localizao e nmero de pessoas envolvidas. Este ambiente pode dar
suporte a incluso, excluso, e migrao de participantes sem a necessidade de mudanas na
infra-estrutura, limitando o efeito destas alteraes no projeto como um todo.
A Web como ambiente de desenvolvimento possibilita que notas, diagramas e croquis
estejam disponveis a qualquer um e acessveis a qualquer hora. Todo o material de projeto
pode ser examinado, procurado e editado on-line; outros benefcios incluem suporte para
controle de verses, estabelecimento de relacionamento hipermdia entre produtos de
trabalho, pessoas e tarefas, e capacidade de rastreamento de dependncias relacionadas.
Planos, projetos, especificaes e cdigo, de projetos anteriores, podem ser localizados e
reusados, parcial ou completamente. Os usurios tambm podem participar diretamente do
desenvolvimento, sendo limitados unicamente pelas restries de acesso determinadas pela
organizao de desenvolvimento. Como exemplo, pode-se citar o Apache Hypertext Transfer
Protocol [Fielding 97], que foi desenvolvido por vrios pesquisadores distribudos pelo
mundo, atravs da colaborao via ambiente Web.
A Web pode tambm capacitar produtos e seus processos associados a serem dispersos
globalmente, enquanto permanecem altamente conectados e dinmicos. Produtos de software
podem ser mais bem projetados e construdos, desde que times de especialistas (projetistas,
analistas, programadores, testadores e outros) dispersos globalmente possam ser agrupados no
ciberespao.
Uma estrutura de comunicao e interao baseada na Web torna possvel tambm que
produtos possam permanecer ligados a seu ambiente de desenvolvimento, aumentando a
qualidade de suporte da organizao. Tais ligaes ou conexes podem dar suporte
otimizaes baseadas em padres de observaes de uso, atualizaes on-line e contnua
avaliao de qualidade. As etapas de treinamento de usurios, manuteno e evoluo podem
ser facilitadas por links para o processo suportado no ambiente de desenvolvimento. O reuso
de componentes pode tambm ser incrementado atravs de uma conveniente biblioteca de
componentes de software de alcance global.

Captulo 2 Engenharia de Software para Web
33
Apesar de ser importante ressaltar a caracterstica da Web de fornecer suporte e infra-
estrutura ao desenvolvimento de software, neste trabalho esta caracterstica no ser
abordada. Consideramos a utilizao desta caracterstica da Web como uma futura evoluo
deste trabalho.
2.8 Consideraes Finais
Neste captulo foram apresentadas as caractersticas especficas de aplicaes Web que
as diferenciam das aplicaes tradicionais, bem como a Engenharia de Software para Web
cujo propsito a utilizao de princpios de engenharia e gerenciamento, e de tcnicas
sistemticas e disciplinadas para o desenvolvimento, implantao e manuteno de aplicaes
Web de alta qualidade. Dentro deste contexto, o prximo captulo apresenta extenses de
UML para aplicaes Web, que so mecanismos utilizados para modelagem das
caractersticas especficas deste tipo de aplicao.




35
Captulo 3
3 Extenses de UML para Aplicaes
Web

UML Unified Modeling Language, uma linguagem padro para modelagem de
sistemas, principalmente os orientados a objetos, amplamente utilizada no meio comercial e
no meio acadmico, e existem inmeras ferramentas CASE que a suportam. Entretanto, por
ser genrica, no satisfaz as necessidades de todos os tipos de aplicao, sendo ento
necessria uma extenso da linguagem para atender situaes especficas, como o
desenvolvimento de aplicaes Web.
Uma extenso de UML uma maneira ordenada de adicionar nova semntica para a
notao de UML. O mecanismo de extenso permite a incluso de: novos atributos, diferentes
semnticas e restries adicionais a elementos da modelagem, de forma a atender mais
satisfatoriamente aspectos especficos de um tipo de aplicao.
Neste captulo, apresentado o estado da arte das extenses de UML para aplicaes
Web. So apresentadas abordagens propostas por J.Conallen [Conallen 99b], N.Koch [Koch
01] e L.Baresi [Baresi 01]. No final do captulo, apresentada uma comparao entre essas
abordagens.
Captulo 3 Extenses de UML para Aplicaes Web
36
3.1 Viso Geral
A UML a linguagem padro para modelagem dos mais diferentes tipos de aplicao.
Devido a esta generecidade, os projetistas da UML reconhecem que a linguagem nem sempre
perfeita (ideal) para todas as situaes. H vezes onde o processo de desenvolvimento
mais bem servido se informaes adicionais forem capturadas, ou se diferentes semnticas
forem aplicadas a certos elementos da modelagem. Para tanto, a UML pode ser estendida de
forma a adicionar novos elementos sua notao, atravs da criao de esteretipos, tagged
values e restries.
Extenses de UML foram criadas para melhor atender a modelagem de aplicaes Web
e, desta forma, satisfazer aspectos especficos deste tipo de aplicao, como a navegao.
Neste captulo so apresentadas algumas extenses de UML para aplicaes Web.
3.2 Extenses de UML
Uma extenso para UML expressa em termos de esteretipos, tagged values, e
restries (constraints). Combinados, esses mecanismos possibilitam criar novos tipos de
blocos de construo que podem ser usados nos modelos.
Esteretipo: uma extenso do vocabulrio da linguagem. Um esteretipo permite
anexar um novo significado semntico a um elemento do modelo. Esteretipos
podem ser aplicados em todos os elementos do modelo e so expressos como uma
string entre << >> ou como um novo cone.
Tagged Value: uma extenso para uma propriedade de um elemento do modelo.
Muitos elementos do modelo tm propriedades associadas a eles. Classes, por
exemplo, tem nome, visibilidade, persistncia, entre outros atributos associados. Um
tagged value a definio de uma nova propriedade que pode ser associada com um
elemento do modelo, sendo representado como uma string entre colchetes [ ].
Restrio: uma extenso da semntica da linguagem. Uma restrio especifica as
condies sobre as quais o modelo pode ser considerado bem formado, sendo
expressa como uma string entre chaves { }.
Nas sees a seguir, so apresentadas extenses de UML para aplicaes Web.
Captulo 3 Extenses de UML para Aplicaes Web
37
3.3 WAE Web Application Extension
Nesta seo, apresentada a WAE (Web Application Extension), proposta por
J.Conallen [Conallen 99a,Conallen 99b], para auxiliar a modelagem de aplicaes Web. Esta
extenso de UML identifica os elementos especficos para construo de uma aplicao Web,
e est detalhada no apndice B. Nos pargrafos a seguir, so apresentados os principais
elementos desta extenso de UML.
Pgina Web
A pgina Web (pgina) necessita ser modelada, pois um dos artefatos primrios de
uma aplicao Web. Uma pgina representada no modelo atravs de duas classes distintas
estereotipadas por <<server page>> e <<client page>>. Qualquer pgina em uma aplicao
Web que tem funcionalidade tanto no servidor como no cliente pode ser representada no
modelo como duas classes separadas, mesmo que suas implementaes estejam em um
mesmo arquivo ou componente.
Deste modo, mtodos servidores e variveis do escopo da pgina so contidos em uma
classe no modelo, estereotipada por <<server page>>. Os mtodos da classe representam os
scripts do lado servidor, sub rotinas e funes. Os scripts do lado cliente e formatao da
interface grfica no so parte do escopo da pgina servidor. Uma pgina servidor pode ter
relacionamentos com componentes existentes no servidor, tais como objetos de negcio nas
camadas do sistema ou componentes de acesso a dados.
As pginas cliente so similarmente representadas no modelo como classes
estereotipadas por <<client page>>. Os atributos da pgina cliente so variveis do escopo da
pgina e funes que executam no browser cliente. As pginas cliente so associadas com
componentes que executam no cliente, como Java Applets e controles ActiveX.
H um relacionamento fundamental entre os esteretipos cliente e servidor de uma
pgina Web. Uma pgina servidor geralmente constri (monta) o resultado em uma pgina
cliente. Este relacionamento representado no modelo atravs de uma associao
estereotipada por <<build>>. A Figura 3-1 apresenta um exemplo de relacionamento entre
pginas Web, que indica qual pgina servidor responsvel pela construo de uma
determinada pgina cliente.
Captulo 3 Extenses de UML para Aplicaes Web
38
ListaLivros
<<C lient P age>>
ListarLivros
<<Server P age>>
<<build>>

Figura 3-1 Construo de uma pgina Cliente
Uma outra facilidade de algumas tecnologias de desenvolvimento de aplicaes Web a
habilidade de redirecionar a requisio de processamento para uma outra pgina servidor. Este
relacionamento representado no modelo atravs de uma associao estereotipada por
<<redirect>>. O redirecionamento uma caracterstica muito til para o reuso em aplicaes
Web. A Figura 3-2 apresenta um exemplo de redirecionamento de processamento entre
pginas servidor.
LogonHome
<<Server Page>>
Admi nHome
<<Server Page>>
<<redirect>>
GuestHome
<<Server Page>> <<redirect>>

Figura 3-2 Redirecionamento de processamento para uma pgina Servidor
Um relacionamento adicional que importante em projetos de aplicaes Web o hiper
link (link). As pginas cliente freqentemente contm links para outras pginas Web (pginas
cliente e/ou servidor) Este relacionamento representado no modelo atravs de uma
associao estereotipada por <<link>>. A Figura 3-3 apresenta um exemplo de
relacionamentos entre pginas Web, que indica quais pginas Web so referenciadas atravs
de link por uma pgina cliente.
AdminHome
<<Client Page>>
ManutencaoUsuarios
<<Client Page>>
ListaRelatorios
<<Clie nt Page>> <<link>>
<<li nk>>

Figura 3-3 Link entre pginas Web

Captulo 3 Extenses de UML para Aplicaes Web
39
Formulrio (Form)
So definidos esteretipos adicionais para o uso de formulrios HTML em aplicaes
Web. Os formulrios contm atributos adicionais que podem no ser apropriados no contexto
da pgina cliente inteira e possvel ter mltiplos formulrios em uma nica pgina cliente,
cada um apontando para uma ao diferente. Desta forma, os formulrios so representados
no modelo atravs de uma classe estereotipada por <<form>>.
Uma classe estereotipada por <<form>> tem como atributos os campos do formulrio.
Estes atributos so estereotipados para representar o tipo dos campos (entrada, lista, boto,
seleo, etc) no formulrio. A conteno a relao formal entre uma pgina cliente e um
formulrio, ou seja, pginas cliente contm formulrios. Isto representado no modelo atravs
da associao do tipo agregao entre a classe que representa a pgina cliente e a classe que
representa o formulrio.
Um relacionamento necessrio para identificar qual pgina Web processa os dados
submetidos por um formulrio. Este relacionamento representado no modelo atravs de uma
associao estereotipada por <<submit>>. A Figura 3-4 apresenta um exemplo da utilizao
de formulrios em aplicaes Web.
InformacaoComprador
<<Client Page>>
DadosComprador
<<input>> nome : String
<<input>> logradouro : String
<<input>> cidade : String
<<select>> estado : String
<<Form>>
- <<i nput>> - campos de e ntrada
- <<se lect>> - campo s de sel eo
( combo, l ista)
<<s ubmit>>
ProcessarInformacaoComprador
<<Server Page>>

Figura 3-4 Uso de Formulrios em aplicaes Web
Captulo 3 Extenses de UML para Aplicaes Web
40
Frame
Uma interface adicional (e elemento de projeto) disponvel em aplicaes Web o
frame. O frame permite a representao de mltiplas pginas Web ao mesmo tempo, e
permite ao projetista Web dividir uma janela do browser em subreas retangulares (panes)
que exibem diferentes pginas Web.
Os frames so implementados em HTML pela definio de um frameset. Um frameset
um tipo especial de pgina Web que divide sua rea de visualizao em mltiplas subreas,
com cada uma exibindo sua prpria pgina Web. Isto representado no modelo atravs de
uma classe estereotipada por <<frameset>>.
Cada uma das subreas de visualizao em uma pgina Web um target. Um target no
frameset um frame nomeado que outras pginas cliente podem requisitar atravs de pginas
Web. Isto representado no modelo atravs de uma classe estereotipada por <<target>>. O
relacionamento entre pginas cliente e um target representado no modelo atravs de uma
associao estereotipada por <<targeted link>>. A Figura 3-5 apresenta um exemplo do uso
de frames em aplicaes Web.
Conteudo
<<Target>>
Livro
<<Frameset>>
Indi ce
<<Client Page>>
Capitulo1
<<Client Page>>
<<targeted link>>
{target=Conteudo}
Introducao
<<Client Page>>
<<targeted li nk>>
{target=Conteudo}
Capitulo2
<<Client Page>>
<<targeted link>>
{target=Conteudo}

Figura 3-5 Uso de Frames em aplicaes Web
Captulo 3 Extenses de UML para Aplicaes Web
41
3.4 Extenso de UML para Modelagem Navegacional
O processo de construo Ad hoc para aplicaes Web foca no contedo e na
apresentao, com pequena ateno a estrutura navegacional. A qualidade de uma aplicao
Web depende no somente da riqueza do contedo e do projeto grfico de alta qualidade, mas
tambm de uma navegao bem estruturada.
Nesta seo, apresentada uma extenso de UML, proposta por N.Koch [Koch 01],
para modelagem da navegao e da apresentao de aplicaes Web. Esta extenso de UML
parte de uma metodologia para anlise e projeto de aplicaes Web [Baumeister 99,Hennicker
00], baseada no OOHDM Object Oriented Hypermedia Design Method [Rossi 96,Schwabe
96]. Esta metodologia trata separadamente o contedo, a navegao e a apresentao da
aplicao, atravs da execuo dos seguintes passos: Projeto Conceitual, Projeto
Navegacional e Projeto da Apresentao.
Projeto Conceitual
O objetivo deste passo capturar a semntica do domnio do problema e, desta forma,
produzir o Modelo Conceitual da aplicao, representado pelo diagrama de classes de UML.
As atividades do Projeto Conceitual consistem em: encontrar classes, especificar atributos e
operaes, definir associaes entre as classes, definir estruturas hierrquicas, encontrar
dependncias, identificar interfaces e definir restries. Tcnicas de modelagem como
agregao, composio, generalizao e especializao so usadas para obter esses propsitos.
A Figura 3-6 apresenta o Modelo Conceitual de uma aplicao Web que controla os servios
prestados por uma empresa.
Cli ente
nome : String
Departamento
nome : String
Pro jeto
nome : String
orcamento : Integer
logomarca : Image
1.. n 1.. n
1..n 1..n
Empregado
nome : String
e-mail : String
fotografia : Image
publicacoes : Set(String)
1..n 1..n
1..n 1..n
Empresa
nome : String
endereco : String
1..n 1..n
1.. n 1.. n

Figura 3-6 Modelo Conceitual da aplicao Controlador de Servios
Captulo 3 Extenses de UML para Aplicaes Web
42
Projeto Navegacional
O objetivo deste passo produzir o Modelo Navegacional da aplicao, que pode ser
considerado uma outra viso do Modelo Conceitual. Para tanto, so necessrios dois passos.
No primeiro passo o Modelo do Espao Navegacional definido e, no segundo passo, o
Modelo da Estrutura Navegacional construdo.
O Modelo do Espao Navegacional define uma viso do Modelo Conceitual mostrando
quais classes (chamadas classes navegacionais) podem ser visitadas atravs da navegao da
aplicao. Este modelo representado por um diagrama de classes de UML, e construdo
com classes estereotipadas por <<navigational class>> e com associaes estereotipadas por
<<direct navigability>>. A Figura 3-7 apresenta o Modelo do Espao Navegacional derivado
do Modelo Conceitual apresentado na Figura 3-6.
Projeto
no me : String
orcamento : I nteger
logomarca : I ma ge
<<na vigati onal clas s>>
Empregado
nome : String
e-mail : String
fotografia : Image
publicacoes : Set(String)
<<navigational class>>
1..n 1..n
Departamento
nome : String
<<navigational class>>
1..n 1..n
1..n 1..n
Empres a
nome : String
endereco : String
clientes : Set(String)
<<navigational class>>
1..n 1..n
1..n 1..n
1..n 1..n

Figura 3-7 Modelo do Espao Navegacional da aplicao Controlador de Servios
Para construo do Modelo do Espao Navegacional, o projetista de navegao deve
orientar-se pelas seguintes regras [Hennicker 00]:
1. Classes do Modelo Conceitual que so relevantes para a navegao so includas
como classes navegacionais no Modelo do Espao Navegacional. Se uma classe
conceitual no visitada no Modelo de Casos de Uso, ela irrelevante no processo
navegacional e, portanto, omitida no Modelo do Espao Navegacional (tal como a
classe Cliente do Modelo Conceitual apresentado na Figura 3-6).
Captulo 3 Extenses de UML para Aplicaes Web
43
2. Informaes requeridas das classes conceituais omitidas podem ser mantidas como
atributos de outras classes no Modelo do Espao Navegacional (tal como o atributo
clientes adicionado classe navegacional Empresa). Todos os outros atributos das
classes navegacionais so mapeados diretamente dos atributos da classe conceitual
correspondente. Os atributos das classes conceituais tidos como irrelevantes para a
apresentao so excludos no Modelo do Espao Navegacional.
3. Geralmente, novas associaes so adicionadas para navegao direta evitando
caminhos navegacionais de tamanho maior que um (tal como a associao
introduzida entre as classes navegacionais Empresa e Projeto). Cenrios descritos
pelo Modelo de Casos de Uso fornecem a base para escolha de navegaes diretas.
O Modelo da Estrutura Navegacional define a navegao da aplicao, isto , como os
objetos navegacionais (instncias de classes navegacionais) so visitados. Este modelo
derivado do Modelo do Espao Navegacional, e representado por um diagrama de classes,
que construdo utilizando elementos adicionais (esteretipos) para realizar navegao, tais
como primitivas de acesso (menus, ndices, query e guided tour) e contextos navegacionais. A
Figura 3-8 apresenta o padro de anlise para estrutura navegacional [Koch 01].
NavigationalClass
item 1
item 2
item 3
item 4
item 5
?
1
1
1
1
1
1
0..1
1
*
*
{XOR}
{ordered}
Index
Query
Menu
GuidedTour

Figura 3-8 Padro de Projeto para Estrutura Navegacional
Captulo 3 Extenses de UML para Aplicaes Web
44
A partir do Modelo do Espao Navegacional, o projetista de navegao deve criar o
Modelo da Estrutura Navegacional, seguindo o padro de projeto apresentado na Figura 3-8.
A Figura 3-9 apresenta o Modelo da Estrutura Navegacional da aplicao Web Controlador
de Servios.
{XOR}
Departamento
<<navigational class>>
PeloNomeEmpregado
PorDepartamento
<<index>>
BuscaP eloNo meEmpregado
PorDepartamento
<<search>>
11
Empregado
<<navigati onal class>>
1..n 1..n
0..1 0..1
MenuEmpregado
<<menu>>
11
MenuDepartamento
<<menu>>
11
11
11
PeloNomeDepartamento
<<index>>
1..n 1..n
PeloNomeEmpregado
<<index>>
1.. n 1.. n
Empresa
<<navigational class>>
MenuEmpresa
<<menu>>
11
11
11
PeloNomeProjeto
PorEmpregad o
<<index>>
11
PeloNomeProjetoPor
Departamento
<<index>>
11
Projeto
<<navigational class>>
1..n 1..n
1.. n 1.. n
Pelo NomeProjeto
<<guided tour>>
11
1..n 1..n

Figura 3-9 Modelo da Estrutura Navegacional da aplicao Controlador de Servios
Captulo 3 Extenses de UML para Aplicaes Web
45
Projeto de Apresentao
O objetivo deste passo modelar as interfaces grficas da aplicao, mostrando como a
estrutura navegacional apresentada ao usurio. O Projeto de Apresentao define a
aparncia dos ns navegacionais e identifica quais objetos da interface grfica ativam a
navegao. Para tanto, so construdos um Modelo de Apresentao Esttico e um Modelo de
Apresentao Dinmico.
O Modelo de Apresentao Esttico representado por diagramas de componentes de
UML, que descrevem como as interfaces grficas so construdas. As interfaces grficas so
definidas a partir de objetos de interface grfica. Um objeto de interface grfica pode ser um
objeto primitivo como texto, imagem e boto, ou uma composio desses objetos primitivos.
A Figura 3-10 apresenta partes do Modelo de Apresentao Esttico da aplicao Web
Controlador de Servios. O lado esquerdo da Figura 3-10 exibe a interface grfica abstrata
da classe navegacional Empresa, atravs do uso de frameset. O lado direito da Figura 3-10
exibe a organizao dos campos que compem a interface grfica da classe navegacional
Empregado.

<<anchor>>
Departamentos
<<anchor>>
Empregados
<<anchor>>
Projetos
<<presentational class>>
ArvoreNavegacional
Empresa
<<presentational class>>
Empresa
<<frameset>>
FramesetEmpresa



<<text>>
Nome
<<text>>
Email
<<image>>
Fotografia
<<collection>>
Publicacoes
<<presentational class>>
Empregado

Figura 3-10 Partes do Modelo de Apresentao Esttico da aplicao Controlador de Servios
O Modelo de Apresentao Dinmico representado por diagramas de seqncia ou
diagramas de estado de UML, que descrevem as colaboraes e comportamentos dos objetos
navegacionais e primitivas de acesso, ou seja, como a navegao ativada. O exemplo deste
modelo no apresentado, pois o aspecto dinmico das interfaces grficas no tratado neste
trabalho.
Captulo 3 Extenses de UML para Aplicaes Web
46
3.4.1 Esteretipos para Modelagem Navegacional
A seguir, so detalhados os esteretipos desta extenso de UML, para modelagem da
navegao e da apresentao de aplicaes Web.
Classe Navegacional (<<navigational class>>): representa a classe conceitual cujas
instncias so visitadas pelo usurio durante a navegao.
Navegao Direta (<<direct navigability>>): representa a associao (navegao) de
uma classe navegacional origem para uma classe navegacional destino.
ndice (<<index>>): primitiva de acesso que representa uma coleo de objetos que
possuem links para uma instncia de uma classe navegacional.
Guided Tour (<<guided tour>>): primitiva de acesso que representa um objeto que
fornece acesso seqencial a instncias de uma classe navegacional.
Query (<<query>>): representa um objeto que possui como atributo uma string que
representa uma operao, como por exemplo, uma operao de seleo, cujo
resultado pode ser mapeado em um link para uma instncia de uma classe
navegacional ou em um link para um ndice.
Menu (<<menu>>): primitiva de acesso que representa uma coleo de objetos que
possuem links para uma instncia de uma classe navegacional ou para uma outra
primitiva de acesso.
Contexto Navegacional (<<navigational context>>): representa uma seqncia
ordenada de navegao entre instncias de classes navegacionais.
Classe de Apresentao (<<presentational class>>): representa a apresentao de
uma classe navegacional ou de uma primitiva de acesso. Instncias de classes de
apresentao so containers de elementos de interface grfica como texto
(<<text>>), link (<<anchor>>), boto (<<button>>), imagem (<<image>>), udio
(<<audio>>), vdeo (<<video>>) e colees (<<collection>>).
Captulo 3 Extenses de UML para Aplicaes Web
47
3.5 O Framework W2000
Nesta seo, apresentado o framework W2000, proposto por L.Baresi [Baresi 01],
para projeto de aplicaes Web. Este framework uma integrao entre UML e HDM
Hypermedia Design Model [Garzotto 93], que consiste em: definir esteretipos e
customizao de diagramas para caracterizar HDM com UML, especificar guias para usar
UML para especificar alguns dos aspectos dinmicos e operacionais de aplicaes Web, e
refinar diagramas de Casos de Uso para descrever requisitos de alto nvel, relacionados a
aspectos funcionais e navegacionais.
O framework W2000 organiza as atividades do projeto em tarefas interdependentes,
conforme apresentado na Figura 3-11. Cada atividade produz um modelo (representado por
diagramas de UML), que descreve alguns aspectos da aplicao.
Anlise de Requisitos
Projeto
Estrutural
da Hiperbase
Projeto da
Estrutura da
Camada de Acesso
Projeto
Navegacional
da Hiperbase
Projeto
Navegacional da
Camada de Acesso
Projeto Navegacional
Projeto da Informao
Projeto de Hipermdia
Anlise de
Requisitos
Navegacionais
Anlise de
Requisitos
Funcionais
Projeto Funcional
P
r
o
j
e
t
o

d
a

V
i
s
i
b
i
l
i
d
a
d
e
P
r
o
j
e
t
o

d
a

E
v
o
l
u

o

d
o

E
s
t
a
d
o

Figura 3-11 Atividades do framework W2000
Nos pargrafos a seguir, so detalhadas as atividades do framework W2000,
apresentadas na Figura 3-11.
Captulo 3 Extenses de UML para Aplicaes Web
48
Anlise de Requisitos
Esta atividade estende a anlise de requisitos convencional para aplicaes hipermdia.
Ela consiste de duas sub-atividades: anlise de requisitos funcionais e analise de requisitos
navegacionais.
A Anlise de Requisitos Funcionais identifica as principais funcionalidades da
aplicao, e produz o Modelo de Casos de Uso Funcional, representado por um diagrama de
Casos de Uso de UML.
A Anlise de Requisitos Navegacionais destaca as estruturas navegacionais necessitadas
pelos diferentes usurios da aplicao, e produz o Modelo de Casos de Uso Navegacional,
representado por um diagrama de Casos de Uso de UML.
Projeto da Evoluo do Estado
Esta atividade complementa a anlise de requisitos e define como evoluir os contedos
da aplicao, atravs de diagramas de estado de UML. Esta atividade no obrigatria, mas
requerida para aplicaes com comportamentos complexos.
Projeto de Hipermdia
Esta atividade especifica as estruturas de informao (Projeto da Informao) e os
caminhos navegacionais (Projeto Navegacional) necessrios para as vrias classes de
usurios.
O Projeto de Hipermdia organizado em duas camadas distintas: a camada de
hiperbase e a camada de acesso. A camada de hiperbase define os objetos de informao base,
suas associaes e os caminhos navegacionais atravs deles. A camada de acesso organiza os
modos dos usurios iniciarem sua navegao dentro do espao de informao.
O Projeto da Informao especifica e organiza os contedos da aplicao, atravs do
Projeto Estrutural da Hiperbase e do Projeto da Estrutura da Camada de Acesso. J o Projeto
Navegacional, define como os usurios podem navegar nos elementos de informao e nas
estruturas de acesso, atravs do Projeto Navegacional da Hiperbase e do Projeto Navegacional
da Camada de Acesso. Todos os modelos produzidos so representados por diagramas de
classes de UML, construdos com esteretipos apropriados.
Captulo 3 Extenses de UML para Aplicaes Web
49
Projeto Funcional
Esta atividade especifica as principais funcionalidades da aplicao e estende a
especificao de funes padres com algumas peculiaridades especficas para aplicaes
hipermdia. Os projetistas devem construir cenrios para as principais funcionalidades, atravs
de diagramas de interao de UML.
Projeto da Visibilidade
Diferentes usurios, em geral, tm uma perspectiva diferente da aplicao, com relao
ao contedo e funcionalidades. O propsito desta atividade especificar quais
funcionalidades, estruturas de informao e caminhos navegacionais devem ser visveis e para
quem.
3.6 Consideraes sobre as Extenses de UML
A WAE (Web Application Extension), proposta por J.Conallen [Conallen 99b], define
um conjunto de esteretipos para modelagem de elementos especficos de aplicaes Web,
tais como, pgina cliente, pgina servidor, link, frame, formulrio, entre outros. Entretanto,
no atende a um aspecto bastante relevante em se tratando de aplicaes Web, a navegao.
A extenso de UML proposta por N.Koch [Koch 01], abordagem orientada a objeto
baseada no OOHDM, trata especificamente os aspectos de navegao e de apresentao de
aplicaes Web, porm, no define esteretipos para modelar elementos bsicos, como
pginas Web.
O framework W2000, proposto por L.Baresi [Baresi 01], uma caracterizao do HDM
usando o meta-modelo da UML, trata os aspecto de navegao e de visibilidade, entretanto,
no define um processo para tratar o aspecto de apresentao.
Captulo 3 Extenses de UML para Aplicaes Web
50
A Figura 3-12 apresenta uma sntese dos aspectos atendidos pelas extenses de UML.
Elementos Especficos Navegao Apresentao
WAE Atende Atende
Koch (OOHDM + UML) Atende Atende
Framework W2000 Atende
Figura 3-12 Aspectos atendidos pelas extenses de UML para aplicaes Web
Aps analisar os aspectos atendidos pelas extenses de UML para aplicaes Web,
conforme apresentado na Figura 3-12, chegamos as seguintes concluses:
A abordagem proposta por J.Conallen (WAE) define esteretipos para modelagem dos
elementos especficos de aplicaes Web, tais como pgina cliente, pgina servidor e script.
Alm disso, define esteretipos para modelagem da apresentao das interfaces grficas para
o usurio.
A abordagem proposta por N.Koch utiliza a UML para modelar os aspectos de
navegao e de apresentao de aplicaes Web. Para tanto, utiliza o processo definido pela
metodologia orientada a objetos para construo de sistemas hipermdia OOHDM.
O framework W2000, proposto por L.Baresi, utiliza a UML para caracterizar o HDM e,
desta forma, atende aos aspectos de navegao e visibilidade de aplicaes Web. Entretanto, o
HDM uma das mais antigas metodologias para construo de sistemas hipermdia e baseia-
se na notao E-R (entidade e relacionamento), ou seja, no orientada a objetos.
Diante deste panorama, a combinao entre as extenses de UML propostas por
J.Conallen (WAE) e N.Koch (OOHDM + UML), mostram-se adequadas para tratar os
aspectos especficos de aplicaes Web orientadas a objetos.
Captulo 3 Extenses de UML para Aplicaes Web
51
3.7 Consideraes Finais

Neste captulo foram apresentadas extenses de UML para aplicaes Web. Estas
extenses esto mais detalhadas em [Souza 01]. Posteriormente, foram feitas consideraes
sobre quais aspectos so atendidos por cada uma destas extenses. Chegamos concluso que
a combinao entre as abordagens propostas por J.Conallen (WAE) e N.Koch (OOHDM +
UML) mostram-se adequadas para atender as caractersticas especficas de aplicaes Web
orientadas a objetos.
No prximo captulo, apresentado o RUP (Rational Unified Process) metodologia
genrica para o desenvolvimento de sistemas. Para o caso de aplicaes Web esta
metodologia deve ser adaptada para melhor atender o desenvolvimento deste tipo de
aplicao. Parte desta adaptao consiste na criao de modelos que descrevam as
caractersticas especficas das aplicaes Web, utilizando para isso a combinao de
extenses de UML eleitas neste captulo.




53
Captulo 4
4 O RUP - Rational Unified Process
Um processo um conjunto de passos ordenados para alcanar um objetivo. Um
processo de software o conjunto de atividades e resultados associados que produzem um
produto de software [Sommerville 96].
O RUP (Rational Unified Process) um processo de software genrico para construo
de sistemas orientados a objetos. Seu objetivo garantir uma produo de software de alta
qualidade que atenda as necessidades dos usurios dentro do prazo e do oramento. O RUP
utiliza as melhores prticas de desenvolvimento de software moderno, de forma que ele pode
ser usado em uma grande faixa de projetos e organizaes.
Neste captulo, apresentado o RUP (baseado na verso 2000.02.10), bem como suas
caractersticas e fundamentos que orientam o processo de desenvolvimento de software.
Captulo 4 O RUP - Rational Unified Process
54
4.1 Viso Geral
O RUP (Rational Unified Process) um processo de software genrico que fornece uma
abordagem disciplinada para assinalar tarefas e responsabilidades dentro do contexto do
projeto, de modo a atender todo o ciclo de desenvolvimento de softwares de alta qualidade.
O RUP foi desenvolvido com o propsito de padronizar o processo de desenvolvimento
de software. Para tanto, utiliza o melhor de vrias tcnicas de desenvolvimento de software e
a UML linguagem de modelagem padro.
4.2 Conceitos Chaves do RUP
A seguir, so apresentados os conceitos chave utilizados para a explanao da
metodologia RUP.
Responsvel define o comportamento, as responsabilidades, e o papel
desempenhado por um indivduo ou uma equipe, dentro do contexto do projeto.
Atividade unidade de trabalho com um claro propsito, desempenhada por um
responsvel e que produz um resultado significante no contexto do projeto,
geralmente expressa em termos de criao e atualizao de artefatos.
Artefato pea de informao que produzida, modificada ou usada pelo processo
de desenvolvimento de software; pode ser um modelo, um elemento do modelo ou
um documento.
Fluxo seqncia de atividades que produz um resultado de valor observvel,
representado no RUP atravs de um diagrama de atividade de UML, sendo que cada
atividade deste diagrama corresponde a um subfluxo.
Subfluxo agrupamento de atividades, responsveis envolvidos, artefatos de
entrada e artefatos produzidos; utilizados para fornecer um alto nvel de abstrao e
para estruturar um fluxo.
Captulo 4 O RUP - Rational Unified Process
55
4.3 Caractersticas do RUP
O RUP baseado em componentes, o que significa que a aplicao a ser construda ser
formada por componentes interconectados atravs de interfaces bem definidas. As principais
caractersticas do RUP so: Dirigido a Casos de Uso; Centrado na Arquitetura; Iterativo e
Incremental. Nas subsees a seguir, essas caractersticas so detalhadas.
4.3.1 Dirigido a Casos de Uso
Um sistema de software construdo para servir aos usurios. Conseqentemente, para
se construir um sistema de sucesso deve-se conhecer o que o usurio espera e necessita do
sistema. Entende-se por usurio no somente pessoas, mas tambm outros sistemas
interconectados.
Uma possvel interao entre um usurio e o sistema pode ser representada por um Caso
de Uso. Um Caso de Uso um pedao de funcionalidade do sistema que retorna ao usurio
um resultado de valor observvel. Os Casos de Uso representam os requisitos funcionais e
juntos formam o Modelo de Casos de Uso que descreve todas as funcionalidades do sistema.
Os Casos de Uso no so somente uma ferramenta para especificao de requisitos. Eles
tambm dirigem o projeto, a implementao e os testes, ou seja, dirigem o processo de
desenvolvimento. Baseados no Modelo de Casos de Uso, projetistas criam uma srie de
modelos de projeto e implementao que realizam os Casos de Uso.
Dirigido a Casos de Uso significa que o processo de desenvolvimento segue um fluxo
de aes para realizao de Casos de Uso isto procede atravs da execuo dos fluxos do
processo. Desta forma, os Casos de Uso so especificados, projetados e no fim, so as bases
para os testadores construrem os casos de teste.
4.3.2 Centrado na Arquitetura
O conceito de arquitetura de software engloba os aspectos estticos e dinmicos mais
significantes do sistema. A arquitetura influenciada por muito fatores, tais como a
plataforma de software, blocos de construo disponveis para reuso, consideraes de
implantao, sistemas legados e requisitos no-funcionais. A arquitetura uma viso do
projeto como um todo, que torna visvel as caractersticas mais importantes do mesmo.
Captulo 4 O RUP - Rational Unified Process
56
O RUP fornece uma maneira metdica e sistemtica para projetar, desenvolver e validar
a arquitetura. So disponibilizados templates para descries arquiteturais sobre vises
arquiteturais
1
, estilos arquiteturais, regras de projeto, e restries.
Todo produto tem funes e forma. Estas duas foras devem ser balanceadas para que o
produto possa ter sucesso. No caso de software, funes correspondem a Casos de Uso e a
forma arquitetura.
4.3.3 Iterativo e Incremental
O desenvolvimento de um produto de software comercial pode continuar por vrios e
vrios anos. Por isso prtico que o trabalho seja dividido em pequenos ciclos ou mini-
projetos. Cada mini-projeto uma iterao que resulta em um incremento. Iteraes referem-
se a passos no fluxo de desenvolvimento, e incrementos a evolues do produto. Sucessivas
iteraes constroem os artefatos de desenvolvimento a partir do estado que eles foram
deixados ao final da iterao anterior.
Em toda iterao, o projetista identifica e especifica os Casos de Uso relevantes, cria um
projeto usando a arquitetura selecionada com guia, implementa o projeto em componentes e
verifica se os componentes satisfazem estes Casos de Uso. Se a iterao alcana suas metas, o
desenvolvimento ento, procede para a prxima iterao.
Os benefcios de um processo iterativo controlado so os seguintes: reduo do risco de
custos com despesas em um nico incremento; reduo do risco de atrasos no planejamento;
acelerao do ritmo de todos os esforos de desenvolvimento porque os desenvolvedores
trabalham mais efetivamente em direo a um resultado claro; reconhecimento de uma
realidade freqentemente ignorada as necessidades do usurio e os requisitos
correspondentes no podem ser completamente definidos de uma vez.

1
Viso da arquitetura do sistema com foco na estrutura, modularidade, componentes essenciais, e os principias
fluxos de controle.
Captulo 4 O RUP - Rational Unified Process
57
4.4 Ciclo de Vida do Software no RUP
O RUP repete uma srie de ciclos de evoluo durante o processo de desenvolvimento
de um sistema. Cada ciclo termina com uma verso do produto e consiste de quatro fases:
Concepo, Elaborao, Construo e Transio. Cada fase adicionalmente dividida em
iteraes, conforme apresentado na Figura 4-1.
Concepo Elaborao Construo Transio Evoluo
Verso 1
tempo
Um ciclo inicial de desenvolvimento
Concepo Elaborao Construo Transio Evoluo
Verso 2
tempo
O prximo ciclo de Evoluo

Figura 4-1 Ciclos e Fases do RUP
Fase de Concepo
Os objetivos desta fase so: estabelecimento do escopo do sistema e condies limites,
incluindo uma viso operacional, o critrio de aceitao e o que para ser esperado do
produto e o que no ; discriminao dos Casos de Uso crticos do sistema e restries;
exibio e/ou demonstrao de pelo menos uma arquitetura candidata; estimao do custo
total e prazo para o projeto inteiro; identificao dos potenciais riscos; preparao do
ambiente de suporte para o projeto.
As atividades essenciais desta fase so as seguintes:
Formular o escopo do projeto capturar o contexto, os requisitos mais importantes e
as restries, para elaborao do critrio de aceitao do produto final.
Planejar e preparar o negcio avaliar alternativas para gerenciamento de risco,
planejar o projeto, e identificar restries de custo e prazo.
Sintetizar uma arquitetura candidata avaliar alternativas entre fazer, comprar e
reusar, de modo que custo, prazo e recursos possam ser estimados.
Preparar o ambiente do projeto selecionar ferramentas para o desenvolvimento.
Captulo 4 O RUP - Rational Unified Process
58
Fase de Elaborao
Os objetivos desta fase so: garantir que a arquitetura e os requisitos estejam estveis, e
os riscos minimizados, para determinar custo e prazo para o restante do processo de
desenvolvimento; controlar os riscos arquiteturais do projeto; estabelecimento de uma
arquitetura e demonstrao de que esta arquitetura suporta os requisitos do sistema com custo
e tempo razovel; produo de um prottipo para identificao de deficincias de requisitos e
projeto, reuso de componente, e demonstrao para investidores, clientes, e usurios finais;
estabelecimento do ambiente de suporte.
As atividades essenciais desta fase so as seguintes:
Definir e validar a arquitetura.
Refinar a Viso
2
estabelecer um entendimento slido dos Casos de Uso mais
crticos que dirigem as decises de planejamento e de arquitetura.
Criar planos de iterao detalhados para a fase de Construo.
Refinar a arquitetura e selecionar componentes potenciais componentes so
avaliados e as decises de fazer/comprar/reusar so tomadas para determinar com
confiana o custo e o prazo da fase de Construo.
Fase de Construo
Os objetivos desta fase so: minimizar custos de desenvolvimento, otimizando recursos
e evitando re-trabalho; criao de verses usveis do sistema (alfa, beta, e outras verses de
teste); concluso da anlise, projeto, desenvolvimento e teste de todas as funcionalidades
requeridas; desenvolvimento iterativo e incremental de um produto que esteja pronto para a
transio para sua comunidade de usurios; decidir se o software e os usurios esto prontos
para a aplicao ser implantada; obteno de um certo grau de paralelismo no trabalho das
equipes de desenvolvimento.
As atividades essenciais desta fase so: gerenciamento de recursos; complemento do
desenvolvimento de componentes e testes; avaliao das verses do produto.

2
Viso do cliente/usurio sobre o produto a ser desenvolvido.
Captulo 4 O RUP - Rational Unified Process
59
Fase de Transio
Os objetivos desta fase so: beta testes para validar o sistema com relao s
expectativas dos usurios; beta testes relativos integrao com sistemas legados;
treinamento de usurios; obteno da concordncia dos stakeholders
3
de que o produto est
consistente com o critrio de aceitao.
As atividades essenciais desta fase so: execuo dos planos de implantao; finalizao
do material de suporte ao usurio final; criao de verses do produto; obteno de feedback
do usurio; melhoramento do produto baseado no feedback; disponibilizao dos produto para
os usurios finais.
4.5 Fluxos do RUP
Basicamente, h dois tipos de fluxo no RUP: fluxos de Processo e fluxos de Suporte,
conforme apresentado na Figura 4-2. Os fluxos de Processo correspondem s atividades de
desenvolvimento: modelagem de negcios, requisitos, anlise e projeto, implementao, testes
e implantao. Os fluxos de Suporte correspondem s atividades de gerenciamento e infra-
estrutura: gerenciamento de configurao e mudanas, gerenciamento de projeto e ambiente.

Figura 4-2 Fluxos do RUP

3
Todas as pessoas relacionadas a um determinado projeto, desde usurios at desenvolvedores, clientes,
gerentes, etc.
Captulo 4 O RUP - Rational Unified Process
60
Nas subsees a seguir, so apresentados os fluxos do RUP. Os fluxos de Suporte so
apresentados em menos detalhes, pois o foco desta dissertao est no processo de
desenvolvimento.
4.5.1 Fluxo de Modelagem de Negcio
Os propsitos deste fluxo, apresentado na Figura 4-3, so os seguintes: entendimento da
estrutura e da dinmica da organizao para a qual o sistema vai ser construdo; entendimento
dos problemas correntes da organizao e identificao de potenciais melhorias; garantir que
clientes, usurios finais, e desenvolvedores tenham um entendimento (viso) comum da
organizao; derivar os requisitos do sistema para dar suporte a organizao.

Figura 4-3 Fluxo de Modelagem de Negcios
Captulo 4 O RUP - Rational Unified Process
61
Este fluxo descreve como desenvolver uma viso da organizao, e baseado nesta viso
so definidos processos, papis, e responsabilidades desta organizao em um Modelo de
Casos de Uso de Negcio e um Modelo de Objetos de Negcio. Para complementar estes
modelos, so produzidos os artefatos Documento de Especificao Complementar de Negcio
e Glossrio de Negcio.
O Modelo de Casos de Uso de Negcio representa as funes que o negcio deve
desempenhar. Este modelo usado como entrada essencial para identificao de papis e
produtos na organizao e deve ser desenvolvido se houver a necessidade de clarificao do
contexto do negcio do sistema a ser desenvolvido. O Modelo de Objetos de Negcio
descreve a realizao dos Casos de Uso de negcio. O Documento de Especificao
Complementar de Negcio apresenta quaisquer definies necessrias do negcio no
includas no Modelo de Casos de Uso de Negcio ou no Modelo de Objetos de Negcio. O
Glossrio de Negcio define termos importantes usados na modelagem de negcio do projeto.
Este fluxo relaciona-se com outros fluxos da seguinte forma: o fluxo de Requisitos
utiliza os modelos de negcio como uma importante entrada para entendimento dos requisitos
do sistema; o fluxo de Anlise & Projeto utiliza entidades de negcio como uma entrada para
identificao de classes de entidade no Modelo de Projeto.
4.5.2 Fluxo de Requisitos
Os propsitos deste fluxo, apresentado na Figura 4-4, so os seguintes: estabelecimento
e manuteno de um acordo com os clientes e outros stakeholders sobre o que o sistema deve
fazer; proporcionar aos desenvolvedores do sistema um melhor entendimento dos requisitos
do sistema; definio dos limites do sistema; fornecer uma base para o planejamento de
contedos tcnicos das iteraes; fornecer uma base para estimao de custos e tempo para o
desenvolvimento do sistema; definio das interfaces grficas do sistema, focando nas
necessidades e objetivos dos usurios.
Captulo 4 O RUP - Rational Unified Process
62

Figura 4-4 Fluxo de Requisitos
Os principais artefatos produzidos por este fluxo, so os seguintes: Documento de
Viso, Documento de Necessidades dos Stakeholders, Modelo de Casos de Uso, Documento
de Especificao Complementar, Glossrio e um prottipo de interfaces grficas.
O Documento de Viso apresenta uma viso geral dos principais requisitos do projeto e
caractersticas do sistema. O Documento de Necessidades dos Stakeholders contm uma lista
sobre o que os diferentes stakeholders do projeto esperam que o sistema faa. O Modelo de
Casos de Uso descreve as funcionalidades do sistema e usado como entrada essencial para
as atividades de anlise, projeto e teste. O Documento de Especificao Complementar
descreve os requisitos no-funcionais do sistema. O Glossrio define termos importantes
usados no projeto. O prottipo de interfaces grficas serve para expor e testar a funcionalidade
e a usabilidade do sistema antes da etapa de projeto.
Captulo 4 O RUP - Rational Unified Process
63
Este fluxo relaciona-se com outros fluxos da seguinte forma: o fluxo de Modelagem de
Negcio fornece um contexto organizacional para o sistema; o fluxo de Anlise & Projeto tem
como entrada primria os requisitos; o fluxo de Teste baseia-se no Modelo de Casos de Uso e
no documento de Especificao Complementar para o planejamento dos testes do sistema.
4.5.3 Fluxo de Anlise & Projeto
Os propsitos deste fluxo, apresentado na Figura 4-5, so os seguintes: transformar os
requisitos em um projeto do sistema; definir uma arquitetura robusta para o sistema; adaptar o
projeto para o ambiente de implementao.

Figura 4-5 Fluxo de Anlise & Projeto
Captulo 4 O RUP - Rational Unified Process
64
Os principais artefatos produzidos por este fluxo so os seguintes: Modelo de Anlise,
Modelo de Projeto, Documento de Arquitetura de Software, Realizaes de Caso de Uso e
Modelo de Dados.
O Modelo de Anlise o modelo conceitual do sistema contendo as classes bsicas e
seus relacionamentos, o resultado da atividade de anlise dos Casos de Uso. O Modelo de
Projeto descreve as realizaes dos Casos de Uso, e serve como entrada essencial para as
atividades de implementao e teste. O Documento de Arquitetura de Software fornece uma
viso geral da arquitetura do sistema, atravs de vises arquiteturais que descrevem diferentes
aspectos do sistema. As Realizaes de Caso de Uso descrevem, atravs de diagramas de
interao, como Casos de Uso so realizados dentro do Modelo de Projeto, em termos de
colaborao de objetos. O Modelo de Dados descreve a representao lgica e fsica dos
dados persistentes do sistema.
Este fluxo relaciona-se com outros fluxos da seguinte forma: o fluxo de Modelagem de
Negcio fornece um contexto organizacional para o sistema; o fluxo de Requisitos fornece a
entrada primria para Anlise e Projeto; o fluxo de Teste testa o sistema projetado durante a
Anlise e Projeto.
4.5.4 Fluxo de Implementao
Os propsitos deste fluxo, apresentado na Figura 4-6, so os seguintes: definir a
organizao do cdigo, em termos de subsistemas de implementao organizados em
camadas; implementar classes e objetos em termos de componentes; testar os componentes
desenvolvidos como unidades; integrar os resultados produzidos pelos implementadores
individuais (ou times), em um sistema executvel.
Captulo 4 O RUP - Rational Unified Process
65

Figura 4-6 Fluxo de Implementao
Os principais artefatos produzidos por este fluxo, so os seguintes: Modelo de
Implementao, Plano de Construo da Integrao, Componentes e Subsistemas de
Implementao.
O Modelo de Implementao uma coleo de subsistemas de implementao e seus
componentes, necessrios para construir e gerenciar o sistema no ambiente de execuo. O
Plano de Construo da Integrao fornece um plano detalhado para integrao dos
componentes e subsistemas em uma iterao. Um Componente representa uma pea de cdigo
de software (fonte, binrio ou executvel) ou um agregado de outros componentes, como uma
aplicao com vrios executveis. Um Subsistema de Implementao uma coleo de
componentes e outros subsistemas de implementao, usado para estruturar o Modelo de
Implementao.
Captulo 4 O RUP - Rational Unified Process
66
4.5.5 Fluxo de Teste
Os propsitos deste fluxo, apresentado na Figura 4-7, so os seguintes: verificar a
integrao entre objetos; verificar a integrao formal de todos os componentes do software;
verificar se todos os requisitos foram corretamente implementados; identificar e garantir que
defeitos sejam resolvidos antes da implementao do software.

Figura 4-7 Fluxo de Teste
Os principais artefatos produzidos por este fluxo, so os seguintes: Plano de Teste,
Procedimento de Teste, Caso de Teste, Script de Teste, Modelo de Teste e Sumrio de
Avaliao de Teste.
O Plano de Teste contm informaes sobre os objetivos dos testes e identifica
estratgias e recursos a serem usados para implementar e executar os testes. Um Caso de
Teste um conjunto de entradas para o teste, condies de execuo, e resultados esperados.
Captulo 4 O RUP - Rational Unified Process
67
Um Procedimento de Teste um conjunto de instrues detalhadas para configurao,
execuo e avaliao de resultados de um Caso de Teste. Os Scripts de Teste so execues
automatizadas de um Procedimento de Teste. O Modelo de Teste uma representao do que
ser testado e como ser testado. O Sumrio de Avaliao de Teste organiza e apresenta os
resultados dos testes.
4.5.6 Fluxo de Implantao
O propsito deste fluxo, apresentado na Figura 4-8, a produo de verses do sistema
e a entrega do software para os usurios finais. representado pela execuo de vrias
atividades, tais como, produzir verses do software, empacotar, distribuir e instalar o
software, fornecer ajuda e assistncia aos usurios, planejamento e execuo de beta testes,
migrao de software ou dados j existentes e aceitao formal.

Figura 4-8 Fluxo de Implantao
Captulo 4 O RUP - Rational Unified Process
68
Os principais artefatos produzidos por este fluxo so: Plano de Implantao, Material de
Suporte ao Usurio Final e Materiais de Treinamento.
O Plano de Implantao determina como ser a transio do produto para os usurios,
com o propsito de garantir que os usurios recebam corretamente o sistema. Neste plano so
consideradas questes sobre a instalao, distribuio, treinamento e suporte. O Material de
Suporte ao Usurio Final assiste os usurios finais no aprendizado, uso, operao e
manuteno do produto. Os Materiais de Treinamento so os materiais que so usados nos
programas de treinamento ou cursos para assistir os usurios finais com o uso, operao e/ou
manuteno do produto.
4.5.7 Fluxo de Gerenciamento de Configurao e Mudanas
Este fluxo controla as mudanas e mantm a integridade dos artefatos do projeto. Neste
fluxo so identificados os itens de configurao, restries a mudanas nestes itens,
verificao de mudanas feitas nestes itens e a definio e gerenciamento das configuraes
dos itens, durante o processo de desenvolvimento. Os mtodos, processos e ferramentas
usados para fornecer gerenciamento de configurao e mudana para uma organizao podem
ser considerados como o sistema de CM (Configuration Management) da organizao.
Um sistema de CM manuseia informaes importantes sobre os processos de
desenvolvimento, implantao e manuteno, alm de conservar o acervo base de artefatos
potencialmente reusveis, resultantes da execuo destes processos. Este sistema essencial
para o controle dos numerosos artefatos produzidos pelas vrias pessoas que trabalham em um
mesmo projeto. O controle ajuda a evitar que os artefatos resultantes no estejam conflitantes
em relao a questes como atualizao simultnea, notificao limitada
4
e mltiplas verses.
4.5.8 Fluxo de Gerenciamento de Projeto
Os propsitos deste fluxo so os seguintes: fornecer um framework para gerenciamento
de projetos de software; fornecer guias prticos para planejamento, recrutamento de pessoal,
execuo e monitorao de projetos; fornecer um framework para o gerenciamento de riscos.

4
Quando um problema corrigido em artefatos compartilhados por vrios desenvolvedores, e alguns deles no
so notificados da mudana.
Captulo 4 O RUP - Rational Unified Process
69
Este fluxo foca principalmente nos aspectos importantes de um processo de
desenvolvimento iterativo: gerenciamento de riscos, planejamento de um projeto iterativo e
monitorao do progresso de um projeto iterativo (mtricas). Entretanto, este fluxo no atende
a todos os aspectos de gerenciamento de projeto, tais como, gerenciamento de pessoal,
gerenciamento de oramento e gerenciamento de contratos.
4.5.9 Fluxo de Ambiente
Este fluxo foca nas atividades necessrias para configurar o processo para um projeto. O
propsito das atividades de ambiente fornecer a organizao e um ambiente (processos e
ferramentas) de desenvolvimento do software, que daro suporte a equipe de
desenvolvimento. Este fluxo no atende questes como seleo, aquisio e construo de
ferramentas; e manuteno do ambiente de desenvolvimento.
4.6 Consideraes Finais
Neste captulo foram apresentadas as caractersticas do Rational Unified Process, bem
como o detalhamento de suas fases e fluxos. O RUP um processo de software genrico para
atender o desenvolvimento de vrios tipos de aplicao. Entretanto, esta generecidade faz com
que caractersticas especficas de alguns tipos de aplicao, como aplicaes Web, no sejam
devidamente contempladas. Diante deste panorama, o prximo captulo apresenta uma
extenso do fluxo de Anlise e Projeto para atender mais apropriadamente o desenvolvimento
de aplicaes Web.




71
Captulo 5
5 Extenso do Fluxo de Anlise e Projeto
do RUP para o Desenvolvimento de
Aplicaes Web

O RUP uma metodologia genrica que pode ser especializada para vrias classes de
sistemas de software e reas de aplicao. O desenvolvimento de aplicaes Web apresenta
caractersticas substancialmente diferentes do desenvolvimento de aplicaes tradicionais,
como questes sobre elicitao de requisitos, interface do usurio, arquitetura da aplicao,
diversidade tecnolgica, estratgias de teste e implantao; conforme apresentado por
A.Arajo [Arajo 01].
A maioria das diferenas entre o desenvolvimento de aplicaes Web e aplicaes
tradicionais se concentra na etapa de Anlise e Projeto. Nesta etapa, R.Pressman define em
[Pressman 92] que, ... tomam-se decises que em ltima anlise afetaro o sucesso da
implementao do software e, o que igualmente importante, a facilidade com que o software
ser mantido, tornando-o, assim, um passo fundamental do desenvolvimento de software. O
projeto o lugar onde a qualidade fomentada, servindo como molde para todos os passos de
desenvolvimento que se seguiro....
Diante da necessidade de um mtodo especifico para o desenvolvimento de aplicaes
Web, da importncia da etapa de Anlise e Projeto para o sucesso do desenvolvimento de uma
aplicao e da caracterstica do RUP de poder ser adaptado para os diferentes tipos de
aplicao, este captulo apresenta uma extenso do fluxo de Anlise e Projeto do RUP para o
desenvolvimento de aplicaes Web.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
72
5.1 Viso Geral
O propsito do fluxo de Anlise e Projeto transformar os requisitos em um Modelo de
Projeto implementvel, evoluir uma arquitetura robusta para o sistema e adaptar o projeto de
acordo com o ambiente de implementao. Este fluxo foi estendido para satisfazer as
necessidades especificas de aplicaes Web, principalmente no que se refere aos aspectos de
navegao e de apresentao da aplicao.
A extenso do fluxo de Anlise e Projeto do RUP para desenvolvimento de aplicaes
Web baseia-se no framework de Anlise e Projeto proposto por A.Arajo [Arajo 01] e em
extenses de UML propostas por J.Connalen [Conallen 99b] e por N.Koch [Koch 01].
5.2 Fluxo de Anlise e Projeto do RUP Estendido
O fluxo de Anlise e Projeto do RUP foi estendido para o domnio de aplicaes Web.
A extenso do fluxo atende a aspectos especficos, no observados originalmente, para
criao da Camada de Apresentao de uma aplicao Web desenvolvida no estilo
arquitetural de camadas. Alm disso, foram feitas recomendaes para atividades j existentes
deste fluxo, para satisfazer mais apropriadamente o desenvolvimento de aplicaes Web.
O fluxo de Anlise e Projeto do RUP foi estendido e adaptado para considerar mais
apropriadamente o desenvolvimento de aplicaes Web sem perder, contudo, as
caractersticas de adequabilidade a outros tipos de aplicao e a generecidade do processo.
Na Figura 5-1, um diagrama de atividades da UML utilizado para representar este
fluxo, sendo que cada atividade do diagrama corresponde a um subfluxo, que uma abstrao
da execuo de atividades do fluxo de Anlise e Projeto.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
73

Figura 5-1 Fluxo de Anlise e Projeto do RUP Estendido para Aplicaes Web
A primeira iterao de Elaborao foca na criao de uma arquitetura inicial para o
sistema, atravs do subfluxo Definir uma Arquitetura Candidata, para fornecer o ponto de
partida do principal trabalho de anlise. Se a arquitetura j foi produzida nas iteraes
anteriores ou em projetos anteriores, o foco do trabalho muda para o refinamento da
arquitetura, atravs do subfluxo Refinar a Arquitetura, e anlise do comportamento, atravs
da criao de um conjunto inicial de elementos que fornecem comportamento apropriado,
representado pelo subfluxo Analisar Comportamento. Se a aplicao for baseada na Web, o
novo subfluxo proposto Projetar Camada de Apresentao executado.
Aps os elementos iniciais serem identificados, eles so gradativamente refinados. Os
subfluxos Projetar Componentes e Projetar Componentes de Tempo Real produzem um
conjunto de componentes que fornecem comportamento apropriado para satisfazer os
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
74
requisitos do sistema. Em paralelo, as persistncias so tratadas no subfluxo Projetar Banco
de Dados.
5.3 Subfluxos do Fluxo de Anlise e Projeto Estendido
Os subfluxos do fluxo de Anlise e Projeto do RUP estendido (Figura 5-1) para o
desenvolvimento de aplicaes Web apresentam a seqncia de execuo das atividades e
seus objetivos, com o propsito de garantir subsdios para o fluxo de Implementao. Nas
subsees a seguir, so apresentados resumos dos subfluxos originais, bem como uma sntese
do novo subfluxo proposto para o projeto da camada de apresentao de aplicaes Web. As
atividades executadas (mencionadas) nesses subfluxos so apresentadas na seo 5.4.
5.3.1 Definir uma Arquitetura Candidata
A Figura 5-2 apresenta o detalhamento deste subfluxo, atravs da identificao das
atividades, responsveis, artefatos de entrada e artefatos produzidos.

Figura 5-2 Subfluxo Definir uma Arquitetura Candidata
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
75
Neste subfluxo criado um esqueleto inicial da arquitetura do sistema, definido um
conjunto inicial de elementos relevantes para a arquitetura, para serem usados como base para
a anlise, definido um conjunto inicial de Mecanismos de Anlise (padro que constitui uma
soluo comum para um problema comum, independente da implementao, como por
exemplo: mecanismos para manipular persistncia e erros ou falhas, e comunicao entre
processos.), definida a organizao do sistema, e so definidas as Realizaes de Casos de
Uso (descreve como um Caso de Uso realizado dentro do Modelo de Projeto, em termos de
colaborao de objetos, expressado por diagramas de interao de UML) para serem
utilizadas na iterao corrente. Alm disso, so identificadas as Classes de Anlise (representa
um Modelo Conceitual para coisas no sistema que tenham responsabilidades e
comportamento) dos Casos de Uso relevantes para a arquitetura do sistema, e so atualizadas
as Realizaes de Casos de Uso com as interaes das Classes de Anlise.
O subfluxo inicia com a definio de uma arquitetura inicial para o sistema, atravs da
atividade Analisar Arquitetura, depois os Casos de Uso relevantes para a arquitetura so
identificados e para cada um deles a atividade Analisar Caso de Uso realizada. O subfluxo
termina com a atualizao da arquitetura para refletir as adaptaes requeridas para satisfazer
o novo comportamento do sistema e para corrigir problemas arquiteturais identificados.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
76
5.3.2 Refinar a Arquitetura
A Figura 5-3 apresenta o detalhamento deste subfluxo, atravs da identificao das
atividades, responsveis, artefatos de entrada e artefatos produzidos.

Figura 5-3 Subfluxo Refinar a Arquitetura
Neste subfluxo fornecida a transio natural das atividades de anlise para as
atividades de projeto, atravs da identificao dos elementos de projeto (refinamento dos
elementos de anlise) apropriados e da identificao dos Mecanismos de Projeto (refinamento
dos Mecanismos de Anlise) apropriados. A arquitetura mantida consistente e ntegra,
possibilitando: a integrao dos novos elementos de projeto identificados na iterao corrente
com os elementos de projeto pr-existentes, e o mximo reuso de componentes disponveis. A
organizao da execuo do sistema descrita e o Modelo de Implementao
5
organizado
para fazer a transio entre projeto e implementao.

5
Coleo de subsistemas de implementao e seus componentes.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
77
O subfluxo inicia com foco nas atividades Identificar Mecanismos de Projeto e
Identificar Elementos de Projeto, e com grande nfase na atividade Incorporar Elementos
de Projeto Existentes para garantir que novos elementos no dupliquem as funcionalidades
de elementos existentes. Aps isso, conceitos de concorrncia e distribuio so introduzidos
nas atividades Descrever a Arquitetura em Tempo de Execuo e Descrever Distribuio,
respectivamente. O subfluxo termina com a execuo da atividade Revisar a Arquitetura.
5.3.3 Analisar Comportamento
A Figura 5-4 apresenta o detalhamento deste subfluxo, atravs da identificao das
atividades, responsveis, artefatos de entrada e artefatos produzidos.

Figura 5-4 Subfluxo Analisar Comportamento
Neste subfluxo, as descries comportamentais do sistema fornecidas pelos Casos de
Uso so transformadas em um conjunto de elementos sobre os quais o projeto deve se basear.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
78
O subfluxo inicia com workshops para anlise dos Casos de Uso, realizados na atividade
Analisar Caso de Uso. Posteriormente, os projetistas responsveis pela anlise dos Casos de
Uso em conjunto com os arquitetos do sistema fundem os resultados dos workshops na
atividade Identificar Elementos de Projeto. O subfluxo termina com a execuo da atividade
Revisar o Projeto.
5.3.4 Projetar Camada de Apresentao
A Figura 5-5 apresenta o detalhamento deste subfluxo, atravs da identificao das
atividades, responsveis, artefatos de entrada e artefatos produzidos.

Figura 5-5 Subfluxo Projetar Camada de Apresentao
Este subfluxo foi criado com o propsito de atender aos aspectos de navegao e de
apresentao, relacionados criao da Camada de Apresentao de uma aplicao Web, no
observados no fluxo de Anlise e Projeto original. Os objetivos deste subfluxo so identificar
a navegao das funcionalidades da aplicao e criar subsdios para o projeto das interfaces
grficas do usurio.
A execuo do subfluxo inicia com o processo de criao do Modelo Navegacional da
aplicao, atravs da realizao da atividade Projetar Navegao cujo objetivo identificar
como o usurio caminha (navega) na aplicao para utilizar as funcionalidades do sistema. O
subfluxo termina com a realizao da atividade Projetar GUI, com o objetivo de projetar as
interfaces grficas do usurio com base no Modelo Navegacional.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
79
5.3.5 Projetar Componentes
A Figura 5-6 apresenta o detalhamento deste subfluxo, atravs da identificao das
atividades, responsveis, artefatos de entrada e artefatos produzidos.

Figura 5-6 Subfluxo Projetar Componentes
Neste subfluxo, as definies dos elementos de projeto so refinadas. As Realizaes de
Casos de Uso so refinadas e atualizadas com base nos novos elementos de projeto
identificados. O projeto revisado de acordo com sua evoluo. Os elementos de projeto so
implementados como componentes e testados para verificar a funcionalidade e a satisfao
dos requisitos no nvel componente/unitrio.
O subfluxo inicia com o refinamento dos elementos de projeto, atravs das atividades
Projetar Classe e Projetar Subsistema. Posteriormente, as Realizaes de Casos de Uso
so atualizadas para contemplar o refinamento ou criao de elementos de projeto, atravs da
atividade Projetar Caso de Uso. O subfluxo termina com a execuo da atividade Revisar o
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
80
Projeto, para garantir que todos os comportamentos requeridos para o sistema estejam
suportados e que os elementos de projeto estejam prontos para implementao.
5.3.6 Projetar Componentes de Tempo-Real
A Figura 5-7 apresenta o detalhamento deste subfluxo, atravs da identificao das
atividades, responsveis, artefatos de entrada e artefatos produzidos.

Figura 5-7 Subfluxo Projetar Componentes de Tempo Real
O subfluxo similar a Projetar Componentes, apresentado na subseo 5.3.5. A
diferena que este subfluxo aplicado a projetos que utilizam o artefato Cpsula
6
como
elemento de projeto primrio, dentro do contexto de sistemas de tempo real ou sistemas
reativos.

6
Padro de projeto que representa um thread de controle encapsulado no sistema, representa a unidade primria
de concorrncia no sistema.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
81
5.3.7 Projetar Banco de Dados
A Figura 5-8 apresenta o detalhamento deste subfluxo, atravs da identificao das
atividades, responsveis, artefatos de entrada e artefatos produzidos.

Figura 5-8 Subfluxo Projetar Banco de Dados
Neste subfluxo so identificadas as classes persistentes do projeto, so projetadas as
estruturas de banco de dados apropriadas para armazenar estas classes, e so definidos
mecanismos e estratgias para armazenar e recuperar dados persistentes de modo a satisfazer
o critrio de performance do sistema.
O subfluxo inicia com a identificao das Classes de Projeto persistentes, atravs da
atividade Projetar Classe. Posteriormente, um Modelo de Dados criado, atravs da
atividade Projetar Banco de Dados, e o subfluxo termina com a execuo da atividade
Revisar o Projeto.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
82
5.4 Atividades do Fluxo de Anlise e Projeto Estendido
As atividades originais do fluxo de Anlise e Projeto do RUP foram estendidas com
recomendaes para satisfazer mais apropriadamente o desenvolvimento de aplicaes Web,
seguindo o framework de Anlise e Projeto proposto por A.Arajo [Arajo 01] apresentado
no Anexo C. Alm disso, foram criadas as atividades Projetar Navegao e Projetar GUI,
com o propsito de estruturar a criao da Camada de Apresentao de aplicaes Web.
Nas subsees a seguir, as atividades do fluxo de Anlise e Projeto estendido so
apresentadas. O responsvel pela atividade identificado e os propsitos da atividade,
juntamente com as extenses (recomendaes) para o desenvolvimento de aplicaes Web, se
houver, so descritos.
5.4.1 Analisar Arquitetura
Nesta atividade o Arquiteto deve definir uma arquitetura candidata para o sistema,
baseado na experincia obtida em sistemas similares; definir padres arquiteturais,
mecanismos chave e convenes de modelagem para o sistema (tipos de diagramas e
elementos de modelagem que devem ser usados, e as regras para o uso); definir a estratgia de
reuso e fornecer entrada para o processo de planejamento.
O framework de Anlise e Projeto proposto por A.Arajo [Arajo 01], conforme
apresentado no Anexo C Atividade Analisar Arquitetura, recomenda entre outras coisas a
utilizao do artefato Guidelines de Projeto Web para auxiliar na execuo desta atividade
para aplicaes Web. Este artefato fornece algumas recomendaes sobre pontos importantes
para a definio inicial da arquitetura, como definio de camadas, padres de distribuio,
Mecanismos de Anlise e identificao de abstraes chave. Alm disso, este artefato pode
ser atualizado durante todo o projeto e atravs do portflio de projetos da organizao,
registrando novas recomendaes ou boas prticas, que forem identificadas para o
desenvolvimento de aplicaes Web.
5.4.2 Identificar Mecanismos de Projeto
Nesta atividade o Arquiteto deve refinar os Mecanismos de Anlise em Mecanismos de
Projeto, baseado nas restries impostas pelo ambiente de implementao.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
83
As aplicaes Web tm sido desenvolvidas usando uma combinao de tecnologias de
orientao a objetos, cliente/servidor e Internet. Surge, ento, um grande nmero de opes de
infra-estrutura que levam a um ilimitado nmero de opes tecnolgicas. Desta forma, a
implementao de uma aplicao Web envolve um grande nmero de tecnologias e restries,
levando a um ambiente de implementao dos mais diversos.
Para aplicaes Web, conforme apresentado no Anexo C Atividade Projetar
Arquitetura Passo Identificar Mecanismos de Projeto, esta atividade deve dar maior
importncia s restries antes do refinamento dos Mecanismos de Anlise em Mecanismos
de Projeto, pois, assim sendo, o risco de opes tecnolgicas conflitantes ou pouco adequadas
a serem utilizadas para implementao da aplicao reduzido.
5.4.3 Identificar Elementos de Projeto
Nesta atividade o Arquiteto deve analisar as interaes das Classes de Anlise para
identificar elementos do Modelo de Projeto.
Esta atividade j atende s necessidades de aplicaes Web, pois como as aplicaes
tradicionais, o desenvolvimento de aplicaes Web baseado nos Casos de Uso que
descrevem as funcionalidades da aplicao e originam as Classes de Anlise.
5.4.4 Incorporar Elementos de Projeto Existentes
Nesta atividade o Arquiteto deve analisar interaes entre as Classes de Anlise para
encontrar Interfaces, Classes de Projeto e Subsistemas; refinar a arquitetura, incorporando
reuso onde possvel; identificar solues comuns para problemas usuais de projeto; e incluir
elementos do Modelo de Projeto significantes para a arquitetura na seo Viso Lgica do
Documento de Arquitetura de Software
7
.
Para aplicaes Web, conforme apresentado no Anexo C Atividade Projetar
Arquitetura Passo Identificar Oportunidades de Reuso, esta atividade deve dar maior
importncia ao reuso e ao desenvolvimento baseado em componentes para aplicaes Web,
devido ao tempo de desenvolvimento de uma aplicao Web (Web Time), que geralmente
crtico.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
84
5.4.5 Descrever a Arquitetura em Tempo de Execuo
Nesta atividade o Arquiteto deve analisar requisitos de concorrncia para identificar
processos, identificar mecanismos de comunicao entre processos, alocar recursos de
coordenao entre processos, identificar ciclos de vida do processo, e distribuir elementos do
modelo entre os processos.
Este atividade, conforme apresentado no Anexo C Atividade Descrever Concorrncia,
j atende s necessidades de aplicaes Web, pois a criao de processos, a alocao de
funcionalidades a estes processos e o seu gerenciamento uma tarefa comum a aplicaes que
utilizam a noo de concorrncia, sejam elas baseadas na Web ou no.
5.4.6 Descrever a Distribuio
Nesta atividade o Arquiteto deve descrever como a funcionalidade do sistema
distribuda atravs de ns fsicos, sendo requerida apenas para sistemas distribudos. A
distribuio de processos atravs de dois ou mais ns requer um exame dos padres de
comunicao entre processos do sistema. O alcance de benefcios reais para a distribuio
requer trabalho e planejamento cuidadoso. Uma aplicao Web naturalmente uma aplicao
distribuda, que tende a saturar a rede rapidamente caso no seja bem projetada.
A descrio da distribuio em aplicaes Web uma atividade crtica. A Internet
uma rede bastante complexa e qualquer sistema que a utilize deve considerar uma srie de
questes para que se tenha performance, segurana, confiabilidade e disponibilidade
necessrias.
Para aplicaes Web, conforme apresentado no Anexo C Atividade Descrever
Distribuio, esta atividade deve considerar questes como: desempenho do backbone,
balanceamento de carga, segurana em nvel de rede (firewall e proxy), espelhamento e
replicao, redundncia de dados e de processamento, interoperabilidade e interface com
outros sistemas.

7
Fornece uma viso geral compreensiva da arquitetura do sistema, usando diferentes vises arquiteturais para
descrever diferentes aspectos do sistema.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
85
5.4.7 Revisar a Arquitetura
Nesta atividade o Revisor da Arquitetura deve fazer o levantamento de alguns riscos
no percebidos ou no conhecidos; detectar alguma falha no projeto arquitetural (defeitos
arquiteturais so mais difceis de detectar e mais prejudiciais em longo prazo); detectar algum
conflito entre os requisitos e a arquitetura; avaliar uma ou mais qualidades arquiteturais
especficas como desempenho, confiabilidade, modificabilidade, segurana de acesso e
segurana de dados, e identificar a oportunidades de reuso.
Para aplicaes Web, conforme apresentado no Anexo C Atividade Revisar
Arquitetura, esta atividade deve realizar checklists para verificar os aspectos especficos que
foram considerados durante o projeto da arquitetura, de modo a fomentar a qualidade e a
aplicabilidade da arquitetura.
5.4.8 Analisar Caso de Uso
Nesta atividade, o Projetista deve identificar as classes que realizam um fluxo de
eventos dos Casos de Uso; distribuir o comportamento dos Casos de Uso para estas classes,
usando Realizaes de Caso de Uso; identificar responsabilidades, atributos e associaes das
classes e anotar o uso de Mecanismos Arquiteturais
8
.
Esta atividade adequada para o desenvolvimento de aplicaes Web, pois da mesma
forma que em aplicaes tradicionais, as classes que compem a aplicao Web so
determinadas a partir dos Casos de Uso e detalhadas superficialmente atravs da definio de
atributos, responsabilidades e associaes.
5.4.9 Projetar Caso de Uso
Nesta atividade, o Projetista deve refinar as Realizaes de Caso de Uso em termos de
interaes; refinar os requisitos nas operaes de Classes de Projeto; refinar os requisitos nas
operaes dos subsistemas e/ou suas interfaces e refinar os requisitos nas operaes das
cpsulas. Esta atividade apresenta-se adequada para o desenvolvimento de aplicaes Web.

8
Padres de estruturas, padres de comportamento, ou ambos. Representam solues concretas para problemas
encontrados freqentemente. No RUP, usado como um termo genrico para os mecanismos de anlise, projeto
e implementao.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
86
5.4.10 Projetar Subsistema
Nesta atividade, o Projetista deve especificar os comportamentos das interfaces dos
subsistemas em termos de colaboraes das classes contidas no subsistema; documentar a
estrutura interna do subsistema; definir realizaes entre as interfaces e as classes contidas e
determinar as dependncias com outros subsistemas. Esta atividade apresenta-se adequada
para o desenvolvimento de aplicaes Web.
5.4.11 Projetar Classe
Nesta atividade, o Projetista deve garantir que as classes providenciam o
comportamento que as Realizaes dos Casos de Uso requerem; garantir que este
comportamento suficiente para a implementao das classes; lidar com os requisitos no-
funcionais relacionados s classes e incorporar os Mecanismos de Projeto usados pelas
classes. Esta atividade apresenta-se adequada para o desenvolvimento de aplicaes Web.
5.4.12 Projetar Navegao
Nesta atividade, o Projetista deve criar o Modelo Navegacional da aplicao Web, com
o propsito de identificar os caminhos navegacionais da aplicao, ou seja, como o usurio
caminha (navega) na aplicao para utilizar as funcionalidades do sistema.
Esta atividade foi criada com o objetivo de atender aos aspectos de navegao da
aplicao e auxiliar o projeto das interfaces grficas do sistema. Esta atividade ser detalhada
no prximo captulo, juntamente com o mtodo proposto para criao do Modelo
Navegacional.
5.4.13 Projetar GUI (Graphic User Interface)
Nesta atividade, o Projetista Web deve definir a aparncia das interfaces grficas com o
usurio, com base no Modelo Navegacional da aplicao Web.
Esta atividade foi criada com o objetivo de melhor atender a criao das interfaces
grficas do usurio para aplicaes Web, e ser detalhada no prximo captulo.
Captulo 5 Extenso do Fluxo de Anlise e Projeto do RUP para o Desenvolvimento de Aplicaes Web
87
5.4.14 Projetar Banco de Dados
Nesta atividade, o Projetista de Banco de Dados deve garantir que os dados persistentes
sejam armazenados com consistncia e eficincia, e definir o comportamento a ser
implementado no banco de dados. Esta atividade apresenta-se adequada para o
desenvolvimento de aplicaes Web.
5.4.15 Projetar Cpsula
Nesta atividade, o Projetista de Cpsula elabora e refina as descries de uma cpsula
(unidade primria de concorrncia do sistema). Esta atividade executada apenas para o
desenvolvimento de aplicaes de tempo real.
5.4.16 Revisar o Projeto
Nesta atividade, o Revisor do Projeto deve verificar se o Modelo de Projeto cumpre os
requisitos do sistema e serve como uma boa base para a implementao; garantir que o
Modelo de Projeto consistente e que respeita as diretrizes gerais do projeto; e garantir que as
diretrizes do projeto cumprem seus objetivos.
Ao final da execuo do fluxo de Anlise e Projeto, os modelos construdos ou
atualizados durante a sua execuo devem ser revisados. Esta reviso deve considerar os
novos aspectos inseridos no fluxo para torn-lo mais apropriado ao desenvolvimento de
aplicaes Web.
5.5 Consideraes Finais
Neste captulo, foi apresentada a extenso do fluxo de Anlise e Projeto do RUP, para
atender mais apropriadamente o desenvolvimento de aplicaes Web. A principal
caracterstica desta extenso foi a criao do subfluxo Projetar Camada de Apresentao
com o objetivo de atender aos aspectos de navegao e de apresentao, bastante relevantes
em se tratando de aplicaes Web. Alm disso, foram feitas recomendaes para atividades j
existentes com base no framework de Anlise e Projeto proposto por A.Arajo [Arajo 01].
O prximo captulo apresenta um detalhamento do subfluxo Projetar Camada de
Apresentao e de suas atividades, bem como o mtodo proposto para criao do Modelo
Navegacional de uma aplicao Web.



89
Captulo 6
6 Detalhamento do Subfluxo Projetar
Camada de Apresentao

O fluxo de Anlise e Projeto do RUP foi adaptado para atender mais apropriadamente o
desenvolvimento de aplicaes Web, conforme apresentado no captulo 5. Esta adaptao foi
baseada no framework de Anlise e Projeto proposto por A.Arajo [Arajo 01], e possui
como principal caracterstica a criao de um novo subfluxo que atende aos aspectos de
navegao e de apresentao de uma aplicao Web.
O novo subfluxo chamado Projetar Camada de Apresentao possui como principais
objetivos: identificar a navegao das funcionalidades da aplicao e criar subsdios para o
projeto das interfaces grficas do usurio. A execuo deste subfluxo consiste na realizao
das atividades Projetar Navegao, cujo objetivo a criao do Modelo Navegacional da
aplicao, e Projetar GUI, cujo objetivo o projeto das interfaces grficas do usurio.
Neste captulo, o subfluxo Projetar Camada de Apresentao detalhado, juntamente
com suas atividades e artefatos. Alm disso, um mtodo proposto para criao do Modelo
Navegacional de uma aplicao Web, baseado nas extenses de UML propostas por
J.Conallen [Conallen 99b] e N.Koch [Koch 01].
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
90
6.1 Viso Geral
O propsito do subfluxo Projetar Camada de Apresentao atender aspectos no
observados no fluxo de Anlise e Projeto original e que so bastante relevantes em se tratando
de aplicaes Web. O primeiro aspecto atendido o navegacional, que consiste na
identificao de como o usurio caminha (navega) pela aplicao para utilizar as
funcionalidades. O segundo aspecto atendido o de apresentao, que consiste em como as
interfaces grficas do usurio so vistas (apresentadas).
Para tanto, faz-se necessria a criao do Modelo Navegacional, que possui como
propsitos: orientar a navegao da aplicao, servir de base para o projeto das interfaces
grficas do usurio e identificar os elementos Web
9
necessrios para criao da Camada de
Apresentao no fluxo de Implementao.
O Modelo Navegacional representado pelo diagrama de classes de UML com base nas
extenses de UML propostas por J.Conallen [Conallen 99b] e N.Koch [Koch 01], e o
processo de criao deste modelo orientado por um mtodo proposto, baseado na
metodologia para o desenvolvimento de sistemas hipermdia proposta por H.Baumeister
[Baumeister 99].
Desta forma, neste captulo so apresentados: o detalhamento do subfluxo Projetar
Camada de Apresentao e o mtodo proposto para criao do Modelo Navegacional de uma
aplicao Web.
6.2 O Subfluxo Projetar Camada de Apresentao
Este subfluxo tem como propsito estruturar a Camada de Apresentao de uma
aplicao Web com base no Modelo Navegacional. Ao final da execuo deste subfluxo, so
alcanados os seguintes objetivos: a navegao da aplicao definida, as interfaces grficas
do usurio so projetadas, e so identificados os elementos Web necessrios para a criao da
Camada de Apresentao da aplicao no fluxo de Implementao.

9
Elementos especficos para aplicaes Web, como pgina cliente, pgina servidor, scripts, entre outros.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
91
A Figura 6-1 apresenta o detalhamento do subfluxo Projetar Camada de
Apresentao, de forma que so identificadas as atividades realizadas e responsveis,
juntamente com os artefatos de entrada e os produzidos.

Figura 6-1 Detalhamento do Subfluxo Projetar Camada de Apresentao
A execuo do subfluxo inicia com o processo de criao do Modelo Navegacional da
aplicao, atravs da realizao da atividade Projetar Navegao cujo responsvel o
Projetista de Navegao. Para esta atividade ser realizada, so necessrios como entrada os
artefatos Modelo de Casos de Uso, Modelo de Anlise e Realizaes de Caso de Uso, que so
produzidos em fases anteriores do processo de desenvolvimento; e o Guia de Projeto
Navegacional, artefato criado para a orientar o projeto da navegao da aplicao.
O subfluxo termina com a realizao da atividade Projetar GUI (Graphic User
Interface) cujo responsvel o Projetista Web, com o objetivo de projetar as interfaces
grficas do usurio com base no Modelo Navegacional. Esta atividade produz o artefato
Templates GUI que so esboos das interfaces grficas do usurio, geralmente pginas
HTML.
Nas subsees a seguir, as atividades deste subfluxo so detalhadas. Os propsitos das
atividades so descritos e os artefatos necessrios para realizao de cada atividade so
detalhados, juntamente com os artefatos produzidos.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
92
6.2.1 A Atividade Projetar Navegao
Nesta atividade o Projetista de Navegao deve criar o Modelo Navegacional da
aplicao Web, com os seguintes propsitos: identificar como o usurio caminha (navega) na
aplicao para utilizar as funcionalidades, criar subsdios para o projeto das interfaces grficas
do usurio, e identificar os elementos Web necessrios para a criao da Camada de
Apresentao da aplicao no fluxo de Implementao.
Esta atividade utiliza como entrada alguns artefatos produzidos em fases anteriores do
processo de desenvolvimento, so eles: o Modelo de Casos de Uso que descreve as
funcionalidades que a aplicao Web fornece para os usurios, o Modelo de Anlise que
descreve as classes bsicas do sistema com seus atributos e associaes, e as Realizaes de
Caso de Uso que descrevem a colaborao entre objetos para os Casos de Uso. Alm disso,
foi criado o artefato Guia de Projeto Navegacional que fornece recomendaes para o projeto
da navegao de aplicaes Web.
Nos pargrafos a seguir, so detalhados os artefatos que servem de entrada para a
realizao desta atividade, bem como o artefato produzido.
Modelo de Casos de Uso
O Modelo de Casos de Uso descreve as funcionalidades que a aplicao fornece para os
usurios, e serve como contrato entre o cliente e os desenvolvedores. Inicialmente, este
modelo contempla os requisitos funcionais do sistema, e serve como entrada essencial para a
anlise e projeto arquitetural. Na fase de Concepo, usado para delimitar o escopo do
sistema, e durante as fases de Elaborao e Construo, refinado por fluxos de eventos mais
detalhados. Este modelo deve ser mantido sempre consistente com o Modelo de Projeto.
O Analista de Sistemas responsvel pela integridade deste modelo, bem como pela
garantia da sua corretude, consistncia, e legibilidade. O Modelo de Casos de Uso correto
quando ele descreve a funcionalidade do sistema, e somente esta funcionalidade.
O Modelo de Casos de Uso usado como entrada para realizao da atividade Projetar
Navegao, pois o Modelo Navegacional deve contemplar as navegaes necessrias para
satisfazer os Casos de Uso deste modelo.

Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
93
Realizaes de Caso de Uso
O artefato Realizaes de Caso de Uso descreve como um particular Caso de Uso
realizado dentro do Modelo de Projeto, em termos de colaborao de objetos, representado
por diagramas de interao da UML. Na fase de Elaborao, as Realizaes de Caso de Uso
so criadas para os Casos de Uso relevantes para a arquitetura. Na fase de Construo, as
Realizaes de Caso de Uso so criadas para os Casos de Uso restantes.
O Projetista de Casos de Uso responsvel pela integridade das Realizaes de Casos
de Uso e deve garantir que elas reflitam o comportamento adequado e correto do Caso de Uso
correspondente no Modelo de Casos de Uso, e que o fluxo de eventos do projeto esteja legvel
e que atenda seu propsito.
O artefato Realizaes de Caso de Uso usado como entrada para realizao da
atividade Projetar Navegao, pois o Modelo Navegacional deve contemplar as interaes,
entre o usurio e a aplicao, descritas neste artefato.
Modelo de Anlise
O Modelo de Anlise tambm chamado de Modelo Conceitual contm as Classes de
Anlise (bsicas) da aplicao, seus atributos e associaes. Este modelo o resultado do
processo de anlise dos Casos de Uso e uma abstrao do Modelo de Projeto.
O Modelo de Anlise criado na fase de Elaborao e atualizado na fase de Construo.
O Projetista responsvel pela integridade deste modelo, e deve garantir que sua manuteno
no estado corrente reflita uma abstrao do projeto.
O Modelo de Anlise usado como entrada para realizao da atividade Projetar
Navegao, pois o Modelo Navegacional uma variao deste modelo, com nfase nos
aspectos de navegao e de apresentao da aplicao.
Guia de Projeto Navegacional
O artefato Guia de Projeto Navegacional, apresentado em detalhes no Apndice A,
define regras que orientam a construo do artefato Modelo Navegacional de aplicaes Web.

Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
94
Modelo Navegacional
O Modelo Navegacional descreve a navegao da aplicao, ou seja, como o usurio
caminha (navega) na aplicao para utilizar as funcionalidades. Neste modelo so
identificados os elementos Web que representam as interfaces grficas da aplicao e os
elementos Web responsveis pela comunicao dessas interfaces grficas com o sistema. Este
modelo representado pelo diagrama de classes utilizando extenses de UML.
O Modelo Navegacional serve de base para o projeto das interfaces grficas da
aplicao e utilizado no fluxo de Implementao para a criao da Camada de Apresentao.
O Projetista de Navegao responsvel por manter este modelo sempre consistente com o
Modelo Conceitual da aplicao.
O Modelo Navegacional produzido pela realizao da atividade Projetar Navegao e
seu processo de criao orientado por um mtodo que ser apresentado na seo 6.3.
6.2.2 A Atividade Projetar GUI (Graphic User Interface)
Nesta atividade o Projetista Web deve projetar as interfaces grficas da aplicao, com
base no Modelo Navegacional. Esta atividade consiste em determinar a aparncia dos
elementos do Modelo Navegacional que representam as interfaces grficas do usurio. Para
garantir consistncia, a aparncia das interfaces grficas do usurio deve obedecer ao padro
de apresentao (fonte, cor, boto, etc.) adotado pela organizao. No pargrafo a seguir,
detalhado o artefato que produzido por esta atividade.
Templates GUI
Este artefato apresenta (descreve) a aparncia das interfaces grficas do usurio.
Geralmente, so pginas HTML com a representao grfica dos elementos definidos no
Modelo Navegacional, que representam as pginas cliente e formulrios da aplicao Web.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
95
6.3 O Mtodo para Criao do Modelo Navegacional
O mtodo proposto para criao do Modelo Navegacional de uma aplicao Web utiliza
conceitos, tais como primitivas de acesso, apresentados na extenso de UML proposta por
N.Koch [Koch 01], que por sua vez baseia-se no OOHDM. Para representar os elementos do
Modelo Navegacional, so utilizados esteretipos definidos na extenso de UML proposta por
J.Connalen [Conallen 99b] pois so especficos para o caso de aplicaes Web. Para
identificao de caminhos navegacionais, o mtodo proposto baseia-se na metodologia para
desenvolvimento de sistemas hipermdia apresentada em [Baumeister 99]. O mtodo proposto
define passos para criao do Modelo Navegacional, alm de padres de projeto navegacional
para satisfazer operaes de manuteno de objetos do sistema.
O mtodo contempla a modelagem da navegao de aplicaes Web que possam ter
funcionalidades como as de qualquer outro tipo de aplicao tradicional. Os passos
necessrios para criao do Modelo Navegacional so os seguintes: Identificar as Classes
Navegacionais, Identificar os Caminhos Navegacionais e Criar os Caminhos Navegacionais.
Nas subsees a seguir, estes passos so detalhados.
6.3.1 Primeiro Passo: Identificar as Classes Navegacionais
O processo de criao do Modelo Navegacional inicia com a identificao das classes
do Modelo de Anlise que so relevantes em termos de navegao. A identificao destas
classes, chamadas de classes navegacionais, orientada pelo Modelo de Casos de Uso e pelas
Realizaes de Casos de Uso. O Projetista Navegacional deve considerar apenas as classes
bsicas do Modelo de Anlise que necessitem de navegao; as classes bsicas que apenas so
referenciadas no Modelo de Anlise so reduzidas a atributos das classes que as referenciam,
no Modelo Navegacional.
As classes navegacionais so representadas no Modelo Navegacional fazendo-se
referncia ao mesmo nome da classe bsica correspondente no Modelo de Anlise. A Figura
6-2 apresenta o padro de projeto navegacional para representar as classes navegacionais, no
Modelo Navegacional de uma aplicao Web. O lado esquerdo da Figura 6-2 apresenta o
padro de projeto navegacional, utilizando esteretipos da extenso de UML proposta por
J.Conallen [Conallen 99b], j o lado direito apresenta o mesmo padro, porm, utilizando a
representao grfica dos esteretipos.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
96

Frame
<<Target>>
Menu
<<Client Page>>
Classe Navegacional
<<Frameset>>

Menu Frame
Classe
Navegacional


Figura 6-2 Padro de Projeto Navegacional para Classes Navegacionais
A seguir, descrito a funo (papel) de cada classe do padro de projeto navegacional
para classes navegacionais de uma aplicao Web, apresentado na Figura 6-2.
A classe chamada Classe Navegacional representa o fato de que, no browser, as
interfaces grficas do usurio so exibidas atravs de pginas cliente com mais de
um frame.
A classe Frame representa o frame principal das pginas cliente, no qual so
montadas as interfaces grficas do usurio, exibidas nos caminhos navegacionais
que satisfazem as funcionalidades oferecidas pela classe navegacional.
A classe Menu representa a pgina cliente responsvel por exibir ao usurio as
funcionalidades oferecidas pela Classe Navegacional, com seus respectivos links.
6.3.2 Segundo Passo: Identificar os Caminhos Navegacionais
Os caminhos navegacionais representam como o usurio caminha (navega) na aplicao
para utilizar as funcionalidades do sistema. Eles so identificados atravs das associaes
entre as classes bsicas do Modelo de Anlise. O Modelo de Casos de Uso utilizado pelo
Projetista de Navegao para verificar se todas as funcionalidades do sistema esto
contempladas na navegao, e as Realizaes de Caso de Uso so usadas para verificar se a
seqncia de eventos para a realizao (execuo) do Caso de Uso est contemplada e
obedecida pelo caminho navegacional.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
97
O sentido dos caminhos navegacionais entre classes navegacionais determinado pela
direo da associao entre as classes bsicas correspondentes no Modelo de Anlise,
entretanto, este sentido pode ser bidirecional. Para cada Classe Navegacional, so relevantes
apenas as associaes que a tm como origem e para cada uma dessas associaes, um
caminho navegacional criado entre as classes navegacionais origem e destino, dependendo
da multiplicidade na origem da associao.
A Figura 6-3 apresenta um exemplo de parte de um Modelo de Anlise com classes
bsicas e associaes. Este Modelo de Anlise mostra exemplos de associaes com os dois
tipos bsicos de multiplicidade (igual a um e maior que um) na origem, que influenciam o
aspecto navegacional de uma aplicao, ou seja, originam caminhos navegacionais distintos.
Docente
cpfDocente : String
nomeDocente : String
Turma
codigoTurma : Integer
qntdeVagas : Integer
1..n 1..n
Disciplina
codigoDisciplina : Integer
descricaoDisciplina : String
11

Figura 6-3 Exemplo de parte de um Modelo de Anlise
A seguir, so identificados os caminhos navegacionais observados para o Modelo de
Anlise apresentado na Figura 6-3.
Um caminho navegacional originado da associao entre as classes Turma e
Disciplina. Esta associao possui multiplicidade igual a um na origem, o que significa que
um objeto da classe Turma possui como atributo um objeto da classe Disciplina. Diante deste
panorama, so obtidas as seguintes concluses:
A interface grfica responsvel pela operao de incluso de objetos da classe
Turma deve possuir um campo para identificar o objeto da classe Disciplina. Este
campo pode ser representado por um campo simples para entrada, uma lista, ou um
link para uma funcionalidade que auxilie a busca de objetos da classe Disciplina.
A interface grfica responsvel pela operao de detalhamento dos objetos da classe
Turma deve possuir um campo que identifique o objeto contido da classe Disciplina,
com a opo de detalhamento atravs de link.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
98
Um caminho navegacional originado da associao entre as classes Turma e Docente.
Esta associao possui multiplicidade maior que um na origem, o que significa que um objeto
da classe Turma possui como atributo uma coleo de objetos da classe Docente. Diante deste
panorama, so obtidas as seguintes concluses:
Deve ser criada uma funcionalidade (oferecida pela classe Turma) cuja interface
grfica possa manipular (incluir, alterar, excluir) a coleo de objetos da classe
Docente que pertencem a um objeto da classe Turma.
A interface grfica responsvel pela operao de detalhamento dos objetos da classe
Turma deve possuir um campo do tipo link, que quando acionado faa referncia a
uma funcionalidade cujo propsito seja o de exibir atravs de uma estrutura de
ndice, a coleo de objetos da classe Docente que pertencem a um objeto da classe
Turma. Dependendo do tamanho da coleo de objetos, pode-se ter uma
funcionalidade intermediria que auxilie a busca dos objetos da coleo.
Pode-se ter outras estratgias (tipos) de implementao para os caminhos navegacionais
derivados das associaes entre as classes bsicas do Modelo de Anlise apresentado na
Figura 6-3. Alm dos caminhos navegacionais originados destas associaes, outros caminhos
navegacionais so necessrios para satisfazer as operaes de manuteno (incluso,
alterao, excluso e consulta) dos objetos das classes do sistema. Estes caminhos
navegacionais so detalhados na prxima subseo (6.3.3).
6.3.3 Terceiro Passo: Criar os Caminhos Navegacionais
O Modelo Navegacional contempla os caminhos navegacionais para satisfazer todas as
funcionalidades oferecidas pelas classes navegacionais. Estes caminhos navegacionais so
resultantes das associaes entre as classes bsicas do Modelo de Anlise conforme
apresentado na subseo 6.3.2 e, so criados para satisfazer as operaes de manuteno dos
objetos das classes do sistema.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
99
Os caminhos navegacionais que satisfazem as operaes de manuteno dos objetos das
classes do sistema seguem padres propostos de projeto navegacional, baseados no padro
arquitetural Thick Web Client
10
, proposto por J.Connalen [Conallen 99b]. Nos pargrafos a
seguir, esses padres propostos de projeto navegacional so detalhados.
Padro de Projeto Navegacional para operao de Incluso
A Figura 6-4 apresenta o padro de projeto para a modelagem navegacional da operao
de incluso dos objetos do sistema.
Resul ta doI ncl usao
<<Client P age>>
Inc lus ao
me todoInc luir ()
<<Server P age>>
<<bui ld>>
FormularioInc lusao
<<es tereotipo>> campo 1 : TipoCampo
<<es tereotipo>> campo n : TipoCampo
<<Form>>
<<submi t>>
ValidarInc lusao
<<ClientScript Object>>
TelaI ncluir
<<Client P age>>
<<include>>
{incluir}

Figura 6-4 Padro de Modelagem Navegacional para operao de Incluso
A seguir, detalhado a funo (papel) de cada classe e associao do padro de projeto
navegacional apresentado na Figura 6-4.
A classe TelaIncluir representa a pgina cliente responsvel por exibir a interface
grfica do usurio para incluso de objetos.
A classe FormularioInclusao representa o formulrio contendo os campos a serem
informados pelo usurio. Os campos so originados dos atributos das classes bsicas
e so representados atravs de atributos estereotipados (ver Anexo A) na classe
FormularioInclusao. O esteretipo de cada atributo (input, select, button, link, entre
outros) especifica como cada campo apresentado na interface grfica.
A associao entre a classe FormularioInclusao e a classe Inclusao representa a ao
de confirmao por parte do usurio ({incluir}) para a incluso do objeto no meio de
persistncia (geralmente, banco de dados) da aplicao.

10
Padro arquitetural para aplicaes Web que assume processamento no browser do usurio, ou seja, usado
em sistemas que utilizam scripts, applets ou controles ActiveX no lado cliente.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
100
A classe ValidarInclusao representa os scripts executados no cliente, responsveis
pela validao das informaes preenchidas pelo usurio.
A classe Inclusao representa a pgina servidor responsvel pela validao no
servidor das informaes vindas da interface grfica, bem como pela execuo da
operao de incluso do objeto no meio fsico de persistncia da aplicao. O
mtodo que chamado (acionado) para de fato realizar a operao de incluso
representado pela operao metodoIncluir da classe Inclusao.
A associao entre a classe Inclusao e a classe ResultadoInclusao representa a
construo do resultado do processamento no servidor no browser do usurio,
atravs de uma pgina cliente representada pela classe ResultadoInclusao.
Padro de Projeto Navegacional para as demais operaes de Manuteno
Este padro de projeto navegacional contempla as operaes de pesquisa, alterao e
excluso de objetos das classes bsicas na aplicao e, apresentado na Figura 6-5.
TelaPes quis ar
<<Client Page>>
FormularioPesquis a
<<estereotipo>> campo 1 : TipoCampo
<<estereotipo>> campo n : TipoCampo
<<Form>>
Resul tadoAl te rac ao
<<Client Page>>
Res ultadoExclusao
<<Cli ent Page>>
Alt era cao
metodoAlterar()
<<Server Page>>
<<bui ld>>
Exc lusao
metodoExc luir()
<<Server Page>>
<<build>>
FormularioDetalhamento
<<est ere oti po>> c ampo 1 : TipoCampo
<<est ere oti po>> c ampo n : TipoCampo
<<F orm>>
<<s ubmit>>
{alterar}
<<submi t>>
{excluir}
ValidarA tualizac ao
<<ClientSc ript Object>>
TelaDetalhar
<<Cli ent P age>>
<<include>>
Pes quisa
metodoPes quisar()
<<Server Page>>
Detalhamento
metodoDetalhar()
<<Server Page>>
<<build>>
FormularioIndice
<<estereotipo>> campo 1 : TipoCampo
<<estereotipo>> campo n : TipoCampo
<<Form>>
I ndice
<<Client Page>> <<bui ld>> <<link>>
{detalhar}
{pesquisar}
<<s ubmit>>

Figura 6-5 Padro de Modelagem Navegacional para operaes de Pesquisa, Alterao e Excluso
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
101
A seguir, detalhada a funo (papel) de cada classe e associao do padro de projeto
navegacional apresentado na Figura 6-5.
A classe TelaPesquisar representa a pgina cliente responsvel por exibir a interface
grfica do usurio para auxiliar a pesquisa de objetos.
A classe FormularioPesquisa representa o formulrio contendo um ou mais campos
a serem informados pelo usurio para auxiliar a pesquisa de objetos no meio de
persistncia da aplicao. Os campos so representados atravs de atributos
estereotipados na classe FormularioPesquisa. O esteretipo de cada atributo
especifica como cada campo apresentado na interface grfica.
A associao entre a classe FormularioPesquisa e a classe Pesquisa, representa a
ao de confirmao por parte do usurio ({pesquisar}) para pesquisa de objetos no
meio fsico de persistncia da aplicao, de acordo com os campos (parmetros)
informados.
A classe Pesquisa representa a pgina servidor responsvel pelo processamento no
servidor, da operao de pesquisa de objetos de acordo com os parmetros vindos da
interface grfica de pesquisa. O mtodo que chamado (acionado) para de fato
realizar a operao de pesquisa representado pela operao metodoPesquisar da
classe Pesquisa.
A associao entre a classe Pesquisa e a classe Indice representa a construo no
browser do usurio, da coleo de objetos retornados do processamento da operao
de pesquisa, organizados por uma estrutura de ndice, atravs de uma pgina cliente
representada pela classe Indice. A identificao dos objetos feita por seus atributos
mais significativos, que so representados atravs de atributos estereotipados da
classe FormularioIndice.
A associao entre a classe Indice e a classe Detalhamento representa a ao por
parte do usurio ({detalhar}) de selecionar um dos objetos da coleo para a
apresentao do seu detalhe.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
102
A classe Detalhamento representa a pgina servidor responsvel pelo processamento
no servidor, da operao de detalhar o objeto selecionado pelo usurio. O mtodo
que chamado (acionado) para de fato realizar a operao de detalhamento do
objeto representado pela operao metodoDetalhar da classe Detalhamento.
A associao entre a classe Detalhamento e a classe TelaAtualizar representa a
construo do detalhamento do objeto no browser do usurio.
A classe TelaDetalhar representa a pgina cliente responsvel por exibir o
detalhamento do objeto, e posteriores operaes de alterao e excluso.
A classe FormularioDetalhamento representa o formulrio contendo a coleo de
campos preenchidos com as informaes do objeto. Os campos so representados
atravs de atributos estereotipados na classe FormularioDetalhamento. O esteretipo
de cada atributo especifica como cada campo apresentado na interface grfica.
A classe ValidarAtualizacao representa os scripts executados no cliente,
responsveis pela validao das informaes do formulrio de detalhamento quando
acionada a operao de alterao.
A associao entre a classe FormularioDetalhamento e a classe Alteracao representa
a ao de confirmao por parte do usurio ({alterar}) para alterao do objeto no
meio fsico de persistncia da aplicao.
A classe Alteracao representa a pgina servidor responsvel pela validao no
servidor, das informaes vindas da interface grfica, bem como pela execuo da
operao de alterao do objeto no meio de persistncia da aplicao. O mtodo que
chamado (acionado) para de fato realizar a operao de alterao representado
pela operao metodoAlterar da classe Alteracao.
A associao entre a classe Alteracao e a classe ResultadoAlteracao representa a
construo do resultado do processamento no servidor no browser do usurio,
atravs de uma pgina cliente representada pela classe ResultadoAlteracao.
A associao entre a classe FormularioDetalhamento e a classe Exclusao representa
a ao de confirmao por parte do usurio ({excluir}) para excluso do objeto no
meio fsico de persistncia da aplicao.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
103
A classe Exclusao representa a pgina servidor responsvel pela validao no
servidor, das informaes vindas da interface grfica, bem como pela execuo da
operao de excluso do objeto no meio fsico de persistncia da aplicao. O
mtodo que chamado (acionado) para de fato realizar a operao de excluso
representado pela operao metodoExcluir da classe Exclusao.
A associao entre a classe Exclusao e a classe ResultadoExclusao representa a
construo do resultado do processamento no servidor no browser do usurio,
atravs de uma pgina cliente representada pela classe ResultadoExclusao.
A operao de pesquisa pode ser simplificada dependendo do contexto, pois se a
pesquisa for feita unicamente por um campo chave, o processo deve considerar apenas o
retorno de um objeto, desconsiderando a estrutura de ndices. Variaes ou adaptaes na
modelagem navegacional para as operaes de manuteno podem ser facilmente realizadas.
Aps a identificao dos caminhos navegacionais e das consideraes apresentadas na
subseo 6.3.2, bem como a apresentao dos padres de projeto navegacional para operaes
de manuteno (incluso, alterao, pesquisa e excluso), a Figura 6-6 apresenta o Modelo
Navegacional derivado do Modelo de Anlise apresentado na Figura 6-3.
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
104
ResultadoInclusaoTurma
<<Client Page>>
ResultadoAlteracaoTurma
<<Client Page>>
Resulta doExclusa oTurma
<<Client Page>>
IncluirTurma
incluirTurma()
<<Server Page>>
<<build>>
FrameTurma
<<Target>>
FormularioPesquisarTuma
<<select>> disciplina : Discipli na
<<Form>>
Turma(Navegacional)
<<Fra mes et>>
TelaPesquisarTurma
<<Client Page>>
TelaDocentesTurma
<<Cli ent Page>>
AlterarTurma
<<Server Page>>
<<build>>
ExcluirTurma
<<Server Page>>
<<build>>
IndiceDocentesTurma
<<Server Page>>
TelaDeta lharDis cipli na
<<Client Page>>
FormularioDetalharTurma
<<input>> codigoTurma : Integer
<<input>> qntdeVagas : Integer
<<select>> disciplina : Disciplina
<<Form>>
<<submit>>
<<submit>>
PesquisarDocentesTurma
pesquisarDocentesDaTurma()
<<Server Page>>
<<build>>
DetalharDisciplina
detalharDisciplina()
<<Server Page>>
<<build>>
FormularioIncluirTurma
<<input>> codigoTurma : Integer
<<input>> qntdeVagas : Integer
<<select>> disciplina : Disciplina
<<Form>>
<<submit>>
MenuTurma
<<Cli ent Page>>
<<link>>
<<link>>
Valida rInclusaoTurma
<<Cli entScript Object>>
TelaIncluirTurma
<<Client Page>>
<<li nk>>
<<include>>
Interface Grfica para
manipular os Docentes
de uma Turma
PesquisarTurma
pes qui sarTurmaPorDiscipli na()
<<Server Page>>
<<submit>>
DetalharTurma
detalharTurma()
<<Server Page>>
DocentesTurma
incluirDocentesDaTurma()
alterarDocentesDaTurma()
excluirDocentesDaTurma()
<<Server Page>>
FormularioDocentesTurma
<<select>> turma : Turma
<<select>> docente : Docente
<<Fo rm>>
<<submit>>
Formul ari oIndiceTurma
<<link>> codigoTurma : Integer
<<Form>>
Indi ce Turma
<<Cli ent Page>>
<<buil d>>
<<link>>
TelaDetalharTurma
<<Client Page>>
<<link>> <<link>>
<<build>>
ValidarAtualizacaoTurma
<<ClientScript Object>>
<<include >>

Figura 6-6 Exemplo de Modelo Navegacional
Captulo 6 Detalhamento do Subfluxo Projetar Camada de Apresentao
105

6.4 Consideraes Finais
Neste captulo, foi apresentado o detalhamento do subfluxo Projetar Camada de
Apresentao, cujo propsito atender aos aspectos de navegao e de apresentao, que so
de grande relevncia quando se trata de aplicaes Web. Ao final da execuo do subfluxo, os
desenvolvedores possuem os subsdios necessrios para criao da Camada de Apresentao
da aplicao, no fluxo de Implementao.
Neste captulo, foi tambm apresentado um mtodo proposto para a criao do Modelo
Navegacional de uma aplicao Web, baseado na metodologia para desenvolvimento de
sistemas hipermdia proposta por H.Baumeister [Baumeister 99], e em extenses de UML
propostas por J.Connalen [Conallen 99b] e N.Koch [Koch 01].
O prximo captulo apresenta a validao do subfluxo proposto, atravs de sua
aplicao a um estudo de caso realizado sobre a aplicao Web SIG@UFPE (Sistema de
Informaes e Gesto Acadmica da UFPE).



107
Captulo 7
7 Estudo de Caso A Aplicao Web
SIG@UFPE

A extenso do fluxo de Anlise e Projeto do RUP para o desenvolvimento mais
apropriado de aplicaes Web explorou as caractersticas da metodologia de adequabilidade a
diferentes tipos de aplicao e generecidade do processo, e consistiu na adaptao de
atividades j existentes e na criao de um novo subfluxo para atender aspectos no
observados originalmente, relacionados criao da Camada de Apresentao da aplicao.
Para tanto, novas atividades e artefatos foram criados e, portanto, devem ser validados atravs
de um estudo de caso, com o propsito de verificar suas adequaes no processo e seus
benefcios.
Neste captulo, um estudo de caso apresentado com nfase no detalhamento da
execuo do subfluxo Projetar Camada de Apresentao. Para isto, os artefatos que servem
como base para realizao das atividades deste subfluxo, produzidos em fases anteriores do
fluxo de Anlise e Projeto, so apresentados, bem como um resumo sobre as caractersticas da
aplicao.
A aplicao Web utilizada como estudo de caso o SIG@UFPE (Sistema de
Informao e Gesto Acadmica da UFPE), desenvolvido no padro arquitetural de camadas,
utilizando Java como linguagem de programao e JSP/Servlets na Camada de Apresentao.
Esta aplicao est sendo desenvolvida sob a gerncia e coordenao do Ncleo de
Tecnologia da Informao desta universidade.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
108
7.1 Viso Geral
A extenso do fluxo de Anlise e Projeto do RUP para o desenvolvimento de aplicaes
Web consistiu na criao de um novo subfluxo para atender aspectos relacionados criao
da Camada de Apresentao da aplicao, tendo como base o artefato Modelo Navegacional.
Para tanto, surgiu a necessidade de orientaes para a criao deste artefato. Desta forma, na
seo 6.3, um mtodo para criao do Modelo Navegacional foi proposto, baseado nas
extenses de UML propostas por J.Conallen [Conallen 99b] e N.Koch [Koch 01].
Alm da criao de um novo subfluxo, atividades j existentes do fluxo de Anlise e
Projeto foram adaptadas (estendidas) para satisfazer, mais apropriadamente, as necessidades
do desenvolvimento de aplicaes Web, com base no framework de Anlise e Projeto
proposto por A.Arajo [Arajo 01].
Diante deste panorama, o estudo de caso tem como objetivo validar a viabilidade da
proposta de extenso do fluxo de Anlise e Projeto. Entretanto, parte desta extenso baseou-se
e j foi validada no framework de Anlise e Projeto proposto por A.Arajo [Arajo 01]. Desta
forma, o estudo de caso apresentado neste captulo tem como foco a execuo do novo
subfluxo e do mtodo proposto para a criao do Modelo Navegacional da aplicao.
7.2 Preparao do Ambiente
Os artefatos apresentados neste estudo de caso so modelos de UML produzidos atravs
da ferramenta de modelagem de sistemas Rational Rose (verso 2001.03.00). Esta ferramenta
precisou ser configurada para incorporar as extenses de UML utilizadas no Modelo
Navegacional, bem como o mtodo proposto para criao deste artefato.
No caso das extenses de UML, foram feitas configuraes na ferramenta Rational
Rose para que os componentes do diagrama de classes (classes, associaes e atributos)
pudessem ser estereotipados (inclusive com a representao grfica) para expressar os
elementos do Modelo Navegacional.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
109
A ferramenta Rational Rose foi tambm configurada para incorporar uma nova
funcionalidade a criao do Modelo Navegacional. Para tanto, foi elaborado um programa
escrito em uma linguagem baseada em scripts, que manipula uma API (Application Program
Interface) denominada REI (Rational Extensibility Interface), fornecida pela ferramenta. Este
programa baseia-se no mtodo proposto para criao do Modelo Navegacional (seo 6.3).
Desta forma, solicitado como entrada o Modelo de Anlise, e baseado nos componentes
deste modelo (classes e seus atributos, associaes e suas multiplicidades) criada uma nova
viso com nfase nos aspectos de navegao e de apresentao o Modelo Navegacional,
que, posteriormente, necessita de um refinamento por parte do projetista da aplicao.
Na seo a seguir, a aplicao que serviu de estudo de caso detalhada.
7.3 A Aplicao Web SIG@UFPE
A informao fator primordial para o planejamento e execuo de aes com o
propsito de melhorar os servios oferecidos por uma instituio de ensino superior. Desta
forma, faz-se necessria, a criao de um sistema de informao robusto que possibilite, entre
outras coisas, a descentralizao e maior agilidade dos processos na instituio de ensino.
Diante deste panorama, a aplicao Web SIG@UFPE visa atender, num primeiro momento, o
principal servio oferecido pela universidade, que o ensino em todos os nveis, ou seja,
graduao, ps-graduao e extenso.
7.3.1 Objetivos da Aplicao
O sistema de informao e gesto acadmica da UFPE est sendo desenvolvido em
mdulos que correspondem a etapas (fases) do ano letivo, ou seja, planejamento de matrcula,
matrcula, acompanhamento e encerramento de perodo, entre outras funcionalidades, como
integralizao curricular, concluso de curso e emisso de documentos oficiais como
diplomas e certificados.
Inicialmente, seguindo como prioridade a ordem cronolgica das etapas, foi
desenvolvido o mdulo do sistema que abrange as fases de planejamento de matrcula e
matrcula. Para tanto, foi tambm necessrio o desenvolvimento de subsistemas, basicamente
de cadastros, com o propsito de controlar aspectos relacionados estrutura (espao) fsica e
organizacional da instituio, bem como os recursos humanos.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
110
Portanto, o estudo de caso tem como foco algumas funcionalidades do mdulo de
planejamento de matrcula e matrcula. Este mdulo possui, como principais objetivos,
auxiliar e controlar o planejamento da matrcula com a finalidade de criar a infra-estrutura
necessria para a matrcula, bem como possibilitar a matrcula descentralizada, podendo o
prprio discente realizar sua matrcula atravs da Internet.
7.3.2 Usurios da Aplicao
Os usurios da aplicao Web SIG@UFPE so toda a comunidade acadmica da
universidade, mais os servidores responsveis pela operacionalizao das aes que dizem
respeito ao ensino nos nveis de graduao, ps-graduao e extenso. Diante deste panorama,
um grande nmero de perfis funcionais do sistema identificado, correspondendo s
diferentes funes que so relevantes no contexto do ensino.
Para o mdulo de planejamento de matrcula e matrcula que est sendo usado como
base para o estudo de caso, os principais perfis funcionais so os seguintes:
Docente responsvel por ministrar atividades acadmicas em que so especialistas,
nos trs nveis de ensino da universidade.
Discente possui vnculo em um ou mais cursos oferecidos pela universidade; cada
vnculo obtido atravs de algum meio de seleo, dependendo do nvel de ensino.
Tcnico Administrativo responsvel pela operacionalizao e controle das
atividades administrativas referentes ao ensino.
Coordenador docente responsvel pela coordenao de um curso ou rea de ensino
da universidade.
Chefe de Departamento docente responsvel pela gerncia (chefia) de um
departamento (rgo gerenciador de um ou mais cursos).
Observando os tipos de perfis funcionais da aplicao descritos acima, nota-se que um
mesmo usurio pode ter mais de um perfil funcional no sistema, ou seja, visibilidades
diferentes com relao s funcionalidades. Desta forma, foi necessrio o desenvolvimento de
um subsistema de controle de acesso robusto o suficiente, para atender esta e outros tipos de
situao, no que diz respeito ao acesso s funcionalidades da aplicao.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
111
7.3.3 Principais Funes da Aplicao
A aplicao Web SIG@UFPE possui como macro funes, realizar (atender) as etapas
(fases) do ano letivo da universidade. Como o foco do estudo de caso o mdulo que controla
as fases de planejamento de matrcula e matrcula, so descritas nos pargrafos a seguir,
algumas das principais funes deste mdulo.
Especificao das Atividades Acadmicas a Ofertar
Consiste em o coordenador e o chefe de departamento especificarem um conjunto de
atividades acadmicas (componente curricular tal como disciplina eletiva, disciplina
obrigatria e estgio) a ofertar no perodo, baseados na obrigatoriedade curricular e em
informaes estatsticas de perodos anteriores.
Inteno de Matrcula
Tambm chamada de pr-matrcula, consiste em o discente manifestar a inteno de
cursar uma ou mais atividades acadmicas do tipo eletivas, ofertadas pelo departamento
responsvel pelo curso para o perodo.
Definio das Atividades Acadmicas Ofertadas
Consiste em o coordenador e o chefe de departamento definirem de forma definitiva as
atividades acadmicas ofertadas para o perodo, com base nas estatsticas da inteno de
matrcula dos discentes.
Criao de Turmas e Subturmas
Consiste em o coordenador ou tcnico administrativo criarem as turmas para o perodo,
especificando a atividade acadmica, espao fsico (salas), horrios nos dias da semana,
quantidade de vagas e professor(es) ministrante(s). Para alguns casos, como por exemplo,
quantidade de vagas muito grande e limitao do espao fsico, algumas turmas so divididas
em subturmas independentes uma das outras.
Matrcula em Atividade Acadmica
Consiste em o discente realizar matrcula em atividades acadmicas que no originam a
criao de turma, como estgios e congressos, ou seja, no necessitam de espao fsico e
horrio permanente.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
112
Matrcula em Turma
Consiste em o discente realizar matrcula em turmas criadas para o perodo, sendo que
esta ao pode estar sujeita a anlise de prioridade de acordo com a situao do discente, caso
haja maior procura que a oferta.
7.4 A Execuo do Subfluxo Projetar Camada de Apresentao
A funcionalidade Criao de Turmas e Subturmas foi eleita para ser detalhada
levando em considerao suas caractersticas e grau de complexidade, que se mostram
adequados para a exemplificao da execuo do subfluxo Projetar Camada de
Apresentao.
A execuo deste subfluxo consiste na realizao das atividades Projetar Navegao e
Projetar GUI. Para tanto, alguns artefatos que so produzidos em fases anteriores do processo
de desenvolvimento so necessrios. Na prxima subseo, estes artefatos so apresentados.
7.4.1 Artefatos Base para Execuo do Subfluxo
Nos pargrafos a seguir, so apresentados os artefatos Modelo de Casos de Uso,
Realizaes de Caso de Uso e Modelo de Anlise ou Conceitual, para contemplar (satisfazer)
a funcionalidade Criao de Turmas e Subturmas da aplicao Web; e que servem de
entrada (base) para criao do Modelo Navegacional, que por sua vez o responsvel pela
estruturao da Camada de Apresentao.
Modelo de Casos de Uso
O Modelo de Casos de Uso usado como entrada essencial para as atividades de
anlise, projeto e testes, e tambm bastante relevante para a criao do Modelo
Navegacional, pois usado para verificar se todos os Casos de Uso so satisfeitos e esto
contemplados na Camada de Apresentao que a responsvel pela interao entre o usurio
e a aplicao.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
113
A Figura 7-1 apresenta o Modelo de Casos de Uso usado como ponto de partida para o
desenvolvimento do estudo de caso para o projeto da Camada de Apresentao. Neste
modelo, os Casos de Uso relevantes para o entendimento da pequena parte da aplicao Web
usada no estudo de caso so identificados, juntamente com os atores que interagem com as
funcionalidades da aplicao representadas por esses Casos de Uso.
Especificar Docentes Ministrantes
Coordenador
Especificar Atividade Acadmica
Criar Turmas e Subturmas
<<include>>
Chefe de Departamento

Figura 7-1 Modelo de Casos de Uso da funcionalidade Criao de Turmas e Subturmas
A seguir, so descritos os Caso de Uso do modelo apresentado na Figura 7-1.
Especificar Atividade Acadmica: o coordenador especifica (define) os
componentes curriculares que sero ofertados no perodo letivo atravs de uma
atividade acadmica, baseado na obrigatoriedade curricular e em informaes
estatsticas do processo de inteno de matrcula (pr-matrcula) dos discentes.
Criar Turmas e Subturmas: o coordenador e/ou chefe de departamento cria
turmas para as atividades acadmicas que necessitam de espao fsico (salas), e
horrios permanentes nos dias da semana. A turma pertence a um turno e de um
tipo (fixa ou varivel com relao ao nmero de discentes). Para cada turma
definido: a natureza (terica ou prtica), o nmero de aulas, carga horria e
quantidade de vagas. A turma dividida em subturmas perante algumas situaes
como diviso para aulas prticas, grande demanda de alunos e limitao do espao
fsico. A turma que possui subturmas pode ter alunos matriculados ou no, no
segundo caso a turma chamada de agregadora.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
114
Especificar Docentes Ministrantes: o coordenador e/ou chefe de departamento
especifica o(s) docente(s) responsvel(eis) por ministrar a atividade acadmica para
uma turma, juntamente com a carga horria. O docente candidato a ministrar a
atividade acadmica dependendo da sua habilitao (especializao) no contedo do
componente curricular vinculado.
Realizaes de Caso de Uso
O artefato Realizaes de Caso de Uso descreve o comportamento dinmico de um
Caso de Uso, ou seja, descreve como um particular Caso de Uso realizado dentro do Modelo
de Projeto, em termos de colaborao de objetos. O Modelo Navegacional deve contemplar
(satisfazer) as interaes do usurio com a aplicao, descritas neste artefato.
A Figura 7-2 apresenta as Realizaes do Caso de Uso Criar Turmas e Subturmas,
representado por um diagrama de seqncia de UML que, conceitualmente, enfatiza a
ordenao no tempo das mensagens. Para simplificar o entendimento, devido relao de
include dos Casos de Uso do modelo apresentado na Figura 7-1, as Realizaes do Caso de
Uso Especificar Docentes Ministrantes tambm esto contempladas neste diagrama de
seqncia.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
115

:

C
o
o
r
d
e
n
a
d
o
r
T
e
l
a
E
s
p
e
c
i
f
i
c
a
r
T
u
r
m
a
T
e
l
a
I
n
c
l
u
i
r
T
u
r
m
a
C
o
n
t
r
o
l
a
d
o
r
M
a
t
r
i
c
u
l
a
A
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a
C
o
n
t
r
o
l
a
d
o
r
E
s
t
r
u
t
u
r
a
F
i
s
i
c
a
S
a
l
a
H
o
r
a
r
i
o
P
a
d
r
a
o
T
u
r
m
a
D
o
c
e
n
t
e
M
i
n
i
s
t
r
a
n
t
e
H
o
r
a
r
i
o
T
u
r
m
a
D
o
c
e
n
t
e
C
a
n
d
i
d
a
t
o
I
n
f
o
r
m
a
r

s
e

T
u
r
m
a

p
o
s
s
u
i
r


S
u
b
t
u
r
m
a
s

e

s
e

e
l
a


A
g
r
e
g
a
d
o
r
a
s
e
l
e
c
i
o
n
a
r

a
t
i
v
i
d
a
d
e

a
c
a
d
e
m
i
c
a
o
b
t
e
r

l
i
s
t
a

d
e

a
t
i
v
i
d
a
d
e
s

a
c
a
d
e
m
i
c
a
s
o
b
t
e
r

a
t
i
v
i
d
a
d
e

a
c
a
d
e
m
i
c
a
i
n
f
o
r
m
a
r

n
a
t
u
r
e
z
a
,

i
d
e
n
t
i
f
i
c
a
c
a
o
,

t
i
p
o
T
u
r
m
a
c
o
n
f
i
r
m
a
r

e
s
p
e
c
i
f
i
c
a
c
a
o

d
a

t
u
r
m
a
i
n
i
c
i
a
r

c
r
i
a
c
a
o

d
a

t
u
r
m
a
*

c
r
i
a
r

t
u
r
m
a
S
e

T
u
r
m
a

n

o

p
o
s
s
u
i
r

S
u
b
t
u
r
m
a
s
,

r
e
a
l
i
z
a
r

a
p
e
n
a
s

u
m
a

i
t
e
r
a
c
a
o

d
e

c
r
i
a
c
a
o

d
e

t
u
r
m
a
.

S
e
n
a
o
,

r
e
a
l
i
z
a
r

u
m
a

i
t
e
r
a
c
a
o

p
a
r
a

c
a
d
a

s
u
b
t
u
r
m
a
s
e
l
e
c
i
o
n
a
r

e
s
p
a
c
o

f
i
s
i
c
o
o
b
t
e
r

l
i
s
t
a

d
e

s
a
l
a
s
o
b
t
e
r

s
a
l
a
s
s
e
l
e
c
i
o
n
a
r

h
o
r
a
r
i
o
s
o
b
t
e
r

l
i
s
t
a

d
e

h
o
r
a
r
i
o
s
o
b
t
e
r

h
o
r
a
r
i
o
s
s
e
l
e
c
i
o
n
a
r

d
o
c
e
n
t
e
s

m
i
n
i
s
t
r
a
n
t
e
s
o
b
t
e
r

l
i
s
t
a

d
e

d
o
c
e
n
t
e
s

c
a
n
d
i
d
a
t
o
s
o
b
t
e
r

d
o
c
e
n
t
e
s

c
a
n
d
i
d
a
t
o
s
i
n
f
o
r
m
a
r

n
u
m
e
r
o
A
u
l
a
s
,

s
i
t
u
a
c
a
o
,

q
t
d
e
V
a
g
a
s
,

t
u
r
n
o
c
o
n
f
i
r
m
a
r

c
r
i
a
c
a
o

d
a

t
u
r
m
a
c
a
d
a
s
t
r
a
r

t
u
r
m
a
i
n
i
c
i
a
r

t
r
a
n
s
a
c
a
o
i
n
c
l
u
i
r

t
u
r
m
a
i
n
c
l
u
i
r

d
o
c
e
n
t
e
s

m
i
n
i
s
t
r
a
n
t
e
s
i
n
c
l
u
i
r

h
o
r
a
r
i
o

t
u
r
m
a
f
i
n
a
l
i
z
a
r

t
r
a
n
s
a
c
a
o
o
p
e
r
a
c
a
o

c
o
m

s
u
c
e
s
s
o
t
u
r
m
a

c
a
d
a
s
t
r
a
d
a

Figura 7-2 Realizaes do Caso de Uso Criar Turmas e Subturmas
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
116
Modelo de Anlise (ou Conceitual)
O Modelo de Anlise o resultado da anlise dos Casos de Uso e de suas realizaes.
Neste modelo so identificadas as classes bsicas da aplicao e suas associaes. O Modelo
Navegacional uma variao do Modelo Conceitual, com nfase nos aspectos de navegao e
de apresentao da aplicao.
A Figura 7-3 apresenta o Modelo de Anlise representado por um diagrama de classes
de UML, resultante da anlise dos Casos de Uso do modelo apresentado na Figura 7-1.
DocenteMinistrante
cargaHoraria : Integer
DocenteCandi dato
dataHabilitao : Date
PeriodoLetivo
codigoPeriodoLetivo : Integer
anoPeriodoLetivo : Integer
semestrePeriodoLetivo : Integer
tipoPeriodoLetivo : String
dataInicio : Date
dataFim : Date
ComponenteCurricular
codi goComponenteCurricular : I nte ger
nomeCo mpone nteCurri cul ar : String
formaAvali aca o : Stri ng
cargaHorariaMini ma Aproveitame nto : Integer
situaca o : Stri ng
dataPropos ta : Da te
dataI mpl antacao : Date
Docente
cpfDocente : String
codigoDocente : Integer
nomeDocente : String
regimeDocente : String
tipoDocente : TipoDocente
1..n 1..n (colecaoDocentesCandidatos)
HorarioPadrao
codigoHorario : Integer
diaSemanaHorario : String
horaInicio : Date
horaFim : Date
AtividadeAcademica
codigoAtividadeAcademica : Integer
situacaoAtividade : String
11
periodoOferecimento
11
componenteCorrespondente
TipoTurma
codi goTi poTurma : Inte ger
descricaoTi poTurma : String
Turno
codigoTurno : Integer
nomeTurno : String
horaInicio : Date
horaFim : Date
duracaoHoraAula : Integer
Turma
codi goTurma : Integer
naturezaT urma : Bool ean
ide ntifi cacao : Stri ng
nume roAul as : Integer
cargaHora riaTurma : I nte ger
situacaoTurma : String
qntde Total Vagas : Integer
1..n 1..n
(colecaoDocentesMinistrantes)
1..n 1..n (colecaoHorariosTurma)
11
atividadeAcademicaMinistrada
11
tipoTurma
11
turnoTurma
0..1
turmaSuperior
0..1
HorarioTurma
codigoHorarioTurma : Integer
Sala
codigoSala : Integer
descricaoSala : String
capacidadeSala : Integer
tipoSala : TipoSala
predio : Predio
11
sala

Figura 7-3 Modelo de Anlise ou Conceitual da funcionalidade Criao de Turmas e Subturmas
7.4.2 Realizao da Atividade Projetar Navegao
O propsito desta atividade criar subsdios para criao da camada de apresentao no
fluxo de Implementao e para o projeto das interfaces grficas da aplicao. Para tanto, faz-
se necessria a criao do Modelo Navegacional, baseado nos artefatos apresentados na
subseo 7.4.1. A Figura 7-4 apresenta o Modelo Navegacional da funcionalidade Criao de
Turmas e Subturmas, gerado automaticamente atravs da rotina integrada ao ambiente da
ferramenta de modelagem Rational Rose, conforme descrito na seo 7.2.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
117
FrameTurma
<<Target>>
Interf aceTurma
<<Frameset>>
Formul ari oIncluirTurma
<<input>> codigoTurma : Integer
<<input>> naturezaTurma : Boolean
<<input>> identificacao : String
<<input>> numeroAulas : Integer
<<input>> cargaHorariaTurma : Integer
<<input>> situacaoTurma : String
<<input>> qntdeTotalVagas : Integer
<<select>> atividadeAcademica : AtividadeAcademica
<<select>> tipoTurma : TipoTurma
<<select>> turno : Turno
<<select>> turma : Turma
<<Form>>
Res ultadoIncl usaoTurma
<<Client Page>>
IncluirTurma
inserirTurma(turma : Turma)
<<Server Page>>
<<submit>>
<<build>>
FormularioPesquisarTurma
<<Form>>
PesquisarTurmaIteravel
consultarTurmasIteravel() : RepositorioTurmasIteravel
<<Server Page>>
<<submit>>
IndiceTurma
<<Client Page>>
<<build>>
DetalharTurma
consultarTurma( codigoTurma : Integer) : Turma
<<Server Page>>
<<link>>
Formul arioAtualiz arTurma
<<input>> codigoTurma : Integer
<<input>> naturezaTurma : Boolean
<<input>> identificacao : String
<<input>> numeroAulas : Integer
<<input>> cargaHorariaTurma : Integer
<<input>> situacaoTurma : String
<<input>> qntdeTotalVagas : Integer
<<link>> colecaoDocentes : RepositorioDocentesIteravel
<<link>> colecaoHorariosPadroes : RepositorioHorariosPadroesIteravel
<<select>> atividadeAcademica : AtividadeAcademica
<<select>> tipoTurma : TipoTurma
<<select>> turno : Turno
<<select>> turma : Turma
<<Form>>
ValidarAtualizacaoTurma
<<ClientScript Object>>
TelaAtualizarTurma
<<Client P age>>
<<buil d>>
0.. n 0.. n
<<include>>
ValidarInclusaoTurma
<<ClientScript Object>>
TelaIncluirTurma
<<Client Page>>
0..n 0..n
<<include>>
TelaPesquisarTurma
<<Client P age>>
AlterarTurma
atual izarT urma(turma : Turma)
<<Server Page>>
<<submit>>
{alterar Turma}
ExcluirT urma
deletarTurma(codigoTurma : Integer)
<<Server Page>>
<<submit>>
{excluir Turma}
ResultadoAlteracaoTurma
<<Client Page>>
<<buil d>>
ResultadoExclusaoTurma
<<Client Page>>
<<build>>
MenuTurma
<<Clie nt Page>>
<<targeted link>>
{incluir Turma}
<<targeted link>>
{pesquisar Turma}

Figura 7-4 Exemplo de Modelo Navegacional gerado automaticamente
O Modelo Navegacional apresentado na Figura 7-4 precisa ser refinado e talvez
modificado pelo projetista de navegao para melhor atender as necessidades de navegao da
funcionalidade do sistema. Desta forma, a Figura 7-5 apresenta parte do Modelo
Navegacional refinado da funcionalidade Criao de Turmas e Subturmas.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
118
F
r
a
m
e
T
u
r
m
a
<
<
T
a
r
g
e
t
>
>
T
u
r
m
a
(
N
a
v
e
g
a
c
i
o
n
a
l
)
<
<
F
r
a
m
e
s
e
t
>
>
V
a
l
i
d
a
r
I
n
c
l
u
s
a
o
T
u
r
m
a
<
<
C
l
i
e
n
t
S
c
r
i
p
t

O
b
j
e
c
t
>
>
T
e
l
a
E
s
p
e
c
i
f
i
c
a
r
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
<
<
i
n
c
l
u
d
e
>
>
M
e
n
u
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
<
<
t
a
r
g
e
t
e
d

l
i
n
k
>
>
{
i
n
c
l
u
i
r

T
u
r
m
a
}
T
e
l
a
P
e
s
q
u
i
s
a
r
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
<
<
t
a
r
g
e
t
e
d

l
i
n
k
>
>
{
p
e
s
q
u
i
s
a
r

T
u
r
m
a
}
F
o
r
m
u
l
a
r
i
o
P
e
s
q
u
i
s
a
r
T
u
r
m
a
<
<
s
e
l
e
c
t
>
>

a
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a

:

A
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a
<
<
F
o
r
m
>
>
P
e
s
q
u
i
s
a
r
T
u
r
m
a
c
o
n
s
u
l
t
a
r
T
u
r
m
a
P
o
r
A
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
s
u
b
m
i
t
>
>
R
e
s
u
l
t
a
d
o
A
l
t
e
r
a
c
a
o
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
R
e
s
u
l
t
a
d
o
E
x
c
l
u
s
a
o
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
A
l
t
e
r
a
r
T
u
r
m
a
a
t
u
a
l
i
z
a
r
T
u
r
m
a
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
E
x
c
l
u
i
r
T
u
r
m
a
e
x
c
l
u
i
r
T
u
r
m
a
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
I
n
d
i
c
e
H
o
r
a
r
i
o
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
I
n
d
i
c
e
D
o
c
e
n
t
e
M
i
n
i
s
t
r
a
n
t
e
<
<
C
l
i
e
n
t

P
a
g
e
>
>
T
e
l
a
A
t
u
a
l
i
z
a
r
D
e
t
a
l
h
a
r
A
c
a
d
e
m
i
c
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
T
e
l
a
D
e
t
a
lh
a
r
T
i
p
o
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
D
e
t
a
l
h
a
r
T
u
r
m
a
c
o
n
s
u
l
t
a
r
T
u
r
m
a
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
F
o
r
m
u
l
a
r
i
o
D
e
t
a
l
h
a
r
T
u
r
m
a
<
<
r
e
a
d
O
n
l
y
>
>

c
o
d
i
g
o
T
u
r
m
a

:

I
n
t
e
g
e
r
<
<
r
e
a
d
O
n
l
y
>
>

t
u
r
m
a
S
u
p
e
r
i
o
r

:

T
u
r
m
a
<
<
r
a
d
i
o
B
u
t
t
o
n
>
>

n
a
t
u
r
e
z
a

:

B
o
o
l
e
a
n
<
<
r
a
d
i
o
B
u
t
t
o
n
>
>

s
i
t
u
a
c
a
o
T
u
r
m
a

:

B
o
o
l
e
a
n
<
<
s
e
l
e
c
t
>
>

a
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a

:

A
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a
<
<
s
e
l
e
c
t
>
>

t
i
p
o
T
u
r
m
a

:

T
i
p
o
T
u
r
m
a
<
<
s
e
l
e
c
t
>
>

t
u
r
n
o

:

T
u
r
n
o
<
<
i
n
p
u
t
>
>

n
u
m
e
r
o
A
u
l
a
s

:

I
n
t
e
g
e
r
<
<
i
n
p
u
t
>
>

c
a
r
g
a
H
o
r
a
r
i
a

:

I
n
t
e
g
e
r
<
<
i
n
p
u
t
>
>

q
n
t
d
e
V
a
g
a
s

:

I
n
t
e
g
e
r
<
<
l
i
n
k
>
>

d
o
c
e
n
t
e
M
i
n
i
s
t
r
a
n
t
e

:

C
o
l
e
c
a
o
D
o
c
e
n
t
e
s
M
in
i
s
t
r
a
n
t
e
s
<
<
l
i
n
k
>
>

h
o
r
a
r
i
o
T
u
r
m
a

:

C
o
l
e
c
a
o
H
o
r
a
r
i
o
s
T
u
r
m
a
<
<
F
o
r
m
>
>
<
<
s
u
b
m
i
t
>
>
{
a
l
t
e
r
a
r

T
u
r
m
a
}
<
<
s
u
b
m
i
t
>
>
{
e
x
c
l
u
i
r

T
u
r
m
a
}
V
a
l
i
d
a
r
A
t
u
a
l
i
z
a
c
a
o
T
u
r
m
a
<
<
C
l
i
e
n
t
S
c
r
i
p
t

O
b
j
e
c
t
>
>
P
e
s
q
u
i
s
a
r
H
o
r
a
r
i
o
T
u
r
m
a
c
o
n
s
u
l
t
a
r
H
o
r
a
r
i
o
s
T
u
r
m
a
I
t
e
r
a
v
e
l
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
P
e
s
q
u
i
s
a
r
D
o
c
e
n
t
e
M
i
n
i
s
t
r
a
n
t
e
I
t
e
r
a
v
e
l
c
o
n
s
u
l
t
a
r
D
o
c
e
n
t
e
s
M
i
n
i
s
t
r
a
n
t
e
s
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
P
e
s
q
u
i
s
a
r
A
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a
c
o
n
s
u
l
t
a
r
A
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
P
e
s
q
u
i
s
a
r
T
i
p
o
T
u
r
m
a
c
o
n
s
u
l
t
a
r
T
i
p
o
T
u
r
m
a
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
T
e
l
a
D
e
t
a
l
h
a
r
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
<
<
i
n
c
l
u
d
e
>
>
<
<
l
i
n
k
>
>
<
<
l
i
n
k
>
>
<
<
l
i
n
k
>
>
<
<
l
i
n
k
>
>
T
e
l
a
D
e
t
a
l
h
a
r
T
u
r
n
o
<
<
C
l
i
e
n
t

P
a
g
e
>
>
P
e
s
q
u
i
s
a
r
T
u
r
n
o
c
o
n
s
u
l
t
a
r
T
u
r
n
o
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
l
i
n
k
>
>
<
<
b
u
i
l
d
>
>
F
o
r
m
u
l
a
r
i
o
E
s
p
e
c
i
f
i
c
a
r
T
u
r
m
a
<
<
r
a
d
i
o
B
u
t
t
o
n
>
>

n
a
t
u
r
e
z
a

:

B
o
o
l
e
a
n
<
<
i
n
p
u
t
>
>

i
d
e
n
t
i
f
i
c
a
c
a
o

:

S
t
r
i
n
g
<
<
s
e
l
e
c
t
>
>

a
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a

:

A
t
i
v
i
d
a
d
e
A
c
a
d
e
m
i
c
a
<
<
s
e
l
e
c
t
>
>

t
i
p
o
T
u
r
m
a

:

T
i
p
o
T
u
r
m
a
<
<
r
a
d
i
o
B
u
t
t
o
n
>
>

s
u
b
t
u
r
m
a

:

B
o
o
l
e
a
n
<
<
r
a
d
i
o
B
u
t
t
o
n
>
>

a
g
r
e
g
a
d
o
r
a

:

B
o
o
l
e
a
n
<
<
F
o
r
m
>
>
F
o
r
m
u
l
a
r
i
o
E
s
p
e
c
i
f
i
c
a
r
H
o
r
a
r
i
o
T
u
r
m
a
<
<
s
e
l
e
c
t
>
>

s
a
l
a

:

S
a
l
a
<
<
s
e
l
e
c
t
>
>

h
o
r
a
r
i
o
P
a
d
r
a
o

:

H
o
r
a
r
i
o
P
a
d
r
a
o
<
<
C
l
i
e
n
t

P
a
g
e
>
>
T
e
l
a
E
s
p
e
c
i
f
i
c
a
r
H
o
r
a
r
i
o
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
F
o
r
m
u
l
a
r
i
o
E
s
p
e
c
i
f
i
c
a
r
D
o
c
e
n
t
e
M
i
n
i
s
t
r
a
n
t
e
<
<
s
e
l
e
c
t
>
>

d
o
c
e
n
t
e
C
a
n
d
i
d
a
t
o

:

D
o
c
e
n
t
e
C
a
n
d
i
d
a
t
o
<
<
i
n
p
u
t
>
>

c
a
r
g
a
H
o
r
a
r
i
a

:

I
n
t
e
g
e
r
<
<
F
o
r
m
>
>
T
e
l
a
E
s
p
e
c
i
f
i
c
a
r
D
o
c
e
n
t
e
M
i
n
i
s
t
r
a
n
t
e
<
<
C
l
i
e
n
t

P
a
g
e
>
>
T
e
l
a
I
n
c
l
u
i
r
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
<
<
l
i
n
k
>
>
<
<
l
i
n
k
>
>
<
<
l
i
n
k
>
>
F
o
r
m
u
l
a
r
i
o
I
n
c
l
u
i
r
T
u
r
m
a
<
<
i
n
p
u
t
>
>

n
u
m
e
r
o
A
u
l
a
s

:

I
n
t
e
g
e
r
<
<
r
a
d
i
o
B
u
t
t
o
n
>
>

s
i
t
u
a
c
a
o

:

B
o
o
l
e
a
n
<
<
i
n
p
u
t
>
>

q
n
t
d
e
V
a
g
a
s

:

I
n
t
e
g
e
r
<
<
s
e
l
e
c
t
>
>

t
u
r
n
o

:

T
u
r
n
o
<
<
b
u
t
t
o
n
>
>

h
o
r
a
r
i
o

:

H
o
r
a
r
i
o
P
a
d
r
a
o
<
<
b
u
t
t
o
n
>
>

d
o
c
e
n
t
e

:

D
o
c
e
n
t
e
C
a
n
d
i
d
a
t
o
<
<
F
o
r
m
>
>
R
e
s
u
l
t
a
d
o
I
n
c
l
u
s
a
o
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
I
n
c
l
u
i
r
T
u
r
m
a
i
n
c
l
u
i
r
T
u
r
m
a
(
)
i
n
c
l
u
i
r
D
o
c
e
n
t
e
M
i
n
i
s
t
r
a
n
t
e
(
)
i
n
c
l
u
i
r
H
o
r
a
r
i
o
T
u
r
m
a
(
)
<
<
S
e
r
v
e
r

P
a
g
e
>
>
<
<
s
u
b
m
i
t
>
>
<
<
b
u
i
l
d
>
>
I
n
d
i
c
e
T
u
r
m
a
<
<
C
l
i
e
n
t

P
a
g
e
>
>
<
<
b
u
i
l
d
>
>
<
<
l
i
n
k
>
>
F
o
r
m
u
l
a
r
i
o
I
n
d
i
c
e
T
u
r
m
a
<
<
l
i
n
k
>
>

c
o
d
i
g
o
T
u
r
m
a

:

I
n
t
e
g
e
r
<
<
F
o
r
m
>
>
{
d
e
t
a
l
h
a
r

T
u
r
m
a
}

Figura 7-5 Modelo Navegacional da funcionalidade Criao de Turmas e Subturmas
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
119
7.4.3 Realizao da Atividade Projetar GUI
O propsito desta atividade o projeto da apresentao dos elementos do Modelo
Navegacional (classes que representam pginas cliente e formulrios) que representam as
interfaces grficas para interao do usurio com a aplicao. Desta forma, so criados
templates (esboos) dessas interfaces grficas, geralmente, pginas HTML.
A Figura 7-6 apresenta a interface grfica para especificar uma turma, j integrada
aplicao Web SIG@UFPE, derivada da classe FormularioEspecificarTurma do Modelo
Navegacional apresentado na Figura 7-5.

Figura 7-6 Interface Grfica Especificar Turma
A seguir, so apresentadas as interfaces grficas da aplicao Web SIG@UFPE
identificadas no caminho navegacional, descrito no Modelo Navegacional apresentado na
Figura 7-5, para satisfazer a funcionalidade de detalhamento de uma turma e posterior
consulta dos docentes ministrantes.
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
120
A Figura 7-7 mostra a interface grfica, identificada no Modelo Navegacional
apresentado na Figura 7-5 atravs da classe TelaPesquisarTurma, onde o usurio seleciona o
componente curricular oferecido no perodo letivo, para auxiliar a busca em quais turmas este
componente est sendo ofertado e confirma a ao clicando no boto pesquisar.

Figura 7-7 Interface Grfica Pesquisar Turma
A Figura 7-8 mostra a interface grfica, identificada no Modelo Navegacional
apresentado na Figura 7-5 atravs da classe IndiceTurma, que retornada ao usurio com o
resultado da pesquisa atravs de uma estrutura de ndice de turmas. Nesta interface grfica, o
usurio seleciona um dos itens do ndice para detalhamento e confirma a ao clicando no
boto detalhar.

Figura 7-8 Interface Grfica ndice Turma
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
121
A Figura 7-9 mostra a interface grfica, identificada no Modelo Navegacional
apresentado na Figura 7-5 atravs da classe TelaDetalharTurma, que retornada ao usurio
com o detalhamento da turma selecionada. Nesta interface grfica, o usurio pode continuar a
navegao para saber maiores informaes, tal como quais so os docentes ministrantes da
turma, atravs do clique no link Relao dos Docentes Ministrantes da Turma.

Figura 7-9 Interface Grfica Detalhamento Turma
A Figura 7-10 mostra a interface grfica, identificada no Modelo Navegacional
apresentado na Figura 7-5 atravs da classe IndiceDocenteMinistrante, que retornada ao
usurio com a coleo de docentes ministrantes da turma atravs de uma estrutura de ndice.

Figura 7-10 Interface Grfica ndice Docentes Ministrantes
Captulo 7 Estudo de Caso A Aplicao Web SIG@UFPE
122
7.5 Consideraes Finais
Neste captulo foi apresentado o estudo de caso da aplicao Web SIG@UFPE, para
validar de forma prtica os benefcios da execuo do subfluxo Projetar Camada de
Apresentao, caracterstica mais importante da extenso do fluxo de Anlise e Projeto do
RUP para o desenvolvimento de aplicaes Web.
Os artefatos apresentados neste captulo foram desenvolvidos atravs da ferramenta de
modelagem de sistemas Rational Rose (verso 2001.03.00). Esta ferramenta possui um
mecanismo para integrar a semntica proposta nas extenses de UML, como a incluso dos
novos esteretipos para serem usados em elementos especficos dos modelos. Alm disto, esta
ferramenta possibilita automatizao na criao e/ou alterao de modelos, atravs da criao
de scripts que manipulam uma API (Application Program Interface) fornecida, denominada
REI (Rational Extensibility Interface).
No projeto SIG@UFPE o mtodo proposto para criao do Modelo Navegacional
apresentado na seo 6.3 est de fato sendo utilizado. Para acelerar o desenvolvimento, foi
desenvolvida uma funo (atravs de script) baseada neste mtodo, integrada ao ambiente da
ferramenta Rational Rose, que solicita como entrada o Modelo de Anlise, e ento cria
automaticamente o Modelo Navegacional correspondente.
A realizao do estudo de caso foi fundamental para verificao da efetividade da
execuo do subfluxo Projetar Camada de Apresentao, bem como para revisar e redefinir o
mtodo proposto para criao do Modelo Navegacional, e as atividades e artefatos deste
subfluxo.

123
Captulo 8
8 Concluso
A demanda pelo desenvolvimento de aplicaes Web est cada dia maior, devido a
fatores econmicos, sociais e culturais. Entretanto, estas aplicaes possuem caractersticas
que as diferenciam de aplicaes tradicionais, e que devem ser observadas e atendidas no
processo de desenvolvimento.
Diante deste panorama, este trabalho visou atender necessidades especficas do
desenvolvimento de aplicaes Web. Para tanto, foi necessria uma adaptao na metodologia
genrica de desenvolvimento de software RUP Rational Unified Process, com foco no fluxo
de Anlise e Projeto.
Neste captulo so apresentadas as consideraes gerais e contribuies deste trabalho,
bem como os trabalhos correlatos e propostas de trabalhos futuros.
Captulo 8 Concluso
124
8.1 Consideraes Gerais e Contribuies
A Web pode ser definida como um universo de informaes globalmente acessvel
atravs da Internet. um espao abstrato dentro do qual pessoas podem interagir. A Web
marca o fim de uma era de frustrao e incompatibilidade entre sistemas de computao,
criando uma exploso de acessibilidade, com muitos impactos sociais e econmicos.
Do ponto de vista social, a Web age como uma ferramenta de disseminao e
popularizao da informao, sendo de fundamental importncia para a construo de uma
cultura global onde barreiras polticas, econmicas e ticas tm menor influncia. A Web
integra pases, pessoas e culturas diferentes, sem distino de raa, credo ou cor, formando
uma comunidade on-line onde o objetivo o mximo de interao [Arajo 01].
Enquanto agente de disseminao de cultura, a Web tem se tornado fundamental para a
pesquisa como um adjunto ou substituto para a biblioteca. Mesmo em salas de aula, sua
presena de grande importncia no auxlio de professores, aumentando a interao no
ensino. Atravs da Internet, a Web tambm usada para aprendizagem distncia, e
iniciativas nesse sentido tm sido realizadas com sucesso [Kessler 99].
Entretanto, onde a Web mais tem se destacado na economia, simplesmente porque os
produtos e servios anunciados ou ofertados possuem uma enorme audincia de possveis
compradores ou clientes. Alm disso, devido em grande parte globalizao da economia
mundial, cada vez mais as empresas esto migrando ou desenvolvendo seus sistemas
corporativos para uma plataforma baseada na Web.
A influncia positiva da Web nos mais diversos setores como economia, educao, e o
entretenimento, entre outros, tem ocasionado uma demanda bastante significativa no
desenvolvimento de aplicaes baseadas na Web.
As aplicaes Web possuem caractersticas especficas que as diferenciam das
aplicaes tradicionais, e que precisam ser tratadas no processo de desenvolvimento de uma
forma disciplinada. Para tanto, fazem-se necessrias adaptaes em processos de
desenvolvimento de software j existentes para um melhor atendimento na construo de
aplicaes Web.
Captulo 8 Concluso
125
Visando atender as necessidades de desenvolvimento especficas para aplicaes Web,
este trabalho props uma adequao da metodologia de desenvolvimento de software RUP
(Rational Unified Process), mais especificamente no fluxo de Anlise e Projeto, tendo em
vista que a etapa de anlise e projeto onde h uma maior diferena no desenvolvimento de
aplicaes Web com relao a aplicaes tradicionais.
O RUP foi escolhido devido ao fato de ser genrico e adaptvel e por reunir o melhor de
vrias tcnicas modernas de desenvolvimento de software, bem como pela sua grande
aceitao nos meios acadmico e comercial.
O fluxo de Anlise e Projeto do RUP foi adaptado (estendido) para considerar mais
apropriadamente o desenvolvimento de aplicaes Web (utilizando o padro arquitetural de
camadas) sem perder, contudo, as caractersticas de adequabilidade a outros tipos de aplicao
e a generecidade do processo.
A extenso do fluxo de Anlise e Projeto do RUP visou atender ao projeto da Camada
de Apresentao de aplicaes Web, j que esta a camada onde esto as maiores diferenas
com relao a aplicaes tradicionais. Alm disto, com base no framework de Anlise e
Projeto proposto por A.Arajo [Arajo 01], foram feitas recomendaes para execuo de
atividades j existentes de modo a propiciar um melhor atendimento ao desenvolvimento de
aplicaes Web.
Desta forma, um novo subfluxo chamado Projetar Camada de Apresentao foi criado,
juntamente com as atividades Projetar Navegao e Projetar GUI (Graphic User Interface). A
atividade Projetar Navegao consiste basicamente na criao do Modelo Navegacional, com
o propsito de identificar como o usurio navega (caminha) pela aplicao para utilizar as
funcionalidades oferecidas. A atividade Projetar GUI consiste na criao de esboos de
interfaces grficas, geralmente pginas HTML, para os elementos do Modelo Navegacional
(pginas cliente, formulrios) que servem para interao do usurio com a aplicao.
Para orientar a criao do Modelo Navegacional, um mtodo foi proposto com base nas
extenses de UML propostas por J.Conallen [Conallen 99b] e N.Koch [Koch 01], e na
metodologia para desenvolvimento de sistemas hipermdia proposta por H.Baumeister
[Baumeister 99].
Captulo 8 Concluso
126
A validao do subfluxo proposto para o projeto da Camada de Apresentao foi
realizada atravs de um estudo de caso sobre a aplicao Web SIG@UFPE (Sistema de
Informaes e Gesto Acadmica da UFPE). O estudo de caso foi de fundamental
importncia para a verificao da efetividade do subfluxo Projetar Camada de Apresentao,
bem como para revisar o mtodo proposto para criao do Modelo Navegacional, e as
atividades e artefatos deste subfluxo.
O estudo de caso, apresentado neste trabalho, uma pequena parte integrante da
aplicao Web SIG@UFPE que est sendo desenvolvida no Ncleo de Tecnologia da
Informao desta universidade.
Para otimizar e agilizar o processo de desenvolvimento, a ferramenta de modelagem de
sistemas Rational Rose precisou ser configurada para incorporar os esteretipos (inclusive
com a representao grfica) das extenses de UML utilizadas no Modelo Navegacional, bem
como para automatizar a criao deste modelo. A automatizao da criao do Modelo
Navegacional baseou-se no mtodo proposto para construo deste modelo, e consistiu da
criao de uma nova funo incorporada ao ambiente da ferramenta Rational Rose.
Esta funo executa um programa escrito em uma linguagem de script que manipula
uma API (Application Program Interface) chamada REI (Rational Extensibility Interface),
fornecida pela ferramenta Rational Rose. Este programa solicita como entrada o Modelo
Conceitual e ento gera uma viso deste modelo com nfase nos aspectos de navegao e de
apresentao, ou seja, uma verso inicial do Modelo Conceitual que posteriormente precisa
ser refinada pelo projetista navegacional da aplicao.
8.2 Trabalhos Relacionados
Tendo em vista que aplicaes Web podem ser consideradas como um tipo de sistema
hipermdia, diversos mtodos para o desenvolvimento de sistemas hipermdia tm sido
propostos. Em [Koch 99] apresentado um estudo comparativo sobre vrios desses mtodos.
Entre os mtodos mais relevantes, esto:
HDM (Hypermedia Design Method) um dos primeiros mtodos desenvolvidos
para definir a estrutura e interao na aplicaes hipermdia [Garzotto 93],
baseado na notao E-R (Entidade e Relacionamento), mas estende o conceito de
entidade e introduz novas primitivas como unidades (ns) e links.
Captulo 8 Concluso
127
RMM (Relationship Management Methodology) o seu propsito melhorar o
projeto e a construo de aplicaes hipermdia, definindo para tanto um processo
de sete passos [Isakowitz 95]. Estes passos so: projeto de entidade-relacionamento,
projeto de unidades de apresentao, projeto navegacional, projeto de interface do
usurio, projeto de converso, projeto de comportamento em tempo de execuo, e
construo e teste.
OOHDM (Object-Oriented Hypermedia Design Method) compreende as
atividades de modelagem conceitual, projeto navegacional, projeto de interface
abstrata e implementao [Rossi 96,Schwabe 98]. Estas atividades so realizadas em
um misto de estilos de desenvolvimento incremental, iterativo e baseado em
prottipo.
WSDM (Web Site Design Method) uma abordagem centrada no usurio que
define os objetos de informao com base nos requisitos de informao dos usurios
de uma aplicao Web [De Troyer 97]. Consiste de trs fases principais: modelagem
de usurio, projeto conceitual e projeto de implementao.
RNA (Relationship-Navigational Analysis) define uma seqncia de passos a
serem usados para o desenvolvimento de aplicaes Web, focando na anlise
[Bieber 98]. especialmente til para aplicaes Web criadas com base em sistemas
legados.
UPHD (Unified Process-based Hypermedia Systems Development) metodologia
para o desenvolvimento de sistemas hipermdia [Koch 00], baseada no Processo
Unificado [Jacobson 99].
O nosso trabalho procurou adaptar uma metodologia genrica de desenvolvimento de
softwares para o caso especfico de aplicaes Web. Para tanto, escolhemos o RUP e, focando
no fluxo de Anlise e Projeto, criamos novas atividades e artefatos. O principal artefato
proposto foi o Modelo Navegacional, e para orientar sua construo utilizamos alguns
conceitos do OOHDM, tais como primitivas de acesso e caminhos navegacionais.
Captulo 8 Concluso
128
8.3 Perspectivas e Trabalhos Futuros
Parte da extenso do fluxo de Anlise e Projeto do RUP consistiu na criao de um
novo subfluxo para tratar o projeto da Camada de Apresentao, juntamente com suas
atividades e artefatos. Uma das atividades do novo subfluxo, denominada Projetar GUI
(Graphic User Interface), tem como propsito a criao de esboos das interfaces grficas
para interao do usurio com a aplicao, com base nas necessidades navegacionais.
Entretanto, esta atividade pode ser refinada para tratar questes relativas organizao e
aparncia da interface, utilizando, para tanto, tcnicas especficas para interao entre homem
e mquina.
Ao final da execuo do subfluxo proposto para o projeto da Camada de Apresentao,
temos os subsdios necessrios para a criao desta camada no fluxo de Implementao. Alm
disso, o Modelo Navegacional que um dos artefatos produzidos, pode ter seus elementos
(pgina cliente, pgina servidor, formulrio, entre outros) mapeados em elementos de um
documento XML Extensible Markup Language [W3C 02], e este documento pode servir de
entrada para uma ferramenta ou ambiente que automatize a criao da Camada de
Apresentao de aplicaes Web. Uma iniciativa como esta est sendo realizada no projeto
realizado no Ncleo de Tecnologia da Informao desta universidade, responsvel pela
construo da aplicao Web SIG@UFPE.
Este trabalho adaptou apenas o fluxo de Anlise e Projeto do RUP, devido ao fato de
que a etapa de anlise e projeto onde esto as maiores diferenas no desenvolvimento de
aplicaes Web com relao s aplicaes tradicionais. Entretanto, os demais fluxos de
desenvolvimento do RUP tambm necessitam ser adaptados para torn-los mais adequados ao
desenvolvimento de aplicaes Web. Alm disso, seria interessante um estudo sobre as
necessidades de adequao dos fluxos de suporte (gerenciamento de projeto, gerenciamento
de configurao e mudanas, e ambiente).
Outros processos genricos como o Open [Sellers 97] e o Catalysis [DSousza 98] que
se propem a guiar o desenvolvimento de aplicaes tambm necessitam ser adaptados para
casos mais especficos, como o desenvolvimento de aplicaes Web.


129
Referncias Bibliogrficas

[1] [Arajo 01] A. Arajo. Framework de Anlise e Projeto Baseado no RUP para o Desenvolvimento
de Aplicaes Web, Dissertao de Mestrado, UFPE, Centro de Informtica, 2001.
[2] [Baresi 01] L. Baresi, F. Garzotto, P. Paolini. Extending UML for Modeling Web Applications,
34
th
Hawaii International Conference on System Sciences, USA, 2001.
[3] [Baumeister 99] H. Baumeister, N. Koch, L. Mandel. Towards a UML Extension for Hypermedia
Design, In Proceedings <<UML>>99, France, Vol. 1723, pp. 614-629, 1999.
[4] [Bennett 99] S. Bennett, S. McRobb, R. Farmer. Object-Oriented Systems Analysis and Design
using UML. McGraw-Hill Publishing Company, 1999.
[5] [Beveridge 98] T. Beveridge, P. McGlashan. Programao de Alto Desempenho na Web com ISAPI e
NSAPI. Traduo M. Pinto. Editora Berkeley, 1998.
[6] [Bieber 98] M. Bieber, R. Galnares, Q. Lu. Web Engineering and Flexible Hypermedia. In
Proceedings of the 2
nd
Workshop on Adaptive Hypertext and Hypermedia, Hypertext,
1998.
[7] [Booch 99] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide,
Addison Wesley Object Technology Series, 1999.
[8] [Borba 00] P. Borba, V. Alves. Desenvolvendo Aplicaes Distribudas em Java. UFPE Centro
de Informtica, Relatrio Tcnico, Maio, 2000.
[9] [Clemons 91] E. Clemons, M. Row. Information Technology at Rosenbluth Travel: Competitive
advantage in a rapidly growing global service company, J. Manage, Info. 8, pp. 53-79,
1991.
[10] [Conallen 99a] J. Conallen. Modeling Web Applications Architectures with UML, Communication of
the ACM, Vol. 42, No. 10, pp. 63-70, October, 1999.
[11] [Conallen 99b] J. Conallen. Building Web Applications with UML, Addison Wesley Object
Technology Series, 1999.
[12] [DSousza 98] D. DSousza, A. Wills. Objects, Components and Frameworks with UML: The
Catalysis Approach, Addison Wesley, Object Technology Series, 1998.
[13] [De Troyer 97] O. De Troyer, C. Leune. WSDM: A User-Centered Design Method for Web Sites. In
Proceedings of the 7
th
International World Wide Web Conference, 1997.
[14] [Fielding 97] R. Fielding, G. Kaiser. The Apache HTTP server project, IEEE Internet Computing,
July, pp. 88-90, 1997.
Referncias Bibliogrficas
130
[15] [Garzotto 93] F. Garzotto, P. Paolini, D. Schwabe. HDM A Model-Based Approach to Hypertext
Application Design, ACM Transactions of Information Systems, pp. 1-26, 1993.
[16] [Gibbs 94] W. Gibbis. Softwares chronic crisis, Scientific American, September, 1994.
[17] [Hanneghan 96] M. Hanneghan. The World-Wide Web as a Platform for Supporting Interactive
Concurrent Engineering. Proceedings of the 8
th
International Conference of Advanced
Information Systems Engineering, 1996.
[18] [Hansen 99] S. Hansen, Y. Deshpande, S. Murugusan. A Skills Hierarchy for Web Information
System Development, First Workshop on Web Engineering in International
Conference on Software Engineering, USA, May, pp. 16-22, 1999.
[19] [Hech 98] E. Hech, P. Vervest. How should CIOs deal with Web-based Auctions,
Communications of the ACM, Vol. 41, No. 10, pp. 99-100,July, 1998.
[20] [Hennicker 00] R. Hennicker, N. Koch. A UML based Methodology for Hypermedia Design, In
Proceedings <<UML>>00, USA, 2000.
[21] [Isakowitz 95] T. Isakowitz, E. Stohr, P. Balasubramanian. A Methodology for Design of Structured
Hypermedia Applications. Communications of the ACM, Vol. 38, No. 8, pp. 149-160,
1995.
[22] [Jacobson 99] I. Jacobson, G. Booch, J. Rumbaugh. The Unified Software Development Process.
Addison Wesley, 1999.
[23] [Kessler 99] G. Kessler, K. Rosenblad, S. Shepard. The Web can be suitable for Learning?, IEEE
Computer, pp. 88-90, February, 1999.
[24] [Koch 00] N. Koch. Hypermedia Systems Development based on the Unified Process, Technical
Report 003, Ludwig-Maximilians-University Munich, 2000.
[25] [Koch 01] N. Koch, H. Baumeister, R. Hennicker, L. Mandel. Extending UML to Model
Navigation and Presentation in Web Applications, 2001.
[26] [Koch 99] N. Koch. A Comparative Study of Methods for Hypermedia Development, Technical
Report 9901, Ludwig-Maximilians-University Munich, 1999.
[27] [Nambisan 99] S. Nambisan, Y. Wang. Roadblocks to Web Technology, Communications of the
ACM, Vol. 42, 1999.
[28] [Pressman 92] R. S. Pressman. Software Engineering: A Practitioners Approach, McGraw-Hill, 3
ed., 1992.
[29] [Rossi 96] G. Rossi. OHDM: Object-Oriented Hypermedia Design Method, PhD Thesis, PUC-
Rio, Brasil, 1996.
[30] [Rossi 99] G. Rossi, D. Schwabe, F. Lyardet. Web Application Models are more than Conceptual
Models, In Proceedings of the World Wide Web and Conceptual Modeling99
Workshop, ER99 Conference, Paris, 1999.
Referncias Bibliogrficas
131
[31] [Schwabe 96] D. Schwabe, G. Rossi, S. Barbosa. Systematic Hypermedia Design with OOHDM, In
Proceedings of the ACM International Conference, 1996.
[32] [Schwabe 98] D. Schwabe, G. Rossi. Developing Hypermedia Applications using OOHDM. In
Proceedings of Workshop on Hypermedia Development Process, Methods and
Models, Hypertext, 1998.
[33] [Sellers 97] B. Sellers, H. Younessi, I. Graham. The Open Process Specification. Addison Wesley,
Open Series, 1997.
[34] [Sommerville 96] I. Sommerville. Software Engineering 5
th
Edition, Addison Wesley, 1996.
[35] [Souza 01] R. Souza. Extenses de UML para Aplicaes Web, Trabalho Individual de
Engenharia de Software UFPE/CIN, 2001.
[36] [Sun 01] Sun http://java.sun.com, Last acess in September/2001.
[37] [Vasudevan 96] S. Vasudevan, Y. Wang. Technology adoption in the presence knowledge barriers:
The Case of the World Wide Web. In Proceedings of the 17
th
International Conference
on Information Systems, December, 1996.
[38] [W3C 02] World Wide Web Consortium http://www.w3c.org, Last acess in January/2002.
[39] [Weippl 00] E. Weippl. Web Engineering for Intranets, Software Competence Center Hagenberg
(http://www.scch.at), 2000.
[40] [Zelnick 98] N. Zelnick. Nifty Technology and Nonconformance: The Web in Crisis, IEEE
Computer, pp. 115,116,119, October, 1998.



133
Apndice A
9 Guia de Projeto Navegacional
O Projeto Navegacional visa atender os aspectos de navegao e de apresentao que
so bastantes relevantes em se tratando de aplicaes Web. Para tanto, o Projeto Navegacional
deve produzir o Modelo Navegacional da aplicao orientado por algumas regras.
Desta forma, neste apndice apresentado um Guia de Projeto Navegacional que define
regras para criao do artefato Modelo Navegacional.
Apndice A Guia de Projeto Navegacional
134
Introduo

O Projeto Navegacional consiste na criao do Modelo Navegacional de uma
aplicao Web, com os seguintes propsitos: identificar como o usurio navega na aplicao
para utilizar as funcionalidades oferecidas, criar subsdios para o projeto das interfaces
grficas do usurio, e identificar os elementos necessrios para criao da Camada de
Apresentao da aplicao.
Entretanto, a criao de um Modelo Navegacional uma atividade complexa que deve
orientar-se por regras definidas em um processo. Desta forma, a seguir apresentado o
processo proposto para criao de um Modelo Navegacional com base no Modelo de Anlise
de uma aplicao.

Processo para criao do Modelo Navegacional

O Modelo Navegacional uma viso do Modelo de Anlise, com nfase nos aspectos
de navegao e de apresentao. Desta forma, as classes navegacionais so derivadas das
classes bsicas do Modelo de Anlise e os caminhos navegacionais so derivados das
associaes entre as classes bsicas do Modelo de Anlise.
Os caminhos navegacionais representam como o usurio caminha (navega) na
aplicao para utilizar as funcionalidades oferecidas pelo sistema. Os caminhos navegacionais
so influenciados pelas multiplicidades das associaes entre as classes bsicas do Modelo de
Anlise. Alm disso, os caminhos navegacionais devem satisfazer as operaes de
manuteno (incluso, alterao, excluso e consulta) de objetos do sistema.
Para exemplificar o processo de criao de um Modelo Navegacional, consideramos
parte de um Modelo de Anlise conforme apresentado na prxima figura. Este exemplo
considera os dois tipos bsicos de multiplicidade (igual a um e maior que um) em associaes
entre classes de um Modelo de Anlise que influenciam na criao de um Modelo
Navegacional.

Docente
cpfDocente : String
nomeDocente : String
Turma
codigoTurma : Integer
qntdeVagas : Integer
1..n 1..n
Disciplina
codigoDisciplina : Integer
descricaoDisciplina : String
11


O processo de criao do Modelo Navegacional derivado da parte do Modelo de
Anlise apresentado na figura acima, orienta-se por algumas regras conforme apresentado a
seguir. Na prxima figura, o Modelo Navegacional apresentado.

O Modelo Navegacional deve satisfazer as operaes de manuteno (incluso,
pesquisa, alterao e excluso) de objetos da classe Turma. Portanto, deve contemplar as
seguintes consideraes:

S Em termos de apresentao: criao de uma interface grfica para incluso de
objetos da classe Turma (classe TelaIncluirTurma); criao de uma interface
grfica para auxiliar a pesquisa de objetos da classe Turma (classe
TelaPesquisarTurma); criao de uma interface grfica para exibir o resultado da
pesquisa atravs de uma estrutura de ndice (classe IndiceTurma); criao de uma
interface grfica para exibir o detalhamento, ou seja, todas as informaes de um
objeto da classe Turma (classe TelaDetalharTurma).
Apndice A Guia de Projeto Navegacional
135
S Em termos de navegao: criao de um caminho navegacional @ para satisfazer a
operao de incluso de uma turma; criao de uma caminho navegacional A para
satisfazer as operaes de pesquisa, detalhamento, alterao e excluso de uma
turma (estas operaes esto agrupadas em apenas um caminho navegacional pois
para alterar e/ou excluir uma turma, tem-se que primeiro pesquisar e detalhar esta
turma).

A associao entre a classes Turma e Disciplina possui multiplicidade igual a um na
origem, o que significa que um objeto da classe Turma possui como atributo um objeto da
classe Disciplina. Desta forma, o Modelo Navegacional deve contemplar as seguintes
consideraes:

S Em termos de apresentao: a interface grfica responsvel pela operao de
incluso de objetos da classe Turma deve possuir um campo para identificar o
objeto da classe Disciplina (atributo disciplina da classe FormularioIncluirTurma);
a interface grfica responsvel pela operao de detalhamento dos objetos da classe
Turma deve possuir um campo que identifique o objeto contido da classe
Disciplina (atributo disciplina da classe FormularioDetalharTurma), com opo de
detalhamento atravs de link (associao entre as classes TelaDetalharTurma e
DetalharDisciplina).

S Em termos de navegao: criao de um caminho navegacional C para satisfazer a
operao de detalhamento da disciplina de uma turma.

A associao entre as classes Turma e Docente possui multiplicidade maior que um na
origem, o que significa que um objeto da classe Turma possui como atributo uma coleo de
objetos da classe Docente. Desta forma, o Modelo Navegacional deve contemplar as seguintes
consideraes:

S Em termos de apresentao: deve ser criada uma interface grfica para incluir,
alterar e excluir a coleo de objetos da classe Docente que pertencem a um objeto
da classe Turma (classe TelaDocentesTurma); a interface grfica responsvel pela
operao de detalhamento de objetos da classe Turma deve possuir um campo do
tipo link , que quando acionado execute um processo cujo propsito o de exibir
os docentes da turma atravs de uma estrutura de ndice (associao entre as
classes TelaDetalharTurma e PesquisarDocentesDaTurma).

S Em termos de navegao: criao de um caminho navegacional B para satisfazer
as operaes de incluso, alterao e excluso de docentes da turma; criao de um
caminho navegacional D para satisfazer a operao de pesquisa dos docentes da
turma.
Apndice A Guia de Projeto Navegacional
136
ResultadoInclusaoTurma
<<Client Page>>
FrameTurma
<<Target>>
ResultadoAlteracaoTurma
<<Client Page>>
ResultadoExclusaoTurma
<<Client Page>>
AlterarTurma
<<Server Page>>
<<build>>
ExcluirTurma
<<Server Page>>
<<build>>
IndiceDocentesTurma
<<Server Page>>
TelaDetalharDisciplina
<<Client Page>>
IncluirTurma
incluirTurma()
<<Server Page>>
<<build>>
Turma(Navegacional)
<<Frameset>>
TelaPesquisarTurma
<<Client Page>>
FormularioIncluirTurma
<<input>> codigoTurma : Integer
<<input>> qntdeVagas : Integer
<<select>> disciplina : Disciplina
<<Form>>
<<submit>>
MenuTurma
<<Client Page>>
<<link>>
ValidarInclusaoTurma
<<ClientScript Object>>
TelaIncluirTurma
<<Client Page>>
<<link>>
<<include>>
Interface Grfica para
manipular os Docentes
de uma Turma
FormularioPesquisarTuma
<<select>> disciplina : Disciplina
<<Form>>
TelaDocentesTurma
<<Client Page>>
<<link>>
DocentesTurma
incluirDocentesDaTurma()
alterarDocentesDaTurma()
excluirDocentesDaTurma()
<<Server Page>>
FormularioDocentesTurma
<<select>> turma : Turma
<<select>> docente : Docente
<<Form>>
<<submit>>
PesquisarTurma
pesquisarTurmaPorDisciplina()
<<Server Page>>
<<submit>>
FormularioIndiceTurma
<<link>> codigoTurma : Integer
<<Form>>
IndiceTurma
<<Client Page>>
<<build>>
FormularioDetalharTurma
<<input>> codigoTurma : Integer
<<input>> qntdeVagas : Integer
<<select>> disciplina : Disciplina
<<Form>>
<<submit>>
<<submit>>
PesquisarDocentesTurma
pesquisarDocentesDaTurma()
<<Server Page>>
<<build>>
DetalharDisciplina
detalharDisciplina()
<<Server Page>>
<<build>>
DetalharTurma
detalharTurma()
<<Server Page>>
<<link>>
ValidarAtualizacaoTurma
<<ClientScript Object>>
TelaDetalharTurma
<<Client Page>>
<<link>> <<link>>
<<build>>
<<include>>
?
@ A B
C D


Apndice A Guia de Projeto Navegacional
137
? As funcionalidades oferecidas pela classe Turma, tais como, cadastrar turma, pesquisar
turma e cadastrar docentes da turma so exibidas para o usurio atravs de uma estrutura de
menu com seus respectivos links.

@ Caminho navegacional para a operao de incluso de uma turma. O usurio visualiza a
interface grfica atravs de uma pgina cliente, preenche os campos com informaes da
turma e atravs de uma ao (clique em um boto) confirma a operao de cadastramento, so
realizadas validaes nas informaes dos campos fornecidas pelo usurio atravs de scripts
executados no cliente, posteriormente essas informaes so validadas e processadas no
servidor atravs de uma pgina servidor, e finalmente, a turma cadastrada na base de dados
do sistema e uma mensagem de sucesso retornada ao usurio.

A Caminho navegacional para as operaes de pesquisa, alterao e excluso de uma turma.
O usurio visualiza a interface grfica que auxilia a pesquisa (busca) de uma turma atravs de
uma pgina cliente, seleciona a disciplina para saber em quais turmas ela est sendo oferecida
e aps isso confirma a operao de busca atravs de uma ao, realizado um processamento
no servidor, atravs de uma pgina servidor, utilizando o argumento (disciplina) fornecido
pelo usurio, e ento exibido ao usurio o resultado da busca, atravs de uma estrutura de
ndice. O usurio pode selecionar um dos itens do ndice para visualizar o detalhamento de
uma turma, e desta forma apresentada uma interface grfica, atravs de uma pgina cliente,
com seus campos preenchidos com todas as informaes da turma. Aps a pesquisa e
detalhamento da turma, o usurio pode realizar as operaes de alterao ou excluso desta
turma.

B Caminho navegacional para as operaes de incluso, alterao e excluso de docentes de
uma turma. O usurio visualiza a interface grfica atravs de uma pgina cliente, seleciona a
turma e ento pode incluir e/ou excluir um docente para esta turma.

C Caminho navegacional para a operao de detalhamento da disciplina de uma turma. O
usurio aps realizar as operaes de pesquisa e detalhamento de uma turma, pode ento
querer visualizar o detalhamento da disciplina oferecida por esta turma. Desta forma, na
interface grfica responsvel por exibir o detalhamento de uma turma, haver um campo do
tipo link que quando acionado pelo usurio executa um processo no servidor, atravs de uma
pgina servidor, cujo resultado a exibio para o usurio de uma interface grfica, atravs de
uma pgina cliente, com seus campos preenchidos com todas as informaes da disciplina
oferecida pela turma.

D Caminho navegacional para a operao de pesquisa dos docentes de uma turma. O usurio
aps realizar as operaes de pesquisa e detalhamento de uma turma, pode ento querer
visualizar os docentes da turma. Desta forma, na interface grfica responsvel por exibir o
detalhamento de uma turma, haver um campo do tipo link que quando acionado pelo usurio
executa um processo no servidor, atravs de uma pgina servidor, cujo resultado a exibio
para o usurio de uma interface grfica com uma estrutura de ndice, atravs de uma pgina
cliente, com campos que identifiquem os docentes da turma.






139
Apndice B
A Extenso de UML WAE

A extenso de UML WAE (Web Application Extension), proposta por J.Conallen
[Conallen 99b], define um conjunto de esteretipos, tagged values e restries que podem ser
aplicados a elementos dos diagramas de UML, com o propsito de modelar caractersticas
especficas de aplicaes Web.
Neste apndice, esta extenso de UML para aplicaes Web apresentada em detalhes,
so descritos os esteretipos e a que elementos so aplicveis.
Apndice B A Extenso de UML WAE
140
Server Page
Tipo no Metamodelo Classe
Descrio Uma pgina servidor representa uma pgina Web que tm scripts executados pelo
servidor. Esses scripts interagem com recursos do servidor tais como, banco de dados,
lgica de negcios e sistemas externos.

cone






Restries As pginas servidor podem ter relao apenas com objetos no servidor.
Tagged Values Engenho de script: linguagem ou engenho de precisa ser usado para executar ou
interpretar esta pgina (JavaScript, VBScript, Perl, entre outros)

Client Page
Tipo no Metamodelo Classe
Descrio Uma pgina cliente representa uma pgina Web formatada, que montada no browser
cliente e que pode conter scripts que so interpretados pelo browser. Estas pginas
podem ter associaes com outras pginas cliente e pginas servidor.

cone



Restries Nenhuma
Tagged Values TitleTag: o ttulo da pgina como exibido pelo browser.
BaseTag: a URL base.
BodyTag: o conjunto de atributos para a tag body.

Form
Tipo no Metamodelo Classe
Descrio Um formulrio representa uma coleo de campos de entrada que so parte da pgina
cliente. Um formulrio no tm operaes, quaisquer operaes que interajam com o
formulrio, sero propriedades da pgina cliente que o contm.

cone



Restries Nenhuma
Tagged Values Mtodos GET e POST usados para submeter dados para ao na URL.





Apndice B A Extenso de UML WAE
141
Frameset
Tipo no Metamodelo Classe
Descrio Container de mltiplas pginas Web. Os contedos de um frame podem ser uma pgina
Web ou um outro frameset.

cone



Restries Nenhuma.
Tagged Values Rows: o valor do atributo linha do tag frameset.
Cols: o valor do atributo coluna do tag frameset.

Target
Tipo no Metamodelo Classe
Descrio Compartimento na janela do browser onde pginas Web podem ser montadas.
Tipicamente, um target um frame na janela definido por um frameset. As associaes
targeted link especificam targets como o lugar onde uma nova pgina Web montada.

cone



Restries Um nome de target deve ser nico para cada cliente do sistema, ento, somente uma
instncia do target pode existir no mesmo cliente.

Tagged Values Nenhum.


JavaScript Object
Tipo no Metamodelo Classe
Descrio No browser possvel simular objetos definidos pelo usurio com funes JavaScript.
Instncias de objetos Java script existem somente no contexto de pginas cliente.

cone



Restries Nenhuma.
Tagged Values Nenhum.






Apndice B A Extenso de UML WAE
142
ClientScript Object
Tipo no Metamodelo Classe
Descrio Coleo separada de scripts do lado cliente, so geralmente pacotes das funes mais
comuns usadas na aplicao ou na empresa.

cone

f(){
}


Restries Nenhuma.
Tagged Values Nenhum.


Link
Tipo no Metamodelo Associao
Descrio Um link um ponteiro da pgina cliente para uma outra pgina Web. No diagrama de
classes, um link uma associao entre uma pgina cliente e outra pgina cliente ou
uma pgina servidor

cone

Nenhum.

Restries Nenhuma.
Tagged Values Nenhum.


Targeted Link
Tipo no Metamodelo Associao
Descrio Similar a associao link, um targeted link um link cuja pgina associada montada
montada em um outro target.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Parmetros: uma lista de nomes de parmetros que so passados junto com a requisio
para a pgina linkada.
Nome do Target: o nome do target que o link desta pgina aponta para ser montada
nela.

Frame Content
Tipo no Metamodelo Associao
Descrio Agregao que expressa uma conteno do frame de outra pgina ou target. Pode
apontar para outro frameset, indicando frames aninhados.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Row e Col: um inteiro indicando a linha ou coluna especfica do frame no frameset que
a pgina associada ou target pertencem.
Apndice B A Extenso de UML WAE
143
Submit
Tipo no Metamodelo Associao
Descrio Associao situada entre um formulrio e uma pgina servidor. Os formulrios
submetem os valores de seus campos para o processamento no servidor, atravs de
pginas servidor.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Parmetros: uma lista de nomes de parmetros que devem ser passados junto com a
requisio para a pgina linkada.

Build
Tipo no Metamodelo Associao
Descrio Relao que liga pginas cliente e pginas servidor. Identifica qual pgina servidor
responsvel pela criao da pgina cliente.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Nenhum.


Redirect
Tipo no Metamodelo Associao
Descrio Associao unidirecional com outra pgina Web, pode ser direcionado de e para ambas
pginas cliente e pginas servidor. Se a relao origina de uma pgina servidor, ento
indica que o processamento da requisio pode continuar em outra pgina. Se a relao
origina de uma pgina cliente, ento indica que a pgina destino ser automaticamente
requisitada pelo browser.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Delay: quantidade de tempo que a pgina cliente espera antes de redirecionar prxima
pgina.

IIOP
Tipo no Metamodelo Associao
Descrio IIOP (Internet Inter-ORB Protocol) uma relao entre objetos no cliente e objetos no
servidor, representa um outro mecanismo de HTTP para comunicao cliente/servidor.
Tipicamente, esta relao entre JavaBeans no cliente e Enterprise JavaBeans no
servidor.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Nenhum.

Apndice B A Extenso de UML WAE
144
RMI
Tipo no Metamodelo Associao
Descrio RMI (Remote Method Invocation) um mecanismo para Java Applets e JavaBeans
enviarem mensagens para outros JavaBeans em mquinas diferentes. Tipicamente, esta
relao entre JavaBeans ou Applets no cliente e Enterprise JavaBeans no servidor.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Nenhum.


Input Element
Tipo no Metamodelo Atributo
Descrio Atributo do objeto formulrio, usado para entrada de uma nica palavra ou linha de
texto.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Type: o tipo de controle de entrada para ser usado texto, nmero ou password.
Size: especifica o tamanho da rea para ser alocada na tela, em caracteres.
MaxLength: o nmero mximo de caracteres que o usurio pode informar.

Select Element
Tipo no Metamodelo Atributo
Descrio Controle de entrada usado em formulrios, permite o usurio selecionar um ou mais
itens de uma lista, geralmente, expressos como combo ou list box.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Size: especifica a quantidade de itens que sero exibidos ao mesmo tempo.
Multiple: boleano que indica se mais de um item podem ser selecionados na lista.

Text Area Element
Tipo no Metamodelo Atributo
Descrio Controle de entrada usado em formulrios, permite a entrada de mltiplas linhas.
cone Nenhum.

Restries Nenhuma.
Tagged Values Rows: o nmero de linhas de textos visveis.
Cols: a largura do controle, de acordo com a mdia da largura dos caracteres.




Apndice B A Extenso de UML WAE
145
Web Page
Tipo no Metamodelo Componente
Descrio Arquivos de texto acessveis pelo servidor Web, mas podem tambm ser mdulos
compilados que so carregados e invocados pelo servidor Web. Quando acessados pelo
servidor Web como um arquivo ou como um executvel, uma pgina produz um
documento HTML formatado que enviado em resposta a requisio do browser.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Path: o caminho requerido para especificar a pgina Web no servidor Web.


ASP Page
Tipo no Metamodelo Componente
Descrio Pgina Web que implementam cdigo ASP no lado servidor. Este esteretipo
aplicvel somente em ambientes de aplicaes baseadas em Active Server Pages.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Path: o caminho requerido para especificar a pgina Web no servidor Web.


JSP Page
Tipo no Metamodelo Componente
Descrio Pgina Web que implementam cdigo JSP no lado servidor. Este esteretipo aplicvel
somente em ambientes de desenvolvimento de aplicaes Web que usam Java Server
Pages.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Path: o caminho requerido para especificar a pgina Web no servidor Web.


Servlet
Tipo no Metamodelo Componente
Descrio Componente servlet Java. Este esteretipo aplicvel somente em ambientes de
desenvolvimento de aplicaes Web que suportam servlets.

cone

Nenhum.

Restries Nenhuma.
Tagged Values Path: o caminho requerido para especificar a pgina Web no servidor Web.






147
Apndice C
10 Framework de Anlise e Projeto para
Aplicaes Baseadas na Web
O framework de Anlise e Projeto apresentado neste apndice corresponde a uma
adaptao do fluxo de Anlise e Projeto do RUP para o desenvolvimento de aplicaes Web.
O fluxo foi alterado de forma a considerar as especificidades das aplicaes para Web e do
seu desenvolvimento. Algumas atividades do fluxo original do RUP (verso 5.0 build 33) no
foram modificadas e, desta forma, no sero detalhadas neste apndice.
Neste apndice, so apresentadas as atividades, bem como seus passos correspondentes,
do framework de Anlise e Projeto para o desenvolvimento de aplicaes baseadas na Web
proposto por A.Arajo em [Arajo 01].
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
148
Framework de Anlise e Projeto para aplicaes Web

Arquiteto de
Software
Analisar
Arquitetura
Projetar
Arquitetura
Descrever
Concorrncia
Descrever
Distribuio
Projetista de
Software
Analisar
Use-Case
Projetar
Subsistema
Projetar
Classes
Projetar
Use-Case
Projetista de
Navegao
Projetar
Navegao
Projetar
Interface
Projetista de
Banco de Dados
Projetar
Banco de Dados
Projetista de
Contedo
Projetar
Contedo
Revisor do
Projeto
Revisar
Projeto
Revisor da
Arquitetura
Revisar
Arquitetura
Atividades no modificadas Atividades adaptadas Atividades includas


Os responsveis e principais artefatos envolvidos neste fluxo so mostrados a seguir:
1. Arquiteto de Software: Modelo de Anlise, Modelo de Projeto e Documento de Arquitetura de
Software.
2. Projetista de Software: Modelo de Projeto (realizao dos use cases e projeto das classes e
subsistemas).
3. Revisor da Arquitetura: Modelo de Projeto e Documento de Arquitetura de Software.
4. Projetista de Contedo: Modelo de Contedo.
5. Projetista de Navegao: Modelo de Navegao e Modelo da Interface.
6. Projetista de Banco de Dados: Modelo de Dados.
7. Revisor de Projeto: Modelo de Projeto (como um todo), Guidelines de Projeto e Guidelines de
Projeto para Web.

Nos pargrafos a seguir esto detalhadas apenas as atividades que foram adaptadas, as atividades
includas e alguns guidelines e checklists que foram criados. As demais atividades, guidelines e checklists, bem
como, os conceitos e mentores de ferramentas podem ser encontrados no RUP (verso 5.0 build 33 ano 1998).
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
149
Atividade: Analisar Arquitetura

Propsito
S Definir os padres arquiteturais, mecanismos chaves e convenes de modelagem para o sistema.
S Definir a estratgia de reuso.
S Providenciar informaes para o processo de planejamento.
S Definir a estrutura inicial da aplicao baseada na Web, identificando as pginas de informao e os
componentes de aplicao.
Passos
S Definir Convenes de Modelagem
S Definir a Organizao de Alto Nvel dos Subsistemas
S Identificar os Mecanismos de Anlise
S Identificar as Abstraes Chaves
S Criar Realizaes de Use-Case
S Revisar os Resultados
Artefatos de Entrada:
S Modelo de Use Case
S Especificaes Suplementares
S Glossrio
S Modelo de Negcios
S Documento de Arquitetura de Software
S Modelo de Projeto
S Guidelines de Projeto
S Guidelines de Projeto para a Web
Artefatos Resultantes:
S Documento de Arquitetura de Software atualizado
S Modelo de Projeto atualizado
S Guidelines de Projeto
S Realizaes dos Use Cases
S Guidelines de Projeto para a Web atualizadas
Freqncia: Uma vez por iterao, durante as primeiras iteraes; as iteraes posteriores visitam a atividade
principalmente para validar e ajustar os aspectos analticos da arquitetura.
Responsvel: Arquiteto
Conceitos: Padres de Distribuio, Mecanismos de Anlise, Concorrncia, Diviso em Camadas
Para aplicaes baseadas na Web os principais passos deste fluxo so "Definir a Organizao de Alto
Nvel dos Subsistemas" e "Identificar os Conceitos Chave". Estes passos so importantes pois neles ocorrem a
estruturao em camadas inicial da aplicao e a definio das classes de anlise iniciais, respectivamente. Os
demais passos podem no serem realizados caso o tempo seja uma questo crtica, uma constante no
desenvolvimento de aplicaes para a Web.
Uma ateno especial deve ser dada aos conceitos de "Definio de Camadas" e "Padres de
Distribuio" pois so de fundamental importncia para a estruturao da aplicao para a Web.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
150
Passo: Definir Convenes de Modelagem

Propsito
S Garantir que a representao da arquitetura e do projeto estejam consistentes atravs de grupos de
trabalho e iteraes.
Padres e mecanismos arquiteturais, bem como o projeto de forma geral so representados de vrias
formas: com textos descritivos, linguagens formais, diagramas (incluindo diagramas de classe, seqncia,
colaborao e atividade, entre outros), etc.
Convenes de modelagem so documentadas no Artefato: Guidelines de Projeto; o formato e o estilo
das descries arquiteturais so definidos na Seo Representao Arquitetural do Artefato: Documento de
Arquitetura de Software.
O Artefato: Guidelines de Projeto para a Web apresenta algumas boas prticas para a construo de
sistemas baseados na Web. Algumas convenes de modelagem e padres arquiteturais esto previamente
indicados podendo ser alterados ou adaptados natureza especfica da aplicao ou organizao em questo. O
Artefato: Guidelines de projeto para a Web um documento em constante evoluo devendo ser sempre
atualizado para o projeto e para a organizao.

Passo: Definir a Organizao de Alto Nvel dos Subsistemas

Propsito
S Criar uma estrutura inicial para o Modelo de Projeto
Guidelines: Diviso em Camadas
O modelo de projeto normalmente organizado em camadas. O nmero de camadas no fixo, mas
varia de situao para situao.
Durante a anlise arquitetural, o foco normalmente as duas camadas de mais alto nvel, isto , as
camadas de aplicao e negcios. As outras camadas de mais baixo nvel estaro em foco durante o projeto
arquitetural, ver a atividade Projetar a Arquitetura para mais informaes.
Uma tendncia nas aplicaes atuais a separao entre regras de negcio, apresentao (interface de
usurio) e gerenciamento de dados. Esta separao de preocupaes leva a uma arquitetura de aplicao de trs
camadas: servios de apresentao, servios de processamento e servios de dados. Este padro arquitetural
especialmente apropriado para sistemas baseados na Web pois promove a noo de interoperabilidade, reuso e
gerenciamento das aplicaes em ambiente distribudo. O tempo de desenvolvimento e principalmente o tempo
de manuteno, de aplicaes desenvolvidas a partir deste padro, so reduzidos, adequando-se mais
facilmente a caracterstica de rpido desenvolvimento de uma aplicao Web.
Aplicaes baseadas na Web podem ser simples, apenas retornando e apresentando pginas HTML ou
sofisticadas aplicaes corporativas que integram a Web a recursos corporativos. A definio das camadas de
uma aplicao baseada na Web deve levar em conta essa diferena.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
151
Passo: Identificar os Mecanismos de Anlise

Propsito
S Definir os padres arquiteturais usados pelos projetistas para dar "vida" a seus objetos.
Um mecanismo de anlise representa um padro que constitui uma soluo comum para um problema
comum. Eles podem ser padres de estruturas, padres de comportamento, ou ambos. Eles so usados durante
a anlise para reduzir a complexidade e para melhorar a consistncia, providenciando aos projetistas pequenas
representaes para problemas complexos. Os mecanismos permitem que o esforo de anlise seja focado
sobre a traduo dos requisitos do sistema em conceitos de software, sem se preocupar com a especificao de
comportamentos relativamente complexos, necessrios para suportar a funcionalidade, mas no central para
ela.
Mecanismos arquiteturais no so usualmente relacionados com o domnio do problema, ao contrrio,
so conceitos da "cincia da computao". Eles providenciam comportamento especfico para classes ou
componentes relacionados ao domnio, ou correspondem a implementao da cooperao entre classes e/ou
componentes. Eles podem ser implementados como um framework. Exemplos incluem mecanismos para
manusear a persistncia, comunicao entre processos, manuseio de falhas ou erros, troca de mensagens, etc.
Alguns mecanismos de anlise especficos para aplicaes Web foram definidos e constam no artefato
Guidelines de Projeto para a Web.

Passo: Identificar as Abstraes Chave

Propsito
S Iniciar a anlise atravs da identificao das abstraes chave (representao de conceitos identificados
durante a modelagem de negcios e a atividade de requisitos) que o sistema deve manusear.
Mentor de Ferramenta: Documentando as Classes de Anlise no Rational Rose.
As atividades de Requisitos e Modelagem de Negcios geralmente revelam os conceitos chave com os
quais o sistema deve lidar; estes conceitos so manifestaes das abstraes de projeto. Devido ao fato do
trabalho j ter sido realizado, no h a necessidade de repetir esta identificao durante a Atividade: Analisar
Use Case. Para se fazer uso do conhecimento existente, preliminarmente identifica-se as classes de entidade de
anlise para representar estas abstraes chaves com base no conhecimento geral do sistema, tal como os
Requisitos, o Glossrio, e em particular, o Modelo do Domnio, ou Modelo de Negcios, caso eles tenham
sido construdos. Enquanto estamos definindo as abstraes chave, ns tambm definimos qualquer
relacionamento que possa existir entre as classes de entidade. Devemos mostrar estas abstraes em um ou
vrios diagramas de classe e devemos criar uma pequena descrio para cada um.
As classes de anlise identificadas neste ponto provavelmente mudaro e evoluiro durante o curso do
projeto. O propsito deste passo no identificar um conjunto de classes que sobreviver atravs do projeto,
mas identificar os conceitos chave que o sistema deve manusear. No gaste muito tempo descrevendo classes
de entidade em detalhes neste estgio inicial, porque h o risco de que voc tenha identificado classes e
relacionamentos que no so necessrios para os use cases. Relembre que voc encontrar mais classes de
entidade e relacionamento quando estiver olhando os use cases.
Sistemas baseados na Web variam entre aplicaes que apenas retornam e apresentam pginas HTML
e aplicaes sofisticadas que integram a Web a recursos corporativos. Devemos identificar as abstraes chave
relacionadas aos componentes da aplicao e tambm s pginas de informao, para que as mesmas possam
ser modeladas. Estas abstraes chave tambm podem ser obtidas a partir do domnio do problema do sistema
baseado na Web que est sendo desenvolvido. As abstraes chave relacionadas s pginas de informao
sero identificadas pelo mecanismo de anlise "HTML" , conforme especificado no artefato Guidelines de
Projeto para a Web. Deve-se encontrar o mximo possvel de abstraes chave que representem as pginas de
informao, pois estas abstraes representaro as classes de anlise na prxima atividade.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
152
Passo: Criar Realizaes de Use-Case

Propsito
S Criar os artefatos do Modelo de Projeto usados para expressar o comportamento dos use cases.
Guidelines: Realizao dos Use Cases
Mentor de Ferramenta: Usando o Rational Rose para criar Realizaes de Use Case
Use Cases formam o foco central do trabalho inicial de anlise e projeto. Para possibilitar a transio
entre as atividades centradas nos Requisitos para atividades centradas no Projeto, o Artefato: Realizao de
Use Case serve como uma ponte, providenciando uma forma de rastrear o comportamento no Modelo de
Projeto para o Modelo de Use Case, to bem como para organizar as colaboraes no Modelo de Projeto em
torno do conceito de Use Case.
Para cada Use Case no Modelo de Use Case, cria-se uma Realizao de Use Case no Modelo de
Projeto. O nome da realizao deveria ser o mesmo do Use Case associado e um trao de dependncia deveria
ser estabelecido da realizao de use case para o use case associado.

Passo: Revisar os Resultados

Propsito
S Garantir que os resultados da anlise arquitetural esto completos e consistentes.
Check-points: Analisar Arquitetura
Com a Anlise Arquitetural concluda, revise os mecanismos arquiteturais, os subsistemas, os pacotes
e a classes que foram identificadas, para garantir que eles esto completos e consistentes. Como os resultados
da Anlise Arquitetural so preliminares e relativamente informais, a reviso tambm deve ser informal.
O check-point: Analisar Arquitetura contm alguns itens de checagem especficos para sistemas
baseados na Web.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
153
Atividade Analisar Use-Case

Propsito
S Identificar as classes que realizam o fluxo de eventos de um use case.
S Distribuir o comportamento do use case atravs destas classes, usando realizaes de use case.
S Identificar as responsabilidades, atributos e associaes das classes.
S Anotar o uso de mecanismos arquiteturais.
Passos
S Suplementar as Descries do Use Case
S Para cada realizao de use case
S Encontrar Classes atravs do Comportamento do Use Case
S Distribuir o Comportamento do Use Case para as Classes
S Para cada classe de anlise resultante
S Descrever Responsabilidades
S Descrever Atributos e Associaes
S Qualificar os Mecanismos de Anlise
S Unificar as Classes de Anlise
S Avaliar seus Resultados
Artefatos de Entrada:
S Glossrio
S Especificaes Suplementares
S Guidelines para Modelagem dos Use Cases
S Modelo de Use Case
S Realizaes de Use Case
S Documento de Arquitetura de Software
Artefatos Resultantes:
S Classes de Anlise
S Modelo de Anlise (opcional) ou Modelo de Projeto
S Realizaes de Use Case atualizadas
Freqncia: Uma vez por iterao, para um conjunto do Artefato: Realizaes de Use Case
Responsvel: Projetista
Guidelines: Workshop de Anlise de Use Case, Classes de Anlise.
Mentor de Ferramenta: Usando o Rational Rose para capturar o resultado da Anlise de Use Case
Em sistemas baseados na Web boa parte das classes de anlise relacionadas s pginas de informao
j foram identificadas durante a atividade "Anlise Arquitetural" como abstraes chave e identificadas com o
mecanismo de anlise "HTML". Apesar disso podemos encontrar ainda algumas classes de anlise a partir da
anlise detalhada dos use cases.
Para as classes de anlise relacionadas a pginas de informao o esforo deve ser concentrado na
definio dos atributos e associaes.
No necessrio executar o passo "Qualificar mecanismos de anlise" para o mecanismo "HTML"
definido durante a Anlise Arquitetural. Este mecanismo serve unicamente para distinguir as classes referentes
s pginas de informao.
Os passos, bem como o detalhamento desta atividade podem ser encontrados na verso 5.0 build 33
(1998) do Rational Unified Process.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
154
Atividade: Projetar Arquitetura

Propsito
S Analisar as interaes das classes de anlise para encontrar interfaces, classes de projeto e subsistemas
de projeto
S Refinar a arquitetura, incorporando reuso quando possvel.
S Identificar solues comuns para problemas de projeto normalmente encontrados
S Incluir os elementos do modelo de projeto arquiteturalmente significantes na Seo de Viso Lgica do
Documento de Arquitetura de Software.
Passos
S Identificar Mecanismos de Projeto
S Categorizar os Clientes dos Mecanismos de Projeto
S Inventariar os Mecanismos de Implementao
S Mapear os Mecanismos de Projeto para Mecanismos de Implementao
S Documentar os Mecanismos Arquiteturais
S Identificar Classes e Subsistemas de Projeto
S Identificar Interfaces
S Identificar Oportunidades de Reuso
S Engenharia Reversa de Componentes e Banco de Dados
S Definir a Organizao de Baixo Nvel dos Subsistemas
S Incluir Elementos de Modelo Arquiteturalmente Significantes na Viso Lgica
S Check-points: Modelo de Projeto
Artefatos de Entrada:
S Especificaes Suplementares
S Documento de Arquitetura de Software
S Modelo de Projeto
S Classes de Anlise
S Guidelines de Projeto
S Guidelines de Projeto para a Web
Artefatos Resultantes:
S Modelo de Projeto (Classes, Pacotes e Subsistemas)
S Documento de Arquitetura de Software atualizado
S Guidelines de Projeto atualizadas
S Guidelines de Projeto para a Web atualizadas
Freqncia: Uma vez por iterao
Responsvel: Arquiteto
Para sistemas baseados na Web o reuso fundamental. Aplicaes para a Web devem ser
desenvolvidas rapidamente para serem competitivas. A overengineering deve ser evitada, usando-se
componentes j existentes sempre que possvel. Em particular, as bibliotecas de classes e frameworks de
objetos normalmente avaliados para software OO deveriam ser utilizados sempre que possvel para
incrementar o reuso. Estudos comprovam que muitas vezes melhor (mais barato e mais rpido) comprar um
componente do que desenvolve-lo. Existe ainda a opo da utilizao de componentes freeware. O Conceito:
Reuso de Componentes traz alguns princpios para o reuso sistemtico de software.
Quando do desenvolvimento de sistemas baseados na Web compostos somente de pginas de
informao esta atividade no necessita ser realizada, pois no haver a existncia de subsistemas e interfaces.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
155
Passo: Identificar Mecanismos de Projeto

Propsito
S Refinar os mecanismos de anlise para mecanismos de projeto, baseando-se nas restries impostas
pelo ambiente de implementao.
Sub-passos:
S Categorizar os Clientes dos Mecanismos de Anlise
S Inventariar os Mecanismos de Implementao
S Mapear os Mecanismo de Projeto para Mecanismos de Implementao
S Documentar os Mecanismos de Projeto
Conceitos: Mecanismos de Anlise, Mecanismos de Projeto
Guidelines: Mecanismos de Projeto
Aplicaes baseadas na Web esto sendo desenvolvidas usando uma combinao de tecnologias de
orientao a objeto, cliente/servidor e Internet. Surge ento um grande nmero de opes de infra-estrutura
(Web servers, Web gateways, desenvolvimento baseado em Java versus CGI, middleware de objetos
distribudos, tecnologias de acesso a dados, configuraes de rede, dados multimdia, etc.) que levam a um
ilimitado nmero de opes tecnolgicas. A implementao de uma aplicao para a Web envolve este grande
nmero de tecnologias levando a um ambiente de implementao dos mais diversos e cheio de restries
(restries de linguagens de programao, de mdias, de middlewares, de browsers, plataforma do servidor,
etc.). Estas restries devem ser bem definidas antes que os mecanismos de anlise sejam mapeados para
mecanismos de projeto e estes para mecanismos de implementao. O mecanismo de anlise "HTML" no
necessita ser mapeado para nenhum mecanismo de projeto e conseqentemente para nenhum mecanismo de
implementao.

Sub-Passo: Categorizar os Clientes dos Mecanismos de Projeto

Identifique os clientes de cada mecanismo de anlise. Analise todos os clientes de um dado mecanismo de
anlise, procurando por caractersticas do mecanismo que eles necessitam.
Identifique os perfis de caractersticas de cada mecanismos de anlise. Pode haver uma grande variedade
de perfis de caractersticas, fornecendo vrios graus de desempenho, segurana, economia de custo, etc.
Agrupe os clientes de acordo com seu uso dos perfis de caractersticas. Forme grupos de clientes que
parecem compartilhar uma necessidade, de um mecanismo de anlise, com caractersticas similares; identifique
um mecanismo de projeto baseado em tal necessidade.

Sub-Passo: Inventariar os Mecanismos de Implementao

Faa um inventrio dos mecanismos de implementao que voc tem a sua disposio:
S Mecanismos oferecidos por produtos de middleware.
S Mecanismos oferecidos por sistemas operacionais.
S Mecanismos oferecidos por um componente.
S Mecanismos oferecidos por uma biblioteca de classes.
S Cdigo legado (ver Engenharia Reversa de Componentes e Banco de Dados abaixo).
S Pacotes de propsito especial: Geradores de GUI, Sistemas de Informao Geogrfica, SGBD.

Determine onde os mecanismos existentes podem ser usados e onde novos mecanismos de
implementao necessitam ser construdos.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
156
Sub-Passo: Mapear os Mecanismos de Projeto para Mecanismos de Implementao

Mecanismos de projeto providenciam uma abstrao dos mecanismos de implementao, ligando a
brecha que existe entre os mecanismos de anlise e os mecanismos de implementao. O uso de mecanismos
arquiteturais abstratos durante o projeto permite-nos um forma de se utilizar mecanismos arquiteturais sem
obscurecer o problema com detalhes de um mecanismo em particular. Ele tambm permite-nos substituir
potencialmente um mecanismo de implementao especfico por outro sem afetar adversamente o projeto.
Determine as variaes das caractersticas. Pegue as caractersticas identificadas para os mecanismos de
projeto e determine as variaes de seus valores.
Considere o custo de aquisio de componentes. Para mecanismos de implementao candidatos, considere
o custo de aquisio ou licenciamento, a maturidade do produto, o relacionamento com o seu vendedor, o
suporte, etc., alm dos critrios tcnicos.
Conduza a procura por componentes corretos, ou construa os componentes. Voc freqentemente
perceber que no h mecanismos de implementao apropriados para alguns mecanismos de projeto; isto
disparar uma procura por um certo produto, ou identificar a necessidade do seu desenvolvimento.
A escolha do mecanismo baseada no somente sobre uma boa soluo para as caractersticas
tcnicas, mas tambm sobre caractersticas no tcnicas, tais como custo. Algumas das escolhas pode ser
provisrias; quase sempre todas tero algum risco associado: desempenho, robustez, escalabilidade, so sempre
preocupaes que devem ser validadas atravs de avaliao, prototipao exploratria ou incluso em um
prottipo arquitetural.

Sub-Passo: Documentar os Mecanismos Arquiteturais

Os mecanismos, o mapeamento entre eles e os detalhes sobre seu uso, devem ser documentados no
Artefato: Guidelines de Projeto especfico para o projeto.

Passo: Identificar Classes e Subsistemas de Projeto

Propsito
S Refinar as classes de anlise, categorizando-as em classes de projeto e subsistemas.
Guidelines: Subsistemas de Projeto, Pacotes de Projeto, Mapeando Classes de Anlise para Classes de
Projeto, Representando Interfaces para Sistemas Externos, Representando Interfaces Grficas de Usurio.
Mentores de Ferramentas: Usando o Rational Rose para Gerenciar Classes, Usando o Rational Rose para
Gerenciar Subsistemas, Usando o Rational Rose para Gerenciar o Modelo de Projeto.
A Atividade: Analisar Use Case resulta em classes de anlise, que representam conceitos que
realizam um comportamento. No projeto, classes de anlise evoluem para classes de projeto e subsistemas,
refletindo a maior profundidade do projeto to bem como a imposio de restries impostas pelo ambiente de
implementao. Um subsistema , efetivamente, um tipo especial de pacote que tem somente interfaces como
elementos pblicos. As interfaces providenciam uma camada de encapsulamento, permitindo que o projeto
interno do subsistema possa permanecer escondido dos outros elementos do modelo.
Identifique as Classes. Quando a classe de anlise e simples e representa uma nica abstrao lgica, ela pode
ser mapeada diretamente para uma classe de projeto. Tipicamente, classes de entidade sobrevivem
relativamente intactas para o projeto. Desde que classes de entidade so tipicamente persistentes, determine se
as classes de projeto devem ser persistentes
Quando estiver identificando classes, elas devem ser agrupadas no Artefato: Pacotes de Projeto, para
propsitos de organizao e de gerenciamento de configurao. Ver as Guidelines: Pacotes de Projeto para
mais informao sobre como tomar decises de empacotamento.
Identifique os Subsistemas. Quando a classe de anlise for complexa, ela deve ser mapeada para um
subsistema de projeto. Um subsistema logicamente equivalente ao Artefato: Componente no Artefato:
Modelo de Implementao.
A deciso de criar um subsistema a partir de um conjunto de colaboraes de classes de anlise
baseada na experincia; a representao atual pode levar umas poucas iteraes para se estabilizar.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
157
Passo: Identificar Interfaces

Propsito
S Identificar as interfaces dos subsistemas baseando-se em suas responsabilidades.
Mentor de Ferramenta: Usando o Rational Rose para representar Interfaces
Identifique um conjunto de interfaces candidatas para todos os subsistemas. Para cada subsistema,
considere suas responsabilidades: organize-as em grupos de responsabilidades relacionadas e coesivas. Estes
grupos definem as interfaces iniciais para o subsistema. De incio, identifique uma operao para cada
responsabilidade.
Procure por similaridades entre as interfaces. De um conjunto candidato de interfaces, procure por nomes
similares, responsabilidades similares e operaes similares. Onde as mesmas operaes existirem em vrias
interfaces, reconstrua as interfaces, extraindo as operaes comuns para uma nova interface. Esteja certo que
voc esta utilizando o reuso quando possvel.
Defina as operaes. Para as novas interfaces, defina os nomes das operaes e os parmetros baseados nas
responsabilidades do subsistema.
Defina as dependncias da interface. Os parmetros de cada operao da interface tem um tipo particular:
eles podem realizar um interface particular ou eles podem ser instncias de um tipo de dado simples. Nos casos
onde os parmetros so objetos que realizam um interface em particular, defina associaes de dependncia
entre a interface e as interfaces das quais ela depende.
Mapeie as interfaces para os subsistemas. Uma vez que as interfaces foram identificadas, crie associaes de
realizao entre os subsistemas e as interfaces que eles realizam.
Empacote as interfaces. Se cada interface realizada por um nico subsistema, a interface pode ser colocada
dentro do subsistema. Se a interface realizada por mais de um subsistema, ela deve ser colocada dentro de um
pacote em separado. Isto permite que as interfaces sejam gerenciadas e controladas independentemente dos
subsistemas.

Passo: Identificar Oportunidades de Reuso

Propsito
S Identificar onde os subsistemas e/ou componentes pode ser reusados, baseando-se em suas interfaces.
Guidelines: Interfaces
O Conceito: Reuso de Componentes traz alguns princpios para o reuso sistemtico de software.
Procure por subsistemas ou componentes existentes que ofeream interfaces similares. Compare cada
interface identificada com as interfaces providenciadas por subsistemas ou componentes existentes.
Modifique as interfaces recentemente identificadas para aperfeioar o encaixe. Pode haver oportunidades
para que mudanas secundrias nas interfaces candidatas aumentem sua conformidade com as interfaces
existentes.
Substitua interfaces candidatas por interfaces existentes quando possvel. Depois da simplificao e da
reconstruo, se houver igualdade com alguma interface existente, elimine a interface candidata e
simplesmente use a interface existente.
Mapeie o subsistema candidato para componentes existentes. Quando um subsistema candidato pode ser
realizado por um componente existente, crie rastreamento entre o subsistema de projeto e o componente no
modelo de implementao.
No mapeamento de subsistemas para componentes, considere os mecanismos de projeto associados ao
subsistema; requisitos de desempenho ou segurana podem desqualificar um componente.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
158
Passo: Engenharia Reversa de Componentes e Banco de Dados

Propsito
S Incorporar elementos de modelo, potencialmente reusveis, de outros projetos, fontes externas ou
iteraes anteriores.
Guidelines: Engenharia Reversa de Banco de Dados Relacional, Mapeando um Modelo de Objetos para um
Banco de Dados Relacional.
Mentor de Ferramenta: Usando o Rational Rose para realizar Engenharia Reversa de Cdigo
Baseando-se sobre os resultados do passo Identificar Oportunidades de Reuso, cdigo e definies de
bancos de dados existentes podem ser utilizados. Usando-se as oportunidades de reuso como um filtro, o
trabalho de realizar a engenharia de forma reversa pode ser focado sobre os componentes que foram reusados
na iterao atual.
Engenharia Reversa de Componentes
Em organizaes que constroem sistemas similares, h freqentemente um conjunto de componentes
comuns que providenciam muitos dos mecanismos arquiteturais necessrios para um novo sistema. Pode haver
tambm componentes avaliados no mercado que atendem as necessidades. Componentes existentes deveriam
ser examinados para determinar sua convenincia e compatibilidade dentro da arquitetura do software.
Componentes existentes, ou desenvolvidos durante interaes anteriores, mas ainda no includos no
Modelo de Projeto, ou componentes comprados, devem passar pelo processo de engenharia reversa e serem
incorporados no modelo de projeto. No modelo de projeto, cada componente representado como um
subsistema com uma ou mais interfaces.
Engenharia Reversa de Banco de Dados
Bancos de dados e os dados residentes neles, representam uma das mais importantes fontes de
recursos reusveis. Para reusar as definies de classes includas nos bancos de dados existentes, determine que
informao usada pela aplicao j existe em algum banco de dados. Realize a engenharia reversa de um
conjunto de classes para representar as estruturas do banco de dados que manuseia esta informao (para mais
informao, veja a Guideline: Engenharia Reversa de Banco de Dados Relacional). Construa um mapeamento
entre a representao da classe na aplicao e a estrutura usada no banco de dados. Para o mapeamento entre
classes e tabelas em um banco de dados relacional, veja a Guideline: Mapeando um Modelo de Objetos para
um Banco de Dados Relacional.

Passo: Definir a Organizao de Baixo Nvel dos Subsistemas

Propsito
S Organizar as camadas inferiores no Modelo de Projeto.
Guidelines: Diviso em Camadas, Subsistemas de Projeto, Pacotes de Projeto
Mentor de Ferramenta: Usando o Rational Rose para Gerenciar o Modelo de Projeto
As camadas inferiores da arquitetura providenciam a interface para a infra-estrutura do sistema. Os
pacotes e subsistemas de mais baixo nvel providenciam uma forma para estruturar o modelo de projeto e para
aperfeioar sua estabilidade, legibilidade e flexibilidade. A diviso em camadas pode, tambm, providenciar
um forma para reduzir o impacto de mudanas: atravs de regras que restringem as dependncias entre pacotes
e subsistemas, reduzindo o grau de acoplamento e tornando, desta forma, o sistema mais robusto.
Atribua as responsabilidades de subsistemas e camadas para indivduos ou equipes. Cada pacote ou
subsistema deveria ser de responsabilidade de uma nica pessoa ou equipe.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
159
Passo: Incluir Elementos de Modelo Arquiteturalmente Significantes na Viso Lgica

Propsito
S Documentar os resultados do Projeto Arquitetural
Guideline: Viso Lgica
Mentor de Ferramenta: Usando o Rational Rose para Gerenciar o Modelo de Projeto
Quando classes, pacotes e subsistemas (elementos de modelo) so importantes em uma perspectiva
arquitetural, eles deveriam ser includos na Seo Viso Lgica do Documento de Arquitetura de Software.
Isto tornar o modelo de projeto homogneo e ao mesmo tempo tornar a arquitetura consistente.

Atividade: Descrever a Concorrncia

Propsito
S Definir requisitos de concorrncia, identificar processos, identificar mecanismos de comunicao entre
processos, alocar recursos de coordenao entre processos, identificar ciclo de vida de processos e
distribuir elementos de modelo entre os processos.
Passos
S Definir os Requisitos de Concorrncia
S Identificar Processos
S Identificar o Ciclo de Vida dos Processos
S Identificar Mecanismos de Comunicao entre Processos
S Alocar Recursos de Comunicao entre Processos
S Mapear Processos para o Ambiente de Implementao
S Distribuir Elementos de Modelo entre os Processos
Artefatos de Entrada:
S Especificaes Suplementares
Artefatos Resultantes:
S Viso de Processo do Documento de Arquitetura de Software
Responsvel: Arquiteto
Guidelines: Conceito: Concorrncia, Checkpoint: Viso de Processo.
Mentor de Ferramenta: Usando o Rational Rose para Documentar o Modelo de Processo
Quando do desenvolvimento de sistemas baseados na Web compostos somente de pginas de
informao, esta atividade no necessita ser realizada. No haver a necessidade de definio de concorrncia
ou identificao de processos.
Os passos, bem como o detalhamento desta atividade podem ser encontrado na verso 5.0 build 33
(1998) do Rational Unified Process.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
160
Atividade: Descrever a Distribuio

Propsito
S Descrever como a funcionalidade do sistema ser distribuda atravs dos ns fsicos. Necessria
somente para sistemas distribudos.
Passos
S Definir a Configurao da Rede
S Levantar a Estrutura de Comunicao
S Analisar Requisitos e Caractersticas que impactam a Arquitetura do Sistema
S Definir Arquitetura do Sistema
S Alocar os Processos para os Ns
S Avaliar seus Resultados
Artefatos de Entrada:
S Viso de Processo do Documento de Arquitetura
de Software
S Modelo de Implementao
S Guidelines de Projeto para a Web
Artefatos Resultantes:
S Viso de Implantao do Documento de
Arquitetura de Software
Responsvel: Arquiteto
Conceitos: Padres de Distribuio
Mentor de Ferramenta: Usando o Rational Rose para Documentar a Viso de Implantao
Para sistemas baseados na Web esta atividade tambm tem o objetivo de localizar o sistema dentro da
Internet, ou seja, determinar o site, o backbone, alm de determinar questes como espelhamento, segurana a
nvel de rede (firewalls e servidores proxy), etc.
A distribuio de processos atravs de dois ou mais ns requer uma examinao detalhada dos
padres de comunicao entre processos do sistema. Freqentemente, h uma viso de que a distribuio de
processos pode deslocar a carga de trabalho de uma mquina para outra. Na prtica, a carga de trabalho da
comunicao entre processos adicional pode facilmente negar qualquer ganho de distribuio, caso o processo
e as fronteiras dos ns no sejam considerados cuidadosamente.
Mesmo assim, h muitos casos onde a carga de trabalho do sistema no pode ser manuseada por um
nico processador. Isto pode acontecer devido aos requisitos de distribuio. Pode tambm ser resultado de
preocupaes com a escalabilidade, onde um grande nmero de usurios concorrentes no pode ser suportado
por um nico processador ou pode resultar de preocupaes econmicas, onde o preo do desempenho
menor.
A descrio da distribuio em sistemas baseados na Web uma atividade crtica. A Internet uma
rede bastante complexa e qualquer sistema que funcione sobre a mesma deve considerar uma srie de questes
para que possa ter o desempenho, segurana, confiabilidade e disponibilidade necessrias. Devemos considerar
questes como: desempenho do backbone, balanceamento de carga, segurana a nvel de rede (firewall e
proxy), espelhamento e replicao, redundncia de dados e de processamento, interoperabilidade e interface
com outros sistemas, etc. Estas preocupaes so fundamentais na definio da infra-estrutura ou arquitetura de
sistema para uma aplicao baseada na Web.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
161
Passo: Definir a Configurao da Rede

Propsito
S Entender a configurao e a topologia da rede.
Sub-passos:
S Levantar a Estrutura de Comunicao
S Analisar Requisitos e Caractersticas que impactam a Arquitetura do Sistema
S Determinar Arquitetura do Sistema
Os sub-passos deste passo referem-se a sistemas baseados na Web.
A topologia da rede e as capacidades e caractersticas dos processadores e mecanismos da rede
determinaro a natureza e o grau de distribuio possvel para o sistema.
As seguintes informaes necessitam ser capturadas:
S Layout fsico da rede, incluindo as localizaes.
S Os ns da rede, suas configuraes e capacidades. A configurao inclui o hardware e o software
instalados nos ns, o nmero de processadores, a quantidade de espao em disco, a quantidade de
memria, a quantidade de swap, etc. O hardware instalado no n pode ser representado atravs de
"devices".
S A largura de banda de cada segmento da rede.
S A existncia de qualquer caminho redundante na rede.
S O propsito primrio do n. Isto inclui:
S estaes de trabalho usadas pelos usurios;
S ns servidores nos quais o processamento ocorre;
S configuraes especiais usadas para desenvolvimento e teste;
S outros processadores especializados.

Sub-Passo: Levantar a Estrutura de Comunicao
Mapear a estrutura de comunicao da Internet, levantando os principais backbones, gateways, sub-
redes, linhas de comunicao e suas principais caractersticas (taxa de transmisso de dados, disponibilidade,
etc.) e as reas alcanadas pelos mesmos.

Sub-Passo: Analisar Requisitos e Caractersticas que impactam a Arquitetura do Sistema
Durante a etapa de elicitao de requisitos alguns tipos de requisitos especiais para sistemas baseados
na Web foram definidos e devem ser analisados. Neste momento devemos analisar os requisitos relacionados
comunidade de usurios qual se destina a aplicao em desenvolvimento (localizao do ncleo base de
usurios, requisitos de tempo de resposta esperado, requisitos de escala e crescimento, restries de
disponibilidade, etc.) e juntamente analise das caractersticas da aplicao determinadas durante o seu
projeto, devemos eleger a sub-rede ou site mais apropriado para a implantao do sistema.
As seguintes caractersticas necessitam ser analisadas:
S taxa de transmisso de dados necessria para que a aplicao possa ter um desempenho aceitvel;
S necessidade de integrao com outros sistemas baseados na Web (a localizao destes sistemas
muito importante);
A partir da determinao do site mais apropriado para a implantao do sistema baseado na Web em
questo devemos nos preocupar com a definio de toda a arquitetura de sistema ou infra-estrutura necessria
para a execuo satisfatria da aplicao.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
162

Sub-Passo: Definir a Arquitetura do Sistema
Uma vez determinado o site mais apropriado para a implantao da aplicao devemos definir toda a
infra-estrutura ou arquitetura de sistema necessria para a execuo satisfatria do sistema.
A topologia do sistema e as capacidades e caractersticas dos processadores e mecanismos envolvidos
(clientes, servidores de aplicao e dados e outros dispositivos como firewall, servidor proxy, etc.)
determinaro a natureza e grau de distribuio possvel no sistema.
As seguintes informaes necessitam ser definidas:
S Os ns de processamento, suas configuraes e capacidades. A configurao inclui o hardware e
software instalado nos ns, o nmero de processadores, o quantidade de espao em disco, a
quantidade de memria, a quantidade de swap, etc. O hardware instalados nos ns pode ser
representados atravs de "devices".
S A taxa de transmisso entre ns.
S A existncia de espelhamento/replicao (esta uma forma de providenciar capacidades de
tolerncia a falhas).
S O propsito primrio de um n. Isto inclui:
S estaes de trabalho usadas pelos usurios finais;
S servidores de aplicao e servidores de dados;
S configuraes especiais usadas para desenvolvimento e teste;
S outros processadores especializados, como firewall (filtram o trfico no permitido) e
servidores proxy (reescrevem pacotes escondendo a fonte original).
A descrio dos ns que representam as mquinas dos usurios finais deve se ater s caractersticas
mnimas exigidas para a execuo do sistema, caractersticas de hardware, mas principalmente de software, de
forma a suportar as diversas tecnologias empregadas na implementao da aplicao.

Passo: Alocar os Processos para os Ns

Propsito
S Distribuir a carga de trabalho do sistema.
Processos deveriam ser alocados para ns de forma a minimizar a quantidade de trfego na rede;
processos que possuem um alto grau de interao deveriam ser colocados no mesmo n; processos que
interagem com menor freqncia podem residir em ns diferentes.
A alocao deve levar em conta:
S A capacidade do n (em termos de memria e poder de processamento)
S Largura mdia de banda passante para comunicao (barramento, LANs, WANs)
S Disponibilidade de hardware e links de comunicao
S Requisitos de redundncia e tolerncia a falhas
S Requisitos de tempo de resposta
S Requisitos de throughput
S e assim por diante.
Algumas guidelines para a alocao de processos para os ns, referentes a sistemas baseados na Web,
podem ser encontradas no Artefato: Guidelines de Projeto para a Web.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
163
Passo: Avaliar seus Resultados

Propsito
S Avaliar a viso de implantao.
Ver os Checkpoints para a Viso de Implantao.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
164
Atividade: Revisar a Arquitetura

Propsito
S Descobrir alguns riscos no percebidos ou desconhecidos no planejamento do sistema.
S Detectar alguma falha de projeto arquitetural. Falhas arquiteturais so difceis de serem resolvidas, a
maioria demanda muito tempo.
S Detectar potenciais desencontros entre a arquitetura e os requisitos. Em particular, a avaliao pode
examinar alguns aspectos freqentemente negligenciados nas reas de operao, administrao e
manuteno. Como o sistema instalado? Atualizado? Como ns realizamos a transio das atuais bases
de dados?
S Avaliar uma ou mais Qualidades arquiteturais especficas: desempenho, confiabilidade,
manutenibilidade, Segurana de acesso, segurana de dados e transaes.
S Identificar oportunidades de reuso.
S Testar a arquitetura.
Passos
S Planejar a Reviso
S Preparar a Reviso
S Conduzir a Reviso
S Alocar as Responsabilidade de Resoluo de Defeitos
S Testar a Arquitetura
Artefatos de Entrada:
S Documento de Arquitetura de Software
S Especificaes Suplementares
S Guidelines de Projeto
S Lista de Riscos
S Guidelines de Projeto para a Web
Artefatos de Entrada:
S Documento de Arquitetura de Software
(aprovado), ou
S Requisies de Mudanas (opcional)
Responsvel: Revisor da Arquitetura
Participantes: Arquiteto, Projetista
Guidelines de Trabalho:
S Conduza a reviso atravs de um encontro formal, apesar de que os participantes podem preparar
algumas revises por conta prpria.
S Monitore continuamente a qualidade durante o projeto para evitar um grande nmero de defeitos que
permanecero at a reviso. Em cada atividade de projeto, os checkpoints listados abaixo podem ser
utilizados; use-os para revises informais no trabalho do dia-a-dia.
S Checklists: Arquitetura de Software (geral), Viso de Processo, Viso de Implantao, Modelo de
Projeto.
O Checklist: Arquitetura de Software Baseado na Web contm pontos de verificao da arquitetura
especficos para sistemas baseados na Web.
O passo "Testar a arquitetura" s deve ser realizado caso o revisor achar que propcio e necessrio.
Sistemas baseados na Web compostos somente de pginas de informao no necessitam de ter sua arquitetura
testada. O revisor pode alocar a responsabilidade do teste da arquitetura a uma pessoa ou a um grupo de
desenvolvedores ou de testadores.
Visto de 20,000 ps no h muito de diferente entre a avaliao da arquitetura de software e qualquer
outra avaliao ou reviso.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
165
Contudo, uma caracterstica importante da arquitetura de software a falta de medidas especficas
para muitos atributos de qualidades arquiteturais somente umas poucas qualidades arquiteturais podem ser
objetivamente medidas. Desempenho um exemplo onde a medida possvel. Outras qualidades so muito
mais subjetivas como a integridade conceitual, por exemplo. Contudo, freqentemente difcil decidir o que
uma mtrica significa na ausncia de outros dados ou referncias para comparao. Se uma referncia para o
sistema avaliada e entendida pelo pblico alvo, comum expressar alguns dos resultados em uma viso
relativa a este sistema referncia.
1. No fim da fase de concepo em um ciclo de desenvolvimento inicial, h muito pouco de
concreto sobre a arquitetura. Mas uma reviso pode descobrir objetivos no realsticos, partes que
esto faltando, oportunidades de reuso, etc.
2. O lugar mais natural para uma avaliao da arquitetura de software no fim da fase de
elaborao. Esta fase foca-se principalmente na explorao dos requisitos em detalhes e na
construo da linha base da arquitetura. Neste caso uma grande variedade de qualidades
arquiteturais so examinadas.
3. Uma avaliao mais focada pode ser realizada durante a fase de construo para examinar
atributos de qualidade especficos, tais como desempenho ou segurana.
4. Avaliao de controle de prejuzos pode ser feita no final da fase de construo ou mesmo na fase
de transio, quando certas coisas podem realmente ter dado errado: construo no completa, ou
um nvel inaceitvel de problemas na base instalada durante a transio.
5. Finalmente uma reviso pode ser realizada no fim da fase de transio para inventariar partes
reusveis para eventuais novos produtos ou ciclos de evoluo.

Passo: Planejar a Reviso

Propsito
S Determinar o foco da reviso
S Determinar o escopo da reviso
Antes da reviso, defina o escopo da mesma, determinando as questes que sero revisadas; defina o
que ser avaliado e porque ser avaliado. Veja os checkpoints referenciados acima para os tipos de
preocupaes que deveramos ter. As questes exatas dependero da fase em que se est.
Uma vez que o escopo foi determinado, defina os participantes da reviso, a agenda e a informao
que ser necessria para realizar a reviso. Tendo selecionados os participantes, estabelea um balano entre os
conhecimentos da arquitetura de software e os conhecimentos do domnio. Designe um lder para a avaliao.
Revisores deveriam ser experientes na arquitetura de software ou no domnio do problema do sistema
em questo.

Passo: Planejar a Reviso

Propsito
S Reunir e distribuir material de preparao para a reviso antes das sesses de reviso, de forma que os
revisores tenham tempo suficiente para entender a arquitetura e possam formar comentrios.
Guidelines: Arquitetura de Software (geral), Viso de Processo, Viso de Implantao, Modelo de Projeto.
A fonte primria de informao para a reviso o Documento de Arquitetura de Software,
suplementado com detalhes adicionais de partes de interesse da arquitetura, do modelo de projeto, notas de
projeto ou documentao de explanao adicional. Em adio, checklists de reviso deveriam circular para
estimular preocupaes e levantar problemas.
Revisores deveriam estudar a documentao, formular preocupaes e identificar questes para
discusso, antes da reviso.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
166
Passo: Conduzir a Reviso

Propsito
S Avaliar a Arquitetura de Software
S Identificar problemas na arquitetura.
Em geral, o processo de reviso segue um ciclo repetitivo:
S Uma questo levantada pelo revisor
S A questo discutida, e potencialmente confirmada
S Um defeito identificado
S Continua-se at que nenhuma outra questo seja identificada

Diversas tcnicas podem ser usadas para a reviso:
S dirigida representao
S dirigida informao
S dirigida cenrio

Reviso dirigida representao
Obtm-se (ou constri-se) uma representao da arquitetura, e ento levanta-se questes baseando-se
nessa representao.
Reviso dirigida informao
Estabelea a lista de informaes - dados, medidas - que so necessrias, pegue a informao e
compare-a aos requisitos ou algum padro de referncia aceitvel. Isto aplica-se bem para a investigao de
certos atributos de qualidade, tais como desempenho ou robustez.
Reviso dirigida cenrio
Esta uma tcnica sistemtica. Transforme as questes gerais a serem levantadas em um conjunto de
cenrios e percorra estes cenrios.

Passo: Alocar as Responsabilidades de Resoluo de Defeitos

Propsito
S Realizar aes sobre os defeitos identificados.
Depois da reviso, aloque as responsabilidades para cada defeito encontrado. "Responsabilidade" em
muitos casos pode no ser consertar o defeito, mas coordenar a investigao de alternativas ou coordenar a
resoluo do defeito.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
167
Passo: Testar Arquitetura

Propsito
S Testar a arquitetura projetada para o sistema.
Sistemas baseados na Web geralmente possuem arquiteturas robustas, flexveis e escalveis,
projetadas para providenciar desempenho e para manusear uma carga de transaes alta e imprevisvel. Estas
arquiteturas geralmente so multi-camadas, encapsulando lgica de negcios e integrando mltiplos sistemas
legados.
Estas arquiteturas necessitam ser testadas buscando o alcance dos requisitos de desempenho e
confiabilidade da aplicao. Quanto mais adiantado estiver o desenvolvimento da aplicao mais caro ser a
mudana da arquitetura da mesma, caso um problema seja detectado. Dessa forma devemos testar a arquitetura
o quanto antes possvel. Testando a arquitetura durante o projeto da aplicao, garantimos que nenhum esforo
de implementao ser despendido inutilmente para a sua construo e que os requisitos de desempenho e
confiabilidade sero alcanados.
O teste da arquitetura inicia durante a fase de Elaborao, quando vrios prottipos executveis da
arquitetura devem ser construdos. Testar estes prottipos o quanto antes no processo de desenvolvimento
permite-nos alcanar um mximo de desempenho e confiabilidade antes que o resto do sistema seja projetado e
desenvolvido. Isto permite a produo de uma arquitetura mais estvel, evitando que grandes mudanas sejam
feitas no sistema em virtude de alteraes na arquitetura.
Todos os componentes da arquitetura devem ser testados para evitar que gargalos de desempenho
ocorram quando o sistema baseado na Web for implantado.
Os fabricantes geralmente testam o desempenho de seus componentes. Contudo, os fabricantes no
testam os padres de comportamento especfico que ocorrem quando seus componentes so invocados por
outras aplicaes. Tambm no testam a carga produzida sobre a rede devido a implantao do componente. Se
sua arquitetura usa componentes adquiridos de outros fabricantes ser necessrio testar como estes
componentes sero usados pela sua aplicao.
A atividade de teste da arquitetura dever ser, quando possvel, automatizada por alguma ferramenta
CASE, como, por exemplo, Rational PerformanceArchitect e Rational LoadTest.
Todos os problemas (desempenho, confiabilidade, etc.) encontrados na arquitetura devem ser
repassados para o arquiteto de software, ou para a equipe de arquitetura, responsvel.


Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
168
Atividade: Projetar Subsistema

Propsito
S Definir o comportamento especificado nas interfaces dos subsistemas em termos de colaboraes de
classes contidas.
S Documentar a estrutura interna do subsistema.
S Definir realizaes entre as interfaces dos subsistemas e as classes contidas.
S Determinar as dependncias entre os subsistemas.
Passos
S Distribuir o Comportamento do Subsistema para os Elementos do Subsistema
S Documentar os Elementos do Subsistema
S Descrever as Dependncias do Subsistema
S Checkpoints: Subsistemas de Projeto
Artefatos de Entrada:
S Realizaes de Use Case
S Subsistemas de Projeto com suas
Definies de Interface
Artefatos Resultantes:
S Realizaes de Use Case
S Subsistemas de Projeto com suas Definies de Interface
S Classes de Projeto
Freqncia: Uma vez por subsistema de projeto
Responsvel: Projetista
Guidelines: Subsistemas de Projeto, Interfaces.
Os passos, bem como o detalhamento desta atividade podem ser encontrados na verso 5.0 build 33
(1998) do Rational Unified Process.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
169
Atividade: Projetar Classe

Propsito
S Garantir que as classes providenciam o comportamento que as realizaes de use Case requerem.
S Garantir que fcil implementar as classes.
S Manusear os requisitos no funcionais relacionados s classes.
S Incorporar os mecanismos de projeto usados pelas classes.
Passos
S Criar as Classes de Projeto Iniciais
S Projetar as Classes Limite
S Projetar as Classes Entidade
S Projetar as Classes Controle
S Identificar as Classes Persistentes
S Definir a Visibilidade das Classes
S Definir as Operaes
S Identificar as Operaes
S Nomear e Descrever as Operaes
S Definir a Visibilidade das Operaes
S Definir as Operaes da Classe
S Definir os Mtodos
S Definir os Estados
S Definir os Atributos
S Definir as Dependncias
S Definir as Associaes
S Definir as Associaes e Agregaes
S Manusear Associaes Subscribes entre Classes de Anlise
S Definir Generalizaes
S Manusear Requisitos No Funcionais em Geral
S Avaliar os Resultados
Artefatos de Entrada:
S Especificaes Suplementares
S Guidelines de Projeto
S Classes de Anlise
S Use Cases
S Realizaes de Use Case
S Modelo de Projeto
Artefatos Resultantes:
S Classes de Projeto
Responsvel: Projetista
Mentor de Ferramenta: Usando o Rational Rose para Gerenciar Classes
Os passos, bem como o detalhamento desta atividade podem ser encontrados na verso 5.0 build 33
(1998) do Rational Unified Process.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
170
Atividade: Projetar Use-Case

Propsito
S Refinar as realizaes de use case em termos de interaes.
S Refinar os requisitos sobre as operaes das classes de projeto.
S Refinar os requisitos sobre as operaes dos subsistemas e/ou suas interfaces.
Passos
S Descrever as Interaes entre os Objetos de Projeto
S Simplificar os Diagramas de Seqncia usando Subsistemas (opcional)
S Descrever o Comportamento relacionado Persistncia
S Escrevendo Objetos Persistentes
S Lendo Objetos Persistentes
S Deletando Objetos Persistentes
S Modelar Transaes
S Manusear Condies de Erro
S Manusear Controle de Concorrncia
S Refinar o Fluxo de Descrio de Eventos
S Unificar Classes e Subsistemas
S Avaliar os Resultados
Artefatos de Entrada:
S Especificaes Suplementares
S Use Cases
S Realizaes dos Use Case
S Classes de Projeto
S Subsistemas de Projeto
S Interfaces
Artefatos Resultantes:
S Realizaes dos Use Case, descritos com diagramas de
seqncia, e fluxo de eventos refinado.
Responsvel: Projetista
Os passos, bem como o detalhamento desta atividade podem ser encontrados na verso 5.0 build 33
(1998) do Rational Unified Process.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
171
Atividade: Projetar Contedo

Propsito
S Levantar as informaes a serem disseminadas.
S Editar as informaes levantadas.
Passos

Artefatos de Entrada:
S Guidelines de Projeto para a Web
S Modelo de Navegao
S Modelo de Use Case
S Especificaes Suplementares
Artefatos Resultantes:
S Modelo de Contedo
Responsvel: Projetista de Contedo
Os passos, bem como o detalhamento desta atividade, no foram definidos neste framework.

Atividade: Projetar Navegao

Propsito
S Projetar a forma atravs da qual os usurios navegaro.
S Definir as estruturas navegacionais.
Passos

Artefatos de Entrada:
S Guidelines de Projeto para a Web
S Especificaes Suplementares
S Modelo de Use Case
S Modelo de Anlise
S Modelo de Projeto
Artefatos Resultantes:
S Modelo de Navegao
Responsvel: Projetista de Navegao
Os passos, bem como o detalhamento desta atividade, no foram definidos neste framework.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
172
Atividade: Projetar Interface

Propsito
S Definir a aparncia dos elementos navegacionais.
S Definir quais objetos da interface ativaram a navegao e outras funcionalidades.
S Definir quais transformaes na interface ocorreram.
Passos

Artefatos de Entrada:
S Guidelines de Projeto para a Web
S Modelo Navegacional
Artefatos Resultantes:
S Modelo de Interface
Responsvel: Projetista de Navegao
Os passos, bem como o detalhamento desta atividade, no foram definidos neste framework.

Atividade: Projetar Banco de Dados

Propsito
S Garantir que os dados persistentes so armazenados consistente e eficientemente.
S Definir o comportamento que deve ser implementado no banco de dados.
Passos
S Mapear as Classes de Projeto Persistentes para o Modelo de Dados
S Otimizar o Desempenho do Modelo de Dados
S Otimizar o Acesso aos Dados
S Definir as Caractersticas de Armazenamento
S Definir as Tabelas de Referncia
S Definir Dados e Regras de Entidade Referencial
S Distribuir o Comportamento das Classes para o Banco de Dados
S Revisar os Resultados
Artefatos de Entrada:
S Especificaes Suplementares
S Guidelines de Projeto
S Modelo de Projeto
S Realizaes de Use Case
S Modelo de Dados
Artefatos Resultantes:
S Modelo de Dados
S Requisies de Mudana no Modelo de Projeto
Responsvel: Projetista de Banco de Dados
Os passos, bem como o detalhamento desta atividade, podem ser encontrados na verso 5.0 build 33
(1998) do Rational Unified Process.

Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
173
Guidelines de Projeto para a Web

Objetivos
Uma breve descrio do propsito das Guidelines de projeto para a Web.

Escopo
Uma breve descrio sobre o que as Guidelines de Projeto para a Web se aplicam; o que afetado ou
influenciado por este documento. Outras sees podem ser inclusas neste documento.

Referncias
Uma lista de documentos relacionados ou referenciados.

Guidelines Gerais de Projeto e Implementao para a Web
Esta seo descreve os princpios e estratgias a serem usadas durante o projeto e implementao do
sistema baseado na Web.

Convenes de Modelagem
1. Criar diagrama de componentes, para a viso de implantao, especificando os vrios pacotes
que compem a aplicao(componentes de software e pginas de informao), mostrando a
localizao desses componentes nas respectivas camadas.
2. Representar a viso de implantao atravs de diagramas de implantao ressaltando todas as
caractersticas dos ns envolvidos na arquitetura da aplicao para a Web, o tipo de gateway
empregado, o tipo de middleware que ser necessrio, o tipo da plataforma de computao, etc.
3. Todas as abstraes chave e classes de anlise levantadas durante a anlise arquitetural e a anlise
de use case que representem pginas de informao devem ser identificadas pelo esteretipo
boundary e pelo mecanismo de anlise "HTML".
4. A partir do projeto da arquitetura as pginas de informao, cujo propsito a apresentao de
informaes, devem ser modeladas segundo a seguinte padro:

Padro Pagina HTML

S Nome: Pagina HTML

S Objetivo: Representar as pginas de informaes cujo propsito a apresentao de informaes.
Estas pginas no interagem com nenhum componente de software.

S Motivao:
1. Separao da representao das pginas de informao dos componentes de software.
2. Separao da representao dos tipos de pginas de informao: pginas que somente
apresentam informaes e pginas que executam funes de componentes de software.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
174
S Estrutura:
PSNomePaginaServidora1
<<Pagina Servi dora>>
PNomePagi naHTML2
attributes
operations()
<<Pagina HTML>>
PNomePaginaHTML1
attributes
operations()
<<Pagina HTML>>
*
*
<<l i nk>>
*
*
<<l i nk>>
*
*
*
*

1. Uma pagina HTML pode estar ligada unicamente a outra pagina HTML ou a uma pgina que
execute alguma funo de um componente de software, aqui representada pelo padro Pagina
Servidora.
2. Os atributos de uma Pagina HTML representam as informaes que a mesma deve apresentar.
Exemplo: Supondo que a PNomePaginaHTML1 fosse a pgina principal de um site de compras;
compras de cd, compras de livros, compras de produtos eletrnicos, logotipo do site, banner para
promoes e seriam possveis atributos para esta pgina.
3. As operaes de uma Pagina HTML representam todas as funes que eventualmente podem ser
acionadas atravs da mesma, inclusive ligaes (links) com outras pginas. Exemplo: Supondo
que a PNomePaginaHTML1 fosse a pgina principal de um site de compras; acessar pgina de
cd, acessar pgina de livros e acessar pgina de promoes seriam possveis operaes para esta
pgina.

S Colaboraes: Uma Pagina HTML pode estar ligada a vrias outras Paginas HTML ou a pginas
de informao que possuam associadas a elas algum processamento baseado no servidor. A partir
de uma Pagina HTML pode se navegar somente para outras pginas de informao.

S Aplicabilidade e Conseqncias:
1. Use o padro quando voc quiser representar pginas de informaes, suas informaes e suas
operaes.
2. Facilita a legibilidade dos diagramas que descrevem a estrutura da aplicao.
3. Identifica classes que faro parte do modelo de navegao.

Mecanismos de Anlise
1. Mecanismos de anlise capturam aspectos chaves de uma soluo de forma independente da
implementao. fundamental em sistemas para a Web a diferenciao entre pginas de
informao e componentes de aplicao. Desta forma as abstraes chave e as classes de anlise
que representarem pginas de informao devero ser identificadas atravs do mecanismo de
anlise HTML. Durante o projeto arquitetural quando os elementos de anlise estiverem sendo
transformados em elementos de projeto, este mecanismo de anlise poder ser mapeado
utilizando-se a conveno de modelagem "Pagina HTML" e o padro de projeto "Pagina
Servidora" descritos neste documento. O propsito nico deste mecanismo a identificao das
classes que representam as pginas de informao.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
175
Reusabilidade de Componentes
1. Evite a overengineering. Sempre que possvel use componentes j criados. Aplicaes para a
Web devem ser desenvolvidas rapidamente para serem competitivas. Fique de olho no Web Time
ou Internet Time.
2. melhor comprar do que desenvolver. Isto especialmente verdade no caso de software baseado
na Web. Uma grande quantidade de esforo e dinheiro pode ser economizado. Preste ateno no
freeware.

Guidelines para o Projeto de Banco de Dados
Esta seo define regras e recomendaes para o projeto do banco de dados para um sistema baseado
na Web.
1. Determine quais as fontes de dados (HTML, arquivos, bancos de dados) sero necessrias, onde elas esto
localizadas e como acess-las.
2. No distribua demais os dados (overdistribute). O Compartilhamento de dados altamente distribudos
entre milhares de usurios torna-se mais difcil e o desempenho pode piorar, uma vez que a rede pode
possuir mais pontos de congestionamento.
3. Use a viso de implantao para descrever a distribuio fsica dos dados atravs dos ns.

Guidelines para a Definio da Arquitetura
Esta seo define regras e recomendaes para o projeto arquitetural de um sistema baseado na Web.
1. Determine o que ser escrito como aplicao e o que ser escrito como pginas de informao.
2. Analise a poro de cdigo que ser processada nas vrias camadas da aplicao (cliente, Servidor Web,
Servidor de Dados, Servidor de Aplicao, etc ...) de forma que no haja sobrecarga de processamento.
3. Verifique se a arquitetura est adequada quanto ao desempenho e confiabilidade. Tcnicas de
redundncia de dados e de processamento podem ser usadas para tal fim.
4. Interaes entre dados e programas atravs de mltiplos computadores e sistemas na Internet introduzem
muitos problemas de segurana e controle de integridade. A arquitetura deve ser projetada para permitir o
mximo de segurana tanto a nvel de rede (firewalls que filtram o trfico no permitido e servidores
proxy que reescrevem pacotes para esconder sua fonte original) e a nvel de aplicao (autenticao,
autorizao e segurana de controle, de dados e de transao).
5. Uma aplicao em um site pode afetar muitas aplicaes que residem em outros sites. Desta forma muitos
pontos de falhas so introduzidos. Interfaces com sistemas legados e outros sistemas na Web s devem
existir se forem realmente necessrias e devem ser cercadas de todo tipo de segurana possvel.
6. Verifique se os requisitos operacionais foram corretamente elicitados pois representam uma grande
quantidade de informao, de desempenho, segurana e interconectividade. Projete a arquitetura e o
sistema para atender estes requisitos.
S Requisitos de escala e crescimento (nmero de usurios que acessaro o sistema, quantidade de
operaes realizadas pelos mesmos, freqncia de chegada de transaes em diferentes sites,
tamanho do banco de dados).
S Requisitos de tempo de resposta dos usurios (mdia, pior caso).
S Requisitos de segurana (criptografia, id seguro).
S Restries de disponibilidade (7 dias por semana, 24 horas por dia).
S Conformidade com os padres de middleware existentes (CORBA, HTTP, CGI, SMTP, RMI).
S Necessidade de conectividade de usurios de vrias plataformas (PCs, Macs, usurios Unix
conectados sobre TCP/IP LAN, redes de pacotes ou linhas dial-up).
S Interoperabilidade e interface com outros sistemas.
S Backup/recuperao necessrias e manuseio de desastres.
S Restries (padres organizacionais e polticos a serem seguidos, controle de aplicao e
restries de auditoria).
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
176
7. Esconda os detalhes irrelevantes da arquitetura para reduzir a complexidade e exponha os detalhes
necessrios para obter controle.
8. Inicie a definio da arquitetura do sistema assumindo que todos os componentes so fisicamente ou
logicamente remotos uns dos outros.
9. Projete a arquitetura para que ela tolere todos os tipos de falhas, incluindo falhas parciais em um ou outro
componente.
10. Componentes arquiteturais devem ser eficientes em sistemas pequenos e suficientemente funcionais em
grandes sistemas.
11. No distribua demais (overdistribute). Se dois processos interagem freqentemente, ento ponha-os na
mesma mquina.

Padres de Projeto
Pagina Servidora
S Nome: Pagina Servidora
S Objetivo: Representar as pginas de informaes que acionam funes de componentes de
software residentes no servidor. Estas pginas se comunicaro a estes componentes de software
atravs de servlets.
S Motivao:
1. Separao da representao das pginas de informao dos componentes de software.
2. Separao da representao dos tipos de pginas de informao: pginas que somente
apresentam informaes e pginas que acionam funes de componentes de software.
3. Representao de pginas de informao que apresentam algum processamento associado.
S Estrutura:
NomeClasseControle
attributes
operations()
Servl etNomeServl et
attributes
operations()
<<Servlet>>
PNomePaginaHTML2
<<Pagina HTML>>
PSNomePagi naServi dora2
attributes
operations()
<<Pagina Servidora>>
PSNomePagi naServi dora1
attritutes
operations()
<<Pagina Servidora>>
*
*
<<redi rect>>
*
*
<<bui l d>>
*
*
*
*

1. Uma Pagina Servidora pode estar ligada unicamente a outra Pagina Servidora ou a uma
pgina que apresente informaes, aqui representada pelo padro Pagina HTML.
2. Os atributos de uma Pagina Servidora representam as informaes que a mesma deve
apresentar. Exemplo: Supondo que a PNomePaginaServidora1 fosse uma pgina para a
realizao de compras de cds; nome do cd, quantidade e local de entrega seriam possveis
atributos para esta pgina.
3. As funes de uma Pagina HTML representam todas as operaes que eventualmente podem
ser acionadas atravs da mesma, inclusive ligaes (links) com outras pginas. Exemplo:
Supondo que a PNomePaginaServidora1 fosse a pgina para a realizao de compras de cds;
calcular preo do transporte e confirmar compra seriam possveis operaes para esta pgina.
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
177
S Colaboraes: Uma Pagina Servidora delega responsabilidades para uma Classe de Controle
(componente de software da aplicao) atravs de um Servlet. Toda Pagina Servidora pode se
ligar a vrias outras Paginas Servidoras ou a pginas de informao que somente apresentam
informaes.
S Aplicabilidade e Conseqncias:
1. Use o padro quando voc quiser representar pginas que apresentam processamento
associado no servidor, suas informaes e suas ligaes.
2. Facilita a legibilidade dos diagramas que descrevem a estrutura da aplicao, identificando a
ligao entre as pginas de informao e os componentes de software.
3. Identifica classes que faro parte do modelo de navegao.

Recomendaes para o Desenvolvimento de Sistemas baseados na Web
1. Use o princpio KISS (Keep it Simple Sir):
S Se possvel inicie com um nico fornecedor de middleware
S Limite o mix-and-matching
S No distribua demais sua aplicao.
2. A diviso de uma grande aplicao em componentes, subsistemas e mdulos no uma tarefa fcil. Ainda
mais quando cada pedao reside em um computador em separado. Desta forma, muitas configuraes de
aplicaes e opes de interconectividade no so cuidadosamente avaliadas.
3. Uma tendncia das aplicaes atuais a separao entre regras de negcio, apresentao (interface do
usurio) e gerenciamento dos dados da aplicao. Esta separao de preocupaes leva a uma arquitetura
de aplicao em trs camadas bastante apropriada para sistemas baseados na Web, pois promove a noo
de interoperabilidade, reuso e gerenciamento das aplicaes em ambiente distribudo.

Checkpoints: Arquitetura de Software baseado na Web
Geral
S As Guidelines de Projeto para a Web foram seguidas?
S Os componentes a serem reusados foram totalmente encontrados?
S Os componentes e sua distribuio nas diversas camadas foram representados em um diagrama de
componentes?
S Todos os detalhes da arquitetura do sistema (infraestrutura) foram representados no diagrama de
implantao?
S As fontes de dados e sua distribuio fsica atravs dos ns foram representadas no diagrama de
implantao?
S Os componentes de aplicao e as pginas de informao foram determinados?
S O processamento foi distribudo corretamente (entre clientes, servidores de dados, servidor Web,
servidores de aplicao, etc.) de forma a no haver sobrecarga de processamento?
S A arquitetura est adequada quanto ao desempenho e a confiabilidade?
S As interfaces com sistemas legados e outros sistemas na Web so realmente necessrias?
S Os detalhes irrelevantes da arquitetura foram escondidos para diminuir a complexidade?
S Os componentes arquiteturais so eficientes sobre carga pequena e funcionais sobre uma carga
alta de processamento?
S O sistema no foi distribudo demais?
Segurana
S Mecanismos de autenticao e autorizao foram projetados?
S A aplicao est segura do ponto de vista da rede? Voc projetou os firewalls e os servidores
proxy necessrios?
Apndice C Framework de Anlise e Projeto para Aplicaes Baseadas na Web
178
Checkpoints: Anlise Arquitetural

Para Sistemas baseados na Web:
S As abstraes chaves (classes de anlise) foram identificadas corretamente com o mecanismo de
anlise HTML?
S As abstraes chaves (classes de anlise) modelam corretamente e suficientemente o domnio do
problema da aplicao para a Web em desenvolvimento?
S O Artefato: Guidelines de projeto para a Web est sendo atualizado corretamente?
S Os conceitos de "Definio de Camadas" e "Padres de Distribuio" foram observados durante a
estruturao inicial da aplicao?
S A estrutura inicial do Web site foi levantada corretamente?

Conceito: Princpios para o Reuso de Componentes
Em experincias relatadas por muitas empresas com o reuso foi encontrado um nmero de princpios
que so comuns maioria delas. Para que o reuso sistemtico de software seja alcanado deve-se ter em mente
este conjunto de princpios:
1. Planeje e adapte a arquitetura do sistema, o processo de desenvolvimento e a organizao para as
necessidades de reuso em uma viso sistemtica mais incremental. Inicie com projetos pilotos e
ento, aumente a escala.
2. Planeje para iniciar o reuso com a arquitetura e um processo incremental de definio
arquitetural.
3. Crie e desenvolva componentes reusveis em um ambiente de trabalho real.
4. Gerencie sistemas de aplicao e componentes reusveis como um portflio de produto de valor
financeiro, focando o reuso sobre componentes comuns em domnios de subsistema.
5. Idealize que um objeto ou componente tecnolgico isolado no suficiente.
6. Invista na incrementao continua da infra-estrutura, educao de reuso e experincia.
7. Mea o progresso do reuso com mtricas, e otimize o programa de reuso.