Você está na página 1de 192

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA

FACULDADE DE CINCIAS APLICADAS DE MINAS

Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000


BACHARELADO EM SISTEMAS DE INFORMAO

SISTEMA DE GESTO PARA HOTELARIA:


PORTO BELLO PALACE HOTEL
GUSTAVO ESTEVES BORGES
HERLANDRO PINTO DA SILVA HERMOGENES
LUCAS FREDERICO CMARA
LUCAS MORENO MAGALHES LELES
RUAN RAMON COSTA

Uberlndia
2009

GUSTAVO ESTEVES BORGES


HERLANDRO PINTO DA SILVA HERMOGENES
LUCAS FREDERICO CMARA
LUCAS MORENO MAGALHES LELES
RUAN RAMON COSTA

SISTEMA DE GESTO PARA HOTELARIA:


PORTO BELLO PALACE HOTEL

Trabalho

de

Concluso

de

curso

submetido UNIMINAS como parte dos


requisitos para a obteno do grau de
Bacharel em Sistemas de Informao.
.
Orientador: Prof. Esp. Walteno Martins
Parreira Jnior

Uberlndia
2009

GUSTAVO ESTEVES BORGES


HERLANDRO PINTO DA SILVA HERMOGENES
LUCAS FREDERICO CMARA
LUCAS MORENO MAGLHES LELES
RUAN RAMON COSTA

SISTEMA DE GESTO PARA HOTELARIA:


PORTO BELLO PALACE HOTEL

Trabalho de Concluso de curso


submetido UNIMINAS como parte dos
requisitos para a obteno do grau de
Bacharel em Sistemas de Informao.
Orientador: Prof. Dr. Walteno Martins

Banca Examinadora:
Uberlndia, 21 de dezembro de 2009.
Prof. Esp. Walteno Martins Parreira Jr (Orientador)
Profa. Dra. Ktia Lopes Silva
Prof. Dr. Mauro Hemerly Gazzani
Uberlndia

2009

Dedico este trabalho aos meus familiares, que acreditaram em mim,


minha namorada, que amo muito, pela presena e apoio e a todos os
meus amigos que sempre estiveram ao meu lado.

AGRADECIMENTOS

A Prof Walteno Martins brao amigo de todas as etapas deste trabalho.


As famlias, pela confiana e motivao, pacincia, compreenso e amor.
Agradeo a Deus por ter guiado nossos passos e nos protegido nos momentos
difceis.

RESUMO

Este trabalho tem como objetivo implementar um aplicativo para gesto de hotelaria
utilizando uma arquitetura em trs camadas e os padres de projeto (design
patterns), facilitando o controle das operaes bsicas de um hotel (hospedagem e
reservas). A utilizao de um design adequado, com as opes bem distribudas e
prticas para uso dirio, atravs de uma interface simples, possibilitam a
automatizao de todo o servio de gerenciamento, atendendo as necessidades do
cliente e permitindo que os usurios tenham acesso s informaes e sejam mais
produtivos no trabalho. A aplicao foi construda com a linguagem de programao
Java utilizando as tecnologias JavaServerPages, Servlets, e TagLibrary, tornando o
sistema eficiente, eficaz e ao mesmo tempo de fcil utilizao. Como a aplicao
baseada na Web, possibilitar uma melhor utilizao de recursos fsicos (Hardware)
e de sistema. Foram utilizados os padres da Sun Front Controller, Application
Controller, Context Object que nessa fase final do projeto foram unificados pelo
Struts, e para a camada de persistncia o padro DAO foi utilizado. Na visualizao
foram utilizadas CSS, JavaScript, Tableless, Display Tag Library, Struts Tiles e a
chamada Uma expresso regular.Para a persistncia dos dados foi utilizado o
banco de dados MySQL a ferramenta de Mapeamento Objeto-Relacional utilizada foi
o Hibernate.
Palavras Chave: Aplicao Web, Hotelaria on-line, Gerenciamento, Java.

ABSTRACT

This paper aims to implement an application for hotel management, using a three-tier
architecture and design patterns (design patterns), facilitating control of the basic
operations of a hotel (lodging and reservations). The use of an appropriate design,
with options well distributed and practices for everyday wear, through a simple
interface, allow for the automation of the management service, meeting the needs of
the customer and allowing users to have access to information and be more
productive at work. The application was built with the Java programming language
using the technologies JavaServerPages, Servlets, and TagLibrary, making the
system efficient, effective and yet easy to use. Because the application is Webbased, will enable a better use of physical resources (hardware) and system. We
used the standard Sun Front Controller, Application Controller, Context Object that
this final phase of the project were unified by Struts, and the persistence layer the
DAO pattern was used. On display were used CSS, JavaScript, Tableless, Display
Tag Library, Struts and Tiles called "A regular expression." For the persistent data
was used MySQL database tool for Object-Relational Mapping Hibernate was used.

Keywords: Web Application, Hospitality Online, Management, Java.

LISTA DE FIGURAS

FIGURA 1 DIAGRAMA DE CASOS DE USO ................................................................................... 43


FIGURA 2 REPRESENTAO GRFICA DE RELAES ENTRE CLASSES............................. 60
FIGURA 3 DIAGRAMA DE CLASSE DE ANLISE ......................................................................... 61
FIGURA 4 DIAGRAMA DE SEQNCIA CADASTRAR FUNCIONRIO....................................... 63
FIGURA 5 DIAGRAMA DE SEQNCIA CADASTRAR HSPEDE............................................... 64
FIGURA 6 DIAGRAMA DE SEQNCIA CADASTRAR APARTAMENTO .................................... 65
FIGURA 7 DIAGRAMA DE SEQNCIA MANTER FUNCIONRIO .............................................. 66
FIGURA 8 DIAGRAMA DE SEQNCIA MANTER HSPEDE ...................................................... 67
FIGURA 9 DIAGRAMA DE SEQNCIA MANTER APARTAMENTO............................................ 68
FIGURA 10 DIAGRAMA DE SEQNCIA REGISTRAR RESERVA .............................................. 69
FIGURA 11 DIAGRAMA DE SEQNCIA CONSULTAR RESERVA ............................................. 71
FIGURA 12 DIAGRAMA DE SEQNCIA REGISTRAR ENTRADA POR RESERVA................... 71
FIGURA 13 DIAGRAMA DE SEQNCIA MANTER REGISTRAR ENTRADA.............................. 72
FIGURA 14 DIAGRAMA DE SEQNCIA REGISTRAR SADA..................................................... 73
FIGURA 15 DIAGRAMA DE SEQNCIA GERAR MAPA DE ACOMODAES ......................... 74
FIGURA 16 DIAGRAMA DE SEQNCIA EFETUARLOGIN.......................................................... 75
FIGURA 17 CLASSES DE FRONTEIRA .......................................................................................... 76
FIGURA 18 DIAGRAMA DE PACOTES ........................................................................................... 80
FIGURA 19 DIAGRAMA DE CLASSES ATUALIZAR APARTAMENTO......................................... 81
FIGURA 20 DIAGRAMA DE CLASSES BUSCAR APARTAMENTO .............................................. 82
FIGURA 21 DIAGRAMA DE CLASSES CADASTRAR APARTAMENTO........................................ 83
FIGURA 22 DIAGRAMA DE CLASSES CADASTAR RESERVA/HOSPEDAGEM......................... 84
FIGURA 23 DIAGRAMA DE CLASSES ATUALIZAR HOSPEDE ................................................... 85
FIGURA 24 DIAGRAMA DE CLASSES BUSCAR FUNCIONRIO................................................. 86
FIGURA 25 DIAGRAMA DE CLASSES BUSCAR HSPEDE ........................................................ 87
FIGURA 26 DIAGRAMA DE CLASSES CADASTRAR FUNCIONRIO ......................................... 88
FIGURA 27 DIAGRAMA DE CLASSES CADASTRAR HSPEDE ................................................. 89

FIGURA 28 DIAGRAMA DE CLASSES EXCLUIR FUNCIONRIO ................................................ 90


FIGURA 29 DIAGRAMA DE CLASSES EXCLUIR HSPEDE ........................................................ 91
FIGURA 30 DIAGRAMA DE CLASSES CONSULTAR RESERVA HOSPEDAGEM ...................... 92
FIGURA 31 DIAGRAMA DE CLASSES EXCLUIR APARTAMENTO.............................................. 93
FIGURA 32 JAVA EE DIAGRAMA DA ARQUITETURA............................................................... 97
FIGURA 33 DIAGRAMA SEM NENHUMA SEPARAO LGICA ................................................ 98
FIGURA 34 COMPONENTES AGRUPADOS................................................................................... 99
FIGURA 35 COMO O STRUTS IMPLEMENTA O MVC ................................................................. 101
FIGURA 36 FLUXO STRUTS .......................................................................................................... 105
FIGURA 37 DIAGRAMA DO FLUXO DO HIBERNATE.................................................................. 107
FIGURA 38 SEM PADRES X COM PADRES. .......................................................................... 121
FIGURA 39 ESTILO DE INTERAO POR LINGUAGEM DE COMANDO .................................. 122
FIGURA 40 INTERAO USURIOSISTEMA. ........................................................................... 131
FIGURA 41 DESIGN DE MENU VERTICAL ................................................................................... 135
FIGURA 42 BARRA DE ROLAGEM EM FORMA DE FLEHA OU REMO ..................................... 136
FIGURA 43 BARRA DE ROLAGEM DISCRETA............................................................................ 137
FIGURA 44 EXEMPLO DE BREADCRUMB................................................................................... 139
FIGURA 45 EXEMPLO INPUT ANTES DO CAMPO ...................................................................... 141
FIGURA 46 DROPDOWNLIST" COMO FERRAMENTA PARA NAVEGAO ...................... 145
FIGURA 47 LAYOUT DE FORMULRIO ....................................................................................... 145
FIGURA 48 EXEMPLOS DE CONES............................................................................................. 146
FIGURA 49 CONE DE MULTIMEDIA ............................................................................................ 146
FIGURA 50 RESOLUES DE TELA UTILIZADAS EM NOVEMBRO DE 2007 ......................... 149
FIGURA 51 RESOLUES DE TELA UTILIZADAS EM NOVEMBRO DE 2008 ......................... 149
FIGURA 52 RESOLUES DE TELA UTILIZADAS EM NOVEMBRO DE 2009 ......................... 149
FIGURA 53 SITE W3C VISUALIZADO NA RESOLUO 1024X768 ........................................... 150
FIGURA 54 SITE W3C VISUALIZADO NA RESOLUO 1280X800 ........................................... 150
FIGURA 55 SITE W3C VISUALIZADO NA RESOLUO 800X600 ............................................. 151
FIGURA 56 RECOMENDAO PARA POSICIONAMENTO DE ELEMENTOS........................... 154
FIGURA 57 SITE ZEN GARDEN TEMA TRANQUILLE ............................................................... 156

FIGURA 58 SITE ZEN GARDEN TEMA CSS CO., LTDA............................................................ 156


FIGURA 59 SITE ZEN GARDEN TEMA UNDER THE SEA........................................................ 156
FIGURA 60 SITE ZEN GARDEN TEMA RETRO THEATER....................................................... 157
FIGURA 61 SITE ZEN GARDEN TEMA WIGGLES THE WONDERWORM............................... 157
FIGURA 62 SITE W3C VISUALIZADO NA RESOLUO 800X600 ............................................. 158
FIGURA 63 SINTAXE CSS.............................................................................................................. 159
FIGURA 64 TABELAS GERADAS PELO DISPLAYTAG .............................................................. 167
FIGURA 65 TELA DE LOGIN.......................................................................................................... 171
FIGURA 66 TELA DE HOME .......................................................................................................... 172
FIGURA 67 DIAGRAMA DE NAVEGAO DO SISTEMA............................................................ 175
FIGURA 68 TELA DE CADASTRO DE HSPEDE ........................................................................ 176
FIGURA 69 TELA DE EXPORTAO DE DADOS PARA PLANILHA EXCEL............................ 176
FIGURA 70 DER .............................................................................................................................. 182

LISTA DE QUADROS

Quadro 1 Documento de Requisito Cadastrar Funcionrio ...................................................... 28


Quadro 2 Documento de Requisito Cadastrar Hspede........................................................... 29
Quadro 3 Documento de Requisito Cadastrar Apartamentos................................................... 30
Quadro 4 Documento de Requisito Alterar Funcionrio............................................................ 30
Quadro 5 Documento de Requisito Alterar Hspede ................................................................ 31
Quadro 6 Documento de Requisito Cadastrar Apartamentos................................................... 32
Quadro 7 Documento de Requisito Registrar Reserva ............................................................. 33
Quadro 8 Documento de Requisito Consultar Reserva ............................................................ 34
Quadro 9 Documento de Requisito Registrar Entrada por Reserva ......................................... 34
Quadro 10 Documento de Requisito Registrar Entrada............................................................ 35
Quadro 11 Documento de Requisito Registrar Sada ............................................................... 36
Quadro 12 Documento de Requisito Gerar Mapa de Acomodaes........................................ 36
Quadro 13 Aspectos de identificao dos Casos de Uso ......................................................... 41
Quadro 14 Regra de Negcio.................................................................................................... 45
Quadro 15 Detalhe do caso de uso CSU01 ............................................................................ 46
Quadro 16 Detalhe do caso de uso CSU02 ............................................................................ 47
Quadro 17 Detalhe do caso de uso CSU03 ............................................................................ 48
Quadro 18 Detalhe do caso de uso CSU04 ............................................................................ 49
Quadro 19 Detalhe do caso de uso CSU05 ............................................................................ 50
Quadro 20 Detalhe do caso de uso CSU06 ............................................................................ 51
Quadro 21 Detalhe do caso de uso CSU07 ............................................................................ 53
Quadro 22 Detalhe do caso de uso CSU08 ............................................................................ 53
Quadro 23 Detalhe do caso de uso CSU09 ............................................................................ 54
Quadro 24 Detalhe do caso de uso CSU10 ............................................................................ 56
Quadro 25 Detalhe do caso de uso CSU11 ............................................................................ 57
Quadro 26 Detalhe do caso de uso CSU12 ............................................................................ 58
Quadro 27 Arquivo web.xml .................................................................................................... 102
Quadro 28 Ao para adicionar apartamento ......................................................................... 104
Quadro 29 Mtodo execute para a ao de cadastrar apartamento ...................................... 104
Quadro 30 Classe DAO ApartamentoDAO.java...................................................................... 110
Quadro 31 Abre sesso com o banco de dados ..................................................................... 111
Quadro 32 Salva determinado objeto no banco...................................................................... 111
Quadro 33 Remove determinado objeto do banco ................................................................. 111
Quadro 34 Salva ou atualiza determinado objeto no banco de dados ................................... 111
Quadro 35 Apenas atualiza determinado objeto no banco de dados ..................................... 111
Quadro 36 Retorna vrios objetos do banco numa lista ......................................................... 112
Quadro 37 Arquivo de configuraes hibernate.cfg.xml ......................................................... 112
Quadro 38 Tag recado............................................................................................................. 124
Quadro 40 Cdigo de text input............................................................................................... 141
Quadro 41 Texto aps o input text .......................................................................................... 141
Quadro 42 Codigo de input checkbox ..................................................................................... 142
Quadro 43 Representao da posio do input checkbox a esquerda do label..................... 142
Quadro 44 Representao da posio do input checkbox a direita do label .......................... 142
Quadro 45 Layout para elementos de formulrio CHI Boas tcnicas .................................. 143
Quadro 46 Cdigo de formulrio com dependncia de script no lado do usurio .................. 144
Quadro 47 Cdigo de formulrio sem dependncia de script no lado do usurio .................. 144
Quadro 48 Tipos de cones ..................................................................................................... 147
Quadro 49 Valor real aproximado. FONTE: adaptada de MCCLURG (2006). ....................... 152
Quadro 50 Posicionamento de elementos de interface. FONTE: adaptada de
AVELAREDUARTE (2009). ........................................................................................................ 154
Quadro 51 Cdigo CSS ........................................................................................................... 160
Quadro 52 Cdigo CSS mais legvel....................................................................................... 160
Quadro 53 Cdigo de comentrio CSS ................................................................................... 160
Quadro 54 Cdigo de seletor id em CSS ................................................................................ 161
Quadro 55 Cdigo CSS de seletor classe............................................................................... 161
Quadro 56 Cdigo CSS de seletor classe para tag p ............................................................. 162

Quadro 57 Link Html para CSS externa .................................................................................. 162


Quadro 58 Exemplo de folha de estilo .................................................................................... 163
Quadro 59 Exemplo de cdigo CSS interno............................................................................ 163
Quadro 60 Exemplo de cdigo CSS inline .............................................................................. 164
Quadro 61 Exemplo de cdigo CSS externo .......................................................................... 164
Quadro 62 Exemplo de cdigo CSS interno............................................................................ 164
Quadro 63 Cinco tags fundamentais da tags do DisplayTag .................................................. 167
Quadro 64 Cdigo do arquivo header.jsp................................................................................ 173
Quadro 65 Cdigo do arquivo menu.jsp.................................................................................. 173
Quadro 66 Cdigo do arquivo footer.jsp.................................................................................. 173
Quadro 67 Cdigo do arquivo layout.jsp ................................................................................. 174
Quadro 68 Arquivo de Configurao hibernate.cfg.xml .......................................................... 185
Quadro 69 hbm.xml ................................................................................................................. 186

LISTA DE ABREVIATURAS E SMBOLOS

ABNT Associao Brasileira de Normas Tcnicas


API Application Programming Interface
ARPA Agncia de Projetos de Pesquisa Avanada
CERN Organizao Europeia para Investigao Nuclear
CHI Computer-Human Interaction (Interao Computador-Humano)
CPF Cadastro de Pessoa Fsica
CS4 Creative Suite 4
CSS Cascading Style Sheets
CTPS Carteira de Trabalho e Previdncia
DAO Data Access Object
FK Foreign key
GoF Gang of Four
HQL Hibernate Query Language
HTML Hyper Text MarkUp Language
HTTP Hipertext Transfer Protocol
IDE Integrated Development Environment
ISO International Standartization Organization
ITCP Internet Transmission Control Program (Programa de Controle de
Transmisso Entreredes)
Java EE Java Enterprise Edition
Java SE Java Standart Edition
JSP Java Server Pages
MVC Model-View-Controller
NCSA Centro Nacional de Aplicaes de Supercomputao

OO Orientado a Objeto
OOP Object Oriented Programmimg
PK Primary Key
POO Programao Orientada a Objetos
RAM Random Access Memory
RG Registro Geral
SGBD Sistema de Gerenciamento de Banco de Dados
SGPB Sistema de Gerenciamento Porto Bello
SQL Structured Query Language
W3C World Wide Web Consortium
WaSP Projeto de Padres Web ou Web Standards Project
WYSIWYG What You See Is What You Get (O que voc v o que voc tem)
XHTML Extensible Hyper Text MarkUp Language
XML Extensible Markup Language (Linguagem extensvel de formatao)

SUMRIO

INTRODUO ............................................................................................................................. 18
1.1
CENRIO ATUAL ..................................................................................................................... 18
1.2
IDENTIFICAO DO PROBLEMA................................................................................................. 19
1.3
OBJETIVOS DO TRABALHO ....................................................................................................... 20
1.3.1 Objetivo Geral.................................................................................................................. 20
1.3.2 Objetivos Especficos ...................................................................................................... 20
1.4
JUSTIFICATIVA PARA A PESQUISA ............................................................................................. 21
1.5
ORGANIZAO DO TRABALHO ................................................................................................. 21

ESPECIFICAO DO PROBLEMA ............................................................................................ 23


2.1
INTRODUO.......................................................................................................................... 23
2.2
LEVANTAMENTO DE REQUISITOS ............................................................................................. 24
2.2.1 Especificao dos Requisitos.......................................................................................... 26
2.3
DOCUMENTAO DE REQUISITOS ............................................................................................ 26

ANLISE E PROJETO ................................................................................................................ 37


3.1
INTRODUO.......................................................................................................................... 37
3.1.1 Engenharia de Software .................................................................................................. 37
3.1.2 A Linguagem UML ........................................................................................................... 38
3.2
DIAGRAMA DE CASOS DE USO................................................................................................. 40
3.2.1 Descrio dos Atores....................................................................................................... 41
3.3
DETALHAMENTO DOS CASOS DE USO ...................................................................................... 44
3.4
DIAGRAMA DE CLASSE DE ANALISE ......................................................................................... 58
3.5
DIAGRAMA DE SEQNCIA .............................................................................................. 62
3.6
CLASSES DE ANLISE ............................................................................................................. 75
3.6.1 Classes de Fronteira........................................................................................................ 75
3.6.2 Classes de Entidade........................................................................................................ 76
3.6.3 Classes de Controle ........................................................................................................ 78
3.6.4 Diagrama de Classe de Projeto....................................................................................... 78

ESTRUTURA E CDIGO............................................................................................................. 94
4.1
4.2
4.3
4.4
4.5

ARQUITETURA ........................................................................................................................ 94
JAVA EE JAVA ENTERPRISE EDITION .................................................................................. 95
CAMADAS E MVC................................................................................................................... 97
STRUTS............................................................................................................................... 99
HIBERNATE....................................................................................................................... 105

PROJETO DE INTERFACES .................................................................................................... 114


5.1
REGRA DO CLICK ................................................................................................................. 114
5.2
TODA HISTRIA TEM UM COMEO .......................................................................................... 115
5.2.1 O nascimento da Internet .............................................................................................. 115
5.2.2 A criao da World Wide Web....................................................................................... 116
5.2.3 A Guerra dos Browsers ............................................................................................... 117
5.2.4 A web sem padres ....................................................................................................... 118
5.2.5 A formao da W3C ...................................................................................................... 119
5.2.6 A formao da WaSP .................................................................................................... 119
5.2.7 Web Standard................................................................................................................ 120
5.3
COMPONENTE: ESTRUTURA .................................................................................................. 122
5.3.1 HTML ............................................................................................................................. 123
5.3.2 XML................................................................................................................................ 123
5.3.3 XHTML........................................................................................................................... 124
5.3.4 JSP ................................................................................................................................ 125
5.3.4.1. Diretivas JSP ............................................................................................................. 126
5.3.4.2. Elementos Scripts JSP.............................................................................................. 126
5.3.4.3. Tag Libraries ............................................................................................................. 127

5.3.4.4. Tag Padro................................................................................................................ 127


5.3.4.5. Tags Personalizadas................................................................................................. 128
5.3.4.6. Evoluo da estrutura de pgina web com JSP ....................................................... 128
5.3.5 Ferramentas .................................................................................................................. 129
5.3.5.1. Adobe Dreamweaver................................................................................................. 129
5.3.5.2. Eclipse ....................................................................................................................... 129
5.4
COMPONENTE: APRESENTAO ............................................................................................ 130
5.4.1 Interface ......................................................................................................................... 130
5.4.1.1. Componentes de interface web ................................................................................ 133
5.4.1.1.1.
Barras de navegao ou menus ........................................................................... 133
5.4.1.1.2.
Barras de rolagem ................................................................................................ 135
5.4.1.1.3.
Breadcrumbs......................................................................................................... 138
5.4.1.1.4.
Formulrios ........................................................................................................... 139
5.4.1.1.5.
Formulrios HTML/XHTML ................................................................................... 139
5.4.1.1.6.
cones.................................................................................................................... 146
5.4.1.1.7.
Ttulo da pgina .................................................................................................... 147
5.4.1.2. Resoluo do monitor e tamanho do website ........................................................... 148
5.4.1.3. Layout lquido ............................................................................................................ 149
5.4.1.4. Espao do browser na tela........................................................................................ 152
5.4.1.5. Localizao dos elementos na tela ........................................................................... 153
5.4.1.6. Navegao do sistema.............................................................................................. 154
5.4.1.7. Layout........................................................................................................................ 155
5.4.2 Tecnologias ................................................................................................................... 157
5.4.2.1. CSS ........................................................................................................................... 157
5.4.2.1.1.
CSS resolve um grande problema........................................................................ 158
5.4.2.2. Espao do browser na tela........................................................................................ 159
5.4.2.2.1.
Sintaxe CSS.......................................................................................................... 159
5.4.2.2.2.
Comentrios CSS ................................................................................................. 160
5.4.2.2.3.
Os seletores de id e class..................................................................................... 160
a)
O seletor id......................................................................................................................... 161
b)
A classe Selector ............................................................................................................... 161
5.4.2.2.4.
Como inserir CSS ................................................................................................. 162
a)
CSS Externa ...................................................................................................................... 162
b)
CSS Interna........................................................................................................................ 163
c)
CSS Inline .......................................................................................................................... 163
d)
CSS Mltiplos..................................................................................................................... 164
5.4.2.3. DisplayTag ................................................................................................................ 165
5.4.2.3.1.
Recursos disponveis ............................................................................................ 165
5.4.2.3.2.
As cinco tags fundamentais .................................................................................. 166
5.4.3 Ferramentas .................................................................................................................. 167
5.4.3.1. Corel Draw ................................................................................................................ 167
5.4.3.2. Adobe Photoshop...................................................................................................... 168
5.5
Componente: Comportamento ...................................................................................... 168
5.5.1 ECMAScript ou JavaScript ............................................................................................ 169
5.5.2 Apache Tiles .................................................................................................................. 169
5.6
CASE PORTO BELLO............................................................................................................. 170
5.7
NAVEGAO DO SITE PORTO BELLO ...................................................................................... 175
6

PERSISTNCIA DE DADOS ..................................................................................................... 178


6.1
INTRODUO........................................................................................................................ 178
6.2
SISTEMA DE GERENCIAMENTO PORTO BELLO ........................................................................ 179
6.3
SGBD SISTEMA DE GERENCIAMENTO DE BANCOS DE DADOS.............................................. 179
6.4
ARQUITETURA DO BANCO DE DADOS ..................................................................................... 180
6.5
MODELADOR DE DADOS CA ERWIN ....................................................................................... 181
6.6
DIAGRAMA DE ENTIDADES E RELACIONAMENTOS (DER) ........................................................ 181
6.7
TABELAS .............................................................................................................................. 183
6.8
HIBERNATE .......................................................................................................................... 184
6.8.1 Arquivo hibernate.cfg.xml .............................................................................................. 185

CONCLUSES .......................................................................................................................... 187

REFERNCIAS .......................................................................................................................... 189

1.1

INTRODUO

Cenrio atual

A indstria hoteleira entre diversas constituies empresariais permanece em


constante renovao, na hotelaria novos tipos e meios de hospedagem surgem
conforme o desenvolvimento scio-econmico. Desta forma causa-se no mercado
uma busca incessante por novos conceitos, que no mnimo acompanhe as
inovaes do mundo globalizado e que em grande maioria espera-se que supere as
expectativas de uma demanda de clientes cada vez mais exigente. O ramo hoteleiro
no Brasil possui hoje em torno de 25 mil meios de hospedagem, e desta totalizao
20 mil so hotis e pousadas.
No geral, 70% so empreendimentos de pequeno porte o que representa
mais de um milho de empregos e a oferta de quase um milho de apartamentos em
todo o pas.
Sabe-se que de cada 10 empregos da populao economicamente ativa
brasileira um de turismo, o que demonstra um nmero expressivo e razovel em
comparao aos outros segmentos de fora e representatividade nacional. No setor
hoteleiro anualmente h um crescimento que varia de 8 a 10% que dependendo de
regio para regio sofrendo oscilaes para mais ou para menos. O turismo de
negcios forte em todo o Brasil e at internacionalmente tendo um crescimento
com nveis superiores a 10%, aproximando em at 15% ao ano. No Brasil, pas
considerado continental, a variao de crescimento torna-se bem mais perceptvel
sobre o turismo de uma forma geral que possui uma mdia de 3 a 4 dias.
Com este cenrio percebe-se que a hotelaria brasileira fortemente
dependente das contas corporativas, e como tal se encaixam o turismo de negcios,
eventos e incentivos. No cenrio atual h a necessidade de excelncia em sistemas
de informao que apiem a gesto, automatizando rotinas, padronizando atividades
e armazenando informaes tornando ferramentas importantes no processo de
gerenciamento de reservas e hospedagens de uma rede hoteleira.
Existem no mercado vrios softwares voltados para o ramo de hotelaria.
18

Fazer uso de sistemas padronizados ou adquirir softwares customizados uma


deciso importante. As duas possibilidades possuem vantagens e desvantagens.

1.2

Identificao do problema

O Porto Bello Palace Hotel um estabelecimento do ramo de servios voltado


para acomodao de hspedes e outros servios. Oferece apartamentos amplos e
arejados, equipados com TV a cabo, ar refrigerado, frigobar e room service 24h, com
quartos nas categorias simples, duplo e triplo. Possui o Centro de Convenes com
10 salas e sales, totalmente preparado para a realizao de feiras, congressos,
convenes e espao para montagem de stands, alm de salas de apoio e
secretaria e toda infra-estrutura para workshops, reunies, cursos, treinamentos e
conferncias. Est localizado na Avenida Joo Naves de vila, nmero 3685, Bairro
Santa Mnica, Uberlndia-MG. A demanda de hspedes constante e mais
pessoas esto providenciando suas reservas. Assim, o fluxo de clientes se
estabelece em constante movimento, aumentando o fluxo de acomodaes e de
recursos humanos. Devido a isso, a organizao busca sempre oferecer um servio
de qualidade, alm de tradio e conforto em suas acomodaes para proporcionar
maior satisfao e permanncia de seus hspedes.
A implantao de um sistema de informao que gerencie o fluxo de clientes,
de acomodaes e de funcionrios do hotel se fez necessria por proporcionar aos
usurios uma ferramenta de maior controle das operaes de entrada e sada de
hspedes, da ocupao dos apartamentos, do movimento de funcionrios do hotel,
entre outros aspectos. Com este melhor gerenciamento, os gestores da organizao
podero realizar relatrios, balanos e previses futuras das temporadas de
ocupao do hotel.

19

1.3

Objetivos do trabalho

1.3.1 Objetivo Geral


Desenvolver uma ferramenta de gerenciamento que proporcione maior
controle do fluxo de clientes, cadastro das acomodaes e dos funcionrios do Porto
Bello Palace Hotel.

1.3.2 Objetivos Especficos


Para que o objetivo geral seja alcanado, este trabalho apresenta os
seguintes objetivos especficos:
-

Levantar os requisitos do sistema.

Documentar os casos de uso

Fazer a modelagem do sistema, implementando os Diagramas de Classes, de


Seqncias e de Casos de Usos, projetados por meio do Enterprise Architect.

Implementar o aplicativo em trs camadas.

Desenvolver o sistema utilizando a linguagem de programao Java.

Pesquisar ferramentas e tecnologias (Servlets, JavaServer Pages, Html


Forms e Banco de dados MySQL) para atendimento do projeto.

Estudar o negcio do cliente, para uma melhor estruturao da aplicao.

Utilizar Padres de Projeto para as camadas.

Utilizar uma base para armazenamento de dados.

Implementar a camada de apresentao utilizando Front Controller.

Implementar a camada de negcio utilizando Business Object.

Implementar camada de integrao utilizando DAO Data Access Object.

Utilizar o mySQL como SGBD.

Utilizar o framework Hibernate para mapeamento objeto-relacional.

Utilizar framework Struts.

20

1.4

Justificativa para a pesquisa

O cenrio globalizado exige preciso na definio dos paradigmas


corporativos, cada vez mais as organizaes buscam softwares personalizados e
que possam atender s suas necessidades de forma mais objetiva. Os sistemas de
hotelaria j desenvolvidos encontrados no mercado possuem relativamente um
menor custo, porm apresentam funcionalidades que no se encaixam no negocio
das organizaes.
Cada Hotel tem uma viso, uma misso, e suas regras de negcio, e um
software padronizado segue uma diretriz de desenvolvimento focada nas
similaridades comuns entre as organizaes, no identificando os pontos crticos de
cada uma. O cuidado em identificar pontos crticos e o atendimento das preferncias
do cliente um legado que o avano tecnolgico e social proporcionou, e que so
exigidos pelos clientes.
A implantao de um sistema de gerenciamento de hotelaria que ir
proporcionar para o hotel uma reduo considervel do tempo, atravs de
operaes simplificadas, melhorando sua gerncia e oferecendo recursos para
aes de planejamento estratgico da organizao e atendendo as necessidades
especificas da corporao.

1.5

Organizao do Trabalho

Para a construo deste software, dividiu-se o trabalho em:


-

Anlise e Projeto: busca identificar o que o sistema ir fazer, quais sero suas
funcionalidades e como ser feito, de forma a satisfazer o cliente em questo.
Esta a primeira fase de desenvolvimento do software.

Estrutura e Cdigo: como o cdigo ficar organizado e o que ser utilizado


nesta organizao (estruturao).

Interface: trata da construo do layout e visual da ferramenta, auxiliando de


forma clara no desenvolvimento.

Banco de Dados: onde ir conter as informaes dispostas para serem


21

organizadas e depois serem armazenadas.


Para uma melhor compreenso do desenvolvimento deste trabalho
subdividiu-se em captulos organizados da seguinte maneira:
-

Captulo 1: Introduo Este captulo descreve o cenrio atual do Porto Bello


Palace Hotel, faz-se a identificao do problema, apresenta os objetivos do
trabalho, a justificativa para a pesquisa e a organizao do trabalho.

Captulo 2: Anlise e Projeto - Descreve as especificidades bem como o


detalhamento das regras de negcio, implementao dos diagramas de caso
de uso, diagramas de classe de anlise e de projeto, diagramas de seqncia
dentre outros.

Captulo 3: Arquitetura Refere-se arquitetura do projeto, apresentando


todas as tecnologias utilizadas, como os frameworks Struts e Hibernate. Ao
descrever os processos e cdigos, utilizou-se como modelo o cadastro de
apartamentos.

Captulo 4: Interface do sistema - Refere-se s apresentaes das telas bem


como

os

respectivos

cdigos,

descrevendo

todas

as

metodologias,

tecnologias e padres utilizados, alm de detalhar os resultados obtidos pela


interface associados a cada uma delas.
-

Captulo

5:

Persistncia

de

dados

Esse

captulo

demonstra

desenvolvimento do modelo de dados e contm o Diagrama de Entidade e


Relacionamentos e a explicao de cada tabela do diagrama e os conceitos e
tecnologias que foram empregados durante o desenvolvimento do sistema.
-

Captulo 6: Concluses - Apresentao das concluses observadas pelo


grupo no projeto e sugestes para a continuidade de trabalhos futuros.

22

ESPECIFICAO DO PROBLEMA

2.1

Introduo

A rede hoteleira Porto Bello, com vrios empreendimentos no Brasil, buscava


melhorar o nvel de informao sobre seus hspedes, bem como garantir a perfeita
comunicao entre suas unidades. O objetivo era um s, ganhar eficincia e
aprimorar a qualidade do atendimento aos hspedes. Para isso foi proposto o
desenvolvimento de um software de gerenciamento de estadias, que facilitar
atividades comumente desempenhadas pela organizao:
-

Controle de clientes com todas as informaes completas e necessrias para


sua

estadia,

registros

de

funcionrios,

apartamentos,

reservas

hospedagens. Efetuando interaes que contemplam cadastros, alteraes,


remoes e buscas desses dados.
-

Ter um panorama completo de seu Hotel com um nico software.

O sistema deve gerar relatrios para administrao do hotel, alm de


gerenciar as reservas do estabelecimento.

A hospedagem pode ser calculada em dias, o controle de reservas deve ter


uma interface muito simples e prtica, permitindo uma visualizao rpida do
status de ocupao e reserva de cada quarto do estabelecimento, diria ou
mensalmente. Telas bem desenhadas com as opes bem distribudas e
prticas para uso dirio.

Consultas simples e eficazes.

Efetuar reservas com praticidade em uma interface muito intuitiva.

Na tela de Atendimento de Hotis deve-se controlar a chegada e sada do


Hspede fazendo o calculo do valor das dirias automaticamente.

Por se tratar de uma rede de hotis, o sistema dever ser desenvolvido de


maneira que uma futura iterao com outros sistemas seja de fcil implementao.
23

Para atender as especificaes e necessidades do cliente, apresentou-se uma


soluo pratica e simples. A tecnologia permite integrar e controlar todo o
gerenciamento de estadias.
O projeto dever ser desenvolvido na linguagem JAVA e deve ter suporte a
Web, utilizando uma arquitetura (MVC) em trs camadas e os padres de projeto
(design patterns). Esse desenvolvimento possibilitar aos funcionrios centralizar
todas as informaes em um nico servidor, que se destina ao controle de toda
rede.

2.2

Levantamento de Requisitos

Foram efetuadas varias reunies com o cliente para o levantamento das


funcionalidades do novo sistema, foi discutido tambm o grau de importncia e qual
informao relevante para a execuo das atividades desempenhadas pela
organizao. Durante a reunio foram definidos quais processos o sistema dever
executar e como ele dever executar essas funcionalidades que seguem abaixo.
-

Cadastro de funcionrios So necessrias informaes do funcionrio como:


nome, RG, CPF, data de nascimento, endereo, nmero da carteira de trabalho
e telefone. Caso esse funcionrio venha a utilizar o sistema tambm se deve
definir o nvel de acesso a esse funcionrio.

Cadastro de hspedes So requisitadas informaes como nome, RG, CPF,


data de nascimento, endereo, telefone, eao longo do tempo se este hspede
se tornar um cliente freqente tambm fica registrado suas preferncias quanto
a apartamentos.

Cadastro de apartamentos Existem trs tipos de apartamentos diferentes, o


normal (para uma pessoa), o duplo (para duas pessoas) e o triplo (para trs
pessoas), sendo que para cada tipo de apartamento existe um valor diferente da
diria.

Registro de Reservas No registro de reservas sero buscadas todas as


informaes do cliente registradas no seu cadastro alm de informaes como o
apartamento desejado e a data da chegada do hspede e a quantidade prevista

24

de dirias, caso seja uma data longnqua se faz necessrio uma confirmao
antecipada. No existe limite de data a frente para se fazer uma reserva.
-

Check-in Esse processo semelhante ao processo de reserva com a


diferena de que a data de chegada ser igual data atual.

Check-out feita a somatria de todos os gastos com o valor da diria


multiplicada pelo nmero de dias de permanncia e realizado o fechamento
da conta. As informaes dessa hospedagem devero ser salvos em um
histrico do hspede.

Impresso de relatrio O relatrio devera conter a relao de todos os


apartamentos do Hotel, quais esto ocupados, quem esta ocupando esse
apartamento e qual a previso de liberao desse apartamento.

Consulta O sistema deve ter a funcionalidade de fazer consultas. Essas


consultas devem ser sobre quais hspedes esto no hotel. Outro tipo de
consulta ser uma consulta no histrico do sistema, sendo que devera ser
pesquisado o cadastro e/ou o histrico de um determinado hspede.
Para entender as solues de automao de tais requisitos especificados

acima se faz os seguintes questionamentos:


-

Quantas vezes ao dia os hspedes do seu hotel, normalmente impacientes e


apressados, se queixam pela demora no fechamento de suas contas e
realizao do seu check-out?

Quanto dinheiro perdido pelo fechamento errneo de contas?

As reservas em seu hotel podem ser feitas via internet?

O Turista em seu hotel encontra todas as informaes que precisa para uma
boa estada?

O seu hotel aproveita todas as oportunidades de negcio que o turista


representa?

Voc

consegue

acompanhar

taxa

de

ocupao

do

seu

hotel

constantemente?
-

A taxa de ocupao est baixa e voc no sabe o que fazer para melhor-la?

Baixar o preo da diria ser que a resposta? Voc possui alguma


25

estatstica sobre a satisfao dos hspedes sobre os servios e instalaes


do hotel?
Diante dessas necessidades foi desenvolvido um sistema que automatiza
todos esses processos tornandoos mais seguros e rpidos, facilitando o
gerenciamento da informao bem como os processos a ela ligados. No somente
na agilidade de processos, mas tambm a melhoria do servio tambm sero fatores
abordados, j que uma base de conhecimento formada em cada estadia, assim o
hotel pode aprender mais sobre aquele hspede e oferecer um atendimento
personalizado.

2.2.1 Especificao dos Requisitos

Na Especificao dos Requisitos de Software, fundamental descrever


cuidadosamente, quais os requisitos do sistema e como o sistema dever
implementar tais requisitos, alm de descrever objetivamente, como essa
implementao poder ser testada e verificada pelo usurio.
Os requisitos podem ser classificados em:
- Requisitos Funcionais: referem-se aos requisitos que esto relacionados
com a maneira com que o sistema deve operar, onde se especificam as
entradas e sadas do sistema e o relacionamento comportamental entre elas,
assim como a interao com o usurio.
- Requisitos

No Funcionais: so aqueles que no esto especificamente

relacionados com a funcionalidade do sistema. Eles impem restries no


produto a ser desenvolvido e/ou no processo de desenvolvimento do sistema
como tambm especificam restries externas as quais o produto precisa
atender. Eles referem-se a questes como: segurana, confiabilidade,
usabilidade, desempenho, entre outros.

2.3

Documentao de Requisitos

O documento de requisitos a especificao oficial dos requisitos do sistema

26

para clientes, usurios finais e desenvolvedores de software. Formalmente,


podemos definir que o documento de requisitos contm os servios e
funcionalidades que o sistema deve prover, alm de restries e informaes sobre
o domnio da aplicao, bem como restries no processo usado para desenvolver o
sistema.
Alm disso, tal documento pode ser visto como um contrato entre o cliente e o
gerente de projeto, pois valida a conformidade segundo a especificao de
requisitos do cliente para definio do escopo.
Uma vez que os requisitos foram levantados, cabe agora organiz-los em
grupos correlacionados, separando em funcionalidades e agregando a cada uma as
suas determinadas restries.
No projeto desenvolvido, foram identificados os seguintes requisitos
funcionais:
-

Cadastrar Funcionrio;

Cadastrar Hspede;

Cadastrar Apartamento;

Manter Funcionrio;

Manter Hspede;

Manter Apartamento;

Registrar Reserva;

Consultar Reserva;

Registrar entrada por reservas;

Registrar entrada;

Registrar de sada;

Gerar Mapa de Acomodaes.


Os quadros a seguir representam a descrio de tudo que o sistema deve

fazer referente s funcionalidades citadas anteriormente, alm de mostrar as


restries colocadas sobre como o sistema deve realizar a mesma.

27

Nome: F1 Cadastrar funcionrios

Oculto ( ) Evidente ( x )

Descrio: O sistema permite o cadastro (incluso) do funcionrio na empresa


Requisitos NoFuncionais
Nome

Restrio

Categoria

O sistema dever permitir a


insero dos campos do
funcionrio a ser cadastrado
NF1.1
Especifica
como: cargo na empresa, data
Preencher
o
admisso, CPF, RG, nome,
campos;
endereo, data de nascimento, n
da CTPS, telefone e opo de
operador ou no do sistema.
O sistema permitir o
NF1.2 Validar prosseguimento do cadastro
Segurana
CPF;
mediante uma insero de CPF
vlido.
Aps a concluso do cadastro de
NF1.3 Gerar
Especifica
funcionrio o sistema gerar a
matricula;
o
matricula.
NF1.4
O sistema permite armazenar os
Especifica
Armazenar os
dados mediante a concluso do
o
dados.
cadastro.
O sistema permite a insero do
NF1.5 Definir
nvel de acesso do funcionrio
Segurana
nvel de acesso. caso ele for definido como
operador do sistema.
Legenda: O Obrigatrio
D Desejvel
P Permanente

Obrigatoriedade

Permanncia

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

T Transitrio

Quadro 1 Documento de Requisito Cadastrar Funcionrio

No cadastro de um funcionrio todos os campos apresentados devem ser


preenchidos obrigatoriamente, visto que o RH da empresa necessita das
informaes para facilitar o gerenciamento de frias, temporizao de servio, a
comunicao externa, provendo o acompanhamento pessoal. Devese fornecer
tambm um CPF vlido, por se tratar de um instrumento auxiliar na autenticao da
identidade do indivduo.
Aps a identificao do funcionrio fazse necessrio definir o nvel de
acesso no sistema que o mesmo deve possuir, uma vez que, as atribuies de seu
cargo definem as funcionalidades habilitadas ao seu perfil.
Depois

de

concludo

cadastro

do

funcionrio,

sistema

gera

automaticamente uma matrcula, com objetivo de identificar cada usurio do sistema


por ser nica e de fcil memorizao. Os dados devem ser salvos para que o
histrico seja mantido.

28

Oculto ( ) Evidente ( x
)

Nome: F2 Cadastrar Hspede.

Descrio: O sistema permite o cadastro (incluso) do hspede no hotel.


Requisitos NoFuncionais
Nome

NF2.1
Preencher
campos;

NF2.2
Validar CPF.

NF2.3
Registrar
preferncias.

Restrio

O sistema dever permitir a


insero dos dados pessoais do
hspede a ser cadastrado como:
nome, RG, CPF, data de
nascimento, endereo, telefone ou
permitir a entrada dos dados
mediante as informaes de uma
reserva realizada, confirmando o
registro de entrada no hotel.
O
sistema
permitira
o
prosseguimento
do
cadastro
mediante uma insero de CPF
vlido.
O sistema permite a insero de
suas preferncias quanto a
apartamentos se este hspede se
tornar ao longo do tempo um
cliente freqente.

Obrigatorieda
de

Permannci
a

Especifica
o

O( X ) D(

P(X) T( )

Segurana

O( X ) D(

P(X) T( )

Especifica
o

O( ) D( X )

P(X) T( )

O( X ) D(

P(X) T( )

Categoria

NF2.4
O sistema permite armazenar os
Especifica
Armazenar os
dados mediante a concluso do
o
dados.
cadastro do hspede.
Legenda: O Obrigatrio
D Desejvel
P Permanente

T Transitrio

Quadro 2 Documento de Requisito Cadastrar Hspede

Para que o hspede seja cadastrado, seus dados pessoais obrigatoriamente


devem ser inseridos e seu CPF validado, tal cadastro fazse necessrio para manter
o histrico do hspede, pois facilita o checkin na prxima hospedagem, uma vez
que as informaes estaro armazenadas. Ao cadastrar o hspede, h a opo de
registrar as preferncias em relao a sua estadia, auxiliando na manuteno da
qualidade no atendimento.

29

Oculto ( ) Evidente ( x
)

Nome: F3 Cadastrar Apartamentos.


Descrio: O sistema dever permitir o cadastro do apartamento
Requisitos NoFuncionais
Nome

Restrio

Categoria

O sistema dever permitir a


insero dos dados dos
Especifica
apartamentos a ser cadastrado
o
como: tipo, valor da diria,
nmero, descrio.
NF3.2
O sistema permite armazenar os
Especifica
Armazenar os
dados mediante a concluso do
o
dados.
cadastro do apartamento.
Legenda: O Obrigatrio
D Desejvel
P Permanente
NF3.1
Preencher
campos

Obrigatorieda
de

Permannci
a

O( X ) D(

P(X) T(
)

O( X ) D(

P(X) T(
)

T Transitrio

Quadro 3 Documento de Requisito Cadastrar Apartamentos

O quadro 3 descreve o requisito funcional cadastrar apartamentos e suas


respectivas restries. Para o cadastro de um apartamento necessrio que todos
os campos visualizados sejam obrigatoriamente preenchidos, todas as informaes
so de extrema importncia, pois descrevem detalhadamente os atributos do
apartamento facilitando o controle de ocupao, e a localizao dos mesmos.

Nome: F4 Manter funcionrio

Oculto ( ) Evidente ( x )

Descrio: O sistema permite a consulta, alterao e excluso do funcionrio


Requisitos NoFuncionais
Nome

Restrio

Categoria

O sistema dever permitir a


alterao dos campos do
funcionrio que j est cadastrado
NF4.1
Especifica
Atualizar
como: a funo, a data de
o
campos;
admisso, CPF, RG, nome,
endereo, data de nascimento, n
da CTPS, telefone.
O sistema permitir a consulta do
NF4.2 Validar funcionrio e alterao dos
Segurana
CPF;
campos mediante a validao do
CPF caso seja alterado.
NF4.3
O sistema permite armazenar os
Especifica
Armazenar os
dados mediante a concluso da
o
dados.
alterao.
Legenda: O Obrigatrio
D Desejvel
P Permanente

Obrigatorieda
de

Permanncia

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

T Transitrio

Quadro 4 Documento de Requisito Alterar Funcionrio

O quadro 4 descreve o requisito funcional Manter Funcionrio e suas

30

respectivas restries. Para alterar o cadastro devese informar o CPF para que
faa a busca dos dados j cadastrados. O usurio poder alterar as informaes que
julgar necessrio at mesmo o CPF exceto a matrcula que gerada
automaticamente, sendo vlido para que todos os itens modificados sejam
atualizados na base de dados. Para a consulta dos dados do funcionrio h
necessidade de informar o CPF.

Oculto ( ) Evidente ( x
)

Nome: F5 Manter Hspede.

Descrio: O sistema permite a consulta, alterao e excluso do hspede.


Requisitos NoFuncionais
Nome

Restrio

Categoria

O sistema dever permitir a


consulta e alterao dos dados
NF5.1
pessoais do hspede j
Especifica
Atualizar
cadastrado no sistema: nome, RG, o
campos.
CPF, data de nascimento,
endereo, telefone.
O sistema dever permitir a
NF5.2
contulta e alterao do cadastro
Segurana
Validar CPF.
mediante a validao do CPF do
Hspede.
O sistema permite a atualizao
de suas preferncias de
NF5.3
Especifica
Registrar
hospedagem, se este hspede se
o
preferncias.
tornar ao longo do tempo um
cliente freqente.
NF5.4
O sistema permite armazenar os
Especifica
Armazenar os
dados mediante a concluso da
o
dados.
alterao do hspede.
Legenda: O Obrigatrio
D Desejvel
P Permanente

Obrigatorieda
de

Permannci
a

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

O( ) D( X )

P(X) T( )

O( X ) D(

P(X) T( )

T Transitrio

Quadro 5 Documento de Requisito Alterar Hspede

O quadro 5 descreve o requisito funcional Manter Hspede e suas restries.


Para alterar o cadastro devese informar o CPF para que faa a busca dos dados j
cadastrados. O usurio poder alterar as informaes que julgar necessrio at
mesmo o CPF, sendo vlido para que todos os itens modificados sejam atualizados
na base de dados.

31

Oculto ( ) Evidente ( x
)

Nome: F6 Manter Apartamentos.

Descrio: O sistema dever permitir a consulta, alterao e excluso dos apartamentos


Requisitos NoFuncionais
Nome

Restrio

Categoria

O sistema dever permitir a


consulta e alterao dos dados
Especifica
dos apartamentos cadastrados
o
como: tipo, valor da diria,
nmero, descrio.
NF6.2
O sistema permite armazenar os
Especifica
Armazenar os
dados mediante a concluso da
o
dados.
alterao do apartamento.
Legenda: O Obrigatrio
D Desejvel
P Permanente
NF6.1
Atualizar
campos

Obrigatorieda
de

Permannci
a

O( X ) D(

P(X) T(
)

O( X ) D(

P(X) T(
)

T Transitrio

Quadro 6 Documento de Requisito Cadastrar Apartamentos

O quadro 6 descreve o requisito funcional Atualizar Apartamentos e suas


respectivas restries. Para alterar o cadastro devese informar o cdigo do
apartamento para que faa a busca dos dados j cadastrados. O usurio poder
alterar as informaes que julgar necessrio at mesmo o prprio cdigo, sendo um
novo cdigo, para que todos os itens modificados sejam atualizados na base de
dados.

32

Oculto ( ) Evidente ( x
)

Nome: F7 Registrar reserva.

Descrio: O sistema dever registrar de acordo com a poltica da empresa.


Requisitos NoFuncionais
Categoria

Obrigatorieda
de

Permannci
a

Nome

Restrio

NF7.1
Buscar
informaes do
hspede.
NF7.2
Verificar
disponibilidade
de
apartamentos.

O sistema permite verificar se o


hspede cliente do hotel com
base nas informaes do cadastro
de cliente.

Especifica
o

O( X ) D(

P(X) T(
)

O sistema permite verificar com


base no cadastro de apartamentos
sua disponibilidade.

Especifica
o

O( X ) D(

P(X) T(
)

O( X ) D(

P(X) T(
)

O( X ) D(

O sistema permite o registro dos


campos como: tipo de
apartamento, nmero do quarto,
data da chegada do hspede,
NF7.3
Especifica
quantidade dias previstos, e
Preencher
o
informaes do cliente como:
campos
nome, RG, CPF, data de
nascimento, endereo, telefone,
com base no cadastro de clientes.
NF7.4
O sistema permite armazenar os
Especifica
Armazenar os
dados mediante a concluso do
o
dados.
registro da reserva.
Legenda: O Obrigatrio
D Desejvel
P Permanente

P(X) T(
)

T Transitrio

Quadro 7 Documento de Requisito Registrar Reserva

O quadro 7 descreve o requisito funcional Registrar Reserva e suas


respectivas restries. Para registrar uma reserva necessrio que o hspede
esteja cadastrado e o tipo de apartamento desejado esteja disponvel para assim
prosseguir a reserva e preencher os dados para concluir e gerar o cdigo da
reserva.

33

Nome: F8 Consultar Reserva.

Oculto ( ) Evidente (X)

Descrio: O sistema permite que seja feita uma consulta de reserva.


Requisitos NoFuncionais
Nome

Restrio

Categoria

O sistema permite consultar uma


reserva atravs do CPF do cliente
Especifica
ou pelo numero da reserva, Deve
o
trazer todas as informaes da
reserva.
Legenda: O Obrigatrio
D Desejvel
P Permanente

NF8.1
Buscar
informaes da
reserva

Obrigatorieda
de

O( X ) D(

Permannci
a

P(X) T(
)

T Transitrio

Quadro 8 Documento de Requisito Consultar Reserva

O quadro 8 descreve o requisito funcional Registrar Reserva e suas


respectivas restries. Para registrar uma reserva necessrio que o hspede
esteja cadastrado e o tipo de apartamento desejado esteja disponvel para assim
prosseguir a reserva e preencher os dados para concluir e gerar o cdigo da
reserva.

Oculto ( ) Evidente ( x
)

Nome: F9 Registrar Entrada por reserva

Descrio: O sistema dever permitir o registro da entrada atravs de reserva.


Requisitos NoFuncionais
Nome

Restrio

NF9.1
Consulta
informaes de
reserva.

O sistema permite consultar a


existncia da reserva com base no
cdigo da reserva ou CPF vlido
do cliente que solicitou.
O sistema permite o registro dos
campos como: tipo de
apartamento, nmero do quarto,
data da chegada do hspede,
quantidade dias previstos.

NF9.2
Registrar
entrada

Categoria

Obrigatorieda
de

Permannci
a

Especifica
o

O( X ) D(

P(X) T(
)

Especifica
o

O( X ) D(

P(X) T(
)

O( X ) D(

P(X) T(
)

NF9.3
O sistema permite armazenar os
Armazenar
Especifica
dados mediante a concluso do
o
dados de
registro de entrada.
clientes
Legenda: O Obrigatrio
D Desejvel
P Permanente

T Transitrio

Quadro 9 Documento de Requisito Registrar Entrada por Reserva

O quadro 9 descreve o requisito funcional Registrar Entrada por Reserva e


suas respectivas restries. Para registrar uma entrada por reserva necessrio

34

que o cliente tenha registrado e confirmada sua reserva para assim prosseguir a o
checkin e preencher os dados complementares para efetivar a sua estrada de
estadia no hotel.
Oculto ( ) Evidente ( x
)

Nome: F10 Registrar entrada.

Descrio: O sistema permite o cadastro(incluso) do hspede no hotel.


Requisitos NoFuncionais
Nome

Restrio

Categoria

Obrigatorieda
de

Permannci
a

NF10.1
Consulta
hspede

O sistema permite consultar a


existncia de cadastro de hspede
com base no CPF vlido ou nome
do cliente.

Especifica
o

O( X ) D(

P(X) T( )

NF10.2
Verificar
disponibilidade
de
apartamentos.

O sistema permite verificar com


base no cadastro de apartamentos
sua disponibilidade.

Especifica
o

O( X ) D(

P(X) T(
)

NF10.3
Registrar
entrada

O sistema permite o registro dos


campos como: tipo de
apartamento, nmero do quarto,
data da chegada do hspede,
quantidade dias previstos.

Especifica
o

O( X ) D(

P(X) T( )

O( X ) D(

P(X) T( )

NF10.4
O sistema permite armazenar os
Especifica
Armazenar
dados mediante a concluso do
o
dados de
registro de entrada.
clientes
Legenda: O Obrigatrio
D Desejvel
P Permanente

T Transitrio

Quadro 10 Documento de Requisito Registrar Entrada

O quadro 10 descreve o requisito funcional Registrar Entrada e suas


respectivas restries. Para registrar uma entrada necessrio que o cliente esteja
cadastrado para assim prosseguir a o checkin e preencher os dados da estadia
para ara efetivar a sua estrada no hotel.

35

Oculto ( ) Evidente ( x
)

Nome: F11 Registro de Sada


Descrio:

O sistema permite o fechamento da conta do hspede.

Requisitos NoFuncionais
Nome

NF11.1
Consultar
Extrato de
Gastos do
Cliente
NF11.2
Gerar total de
gastos do
cliente

Restrio

Categoria

Obrigatorieda
de

Permannci
a

O sistema dever permitir acesso


consulta do extrato de gastos de
clientes que se encontra no campo
histrico.

Especifica
o

O( X ) D(

P(X) T(
)

O sistema dever permitir o valor


total de gastos de clientes.

Especifica
o

O( X ) D(

P(X) T(
)

O( X ) D(

P(X) T(
)

O sistema dever atribuir ao


Especifica
registro de sada sua data e hora
o
do encerramento da conta e valor
total pago.
Legenda: O Obrigatrio
D Desejvel
P Permanente

NF11.3
Fechar conta.

T Transitrio

Quadro 11 Documento de Requisito Registrar Sada

O quadro 11 descreve o requisito funcional Registrar Sada e suas


respectivas restries. Para que o hspede feche sua estadia h necessidade que
seja lanado todos os valores dos servios oferecidos pelo hotel para assim efetivar
o checkout do hspede.
Nome: F12 Gerar Mapa de Acomodaes

Oculto ( ) Evidente (X)

Descrio: O sistema permite a criao de um relatrio de acomodaes do hotel


Requisitos NoFuncionais
Nome

Restrio

Categoria

O sistema permite gerar um


relatrio que devera conter a
NF12.1
relao de todos os apartamentos
Especifica
Gerar Home
do Hotel, quais esto ocupados,
o
List
quem esta ocupando esse
apartamento e qual a previso de
liberao desse apartamento.
Legenda: O Obrigatrio
D Desejvel
P Permanente

Obrigatorieda
de

O( X ) D(

Permannci
a

P(X) T(
)

T Transitrio

Quadro 12 Documento de Requisito Gerar Mapa de Acomodaes.

O quadro 12 descreve o requisito funcional Gerar Mapa de Acomodaes e


suas respectivas restries. Para que o usurio obtenha as informaes dever
possuir pelo menos um apartamento cadastrado, assim trazendo todos os dados de
ocupaes ou reservas existentes para ele.
36

3.1

ANLISE E PROJETO

Introduo

3.1.1 Engenharia de Software

Durante a crise do software, ficou explcito que as abordagens informais


utilizadas na poca para desenvolvimento de software eram ineficientes, propiciando
atrasos para o fim dos projetos e gerando um custo acima do previsto. Com intuito
de buscar a produo efetiva de software de alta qualidade com custos e prazos
reduzidos, foi criada uma abordagem sistemtica, a Engenharia de Software.
Um sistema de software complexo se caracteriza por um conjunto de
componentes

abstratos

de

software

(estruturas

de

dados

algoritmos)

encapsulados na forma de procedimentos, funes, mdulos, objetos ou agentes


interconectados entre si, que devero ser executados em sistemas computacionais.
Essa engenharia envolve o uso de modelos abstratos e precisos que permitem ao
engenheiro especificar, planejar e gerenciar o processo de desenvolvimento.
Segundo Gaudel (1996), a Engenharia de Software pode ser vista como a
arte de especificar, analisar, conceber, realizar, verificar e fazer evoluir programas,
documentaes, procedimentos de qualidade com meios e prazos razoveis, a fim
de poder usar um sistema computacional para tratar certos problemas.
No Levantamento de Requisitos muito importante que os requisitos sejam
extrados da maneira correta e objetiva. Caso o sistema seja utilizado por uma
grande quantidade de pessoas, recomendado que as entrevistas sejam feitas com
presena de um conjunto de representantes do cliente (dependendo da
complexidade do sistema) divididos por reas de atuao e outros especialistas das
reas de interesse.
Para desenvolver um software que satisfaa o propsito pretendido,
necessrio reunir-se e interagir com os usurios de uma maneira
disciplinada, buscando determinar os requisitos reais do sistema

37

(BACAL, 2003, P.12).

Requisito pode ser descrito como uma condio ou capacidade necessitada


por um usurio para resolver um problema ou alcanar um objetivo. Enfim, tudo o
que o sistema deve fazer para implementar uma necessidade de automao
requerida pela soluo. Na prtica, requisito o que o sistema tem que ter para
atender plenamente ao propsito para o qual foi criado.
Depois de feito o levantamento de requisitos, h necessidade de uma anlise
envolvendo a equipe funcional que deve verificar cada requisito, em termos de existir
consistncia, e checar os mesmos como um todo.
- A especificao no dever haver a preocupao com a soluo tcnica que
ser adotada, poder, no entanto, h a necessidade de descrever as opes j
verificadas ou desejadas pelos usurios no que se refere tecnologia pretendida.

3.1.2 A Linguagem UML

Para possibilitar a visualizao dos requisitos e da arquitetura, facilitando a


compreenso do problema proposto necessrio utilizao de uma ferramenta de
modelagem, pois durante a execuo das mais diversas atividades devem-se
construir modelos para representar a estrutura e o comportamento desejado do
sistema. Para o desenvolvimento do projeto utilizou-se a modelagem UML (Unified
Modeling Language) que tem como objetivo:
-

Fornecer aos usurios uma linguagem de modelagem visual expressiva e


pronta para o desenvolvimento para os modelos de negcio;

Ser

independente

de

linguagens

de

programao

processos

de

desenvolvimento;
-

Prover uma base formal para prover uma linguagem de modelagem;

Encorajar o Crescimento no nmero de ferramentas orientadas a objeto no


mercado;

38

Suportar conceitos de desenvolvimento de nvel mais elevado tais como


colaboraes, estruturas de trabalho, padres e componentes;

Integrar as melhores prticas;


A Unified Modeling Language muito mais que a padronizao de uma

notao, o desenvolvimento de novos conceitos. Por essa razo entender UML


no apenas aprender a ler uma simbologia, mas significa aprender a modelar
orientado a objetos.
A UML uma linguagem padro para especificar, visualizar,
documentar e construir artefatos de um sistema e pode ser utilizada
com todos os processos ao longo do ciclo de desenvolvimento e
atravs de diferentes tecnologias de implementao (FURLAN, 1998,
P.3).

Segundo Bacal (2003), a UML uma linguagem de modelagem simples,


intuitiva, homognea, coerente e genrica que pode ser estendida e configurada
pelo usurio, pois suficientemente expressiva para modelar a estrutura, o
comportamento e o fluxo de trabalho de vrios tipos de atividades.
Um modo para descrever os vrios aspectos de modelagem atravs de uma
notao definida pelos seus vrios tipos de digramas. Um diagrama uma
apresentao grfica de um conjunto de elementos e so usados para visualizar o
sistema sob diferentes perspectivas e define um nmero de diagramas que permite
dirigir o foco para aspectos diferentes do sistema de maneira independente. Se bem
usados, os diagramas facilitam a compreenso do sistema que est sendo
desenvolvido.
A UML pode ser usada para mostrar as fronteiras de um sistema e suas
funes principais utilizando atores e casos de uso, representar uma estrutura
esttica de um sistema utilizando um diagrama de classe, modelar o comportamento
de objetos com diagrama de composio de estado, revelar a arquitetura de
implementao fsica com diagramas de componente de implantao, estender sua
funcionalidade atravs de esteretipos.
A Unified Modeling Language possui diversos diagramas que podem ser
divididos em estticos (diagrama de classes, diagrama de objetos, diagrama de

39

componentes e diagramas de implantao), para representao estrutural dos dados


e dinmico (diagrama de casos de uso, diagramas de seqncia, diagramas de
grficos de estado, diagrama de atividades), usado para representao do controle
do sistema.
Para este Projeto foram modelados os diagramas de caso de uso, diagramas
de classe, diagrama de pacote, diagramas de seqncia alm da documentao de
casos de uso e de requisitos.

3.2

Diagrama de Casos de Uso

Casos de uso (do ingls Use Case) uma excelente forma de entender o
ponto de vista do usurio simplesmente pelo fato de que modela o que ele precisa
executar.
Outros aspectos, tais como: como cada caso de uso efetivamente utilizado
ou onde ficaro armazenados os dados que so utilizados para fazer os casos de
uso funcionassem, so assuntos para discusso em prximos diagramas.
Segundo Scheneider (1998), um caso de uso uma descrio de um
conjunto de seqncias representando a interao de itens externos ao sistema
(atores) com o prprio sistema. Os casos de uso so tcnicas de levantamento e
captura de requisitos e tem como principal caracterstica a simplicidade da
representao facilitando a comunicao do usurio, alm de representar uma
funcionalidade do sistema, sem a necessidade de especificar como ser
implementado
A implementao de um tipo de Caso de Uso apresentada como uma
colaborao de objetos e vnculos junto com possveis seqncias de fluxos,
mensagens que produzem o efeito do Caso de Uso, intensificando a explorao de
cada cenrio de Caso de Uso de um sistema a partir de um caminho normal pelo
cenrio descrevendo as excees e condies de erro que podem acontecer
explicitamente.
Para identificao dos casos de uso, podemse observar os seguintes
aspectos:

40

O ator precisa ler criar, destruir, modificar ou armazenar algum tipo de


informao no sistema?
O trabalho dirio do ator pode ser simplificado ou tornado mais eficiente
atravs de novas funes no sistema?
O ator tem de ser notificado sobre eventos no sistema ou ainda notificar o
sistema entre si?
Quais so as funes que o ator necessita do sistema?
O que o ator necessita fazer?
Quais so os principais problemas com a implementao atual do
sistema?
Quais so as entradas e as sadas, juntamente com sua origem e destino
que o sistema requer?
Quadro 13 Aspectos de identificao dos Casos de Uso

Um caso de uso no deve se preocupar com o "como" das funes, mesmo


que seja apenas uma maneira de conhecer o fluxo de entrada e sada de dados.
importante encapsular aes que em conjunto sejam relevantes e que de alguma
forma influenciam algo ou algum no sistema. Identificar um caso de uso, portanto,
um esforo que envolve:

Descobrir um ator (algum que influencia ou influenciado pelo


sistema);

Verificar para esse ator aes das quais ele participaria;

Agrupar tais aes de forma que possuam um nome em comum.

3.2.1 Descrio dos Atores

Os Casos de Uso sempre esto associados a um ator que representa


qualquer entidade com a qual o sistema interage tais como usurios e outros
sistemas de informao.
Os atores podem ser classificados como atores principais, quem utilizar a
41

principal funcionaidade do sistema, e atores secundrios, quem ir manter,


administrar e fazer com que o sistema permanea operando.
Para descreverse um Caso de Uso corretamente necessrio identificar
cada ator pelo papel que representa na interao com o sistema, por exemplo,
cliente, gerente, funcionrio.
No diagrama de casos de uso do Sistema de gerenciamento de hotelaria do
Porto Bello Palace Hotel, foram identificados dois atores: o Cliente e o Funcionrio.
- Cliente: Este ator a pessoa que se beneficia com a realizao das
atividades realizadas no sistema, em todos os casos de uso em que tem
participao considerado ator secundrio (checkin por reserva, checkin,
checkout, cadastrar hspede).
- Funcionrio: Este ator a pessoa que atua no sistema para realizar todas as
funcionalidades previstas no sistema, em todos os casos de uso tem o papel
de ator primeiro, uma vez que inicia todos os casos de uso do sistema
desenvolvido.
Cada ator comunicase com o sistema enviando e recebendo mensagense
um caso de uso iniciase a partir do momento que um ator envia uma mensagem, e
representado por uma elipse conectada a smbolos de atores. Um retngulo
mostra os limites (fronteiras) do sistema, contendo em seu interior o conjunto de
casos de uso e, do lado externo, os atores interagindo com o sistema. Cada linha
entre o ator e uma elipse de caso de uso mostra uma interao entre eles.
As interaes so muito importantes em um diagrama de casos de uso, pois
descrevem como deve ser a comunicao entre atores e casos de usos e entre
casos de usos. No Diagrama de Casos de Uso do Porto Bello Palace Hotel utilizou
se as interaes de comunicao, extenso(<<extends>>) e incluso (<<include>>).
A comunicao utilizada para conectar o ator com o caso de uso por um
caminho slido.
A extenso um relacionamento de um caso de uso para o outro,
especificando como o comportamento definido para o primeiro pode ser inserido no
comportamento definido para o segundo. Pode se disser que utilizada para
expressar rotinas de exceo e pra descrever cenrios opcionais de um Caso de

42

Uso que somente ocorrero em uma situao especfica, se uma determinada


condio for satisfeita.
Um relacionamento de incluso entre casos de uso ocorre quando h uma
parcela de comportamento similar entre eles sugerindo uma reutilizao em vez de
uma nova cpia para descrio do comportamento.
Em uma modelagem de casos de uso importante que no inclua aspectos
de implementao, Conforme j citado anteriormente, o "como" deve ser deixado
para outros nveis de abstrao, ou seja, para os diagramas de classes e de
interao.
No entanto, o aspecto mais perigoso nesse momento seria o abuso de
includes e extends. A relao de incluso deve ser empregada somente quando
houver realmente um compartilhamento da funo indicada; caso contrrio estar
abusando do detalhamento.

Figura 1 Diagrama de Casos de Uso

A figura 1 apresenta o diagrama geral de casos de uso do Porto Bello Palace


43

Hotel.

3.3

Detalhamento dos Casos de Uso

O modelo usado para descrever os casos de uso, os atores e a


documentao do caso de uso apresenta os seguintes itens:
Nome: o mesmo que aparece no diagrama de caso de uso.
Sumrio: uma pequena descrio do caso de uso.
Ator primrio: nome do ator que inicia o caso de uso.
Ator(s) secundrio(s): nomes dos demais atores participantes do caso de
uso.
Prcondio: define que hipteses so assumidas como verdadeiras para
que se tenha incio um caso de uso.
Pscondio: define a finalizao do caso de uso, encerramento deste.
Fluxo principal: descreve o que normalmente acontece quando o caso de uso
realizado, uma descrio da seqncia de passos.
Fluxo alternativo: utilizado para descrever o que acontece quando o ator faz
uma escolha alternativa, diferente da descrita no fluxo principal, para
alcanar o seu objetivo.
Fluxo de exceo: descrio de situaes que acontecem quando algo
inesperado ocorre na iterao entre o usurio e o caso de uso.
Regras de negcio: a descrio de caso de uso pode fazer uma referencia a
uma ou mais regras de negcio, so polticas, condies ou restries.
Abaixo sero apresentadas as regras de negcios identificadas referente aos
casos de uso do sistema SGPB no quadro 14.

44

Quadro 14 Regra de Negcio

Abaixo sero demonstrados os quadros com as especificaes dos casos de


uso identificados no sistema.

45

Nome

Cadastrar funcionrio

CSU01

Este caso de uso descreve as etapas necessrias para o cadastro de


funcionrios na empresa.
Ator primrio: Funcionrio.
Sumrio

Ator secundrio: N/A.


Prcondio: O Funcionrio deve estar logado ao sistema e o funcionrio dever
possuir um CPF vlido.
Pscondio: O funcionrio cadastrado.
Fluxo Principal
1. O Caso de uso inicia quando o funcionrio clica no menu funcionrio.
2. O sistema apresenta um submenu referente s opes do funcionrio.
3. O Funcionario clica em cadastrar funcionrio.
4. O sistema apresenta uma tela com os campos necessrios para realizar o cadastro.
5. Funcionrio fornece os dados do futuro funcionrio, define o cargo e clicar em
cadastrar.
6. O sistema dever armazenar os dados obtidos e gerar um nmero de matricula.
7. O caso de uso finaliza quando o funcionrio recebe na tela a mensagem que os
dados foram salvos com sucesso.
Fluxo de Exceo [3]: Dados Obrigatrios no Preenchidos.
a. O sistema verifica se todos os campos obrigatrios do cliente foram preenchidos.
b. O caso de uso retorna ao passo 2.
Fluxo de Exceo [3]: CPF invlido.
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e n disponibiliza
o sucesso do cadastro do funcionrio.
b. O caso de uso retorna ao passo 3.
Regra de Negcio Associadas
RN01, RN02 e RN03.

Quadro 15 Detalhe do caso de uso CSU01

46

Nome

Cadastrar Hspede

CSU02

Este caso de uso descreve as etapas necessrias para o cadastro de


hspedes no hotel.
Ator primrio: Funcionrio.
Sumrio

Ator secundrio: Hspede.


Prcondio: O Funcionrio deve estar logado ao sistema e o Hspede dever
possuir um CPF vlido.
Pscondio: O funcionrio cadastrado.
Fluxo Principal
1. O Caso de uso inicia quando o funcionrio clica no menu Hspede.
2. O sistema apresenta um submenu referente s opes do Hspede.
3. O Funcionrio clica em cadastrar hspede.
4. O sistema apresenta uma tela com os campos necessrios para realizar o cadastro e
registro de preferncias, se for o caso.
5. O Funcionrio fornece os dados do cliente ao sistema e, se for o caso, fornece
tambm as preferncias do cliente e clica em cadastrar.
6. O sistema armazena os dados obtidos.
7. O caso de uso finaliza quando o funcionrio recebe na tela a mensagem que os
dados foram salvos com sucesso.
Fluxo de Exceo [3]: Dados Obrigatrios no Preenchidos.
a. O sistema verifica se todos os campos obrigatrios do cliente foram preenchidos.
b. O caso de uso retorna ao passo 2.
Fluxo de Exceo [3]: CPF invlido
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no
disponibiliza o sucesso do cadastro do hspede.
b. O caso de uso retorna ao passo 3.
Regra de Negcio Associadas
RN01, RN02 e RN03.
Quadro 16 Detalhe do caso de uso CSU02

47

Nome
Sumrio

Cadastrar Apartamento

CSU03

Este caso de uso descreve as etapas necessrias para o cadastro de


apartamentos do hotel.

Ator primrio: Funcionrio.


Ator secundrio: no possui.
Prcondio: O apartamento no est cadastrado.
Pscondio: O apartamento cadastrado.
Fluxo Principal
1. O Caso de uso inicia quando o funcionrio clica no menu Apartamento.
2. O sistema apresenta um submenu referente s opes do Apartamento.
3. O Funcionrio clica em cadastrar Apartamento.
4. O sistema apresenta uma tela com os campos necessrios para realizar o cadastro.
5. Funcionrio fornece os dados do apartamento e clicar em cadastrar.
6. O sistema armazena os dados obtidos.
7.
O caso
de uso [3]:
finaliza
quando
o funcionrio
recebe na tela a mensagem que os
Fluxo
de Exceo
Dados
Obrigatrios
no Preenchidos.
a. O sistema verifica se todos os campos obrigatrios do cliente foram preenchidos.
b. O caso de uso retorna ao passo 2.
Fluxo de Exceo [3]: Apartamento j possui cadastro.
a. O sistema emite uma mensagem dizendo que o apartamento est cadastrado e no
disponibiliza o sucesso do cadastro do Apartamento informado.
b. O caso de Uso retorna ao passo 2.
Regra de Negcio Associadas
RN01 e RN03.
Quadro 17 Detalhe do caso de uso CSU03

48

Nome

CSU04
Manter funcionrio
Este caso de uso descreve as etapas necessrias para a Manuteno de
Sumrio
um Funcionrio.
Ator primrio: Funcionrio.
Ator secundrio: N/A.
Prcondio: O Funcionrio deve estar logado ao sistema e o funcionrio dever
possuir um CPF vlido.
Pscondio: Manuteno do Funcionrio efetuada.
Fluxo Principal
1. O Caso de uso inicia quando o funcionrio clica no menu Funcionrio.
2. O sistema apresenta um submenu referente s opes do Funcionrio.
3. O Funcionrio clica em Manter funcionrio.
4. O sistema apresenta uma tela com o campo de CPF.
5. O Funcionrio fornece CPF e clica em pesquisar.
6. O Sistema efetua a consulta e retorna os dados do funcionrio.
7. O caso de uso finaliza quando o funcionrio recebe na tela a mensagem que a
manuteno desejada foi efetuada com sucesso.
Fluxo Alternativo [4]: Alterao
a. O Funcionrio modifica os campos que desejar e clicar em atualizar.
b. O sistema atualiza os dados modificados e retorna para o passo cinco.
Fluxo Alternativo [4]: Excluso
a. O Funcionrio clicar em excluir.
b. O sistema exclui o registro apresentado na tela e retorna para o passo cinco.
Fluxo de Exceo [3]: CPF invlido.
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no
disponibiliza a continuao da alterao ou retornos dos dados do funcionrio.
b. O caso de uso retorna ao passo dois para consulta e retorna para o passo cinco
para atualizao dos dados.
Fluxo de Exceo [4]: Funcionrio no encontrado.
a. O sistema emite uma mensagem dizendo que o Funcionrio no est cadastrado e
no disponibiliza o sucesso da busca dos dados do Funcionrio.

b. O caso de uso retorna ao passo 2.


Fluxo de Exceo [5]: Dados Obrigatrios no Preenchidos.
a. O sistema emite uma mensagem dizendo que todos os campos obrigatrios para
consulta ou de alterao devem ser preenchidos.
b. Na situao de consulta o caso de uso retorna ao passo 2
c. Na situao de alteao o caso de uso retorna ao fluxo alternativo alterao do
passo 4.
Regra de Negcio Associadas
RN01, RN02 e RN03.
Quadro 18 Detalhe do caso de uso CSU04

49

Nome

Manter Hspede

CSU05

Sumrio
Este caso de uso descreve as etapas para a Manuteno de um Hspede.
Ator primrio: Funcionrio.
Ator secundrio: Hspede.
Prcondio: O Funcionrio deve estar logado ao sistema e o Hspede dever possuir um
CPF vlido.
Pscondio: Manuteno do Hspede efetuada.
Fluxo Principal
1. O Caso de uso inicia quando o funcionrio clica no menu hspede.
2. O sistema apresenta um submenu referente s opes do hspede.
3. O Funcionrio clica no submenu Manter hspede.
4. O sistema apresenta uma tela com o campo de CPF.
5. O Funcionrio fornece CPF e clica em pesquisar.
6. O Sistema efetua a consulta e retorna os dados do hspede.
7. O caso de uso finaliza quando o funcionrio recebe na tela a mensagem que a
Fluxo Alternativo [4]: Alterao
a. O Funcionrio modifica os campos que desejar e clicar em atualizar.
b. O sistema atualiza os dados modificados e retorna para o passo cinco.
Fluxo Alternativo [4]: Excluso
a. O Funcionrio clicar em excluir.
b. O sistema exclui o registro apresentado na tela e retorna para o passo cinco.
Fluxo de Exceo [3/5]: CPF invlido
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no disponibiliza a
continuao da alterao ou retornos dos dados do hspede.
b. O caso de uso retorna ao passo dois para consulta e retorna para o passo cinco para
atualizao dos dados.
Fluxo de Exceo [4]: Hspede no encontrado.
a. O sistema emite uma mensagem dizendo que o hspede no est cadastrado e no
disponibiliza o sucesso da busca dos dados do hspede.
b. O caso de uso retorna ao passo 2.
Fluxo de Exceo [5]: Dados Obrigatrios no Preenchidos.
a. O sistema emite uma mensagem dizendo que todos os campos obrigatrios para
consulta ou de alterao devem ser preenchidos.
b. Na situao de consulta o caso de uso retorna ao passo 2.
c. Na situao de alteao o caso de uso retorna ao fluxo alternativo alterao do passo 4.
Regra de Negcio Associadas
RN01, RN02 e RN03.
Quadro 19 Detalhe do caso de uso CSU05

50

Nome

Manter Apartamento

CSU06

Este caso de uso descreve as etapas necessrias a Manuteno de


apartamentos no hotel.
Ator primrio: Funcionrio.
Sumrio

Ator secundrio: no possui.


Prcondio: O apartamento est cadastrado.
Pscondio: Manuteno do Apartamento efetuada.
Fluxo Principal
1. Caso de uso inicia quando o funcionrio clica no menu apartamento.
2. O sistema apresenta um submenu referente s opes do apartamento.
3. O funcionrio clica em Manter Apartamento.
4. O sistema apresenta uma tela com o campo numero apartamento.
5. Sistema retorna dados do Apartamento.
6. Funcionrio fornece o numero e clica em pesquisar.
7. O Sistema efetua a consulta e retorna os dados do apartamento.
8. O caso de uso finaliza quando o funcionrio recebe na tela a mensagem que a
manuteno desejada foi efetuada com sucesso.
Fluxo Alternativo [4]: Alterao
a. O Funcionrio modifica os campos que desejar e clicar em atualizar.
b. O sistema atualiza os dados modificados e retorna para o passo 6.
Fluxo Alternativo [4]: Excluso
a. O Funcionrio clica em excluir.
b. O sistema exclui o registro apresentado na tela e retorna para o passo 6.
Fluxo de Exceo [4]: Apartamento no possui cadastro.
a. O sistema emite uma mensagem dizendo que o apartamento no est cadastrado e
no disponibiliza o sucesso da busca dos dados do Apartamento informado.
b. O caso de uso retorna ao passo 2.
Fluxo de Exceo [5]: Dados Obrigatrios no Preenchidos.
a. O sistema emite uma mensagem dizendo que todos os campos obrigatrios do
cliente devem ser preenchidos.
b. Na situao de consulta o caso de uso retorna ao passo 2.
c. Na situao de alteao o caso de uso retorna ao fluxo alternativo alterao do
passo 4.
Regra de Negcio Associadas
RN01 e RN03.
Quadro 20 Detalhe do caso de uso CSU06

51

Nome

Registrar Reserva

CSU07

Este caso de uso descreve as etapas necessrias para o registro de


reservas de acordo com a poltica da empresa.
Ator primrio: Funcionrio
Sumrio

Ator secundrio: Cliente


Prcondio: A Reserva no est registrada.
Pscondio: A Reserva est registrada.
Fluxo Principal
1. Caso de uso inicia quando o funcionrio clica no menu Reserva.
2. O sistema apresenta um submenu referente s opes da Reserva.
3. O funcionrio clica em Registrar Reserva.
4. O sistema apresenta uma tela com o campo de CPF.
5. Funcionrio fornece CPF e clica em pesquisar.
6. O Sistema efetua a consulta e retorna dados da reserva e do hspede.
7. O Sistema solicita o preenchimento do restante das informaes de reserva.
8. Funcionrio informa restante dos dados, o tipo de apartamento e clica em registrar.
9. O sistema verifica se h apartamentos disponveis para reservas do tipo de
apartamento informado.
10. O sistema armazena as atualizaes efetuadas.
11. Caso de uso finaliza quando o funcionrio recebe na tela a mensagem que os dados
foram salvos com sucesso.
Fluxo de Exceo [3]: CPF invlido
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no
disponibiliza o sucesso da busca dos dados do hspede.
b. O caso de uso retorna ao passo dois.
Fluxo Alternativo [4]: Cliente no cadastrado
a. O sistema emite uma mensagem dizendo que o cliente no est cadastrado e no
disponibiliza o sucesso do cadastro da reserva.
b. O caso de uso e desviado para o caso uso cadastrar hspede CSU02.
c. Aps todas as etapas do cadastro do cliente esteja realizada, o caso de uso passa
para o passo 5.
Fluxo de Exceo [6]: Dados Obrigatrios no Preenchidos.
a. O sistema verifica se todos os campos obrigatrios do cliente foram preenchidos.
b. O caso de uso retorna ao passo 5.
Fluxo de Exceo [7]: No h apartamentos disponveis

52

a. O sistema emite uma mensagem informando que no h disponibilidade para a


reserva para o tipo de apartamento informado.
b. Caso de uso retorna ao passo 6.
Regra de Negcio Associadas
RN01, RN02, RN03, RN04 e RN05.
Quadro 21 Detalhe do caso de uso CSU07

Nome
Sumrio

Consultar Reserva

CSU08

Este caso de uso descreve as etapas necessrias para a consulta de


reservas de acordo com a poltica da empresa.

Ator primrio: Funcionrio


Ator secundrio: Cliente
Prcondio: Reserva j registrada
Pscondio: Dados da Reserva consultada.
Fluxo Principal
1. Caso de uso inicia quando o funcionrio clica no menu reserva.
2. O sistema apresenta um submenu referente s opes da reserva.
3. O funcionrio clica em Consultar reserva.
4. O sistema apresenta uma tela com o campo de CPF e numero de reserva.
5. Cliente informa numero de CPF ou numero de reserva.
6.
Sistema
efetua a[3]:
consulta
com base no CPF ou numero e retorna dados da Reserva.
Fluxo
de Exceo
CPF invlido.
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no
disponibiliza o sucesso da busca dos dados do hspede.
b. O caso de uso retorna ao passo 2.
Fluxo Exceo [4]: Reserva no cadastrada
a. O sistema emite uma mensagem dizendo que o cliente no possui reserva.
b. O caso de uso encerrado.
Regra de Negcio Associadas
RN01 e RN02.
Quadro 22 Detalhe do caso de uso CSU08

53

Nome

Registrar Entrada por Reserva

CSU09

Este caso de uso descreve as etapas necessrias para o registro de


entrada por meio de reserva
Ator primrio: Funcionrio
Sumrio

Ator secundrio: Cliente


Prcondio: O cliente ter efetuado uma reserva anteriormente.
Pscondio: A entrada do hspede registrada.
Fluxo Principal
1. Caso de uso inicia quando o funcionrio clica no menu hospedagem.
2. O sistema apresenta um submenu referente s opes da hospedagem.
3. O funcionrio clica em Registrar Entrada por Reserva.
4. O sistema apresenta uma tela para ser colocado o CPF ou o numero da reserva.
5. O Funcionrio fornece o CPF ou o nome do cliente
6. O sistema consulta, com base no CPF ou numero da reserva, a existncia da
reserva.
7. Sistema retorna dados da Reserva e solicita restante dos dados.
8. O funcionrio informa restante dos dados e clica em registrar.
9. O sistema com base no registro de identificao de reserva armazena os dados do
registro.
Fluxo de Exceo [3]: CPF invlido
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no
disponibiliza o sucesso da entrada do hspede.
b. O caso de uso retorna ao passo 2.
Fluxo de Exceo [4]: Reserva No Cadastrada
a. O sistema emite uma mensagem dizendo que o cliente no possui reserva e no
dispibiliza o checkin do Hspede.
b. O caso de uso encerrado.
Fluxo de Exceo [6]: Dados Obrigatrios no Preenchidos.
a. O sistema emite uma mensagem dizendo que todos os campos obrigatrios do
cliente devem ser preenchidos.
b. O caso de uso retorna ao passo 6.
Regra de Negcio Associadas
RN01, RN02, RN03 e RN05.
Quadro 23 Detalhe do caso de uso CSU09

54

Nome
Sumrio

Registrar Entrada

CSU10

Este caso de uso descreve as etapas necessrias para o registro de


entrada.

Ator primrio: Funcionrio


Ator secundrio: Cliente
Prcondio: O Funcionrio deve efetuar login no sistema e o cliente cadastrado.
Pscondio: A entrada do hspede registrada.
Fluxo Principal
1. Caso de uso inicia quando o funcionrio clica no menu Hospedagem.
2. O sistema apresenta um submenu referente s opes da Hospedagem.
3. O funcionrio clica em Registrar Entrada.
4. O sistema apresenta uma tela para ser colocado o CPF.
5. Funcionrio fornece o CPF e clica em pesquisar.
6. O sistema consulta, com base no CPF ou nome fornecido, a existncia do cadastro
desse cliente.
7. O Sistema solicita o preenchimento do restante das informaes do checkin.
8. Funcionrio informa restante dos dados e o tipo de apartamento e clica em registrar.
9. O sistema verifica se h apartamentos disponveis para reservas para o tipo de
apartamento informado
10. O sistema registra a entrada do cliente com base no registro de identificao de
reserva ou dados de cadastro de cliente
11. O sistema armazena os dados informados.
Fluxo de Exceo [3]: CPF invlido.
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no
disponibiliza o sucesso da entrada do hspede.
b. O caso de uso retorna ao passo trs.
Fluxo Alternativo [4]: Cliente no cadastrado
a. O sistema emite uma mensagem dizendo que o cliente no est cadastrado e
disponibiliza a opo de cadastro do Cliente.
b. Caso de uso e desviado para o caso uso cadastrar hspede CSU02.
c. Aps todas as etapas do cadastro do cliente esteja realizada, o caso de uso passa
para o passo 6.
Fluxo de Exceo [6]: Dados Obrigatrios no Preenchidos.
a. O sistema emite uma mensagem dizendo que todos os campos obrigatrios do
cliente devem ser preenchidos.
b. O caso de uso retorna ao passo 6.

55

Fluxo de Exceo [7]: No h apartamentos disponveis


a. O sistema emite uma mensagem informando que no h disponibilidade para o
chekin do tipo de apartamento informado.
b. Caso de uso retorna ao passo 6.
Regra de Negcio Associadas
RN01, RN02, RN03, RN04 e RN05.
Quadro 24 Detalhe do caso de uso CSU10

56

Nome
Sumrio

Registrar Sada

CSU11

Este caso de uso descreve as etapas necessrias para o registro de sada


do hspede

Ator primrio: Funcionrio


Ator secundrio: Cliente
Prcondio: O Funcionrio deve estar logado no sistema e o cliente hospedado.
Pscondio: A sada do hspede efetuada
Fluxo Principal
1. Caso de uso inicia quando o funcionrio clica no menu Hospedagem.
2. O sistema apresenta um submenu referente s opoes da Hospedagem.
3. O funcionrio clica em Registrar Sida.
4. O sistema apresenta uma tela com o campo de CPF, numero do apartamento e da
hospedagem.
5. O Cliente informa o CPF e nmero do apartamento ou o nmero da hospedagem e
clica em pesquisar.
6. O sistema efetua a consulta e retorna os dados da hospedagem.
7. Funcionrio lana os valores adicionais e clica em encerrar hospedagem.
8. O sistema calcula o valor da hospedagem e atualiza disponibilidade do apartamento.
9. O sistema emite o valor total da hospedagem
10.
O caso
de uso finaliza
quando
o funcionrio recebe na tela a mensagem que os
Fluxo
de Exceo
[3]: CPF
invlido.
a. O sistema emite uma mensagem dizendo que o CPF est incorreto e no
disponibiliza o sucesso da entrada do hspede.
b. O caso de uso retorna ao passo 3.
Fluxo Alternativo [4]: Hospedagem no cadastrada
a. O sistema emite uma mensagem dizendo que no h hospedagem cadastrada e
disponibiliza a opo da consulta da hospedagem.
b. Caso de uso retorna ao passo 2.
Regra de Negcio Associadas
RN01 e RN02.
Quadro 25 Detalhe do caso de uso CSU11

57

Nome

Gerar Mapa de Acomodaes

Sumrio

CSU12

Este caso de uso descreve as etapas necessrias para a gerao do mapa


de acomodaes.

Ator primrio: Funcionrio


Ator secundrio(s): N/A
Prcondio: O funcionrio estar logado no sistema e apartamentos cadastrados.
Pscondio: Relatrio gerado
Fluxo Principal
1. Caso de uso inicia quando o funcionrio clica em Mapa de Acomodaes.
2. O sistema busca todas as informaes referentes s acomodaes.
3. O Funcionrio visualiza o relatrio gerado e se desejar pode fazer pedir a impresso
do relatrio.
4. O caso de uso finaliza quando o funcionrio clica em sair.
Fluxo Alternativo [2]: Nenhum apartamento cadastrado
a. O sistema emite uma mensagem dizendo que no h apartamentos cadastrados e
no disponibiliza a gerao das acomodaes.
b. Caso de uso e encerrado.
Quadro 26 Detalhe do caso de uso CSU12

3.4

Diagrama de Classe de Analise

Segundo Furlan (1998), diagrama de classes tratase de uma estrutura


lgica, esttica em uma superfcie de duas dimenses mostrando uma coleo de
elementos declarativos de modelo como classes, tipos e seus respectivos contedos
e relaes, e so encontrados com maior freqncia na modelagem de sistemas
orientados objetos
As classes possuem alm de um nome, os atributos e mtodos. Uma relao
indica um tipo de dependncia entre as classes. Geralmente as classes no esto
ss e se relacionam entre si. O relacionamento e a comunicao entre as classes
definem responsabilidades, a UML reconhece trs tipos mais importantes de
relaes: dependncia, associao e generalizao (ou herana).
A associao um relacionamento estrutural entre instncias e especificam

58

que objetos de uma classe esto ligados a objetos de outras classes. Podemos ter
associao unria, quando a um relacionamento de uma classe consigo prpria,
binria, quando a duas classes envolvidas na associao de forma direta de uma
para outra e nria, que uma associao de trs ou mais classes, mas uma nica
classe pode aparecer mais de uma vez. Em uma associao podemos definir dois
tipos:
- Agregao Regular tipo de associao ( parte de, todo/parte) onde o
objeto parte um atributo do todo; onde os objetos partes somente so criados
se o todo ao qual esto agregados seja criado. Pedidos composto por itens de
pedidos.
- Agregao de Composio Relacionamento entre um elemento (o todo) e
outros elementos (as partes) onde as parte s podem pertencer ao todo e so
criadas e destrudas com ele.
A dependncia um relacionamento de utilizao no qual uma mudana na
especificao de um elemento pode alterar a especificao do elemento
dependente. A dependncia entre classes indica que os objetos de uma classe
usam servios dos objetos de outra classe.
A generalizao um relacionamento entre um elemento mais geral e um
mais especfico. Onde o elemento mais especfico (subclasse) herda as
propriedades e mtodos do elemento mais geral (superclasse). A relao de
generalizao tambm conhecida como herana no modelo a objetos. Como a
relao de dependncia, ela existe s entre as classes.
A figura 2 apresenta graficamente os relacionamentos entre classes em uma
representao de um diagrama de classes.

59

Figura 2 Representao grfica de relaes entre classes

Uma classe uma representao de um conjunto de coisas reais ou


abstratas que so reconhecidas como sendo do mesmo tipo por compartilhar as
mesmas caractersticas. A definio de classes inclui atributos e mtodos para
instncias podendo ser pensada como uma fbrica que cria instncias conforme
necessrio.
Um atributo representa uma propriedade que todos os objetos da classe tm,
a menor unidade que em si possui significncia prpria e apresenta um princpio
do armazenamento de valores em clulas. Um mtodo um corpo de procedimento,
ou seja, a implementao de uma operao.
Para poder representar a visibilidade dos atributos e operaes em uma
classe utilizase as seguintes marcas e significados:
- + pblico visvel em qualquer classe
- # protegido qualquer descendente pode usar
- privado visvel somente dentro da classe

60

Figura 3 Diagrama de classe de Anlise

A figura 3 apresenta o diagrama de classes do Porto Bello Palace Hotel.


Foram identificadas oito classes. Hotel, Pessoa, Hspede, Funcionrio, Reserva,
Hospedagem, Apartamento e Tipo Apartamento.

61

3.5

DIAGRAMA DE SEQNCIA

Um diagrama de seqncia um tipo de diagrama de interao que descreve


como os objetos colaboram em algum comportamento ao longo do tempo e registra
o comportamento de um nico caso de uso. Esse diagrama simples e lgico, com
o objetivo bvio a seqncia e o fluxo de controle.
Os diagramas de seqncia do nfase ordenao temporal das
mensagens mostrando uma viso cronologia de interao entre os
objetos que podem representar um cenrio de execuo ou vrios
possveis com bifurcaes ou laos. (BACAL, 2003, p. 26)

Os casos de uso vistos anteriormente representam conjunto de cenrios que


descrevem os diferentes processos que ocorrem no sistema. O diagrama de
seqncia permite modelar estes processos atravs da troca de mensagens
(eventos) entre os objetos do sistema.
Os objetos so representados por linhas verticais chamadas linhas de vida, e
as mensagens como setas que partem do objeto que invoca outro objeto. As setas
podem ser cheias para indicar uma mensagem de chamada ou tracejadas para
indicar uma mensagem de retorno.
Cada mensagem no diagrama de seqncia corresponde a uma operao no
diagrama de classes, como as mensagens so operaes invocadas, elas devem
estar presentes no objeto de destino, que so ativadas pelas mensagens no objeto
de origem.
Abaixo seguem os diagramas de seqncia do Porto Bello, onde se pode
observar que o tempo segue o eixo vertical de cima para baixo.

62

O Diagrama de Sequncia Cadastrar Funcionrio descreve os passos que


devem ser seguidos para efetuar o cadastro de funcionrios do Hotel. Atravs desse
diagrama o funcionrio cria-se tambm o login caso o funcionrio utilize o sistema.

Figura 4 Diagrama de seqncia Cadastrar Funcionrio

63

O Diagrama de Sequncia Cadastrar Hspede descreve os passos que


devem ser seguidos para efetuar o cadastro de Hspedes do Hotel. Atravs desse
diagrama gravam-se as preferncias do hspde se houver.

Figura 5 Diagrama de seqncia Cadastrar Hspede

64

O Diagrama de Sequncia Cadastrar Apartamento descreve os passos que


devem ser seguidos para efetuar o cadastro dos apartamentos do Hotel. Atravs
desse diagrama que classifica os quartos e suas caractersticas.

Figura 6 Diagrama de seqncia Cadastrar Apartamento

65

O Diagrama de Sequncia Manter Funcionrio descreve os passos que


devem ser seguidos para efetuar a Manuteno de dados do funcionrio do Hotel.

Figura 7 Diagrama de seqncia Manter Funcionrio

O Diagrama de Sequncia Manter Hspede descreve os passos que devem


ser seguidos para efetuar o cadastro de hspedes do Hotel. Atravs desse diagrama
66

permiti-se consultar hspedes j cadastrados e alterar dados necessrios.

Figura 8 Diagrama de seqncia Manter Hspede

O Diagrama de Sequncia Manter Apartamento descreve os passos que


67

devem ser seguidos para efetuar o cadastro dos apartamentos do Hotel. Atravs
desse diagrama permiti-se consultar hspedes j cadastrados e alterar dados
necessrios.

Figura 9 Diagrama de seqncia Manter Apartamento

68

O Diagrama de Sequncia Registrar Reserva descreve os passos que devem


ser seguidos para efetuar o Registro de reservas de apartamentos disponveis do
hotel.

Figura 10 Diagrama de seqncia Registrar Reserva

O Diagrama de Sequncia Consultar Reserva descreve os passos que devem


69

ser seguidos para consultar os dados de uma determinada reserva feita no hotel.

70

Figura 11 Diagrama de seqncia Consultar Reserva

O Diagrama de Sequncia Registrar Entrada por Reserva descreve os passos


que devem ser seguidos para efetuar a entrada do hspede atravs de uma reserva
efetuada no hotel.

Figura 12 Diagrama de seqncia Registrar Entrada por Reserva

71

O Diagrama de Sequncia Manter Registrar Entrada descreve os passos que


devem ser seguidos para alterar alguam informao referente ao Registro de
Hospedagem de um determinado hspede.

Figura 13 Diagrama de seqncia Manter Registrar Entrada

72

O Diagrama de Sequncia Registrar Sada descreve os passos que devem


ser seguidos para Sada do hspede no hotel.

Figura 14 Diagrama de seqncia Registrar Sada

O Diagrama de Sequncia Gerar Mapa de Acomodaes descreve os passos


73

que devem ser seguidos para gerar o relatrio contendo os apartamentos


disponveis, reservados e hospedados do hotel.

Figura 15 Diagrama de seqncia Gerar Mapa de Acomodaes

O Diagrama de Sequncia Efetuar Login descreve os passos que devem ser


seguidos para entrar no sistema.

74

Figura 16 Diagrama de seqncia EfetuarLogin

3.6

Classes de Anlise

As classes de anlise so utilizadas na obteno das principais classes que


compem o projeto desenvolvido, atravs de uma descrio textual dos Casos de
Uso buscase identificar as classes de anlise, as quais refletem as principais
abstraes do sistema.
As classes de anlise que o sistema composto dividemse de acordo com
suas responsabilidades em: classes de fronteira, classes de entidade e classes de
controle.

3.6.1 Classes de Fronteira

Uma classe de fronteira (Boundary Class) representa os resultados de uma


interao dos objetos internos, em algo que possa ser entendido pelo ator. Os
aspectos considerados so:
- Coordenao do comportamento do atores com os "aspectos internos" do
sistema;
- Recebimento de entradas (informaes ou requisies) provenientes do ator
para o sistema;
- Fornecimento de sadas (informaes armazenadas ou resultados derivados)
provenientes do sistema para o ator.
Estas classes so responsveis em fazer a interface com o usurio, ou seja,
fazem a interao com os usurios do sistema. No caso do nosso sistema as
classes de extenso JSP e as pginas de extenso HTML so as responsveis por
desempenhar essa funo. A figura 17 ilustra as classes de fronteira contidas neste
projeto

75

Figura 17 Classes de Fronteira

3.6.2 Classes de Entidade

A classe de entidade representa os conceitos do domnio do negcio cuja


informao e os comportamentos associados so, de maneira geral, persistentes
atravs de um arquivo ou banco de dados. As classes de entidade do sistema e
76

suas responsabilidades so:


-

PessoaBO: Classe genrica para todas as pessoas cadastradas no sistema,


tanto os funcionrios quanto aos hspedes. No banco as tabelas funcionrio e
cliente sero filhas da tabela pessoas que faz ligao classe Pessoas. As
informaes pertinentes a essa entidade so: nome da pessoa, registro geral
(RG), data de nascimento, endereo, cidade de residncia, unidade
federativa, cadastro de pessoa fsica (CPF), telefone de contato e email.

FuncionarioBO: Essa classe responsvel pelos dados dos funcionrios,


dados estes que sero armazenadas na tabela funcionario, e os campos
que persistiram alm dos referidos na classe Pessoa so: matricula do
funcionrio, data de admisso, cdigo e srie do CTPS, nmero do PIS, cargo
exercido e caso exista data da demisso.

HspedeBO: Classe responsvel pelas informaes pertinentes aos


hspedes do hotel que so: numero do cadastro e as preferncias do
hspede.

UsuarioBO: Nessa classe sero pertinentes informaes referentes ao


acesso dos funcionrios do hotel ao sistema. Tendo em vista que nem todos
os funcionrios tero o mesmo nvel de acesso ao sistema informaes como
nome de login, senha, status do usurio e grupo de acesso so necessrias
para o controle de acesso.

ReservaHospedagemBO: A classe hospedagem o corao do sistema,


pois tudo gira em torno dela. Os Casos de Uso Check In e Check Out juntos
fornecem todas a informaes necessrias para esta classe, sendo assim
nem todas as informaes so inseridas na tabela reserva_hospedagem, no
ato da insero no banco. As informaes pertinentes so: data de entrada e
data de sada (no caso de ser feita uma reserva antes da hospedagem), data
do check i e data do check out (em todos os casos, seja uma hospedagem
por reserva ou no), valor da hospedagem, valor d o desconto, valor da multa,
nmero do apartamento e status do apartamento.

ApartamentoBO: Na classe apartamento ficam registradas as informaes


referentes aos quartos existentes no hotel, como: andar do apartamento,
descrio do apartamento e tipo do apartamento.
77

TipoApartamentoBO: Informaes referentes aos diferentes tipos de


apartamentos como: descrio do tipo de apartamento e o valor da diria
desse tipo de apartamento.

3.6.3 Classes de Controle

As classes de controle so responsveis pela comunicao entre as classes


de fronteira e as classes de entidade e representa coordenao, seqncia,
transaes e controle de outros objetos.
Essas classes so utilizadas para encapsular controle relacionado a um ou
mais casos de uso e representam um processamento complexo (clculos envolvidos
na lgica de um processo de negcio) que no seja apropriado a uma classe de
entidade em particular. Suas principais caractersticas de controle so:
-

Criao, ativao e anulao objetos.

Controla a operao de objetos.

Controla a concorrncia de pedidos de objetos.

Trabalha somente com sinais (no com dados normais).

No sabe como fazer, mas sabe quem deve fazer (qual objeto controlado que
faz).
No projeto utilizouse a tecnologia Struts para o controle da aplicao. As

classes do Struts usadas na nossa aplicao foram:


-

ActionServlet: Essa classe obtm as requisies e as disponibiliza em um


ActionForm, e delega para o Action especfico.

3.6.4 Diagrama de Classe de Projeto

O diagrama de classes na fase de projeto deve especificar as classes de


software e as interfaces da aplicao, diferentemente do diagrama de classes da
fase de analise que considerado um diagrama de classes no modelo conceitual,
78

onde uma entidade no representa uma classe de software, mas um conceito do


domnio do problema.
Para construir um diagrama de classes na fase de projetos devese:
- Identificar todas as classes que participam da soluo em software, e inclu
las num diagrama de classes.
- Duplicar os atributos a partir das entidades associadas no modelo conceitual.
- Adicionar informao de tipo aos atributos e mtodos.
- Adicionar as associaes para indicar a direo da visibilidade de atributos.
- Adicionar linhas de relaes de dependncia para indicar a visibilidade que
no seja de atributo.
As associaes so necessrias somente para visibilidade de objetos,
diferentemente das associaes do modelo conceitual que so inseridas para
melhorar o entendimento.
Os diagramas de interaes so utilizados para descobrir a visibilidade,
associaes e navegabilidade do diagrama de classe.
Aps a definio das classes que vo ser utilizadas no diagrama, so
acrescentados alguns padres para alcanar o nvel de organizao.
O diagrama da figura 18 mostra uma viso macro de todo o sistema
permitindo a viso da organizao do mesmo em pacotes:

79

Figura 18 Diagrama de Pacotes

Abaixo seguem os diagramas de classe na fase de projeto divididos em


interaes para que uma seqncia lgica seja estabelecida.

80

Figura 19 Diagrama de Classes Atualizar Apartamento

81

Figura 20 Diagrama de Classes Buscar Apartamento

82

Figura 21 Diagrama de Classes Cadastrar Apartamento

83

Figura 22 Diagrama de Classes Cadastar Reserva/Hospedagem

84

Figura 23 Diagrama de Classes Atualizar Hospede

85

Figura 24 Diagrama de Classes Buscar Funcionrio

86

Figura 25 Diagrama de Classes Buscar Hspede

87

Figura 26 Diagrama de Classes Cadastrar Funcionrio

88

Figura 27 Diagrama de Classes Cadastrar Hspede

89

Figura 28 Diagrama de Classes Excluir Funcionrio

90

Figura 29 Diagrama de Classes Excluir Hspede

91

Figura 30 Diagrama de Classes Consultar Reserva Hospedagem

92

Figura 31 Diagrama de Classes Excluir Apartamento

93

4.1

ESTRUTURA E CDIGO

Arquitetura

Desde sua criao, o desenvolvimento de sistemas tem lidado com


problemas associados com a complexidade da informao. Os primeiros problemas
de complexidade foram resolvidos pelos desenvolvedores atravs da escolha da
estrutura de dados, do desenvolvimento de algoritmos e pela aplicao de conceitos
de separao de escopos.
Embora o significado de arquitetura seja relativamente amplo, os princpios
fundamentais deste campo vm sendo aplicados esporadicamente pela engenharia
de software desde o incio dos anos 80. As primeiras tentativas de capturar e
explicar a arquitetura de software de sistema foram imprecisas e desorganizadas,
freqentemente caracterizadas por um conjunto de diagramas.
A Arquitetura de Software de um sistema consiste dos componentes de
software, propriedades externas, e seus relacionamentos com outros
softwares. O termo tambm se refere documentao da arquitetura de
software do sistema. A documentao facilita a comunicao entre os
stakeholders, registra as decises iniciais acerca do projeto de alto-nvel, e
permite o reuso do projeto dos componentes e padres entre projetos.
(http://pt.wikipedia.org/wiki/Arquitetura_de_software)

Durante o decorrer da dcada de 90, houve um esforo concentrado para


definir e codificar os aspectos fundamentais sobre arquitetura. Inicialmente, um
conjunto de padres de projeto, estilo, melhores prticas, descrio de linguagens, e
lgica formal foi desenvolvido durante este perodo. Com base nesses estudos
feitos, a fim de encontrar uma melhor prtica para a elaborao de sistemas e
desenvolver um software da forma que o cliente necessita, foram criados padres de
projetos que auxiliam nesse desenvolvimento com a finalidade de simplificar a
codificao com base na solicitao do cliente.
Porm, para desenvolver um software com qualidade, necessrio entender
o que o cliente quer, de tal forma que sua perspectiva esteja de acordo com a forma
no qual a arquitetura foi aplicada. Este caso envolve um paradigma de programao
orientada a objetos ou POO (Programao Orientada a Objetos) ou do ingls OOP
94

(Object Oriented Programmimg), que se baseia em identificar os objetos fornecidos


no levantamento feito com o cliente e aplicar esses objetos no software a ser criado,
mantendo assim um comportamento semelhante e funcional conforme os requisitos
dessa aplicao.
O

desenvolvimento da

aplicao do Porto

Bello

Palace

Hotel foi

implementado na linguagem JAVA baseado para a web (JAVA EE Java Enterprise


Edition), utilizando os frameworks Struts, Hibernate e Tiles.

4.2

JAVA EE Java Enterprise Edition

Segundo Alur, Crupi e Malks (2004), a plataforma JAVA EE est designada


para desenvolvimento de solues empresariais para sistemas distribudos.
J2EE uma plataforma para desenvolvimento de aplicativos empresariais
distribudos. A linguagem Java, desde sua implementao, teve uma grande
aceitao e crescimento. Mais e mais tecnologias para atender a vrias
necessidades. Eventualmente, a Sun e um grupo de lderes da indstria,
sob o s auspcios do Java Community Process (JCP) aberto, unificaram
todos os padres e APIs relativos a empresas na plataforma J2EE. (ALUR,
CRUPI & MALKS, 2004)

Os Design Patterns, solues para problemas cotidianos, foram elaborados


por arquitetos de software e orientao a objetos. O objetivo era de tornar mais
eficiente o desenvolvimento de um software e assim poupar os demais
desenvolvedores de "reinventar a roda" toda vez que se deparassem com um
problema.
Entendese, mediante a obra dos autores Alur, Crupi e Malks (2004), que,
com a demanda da criao de aplicaes distribudas, cada vez mais empresas
procuravam criar sua prpria maneira de resolver esses problemas. Com isso, um
grupo de arquitetos pensou nas situaes mais relevantes no cenrio coorporativo e,
baseado na necessidade de segurana/escalabilidade, esses arquitetos fizeram um
documento por escrito que se tornou a primeira especificao do JAVA EE.
Os padres se referem comunicao de problemas e solues. Em outras
palavras, os padres permitem documentar um problema conhecido
recorrente e sua soluo em um contexto especfico e comunicar esse
conhecimento para outras pessoas. M dos elementoschave na declarao

95

anterior a palavra recorrente, visto que a meta do padro promover uma


reutilizao do conceitual ao longo do tempo. (ALUR, CRUPI & MALKS,
2004)

No incio, o desenvolvimento na especificao JAVA EE era muito


complicado, mas, com o tempo, vrias mudanas foram acontecendo e se tornou
uma tecnologia difundida e muito utilizada em todo o mundo.
A especificao prega as seguintes caractersticas:
Alta Disponibilidade: Aplicaes para misses crticas, aplicaes que no
podem parar, servios que tm que estar funcionando 24 horas por dia, 7 dias
por semana;
Segurana: Os dados devem estar muito bem protegidos, tanto em relao
privacidade dos usurios, quanto segurana das informaes do "negcio";
Confivel: Confivel se enquadra no princpio de ser SEGURA e
DISPONVEL, ou seja, uma aplicao na qual voc pode confiar (pois sempre
vai funcionar quando voc precisa e suas informaes estaro seguras com
ela);
Escalvel: Uma aplicao que cresce seguindo a demanda do seu negcio.
Isso quer dizer que, teoricamente, voc poderia comear com uma aplicao
"pequena" e, conforme a necessidade fosse surgindo, bastaria voc adicionar
mais "mquinas/recursos" para suportar a demanda.

96

Figura 32 JAVA EE Diagrama da Arquitetura

Aprofundando no JAVA EE e observando o diagrama da arquitetura (Figura


63), notase que essa especificao foi criada baseada em outra especificao do
JAVA, a Java SE (Java Standart Edition), ou seja, o padro JAVA EE uma forma
de se utilizar o padro JSE que contempla as APIs de funcionamento bsicas do
JAVA aplicado para a WEB.

4.3

Camadas e MVC

Para que esta aplicao fosse desenvolvida mantendo sustentao para


novas funcionalidades e, ainda, com um cdigo mais organizado e fcil de entender,
a arquitetura aplicada no desenvolvimento desse sistema foi o MVC (Modelview
controller). De acordo com Macoratti (2003),

A arquitetura MVC (Modelo Visualizao Controle) fornece uma maneira de

97

dividir a funcionalidade envolvida na manuteno e apresentao dos dados


de uma aplicao. A arquitetura MVC no nova e foi originalmente
desenvolvida para mapear as tarefas tradicionais de entrada,
processamento e sada para o modelo de interao com o usurio.
(MACORATTI, 2003)

Arquitetura em camadas um padro de arquitetura de software, que define


os componentes da aplicao em camadas (Camada de Negcio, Apresentao e
Controle). O conceito de MVC aplicase s camadas, assim separadas, atribuindo
responsabilidades a elas.
A arquitetura de camadas utilizada em uma aplicao para manter os
componentes separados por responsabilidade, diminuindo o acoplamento entre
esses componentes, fazendo com que no haja impacto em mudanas decorrentes
na aplicao. A figura 64 exemplifica um exemplo de uma estrutura sem separao
lgica:

Figura 33 Diagrama sem nenhuma separao lgica

98

A figura 65 mostra como ficaria uma estrutura com uma separao lgica
definida.

Figura 34 Componentes agrupados

O padro MVC divide a aplicao em 3 vises (ModemViewController), no


momento em que os componentes da nossa aplicao so organizados, o conceito
de MVC aplicado nesses agrupamentos, no qual a camada de negcios fica como
o Model, a camada de apresentao como a View, e a camada de controle fica
sendo definida na camada de apresentao, agindo como um meio de
comunicao com o negcio.

4.4

STRUTS

Dentre os frameworks disponveis para desenvolvimento de aplicaes web,


utilizando a linguagem Java, o que se destaca o Struts. Este framework se aplica
fortemente sob a arquitetura JAVA EE.
Struts uma camada de controle flexvel baseada na avanada tecnologia de
Java Servlets, JavaBeans, ResourcesBundles e XML, assim como vrios pacotes
99

Apache Commons, como BeanUtils e Chain of Responsibility. O framework ajuda a


criar um ambiente de desenvolvimento extensvel para sua aplicao, baseado em
normas e padres de projeto.
De acordo com a obra de Husted (2004), percebese que o uso desse padro
fundamental para prevenir o aumento da complexidade da aplicao. Desta forma,
os dados e a viso ficam separados de forma que no haja manipulao entre os
dados dessas camadas, ou seja, as mudanas que precisarem ser feitas na parte de
dados da aplicao podem ser feitas sem a preocupao de ocorrer alteraes
indevidas nas demais camadas, e viceversa.
Ao elevar as estruturas fsicas, os engenheiros da construo usam
suportes para fornecer sustentao para cada piso de um prdio. Do
mesmo modo, os engenheiros do software usam o Struts para suportar
cada camada de uma aplicao comercial. (HUSTED, 2004)

Utilizando o Struts no desenvolvimento da aplicao do Porto Belo Palace


Hotel, a implementao do sistema foi simplificada com os recursos desse
framework, pois utiliza, alm de servlets, outros design patterns (Front Controller,
Command, Adapter) que beneficiam ainda mais o desenvolvedor, tais como:
1. Redirecionar todas as requisies para um nico ponto.
2. Extrair e validar informaes contidas nas requisies.
3. Mapear as requisies para as suas respectivas atividades.
4. Redirecionar dados e contedo para suas respectivas pginas.
5. Tratar eventuais excees.
O Struts implementado como controle da aplicao, responsvel por
receber todas as requisies e passar para a camada de negcios, executar as
regras e, devido a popularidade das aplicaes web, requisitos foram adicionados
para tornar simples esse mecanismo de request e response. Na figura 66, o
diagrama mostra com clareza este fluxo:

100

Figura 35 Como o Struts implementa o MVC

A classe ActionServlet vai atuar como o FrontController, responsvel por


receber a requisio enviada pelo cliente (http://localhost:8080/projeto/acao.do).
Uma leitura do web.xml (quadro 58) ser feita, a fim de encontrar a ao especfica
e invocar a respectiva solicitao.
Para o desenvolvimento, a classe ActionServlet atua como FrontController do
Struts, sendo necessrio configurla no arquivo web.xml do projeto, conforme o
quadro 58.

<servlet>
<servletname>action</servletname>
<servletclass>org.apache.struts.action.ActionServlet</servletclass>

<! Struts Initiate Parameter >


<initparam>
<paramname>config</paramname>
<paramvalue>/WEBINF/strutsconfig.xml</paramvalue>
</initparam>

<initparam>
<paramname>chainConfig</paramname>
<paramvalue>org/apache/struts/tiles/chainconfig.xml</paramvalue>
</initparam>

<loadonstartup>1</loadonstartup>
</servlet>

101

<! Standard Action Servlet Mapping >


<servletmapping>
<servletname>action</servletname>
<urlpattern>*.do</urlpattern>
</servletmapping>

Quadro 27 Arquivo web.xml

ActionServlet

funciona

recebendo

requisio,

tendo

como

responsabilidade tambm extrair os parmetros para instanciar um ActionForm.


Para os domains (ou beans) utilizados no projeto do sistema do Porto Bello,
aplicado o uso do ActionForm, que trabalha juntamente com o ActionServlet para
receber os valores dos respectivos atributos de determinado domain.
O termo domain significa domnio de uma entidade como, por exemplo, para
uma tela de cadastro de cliente, na qual cada campo representa um atributo do
mesmo, existe um domnio que ir conter os atributos de um cliente, que ser o
objeto do negcio. O uso do ActionServlet aplicado ao recebimento da requisio e
do ActionForm aplicado ao domain, implica na validao dos atributos, ou seja, o
ActionServlet ir receber a requisio contendo os valores informados no formulrio,
e ir extrair os parmetros da requisio e popular um domain aplicado pelo
ActionForm, formando, assim, o objeto cliente populado com as informaes
fornecidas na tela.
Para cada requisio feita pelo usurio, uma Action executada, e o
processo de criao do objeto por meio do ActionForm executado caso solicitado e
o objeto montado e enviado para continuar o processo de acordo com as regras.
As Actions representam as aes que sero feitas na aplicao, aes como
salvar, listar, excluir, etc, sendo elas invocadas atravs de submits, nos quais so
informadas essas aes, como por exemplo:
salvarApartamento.do
listarHospedes.do
excluirFuncionario.do
A ao de salvar apartamento demonstrada no diagrama de sequncia a

102

nvel de projeto conforme mostra a figura:

Figura Diagrama de sequncia cadastrar apartamento (projeto)


Aps receber a solicitao (exemploAcao.do), o ActionServlet ir recuperar
essa ao no arquivo de configuraes. As informaes vindas do cliente sero
encaminhadas para a respectiva ao atravs de um request (ou como sendo um
FormBean). A partir desta ao, o modelo do negcio ser acessado e a informao
ser processada ou salva no banco. Para encerramento desta ao, ser feito um
actionForward, que representlaa o mecanismo (JSP, HTML) que ir apresentar o
resultado para o cliente. (Quadro 59):

<action path="/jsp/addApartamento"
type="bello.porto.action.ApartamentoAction"
name="ApartamentoForm"
scope="request"
input="tiles.apartamento.form"
validate="true"
parameter="acao" >
<forward name="cadastraApart" path="tiles.apartamento.form" />
</action>

103

Quadro 28 Ao para adicionar apartamento

A classe que ser a ao informada ir estender a classe Action do Struts, e


possui o mtodo execute (argumentos), que dever ser sobrescrito (Quadro 60):
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception {
Apartamento apart = new Apartamento();
apart = (Apartamento) form;
apartB.addApartamento(apart);
return mapping.findForward("cadastraApart");
}

Quadro 29 Mtodo execute para a ao de cadastrar apartamento

A partir da (funo) Action, o objeto recebido ser manipulado pelas regras da


aplicao e persistido no banco, se for o caso.
O mapeamento de todas essas actions ficam no arquivo denominado struts
config.xml. Dentro desse arquivo de configuraes do Struts ficam, como principais,
os:
1. ActionForms;
2. ActionForwards;
3. ActionMapping.
As requisies passam por esse xml para poder prosseguir com o fluxo. Ver
figura 67:

104

Figura 36 Fluxo Struts

A figura 67 descreve desde o incio da requisio, todos os passos, at o seu


trmino.
A princpio, o usurio em seu navegador acessando uma tela de cadastro,
seleciona a opo cadastro de apartamento, por exemplo, preenche os campos com
as informaes solicitadas, e faz um submit. Em seguida, o controller acionado e
invoca o ActionServlet, que chama o arquivo de configurao do Struts (struts
config.xml), que procura pela ao solicitada pelo usurio. Com isso, as
configuraes so montadas de acordo com a action que foi solicitada na requisio,
neste momento o Struts j sabe qual classe vai ser acessada, qual domain ser
populado e devolve essas informaes para o ActionServlet que vai executar. Com
isso, o domain ser populado e enviado para a classe da respectiva ao que ter o
mtodo execute que ser acessado e executado. A partir desse momento, o objeto,
j montado, ir passar pela camada de negcio da aplicao, tendo todas as regras
executadas e persistidas no banco.

4.5

HIBERNATE

105

Ao interagir com um banco de dados relacional, o uso do Hibernate pode


facilitar muito no que diz respeito clareza e objetividade do cdigo. Ao invs de
criar trechos em SQL para manipular objetos, o Hibernate trata esses objetos como
sendo suas respectivas tabelas, facilitando o manuseio da persistncia da aplicao,
assim como a manuteno.
O Hibernate um framework para o mapeamento objetorelacional
escrito na linguagem Java, mas tambm disponvel em .Net com o
nome NHibernate. Este programa facilita o mapeamento dos
atributos entre uma base tradicional de dados relacionais e o modelo
objeto de uma aplicao, mediante o uso de arquivos (XML) para
estabelecer esta relao. (http://pt.wikipedia.org/wiki/Hibernate)

Persistncia um termo raramente utilizado no contexto de dados,


preferencialmente, o termo banco de dados. A funo do sistema na parte de
gerenciamento de dados, ou camada de persistncia, permitir o acesso e a
atualizao simultneos de dados persistidos, ou seja, a fim de garantilos a um
longo prazo.
Na aplicao do Porto Bello, foi usado na camada de persistncia com o
padro de projeto Data Access Object (DAO), que se trata de um modelo para
persistir dados em banco de dados relacionais. Esse padro mantm separadas as
regras do negcio do Porto Bello das regras de acesso ao banco de dados, no caso
dessa aplicao que utiliza o MVC.
Na utilizao desse padro de projeto, foi usado o Hibernate como
mecanismo de persistncia. O uso do Hibernate permite persistir dados relacionais
de maneira transparente, utilizandose de arquivos xml (os HBM) para mapear os
atributos dos nossos domains com os atributos das tabelas no banco de dados.
Muitas tentativas foram feitas para interligar as tecnologias
relacionais e orientadas para objeto, ou para substituir uma pela
outra, mas o abismo entre ambas um dos fatores intrincados da
computao corporativa hoje em dia. este desafio fornecer uma
ponte entre dados relacionais e objetos Java que o hibernate
assume atravs de sua abordagem do mapeamento objeto/relacional
(ORM). O Hibernate enfrenta este desafio de uma maneira
pragmtica, direta e realista. (CHRISTIAN BAUER, 2005)

A simplicidade do uso do hibernate evita a perda de tempo escrevendo SQL e


misturar com o cdigo Java, fazendo com que a preocupao seja toda voltada
106

somente para os objetos do negcio, ou domains. Os passos utilizados na utilizao


do Hibernate no sistema do Porto Bello so:
Criao das tabelas no banco, onde os dados iro persistir.
Criao dos objetos de negcio, tais objetos que tero seu estado persistido
nas suas respectivas tabelas.
Criao dos arquivos HMB, utilizado para relacionar as propriedades do
objeto aos campos da tabela.
Criao do arquivo de configuraes do hibernate, responsvel por manter os
dados da conexo e quais objetos estaro disponveis no mapeamento.
Criao da classe DAO que ir conter as propriedades para que o acesso ao
banco seja realizado.

Figura 37 Diagrama do fluxo do Hibernate

A utilizao do Hibernate consiste em ter um objeto para cada tabela do


banco, entretanto, haver um arquivo que funcionar com mecanismo responsvel
pelo mapeamento das propriedades do objeto com os campos da tabela. Este
arquivo chamado de HBM (SeuObjeto.hbm.xml).
Esse arquivo de mapeamento contm tags que interpretam as propriedades
do objeto, e define a configurao com base no tipo do dado do objeto e do campo
107

da tabela. Com todo esse arquivo montado, a persistncia do objeto mapeado com
sua respectiva tabela, a persistncia desse objeto j fica automtica, evitando que o
resultado de uma busca ou a preparao de uma insero fosse feita manualmente
e sujeita a erros.
O objeto Apartamento possui seus atributos e tambm um arquivo HBM
(Apartamento.hbm.xml). O mapeamento foi feito e adicionado nas configuraes do
Hibernate para estar disponvel para uso.
O mapeamento HBM define todas as caractersticas de uma tabela, desde o
ID que a chave primria, at os relacionamentos existentes. Com esses arquivos
criados, o DAO ter apenas que informar qual objeto ir ser persistido e invocar
mtodos j prontos para executar as aes (salvar, buscar, excluir, etc).

package bello.porto.dao;

import java.util.Iterator;
import java.util.List;

import org.hibernate.HibernateException;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.Transaction;

import bello.porto.beans.Apartamento;

public class ApartamentoDAO {

protected Session session;


protected Transaction tx;
private static List<Apartamento> apartamentos;

public ApartamentoDAO() throws HibernateException {


HibernateFactory.buildSessionFactory();
}

public Session getSession() {


return session;
}

108

public Transaction getTx() {


return tx;
}

public void salvar(Apartamento obj){


try {
session = HibernateFactory.openSession();
tx = session.beginTransaction();
session.save(obj);
tx.commit();
} catch (HibernateException e){
HibernateFactory.rollback(tx);
} finally {
HibernateFactory.close(session);
}
}

@SuppressWarnings("unchecked")
public Apartamento localizar(int id){

Apartamento apart = null;


Iterator iter = apartamentos.iterator();

while(iter.hasNext()){
apart = (Apartamento) iter.next();
if(apart.getIdApartamentoNum() == id){
break;
}
}
return apart;
}

@SuppressWarnings("unchecked")
public List localizarTodos(Class clazz){
List objs = null;
try {
session = HibernateFactory.openSession();
tx = session.beginTransaction();
Query q = session.createQuery("from " + clazz.getName());
objs = q.list();
tx.commit();
} catch (HibernateException e) {
HibernateFactory.rollback(tx);

109

} finally {
HibernateFactory.close(session);
}
return objs;
}

@SuppressWarnings("unchecked")
public void remover(Apartamento obj) {
try {
session = HibernateFactory.openSession();
tx = session.beginTransaction();
session.delete(obj);
tx.commit();
} catch (HibernateException e) {
HibernateFactory.rollback(tx);
} finally {
HibernateFactory.close(session);
}
}

public void salvarOuAtualizar(Apartamento obj) {


try {
session = HibernateFactory.openSession();
tx = session.beginTransaction();
session.saveOrUpdate(obj);
tx.commit();
} catch (HibernateException e) {
HibernateFactory.rollback(tx);
} finally {
HibernateFactory.close(session);
}
}

public void handleException(HibernateException e){


HibernateFactory.rollback(tx);
return;
}
}

Quadro 30 Classe DAO ApartamentoDAO.java

Os mtodos da classe (Quadro 61), no caso da aplicao do Porto Bello, so


110

especficos para o objeto referente ao apartamento. Cada mtodo recebe um objeto


do tipo Apartamento e invoca os mtodos do Hibernate para continuar com a
persistncia.
Esse cdigo abre a sesso com o banco e inicia uma transao, onde ir ser
feita a ao especfica (Quadro 62). So eles:

session = HibernateFactory.openSession();
tx = session.beginTransaction();
Quadro 31 Abre sesso com o banco de dados

Em seguida, atravs desses mtodos que o objeto manipulado, que pode


ser:
a) Salvar:
session.save(obj);
Quadro 32 Salva determinado objeto no banco

b) Remover:
session.delete(obj);
Quadro 33 Remove determinado objeto do banco

c) Atualizar (neste caso, salvar ou atualizar):


session.saveOrUpdate(obj);
Quadro 34 Salva ou atualiza determinado objeto no banco de dados

d) Somente atualizar:
session.update(obj);
Quadro 35 Apenas atualiza determinado objeto no banco de dados

Ou criando uma query que retorna todos os valores e gerando uma lista de
objetos:
111

Query q = session.createQuery("from " + clazz.getName());


objs = q.list();
Quadro 36 Retorna vrios objetos do banco numa lista

Agora, para que esse mapeamento fique disponvel para uso, devemos
configurar o arquivo (Quadro 51) de configuraes (hibernate.cfg.xml):

<?xml version="1.0" encoding="UTF8"?>


<!DOCTYPE hibernateconfiguration PUBLIC
"//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernateconfiguration3.0.dtd">
<hibernateconfiguration>
<sessionfactory>
<property
name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.password">lucas</property>
<property
name="hibernate.connection.url">jdbc:mysql://localhost:3306/portobello</property>
<property name="hibernate.connection.username">root</property>
<property
name="hibernate.dialect">org.hibernate.dialect.DB2Dialect</property>

<mapping resource="bello/porto/dao/Funcionario.hbm.xml" />


<mapping resource="bello/porto/dao/Grupo.hbm.xml" />
<mapping resource="bello/porto/dao/Hospede.hbm.xml" />
<mapping resource="bello/porto/dao/Usuario.hbm.xml" />
<mapping resource="bello/porto/dao/ReservaHospedagem.hbm.xml" />
<mapping resource="bello/porto/dao/Apartamento.hbm.xml" />
<mapping resource="bello/porto/dao/Pessoa.hbm.xml" />
<mapping resource="bello/porto/dao/TipoApartamento.hbm.xml" />

</sessionfactory>
</hibernateconfiguration>

Quadro 37 Arquivo de configuraes hibernate.cfg.xml

Quando o mapeamento criado, ele deve ser adicionado nesse arquivo para
que possa ser usado na nossa camada de persistncia por um DAO.
112

A aplicao se tornou mais fcil de desenvolver com o uso dessas


tecnologias (frameworks), mantendo um cdigo com lgica separada e simplicidade
na codificao, resultando em uma manutenibilidade mais fcil.

113

5.1

PROJETO DE INTERFACES

Regra do Click

A web o ambiente no qual o poder do cliente se manifesta no mais alto grau


seguindo a regra do click: quem faz o click faz as regras. Na economia de rede, o
website tornase a principal interface da empresa com o cliente. Na verdade, para
empresas de comrcio eletrnico, o site a empresa.

Dr. Jakob Nielsen

importante engenheiro da Sun Microsystems (at 1998), guru de usabilidade na Web


e detentor de 38 patentes nos Estados Unidos (principalmente de formas de facilitar
o uso na internet) argumenta que:
[...] A interface com o usurio tornase os materiais de marketing, a
vitrine, o interior da loja, a equipe de vendas e o suporte psvenda,
tudo em um s pacote. Em muitos casos, o site tornase at mesmo
o produto em si. Portanto ter uma m usabilidade como ter uma
loja que fica no dcimostimo andar de um prdio (e, portanto,
ningum pode ir) e no tem nada alm de vendedores mal
humorados que no falam com os clientes (e, portanto, as pessoas
no compram muito) (NIELSEN, 2000).

Joel Spolsky, exprogramador e gerente na Microsoft, na Viacom e no Juno e


fundador da Fog Creek Software (Nova York) confirma a teoria com o axioma de
maior importncia de todos os projetistas de interfaces com usurios: uma interface
de usurio bem projetada quando o programa se comporta exatamente como o
usurio pensa que ele se comportaria (SPOLSKY, 2000). Geralmente os usurios
julgam um sistema pela sua interface ao invs de sua funcionalidade, um projeto de
interface mal elaborado pode levar o usurio a cometer erros catastrficos. Um
projeto de interface pobre uma das razes pela qual muitos sistemas de software
nunca foram utilizados.
Um dos maiores desafios hoje projetar interfaces efetivas para sistemas de
software com o objetivo de ajudar o usurio a obter acesso rpido ao contedo de
sistemas complexos. Uma web com padres resolve estes problemas.

114

5.2

Toda histria tem um comeo

[...] Onde devo comear, por favor vossa majestade? Comece do


comeo, disse bravo o rei, e v at chegar ao fim: ento pare.[...]
(Lewis Caroll Alice no pas das maravilhas)

5.2.1 O nascimento da Internet

No final de outubro de 1957 a Unio Sovitica chocou o planeta e


principalmente os Estados Unidos ao lanar com sucesso o primeiro satlite na
rbita da Terra chamado Sputnik 1. Os Estados Unidos tinha seu prprio programa
de lanamento de satlites, mas ainda no havia lanado. Este evento levou
diretamente criao da ARPA (Agncia de Projetos de Pesquisa Avanada) do
Departamento de Defesa dos Estados Unidos.
Em 1960, o psiclogo e cientista de computao Joseph Licklider publicou um
documento intitulado Relao HomemComputador, que articulava a idia de
computadores em rede fornecendo armazenamento e consulta de informaes. Em
1962, ao mesmo tempo em que trabalhava para a ARPA como o chefe do escritrio
de processamento de informao, ele formou um grupo para futuramente fazer
pesquisas com computadores, mas deixou o grupo antes que qualquer trabalho
sobre a idia tivesse sido feito. O plano para esta rede de computadores (chamada
ARPANET) foi apresentado em outubro de 1967, e em dezembro de 1969 a
primeira rede de quatro computadores estava pronta e funcionando. O grande
problema em criar uma rede era como conectar redes fsicas separadas sem que as
ligaes aumentassem os recursos de rede para links constantes. A tcnica que
solucionou este problema conhecida como troca de pacotes e envolve requisies
de dados sendo divididos em pequenos pedaos (pacotes), que podem ser
processados rapidamente sem bloquear a comunicao de outras partes esta
tcnica usada para o funcionamento da Internet hoje. Este conceito recebeu
grande adoo, com o surgimento de vrias outras redes usando a mesma tcnica
de troca de pacotes.
A proliferao de diferentes protocolos de rede logo se tornou um problema,
115

quando se tentava fazer todas as redes separadas se comunicarem. Robert Kahn,


enquanto trabalhava em um projeto de pacotes de rede de satlite para a ARPA,
comeou a definir algumas regras para uma arquitetura de rede mais aberta para
substituir o protocolo atual usado na ARPANET. Mais tarde, com a chegada de
Vinton Cerf da Universidade de Stanford, os dois criaram um sistema que mascara a
diferena entre os protocolos de rede usando um novo padro. Na publicao do
rascunho da especificao em dezembro de 1974, eles o chamaram de ITCP
Internet Transmission Control Program (Programa de Controle de Transmisso
Entreredes).
Esta especificao reduziu o papel da rede e transferiu a responsabilidade de
manter a integridade da transmisso para o computador servidor possibilitando o
acesso com facilidade a quase todas as redes simultaneamente. A ARPA financiou o
desenvolvimento do software e em 1977 foi conduzida uma demonstrao de uma
comunicao entre trs redes diferentes. Em 1981, a especificao foi finalizada,
publicada e adotada e em 1982 as conexes da ARPANET fora dos EUA foram
convertidas para usar um novo protocolo chamado TCP/IP. Assim nasceu a Internet.

5.2.2 A criao da World Wide Web

No incio dos anos 90 surgiu um sistema (criado pela Universidade de


Minnesota) de recuperao de informao chamado Gopher que oferecia um
mtodo de entrega de menus de links para arquivos, recursos de computadores e
outros menus. Estes menus puderam atravessar as fronteiras da computao da
poca e usar a Internet para obter menus de outros sistemas. Eles foram muito
populares com universidades que buscavam oferecer informao dentro do campus
e grandes empresas procurando centralizar o armazenamento e gerenciamento de
documentos. No incio do ano de 1993 muitas empresas comearam a buscar
alternativas ao Gopher devido incio de cobrana de taxas de licena pelo uso de
sua referncia de implementao do servidor Gopher.
A CERN (Organizao Europeia para Investigao Nuclear), na Suia, tinha
uma alternativa atravs de Tim BernersLee que estava trabalhando em um sistema
116

de gerenciamento de informao, no qual um texto poderia conter links e referncias


para outros trabalhos, permitindo o leitor a pular rapidamente de um documento para
outro. Ele havia criado um servidor para publicar este tipo de documento (chamado
hipertexto) bem como um programa para llo, que ele havia chamado de
WorldWideWeb. Este software foi lanado em 1991, entretanto, ele teve dois
eventos que causaram sua exploso em popularidade e a eventual substituio do
Gopher.
Em 20 de Abril de 1993 o CERN lanou o cdigofonte do WorldWideWeb em
domnio pblico, ento qualquer um poderia usar ou construir algo sobre o software
sem nenhuma taxa.
Ento, mais tarde no mesmo ano, o NCSA (Centro Nacional de Aplicaes de
Supercomputao) lanou um programa que combinava um navegador web e um
cliente Gopher, chamado Mosaic. Ele estava disponvel originalmente apenas para
mquinas Unix e em forma de cdigofonte, mas em dezembro de 1993 saiu uma
nova verso do Mosaic que podia ser instalada em Apple Macintosh e Microsoft
Windows. O Mosaic viu sua popularidade aumentar rapidamente, e junto com ele a
Web. Tambm o nmero de navegadores disponveis aumentou drasticamente,
muitos criados por projetos de pesquisa em universidades e empresas.

5.2.3 A Guerra dos Browsers

A popularizao da web trouxe interesses comerciais. Marc Andreessen


deixou a NCSA e junto com Jim Clark fundou a Mosaic Communications, depois
renomeada para Netscape Communications Corporation, e comeou a trabalhar no
que viria a ser o Netscape Navigator. A verso 1.0 do software foi lanada em
dezembro de 1994. Neste mesmo ano a Telenor (uma empresa de comunicaes
Noroeguesa) criou a primeira verso do navegador Opera. A Spyglass Inc. (o brao
comercial da NCSA) licenciou sua tecnologia do Mosaic para a Microsoft formar a
base do Internet Explorer. A verso 1.0 foi lanada em agosto de 1995. Em uma
rpida escalada, a Netscape e a Microsoft tentaram cada qual obter uma margem
competitiva em termos de recursos suportados, a fim de atrarem desenvolvedores.
Isto ficou reconhecida como a Guerra dos Browsers.

117

5.2.4 A web sem padres

No perodo da guerra dos navegadores, Microsoft e Netscape estiveram


focadas em implementar novas funes em vez de consertar os problemas com as
funes j suportadas, e adicionaram funes proprietrias e criaram funes que
competiam diretamente com funes existentes no outro navegador, mas
implementadas

de

uma

forma

incompatvel.

Como

conseqncia

os

desenvolvedores foram forados a lidar com o crescente aumento do nvel de


confuso enquanto tentavam criar web sites, as vezes chegando ao ponto de
construir dois sites diferentes para os navegadores principais, e outras vezes
escolhendo suportar apenas um navegador, e bloqueando os outros de usarem seus
sites.
Com o crescimento do comrcio na Web (ecomerce) veio a necessidade de
publicao de contedo diagramado, como jornais, revistas, catlogos e assim por
diante, a linguagem HTML (por no possui estes recursos) foi adaptada, infelizmente
nesta fase foi esquecido a qualidade do cdigo e somente houve preocupao
unicamente visual.
Por volta de 1996 surgiram editores HTML WYSIWYG como Go Live, Front
Page e Dreamweaver. Editores HTML WYSIWYG (do ingls "What You See Is What
You Get" ou em portugus O que voc v o que voc tem") so programas que
permitem ter a visualizao final de um documento, enquanto o mesmo editado. A
edio do arquivo pode ser feito por cdigo ou por design. No modo design, uma
pessoa com pouco experincia (ou nenhuma) em programao pode criar uma
pgina ou mesmo um site. Entretanto o cdigo gerado pelo editor visual blackcode
(cdigo sujo) com scripts complexos (vrias linhas de cdigo) para funes simples
de pouca codificao.
No mercado apareceram vrios cursos e profissionais desatualizados e sem
experincia, como conseqncia as pginas geradas eram um incompreensvel
emaranhado de tags com tabelas, formataes, scripts e assim por diante e tudo
bem maior que o necessrio. E o problema aumentou quando a codificao da
apresentao da pgina foi desenvolvida com tabelas com bordas ocultas (border =
0), imagens invisveis (spacers.gif) e misturado o cdigo da apresentao com o
cdigo da estrutura. Na necessidade de alterao no site era preciso alterar todos os
118

arquivos, isto um a um. O resultado de tudo isso foi uma web sem padres.

5.2.5 A formao da W3C

Em 1994, Tim BernersLee fundou o World Wide Web Consortium (W3C), no


Instituto de Tecnologia de Massachusetts, com suporte do CERN, DARPA (como foi
renomeada a ARPA) e da Comisso Europeia. A viso da W3C era a de padronizar
os protocolos e tecnologias usados para criar a web de modo que o contedo possa
ser acessado largamente pela populao mundial tanto quanto o possvel. Nos anos
seguintes o W3C publicou vrias especificaes (chamadas recomendaes)
incluindo o HTML, o formato de imagens PNG, e as Folhas de Estilo em Cascata
(CSS 1 e CSS 2).
Apesar dos principais browsers terem sido envolvidos na criao de pades
web desde a formao do W3C, durante muitos anos o seguimento dessas regras
no era obrigatrio, os fabricantes adotavam os documentos da W3C apenas se
eles quizessem etiquetar que seus produtos como complacentes com a W3C. Ao
lanar browsers que no suportavam os standards uniformemente, os fabricantes
fragmentaram desnecessariamente a web, prejudicando de igual forma designers,
programadores, utilizadores e empresas.
A falta de suporte uniforme para os standards do W3C deixou os
consumidores frustrados: se usassem o browser errado, muitos no conseguiriam
ter acesso ao contedo ou executar as transaes pretendidas. Entre aqueles mais
frequentemente afetados estavam as pessoas com incapacidades ou necessidades
especiais.
Na poca as recomendaes W3C no tinham muito valor no mercado devido
a falta de conhecimento, importncia e interesse dos usurios e programadores, em
conseqncia disto, a Guerra dos Browsers continuou inabalvel.

5.2.6 A formao da WaSP

Um grupo de desenvolvedores web e web designers profissionais se uniu e


autodenominou como Projeto Padres Web ou Web Standards Project (WaSP). A
119

idia era mudar o nome dos documentos da W3C de recomendaes para padres
e assim poder Microsoft e a Netscape a suportlos.
Em 2000, a Microsoft lanou o Internet Explorer 5 para Macintosh. Este foi um
marco muito importante, ele se tornou o navegador padro instalado no MacOS
nesse momento, e teve um razovel suporte s recomendaes da W3C tambm.
Juntamente com o suporte decente do Opera para CSS e HTML, isto contribuiu para
um momento geral positivo, em que desenvolvedores e web designers se sentiram
confortveis projetando sites usando padres web pela primeira vez.
A WaSP persuadiu a Netscape a adiar o lanamento da verso 5.0 do
Netscape Nativagor at que ele estivesse mais complacente com os padres (este
trabalho formou a base do que hoje o Firefox, um navegador muito popular). A
WaSP tambm criou uma foratarefa para o Dreamweaver, para encorajar a
Macromedia a mudar sua popular ferramenta de desenvolvimento para estimular e
suportar a criao de sites complacentes.

5.2.7 Web Standard

No evento Campus Party 2009, Eduardo Santos em sua palestra sobre Web
Standard argumentou:
Web Standards ou padres Web como um conjunto de normas,
diretrizes, recomendaes, notas, artigos, tutoriais e afins de carter
tcnico, produzidos pela W3C. destinado a orientar fabricantes,
desenvolvedores, projetistas para o uso de prticas que possibilitem
a criao de uma Web acessvel a todos. [...] na comunidade de
desenvolvedores web profissionais os padres web se tornaram
obrigatrios (SANTOS, E. 2009).

A Figura 38 mostra um paralelo entre um site com e sem padres web.

120

Figura 38 Sem padres x Com padres.


(Fonte: http://www.agni.art.br/palestras/WebStandards.pdf)

Construir sites sem os padres W3C as pginas precisam de extenso da


mdia impressa, seus layouts so baseados em tabelas, na codificao o contedo,
apresentao e comportamento so misturados resultando um cdigo difcil de
compreender. Enquanto que com padres as pginas so acessveis de qualquer
dispositivo, seus layouts so baseados em CSS, h separao na codificao de
contedo, apresentao e comportamento resultando um cdigo acessvel e de fcil
compreenso.
Para ter um projeto de sucesso com os padres web necessrio uma
mudana de conceito dos designers e dos desenvolvedores. A Figura 33 indica
como os padres web resolvem os problemas discutidos.

121

Figura 39 Estilo de interao por linguagem de comando

A tcnica web standard dividir qualquer pgina web em trs componentes


separados: estrutura, apresentao e comportamento. As pginas devem ser
desenvolvidas de forma independente, porm uma complementando a outra.

5.3

Componente: Estrutura

A funcionalidade da web baseada em trs padres:


- URI, um sistema que especifica como cada pgina de informao recebe um
"endereo" nico onde pode ser encontrada.
- Protocolo de Transferncia de Hipertexto (HTTP), um protocolo que
especifica como o navegador e servidor web comunicam entre si.
- Linguagem de Marcao de Hipertexto (HTML), uma linguagem de marcao
para codificar a informao de modo que possa ser exibida em uma grande
quantidade de dispositivos.
A linguagem de marcao que uma das funcionalidades da web tambm
um dos componentes W3C da diviso da web. Linguagem de marcao tambm
um conjunto de cdigos aplicados a um texto ou a dados, com o fim de adicionar
informaes particulares sobre esse texto ou dado, ou sobre trechos especficos.

122

5.3.1 HTML

A HTML uma linguagem de marcao de texto. A W3SCHOOLS, uma


empresa de treinamento e certificaes web define HTML como:
HTML uma linguagem para descrever as pginas web. HTML
significa Hyper Text Markup Language. HTML no uma linguagem
de programao, uma linguagem de marcao. Uma linguagem de
marcao um conjunto de tags de marcao. HTML usa etiquetas
de marcao para descrever as pginas da web. (Traduo nossa).

De acordo com os padres da W3C o cdigo HTML deve ser semntico.


Cada marcao utilizada para o que ela realmente foi criada um cdigo semntico
est sendo construdo. Semntica refere ao estudo do significado, ao codificar
preciso pensar na estrutura da Informao e fazer uma marcao com significado,
por exemplo:
- Usar <table></table> apenas para dados tabulares e no para layout de
pginas;
- Usar <h1></h1> at <h6></h6> para ttulos;
- Usar <ol></ol> para listas ordenadas e <ul></ul> para listas no
ordenadas, seguidos do elemento <li></li>;
- Usar <em></em> para nfase;
- Usar <strong></strong> para enfase forte;
- Usar <label></label> para identificar campos em formulrios;
- Assim por diante.

5.3.2 XML

A XML uma linguagem de marcao de dados. A W3SCHOOLS (2009)


define XML como:
123

XML significa Extensible Markup Language. O XML uma linguagem


de marcao muito semelhante ao HTML. O XML foi projetado para
transportar dados, para no exibir dados. Tags XML no so
predefinidas. Voc deve definir suas prprias marcas. O XML
projetado para ser autodescritivo. XML uma recomendao do
W3C. (Traduo nossa).

A XML simplesmente um texto e no tem nada de especial. apenas texto


simples e o software que pode lidar com texto puro tambm pode manipular XML.
No um substituta para o HTML elas foram projetadas com diferentes objetivos: A
XML para o transporte e armazenamento de dados e informaes e a HTML para
exibir dados e informaes.
Com XML voc inventar suas prprias tags (tags personalizadas) como por
exemplo a tag recado que poderia ser utilizado em um sistema de recados:
<recado>
<de>Joo</de>
<para>Maria</para>
<texto>Voc quer sair comigo?</texto>
</recado>
Quadro 38 Tag recado.

As tags no exemplo acima (como <de> e <para>) no so definidos em


qualquer padro XML. Essas marcas so "inventadas" pelo desenvolvedor do
documento XML. Isso possvel porque a linguagem XML no possui tags pr
definidas.
A XML agora to importante para a Web como HTML foi fundao da
web, tornouse uma recomendao do W3C e est em toda parte, a ferramenta
mais comum para as transmisses de dados entre todos os tipos de aplicaes, e
est se tornando cada vez mais popular na rea de armazenamento e descrever a
informao.

5.3.3 XHTML

Uma linguagem de marcao amplamente usada para texto a HTML, mas


que vem perdendo espao para a sua evoluo, o XHTML por conta desta ser mais

124

eficiente para separao entre a estrutura e o contedo de uma pgina de forma


mais organizada e eficiente e compatvel com HTML 4.01 e todos os browsers
suportam. Em XHTML 26 de janeiro de 2000 tornouse uma recomendao W3C
Segundo a W3SCHOOLS (2009), XHTML significa:
XHTML significa Extensible HyperText Markup Language. XHTML
quase idntico ao do HTML 4,01. XHTML uma verso mais
rigorosas e de limpeza de HTML. XHTML HTML definido como
uma aplicao XML. XHTML uma recomendao do W3C
(Traduo nossa).

Quando criada corretamente (sem erros, sem tags ilegais e sem atributos) a
marcao XHTML completamente porttil. Ele funciona em navegadores web,
leitoras de tela, navegadores de texto, dispositivos sem fio, entre outros.

5.3.4 JSP

Segundo Deitel (2005), JavaServer Pages (JSP) :


[...] uma extenso da tecnologia de servlet que separa a
apresentao da lgica do negcio. Isso permite que os
programadores em Java e designers de site Web concentrem suas
formas em escrever cdigo Java e desenhar pginas Web,
respectivamente [...].

Por ser baseada na linguagem de programao Java, a JSP tem a vantagem


da portabilidade de plataforma, que permite a sua execuo em diversos sistemas
operacionais, como o Windows e o linux. Esta tecnologia permite ao desenvolvedor
web produzir aplicaes que acessem o banco de dados e manipular arquivos no
formato texto, capturar informaes a partir de formulrios e captar informaes
sobre o visitante e sobre o servidor.
A JSP similar s tecnologias Ative Server Pages (ASP) da Microsoft e PHP
e permite a mistura de HTML esttico com contedo gerado dinamicamente. Esses
comandos dinmicos so processados pelo servidor web antes da pgina HTML ser
enviada. No lugar do comando enviado apenas o resultado deste comando no
formato HTML. Em resumo JSP uma pgina HTML comum que contm cdigo

125

Java.
Uma pgina JSP contm dois tipos de elementos:
- Elementos template que so a parte esttica de uma pgina web que pode
ser escrito em HTML, XML ou XHTML. Em linhas gerais tudo que existe na
pgina e que no elemento JSP.
- Elementos

JSP

so

os

diretivas,

scripts,

aes

padro

aes

personalizadas (tag extension).


Atravs destes componenteschave a JSP auxilia no somente na estrutura
da pgina web, mas tambm na apresentao e no comportamento.

5.3.4.1.

Diretivas JSP

De acordo com Deitel (2005) diretivas so:


[...] mensagens para o continer de JSP o componente de servidor
que executa JSPs que permitem ao programador especificar
configuraes de pgina, incluindo contedo de outros recursos, e
especificar bibliotecas de tag personalizada para utilizao em uma
JSP [...].

As diretivas so limitas pela por <%@ e %>, so processadas em tempo de


traduo e no produzem nenhuma sada imediata porque so processadas antes
de a JSP aceitar qualquer solicitao.

5.3.4.2.

Elementos Scripts JSP

Segundo Deitel (2005), os elementos scripts:


[...] permitem aos programadores inserir cdigo Java que interaja
com componentes em um JSP (e possivelmente outros componentes
de aplicativo Web) para realizar o processamento de solicitao.
Scriptlets, um tipo de elemento script, contm fragmentos de cdigo
que descrevem a ao a ser realizada em resposta a uma solicitao
de usurio. [...].

126

Os scriptlets so blocos de cdigos delimitados por <% e %> e contm


instrues Java que o continer coloca no mtodo _jspService em tempo de
traduo.

5.3.4.3.

Tag Libraries

Segundo DEITEL (2005) as aes:


[...] encapsulam funcionalidades em tags predefinidas que
programadores podem incorporar em uma JSP. As aes
freqentemente so realizadas com base nas informaes enviadas
para o servidor como parte de uma solicitao particular de cliente.
Elas tambm podem criar objetos Java para utilizao em scriplets
de JSP [...].

De acordo com Deitel a JSP possibilita embutir scriplets e JavaBeans em


linha com contedo HTML, ento porque precisamos de Tags Libraries? Segundo
SHACHOR (2002) precisamos porque:
[...] as tags nunca foram destinadas a oferecer mais funcionalidades
do que scriptlets, apenas uma melhor embalagem. As tags JSP
formam criadas para melhorar a separao de lgica de
apresentao e lgica do programa, especificamente para abstrair
sintaxe Java de HTML [...]

Os contineres de JSP processam as tags em tempo de execuo. Estas


tags so de dois tipos: padro e personalizadas.

5.3.4.4.

Tag Padro

As aes padro facilitam a utilizao da JPS, pois o cdigo das pginas fica
centralizado em marcadores (tags) e o cdigo Java fica separado do cdigo
existente na pgina (elemento template).
Essas aes fornecem implementadores de JSP com acesso s tarefas mais
comuns realizadas em um JSP, como incluir o contedo de outros recursos,
encaminhar solicitaes para outros recursos e interagir com componentes de

127

software JavaBean. As tags padro so delimitadas por <jsp:ao> e


</jsp:ao>. O Quadro 28 exemplifica algumas tags padro e suas funes.

Tag Padro

Funo

<jsp:include>

Inclui dinamicamente outro recurso em um JSP.

<jsp:forward>

Encaminha processamento de solicitao para outro JSP,


servlet ou pgina esttica.

<jsp:useBean>

Especifica que o JSP utiliza um objeto (instncia) de JavaBean


seu escopo e ID para sua manipulao.

<jsp:setProperty>

Configura uma propriedade na instncia JavaBean especfica.

<jsp:getProperty>

Obtm uma propriedade na instncia de JavaBean especfica


e converte o resultado em uma string para sada na resposta.

Quadro 39 Exemplo de Tag padro da JSP e suas funes. FONTE: adaptada de

DEITEL (2005).

5.3.4.5.

Tags Personalizadas

O conjunto de aes padro disponvel pela especificao JSP insuficiente,


mesmo para tarefas pequenas. Ento a especificao proveu a criao de novas
tags possibilitando associar uma srie de funcionalidades s pginas JSP. Estas
novas tags so agrupadas e conhecidas como Tag Libraries.

5.3.4.6.

Evoluo da estrutura de pgina web com JSP

De acordo com ANGOTI (2009) houve uma evoluo da estrutura de pgina


web e est dividida em trs geraes:
Na primeira gerao as pginas JSP contm tags HTML embutidas. Com este
mtodo tcnica web standard dividir qualquer pgina web em trs componentes

128

separados contrariada, porque no h separao entre estrutura e apresentao.


Segunda gerao: pginas JSP contm diretivas include estticas ou
include JSP dinmico. O reuso de cdigo utilizado estrutura e limitado na
apresentao, pois cada pgina JSP ainda contm informaes sobre apresentao.
Terceira gerao: H total separao entre estrutura e apresentao, ambos
pginas JSP e layouts so reusveis.

5.3.5 Ferramentas

5.3.5.1.

Adobe Dreamweaver

Macromedia Dreamweaver um editor de texto para projeto, codificao,


pginas e aplicaes web. Seu ambiente de edio desfruta do controle da
codificao manual ou trabalho visual. O Dreamweaver fornece ferramentas teis
para melhorar a sua experincia de criao web.
Os recursos de edio visual no Dreamweaver permitem criar rapidamente
pginas sem escrever uma linha de cdigo e ver todos os elementos do site e
arrastlos do painel diretamente em um documento. possvel otimizar o fluxo de
trabalho de desenvolvimento, criando e editando imagens em um aplicativo grfico,
ento importlos diretamente para o Dreamweaver, ou adicionando o Macromedia
Flash objetos.
Segundo o Dreamweaver Help, o aplicativo
[...] fornece um ambiente completo de recursos de codificao que
inclui cdigo de ferramentas de edio (tais como a colorao de
cdigo e marca concluso) e material de referncia sobre a
linguagem Cascading Style Sheets (CSS), JavaScript e ColdFusion
Markup Language (CFML), entre outros. (Traduo nossa).

5.3.5.2.

Eclipse

129

Eclipse um ambiente multilinguagem de desenvolvimento de software que


inclui um IDE e um plugin do sistema para estendlo. escrito em Java e pode ser
usado para desenvolver aplicaes em Java e, por meio de diversos plugins, em
outras lnguas, bem como, incluindo C, C++, COBOL, Python, Perl, PHP e outros.
Os usurios podem estender as suas capacidades atravs da instalao de plugins
escritos para a estrutura de software Eclipse, como kits de ferramentas de
desenvolvimento para outras linguagens de programao, e podem escrever e
contribuir com seu prprio plugin modules. Os pacotes de idiomas fornecer
tradues em mais de uma dezena de lnguas naturais. O Software disponibilizado
sob os termos da Eclipse Public License e livre e aberto.
De acordo com a Wiki Eclipse (2004) o Eclipse
[...] no surgiu do nada, mas evoluram a partir de uma linha de
produtos longos de ambientes de desenvolvimento, dos quais os
anteriores so a IBM VisualAge para Smalltalk e VisualAge IBM
Java. Ambos os produtos foram escritos em Smalltalk. A IBM
VisualAge Micro Edition produto foi a primeira experincia sria e
realmente muito bemsucedida com a escrita todo o IDE em Java
[...]. No entanto, por conta de terceiros, foi difcil estender o produto
com componentes novos, principalmente por duas razes: (1) no foi
projetado com um modelo de componentes em mente, e (2), foi
essencialmente um monoltico, fechado, produto de origem.

O projeto Eclipse foi iniciado na IBM que desenvolveu a primeira verso do


produto e doouo como software livre para a comunidade. O gasto inicial da IBM no
produto foi de mais de 40 milhes de dlares.
O Eclipse Web Tools Platform (WTP) projeto amplia a plataforma Eclipse com
ferramentas para desenvolvimento de aplicaes web e Java EE. Inclui fonte e
editores grficos para uma variedade de lnguas, assistentes e aplicaes integradas
para simplificar o desenvolvimento e as ferramentas e APIs para apoiar a
implantao, execuo e aplicaes de testes.

5.4

Componente: Apresentao

5.4.1 Interface
130

O termo interface aplicado normalmente quilo que interliga dois sistemas.


Uma interface humanocomputador uma parte do sistema
computacional, composta por uma coleo de dispositivos, por meio
dos quais o usurio pode trocar informaes com o sistema. Esses
dispositivos so sensveis s aes do usurio e so capazes de
estimular a sua percepo para que ele possa avaliar e controlar o
funcionamento do sistema (LEITE, 1998).

A interface possui componentes de hardware e software. Os componentes de


hardware compreendem os dispositivos com os quais o usurio realiza as atividades
motoras e perceptivas. Entre eles esto a tela, o teclado, o mouse e vrios outros.
Os componentes de software so responsveis por controlar os
dispositivos de hardware, construir os dispositivos virtuais, com os
quais o usurio tambm pode interagir, gerar os diversos smbolos e
mensagens que representam as informaes do sistema e interpretar
os comandos do usurio (SOUZA ET AL., 1999).

Na Figura 34, observase que a interface a parte do sistema responsvel


por traduzir aes do usurio em ativaes das funcionalidades (aplicao) e pela
apresentao dos resultados produzidos.
A interao um processo de comunicao entre o usurio e o
sistema, que engloba as aes do usurio sobre a interface e as
suas interpretaes sobre as respostas reveladas por essa interface
(LEITE, 1998).

Portanto, a interface o combinado de hardware e software que viabiliza a


interao.

Figura 40 Interao usuriosistema.

Segundo SPOLSKY (2009), IU (Interface de Usurio) importante porque


afeta os sentimentos, as emoes, e o humor de seus usurios. Se a IU est
131

incorreta e o usurio sente como se eles no pudessem controlar o seu software,


eles literalmente no sero felizes e eles amaldioaro isto no seu software. Se o IU
esperto e as coisas funcionam da maneira que o usurio espera que elas
funcionem, eles estaro felizes como se eles controlassem o sucesso de pequenos
objetivos.
Conforme relatado anteriormente sobre o conceito de Spolsky em relao ao
axioma de maior importncia de todos os projetistas de interfaces com usurios:
Uma interface de usurio bem projetada quando o programa se comporta
exatamente como o usurio pensa que ele se comportaria. Steve Jobs, Apple CEO,
refora o conceito afirmando que Design no o que um produto parece ser, design
como o produto funciona.
Sobre a apresentao de um produto concebido por uma atividade de Design,
Leite (1998) afirma:
Design a atividade intelectual de conceber e descrever um produto
a partir dos requisitos de seus potenciais usurios. Esta atividade
requer tcnicas e ferramentas adequadas, aliadas criatividade, ao
talento e experincia do designer. O produto concebido em uma
atividade de design precisa ser apresentado atravs de um prottipo
e/ou de uma especificao. A prototipao consiste na descrio do
que foi concebido, utilizando materiais mais baratos e dimenses
reduzidas. O objetivo poder fazer uma avaliao. A especificao
consiste na descrio abstrata, rigorosa, idealmente correta e
completa do produto, utilizando uma notao ou linguagem
adequadas. A especificao e a prototipao permitem vises e
formas de avaliao complementares do produto concebido. A
especificao permite uma descrio e avaliao a partir de tcnicas
associadas s notaes utilizadas. J a prototipao permite uma
descrio e avaliao mais concreta do produto no contexto de
utilizao.O design de interfaces de usurio uma atividade que
requer anlise dos requisitos dos usurios, concepo, especificao
e prototipao da interface, e avaliao da utilizao do prottipo
pelos usurios. Diversos modelos do desenvolvimento de software
baseados em prototipao argumentam que este processo deve ser
realizado de forma cclica, isto , a avaliao deve levar a um novo
design e ser posteriomente avaliado. (LEITE, 1998).

Dias (2002), recomenda o uso dos sete princpios de design definidos pelo
Centro para Design Universal, da Universidade Estadual da Carolina do Norte
(1995), nos Estados Unidos. Foram definidos a partir de um esforo cooperativo
para estabelecer parmetros para as disciplinas de design de produtos, ambientes e
comunicaes:
132

- Uso equitativo o design passvel de utilizao por qualquer grupo de


usurios e oferece as mesmas formas de uso (idnticas ou equivalentes) a
todos, sem segregar ou estigmatizar qualquer usurio.
- Flexibilidade no uso o design acomoda uma vasta variedade de preferncias
e habilidades individuais, oferecendo mais de uma opo de uso ao usurio.
- Uso simples e intuitivo o design de fcil compreenso indeprendente da
experincia, conhecimento ou habilidades verbais do usurio. Elementos
complexos desnecessrios devem ser eliminados.
- Informao perceptvel o design consegue comunicar, com eficcia, a
informao necessria ao usurio, independentemente das condies
ambientais ou habilidades sensoriais do usurio.
- Tolerncia a falhas o design minimiza erros e aes adversas originadas por
atos no intencionais ou acidentais do usurio, provendo mensagens
elucidativas e alternativas para solucionar falhas.
- Baixo esforo fsico o design pode ser usado de forma eficiente e agradvel,
gerando o mnimo de fadiga ao usurio, minimizando tarefas repetitivas,
manipulaes complexas e posies desconfortveis.
- Tamanho e espao para aproximao e uso o design tem tamanho e
espao apropriado para aproximao, alcance, manipulao e uso,
independentemente da mobilidade, postura ou tamanho do corpo do usurio.
Alm desses princpios de design universal, outros fatores so importantes
para um bom design, tais como esttica, custo, segurana, adequao cultural e de
gnero.

5.4.1.1.

Componentes de interface web

Avelareduarte (2009) define componentes de interface como elementos


comuns maioria dos sites web que influenciam o deslocamento, a ao e a
experincia do usurio de acordo com solues amplamente testadas e aceitas.

5.4.1.1.1.

Barras de navegao ou menus


133

Segundo Linwood (2003) a navegao apenas um segmento da arquitetura


de um site de informao, mas o segmento mais visvel para o usurio final e as
barras de navegao a forma mais prevalente de navegao.
A maioria dos usurios espera que as barras de navegao permaneam
constantes durante todo o perodo de visita no site. Cada nvel pode ter um esquema
de navegao de trs ou quatro nveis. Mais longe do que isso, possvel prejudicar
o espao disponvel o contedo do site, especialmente com os locais que
disponibilizam banners.
possvel usar duas abordagens para criar barras de navegao: com
imagens ou texto. As imagens foram mais populares antes da maioria dos
navegadores darem suporte a HTML dinmico (DHTML) e Cascading Style Sheets
(CSS), porque era mais fcil de mudar uma imagem quando o ponteiro do mouse
rolava sobre ela, para dar ao usurio final um efeito visual. O texto mais rpido
para carregar e mais fcil de gerar a partir da estrutura do seu site, e permite mudar
a cores dos links com efeitos DHTML.
Jakob Nielsen (2008) baseando nos estudos de eyetracking (caminho do
escaneamento uma srie resultante das fixaes e movimentaes oculares) em
sites recomenda algumas diretrizes para o design de menus verticais:
No alinhar direita o menu, porque dificulta a leitura (ver Figura 35
imagem esquerda).
Alinhar esquerda o menu, de modo que os olhos do usurio pode se mover
em linha reta e no ter de voltar a adquirir no incio de cada nova linha (ver Figura 35
imagem direita).
Evitar usar as mesmas palavras para iniciar alguns itens da lista, porque isso
torna mais difcil a verificao.

134

Figura 41 Design de menu vertical

5.4.1.1.2.

Barras de rolagem

De acordo com Avelareduarte (2009) Barras de rolagem so as barras


laterais janela do browser, que sinalizam a existncia de contedo que ultrapassa
a rea visvel da pgina e permitem o deslocamento da janela para alcanlo.
Como muitos usurios relutam em utilizar estas barras, importante que o
contedo mais importante de cada pgina fique localizado na parte visvel da pgina
logo que esta carrega no browser.
Segundo King (2006), apenas 23% dos usurios que visitam um site pela
primeira vez usam as barras de rolagem na pgina principal e este nmero diminui
ainda mais nas visitas seguintes. As barras de rolagem podem ser horizontais mas
so pouco indicadas (pois exigem a rolagem horizontal) e so usadas por apenas
0,4% dos usurios.
De acordo com Avelareduarte (2009), os usurios esto habituados a
encontrar nas barras de rolagem os seguintes elementos:
- Setas acionveis no alto e embaixo, sensveis ao toque prolongado do
mouse.
- Deslizador" arrastvel, normalmente em cor diferente do fundo, que sinalizar
o movimento em direo parte de cima ou de baixo da pgina e, pelo seu
tamanho, indica a extenso da janela.
135

Para ajudar o usurio a identificar e imediatamente entender o uso das barras


de rolagem importante que o projetista de interface utilize um layout semelhante ao
das barras de rolagem do browser e dos programas que usurio est acostumado a
usar.
Quando as barras so muito diferentes da interface do browser, sua
funcionalidade fica difcil de identificar, especialmente pelos usurios que usam a
internet h pouco tempo.

Figura 42 Barra de rolagem em forma de fleha ou remo

Na Figura 36 a barra de rolagem apresentada em forma de flecha, ou remo.


Visualmente interessante e chama a ateno do pblico infantil, mas muitas
crianas podem passar pela pgina sem saber que h mais texto na parte de baixo,
que pode ser visto tocandose a parte inferior e superior da imagem

136

Figura 43 Barra de rolagem discreta

Na Figura 37, as barras de rolagem muito discretas dificultam a identificao


pelo usurio, que deixa de ter acesso a informaes que pode estar procurando.
So duas setas localizadas direita, uma apontando para cima e outra apontando
para baixo. Alguns usurios podem no encontrlas facilmente.
Nielsen (2005) recomenda cinco diretrizes de usabilidade indispensvel para
rolagem e barras de rolagem:

Oferecer uma barra de rolagem, se tem uma rea de rolagem de


contedo. No confie na rolagem automtica ou arrastando, que as
pessoas no podem notar.

Ocultar todas as barras de rolagem se o contedo visvel. Se as pessoas


vem uma barra de rolagem, eles assumem que h contedo adicional e
ser frustrado se no pode rolar.

Cumprir as normas de uso da GUI e barras de rolagem que se parecem


com barras de rolagem.

Evitar a rolagem horizontal em pginas da Web e minimizla em outro


lugar.

Mostrar todas as informaes importantes acima da dobra. Usurios


muitas vezes decidir ficar ou sair com base no que eles podem ver sem se
mover.

137

5.4.1.1.3.

Breadcrumbs

Segundo Avelareduarte (2009), breadcrumbs so recursos de navegao que


mostram a trilha de acesso a uma pgina em relao estrutura do site em que est
situada. O nome em ingls uma referncia histria de Joo e Maria, que, para
no se perder na floresta, jogam pedaos de po para formar uma trilha que sinalize
o caminho de volta.
Jacob Nielsen (2007) tem recomendado o uso de breadcrumb desde 1995 por
alguns motivos que ele considera simples:

Mostram s pessoas a sua localizao atual em relao ao ensino de


conceitos de nvel.

Ajuda a compreender onde o usurio est em relao ao resto do site.

Permite acesso de um clique para nveis mais elevados do site.

Nunca causam problemas nos testes de usurio.

Os breadcrumbs devem mostrar a hierarquia do site, e no uma histria do


usurio. Quase sempre so implementadas da mesma maneira, com uma linha
horizontal que:

progride do nvel mais alto ao mais baixo, a um passo de cada vez;

comea com a homepage e termina com a pgina atual;

tem um link de texto simples para cada nvel (exceto para a pgina atual,
porque voc nunca deve ter uma ligao que no faz nada), e

tem um simples, um separador de carter entre os nveis (geralmente ">").

A Figura 38 exemplifica um breadcrumb no site UseIT.com.

138

Figura 44 Exemplo de Breadcrumb

5.4.1.1.4.

Formulrios

Segundo Avelareduarte (2009), os formulrios permitem que o usurio inclua,


a partir de um web site, diversos tipos de informaes e as envie para destinatrios
definidos, como no caso de pagamento de impostos, compra de mercadorias,
contrato de servios, registro de acesso a um site. As informaes encaminhadas
podem ser includas em bancos de dados e gerar respostas automticas como a
compra de uma mercadoria, por exemplo. Podem tambm ser enviadas por email
para uma pessoa, responsvel pela resposta ou pelo seu encaminhamento a
terceiros.

5.4.1.1.5.

Formulrios HTML/XHTML

Este tpico (4.4.1.1.5) uma adaptao traduo feita por (SILVA, 2006) do
ttulo original Accessible HTML/XHTML forms de Ian Lloyd (LLOID) disponibilizado
no site da Web Standard Project.
Normalmente, para novatos, os formulrios se constituem em um aspecto
complicado do desenvolvimento web, porque sua implementao vai alm de incluir
informaes em elementos da marcao, para serem vistos pelos visitantes do site.
Formulrios coletam informaes e dados a serem processados. E da mesma forma
139

como deve ser difcil ao novato entender a mecnica de coletar e processar dados,
tambm difcil o entendimento dos aspectos de acessibilidade relacionados aos
formulrios.
Contedos estticos do site sero facilmente visualizados e entendidos por
usurios de leitores de tela ou at mesmo, talvez, por um computador Braille se
cosiderarmos que voc usou uma marcao semntica e bem estruturada (tal como
h1 h6 para cabealhos). Ler ou deixar de ler um contedo esttico no site uma
atitute passiva do visitante, mas ao encontrar um formulrio o usurio quer interagir
com ele e de repente mudase um campo uma via de duplo sentido. Para
formulrios, a marcao tornase crucial para a correta captura de informaes do
usurio.
Os elementos HTML usados para marcao de formulrios so:

O elemento <form> (o "container" para os elementos a seguir);

<input> podem ser de variados tipos como: text, submit, button,


radio button e checkbox;

<textarea>

para

entrada de

textos

multilinhas,

tais

como

comentrios;

e o elemento <select> tambm conhecido como dropdownlist, ou


pulldown menu ( sua preferncia);

Existe tambm o elemento <button>, que vem sendo pouco usado


ultimamente.
Estes elementos so renderizados e tm um comportamento semelhante em
diferentes browsers (GUIbased). Pode haver algumas diferenas de estilizao,
mas essencialmente um campo de texto se parece com um campo de texto e uma
dropdownlist cumpre a finalidade de uma dropdownlist. Teoricamente a
interao com formulrios deveria ser fcil para qualquer um, independente do
dispositivo ou browser usado.
Quando voc l o ttulo de um artigo no jornal, fica sabendo que o texto que
se segue diz respeito quele ttulo, assim como, o texto que aparece embaixo de
uma foto, a descrio da foto. Por vezes um layout de pgina no segue padres e
em conseqncia voc encontra dificuldade em entender o que se passa duas
140

fotos sendo uma ao lado da outra com um texto entre elas, OK voc inteligente e
vai acabar descobrindo a que foto se refere o texto.
Para formulrios existem alguns consagrados princpios CHI (Computer
Human Interaction Interao ComputadorHumano) que funcionam de modo
anlogo ao jornal, isto , formulrios sero bem mais fceis de se usar se projetados
conforme determinados princpios de uso. Por isto tecnologias assistivas, tais como
leitores de tela, seguem queles princpios quando interpretam formulrios em
pginas web. Assim, ao encontrar um campo "text input", os leitores de tela
esperam que o texto descritivo daquele "text input" esteja antes do campo e
ali, antes do campo que o leitor vai procurar a descrio! Ento, se o leitor de tela
encontra algo como o Quadro 28, ele vai ter dificuldade em interpretar o formulrio:

<input type="text" name="nome" id="nome" /> - Entre seu


primeiro nome<br />
<input type="text" name="sobrenome" id="sobrenome" /> Entre seu sobrenome <br />

Quadro 40 Cdigo de text input

Dificuldade por qu? Porque o leitor de tela poder associar incorretamente o


segundo input com a primeira linha de texto como mostrado no Quadro 29:
<input type="text" name="sobrenome" id="sobrenome" /><-Entre seu sobrenome<br />

Quadro 41 Texto aps o input text

Figura 45 Exemplo input antes do campo

141

Esta a receita para o desastre, colocar o texto depois do campo. Para


alguns tipos de input isto absolutamente correto (Quadro 30):
<input type="checkbox" name="athome" id="athome" />
Please call me at home<br />
<input type="checkbox" name="atwork" id="atwork" />
Please call me at work<br />

Quadro 42 Codigo de input checkbox

Considere uma srie de checkboxes. Observe no layout a seguir, tudo bem


alinhado (Quadro 43).

] Please call me at hom

] Please call me at my workplace

] Please call me at the shack

Quadro 43 Representao da posio do input checkbox a esquerda do label

Mas se for invertido o alinhamento perdido:

Please call me at home [


Please call me at my workplace [
Please call me at the shack [

]
]

Quadro 44 Representao da posio do input checkbox a direita do label

Siga as recomendaes abaixo e os seus formulrios sero automaticamente


mais acessveis, pois desta forma que os dispositivos adaptados esperam que eles
sejam (Quadro 44):

142

Elemento e tipo
HTML

Sequncia no
layout

Exemplo

Your First Name<br />


Rtulo
descritivo,
<input type="text"
Elemento HTML
name="txtFirstName" />
Your Passnumber<br />
Rtulo
descritivo,
<input type="password"
input type="password"
Elemento HTML
name="txtPassword" />
<input type="button"
No se aplica (usar
name="cmdChkAvail" value="Check
input type="button"
atributo)
Availability" />
<input type="submit"
No se aplica (usar
name="cmdBookNow" value="Place
input type="submit"
atributo)
Booking" />
<input type="radio"
name="radMarried"
value="Yes" /> Yes, I am
Elemento
HTML, married<br />
input type="radio"
<input type="radio"
Rtulo descritivo
name="radMarried"
value="No" /> No, I am single<br
/>
<input type="checkbox"
Elemento
HTML, name="chkSubscribe"
input type="checkbox"
value="Subscribe" /> Subscribe to
Rtulo descritivo
the newsletter
Title<br />
<select name="ddlTitle">
Rtulo
descritivo, <option>Mr</option>
select
...
Elemento HTML
</select>
input type="text"

textarea
button

Your comments<br />


Rtulo
descritivo,
<textarea
Elemento HTML
name="txtComments"></textarea>
No se aplica (usar <button name="cmdBigButton">Go on,
click me!</button>
atributo)

Quadro 45 Layout para elementos de formulrio CHI Boas tcnicas

Seguindo as diretrizes do Quadro 33 e construindo formulrios de acordo com


os princpios CHI, eles sero mais acessveis e cumpriro melhor sua finalidade. E,
com o propsito de manter as coisas simples, deve-se considerar como usar (ou no
usar) scripts para construir formulrios mais acessveis.
Considere que scripts esto desabilitados no lado do usurio. Um formulrio
deve cumprir sua finalidade independentemente de scripts estarem ou no
habilitados no browser (ainda que eles suportem scripts lembrese que alguns
dispositivos adaptados no suportam scripts). Validao e manipulao de dados no
lado do servidor possibilita o funcionamento de formulrios independentemente de
143

scripts no lado do usurio. Muitos desenvolvedores ainda se utilizam largamente de


scripts no lado do cliente para validao, ou mesmo disparadores de eventos
(observe no Quadro 34 um formulrio, cujo funcionamento totalmente dependente
de scripts estarem habilitados no lado do usurio:
<input type="button" value="Place order"
onclick="document.forms('main'.submit();" />

Quadro 46 Cdigo de formulrio com dependncia de script no lado do usurio

e uma maneira alternativa no dependente de scripts que cumpre a mesma


finalidade:
<input type="submit" value="Place order" />

Quadro 47 Cdigo de formulrio sem dependncia de script no lado do usurio

Assegurese de que seu formulrio funciona com scripts desabilitados


entregue a tarefa ao servidor!
Quais as implicaes de se usar JavaScript que desencadeia no formulrio
uma ao fora do controle do usurio? O exemplo clssico ocorre com um elemento
de formulrio do tipo "dropdownlist" usado como ferramenta para navegao.
Muitos sites utilizam este recurso que consiste em ao usurio selecionar um item do
menu,

automaticamente

abrese

pgina

selecionada.

Para

usurios

impossibilitados de usar mouse (pessoas cegas navegando com leitores de tela,


pessoas com restries motoras e outros casos mais) o uso do menu tornase muito
difcil (ou mesmo impossvel).
Usar o teclado para tentar selecionar as opes da lista no ter efeito, pois
resultar sempre em seleo e ativao do primeiro item da lista. A tentativa de
encontrar uma soluo inteligente resultou em uma armadilha para a acessibilidade.
Mantenha as coisas simples use uma lista "dropdownlist" sempre que assim
desejar, mas fornea um boto "Go" (Ir) para o usurio ativar sua seleo, conforme
144

mostrado na Figura 47.

Figura 46 Dropdownlist" como ferramenta para navegao

Uma outra questo envolvendo a acessibilidade em formulrios, diz respeito


ao uso de tabelas para se conseguir um layout alinhado e certinho. Esta prtica no
implica necessariamente em um problema de acessibilidade, mas poder vir a
causar problemas um layout de formulrio baseado em tabela irrelevante para
um leitor de tela, o contedo lido na ordem em que foi escrito no cdigo fonte. Se
voc dispor seu layout de formulrio, agrupando os rtulos descritivos e os controles
do formulrio voc "quebrar" o relacionamento entre eles. Isto pelo fato de que
leitores de tela ' linearizam' as tabelas e interpretaro erroneamente o formulrio,
conforme exemplo mostrado na Figura 41:

Figura 47 Layout de formulrio

Estas

so

algumas

regras

bsicas

relacionadas

ao

layout

ao

posicionamento de elementos de formulrios e seus rtulos descritivos, que serviro


como um bom ponto de partida para projetar formulrios.

145

5.4.1.1.6.

cones

A escrita ocidental baseada em um alfabeto composto de letras (unidades


mnimas) que devem ser associadas para formar palavras, que agrupadas formam
frases. H situaes em que a leitura e compreeno de uma mensagem comprida
deve ser instantnea. Frases compridas como: "H uma lombada adiante; diminua a
velocidade" podem causar acidentes pela demora na leitura. Para superar esta e
outras situaes surgiram os cones.
De acordo com Instituto Brasileiro de Amigabilidade e Usabilidade IBRAU
(2006), um cone um smbolo grfico cuja visualizao recupera, da memria de
curto ou longo prazo, lembranas relacionadas a vrios fatores: perigos, alertas,
opes, aes, etc. (ver na Figura 42 alguns exemplos de cones). Avelareduarte
(2009) relata que em sites com usurios regulares, cones podem ajudar a simplificar
a navegao, atravs da rpida visualizao de links e informaes a eles
associadas.

Figura 48 Exemplos de cones

Os cones para serem melhores compreendidos seu layout deve estar


associado a elementos conhecidos no contexto sciocultural do usurio. A Figura
43 lembra um controle de um aparelho de som, ou de vdeo, ou de um DVD.

Figura 49 cone de multimedia

Segundo Norman, apud. IBRAU (2006) h trs tipos de cones (Quadro 36):

Os que representam os objetos que sero manipulados

146

Os que representam as operaes ou os operadores

Os que representam operadores atuando sobre objetos

Quadro 48 Tipos de cones

Na sistemas desktop ou web os cones podem ser utilizados para diversas


finalidades como: ativao de menus, iniciao a execuo de aes, manipulao
de janelas, representao de arquivos, diretrios e estruturas, entre outros.
Dentre vrias vantagens dos cones se destacam:
Um cone, desde que corretamente projetado, dispensa leitura, anlise,
reconhecimento ou traduo.
compreensvel at por pessoas no alfabetizadas.
compreendido rapidamente: Estudos na compreenso de sinalizao
rodoviria demonstram que um cone pode ser reconhecido ao dobro de
distncia e na metade do tempo que um sinal escrito .
Contribui facilidade de (re)aprendizado.
Projetados adequadamente, contribuem optimizao de espao na tela.
H extensas bibliotecas com cones prontos de acesso gratuito na internet.
Os cones so um grande aliado do projetista. Sua capacidade de
compreenso imediata tornaos extremamente teis para destacar aes, sinalizar
eventos e representar estados. Na deciso de seu uso, devese tomar o cuidado
utilizlos com moderao para no caursar poluio visual nem aumentar o tempo
de carregamento das pginas em sistemas web.

5.4.1.1.7.

Ttulo da pgina

Segundo AVELAREDUARTE (2009) um ttulo da pgina identifica o assunto


da pgina. o texto registrado por default nos favoritos dos browsers e um
147

lembrete muito til sobre o contedo da pgina para os usurios dos programas.
uma informao que merece ateno especial, pois algumas ferramentas
de busca mostram o ttulo da pgina na lista de resultados, associada sua URL.
Cada pgina de um site deve ter um ttulo diferente, para identificar seu
contedo e sua especificidade. Os ttulos ou cabealhos das pginas devem
corresponder exatamente aos termos utilizados nos links que apontam para essas
pginas.
Para ajudar a indexao dos sites de busca e o rastreamento da navegao
pelo usurio, cada pgina deve ter um ttulo especfico, que explique o contedo da
pgina e faa sentido fora do contexto do site. Se o usurio l o ttulo no resultado
de uma ferramenta de busca, deve poder entendlo para que possa selecionlo.

5.4.1.2.

Resoluo do monitor e tamanho do website

A resoluo de um monitor indica a quantidade de pixels (pontos) que formam


a imagem que aparece em uma tela de dispositivo digital. A resoluo de um monitor
com 800 x 600, por exemplo, mostra 800 pixels em cada uma das 600 linhas do
monitor, totalizando 480.000 pixels.
A qualidade da definio de uma imagem depende da relao entre o nmero
de pixels por polegada quadrada (dpi, dots per inch) com que a tela est
configurada, sua resoluo, e o tamanho do monitor. Quanto maior o nmero de
pontos que forma uma imagem, maior o monitor, maior ser a definio da imagem
que aparecer para os usurios.
Se, no entanto, um monitor grande configurado com baixa resoluo de
pontos, mostra imagens indefinidas e embaadas, so criados pixels "falsos" a partir
da imagem de menor tamanho para ocupao de toda a sua rea na tela.

148

Figura 50 Resolues de tela utilizadas em novembro de 2007

O site Market Share disponibiliza um resultado de pesquisa de resolues de


telas utilizadas para visualizao de pginas web. Na Figura 44 possvel visualizar
que em novembro de 2007 a resoluo 1024x768 era utilizada por 46,08% dos
internautas e 800x600 por 7,62%. O cenrio muda em novembro de 2008 (Figura
45) com a resoluo 1024x768 em queda para 37,59% e 800x600 para 4,69%. Na
Figura 0012 mostra que em novembro de 2009 a resoluo 1024x768 est com
30,25% e 800x600 com 3,58%. De acordo com as Figuras 44, 45 e 45 a perda de
percentual foi devido ao aumento de uso de telas com resoluo maior que
1024x768.

Figura 51 Resolues de tela utilizadas em novembro de 2008

Figura 52 Resolues de tela utilizadas em novembro de 2009

5.4.1.3.

Layout lquido

Por apresentar compatibilidade com os monitores mais antigos, muitos


desenvolvedores e designers ainda consideram a resoluo de 800x600 como base,
com a largurareferncia da interface de 750px, que leva em conta as dimenses do
149

browser e de barra de rolagem laterais.


Especialistas da web como Jakob Nielsen recomenda o desenvolvimento de
interfaces baseadas no chamado "layout lquido", em que os limites laterais das
pginas so definidos em percentuais em vez de pixels. Essa tcnica uma
otimizao que faz com que uma pgina criada no tamanho 1024x768 funcione bem
em outros tamanhos com um bom aspecto.
Existem vrios sites utilizando esta otimizao, a Organizao W3C um
exemplo, na Figura 47 possvel visualizar a pgina na resoluo 1024x768. A
visualizao 800x600 visto na Figura 48 e Figura 49 o mesmo site apresentado
em resoluo 1280x800. Independente da resoluo o site ficou com um timo
aspecto.

Figura 53 Site W3C visualizado na resoluo 1024x768

Figura 54 Site W3C visualizado na resoluo 1280x800

150

Figura 55 Site W3C visualizado na resoluo 800x600

Nielsen (2009) recomenda tambm trs critrios a considerar na adaptao


da interface resoluo de tela:
Visibilidade inicial: Informaes mais importantes da pgina localizadas no
alto, para que o usurio possa tomar conhecimento do assunto geral sem
precisar fazer rolagem vertical.
Esttica: Aparncia da pgina e composio dos elementos dispostos de
maneira harmnica em diferentes resolues de tela.
Legibilidade: Textos fceis de ler em pginas com colunas de diversas
larguras, especialmente colunas nas mais estreitas.
O layout lquido por no ser uma soluo perfeita, apresenta algumas
desvantagens:
Dificuldade na leitura em janelas pequenas, em que a largura da mancha que
contm os textos fica muito estreita, especialmente em telas de baixa
resoluo. Este problema pode ser atenuado com a configurao de larguras
mnimas de colunas de textos.
Se o layout ocupa toda a largura da janela do browser numa tela de alta
resoluo, as linhas de textos podem ficar muito longas e difceis de ler, o que
pode ser atenuado com a configurao da largura para apenas 85% da
pgina.

151

5.4.1.4.

Espao do browser na tela

Os componentes de um navegador ou browser (menu, outros atalhos, barras


de rolagem vertical e horizontal) ocupam espao na tela e seus tamanhos mudam
em tipo de browser e tambm de acordo com a resoluo da tela utilizada. Para criar
layouts adequados a estas telas, necessrio considerar a largura em pixels e
subtrair o espao ocupado pelo browser da largura total.
Segundo MCCLURG (2006),[...] no podemos usar os nmeros "brutos" para
determinar como um grande projeto deve ser. Temos de considerar o espao
ocupado pelo prprio navegador, e subtrair que a partir do tamanho da tela global
para obter uma imagem mais precisa.
Assim, quanto espao um navegador ocupa? Depende do navegador e suas
configuraes padro. A melhor maneira de aproximar isso configurar um monitor
de tela no tamanho apropriado, ampliar o navegador, e ter uma captura de tela.
Voc pode ento ter uma idia de quanto espao est realmente disponvel para
exibir informaes. No entanto, devido s diferenas nos hbitos de navegao do
usurio, difcil chegar a nmeros definitivos sobre o melhor tamanho para
trabalhar. As pessoas no podem ter seus navegadores completamente expandidos,
e eles podem ter muitas ou poucas barras de abrir a qualquer momento. Esta
tcnica permite uma aproximao do tamanho de trabalhar menos para um projeto
de largura fixa. (Traduo nossa).
Tamanho da Tela
800 600
1024 768

IE 6
779 400
1003 568

Firefox
781 434
1005 602

Opera
777 427
1001 595

Mozilla
779 420
1003 588

Netscape
781 389
1005 557

Quadro 49 Valor real aproximado. FONTE: adaptada de MCCLURG (2006).

O Quadro 37 contm valores padro para um site recomendados por


MCCLURG (2006) Os nmeros abaixo mostram a propriedade "aproximados real",
disponvel para os dois tamanhos de tela dominante e as verses atuais dos
browsers mais populares. Estes nmeros assumem um padro de instalao (pelo
menos no menu Arquivo, botes padro, barra de endereos, barra de favoritos,
barra de status e barra de rolagem). Os valores usados para a elaborao de layouts
devem considerar os valores default, usados pela maioria dos usurios.
152

O layout lquido uma maneira de controlar os problemas de diferentes


configuraes de usurio, devese tambm planejar com preciso as reas que
devero ou no esticar ou encolher para melhor controlar o resultado em cada
situao.

5.4.1.5.

Localizao dos elementos na tela

Segundo AVELAREDUARTE (2009), A maioria dos usurios quando acessa


um site desconhecido procura alguns elementos em lugares consagrados pelo uso
[] se num site os visitantes encontram facilmente o que procuram, podem se
concentrar mais facilmente nas tarefas e nas informaes que os levaram at ali.
Tambm de acordo com AVELAREDUARTE (2009) os usurios esto
acostumados a encontrar diferentes tipos de informaes disponveis na pgina
agrupadas, sendo as mais importantes mostradas em primeiro lugar. No Quadro 38
possvel visualizar o outros elementos que so encontrados nos sites em vrias
posies.
Elemento de Interface
Logotipo

Posicionamento
no alto, esquerda da pgina

Menu de navegao

no alto, com links dispostos horizontalmente, ou no lado


esquerdo da pgina, com links dispostos verticalmente

Links para "Voltar Principal

na rea superior esquerda da pgina

Buscador interno

no alto, na rea central ou na parte direita da pgina

Informaes para contato

no alto da pgina, direita

Banners e anncios

no alto ou ao longo do lado direito

Menus drop down e atalhos para


pginas

reas mais profundas no alto da rea de contedo ou ao


longo do lado direito

Campos login e senha

no alto, esquerda da pgina

Breadcrumbs ou "migalhas de po"

no alto da rea de contedo ou embaixo do logotipo, de


forma que fiquem facilmente associados localizao da
pgina em relao Principal

Carrinho de compras (sites de


comrcio)

no alto da pgina

Informaes sobre as compras

normalmente no alto

Agrupamentos de links internos

na rea esquerda das pginas

Artigos em promoo (sites de


comrcio)

no alto da rea de contedo

153

rea de contedo

na rea central da pgina

Links internos para informao adicional na rea direita da pgina


Links para outros sites

na parte inferior da pgina

Informaes institucionais

no alto da pgina em sites institucionais ou na barra


localizada na parte de baixo, como nos sites de comrcio,
em que as informaes institucionais no so prioritrias

Links para "Voltar ao alto"

na base de pginas muito altas.

Informaes sobre o site e mapa do site


eventualmente tambm no alto da pgina
na base da pgina

Quadro 50 Posicionamento de elementos de interface. FONTE: adaptada de


AVELAREDUARTE (2009).

O posicionamento dos elementos de interface tambm foi estudado por


pesquisadores como Nielsen, Adiksson, Krung, Lynch e Bernard. O resultado do
estudo encontrase na Figura 49.

Figura 56 Recomendao para posicionamento de elementos

Ao analisar os dados dos elementos: marca da empresa, buscador,


navegao, beadcrubs e contedo notase que a Figura 50 refora o resultado do
quadro 34 destes mesmos elementos.

5.4.1.6.

Navegao do sistema

De onde vim ou onde estive? Referese ao sentido de localizao do usurio


em relao s pginas j visitadas. Em listas ou conjuntos de links, esta informao
especialmente necessria, pois muitas vezes impossvel lembrar todos os links
selecionados e todas as pginas visitadas.
154

Onde estou? Referese ao sentido de localizao do usurio em relao a


um site e web em geral, de forma que se oriente adequadamente para encontrar
as informaes que procura, ou realizar as tarefas a que se prope ao selecionlo.
Um timo recurso para ajudar na localizao do usurio na pgina so os
breadcrumbs, que mostra a estruturada hierrquica da pgina onde o usurio se
encontra. Outro excelente recurso (muito utilizado) mudar a cor dos links em que
as pginas foram visitadas
Para onde vou ou onde posso ir e como chegar? Referese ao sentido de
localizao do usurio em relao estrutura de informaes, que levao a
encontrar o que est procurando, seja uma notcia, um produto para compra, um
texto acadmico.
Um sistema bem definido primeira vista, com links visveis e identificveis,
ajuda o usurio a se deslocar sem erros ou expectativas no correspondidas,
reforando o seu sentido de localizao dentro do sistema.

5.4.1.7.

Layout

No ano de 2003, Dave Shea lanou um site chamado CSS Zen Garden, foi
um grande impacto para os profissionais web porque demonstrou verdadeiramente
que o design inteiro pode mudar apenas alterando o estilo da pgina e o contedo
pode permanecer idntico. A Figura 51 ilustra o tema padro Tranquille do site CSS
Zen Garden. As Figuras 52, 53, 54 e 55 so quatro dos 200 estilos disponibilizados
no site.

155

Figura 57 Site Zen Garden Tema Tranquille

Figura 58 Site Zen Garden Tema CSS Co., Ltda

Figura 59 Site Zen Garden Tema Under the Sea

156

Figura 60 Site Zen Garden Tema Retro Theater.

Figura 61 Site Zen Garden Tema Wiggles the Wonderworm.

5.4.2 Tecnologias

5.4.2.1.

CSS

Segundo a W3SCHOOLS (2009), CSS significa Cascading Style Sheets. Os


estilos definem como exibir os elementos HTML. Estilos foram adicionados ao HTML
4.0 para resolver um problema. As folhas de estilo externas podem salvar um monte
de trabalho. As folhas de estilo externas so armazenadas em arquivos CSS
(Traduo nossa).
157

5.4.2.1.1.

CSS resolve um grande problema

HTML nunca foi destinado a conter tags para a formatao de um documento.


destinada a definir o contedo de um documento, como:
<h1> Este um ttulo </ h1>
<p> Este um pargrafo. </ p>
Quando <font> como tags, e atributos de cor foram adicionados
especificao HTML 3.2, iniciouse um pesadelo para os desenvolvedores web.
Desenvolvimento de web sites grandes, onde as fontes e informaes de cores
foram adicionadas a cada pgina, tornouse um processo longo e caro.
Para resolver este problema, a World Wide Web Consortium (W3C) criou
CSS. Em HTML 4,0, toda a formatao pode ser removido de um documento HTML,
e armazenado em um arquivo CSS separado. Folhas de estilo externas permitem
alterar a aparncia eo layout de todas as pginas em um site, apenas editando um
nico arquivo e todos os navegadores hoje suportam CSS.

Figura 62 Site W3C visualizado na resoluo 800x600

Nielsen (2006) recomenda tambm trs critrios a considerar na adaptao


da interface resoluo de tela:
Visibilidade inicial: Informaes mais importantes da pgina localizadas no
alto, para que o usurio possa tomar conhecimento do assunto geral sem
precisar fazer rolagem vertical.

158

Esttica: Aparncia da pgina e composio dos elementos dispostos de


maneira harmnica em diferentes resolues de tela.
Legibilidade: Textos fceis de ler em pginas com colunas de diversas
larguras, especialmente colunas nas mais estreitas.
O layout lquido por no ser uma soluo perfeita, apresenta algumas
desvantagens:
Dificuldade na leitura em janelas pequenas, em que a largura da mancha que
contm os textos fica muito estreita, especialmente em telas de baixa
resoluo. Este problema pode ser atenuado com a configurao de larguras
mnimas de colunas de textos.
Se o layout ocupa toda a largura da janela do browser numa tela de alta
resoluo, as linhas de textos podem ficar muito longas e difceis de ler, o que
pode ser atenuado com a configurao da largura para apenas 85% da
pgina.

5.4.2.2.

Espao do browser na tela

5.4.2.2.1.

Sintaxe CSS

Uma regra CSS tem duas partes principais (ver Figura 57):
um selector, e uma ou mais declaraes.

Figura 63 Sintaxe CSS

O seletor normalmente o elemento HTML que deseja estilo (ex: h1).


Cada declarao consiste de uma propriedade (ex: color) e um valor (ex:
blue). A propriedade o atributo style voc deseja alterar. Cada propriedade tem um
159

valor. Declaraes CSS sempre terminam com um ponto e vrgula, e os grupos de


declarao so cercados por chaves. Exemplo no Quadro 39:

p {color:red; text-align:center;}
Quadro 51 Cdigo CSS

Para fazer o CSS mais legvel, voc pode colocar uma declarao em cada
linha, como este exemplo do Quadro 40:
p
{
color:red;
text-align:center;
}
Quadro 52 Cdigo CSS mais legvel

5.4.2.2.2.

Comentrios CSS

Comentrios so usados para explicar o seu cdigo, e pode ajudlo quando


voc editar o cdigofonte em uma data posterior. Comentrios so ignorados pelo
navegador.
Um comentrio comea com CSS "/*", e termina com "*/", como este, do
Quadro 41:

/ * Este um comentrio * /
p{text-align:center;color: black;font-family:Arial;}
Quadro 53 Cdigo de comentrio CSS

5.4.2.2.3.

Os seletores de id e class
160

Alm de definir um estilo para um elemento HTML, CSS permite que voc
especificar os seus prprios seletores chamado "id" e "classe".

a) O seletor id

O seletor id usado para especificar um estilo para um elemento nico e


exclusivo. O seletor usa o atributo id do elemento HTML e definido com um "#". A
regra de estilo aplicada para o elemento com id = "para1" (Quadro 42).
#para1
{
text-align:center;
color:red ;
}
Quadro 54 Cdigo de seletor id em CSS

Observao: No comear um nome de identificao com um nmero. No


ir funcionar no Mozilla / Firefox.

b) A classe Selector

O seletor de classe usada para especificar um estilo para um grupo de


elementos. Ao contrrio do seletor de id, seletor de classe mais freqentemente
usado em vrios elementos. Isto permitelhe definir um estilo especial para todos os
elementos de HTML com a mesma classe. O seletor classe usa o atributo class de
HTML, e definido com um "." No exemplo do Quadro 43, todos os elementos HTML
com class = "centro" sero alinhados ao centro.
.center {text-align:center;}
Quadro 55 Cdigo CSS de seletor classe

Tambm possvel especificar que apenas os elementos HTML especficos


devem ser afetadas por uma classe. No exemplo do Quadro 44, todos os elementos
com p class = "centro" ser alinhado ao centro. Exemplo:
161

p.center {text-align:center;}
Quadro 56 Cdigo CSS de seletor classe para tag p

Observao: No comear um nome de classe com um nmero! Isso s


suportado no Internet Explorer.

5.4.2.2.4.

Como inserir CSS

H trs maneiras de inserir uma folha de estilo:

Externo folha de estilos

Interno folha de estilo

Estilo inline

a) CSS Externa

Uma folha de estilo externa ideal quando o estilo aplicado a muitas


pginas. Com uma folha de estilo externa, voc pode mudar a aparncia de um site
inteiro mudando um arquivo. Cada pgina tem link para a folha de estilo usando a
tag <link>. A tag <link> vai dentro da seo head (Quadro 45):
<head>
<link rel="stylesheet" type="text/css"
href="mystyle.css" />
</head>
Quadro 57 Link Html para CSS externa

Uma folha de estilo externa pode ser escrito em qualquer editor de texto. O
arquivo no deve conter quaisquer tags HTML. A folha de estilo deve ser salvo com
uma extenso .css. Um exemplo de um arquivo de folha de estilo mostrado no
Quadro 58:

162

hr {color:sienna;}
p {margin-left:20px;}
body {background-image:url("images/back40.gif");}
Quadro 58 Exemplo de folha de estilo

Observao: No deixar espaos entre o valor da propriedade e as unidades


como em "marginleft:20 px" (correto: "marginleft:20px") ir funcionar no Internet
Explorer, mas no no Firefox ou Opera.

b) CSS Interna

Uma folha de estilo interna deve ser usado quando um documento nico, tem
um estilo nico. Voc define estilos internos na seo principal de uma pgina
HTML, usando a tag <style>, ver Quadro 59:
<head>
<style type="text/css">
hr {color:sienna}
p {margin-left:20px}
body {background-image:url("images/back40.gif")}
</style>
</head>
Quadro 59 Exemplo de cdigo CSS interno

c) CSS Inline

Um estilo inline perdese muitas das vantagens das folhas de estilo,


misturando contedo com apresentao. Use este mtodo com moderao! Para
usar estilos inline voc usar o atributo de estilo na marca relevante. O atributo style
pode conter qualquer propriedade CSS. O exemplo do Quadro 48 mostra como
alterar a cor e a margem esquerda de um pargrafo:
<p style="color:sienna;margin-left:20px">Este um pargrafo.</p>

163

Quadro 60 Exemplo de cdigo CSS inline

d) CSS Mltiplos

Se algumas propriedades foram definidas para o mesmo seletor em folhas de


estilos diferentes, os valores sero herdadas da folha de estilo mais especfico.
Por exemplo, uma folha de estilo externa tem estas propriedades para o
seletor h3 (Quadro 49):
h3{color:red; text-align:left; font-size:8pt;}

Quadro 61 Exemplo de cdigo CSS externo

E uma folha de estilo interna tem estas propriedades para o seletor h3


(Quadro 62):
h3{text-align:right; font-size:20pt;}
Quadro 62 Exemplo de cdigo CSS interno

Se a pgina com a folha de estilo interna tambm links para a folha de estilos
externa as propriedades para h3 ser:
color:red;
textalign:right;
fontsize:20pt
A cor herdado da folha de estilo e alinhamento do texto e fontsize passam
a ter a folha de estilo interna.
possvel tambm criar vrios arquivos CSS (ex: menu, topo, contedo e
rodap) e uslos no sistema, bastando referencilos nos seguintes locais da
pgina:
dentro de um elemento HTML
164

dentro da seo head de uma pgina HTML


em um arquivo CSS externo
De um modo geral, podese dizer que todos os estilos em cascata "em uma
nova folha de estilos" virtual "pelas regras a seguir, onde o nmero quatro tem a
maior prioridade:
1. Browser padro
2. Externo folha de estilos
3. Interno folha de estilo (na seo de cabea)
4. Estilo inline (dentro de um elemento HTML)
Assim, um estilo inline (dentro de um elemento HTML) tem a maior prioridade,
o que significa que ele ir substituir um estilo definido dentro da tag <head>, ou em
uma folha de estilo externa, ou em um navegador (um valor padro).
Observao: Se o link para a folha de estilo externa colocada aps a folha
de estilo interna em HTML <head>, a folha de estilos externa ir substituir a folha de
estilo interna!
Um excelente exemplo de aplicao de CSS o site CSS Zen Garden que
demonstra verdadeiramente que o design inteiro pode mudar apenas alterando o
estilo da pgina (CSS) e o contedo permanece idntico.

5.4.2.3.

DisplayTag

A biblioteca de tag de exibio uma sute open source de custom tags que
fornecem elevados padres de apresentao web que ir trabalhar em um modelo
MVC. A biblioteca fornece uma quantidade significativa de funcionalidade enquanto
ainda est sendo fcil de usar.
A DisplayTag trata da exibio da coluna, classificao, paginao, corte,
agrupamento e exportao, interligando e decorando com um mesmo estilo XHTML
personalizvel os dados fornecidos de uma lista.

5.4.2.3.1.

Recursos disponveis
165

Paginao Imagine uma aplicao web em que necessrio fazer uma


consulta ao banco de dados e retornar centenas de registros e apresentlos
pgina web. Como mostrar estas informaes sem visualizar uma tabela
enorme que demora muito para ser carregada no navegador? Uma soluo
clssica a paginao de resultados: quebrar uma coleo de registros em
vrias pginas de tamanho limitado. A DisplayTag suporta diversas
estratgias de paginao e oferece barras customizveis para a navegao
dos resultados.
Exportao de dados Atravs do recurso de exportao, que ativado
alterandose apenas um atributo, o usurio pode transformar a tabela exibida
para vrios formatos. A DisplayTag inclui filtros de exportao predefinidos
para CSV (valores separados por vrgulas), Excel, XML e PDF simples.
Internacionalizao

(i18n)

Normalmente

implementase

internacionalizao atravs de vrios arquivos texto (chamados resources),


um para cada idioma desejado. Estes arquivos so compostos de pares
chave=mensagem, sendo as chaves fixas e as mensagens customizadas
para o idioma. A DisplayTag suporta a internacionalizao dos cabealhos
das tabelas e das barras de paginao, entre outros elementos.
Flexibilidade visual com Decorator O design pattern Decorator,
implementado pela DisplayTag, aumenta a flexibilidade do design, atravs de
objetos que customizam ou adicionam dinamicamente comportamentos a
outro objeto. Geralmente utilizamse este pattern quando se precisa
visualizar uma informao de vrias formas diferentes. Por exemplo,
apresentar formatos distintos para datas, nmeros, valores monetrios etc.
sem precisar alterar a classe de negcio.

5.4.2.3.2.

As cinco tags fundamentais

A DisplayTag composta pelas tags caption, column, footer, setProperty e


table, todas com prefixo display. No Quadro 51 apresentado funo de cada uma
dessas tags.
166

Tag

Funo

caption

Cria um cabealho na tabela.

column

Cria uma coluna na tabela.

footer

Cria um rodap na tabela.

setProperty

Permite definir o valor de propriedades relacionadas paginao, exportao etc.

table

Cria uma tabela. Todas as outras tags da DisplayTag so utilizadas dentro desta
tag.

Quadro 63 Cinco tags fundamentais da tags do DisplayTag

As tabelas da Figura 64 foram geradas a partir de listas usando a tag


<display:table>:

Figura 64 Tabelas geradas pelo DisplayTag

(Fonte: http://displaytag.sourceforge.net/1.2/)

5.4.3 Ferramentas

5.4.3.1.

Corel Draw
167

O CorelDRAW um programa de desenho vetorial bidimensional para design


grfico desenvolvido pela Corel Corporation, Canad. um aplicativo de ilustrao
vetorial e layout de pgina que possibilita a criao e a manipulao de vrios
produtos, como por exemplo: desenhos artsticos, publicitrios, logotipos, capas de
revistas, livros, CDs, imagens de objetos para aplicao nas pginas de Internet
(botes, cones, animaes grficas, etc) confeco de cartazes, etc.
O CorelDRAW surgiu em 1988, apenas em ingls. Em 1995, surgiu a primeira
verso em 32 bits (CorelDRAW 6). Dois anos depois surgiu a primeira verso para
computadores Macintosh. No ano seguinte, foi lanada a primeira verso para Linux.
Em 2003, surgiu a verso 12 para Windows XP. A ltima verso criada em 2008 se
denomina Corel X4 ("X" em algarismos romanos =10 + 4= verso 14).
Em ambiente software proprietrio os concorrentes diretos so os programas
Adobe Illustrator e Macromedia Freehand. Em software livre, para ambiente Linux, o
principal concorrente o Inkscape.

5.4.3.2.

Adobe Photoshop

Adobe Photoshop um software caracterizado como editor de imagens


bidimensionais do tipo raster (possuindo ainda algumas capacidades de edio
tpicas dos editores vetoriais) desenvolvido pela Adobe Systems. considerado o
lder no mercado dos editores de imagem profissionais, assim como o programa de
fato para edio profissional de imagens digitais e trabalhos de primpresso.
Sua mais recente verso apelidada como Adobe Photoshop CS4 (sigla cujo
significado Creative Suite 4, correspondente dcima primeira edio desde seu
lanamento), disponvel para os sistemas operativos Microsoft Windows e Mac OS
X. Em software livre, para ambiente Linux, pode ser rodado atravs da camada de
compatibilidade Wine e o principal concorrente o Gimp.

5.5

Componente: Comportamento

A camada de comportamento contm todos os efeitos e todas as decises


funcionais da interface. Manter a programao separada da estrutura facilita a
168

manuteno e evita erros.

5.5.1 ECMAScript ou JavaScript

O Nome oficial do JavaScript ECMAScript (desenvolvido e mantido pela


organizao ECMA). A lnguagem foi criada por Brendan Eich da Netscape e tem
aparecido em todos os browsers Netscape e da Microsoft desde 1996.
JavaScript foi concebido para adicionar interatividade a pginas HTML.
Segundo a (W3SCHOOLS), JavaScript significa:
JavaScript uma linguagem de script. A linguagem de script uma
linguagem

de

programao

leve.

JavaScript

normalmente

incorporada diretamente em pginas HTML. JavaScript uma


linguagem

interpretada

(significa

que

executar

scripts

sem

compilao preliminar). Todos podem usar o JavaScript sem comprar


uma licena. (Traduo nossa)

Na lista abaixo seguem algumas possibilidades do JavaScript, que


ultrapassam os limites da linguagem de marcao HTML e da linguagem de estilos
CSS que incluem:
Efetuar operaes matemticas;
Gerar pginas de acordo com caractersticas do browser e do computador do
cliente e em tempo de carregamento;
Tratar determinados eventos, interagindo com o usurio atravs desse
tratamento;
Manipular janelas do browser, inclusive trocando informaes entre janelas;
Modificar propriedades da pgina dinamicamente, pois essa considerada
um conjunto de objetos;
Efetuar verificao de formulrios.

5.5.2 Apache Tiles

169

De acordo com a Apache Sofware Foundation (2009), Apache Tiles um


framework de templating construdo para simplificar o desenvolvimento de interfaces
de usurio da aplicao web.
Tiles framework era anteriormente chamado framework de componentes,
Tiles um framework open source para fazer a camada de apresentao de
trabalho muito mais fcil pela eliminao de grande quantidade de retrabalho e
cdigos repetidos. So muito teis quando uma aparncia comum entre todas as
pginas so necessrios, faz a manuteno do cdigo muito fcil e uma separao
de distribuio de contedo.
Tiles baseiase na <include> oferecida pela especificao JavaServer Pages,
assim, deixandoo mais vivel criar pginas reutilizveis. Ela ajuda a fornecer um
framework completo e robusto para a montagem de pginas de apresentao de
componentes de peas. Cada parte ("Tile") pode ser reutilizado quantas vezes for
necessrio em toda a sua aplicao. Isto reduz a quantidade de marcao que deve
ser mantida e torna mais fcil mudar a aparncia de um website. Podese dizer que
Tiles so como componentes visuais.
Um layout uma pgina JSP especial que permite que os pedaos de
pginas sejam inseridos. A estrutura usa um arquivo de configurao XML para
organizar as peas. E o framework no s permite a reutilizao de peas, mas
tambm os esquemas que organizlos.

5.6

Case Porto Bello

Conforme relatado anteriormente o objetivo geral deste trabalho


implementar uma ferramenta de hotelaria utilizando uma arquitetura em trs
camadas e os padres de projeto (design patterns), facilitando o controle das
operaes bsicas de um hotel (hospedagem e reservas), utilizando um design
sofisticado, com as opes bem distribudas e prticas para uso dirio, atravs de
uma interface simples, possibilitando a automatizao de todo o servio de
gerenciamento, atendendo as necessidades do cliente e permitindo que os usurios
tenham acesso s informaes e sejam mais produtivos no trabalho.
Ao analisar este objetivo e separar as funes especficas onde o projeto de
170

inteface atuaria constatouse dois desafios:


Do lado do sistema: Na arquitetura MVC (Model View Controler) o View
deve ser bem estruturado (seguindo os padres W3C) separando o
cdigo do contedo com o cdigo do layout para facilitar o
desenvolvimento e manuteno do sistema.
O lado do usurio: Desenvolver uma interface com um layout sofisticado,
simples e intuitivo que possibilite ao usurio a facilidade de utilizao do
sistema e ganho de produo no trabalho executado.
A documentao do sistema (relatrio de entrevistas com o cliente,
documentos de requisitos, diagramas UML) foi de grande importncia para o
sucesso do entendimento do problema.
Depois de vrias anlises foi possvel concluiuse que era necessrio criar
um prottipo esttico. As ferramentas utilizadas no desenvolvimento do layout foram
o CorelDraw (Corel) e Photoshop (Adobe). Somente aps finalizar o prottipo
esttico em sua terceira verso o prottipo dinmico foi iniciado e concludo
utilizando o editores Dreamweaver (Adobe) e Eclipse.
A primeira tela de acesso ao Sistema de Gerenciamento de Hotelaria Porto
Bello a de login que executa a autenticao do usurio (ver Figura 59).

Figura 65 Tela de login

Aps a validao da autenticao o sistema redireciona o usurio para a


tela de abertura (Home) do site. Notase que na Figura 60 o usurio Administrador
foi autenticado com sucesso.

171

Figura 66 Tela de Home

O sistema est estruturado e dividido em quatro reas: topo, navegao,


contedo e rodap.
O Topo contm (localizado a esquerda na parte superior) a imagem da
identidade visual da empresa. Seguindo a direita encontrase o ttulo do mdulo e o
nome do usurio autenticado. Abaixo h uma imagem (montagem da sala de
recepo e um quarto) do hotel. Para navegao foi escolhido um menu tipo barra
(por ocupar pouco espao na tela e estar em posio de destaque) que direciona os
usurios para as reas de interesse: apartamento, funcionrio, hspede,
reserva/hospedagem, mapa de acomodaes, usurio e fechar.
Na rea do contedo todas as pginas contm um ttulo que destaca das
informaes acessadas atravs menu e submenu do sistema e para exibio das
listas foi utilizada a biblioteca DisplayTag. cones foram inseridos nas pginas para
tambm ajudar com a intuio e ganho de produtividade do usurio na execuo das
funes do sistema. O rodap contm as informaes de direitos autorais da
empresa e a empresa desenvolvedora do sistema.
O topo, navegao e rodap so contedos estticos e somente o contedo
dinmico. Esto codificados separadamente e so montados dinamicamente atravs
do framework Tiles.
Os Quadros 52, 53, 54 mostram o cdigo do topo, menu e rodap
respectivamente. O menu foi elaborado sem o uso de tabelas para diagramao do
contedo conforme especificao do W3C Standard (utilizao de lista para
organizao dos itens do menu).

172

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"


pageEncoding="ISO-8859-1"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<c:url var="img" value="/img/"/>
<table WIDTH="770" HEIGHT="42" BORDER="0"
CELLPADDING="0" CELLSPACING="0">
<tr HEIGHT="100%">
<td WIDTH="9"></td>
<td WIDTH="175"><img SRC="${img}topo1.gif"></td>
<td WIDTH="2"></td>
<td WIDTH="390" CLASS="destaque_blue">
<span CLASS="style2">
M&oacute;dulo Admin</span>istrativo</td>
<td WIDTH="37"><img SRC="${img}user.gif"></td>
<td WIDTH="157" CLASS="normal">Administrador</td></tr>
</table>
<table WIDTH="770" HEIGHT="94" BORDER="0"
CELLPADDING="0" CELLSPACING="0">
<tr HEIGHT="100%">
<td WIDTH="100%"><img SRC="${img}topo2.gif"></td></tr></table>

Quadro 64 Cdigo do arquivo header.jsp

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"


pageEncoding="ISO-8859-1"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<c:url var="jsp" value="/jsp/"/>
<c:url var="img" value="/img/"/>
<ul>
<li><a HREF="${jsp}apartamentoForm.do">
<span>Apartamento</span></a></li>
<li><a HREF="${jsp}funcionarioForm.do">
<span>Funcion&aacute;rio</span></a></li>
<li><a HREF="${jsp}hospedeForm.do">
<span>H&oacute;spede</span></a></li>
<li><a HREF="${jsp}reservaHospedagemForm.do">
<span>Res/Hospedagem</span></a></li>
<li><a HREF="${jsp}mapaAcomocacoesForm.do">
<span>Mapa de Acomodaes</span></a></li>
<li><a HREF="${jsp}usuarioForm.do">
<span>Usurio</span></a></li>
<li><a CLASS="right" HREF="#">
<span>Fechar </span></a></li></ul>

Quadro 65 Cdigo do arquivo menu.jsp

01 <%@ page language="java" contentType="text/html; charset=ISO-8859-1"


02
pageEncoding="ISO-8859-1"%>
03
04 <span CLASS="rodape"><br/>
05
&copy; 2007 &bull; Porto Bello Palace Hotel &bull; Powered by
06
<a HREF="#">SIG5 Solutions</a></span>

Quadro 66 Cdigo do arquivo footer.jsp

173

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"


pageEncoding="ISO-8859-1"%>
<%@ taglib uri="http://struts.apache.org/tags-tiles-el" prefix="tiles"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<c:url var="css" value="/css/"/>
<c:url var="img" value="/img/"/>
<c:url var="jsp" value="/jsp/"/>
<html>
<head>
<title>:: PORTO BELLO PALACE HOTEL ::</title>
<style type="text/css" media="screen">
@import "${css}header.css";</style>
<style type="text/css" media="screen">
@import "${css}toolbar.css";</style>
<style type="text/css" media="screen">
@import "${css}body.css";</style>
<style type="text/css" media="screen">
@import "${css}footer.css";</style>
</head>
<body STYLE="margin-top: 10px; margin-bottom: 0px;
margin-left: 0px; margin-right: 0px;">
<div ID="TableBody">
<div ID="header_img">
<tiles:insert attribute="header"/>
</div>
<div ID="vista_toolbar">
<tiles:insert attribute="menu"/>
</div>
<div ID="body_page">
<table BORDER="0" CELLPADDING="0" CELLSPACING="0" >
<tr >
<td WIDTH="12" BACKGROUND="${img}body_left.gif"></td>
<td WIDTH="745" VALIGN="TOP" >
<span CLASS="destaque_blue">
<br></span>
<tiles:insert attribute="body"/>
</td>
<td WIDTH="13" BACKGROUND="${img}bory_rigth.gif"></td>
</tr>
</table>
</div>
<div ID="body_page_down">
<table WIDTH="100%" HEIGHT="100%" BORDER="0" CELLPADDING="0"
CELLSPACING="0">
<tr>
<td WIDTH="12" BACKGROUND="${img}body_left_down.gif"></td>
<td WIDTH="745" BACKGROUND="${img}body_center_down.png"></td>
<td WIDTH="13" BACKGROUND="${img}body_rigth_down.gif"></td>
</tr>
</table>
</div>
<div ID="footer">
<tiles:insert attribute="footer"/>
</div>
</div>
</body></html>

Quadro 67 Cdigo do arquivo layout.jsp

O Quadro 55 mostra o cdigo do template layout.jsp, esta pgina contm tags


174

Tiles de insero para montagem das partes do sistema. Tambm contm links para
incluso de css externo (header.css, toolbar.css, body.css e footer.css).

5.7

Navegao do site Porto Bello

A Figura 61 representa a navegao do sistema que conforme dito


anteriormente acessada atravs da barra de navegao aps feita a autenticao.
Cadastrar
Apartamento
Manter
Cadastrar
Funcionrio
Manter
Cadastrar
Hspede
Manter
Login
Cadastrar
Res/Hospedagem
Procurar

Mapa de
Acomodaes

Usurio

Figura 67 Diagrama de Navegao do sistema

175

A Figura 68 mostra a tela de cadastro de cadastro de hspede.

Figura 68 Tela de Cadastro de Hspede

possvel visualizar na Figura 63 a tela de exportao dos dados dos


apartamentos em planilha excel.

Figura 69 Tela de Exportao de dados para planilha Excel

176

Com a recomendao W3C para arquitetura web (estrutura, apresentao


e comportamento separados e complementares) foi possvel planejar um projeto de
interface bem estruturado e executlo em conjunto com as outras reas do
sistema. Com esse padro implementado, o trabalho de alterao do layout do site
fica mais fcil, pois os desenvolvedores somente precisaro atualizar os arquivos
CSS e o template que o cdigo do contedo no ser alterado.

177

PERSISTNCIA DE DADOS

6.1

Introduo

Bancos de Dados (ou bases de dados) so conjuntos de registros


estruturados que normalmente agrupam registros utilizveis para um mesmo fim.
Esses dados so organizados de forma a se reorganizar para produzir informao.
Um Banco de Dados normalmente gerenciado por um conjunto de
softwares conhecidos como Sistema Gerenciador de Banco de Dados (SGBD). O
objetivo principal de um SGBD o gerenciamento de base de dados retirando da
aplicao cliente a responsabilidade de controle ao acesso e a manipulao dos
dados, mas permitindo que os mesmo possam incluir, alterar, excluir ou consultar os
registros na base de dados contidos.
Os Bancos de dados podem ser classificados quanto ao seu modelo de
organizao estrutural. O modelo mais adotado nos dias de hoje o Modelo
Relacional, que consiste em uma organizao em forma de tabelas compostas por
linhas e colunas construindo um Banco de Dados.
Os Bancos de Dados so utilizados em diversos tipos de aplicaes,
abrangendo todo tipo de softwares que necessitam de um armazenamento de
dados. Os Bancos de Dados so a forma mais utilizada de armazenamento e
produo

de

informao.

Uma

BD

utiliza

tecnologias

padronizadas

de

armazenamento.
Um Banco de Dados pode ou no ser armazenado de forma legvel para um
computador. Um Banco de Dados pode ter um tamanho bem reduzido, sendo
armazenado em arquivos nicos de pequeno porte e possuindo apenas algumas
tabelas. Mas tambm pode ter milhares de tabelas com milhes de registros que
ocupem dimenses fsicas extremamente grandes.
Os primeiros Bancos de dados considerados modernos, como os que
dispomos nos dias de hoje, foram concebidos por Charles Bachman na dcada de
1960.

178

6.2

Sistema de Gerenciamento Porto Bello

O empenho em analisar e acompanhar as preferncias de armazenamento


assume importante posio na escolha da tecnologia a ser usada, no tipo de
organizao estrutural e na criao das estruturas que atendem as necessidades da
aplicao.
No projeto do Banco de Dados da nossa aplicao tem como objetivo
armazenar os dados referentes ao gerenciamento de reservas de quartos e a
hospedagem.

Tambm foram criadas estruturas para armazenar informaes

referentes ao funcionrio, ao hspede e ao apartamento, que so informaes


necessrias para realizar tanto a reserva quanto a hospedagem.
Foram criadas tabelas que identificam com clareza a necessidade de
armazenamento de dados do nosso cliente, sendo assim seus dados persistem em
uma estrutura externa a aplicao, ficando assim protegidos contra falhas na
operao da aplicao ou mesmo falhas da aplicao.

6.3

SGBD Sistema de Gerenciamento de Bancos de Dados

O SGBD escolhido para ser utilizado no desenvolvimento e na manuteno


do nosso Banco de Dados o MySQL que um sistema que utiliza a linguagem
SQL (Linguagem de Consulta Estruturada) como interface. O MySql o SGDB mais
utilizado atualmente.
O MySql foi criado pela empresa MySql AB e os responsveis pelo seu
surgimento foram David Axmark, Allan Larsson e Michael Widenius, no entanto a
equipe de desenvolvimento e manuteno de cerca de quatrocentas profissionais
e mais mil colaboradores. O software gratuito e pode ser facilmente encontrado
para download na Internet.
Uma das principais caractersticas do SGBD a possibilidade de colaborao
de vrias pessoas ao redor do mundo que contribuem testando o software,
integrandoo a outros produtos, escrevendo a respeito dele e alterando o software,

179

criando assim novas distribuies que so compartilhadas entre os usurios.


No incio de 2008 a empresa Sun Microsystems comprou a empresa MySql
AB pelo valor de 1 Bilho de dlares, sendo este o maior valor j pago no setor de
licenas livres. Em Abril de 2009 a empresa Oracle comprou a Sun Microsystems e
todos os seus produtos inclusive o MySql.
Dentre alguns usurios do MySql esto: NASA, Friendster, Banco Bradesco,
Dataprev, HP, Nokia, Sony, Lufthansa, U.S Army, US. Federal Reserve Bank,
Associated Press, Alcatel, Slashdot, Cisco Systems e CanaVialis S.A.
As principais caractersticas do SGBD MySql so: controle de transies e a
utilizao de Stored Procedures, Triggers e Funes. Essa quatro caractersticas
contribuem para a popularidade do software. Alem disso outro ponto que ajuda na
disseminao do MySql o fato de ser um software de cdigo livre.

6.4

Arquitetura do Banco de Dados

A idia geral de um Banco de Dados simplesmente armazenar os dados de


um determinado sistema a fim de recuperlo posteriomente, alteralo quando
necessrio e principalmente gerar informao atravs do cruzamento e interpretao
dos dados nele contidos. No entanto nem sempre o usurio do sistema tem idia de
como esse armazenamento feito fisicamente no disco.
Para que fosse representada tal abstrao do armazenamento dos dados
foram definidos trs nveis conceituais de organizao: o nvel fsico, o nvel
conceitual e o nvel de visualizao. No nvel fsico so definidas as configuraes
do Banco de Dados, tais como localizao dos arquivos em disco e suas
configuraes. O nvel conceitual onde so definidas as caractersticas dos dados,
tais como seu tipo, suas restries e seus relacionamentos. E o nvel de visualizao
onde o usurio do sistema ter acesso aos dados contidos no banco abstraindo
assim todo conceito e configurao definida nos nveis anteriores.

180

6.5

Modelador de Dados CA Erwin

O Modelador CA Erwin foi ferramenta escolhida para fazer a modelagem do


diagrama de entidade e relacionamentos (DER) do nosso Banco de Dados. O CA
Erwin, tambm conhecido somente por Erwin pertence ao conjunto de programas de
apoio ao desenvolvimento de software normalmente chamados de Ferramentas
Case.
A ferramenta de extrema facilidade de uso e permite ao desenvolvedor
especificar os dados e tabelas envolvidas e seus relacionamentos. Atravs da
ferramenta possvel gerar scripts de criao de bancos bem com o processo
inverso, ou seja, a engenharia reversa. Alm disso, a ferramenta permite tambm a
criao dos mecanismos de sincronizao de dados necessrios. Todos esses
pontos a tornam um dos softwares mais utilizados na rea de modelagem de dados.

6.6

Diagrama de Entidades e Relacionamentos (DER)

Diagrama de entidade e relacionamento um modelo diagramtico o que


descreve conceitualmente o Modelo de Entidades e Relacionamentos. Sua principal
funo representar e um alto nvel de abstrao as tabelas, os atributos e as
relaes existentes no Banco de Dados.
Abaixo, a figura 61 representando o DER do Sistema de Gerenciamento Porto
Bello.

181

Figura 70 DER

182

6.7

Tabelas

O Banco de Dados desenvolvido possui 8 tabelas, sendo que estas sero


descritas a seguir.
Tabela pessoa: responsvel em manter os dados referentes a todas as
pessoas que tem o cadastro efetuado pelo sistema ou que tenham acesso ao
sistema. Sua chave primria o atributo id_pessoa_cpf, que apesar de ter o
prefixo id o campo uma chave natural. Todas as pessoas cadastradas no
sistema possuem um usurio para acesso, por isso foi criada um foreign key
da tabela usurio.
Tabela funcionrio: uma especializao da tabela pessoas. A tabela
funcionrio guarda os dados referentes aos funcionrios da empresa, tanto os
que utilizam o sistema quanto os funcionrios que no o utilizam. Sua chave
primria o atributo id_pessoa_funcionario que apesar de tero prefixo id o
campo uma chave natural. A tabela funcinrio possui uma foreign key com
cardinalidade um para um chamada id_pessoa_cpf, no entanto devido
modelador do Diagrama de Entidades e Relacionamentos e ao tipo de
relacionamento no foi possvel representar graficamente, mas na construo
do Banco de Dados foi inserido.
Tabela usurios: a tabela na qual sero gravados os dados referentes aos
funcionrios que possuem acesso ao sistema. Os dados dessa tabela so
utilizados no login e conseqentemente no controle de acesso aos casos de
uso do sistema. Sua chave primria o atributo id_usuario, que apesar de
identificar o usurio no usado para a realizao do login. A tabela possui
um foreign key chamada id_grupo referente a tabela grupo.
Tabela grupo: para a implementao do controle de acesso do sistema foi
concebida a idia de criar uma tabela que serviria de parmetro para a
separao entre os diferentes nveis de acesso. Essa tabela possui apenas
um identificador e uma descrio, atravs desse identificador se define o
acesso que o usurio ter no sistema. Sua chave primria o atributo
id_grupo.
Tabela hospedes: a tabela que persiste os dados referentes ao hspedes
183

do hotel. a tabelas mais acessadas do sistema, pois alm de possuir telas


de insero, edio, excluso e de visualizao, ainda est presente nos
principais casos de uso do sistema, que so o Cadastro de Reserva, Chek In
e Check Out. Sua chave primria o atributo id_pessoa_hospede. A tabela
hospede possui uma foreign key referenciando a tabela pessoa. Devido ao
tipo de relacionamento entre as tabelas pessoa e hospede no foi possvel
representar a foreign key graficamente.
Tabela apartamento: responsvel por guardar os dados referentes aos
apartamentos existentes no hotel. Seu atributo chave id_apartamento_num,
que apesar de ter o prefixo id o campo uma chave natural. Sua chave
primria o atributo id_apartamento_num. O atributo id_tipo_apartemento
uma foreign key referenciando a tabela tipo_apartamento.
Tabela tipo_apartamento: a tabela onde ficaram definidos os tipos de
apartamentos que existem no hotel. Sua chave primria o atributo
id_tipo_apartamento.
Tabela reserva_hospedagem: o corao da aplicao. As principais
funes do sistema tm por base essa tabela. A tabela reserva_hospedagem
registra todas as informaes referentes s reservas e hospedagens
realizadas no hotel. A diferenciao entre os dois tipos de registro feita
atravs da uma anlise aos campos persistidos, caso apenas os campos de
data dt_entrada e dt_saida estejam populados o registro se refere a uma
reserva, caso alm desses dois campos o campo dt_check_in estiver
preenchido quer dizer que o registro se refere a um hospedagem iniciada, e
caso alm desses trs campos o campo dt_check_out tambm estiver
preenchido o registro se refere ao uma hospedagem concluda. Sua chave
primria composta e formada pelos atributos id_res_hospedagem e
id_pessoa_cpf.

6.8

Hibernate

Hibernate um framework escrito na linguagem Java para realizar o


184

mapeamento objetorelacional, ou seja, faz a ligao entre uma classe de um


programa Java a uma tabela do Banco de Dados, e faz a correlao entre uma
varivel de uma classe Java ao uma coluna ou atributo de uma tabela no Banco de
Dados.
A principal caracterstica do Hibernate reduzir a complexidade na relao
entre um programa Java e um Banco de Dados.

6.8.1 Arquivo hibernate.cfg.xml

Para realizao do mapeamento entre a classe Java e a tabela na Base de


Dados, escrito um arquivo de configurao chamado hibernate.cfg.xml que ser
mostrado no Quadro 56.

Quadro 68 Arquivo de Configurao hibernate.cfg.xml

A configurao realizada no arquivo

hibernate.cfg.xml apenas o

mapeamento entre classe e tabela, para que se mapeie as variveis das classe com
as colunas do Banco de Dados criado um arquivo *.hbm.xml. So criados vrios
arquivos de configurao entre varivel e coluna, sendo que cada arquivo
rsponsvel por configurar as variveis de uma classe a uma tabela, sendo
necessrias ento um arquivo por mapeamentos desejados. Por exemplo para
mapear a tabela funcionrios criasse o arquivo funcionrios.hbm.xml. Segue abaixo
185

a representao desse arquivo.

Quadro 69 hbm.xml

Nesse captulo foi demonstrado como foi planejada a parte de persistncia de


dados do Sistema de Gerenciamento Porto Bello, desde a escolha das tecnologias e
frameworks at a configurao entre a aplicao e a Base de Dados.
Aps todo o mapeamento realizado pelos arquivos de configurao basta
apenas informar classe que se deseja fazer acesso e atravs de uma classe DAO
(Data Access Object). Nessa classe esto escritos os mtodos responsveis pela
manipulao dos dados.

186

CONCLUSES

O crescimento da utilizao de sistemas web est em ritmo acelerado o que


torna imprescindvel a adoo de tais sistemas em ambientes onde a velocidade e a
adaptabilidade so fatores fundamentais.
Analisando as necessidades do cliente, as suas exigncias e tambm o
ambiente onde o sistema ser implantado, ento foram escolhidas as ferramentas,
as metodologias, os frameworks e a linguagem que atende melhor o cliente.
Atravs da anlise foi possvel planejar um sistema gil e confivel e que
possui a possibilidade de qualquer computador da rede do hotel, necessitando
apenas ter acesso Internet.
Foi adquirido conhecimento em frameworks Struts e Hibernate, do padro
MVC, que foram utilizados nesse sistema. A integrao dos frameworks juntamente
com os padres de projeto resultou na arquitetura em si, estruturando um fluxo bem
definido das requisies clienteservidor.
O resultado que realmente marca esse projeto, sem duvida o aprendizado,
a experincia e a viso do mercado de trabalho, perceptvel o amadurecimento
tcnico e gerencial agregado, e a juno dos esforos durante essa maravilhosa
empreitada foi transformado em uma aplicao, e documentao que satisfez as
especificaes e requisitos solicitados, superando as expectativas iniciais.
Os resultados obtidos so fruto da dedicao e comprometido de toda equipe
envolvida no planejamento, sendo que cada integrante foi responsvel por uma
parte do projeto, escolhendo a metodologia, as ferramentas e trabalhando na
representao da idia em forma de formulrios, documentos e diagramas tornando
assim a concepo da idia por atores externos ao planejamento, fcil e desprovida
de entendimento ambguo.
As experincias adquiridas pelos integrantes da equipe foram de grande valia
para a utilizao no mundo coorporativo, pontos como o trabalho em equipe, o
comprometimento com prazos e principalmente a experincia na parte de analise e
projeto de sistemas voltados para web utilizando a plataforma J2EE. Portanto o
187

principal resultado obtido durante esse projeto foi o crescimento profissional de toda
equipe que hoje est apta a desenvolver atividades semelhantes fora do ambiente
acadmico.

188

REFERNCIAS

ALUR D.; CRUPI J.; MALKS D. Core J2EE Patterns:as melhores prticas e
estratgias de design. Elsevier Editora Ltda: 2004.
ALVIM, P. Tirando o Mximo do J2EE com jCompany. So Paulo, 2006.150p.
ANGOTI, E. Desenvolvimento de Sistemas I. Uberlndia: Faculdade de Cincias
Aplicadas de Minas. Apostila. Disponvel em:
<http://si.uniminas.br/~angoti/arquivos/tiles.pdf>. Acesso em: 13 out. 2009.
APACHE SOFTWARE FOUNDATION. Tiles 2. Forest Hill, MD, USA. 2009.
Disponvel em: <http://tiles.apache.org/> Acesso em: 13 out. 2009.
AVELAREDUARTE. Localizao dos elementos interface web. 2009.
Disponvel em:
<http://www.avellareduarte.com.br/projeto/interface/interface1/interface1_composica
o.htm>. Acesso em: 22 nov. 2009.
______. Componentes da interface web. 2009. Disponvel em:
<http://www.avellareduarte.com.br/projeto/interface/interface8/interface8.htm>.
Acesso em: 02 dez. 2009
BAUER C.; KING G. Hibernate em ao. Rio de Janeiro: Editora Cincia Moderna
Ltda. 2005.
BACAL JNIOR, SILVIO. Arquitetura de software baseada numa abordagem
UML/Redes de Petri com preveno de bloqueio mortal em sistemas de tempo
real. Mestrado. Uberlndia, 2003. 173p.
BODOFF S; ARMSTRONG E; BALL J; Tutorial do J2EE Enterprise Edition 1.4.
Rio de Janeiro: Editora Cincia Moderna Ltda. 2002.
BORTOLASSI, Giuliano. Uma breve introduo ao JEE: conhecendo o JEE.
Disponvel em <http://jeenoob.blogspot.com/2007/01/conhecendoojee
part1.html>. Acesso em: 01 jun. 2009.
DEITEL, H.M; DEITEL, P.J. Java: como programar. Traduo de Edson
Furmankiewicz So Paulo: Pearson Prentice Hall, 2005. 1110p
DIAS, C. Usabilidade na web: criando portais mais acessveis. Rio de Janeiro: Alta
Books, 2002. 312 p.
FOUNDATION, The Apache Software. Welcome to Struts 1. Disponvel em
<http://struts.apache.org/1.3.10/index.html>. Acesso em: 01 jun. 2009.
FRAGMENTAL Tecnologia. MVC e Camadas. Disponvel em:
<http://www.fragmental.com.br/wiki/index.php/MVC_e_Camadas>. Acesso em: 01
mai. 2009.

189

FURLAN, J.D. Modelagem de Objetos a travs da UML Unified Modeling


Language. So Paulo: Makron Books, 1998. 329p.
Gaudel, M-C., Marre, B., Schilienger, F. Bernot, G. Prcis de gnie logiciel.
Masson: 1996. 437p.
HOOK, David. Beginning Cryptography with Java. Indianapolis: Wrox, 2005. 448p.
HUSTED T. Struts em ao. Rio de Janeiro: Editora Cincia Moderna Ltda. 2004.
IBRAU. cones, grandes aliados do projetista. 2006. Disponvel em:
<http://www.ibrau.com.br/artigoicones.htm>. Acesso em: 05 dez. 2009.
JAVA Community Process. Community Development of Java Technology
Specifications. Disponvel: <http://jcp.org/aboutJava/communityprocess/pr/jsr244/>.
Acesso em: 01 jun. 2009.
JUNIOR,E.; SEGUNDO,A. Historico dos Banco de Dados. Eduardo Junior
Alonso Segundo. Disponvel em:
<http://disciplinas.dcc.ufba.br/svn/MATA60/tarefa1/historico/historico.pdf?revision=2>
. Acesso em 05 ago. 2009
KING, A. Clickstream Study Reveals Dynamic Web. 2006. Washtenaw County,
Michigan USA. Disponvel em:
<http://www.websiteoptimization.com/speed/tweak/clickstream/>. Acesso em: 03
dez. 2009
LEITE, J. C. Projeto de Interfaces de usurio. 2001. 10f. Tese (Mestrado)
Universidade Federal do rio Grande do Norte, Rio Grande do Norte. Disponvel em:
< http://www.dimap.ufrn.br/~jair/piu/JAI_Apostila.pdf>. Acesso em: 08 jun. 2008.
LINEBACK, N. Graphical User Interface Timeline. 2006. Disponvel em:
<http://toastytech.com/guis/guitimeline.html>. Acesso em: 08 jun. 2008.
LINWOOD, J. Determine the best elements for Web site navigation. 2003.
Disponvel em: <http://articles.techrepublic.com.com/510010878_11
1058652.html?tag=nl.e055>. Acesso em: 02 dez. 2009
LLOID,I. Accessible HTML/XHTML Forms. Disponvel em:
<http://www.webstandards.org/learn/tutorials/accessibleforms/beginner/>. Acesso
em: 04 dez. 2009.
MACORATTI, J.C. Padres de Projeto: o modelo MVC Model View Controller.
Artigo disponvel em <http://www.macoratti.net/vbn.htm> Acesso em: 01 jul. 2009.
MACROMEDIA DREAMWEAVER HELP. Dreamweaver Basics: Intrudoction. 1997
MARKETSHARE. Screen Resolutions. 2009. Disponvel em:
<http://marketshare.hitslink.com/report.aspx?qprid=17&qptimeframe=M&qpsp=129&
qpct=3&qpmr=10>. Acesso em: 01 nov. 2009.

190

MCCLURG, J. Designing for the Web. 2006. Disponvel em: < http://www.digital
web.com/articles/designing_for_the_web/>. Acesso em: 02 nov. 2009.
NIELSEN, J. Projetando websites. Traduo de Ana Gibson Rio de Janeiro:
Enselvier, 2000 5 reimpresso. 416p. Ttulo origina: Designing web usability.
______. Breadcrumb Navigation Increasingly Useful. Fremont CA USA. 2007.
Disponvel em: <http://www.useit.com/alertbox/breadcrumbs.html>. Acesso em: 03
dez. 2009.
______. RightJustified Navigation Menus Impede Scannability. Fremont CA
USA. 2008. Disponvel em: <http://www.useit.com/alertbox/navigationmenu
alignment.html>. Acesso em: 02 nov. 2009.
______. Screen Resolution and Page Layout. Fremont CA USA. 2006. Disponvel
em: <http://www.useit.com/alertbox/screen_resolution.html>. Acesso em: 02 nov.
2009.
______. Scrolling and Scrollbars. Fremont CA USA. 2005. Disponvel em:
<http://www.useit.com/alertbox/20050711.html>. Acesso em: 03 dez. 2009.
SANTOS, E. Web Standard. 62 p. Slide. So Paulo: Campus Party. Disponvel em:
<http://www.agni.art.br/palestras/webstandardsnocampusparty>. Acesso em: 24
ago. 2009.
SCHNEIER, Bruce. Applied Cryptography. New York: John Wiley and Sons, 1996.
758p.
SCIARRETTA, T. Clientes de baixa renda j so maioria nas compras online.
So Paulo: Folha online. 2007. Disponvel em:
<http://www1.folha.uol.com.br/folha/dinheiro/ult91u353177.shtml>. Acesso em: 03
jun. 2008.
SHACHOR, G; CHACE, A; RYDIN,M; Java Server Pages: biblioteca de tags.
Traduo de Rejane Freitas Rio de Janeiro: Editora Cincia Moderna Ltda, 2002.
594p.
SCHNEIDER, G. WINTERS, J. P., Applying Use Cases a Practical Guide. Ed.
Addison Wesley. USA 1998.
SILVA, M.S. Construindo formulrios HTML/XHTML acessveis. 2006. Disponvel
em: <http://maujor.com/tutorial/formaca.php>. Acesso em: 04 dez. 2009.
SOFTECH NETWORK. Treinamento Java. Disponvel em:
<http://java.danieldestro.com.br/>. Acesso em: 01 jul. 2009.
SPOLSKY, J. Projeto de Interface com Usurio para Programadores. 2000.
Disponvel em: <http://brazil.joelonsoftware.com/uibook/chapters/1.html> Acesso em:
17 ago. 2009.

191

SOMMERVILLE, Ian. Engenharia de Software. Traduo de Maurcio de Andrade.


6. ed. So Paulo: Person Education do Brasil, 2003. 591 p. Ttulo Original: Software
Engineering.
W3SCHOOLS. HTML Introduction. Disponvel em:
<http://www.w3schools.com/html/html_intro.asp> Acesso em: 27 ago. 2009.
______. CSS Introduction. Disponvel em:
<http://www.w3schools.com/css/css_intro.asp> Acesso em: 30 set. 2009.
______. Introduction to XML. Disponvel em:
<http://www.w3schools.com/xml/xml_whatis.asp> Acesso em: 27 ago. 2009.
______. JavaScript Introduction. Disponvel em:
<http://www.w3schools.com/js/js_intro.asp> Acesso em: 05 dez. 2009.
______. XHTML Introduction. Disponvel em:
<http://www.w3schools.com/xhtml/xhtml_intro.asp> Acesso em: 27 ago. 2009.
WEB STANDARDS PROJECT. WaSP: Fighting for Standards. Disponvel em:
<http://www.webstandards.org/about/mission/>. Acesso em: 24 ago. 2009.
WIKI,ECLIPCE. Where did Eclipse come from?. 2004. Disponvel em:
<http://wiki.eclipse.org/FAQ_Where_did_Eclipse_come_from%3F> Acesso em: 13
set. 2009.
ZELDMAN, J. Projetando Web Sites compatveis: como construir web sites
compatveis com browsers e dispositivos variados. Traduo de Altair Dias Caldas
de Moraes Rio de Janeiro: Enselvier, 2003. 412p.

192