UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

ESCOLA POLITCNICA
DEPARTAMENTO DE ELETRNICA E DE
COMPUTAO

ENGENHARIA DE SOFTWARE APLICADA WEB

ORIENTAO A OBJETOS

Autores:

Lucas Lopes Alenquer

Orientador:

Prof. Antnio Cludio Gmez de Sousa

Examinador:

Prof. Marcelo Luiz Drumond Lanza

Examinador:

Prof. Srgio Palma da Justa Medeiros

DEL
Dezembro de 2005

Resumo
O trabalho desenvolvido realizou uma iterao sobre um processo de desenvolvimento de
uma aplicao Web j em fase de produo, adicionando novos requisitos e considerando a
orientao a objetos.
Ao longo do trabalho so discutidas boas prticas no processo de Engenharia de Software e
problemas, limitaes e vantagens ao adotar a orientao a objetos para uma aplicao Web.
Os resultados obtidos foram um conjunto de telas e classes de negcio e auxiliares que
implementam os novos requisitos e esto prontos para serem incorporados ao restante do
sistema.
Palavras-chave
Engenharia de Software, UML, World Wide Web, Orientao a Objetos, Aplicao Web

ndice
1Introduo............................................................................................................................... 1
2CAPTULO II - Conceitos bsicos........................................................................................ 3
2.1Sistema Web bsico..........................................................................................................3
2.1.1Aplicao Web x Site Web.........................................................................................4
2.1.2HTTP (HyperText Transfer Protocol).........................................................................4
2.1.3HTML (HyperText Markup Language)......................................................................4
2.1.4Formulrios................................................................................................................. 5
2.1.5Aplicaes Web.......................................................................................................... 6
2.2Gerenciamento do estado do cliente...............................................................................6
2.2.1Cookies........................................................................................................................7
2.2.2Sesso..........................................................................................................................7
2.2.3Tecnologias de Ativao.............................................................................................8
2.3Clientes Dinmicos.........................................................................................................11
2.3.1Document Object Model (DOM)..............................................................................13
2.3.2Script......................................................................................................................... 15
2.3.3Objetos JavaScript.....................................................................................................15
2.3.4Eventos......................................................................................................................16
2.3.5Alternativas: Applets Java e ActiveX/COM.............................................................18
3CAPTULO III - O processo de desenvolvimento de uma aplicao Web......................20
3.1Representao do processo de desenvolvimento de software.................................... 23
3.1.1Atividades do Caso de Uso Desenvolvimento de Software..................................24
3.1.2Atividades do Caso de Uso Iterao de Software..................................................25
3.2Artefatos Gerados.......................................................................................................... 27
3.2.1Modelos.....................................................................................................................27
3.2.2Conjunto de gerenciamento de projeto..................................................................... 28
3.2.3Conjunto de domnio.................................................................................................29
3.2.4Conjunto de requisitos.............................................................................................. 30
3.2.5Conjunto de anlise...................................................................................................31
3.2.6Conjunto de projeto...................................................................................................33
3.2.7Conjunto de implementao......................................................................................34
3.2.8Conjunto de teste.......................................................................................................34
3.2.9Conjunto de implantao.......................................................................................... 37
4CAPTULO IV Principais Documentos Gerados........................................................... 38
4.1Documento de Viso...................................................................................................... 38
4.1.1Descrio do problema..............................................................................................38
4.1.2Lista das partes interessadas envolvidas no projeto e suas vises do sistema..........38
4.1.3Esboo do escopo do projeto.................................................................................... 38
4.1.4Esboo da soluo de software................................................................................. 39
4.1.5Segurana..................................................................................................................39
4.1.6Ambientes de cliente suportados...............................................................................39
4.2Documento de Requisitos.............................................................................................. 40
4.2.1Coletando requisitos..................................................................................................42
4.2.2Priorizando requisitos............................................................................................... 42
4.3Documento de Caso de Uso........................................................................................... 44
4.4Documento de Anlise................................................................................................... 47
4.4.1Estrutura....................................................................................................................47
4.4.2Elementos estruturais................................................................................................ 48
I

4.5Experincia do Usurio UX........................................................................................49

4.5.1Artefatos do modelo UX...........................................................................................50
4.5.2Entrada de dados do usurio..................................................................................... 51
4.6Documento de Arquitetura........................................................................................... 52
4.6.1Atividades da Arquitetura......................................................................................... 53
4.6.2Padres arquitetnicos de alto nvel..........................................................................53
4.7Projeto.............................................................................................................................55
4.7.1WAE Web Application Extension.........................................................................57
4.7.1.1Viso Lgica...................................................................................................... 57
4.7.1.2Viso de Componente........................................................................................ 59
4.7.2Mapeando o projeto para o modelo UX....................................................................60
5CAPTULO V Caso - Sistema Livraria - Artefatos Gerados........................................ 63
5.1Documento de Viso - Sistema Livraria -....................................................................63
5.1.1Descrio do problema..............................................................................................63
5.1.2Partes interessadas envolvidas:.................................................................................63
5.1.3Esboo da soluo de software:................................................................................ 63
5.1.4Esboo do escopo do projeto:................................................................................... 64
5.2Glossrio - Sistema Livraria ...................................................................................... 66
5.3Documento de Requisitos - Sistema Livraria -............................................................67
5.3.1Requisitos Funcionais............................................................................................... 67
5.3.1.1Gerncia de Preo Promocional.........................................................................67
5.3.1.1.1Requisito..................................................................................................... 68
O sistema dever permitir que o usurio visualize, dentre uma lista de artigos,
aquele que deseja programar um preo promocional................................................68
5.3.1.1.2Requisito..................................................................................................... 68
5.3.1.1.3Requisito..................................................................................................... 68
5.3.1.1.4Requisito..................................................................................................... 68
5.3.1.1.5Requisito..................................................................................................... 69
5.3.1.1.6Requisito..................................................................................................... 69
5.3.1.1.7Requisito..................................................................................................... 69
5.3.1.2Gerncia de Emprstimo ...................................................................................69
5.3.1.2.1Requisito..................................................................................................... 70
5.3.1.2.2Requisito..................................................................................................... 70
5.3.1.2.3Requisito..................................................................................................... 70
5.3.1.2.4Requisito..................................................................................................... 71
5.3.1.2.5Requisito..................................................................................................... 71
5.3.1.3Gerncia de Usurio...........................................................................................71
5.3.1.3.1Requisito..................................................................................................... 72
5.3.1.3.2Requisito..................................................................................................... 72
5.3.1.3.3Requisito..................................................................................................... 72
5.3.2Requisitos No Funcionais........................................................................................73
5.3.2.1Usabilidade ........................................................................................................73
5.3.2.2Desempenho ......................................................................................................73
5.3.2.3Rotina ................................................................................................................73
5.3.2.4Segurana ..........................................................................................................74
5.3.2.5Hardware ...........................................................................................................74
5.3.2.6Implantao .......................................................................................................74
5.4Documento de casos de uso Sistema Livraria -........................................................ 75
5.4.1Gerncia de preo promocional................................................................................ 75
5.4.1.1Casos de Uso......................................................................................................75
II

5.4.1.1.1Listar Preo Promocional............................................................................75

5.4.1.1.2Alterar Preo Promocional..........................................................................77
5.4.1.1.3Cancelar Preo Promocional.......................................................................78
5.4.1.1.4Cadastrar Preo Promocional......................................................................79
5.4.2Gerncia de emprstimo............................................................................................80
5.4.2.1Casos de Uso......................................................................................................80
5.4.2.1.1Listar Emprstimos..................................................................................... 80
5.4.2.1.2Inserir Emprstimos.................................................................................... 83
5.4.2.1.3Inserir Devoluo........................................................................................84
5.4.3Gerncia de Usurios................................................................................................ 85
5.4.3.1Casos de Uso......................................................................................................85
5.4.3.1.1Listar Usurios............................................................................................ 85
5.4.3.1.2Cadastrar Usurios...................................................................................... 87
5.4.3.1.3Alterar Usurio............................................................................................88
5.5Documento de Anlise................................................................................................... 89
5.5.1Diagrama de classes..................................................................................................89
5.5.2Caminhos de navegao............................................................................................90
5.5.3Diagramas de Seqncia...........................................................................................91
5.5.3.1Cadastrar Preo Promocional.............................................................................91
5.5.3.2Cancelar Preo Promocional..............................................................................92
5.5.3.3Alterar Preo Promocional.................................................................................93
5.5.3.4Listar Preos Promocionais................................................................................95
5.5.3.5Listar Usurios................................................................................................... 96
5.5.3.6Atualizar Usurio............................................................................................... 97
5.5.3.7Inserir Usurio....................................................................................................98
5.5.3.8Listar Emprstimos............................................................................................ 99
5.5.3.9Listar Movimentos........................................................................................... 100
5.5.3.10Inserir Emprstimo.........................................................................................101
5.5.3.11Inserir Devoluo...........................................................................................102
5.6Documento de arquitetura.......................................................................................... 103
5.6.1Estratgia de reutilizao........................................................................................ 105
5.6.2Consideraes Finais...............................................................................................107
6Captulo VI - Etapa Projeto...............................................................................................109
6.1Diagramas de Classes - Aperfeioado........................................................................ 109
6.2Caminhos de navegao.............................................................................................. 113
6.3Pacote Login................................................................................................................. 114
6.3.1Relacionamentos - Tela de Login........................................................................... 114
6.3.2Diagramas de Seqncia.........................................................................................115
6.4Pacote Usurio..............................................................................................................118
6.4.1Relacionamentos Tela de Gerncia de Usurios..................................................118
6.4.1.1Diagrama de Seqncia....................................................................................118
6.4.2Relacionamentos Tela de Cadastro de Usurio....................................................119
6.4.2.1Diagramas de Seqncia..................................................................................123
6.5Pacote Promoo..........................................................................................................125
6.5.1Relacionamentos Tela de Promoes.................................................................. 125
6.5.2Diagramas de Seqncia.........................................................................................128
6.6Pacote Emprstimo...................................................................................................... 130
6.6.1Relacionamentos Tela de Gerncia de Emprstimos...........................................130
6.6.1.1Diagramas de Seqncia..................................................................................132
6.6.2Relacionamentos Tela de Cadastro de Emprstimo.............................................133
III

6.6.2.1Diagramas de Seqncia..................................................................................137
6.7Classes Auxiliares.........................................................................................................139
6.8Diagrama de Desdobramento..................................................................................... 143
7Resultados............................................................................................................................145
8Concluso.............................................................................................................................146
9Bibliografia.......................................................................................................................... 149

IV

Introduo

O trabalho desenvolvido a seguir tem como objetivo discorrer a respeito de como aplicar os
preceitos da Engenharia de Software com o paradigma orientado a objetos no
desenvolvimento de aplicaes Web.
Atualmente existe uma grande corrente que conduz a indstria de software para repensar a
maneira como os programas so feitos e distribudos aos seus clientes. Cada vez mais se
escuta falar sobre software como um servio, hospedagem de aplicaes, etc. Por mais
que estas definies sirvam para denominar diferentes abordagens de utilizao do software,
todas elas possuem em comum o fato de utilizarem a Web como canal de comunicao entre
um sistema e seus usurios.
Esta maior demanda por sistemas na Web implica em softwares que atendam requisitos cada
vez mais complexos e que se comuniquem com uma srie de outros sistemas externos,
dependendo do contexto da aplicao.
Percebendo toda esta movimentao, a pergunta que surge : como desenvolver e gerenciar o
desenvolvimento de aplicaes Web utilizando as ferramentas de que dispe-se hoje? A UML
permite a modelagem de software em nveis de abstrao condizentes com cada fase do
projeto. Porm, como a UML trataria as especificidades que uma aplicao Web possui? Cada
tela da aplicao representaria um subsistema prprio? E caso esta mesma tela abra uma outra
cujo estado depende da primeira? Como realizar a interao entre o usurio que utiliza o
navegador e o servidor que executa a aplicao? E as interaes do usurio com o sistema que
no passam pelo servidor?
Por conta destas questes, foi utilizada uma extenso da UML chamada WAE (Web
Application Extension) para conseguir modelar de forma adequada uma aplicao Web com
todas as suas caractersticas prprias. A WAE representa um conjunto de prottipos de
classes e relacionamentos UML especficos do ambiente Web, tais como a pgina do servidor
e scripts do cliente.

Como exemplo de sua utilizao, foi realizada uma iterao sobre um projeto baseado em
uma Intranet com o objetivo de inserir o paradigma orientado a objetos em alguns requisitos
de uma aplicao Web existente e sua eficcia ser discutida.
Alm desta introduo, o projeto pode ser dividido em quatro partes principais:
-

Captulo II, onde so apresentados os conceitos bsicos que cercam uma aplicao
Web;

Captulos III e IV, que explica o processo de desenvolvimento de uma aplicao Web,
seus fluxos de trabalho e principais artefatos gerados;

Captulos V e VI, que exemplifica o processo descrito anteriormente durante uma

iterao de desenvolvimento sobre um sistema de exemplo;

Captulos VII e VIII, que resumem as principais concluses extradas ao longo de todo
o projeto

Neste captulo ser apresentada uma srie de conceitos e definies sobre o ambiente Web e
suas especificidades. De carter introdutrio, o seu contedo serve para melhor compreenso
dos captulos subseqentes.
2
2.1

CAPTULO II - Conceitos bsicos

Sistema Web bsico

Os documentos so acessados e visualizados por um software navegador (browser), que

uma aplicao executada pelo computador cliente. O cliente pode atravs do navegador
solicitar documentos de outros computadores da rede e apresent-los na tela.
O navegador envia uma solicitao do documento para o computador host. Esta solicitao
tratada por um software de aplicao denominado servidor Web, que uma aplicao que
normalmente executada como um servio, geralmente utilizando a porta 80.
Ao receber a solicitao, o servidor Web localiza o documento no seu sistema de arquivos
locais e o envia para o navegador:

2.1.1

Aplicao Web x Site Web

Existe uma sutil diferena entre Aplicao Web e site Web. Uma Aplicao Web um
sistema que permite que seus usurios executem as regras de negcio atravs de um
navegador Web, com uma interface de um site Web. Desta forma, os usurios da aplicao
podem afetar, via entrada de dados, o estado do negcio. E justamente isto alterar o estado
do negcio que um site Web no realiza.

2.1.2

HTTP (HyperText Transfer Protocol)

o protocolo principal de comunicao utilizado entre os navegadores e os servidores Web.

Ele especifica como um navegador deve formatar e enviar uma solicitao para o servidor
Web.
O HTTP executado sobre o TCP (Transmission Control Protocol), mas poder ser executado
sobre qualquer servio orientado para conexo.
O HTTP um protocolo sem conexo, ou seja, cada vez que o cliente solicita um documento
a um servidor Web uma nova conexo deve ser estabelecida com o servidor.
A Internet tambm possui outros protocolos comumente utilizados, tais como FTP, news, file
e Gopher.
2.1.3

HTML (HyperText Markup Language)

Alm de estabelecer conexes com a rede e protocolos para intercmbio de documentos, os

navegadores necessitam apresentar o documento em uma tela. A apresentao do contedo
gerenciada pelo navegador.
Para isso existe a HTML, que uma linguagem baseada em tags para apresentao de
documentos de texto. Ela define a formatao do texto, atravs de fonte, cor, tamanho, etc.
Ela tambm utiliza tags para apontar para imagens a serem includas na tela, bem como para
definir links para outras pginas Web.

2.1.4

Formulrios

Os elementos de formulrio da HTML distinguem um site Web de uma aplicao Web. Ser
atravs dos campos do formulrio que o usurio poder digitar e/ou alterar valores.
O formulrio e seu contedo so submetidos ao servidor Web como parte de outra solicitao
de pgina Web. O servidor Web recebe a solicitao para uma pgina Web especial ou um
mdulo executvel, que capaz de ler os valores dos campos do formulrio e process-los no
servidor. O resultado final a gerao de uma nova pgina HTML enviada de volta para o
navegador.

Geralmente, este processamento dos dados dos campos do formulrio envolve comunicao
com objetos no servidor ou com bancos de dados.
Os dados do formulrio podem ser enviados ao servidor por dois mtodos: GET e POST.
Quando GET usado, os valores de todos os campos so anexados ao URL como parmetros.
Quando o mtodo POST utilizado, o navegador ir empacotar os valores de cada campo em
uma seo especial da solicitao chamada corpo de dados (data body).
O parmetro mais comum o <input>, que possui como tipos mais comuns os seguintes
elementos:

Checkbox, Hidden, Password, Radio, Submit, Text

2.1.5

Aplicaes Web

As Aplicaes Web usam as chamadas tecnologias de ativao (sero discutidas

posteriormente) para tornar o contedo dinmico e para permitir que os usurios alterem a
regra de negcio no servidor.
Se no houver nenhuma regra de negcio em um servidor, o sistema no deve ser considerado
uma aplicao Web.
Normalmente, os usurios de uma aplicao Web inserem diversos tipos de dados, desde
textos simples at opes de uma caixa de seleo ou arquivos.
Para distingir melhor uma aplicao Web de um site Web, observemos as ferramentas de
busca na Internet. Elas simplesmente aceitam os critrios de pesquisa passados pelo usurio e
retornam os resultados, sem alterao perceptvel no estado da ferramenta de pesquisa.
2.2

Gerenciamento do estado do cliente

O fato das comunicaes entre cliente e servidor serem sem conexo no torna fcil o controle
do servidor das solicitaes dos clientes e associ-las entre si, uma vez que toda solicitao
estabelece e logo em seguida interrompe um conjunto novo de conexes.
Imagine um cenrio de utilizao do sistema. de se esperar que o usurio navegue por
algumas pginas Web. Se no existir um mecanismo de gerenciamento de estado do cliente,
todas as informaes inseridas anteriormente devero ser fornecidas para cada nova pgina,
tornando o processo cansativo e custoso. Um exemplo deste provvel transtorno seria a
obrigao de se inserir seu login e senha para cada pgina do seu servio de WebMail.
O W3C props um mecanismo de gerenciamento de estado http, conhecido como cookie

2.2.1

Cookies

Um cookie um fragmento de dado que um servidor Web pode pedir a um navegador para
manter e retornar cada vez que ele fizer uma solicitao subseqente de um recurso http para
esse servidor. O tamanho do dado pode alcanar at 4K.
Inicialmente, o cookie enviado de um servidor para o browser adicionando uma linha ao
cabealho HTTP. Se o browser estiver configurado para aceitar cookies, a linha ser aceita e
armazenada em algum lugar na mquina do cliente (isto varia de navegador para navegador).
Quando um cookie enviado ao cliente, ele pode ter at 6 parmetros preenchidos, que so:
Parmetro
Name

Obrigatrio?
Sim

Restries
No deve conter

Definio
Nome do cookie

Value

Sim

blank, , e ;
No deve conter

Valor do cookie

Expiration

No

blank, , e ;
-

Informa ao browser por quanto tempo ele manter a

date
Path

No

informao
Utilizado para organizar os cookies dentro do

Domain

No

domnio
Utilizado para indicar para quais servidores ou

Require a

No

domnios os cookies sero enviados de volta

Indica se os dados sero enviados via conexo

secure

segura

connection

Alm do servidor , o JavaScript tambm pode configurar o valor de um cookie.

2.2.2

Sesso
7

Uma sesso representa um uso coesivo e nico do sistema. Normalmente, uma sesso envolve
muitas pginas Web executveis e bastante interao com a regra de negcio no servidor de
aplicao.
O estado da sesso em uma aplicao Web pode ser mantido de quatro maneiras comuns:
1. Colocar todos os valores do estado em cookies;
2. Colocar uma chave nica no cookie e usar um dicionrio ou mapa gerenciado pelo
servidor;
3. Incluir todos os valores de estado como parmetros em cada URL do sistema;
4. Incluir chave nica como um parmetro em cada URL do sistema e usar um dicionrio ou
mapa gerenciado pelo servidor.
Os dois primeiros mtodos sugeridos, baseados em cookies, tm o inconveniente da
dependncia do cliente estar com o browser aceitando cookies.
Os dois ltimos mtodos sugeridos se baseiam na idia que todos os URLs do sistema sero
dinamicamente contrudos para incluir parmetros que contenham todo o estado da sesso ou
apenas uma chave para um dicionrio no servidor.
Porm, esta soluo poder se tornar cara se a manuteno do dicionrio na memria nunca
expirar. Para contornar este problema, a maioria dos dicionrios de sesso so removidos
quando o usurio da aplicao Web termina o processo ou pra de utilizar o sistema por um
determinado perodo de tempo.
Um valor de timeout da sesso geralmente utilizado o de 15 minutos.

2.2.3

Tecnologias de Ativao
8

As tecnologias de ativao so, em parte, o mecanismo pelo qual as pginas Web se tornam
dinmicas e respondem entrada do usurio.
A mais antiga tecnologia de ativao envolve a execuo de um mdulo separado por um
servidor Web. Em vez de solicitar uma pgina HTML formatada do sistema de arquivos, os
navegadores deviam solicitar o mdulo, que o servidor Web interpreta como uma solicitao
para carregar e executar o mdulo. A sada do mdulo normalmente uma pgina HTML
formatada adequadamente, mas poderia ser qualquer outro dado.
O mecanismo original para processar a entrada do usurio em um sistema Web o Common
Gateway Interface (CGI). Os mdulos CGI podem ser escritos em qualquer linguagem,
podendo ser ainda em forma de script.
Os dois grandes problemas ao utilizar CGI so que ele no proporciona automaticamente
servios de gerenciamento de sesso e que cada execuo do mdulo CGI requer um processo
novo e separado.
Hoje j existem solues que resolvem o problema do multiprocesso do CGI. Ao adicionar
plug-ins ao servidor Web, permite-se que o servidor web se preocupe apenas com o servio de
solicitaes HTTP padro e transfira as pginas executveis para outro, j executando o
processo.
Os dois principais enfoques para as tecnologias que ativam a aplicao Web so: mdulos
compilados e scripts interpretados.
Os mdulos compilados so uma soluo eficiente e adequada para aplicaes de alto volume.
As desvantagens recaem sobre o desenvolvimento e manuteno, uma vez que geralmente
estes mdulos combinam regra de negcio com a construo de pgina HTML, tornando a
leitura difcil para o programador. Alm disso, a cada nova atualizao a aplicao Web tem
de ser fechada e o mdulo descarregado.

Enquanto o mdulo compilado parece um programa de lgica do negcio que ocorre para
emitir HTML, as pginas baseadas em script parecem uma pgina HTML que ocorre para
processar uma lgica do negcio.
Estas pginas possuem scripts que sero interpretados e iro interagir com objetos no
servidor. Feito isto, finalmente iro produzir uma sada HTML.
Normalmente, a extenso do arquivo determina ao servidor Web qual servidor de aplicao
dever ser usado para pr-processar a pgina. Exemplos: JavaServerPages, Microsofts Active
Server Pages e o PHP.

A figura acima demonstra o relacionamento entre os componentes das tecnologias de ativao

e o servidor Web.
A soluo de mdulo compilado quase intercepta as solicitaes de pgina Web do servidor.
A soluo de pginas baseadas em script chamada pelo servidor Web apenas aps ele ter
determinado que a pgina realmente tem scripts para interpretar. Quando ele recebe uma
solicitao para essa pgina, ele localiza a pgina no diretrio especificado e a entrega para o
servidor de aplicao. O servidor de aplicao pr-processa a pgina, interpretando todos os
10

scripts de servidor existentes e interagindo com os recursos de servidor, se necessrio. O

resultado uma pgina HTML formatada adequadamente que enviada para o navegador do
cliente.
O sucesso desta ltima soluo se deve ao fato de facilitar o desenvolvimento e a distribuio,
funcionando como uma cola que liga os aspectos da interface de usurio HTML do sistema
com os componentes da regra de negcio.
2.3

Clientes Dinmicos

At o momento discutimos as aplicaes Web e suas tecnologias de ativao imaginando que

toda a execuo da lgica do negcio estando centrada no servidor. Sob este ponto de vista, o
browser se torna apenas um dispositivo de interface generalizado e simples.

Porm, os desenvolvedores de sistema passaram a imaginar que uma partilha de

responsabilidades entre cliente e servidor poderia ser bastante proveitosa para ambos. A idia
era simples, mas alguns problemas como a distribuio e independncia de plataforma
deveriam ser solucionados.
A lgica do negcio composta de regras e processos que formam o estado do negcio do
sistema. Ela composta de validaes e sistemas de dados.
J a lgica de apresentao se concentra em tornar a interface com o usurio mais fcil. Ela
pode aceitar qualquer dado que contribua para o estado do negcio do sistema, mas no
responsvel por ele.
Por exemplo, imaginemos uma tela com um controle de seleo de data de nascimento de um
usurio do sistema, que se exibe como um minicalendrio no navegador. Este artefato captura
a entrada do usurio (data de nascimento), no constituindo, assim, uma lgica do negcio. A
utilizao desta data para o clculo de um perodo de validade, por exemplo, entretanto, uma
lgica do negcio.

11

Os exemplos mais comuns da lgica do negcio no cliente so validaes de campo e

formulrio. Por exemplo, plausvel que o sistema no aceite que o usurio entre com a
data de 30 de Fevereiro. Ainda assim, ele pode digit-la e enviar este dado incorreto para o
servidor, que apenas aps o recebimento ir verificar o erro e reenviar o formulrio inteiro de
volta ao cliente. Esta soluo exige um tempo demasiado grande, uma vez que a durao entre
a submisso do formulrio ao servidor, o recebimento do mesmo e o seu reenvio pode levar
segundos.
Imaginando uma soluo com um cliente dinmico, o valor da data preenchido seria
verificado pela mquina do cliente, possivelmente com o usurio, j que a ao no requer
recursos do servidor.
Vrios mecanismos e tecnologias trazem a lgica do negcio para o cliente. Todas elas
podem ser utilizadas para melhorar a interface com o usurio, e podem ser divididas em duas
categorias:
-

baseadas em script

compiladas

Entretanto, todas compartilham alguns pontos em comum, que so:

-

Esto associadas uma pgina Web e podem acessar e modificar seu contedo;

So automaticamente distribudas, ou descarregadas no computador cliente conforme

necessrio;
-

Tratam de questes especficas de segurana.

A escolha de qual soluo usar na mquina do cliente se baseada em script ou compilada

ir depender do grau de complexidade da lgica de negcio a ser executada. Quando ela
mnima, o script o meio mais simples. Quando se deseja executar uma lgica mais
sofisticada, geralmente so construdos applets Java, controles JavaBeans ou ActiveX.
Haver uma discusso posterior sobre estas tecnologias.
12

Vale ressaltar que a utilizao da lgica de negcio por parte do cliente deve ser incentivada
sempre que ela acesse apenas recursos no cliente. Uma lgica de negcio que requer recursos
no servidor no uma candidata a migrar para o cliente.
A lgica de negcio que implementada no cliente precisa se concentrar no tratamento de
dados na pgina Web propriamente dita.
2.3.1

Document Object Model (DOM)

O DOM representa uma plataforma neutra para o navegador e o documento HTML

desenvolvida pelo W3C e est implementada na grande maioria dos navegadores atualmente.
A idia bsica possuir uma API comum com a qual os desenvolvedores Web possam tratar
o contedo do documento HTML e XML, assim como os recursos do prprio navegador.
A figura abaixo exibe os relacionamentos entre o navegador, o documento HTML, os scripts,
os mdulos compilados e o DOM.

O documento contm os scripts que utilizam a interface DOM. Ele tambm possui
referncias aos mdulos compilados, que tambm utilizam interface DOM.
J o navegador responsvel pela apresentao do documento HTML dinmico e pela
implementao da interface DOM dos scripts e programas para modificar o documento
HTML.

13

Como a sigla DOM demonstra, os documentos so tratados como objetos possuindo dados e
comportamento. A colaborao entre esses objetos constitui a estrutura do documento. Como
um documento uma coleo de objetos, ele pode ser representado por um modelo de
objetos:

Body

Paragraph

UnOrderedList

List item

14

Os trs principais objetivos do DOM so especificar:

-

As interfaces e objetos usados para representar e tratar um documento;

As semnticas destas interfaces e objetos;

Os relacionamentos e colaboraes entre estas interfaces e objetos

2.3.2

Script

Dentre as tecnologias de script mais comuns destaca-se o JavaScript. O JavaScript uma

linguagem baseada em objeto, e no orientada a objeto. Isto significa que ele utiliza objetos
extensveis internos, mas no suporta classes definidas pelo usurio ou herdadas.
O JavaScript no compilado. Ele utiliza binding dinmico e todas as referncias a objeto
so verificadas em tempo de execuo. O seu cdigo vem incorparado ao HTML e
delimitado pela tag <script>:
<script language = javascript>
alert(Hello World);
</script>
2.3.3

Objetos JavaScript

O DOM, que a fonte principal de objetos para JavaScript, coloca uma interface de objeto
tanto no documento HTML quanto no browser. O JavaScript pode interagir com o browser e dele extrair informaes como o seu histrico ou com outras pginas de um frameset.
O objeto principal utilizado no trabalho sobre o contedo de um documento o objeto
document, cuja referncia pode ser alcanada pela propriedade document do objeto window,
existente em qualquer funo JavaScript.

15

A figura abaixo mostra a hierarquia DOM disponvel para scripts em uma pgina:

2.3.4

Eventos

O JavaScript incorporado ao HTML tambm lido e interpretado para que aparea no

documento. Por isso, alguns problemas podem ocorrer. Imagine o caso em que um trecho em
JavaScript faa chamada a duas funes, uma seguida da outra, e que a segunda dependa do
resultado da primeira para funcionar corretamente. O navegador, to logo seja chamada a
primeira funo, ir para a prxima linha sem aguardar o encerramento da primeira.
Para contornar este tipo de problema e organizar o documento se criam funes que
encapsulem os comportamentos desejados para que sejam executadas conforme necessrio.
Desse modo, uma funo ir responder a um evento. Como por exemplo, uma funo ir
responder ao evento onLoad do elemento <body> da pgina HTML quando o documento for
carregado pela primeira vez.
16

A tabela a seguir mostra um resumo dos eventos a que um documento HTML pode
responder, valendo ressaltar que nem todos os elementos do documento HTML podem
responder a todos os eventos:
Evento

Aplica-se a

Ocorre quando

Manipulador

Abort

Imagens

O usurio aborta a

de evento
OnAbort

carga de uma imagem,

clicando, por exemplo,
em um link ou no
Blur

Janelas, quadros e todos os

boto Stop.
O usurio remove o

elementos de formulrio

foco de entrada da

OnBlur

janela, quadro ou
elemento do
Botes, botes de opo, caixas de

formulrio
O usurio clica no

seleo, botes Submit, botes

elemento do

Change

Reset, links
Campos de texto, reas de texto,

formulrio ou link
O usurio altera o

OnChange

Error

listas de seleo
Imagens, janelas

valor do elemento
A caraga de um

OnError

Click

OnClick

documento ou imagem
Focus

Janelas, quadros e todos os

causa um erro
O usurio d o foco

elementos de formulrio

para a janela, quadro

OnFocus

ou elemento de
Load

Corpo do documento

formulrio
O usurio carrega a

OnLoad

Mouse

reas, links

pgina no navegador
O usurio move o

OnMouseOut

Out

ponteiro do mouse
para fora de uma rea
mapa de imagem do

Mouse

Links

Over

cliente ou link
O usurio move o

OnMouseOver

ponteiro do mouse
sobre um link

Reset

Formulrios

O usurio redefine um

OnReset

formulrio: clica em
Select

Campos de texto, reas de texto

um boto Reset
O usurio seleciona

OnSelect

17

um campo de entrada
do elemento do
Submit

Boto Submit

formulrio
O usurio submete um

OnSubmit

UnLoad

Corpo do documento

formulrio
O usurio sai da

OnUnLoad

pgina

Desta forma, a programao no cliente voltada para o evento. Quando esta programao em
JavaScript usada para executar a lgica de negcio ela deve ser idealizada durante a fase
de design, e possivelmente, nos modelos de anlise. Quando ela visa apenas melhorar a
apresentao ela deve ser pensada durante a modelagem dos modelos de interface e na
criao dos prottipos. Estes tpicos sero melhor abordados e esclarecidos no decorrer do
trabalho.
2.3.5

Alternativas: Applets Java e ActiveX/COM

As tecnologias de cliente dinmico no se restrigem apenas ao JavaScript. Os applets

JavaScript ou Java tambm conferem pgina um maior dinamismo por parte do cliente.
O applet uma espcie de controle de interface com o usurio que colocado em uma pgina
Web, e referenciado por uma tag <object>. Dentro desta tag so preenchidos parmetros
que identificam o applet e indicam onde ele pode ser obtido.
Alm desses parmetros, a tag <param> no interior da tag <object> permite que o applet
acesse parmetros definidos pelo programador. Um exemplo de utilizao de um applet pode
ser visto abaixo:

<OBJECT codetype = application/java

classid = java:DatePicker.class
codebase = http://www.meusite.org/javaclasses/>
<PARAM name = format value = mm-dd-yyyy type = data>
<PARAM name = style value = DropDown type = data>
18

</OBJECT>

Um ponto positivo o fato de os applets Java, aps terem sido descarregados para o cliente,
no sero carregados novamente quando forem chamados posteriormente. Cada vez que a
pgina Web que contm o applets revisitada, o browser verifica se o applet j foi
descarregado e se certifica que possui a verso correta. Se houve alterao de verso ou se
no existir mais no cliente o applet em cache, o applet descarregado novamente.
J os controles ActiveX, ou objetos COM, so a soluo da Microsoft para dar dinamismo ao
cliente, da mesma maneira que os applets Java. Trata-se de um mdulo executvel completo
que acionado pelo navegador.

19

Neste captulo ser sugerido um processo de desenvolvimento de uma aplicao

Web, que ser dividido em diversas etapas e iro gerar uma srie de artefatos que
iro organizar e facilitar o gerenciamento do trabalho da equipe ao longo do
tempo.
3

CAPTULO III - O processo de desenvolvimento de uma aplicao Web

Neste momento ser enfatizada a importncia em se construir um processo para desenvolver

uma aplicao Web.
Uma equipe de desenvolvimento de software pode atravs de muito esforo e dedicao
concluir um projeto em sua forma completa. Porm, esta mesma equipe, atravs de muito
esforo e dedicao, pode, auxiliada por um processo robusto fazer do desenvolvimento de
uma aplicao Web uma tarefa repetitiva e confivel.
Ser apresentado a seguir um processo de desenvolvimento de software, com seus termos e
conceitos que sero largamente utilizados no decorrer do texto.
Independente do processo utilizado, qualquer processo de desenvolvimento de software
possui quatro finalidades bsicas:
1. Fornecer uma ordenao sobre a seqncia de atividades de uma equipe de
desenvolvimento. Desta forma a equipe possui em mos um roteiro de atividades a serem
executadas em uma determinada ordem pr-estabelecida;
2. Especificar os artefatos que sero desenvolvidos
3. Delegar tarefas para cada desenvolvedor individualmente e tambm para a equipe como
um todo
4. Criar critrios para monitorar e comparar produtos e atividades do projeto

21

O processo de desenvolvimento de software geralmente fica disposto sob a forma de um

conjunto de documentos ou um sistema de hipertexto on-line. A figura abaixo demonstra
como o processo de desenvolvimento de software implica na criao de fluxos de trabalho
que envolvem a definio de atividades executadas por operadores para gerar artefatos prdeterminados.

Vale ressaltar que ser utilizada a notao dos diagramas UML para sintetizar graficamente
alguns dos fluxos de trabalho, como generalizado acima. No haver, neste momento,
nenhum compromisso em se manter fiel s determinaes que a linguagem UML impe.
Fluxo de trabalho o conjunto de atividades levantamento de requisitos, anlise,
projeto, codificao, teste e manuteno que ao final produz um resultado tangvel e
observvel.
Atividade o conjunto de procedimentos que os operadores executam para gerar os
artefatos de sada do fluxo de trabalho.
Artefato qualquer parte de informao persistente ao projeto produzida pelos operadores
durante suas atividades. Podem envolver modelos, elementos de modelo, documentos e
cdigo-fonte.
Operador um papel executado por uma pessoa durante o processo de desenvolvimento
de software

22

As principais caractersticas do processo descrito a seguir so sua orientao a caso de uso,

sua centralizao na arquitetura e sua natureza iterativa e incremental.
Por se tratar de um processo iterativo, cada fluxo de trabalho (que envolve as diversas
atividades que geram artefatos na sada) repetido e redefinido at que se atenda a todos os
requisitos do sistema e seja implantado.
Geralmente, cada atividade do desenvolvimento de software descobre problemas e
circunstncias que pem em cheque ou podem at alterar decises tomadas anteriormente. A
figura abaixo esquematiza a idia de processo iterativo que se deseja alcanar:

3.1

Representao do processo de desenvolvimento de software

Como usarei bastante os recursos da UML durante todas as etapas do desenvolvimento de

software voltado para a Web, tambm irei representar o processo de desenvolvimento de
software atravs de elementos UML.
No caso do processo em si, temos um caso de uso superior que chamarei de
Desenvolvimento de Software, que ir interagir com as partes interessadas neste processo:
clientes, usurios, donos de empresa, etc. Este caso de uso se utiliza de um outro caso de uso
crtico para este processo, que darei o nome de Iterao de Software.

23

<<include>>

Parte interessada

Desenvolvimento de Software

Iterao de software

(f rom Actors)

3.1.1

Atividades do Caso de Uso Desenvolvimento de Software

As atividades de Desenvolvimento de Software podem ser expressas atravs de um

diagrama de atividades. Inicialmente ocorre uma anlise do negcio e a identificao de seus
problemas mais evidentes ( bastante comum que outros problemas surjam durante todo o
processo, da minha defesa sobre o ciclo iterativo). Ser representada, de maneira ilustrativa,
a seqncia de atividades de uma iterao apenas:

Desenvolver modelo
de domnio

Analisar negcio e
problemas percebidos

Analisar o
problem a

Gerenciar verses
de artefatos

Desenvolver
documento de viso

desenvolver plano
de projeto
Diagrama de
atividades
para Caso de
Uso Iterao
de software

Reiterar

Critrios de aceitao
Implantar
sistema
Atualizar
sistema

24

Simultaneamente, ocorre a atividade de desenvolvimento de um modelo de domnio que ir

expressar as entidades e os processos principais do negcio. O documento mais importante a
ser gerado nesta atividade ser o glossrio, que ir definir os termos e conceitos principais do
contexto em que o sistema est inserido.
Concludas as duas primeiras atividades, a equipe pode se dedicar anlise do problema em
si e desenvolver o documento de viso, que ir expressar o escopo e a finalidade de todo o
projeto de software. Geralmente este documento de viso tem como principal objetivo
fornecer os recursos principais e critrios de aceitao para o sistema em desenvolvimento.
Tendo o documento de viso em mos, a equipe est apta para desenvolver o plano de
projeto, que ir esboar as atividades de desenvolvimento do software como um todo,
determinando e dispondo eventos em ordem de prioridade e tambm gerando plano de
gerenciamento de alterao e de configurao.
importante que o plano de projeto contenha o primeiro esboo do plano de iterao, que a
razo do sucesso de todo o processo. Este plano dever conter as atividades que sero
executadas durante cada iterao, os artefatos que devero ser gerados e, o mais importante,
os critrios de avaliao para cada um.
de se esperar, tambm, que o plano de iterao sofra mudanas significativas at a
concluso do projeto de desenvolvimento. Porm, o ponto mais importante desta atividade
que as iteraes devem ser pensadas antecipadamente.
A atividade de reiterar nos leva ao caso de uso Iterao de Software, descrito a seguir.
3.1.2

Atividades do Caso de Uso Iterao de Software

O caso de uso Iterao de Software corresponde a todas as atividades do processo que

envolve a iterao de todos os artefatos que formam o ponto de partida do documento de
viso para a formao da coleo de artefatos que iro compor o produto final.

25

NewState

Rever e refinar
plano de iterao

Requisitos

Arquitetura

Anlise

Desenvolver
Ambiente

Projeto

Desenvolver
Projeto

Gerenciar
Alteraes

Implementao

Teste

Avaliar iterao / Ajustar

plano de iterao

Rever progresso com a

parte interessada

26

Como descrito na figura anterior, a caracterstica mais marcante deste caso de uso que
vrios os fluxos de trabalho ocorrem em paralelo. Alm disso, recomendvel que o gerente
da equipe consiga ditar um ritmo constante ao processo, seja atravs de reunies de status
semanais, relatrios de testes da manh ou qualquer outra. Isto ir manter a equipe
concentrada no desenvolvimento dos artefatos pretendidos e diminuir a sensao de pnico
quando algum problema ocorrer.
Ao longo da iterao sobre todos os artefatos, devem ocorrer as atividades de rever e refinar
o plano de iterao, rever o progresso com as partes interessadas (atividade importante para
manter investimentos e mostrar o progresso ou estagnao do status do projeto) e tambm
avaliar a iterao ao seu final e ajustar o prximo plano.
3.2

Artefatos Gerados

3.2.1

Modelos

Durante a confeco dos diferentes artefatos que iro compor o sistema, os modelos de
sistema se situam entre os principais, por serem um excelente canal de comunicao entre os
membros da equipe, e tambm por auxiliarem no gerenciamento da complexidade do sistema
em construo.
Os modelos recomendados para desenvolvimento so os seguintes:
-

Modelo de domnio

Modelo de caso de uso

Modelo de anlise/projeto

Modelo de implementao

Modelo de processo

Modelo de segurana

Modelo de experincia de usurio ou interface com o usurio

27

Cada um destes modelos, ainda que possuam um enfoque particular, devem ser consistentes
entre si. Ser esta consistncia que permitir que a equipe consiga visualizar a interao entre
os diversos componentes e tambm prever o impacto que uma alterao em algum deles teria
sobre todo o sistema ou parte dele.
Todos os artefatos principais podem ser agrupados em conjuntos que iro interagir uns com
os outros. Neste momento definem-se estes conjuntos, seus atores e fluxos de trabalho
necessrios para a construo de cada um dos artefatos pretendidos.
3.2.2

Conjunto de gerenciamento de projeto

Os principais artefatos deste conjunto so os planos de projeto, de iterao e de

gerenciamento de alterao (veja figura abaixo).

Plano de gerenciamento de alterao

Desenvolver plano de
gerenciamento de alterao

Plano de projeto

Gerente de projeto

Desenvolver plano de projeto

1..*

Plano de iterao

Equi pe de
arquitetura

Gerenciar iterao

Sero estes documentos que esboam o cronograma de desenvolvimento, procedimentos de

seleo de pessoal, reas de responsabilidade e eventos principais. Neste momento dever se
buscar metas realistas para cada iterao e tambm testar as reas de maior risco da aplicao
logo nas primeiras iteraes e no nas ltimas.

28

3.2.3

Conjunto de domnio

Os principais artefatos deste conjunto so o modelo de domnio e o glossrio. O modelo de

domnio corresponde a um modelo UML que captura a essncia do contexto do negcio e do
domnio no qual o sistema ir residir. Este modelo descrito atravs de objetos de domnio
possuidores de operadores e entidades.
J o glossrio ir capturar definies de conceitos e termos-chave para as discusses do
negcio, e dever estar facilmente acessvel a todas as partes interessadas no
desenvolvimento. Ser ele que ir evitar interpretaes dbias ou incompletas pelos membros
da equipe.

Glossrio

Equi pe de
requisitos

Desenvolver glossrio

Modelo de domnio

Desenvolver pl ano de domni o

Objeto de domnio

Operador

Entidade

29

3.2.4

Conjunto de requisitos

Os principais artefatos deste conjunto so as vises, o documento de diretrizes de experincia

do usurio, o modelo de casos de uso(e seus respectivos diagramas de atividade e seqncia),
e especificar os requisitos suplementares (de negcio e arquitetura).

Parte interessada
(f rom Ac tors)

Analista de
sistemas

Viso
Criar declarao de viso

Arquiteto de
informao

Desenvolver especificao de
experincia de usurio

Documento de diretrizes de experincia de usurio

Equipe de
arquitetura

Modelo de caso de uso

Priorizar modelo de caso de uso

Fluxo Principal
1

Gerente de projeto

Diagrama de seqncia

Elemento

0..*

Desenvolver modelo de caso de uso

1
1
Equipe de
requisitos

Diagrama de atividade

Especificao
Especifi car caso de uso

Especifi car requi si tos

suplementares

Negcio
Recurso

Poltica de segurana

Arquitetnico

Desempenho

Disponibilidade

Mecanismo de segurana

30

Um requisito uma declarao do que o sistema deve executar. Ele dever especificar uma
soluo de sistema independente da arquitetura do sistema, apenas do ponto de vista de como
gostaramos que o sistema se comportasse.
O documento mais importante deste conjunto o documento de viso. Ser ele que ir
determinar a meta global do sistema a ser desenvolvido e o contexto em que est definido.
Geralmente ele criado antes do projeto mas deve permanecer estvel ao longo de todo o
ciclo de vida do projeto.
J os casos de uso possuem um modelo UML, meramente simblico, e sua especificao com
termos do domnio para que possam ser bem compreendidos por todas as partes interessadas.
Sero eles os principais elos entre o domnio e o mundo tcnico do sistema.
No caso especfico de aplicaes Web, o documento de experincia do usurio ganhou
notvel importncia. Este documento ir definir a aparncia destinada para a aplicao. Ele
faz uma combinao entre o tcnico e o criativo, na medida em que descreve mecanismos de
navegao ao mesmo tempo que folhas de estilo e esquemas de cores. Maiores detalhes sero
apresentados na seo Experincia do Usurio UX.
3.2.5

Conjunto de anlise

O principal artefato deste conjunto o documento de arquitetura de software. Ser a partir

dele que a equipe poder ser dividido em subsistemas e respectivas reas de
responsabilidade, e assim permitir o seu desenvolvimento assncrono.
O documento de arquitetura ser melhor confeccionado a partir do desenvolvimento e anlise
de prottipos arquitetnicos, o que permite testar diversas tecnologias existentes e precaver a
equipe de riscos maiores no futuro.
A anlise dos casos de uso ir levar a um modelo conceitual do sistema o mais independente
possvel da arquitetura. Este modelo ir corresponder a criao de diversas classes de anlise,
que provavelmente iro possuir os mesmos nomes das classes de domnio.

31

Projeto de arquitetura de software

desenvolver documento de
arquitetura de software

Especificao de subsistema

Equipe de
arquitetura
Projeto de subsistema

Projeto de arquitetura de software

Desenvolver e analisar prottipos
arquitetnicos

Fluxo principal

Diagrama de seqncia

Realizao de caso de uso

Equi pe de anli se

Anl ise de caso de uso

Classe de anlise

Controle

Diagrama de estado
0..1

Limite

Entidade

Roteiro
1..*
Desenvolver roteiros e fluxos de
Equipe de UX
navegao

Tela

1..*
Diagrama de colaborao

1..*

32

3.2.6

Conjunto de projeto

Este fluxo de trabalho se encarrega de aplicar a arquitetura escolhida sobre os artefatos

gerados durante o fluxo de trabalho da anlise. O objetivo principal do projeto tornar o
modelo de anlise do sistema realizvel em software.

Viso do processo

Equi pe de
arquitetura

Desenvol ver vi so do processo

Encadeamento
Subsistema

Projetar subsistema

Equipe de projeto

Processo

Elemento do componente

Classe de projeto

Desenvol ver lgica da pgi na Web

Pgina Web

Equi pe de UX

Desenvolver estrutura e contedo

esttico da pgi na Web

Tambm sero gerados os modelos de processo, que iro definir em quais camadas da
aplicao Web, cliente, dados, etc os ciclos de vida do objeto iro residir.
Tambm h preocupao com a definio de classes ao nvel de projeto, as assinaturas de
seus mtodos e as associaes entre elas para satisfazer o comportamento do negcio
desejado.
Alm disso, ocorre a colaborao entre a equipe de experincia do usurio com a equipe de
projeto para se definir como estaro dispostas as pginas Web
33

3.2.7

Conjunto de implementao

Durante o fluxo de trabalho de implementao os artefatos gerados durante a fase de projeto

sero aplicados atravs das ferramentas de desenvolvimento (geralmente editores e
compiladores). Chegamos fase da codificao e do teste, que ir gerar os componentes
binrios do sistema.

3.2.8

Conjunto de teste

O fluxo de trabalho do conjunto de teste se baseia na avaliao dos artefatos executveis

gerados durante o fluxo de trabalho de implementao.
Muitas vezes desprezado, este fluxo de trabalho requer bastante esforo da equipe para que
seja de fato eficiente. Basta lembrar que realizar testes sobre os artefatos executveis sem o
auxlio de uma ferramenta de teste automtica fatalmente far a equipe identificar apenas os
mais bvios erros.

34

Isto ainda pode piorar, na medida que a equipe esteja com um ciclo de desenvolvimento
pequeno o que tornar as alteraes uma constante.
Cabe aqui mencionar os tipos de teste que podemos realizar sobre um artefato desenvolvido,
sendo cada um possuidor de um enfoque particular. So eles:
-

Teste de desempenho avalia a capacidade do sistema de funcionar rapidamente e

sob intensa demanda.

-

Teste de demanda estabelece o ponto de equilbrio do sistema ou apenas as curvas

de desempenho sob demanda

-

Teste funcional avaliam se funes especficas, definidas na especificao de

requisitos, esto implementadas corretamente (ele geralmente parte da anlise dos casos de
uso).
-

Teste de regresso testa novamente o sistema em busca de alteraes que

pudessem ter sido efetuadas. Ele tenta evitar que alteraes realizadas posteriormente no
adicione falhas a outros pontos do sistema no detectados atravs do rastreamento dos casos
de uso.
As figuras abaixo demonstram os fluxos de trabalho que envolve o conjunto de testes e
tambm suas associaes e rastreamentos:

35

Plano de teste
Desenvolver pl anbo de teste

Procedimento de teste
Projetar procedimento de teste

Equipe de teste

Script de teste
Automatizar teste
Equi pe de
arquitetura
(f rom Use Cas es)

Testar sistema

Resultados de teste

Avaliar teste

Equi pe de
impl antao
(f rom Use Cases)

Plano de teste

Script de teste
<<trace>>
Elemento do caso de uso
Procedimento de teste
<<trace>>

<<trace>>
Requisito no-funcional

Caso de teste
Negcio

Arquitetnico

(f rom Us e Cases)

(f rom Use Cas es)

36

3.2.9

Conjunto de implantao

O fluxo de trabalho do conjunto de implantao tem como objetivo maior definir o plano de
desenvolvimento, que dever ser bem estudado e construdo muito antes da produo do
sistema.
Dependendo do contexto, o plano de desenvolvimento pode ser simples (uma aplicao
Intranet) ou bastante complexo (aplicao Internet com alta demanda e segurana
imprescindvel). Tratar situaes como migrao de aplicaes (um sistema herdado sendo
gradualmente substitudo), componentes comprados de terceiros, conexes de Internet
redundantes so alguns dos exemplos que demonstram a importncia de um estudo prvio e
cauteloso sobre o desenvolvimento do sistema em si.

Plano de implantao
Desenvol ver plano de implantao

Componente binrio

Empacotar componentes

Arquivo de implantao

Equi pe de
impl antao

Pgina Web com script

Script de banco de dados

Impl antar apli cao

Procedimento armazenado
Folha de estilo

37

CAPTULO IV Principais Documentos Gerados

4.1

Documento de Viso

O documento de viso representa a viso geral de todo o projeto e funciona como a origem
de toda a anlise do que conduzir a equipe de desenvolvimento durante todo o processo.
O documento de viso possui alguns elementos principais. So eles:
4.1.1

Descrio do problema

O analista de sistema responsvel pelo documento de viso dever capturar a natureza do

problema e seu contexto. Toda a linguagem utilizada no documento dever ser a do domnio
do problema, uma vez que, normalmente, as partes interessadas no possuem conhecimento
tcnico suficiente. Alm disso, essencial que elas entendam da forma mais clara possvel as
vises do problema.
4.1.2

Lista das partes interessadas envolvidas no projeto e suas vises do sistema

Este elemento fundamental para que a equipe de desenvolvimento possa compreender para
quem o sistema est sendo criado e quais so as suas reais necessidades e expectativas
individuais. As partes interessadas podem compreender odesde os usurios finais do sistema
at departamentos ou organizaes inteiras.
4.1.3

Esboo do escopo do projeto

A grande parte dos projetos bem-sucedidos so aqueles que possuem escopo limitado. Nunca
ser possvel que todos os problemas do negcio sejam resolvidos por um sistema de
software. A equipe deve elencar o menor conjunto de necessidades das partes interessadas
que deve ser plenamente atendido, e nunca as necessidades da equipe de desenvolvimento.

Uma idia inicialmente discutida sobre recursos disponveis e intervalo de tempo tambm
contribuem bastante para um bom documento de viso.

4.1.4

Esboo da soluo de software

A soluo de software contida no documento de viso dever conter somente requisitos de

alto nvel, que iro descrever, de modo amplo, os fragmentos de funcionalidade que se espera
que o sistema possua.
Sero estes requisitos principais que iro dar origem posteriormente aos diversos requisitos
detalhados que a soluo de software exigir. A anlise e documentao de requisitos ser
discutida mais adiante.
Quanto arquitetura, o documento de viso dever ser completamente independente. Porm,
no caso de plicaes Web, comum encontrarmos termos associados a elas, e que inseridos
em alto nvel de abstrao so de fcil entendimento para toda a equipe e partes interessadas.
No caso especfico de aplicaes Web, o documento de viso dever incluir sees que
tratem de:
4.1.5

Segurana

Deve-se esboar o nvel de segurana do sistema de modo geral e apontar a(s) rea(s) onde
ela assume um papel mais crtico. Pode-se tentar estabelecer o impacto que a segurana
dever ter sobre funcionalidades e desempenho do sistema.
4.1.6

Ambientes de cliente suportados

Deve-se descrever o ambiente do cliente de destino, mencionando a verso do navegador

suportada, o sistema operacional, recursos de tela e a importncia de dar suporte a outros
clientes na primeira e futuras verses. Todas estas informaes devero ser escrutinadas no
documento de requisitos.

39

Ao fim, vale ressaltar que o documento de viso, por ser confeccionado com grande
facilidade de compreenso, bastante usado para se obter financiamento. Por isso, e para
garantir finaciamenos futuros, o documento deve conter vises realistas, e nunca futuristas ao
ponto de no se concluirem dentro do prazo e modo estipulados e causar frustrao. Estipular
critrios de sucesso efetivos e tangveis de fato tambm em muito contribuem para sua boa
aceitao.
4.2

Documento de Requisitos

Uma especificao de requisitos compreende uma coleo de artefatos (documentos,

registros de banco de dados, modelos) que iro descrever sem ambigidade um sistema de
software a ser criado.
O documento de requisitos contm informaes sobre sua finalidade, verso, seus
colaboradores e finalmente uma lista de requisitos especficos do sistema. Ele geralmente
deve estar acessvel a todas as pessoas envolvidas no projeto, sendo que para uma aplicao
Web a infraestrutura local j permite sua publicao em rede.
Um requisito representa uma restrio que o sistema deve observar. Ele possui como
finalidade expr da maneira mais objetiva possvel um comportamento ou uma propriedade
que o sistema ir possuir.
Um bom requisito aquele que possa ser verificado pela equipe de teste quando produzido.
Para tal, necessrio criar um requisito objetivo e com critrio de aprovao claramente
definido.
De modo geral, os requisitos podem ser divididos em funcionais e no-funcionais:
-

Requisito Funcionais : so aqueles que descrevem uma ao que o sistema deve

executar
-

Requisitos No-Funcionais : so aqueles que descrevem fatores como usabilidade,

desempenho, rotina, segurana, hardware e implantao.

40

Os requisitos de usabilidade se referem aos aspectos de interface entre usurio e sistema,

como a aparncia dos padres de interface, nmero mximo de cliques que o usurio pode
fazer para concluir uma funo do sistema, restries a elementos HTML, etc.
Os requisitos de desempenho geralmente esto relacionados ao tempo que o sistema leva
para executar suas funes. Normalmente eles so declarados restringindo o tempo mximo
de carregamento de pgina no navegador do cliente em situaes normais de uso do sistema.

Os requisitos de rotina tentam precaver e organizar tarefas que fatalmente a equipe ir

enfrentar, como a manuteno, a correo e o backup do sistema. Eles podem vir declarados
com sentenas que definam, por exemplo, o tempo mximo por semana que a equipe ter
para executar estar tarefas.
Os requisitos de segurana iro especificar os nveis de acesso ao sistema, sejam eles atores
humanos ou sistemas externos. Eles tambm podem definir controles de autenticao,
criptografia, deteco de intruso e auditoria.
Os requisitos de hardware geralmente definem o hardware mnimo exigido para que se
implemente o sistema, tendo a preocupao de definir um conjunto para cada camada do
sistema: cliente, apresentao, entidade e dados.
Os requisitos de implantao servem para restringir o modo como o sistema deve ser
instalado, atualizado e acessado pela equipe. Determinar um processo nico para execuo
destas tarefas importante para evitar erros de verses ou paralisaes inesperadas de partes
do sistema.
O documento de requisitos, como todos os demais criados durante o processo de
desenvolvimento de software interativo e incremental, dever sofrer alteraes ao longo do
tempo. Quanto melhor for o trabalho da equipe de requisitos, menos freqentes sero as
modificaes.

41

4.2.1

Coletando requisitos

A equipe de requisitos ser a responsvel por coletar os requisitos exigidos pelo sistema. A
participao de todos os seus membros fundamental neste momento, pois neste momento
ocorre a udana de foco entre o mundo do problema (o seu domnio) e o campo da soluo (o
mundo do sistema de software). Ser ao realizar esta transio que algumas informaes
podem ser negligenciadas ou at mesmo erroneamente transformadas.

importante que a equipe de requisitos possua como membro pelo menos um representante
da comunidade de usurios ou das partes interessadas e um membro tcnico da equipe de
desenvolvimento.
Cada requisito dever possuir uma identificao nica dentro do documento, sendo o seu
contedo auto-explicativo. Ao longo do projeto, cada elemento do modelo dever atender a
pelo menos um desses requisitos, para que sua existncia seja justificada.

4.2.2

Priorizando requisitos

Antes que os requisitos possam ser utilizados em qualquer fase do processo de

desenvolvimento, eles devem ser priorizados. Esta tarefa atribuda s equipes de
gerenciamento do projeto e de arquitetura.
Neste momento, o engenheiro de software deve assumir compromissos entre funcionalidade
e tempo para produzir. Os requisitos classificados como os de maior prioridade seriam
aqueles que viabilizam a funcionalidade do sistema como um todo. Os de prioridade mdia
englobariam os requisitos que so altamente desejveis mas podem ser retardados para um
segundo momento. J os requisitos de baixa prioridade representariam aqueles que so
desejveis, mas opcionais.
Uma boa fonte de orientao no momento de priorizar requisitos consultar o documento de
viso e indagar a importncia de sua funcionalidade perante a viso original do sistema.

42

Como visto anteriormente, o documento de requisitos bastante til para se capturar e

priorizar requisitos de desempenho, de hardware, de implementao e de usabilidade os
chamados requistos no funcionais.
Porm, esta tcnica ainda um pouco deficiente para capturar os requisitos funcionais em
sua totalidade, uma vez que eles demandam uma dinmica entre atores usurios e/ou
sistemas externos - e o sistema. Para que estes requisitos sejam capturados com uma riqueza
maior de detalhes devemos utilizar os casos de uso.

Um caso de uso consiste em uma declarao textual da interao entre um ator e o sistema.
Todo caso de uso possui uma descrio textual de um cenrio de utilizao do sistema,
contendo a entrada de dados por parte do ator e o sistema, em resposta, exibindo uma sada
observvel.
Todo caso de uso possui um cenrio denominado cenrio principal. Ele poder possuir
diversos cenrios alternativos, que geralmente iro capturar a interao ator / sistema quando
ocorrem excees durante o cenrio principal.
Um caso de uso deve expressar o que o sistema deve fazer, sem se preocupar em como ir
fazer. Ele deve descrever o comportamento do sistema quando observado pelo lado externo.
O esforo da equipe neste momento ser focar no comportamento de entrada e sada do
sistema, deixando os detalhes de arquitetura e projeto para um momento posterior.
Para uma correta declarao de caso de uso, alm de sua descrio textual de cenrio e de um
nome que reflita objetivamente sua finalidade, ele tambm dever conter:
-

Identificao nica: fundamental para se manter o rastreamento do caso de uso ao

longo do processo de desenvolvimento

-

Declarao de Meta: uma declarao simples e concisa que resuma o objetivo do

caso de uso. Bastante til durante o rastreamento de casos de uso e durante a sua prpria
confeco, uma vez que a equipe poder questionar se as aes contidas no caso de uso esto
de fato contribuindo para suportarem o objetivo pr determinado.
43

Autores: til para entrar em contato caso alguns pontos exigirem maiores explicaes

e tambm caso se verifique algum erro.

-

Suposies: uma declarao do estado sistema quando da entrada do caso de uso.

Consiste em procedimentos que a equipe julgam verdadeiros enquanto escrevem o caso de

uso
-

Condies prvias: Diferente das suposies, elas devem descrever as pr-condies

que devem ser satisfeitas antes do caso de uso se iniciar

-

Condies posteriores: devem descrever as ps-condies que devem ser satisfeitas

antes do caso de uso se encerrar. Geralmente elas representam um estado do sistema

-

Questes importantes / Observaes : Indica uma coleo de itens que precisam ser

definidos antes do caso de uso ser utilizado nas etapas de anlise e projeto.

Como o caso de uso utilizado para melhor descrever os requisitos funcionais, eles devero
estar escritos - assim como os requisitos na linguagem do domnio. Como ser visto a
seguir, o modelo de caso de uso da UML uma ferramenta bastante til no s para a
comunicao entre os membros da equipe, mas tambm entre a equipe e as partes
interessadas. E neste momento a linguagem do domnio se faz imprescindvel.

4.3

Documento de Caso de Uso

A UML nos auxilia a dar uma interpretao grfica dos casos de uso e dos atores que
interagem com o sistema:

44

<<communicate>>
Listar Promoes

Usurio

(f rom <Use Case Name>)

(f rom Actors)

Os relacionamentos entre ator (no exemplo Usurio) e caso de uso (Listar Promoes)
indicam que o ator poder requisitar o caso de uso especificado.
Os principais relacionamentos entre casos de uso so os do tipo <<include>> e <<extend>>.
Ambos representam uma relao de dependncia entre casos de uso. O relacionamento
<<include>> entre casos de uso indica que um ir chamar o outro pelo menos uma vez
quando requisitado. J o relacionamento <<extend>> indica que o caso de uso pode - ou no
estender o dilogo entre com o sistema ao chamar o outro caso de uso.

<<incl ude>>

Cliente

Pagar Fatura

Atuali zar Conta Corrente

<<extend>>

Pagar taxa

O modelo de caso de uso mostra um relacionamento estrutural entre os casos de uso, sem
mostrar os relacionamentos dinmicos ou fluxos de trabalho. Para tal, a equie deve utilizar
deveremos os diagramas de seqncia, atividade e colaborao.
Sero os diagramas de atividade que iro mostrar claramente todos os cenrios o principal e
os alternativos durante cada caso de uso. Eles tambm esclarecem a natureza dos
relacionamentos <<include>> e <<extend>>. Basta notar no diagrama de atividades se
possvel que o ator v da atividade inicial final sem chamar o caso de uso extendido.
45

Tambm til gerar diagramas de seqncia para cada cenrio de caso de uso. Eles iro
auxiliar a equipe a identificar as declaraes mais importantes no texto do caso de uso. Ao se
deparar com casos de uso prolixos esta atividade ser muito bem-vinda.

Usurio

Sistema

Entrar na rede

Exibir campos "Login" e "Senha"

Informar login e senha

Validar Login e Senha

Exibir Tela Inicial

Vale ressaltar que estes diagramas de seqncia sero constitudos apenas pelo ator e uma
instncia do sistema, cabendo s etapas de mais baixo nvel a tarefa de expandir as
mensagens entre os dois em mensagens concretas entre instncias de classes determinadas.

46

4.4

Documento de Anlise

Tendo em mos os documentos de requisitos e de casos de uso - cada um focado,

respectivamente, em requisitos estticos e dinmicos das regras de negcio -, a equipe de
anlise j se encontra em condies de desenvolver um modelo de anlise do sistema.
O modelo de anlise do sistema ser composto por classes e colaboraes de classes que iro
exibir os comportamentos dinmicos detalhados nos casos de uso e nos requisitos.
As classes iro representar objetos do domnio do negcio ou do campo do problema, tais
como carrinho de compras, pedido, artigo, produto, etc.
recomendvel que o nvel de abstrao do modelo de anlise seja tal que as mesmas classes
possam ser definidas independente da arquitetura do sistema. Na prtica, porm, sabemos
que a arquitetura comea a surgir com importncia neste momento do processo e algumas
observaes sero consideradas.
A anlise deve enfocar os requisitos funcionais do sistema, ignorando temporariamente suas
restries. Desta forma, iremos garantir que todos os requisitos funcionais estejam
implementados em algum lugar do sistema.
4.4.1

Estrutura

A atividade inicial da equipe de anlise ser criar a hierarquia de pacotes do modelo de

anlise. Um pacote em UML representa uma amostra do modelo, de tamanho pequeno
suficiente para que uma pessoa possa entender seu significado e e finalidade no modelo.
Os pacotes iro conter elementos do modelo, como classes, diagramas, componentes, etc. As
classes do interior do pacote podero ser pblicas ou privadas. Sero as classes pblicas as
responsveis pela interface pblica do pacote.
Definidas as classes pblicas que iro se comunicar com o restante do sistema, o analista
ganha a liberdade de criar quantas classes privadas quiser sem afetar o restante da equipe. J
possveis alteraes em classes pblicas devero ser combinadas com todos.
47

O modelo de anlise de nvel superior deve considerar a diviso de pacotes realizada durante a
atividade de definio dos casos de uso:

Preo Promocional

Usurio

Emprstimo

(f rom Projeto Final)

(f rom Projeto Final)

(f rom Projeto Final)

Mesmo sendo um bom ponto de partida, este modelo inicial pode falhar ao tentar definir a
viso estrutural do sistema, que so as classes. Isto ocorre porque provvel que alguns
objetos participem de muitos casos de uso e pacotes e logicamente no podem ser atribudos a
um nico pacote de caso de uso.
Por isso, aconselhvel que, ao partir do modelo de anlise de nvel superior, se v a nveis
mais baixos e consigamos dividir cada pacote principal em menores. Desta maneira, a equipe
conseguir gerenciar melhor o modelo de anlise e agrupar os futuros objetos semelhantes, e
no os comportamentos.
Em resumo, ao definir pacotes a equipe de anlise dever se preocupar em garantir que eles
sejam:

Compreensveis;

Coesivos as classes do pacote devem se agrupar naturalmente;

Conjugados livremente as classes se relacionam mais com classes do prprio

pacote do que com classes externas ao pacote;

Hierarquicamente

superficiais

poucos

nveis

hierrquicos

reduzem

complexidade. O limite costuma ser de dois ou trs nveis.

4.4.2

Elementos estruturais

Neste momento, a equipe j identificou todos os objetos ao analisar os casos de uso. As

classes podem ser classificadas como classes estereotipadas boundary (fronteira), control
(controle), e entity (entidade):

48

Usuario do
sistema

Fronteira

Controle

Entidade

(f rom Actors)

As classes de fronteira conectam os usurios ao sistema. Em uma aplicao Web, elas so as

pginas ou telas do sistema.

As classes de controle fazem o mapeamento para os processos que distribuem a

funcionalidade do sistema.
As classes de entidade representam tudo o que persistente no sistema, como o banco de
dados. As entidades so compartilhadas e possuem um cliclo de vida fora de qualquer uso do
sistema, considerando que as instncias de controle possuem um ciclo de vida bem definido.
As classes surgidas a partir da anlise dos casos de uso de uma aplicao Web sero
classificados como classes de entidade e de controle. As classes de fronteira sero
identificados durante a anlise de experincia do usurio, nosso prximo tpico.
4.5

Experincia do Usurio UX

O modelo de experincia do usurio user experience (UX) representa um novo conceito na

modelagem de sistemas e ganha especial importncia nas aplicaes Web.

O termo experincia do usurio descreve todas as atividades responsveis por manter a

interface com o usurio adequada ao contexto no qual se espera que o sistema seja executado.
A equipe de UX responsvel por criar a aparncia da aplicao, determinar as rotas de
navegao principais das pginas Web do sistema e gerenciar a estrutura do contedo das
pginas.

49

A equipe de UX ir desenvolver artefatos que incluiro desde a definio de cores e fontes at

o posicionamento de informaes na tela durante o fluxo de navegao. Algumas dessa
informaes sero arquitetonicamente significativas, enquanto outras tero efeito puramente
cosmtico.
4.5.1

Artefatos do modelo UX

O modelo de UX um modelo separado dos demais porque uma visualizao completa do

sistema do ponto de vista de suas telas. As propriedades arquitetonicamente significativas das
telas e seus relacionamentos de navegao so os elementos principais do modelo UX e
merecem maior ateno.

Roteiro
1..*

1..*
Equipe de UX

Diagrama de colaborao

Tela
1..*

O conceito de tela no pode ser confundido com pgina Web, que so os mecanismos que
criam e produzem as telas. Desta forma, a tela representa estritamente o que apresentado ao
usurio.
Cada tela de uma aplicao Web dever possuir um contedo esttico geralmente fornecido
pelo sistema de arquivos do servidor - e um contedo dinmico construdo a partir da
interao com os componentes do lado do servidor.
Alm destas propriedades, a tela tambm possui:

Nome e descrio;

Campos de entrada e controles que aceitem a entrada de dados do usurio;

50

A representao em UML de uma tela se d atravs de uma classe estereotipada screen

definida pela WAE (a ser definida adiante):

Nome da Tela

Como em qualquer modelo, nem todas as propriedades de uma tela so adequadas para serem
capturadas por ele, que representa uma simplificao, uma abstrao da realidade.
O contedo esttico da tela e a sua estrutura (layout) no devem ser capturados pelo
modelo. J o contedo dinmico arquitetonicamente significativo e deve ser representado
pelo modelo da equipe de UX. A representao da associao entre a tela e o contedo
dinmico igual a todas as classes UML. No exemplo abaixo, a tela de promoo possui
como contedo dinmico o nome do artigo, da loja e uma lista contendo linhas de preo
promocional:

Preo Promocional

Tela de Promoo
Nome do Artigo
Nome da Loja

0..*

Preo : Currency
Inicio : Date
Fim : Date

IncluirPromocao()

4.5.2

Entrada de dados do usurio

Os formulrios de entrada de dados so muito importantes para o modelo de UX. Eles so

modelados como como uma classe estereotipada <<input form >>. Os campos de entrada
so capturados como atributos e podem ser classificados como caixas de texto, checkbox, lista
de seleo, etc:

51

Promoo
Data inicial : TextBox
Data final : TextBox
Preco : textBox

Atravs destas classes estereotipadas, os artefatos de UX os cenrios de roteiro e os

caminhos de navegao - podem ser construdos de maneira apropriada.
Um cenrio de roteiro tem como objetivo expressar um uso tpico do sistema atravs dos
olhos do usurio. As telas utilizadas para cada cenrio de roteiro podem ser acessadas mais de
uma vez e com um conjunto de dados dinmicos. Um diagrama de seqncia envolvendo as
telas somado a pequenas descries textuais executam bem esta tarefa.
J o mapa de caminhos de navegao, que ir expressar todos os caminhos legais e esperados
ao longo do sistema, ir conectar as telas a seus formulrios de entrada e outras telas atravs
de associaes UML.
4.6

Documento de Arquitetura

O planejamento da arquitetura do sistema visa definir um conjunto de restries que sero

aplicados nas equipes de projeto e implementao durante a transformao dos modelos de
requisitos e anlise em sistema executvel.

Desse modo, compreensvel que o documento de arquitetura tente abranger diversos pontos
de vista do sistema. Cada ponto de vista ou viso ser uma projeo dos modelos da
aplicao Web.
Num primeiro momento esta atividade pode parecer redundante, uma vez que cada modelo
criado a partir de uma abstrao diferente do sistema. Porm, o documento de arquitetura ir
focar apenas no que arquitetonicamente significativo. Um requisito arquitetonicamente
significativo aquele que possui um profundo impacto no desenvolvimento do resto do
sistema.
52

As vises iro compreender, assim, os requisitos, os modelos de projeto UML viso lgica e
de processos a realizao do sistema (quais sero os mecanismos de comunicao? H
limites de desempenho?) e as estratgias e estruturas de teste.
4.6.1

Atividades da Arquitetura

As principais atividades da arquitetura so:

Priorizar os casos de uso arquitetonicamente significativos;

Definir e documentar uma arquitetura candidata;

Definir a estratgia de reutilizao

Ao priorizar os casos de uso, deve-se buscar aqueles que apresentam maior risco, que
envolvam uma tecnologia nova e/ou desconhecida para a equipe ou que exija um alto grau de
desempenho. Desta maneira, a equipe estar evitando surpresas desagradveis durante o
desenvolvimento da aplicao.

Ao definir uma arquitetura candidata para uma aplicao Web, deve levar em considerao os
requisitos significativos e tambm os aspectos culturais da empresa destinada a realizar o
sistema. Assim, as experincias anteriores e as habilidades dos profissionais envolvidos so
determinantes para a deciso da arquitetura candidata.

4.6.2

Padres arquitetnicos de alto nvel

Um padro arquitetnico tem como objetivo nos ajudar a compreender as formas bsicas de
camadas de apresentao em uma aplicao Web.
Os trs padres mais comuns so:

O cliente Web magro utilizado basicamente para aplicaes baseadas na

Internet. Se caracteriza por um pouco controle sobre a configurao do cliente. Toda a lgica
do negcio executada no servidor.

O cliente Web gordo uma parte significativa da lgica do negcio

executada no cliente, utilizando HTML, applets e controles ActiveX. A aplicao ainda utiliza
o protocolo HTTP para comunicao com o servidor.
53

Produo Web Caracterizado quando o browser age como um dispositivo

de produo e de continer para um de sistema de objetos distribudos. Alm do HTTP, a

aplicao pode utilizar os protocolos IIOP e DCOM.
Considerando os padres mais comuns Clientes Web magro e gordo -, os principais
componentes de ambas arquiteturas so:

Navegador: realiza a interface com usurio, solicita pginas Web, HTML,

scripts e applets;

Servidor Web: recebe as solicitaes por pginas Web, estticas ou do

servidor. Responsvel por formatar a pgina HTML e envi-la ao navegador do cliente;

Protocolo HTTP: realiza a conexo entre cliente e servidor;

Pgina esttica: pgina Web que no processa nada do lado do servidor;

Pgina dinmica: pginas Web que processam algo do lado do servidor, sendo

implementadas como pginas com script (ASP, JSP, PHP, etc)e processadas por um servidor
de aplicao;

Servidor de aplicao: responsvel por executar o cdigo das pginas do

servidor;

Servidor de banco de dados: mantm o estado do sistema persistente;

Sistemas de arquivos: responsvel por gerenciar arquivos HTML e arquivos

Web com scripts

A figura abaixo mostra os relacionamentos entre os componentes bsicos dos padres de
arquitetura Cliente Web magro e gordo:

54

<<Apresenta>>

Pgina Web

Script

Applet
Servidor de Banco de dados

Navegador
DOM

Servidor de Aplicao
HTTP

Servidor Web
Recurso de pgina

Pgina Dinmica

Pgina Esttica

Sistema de Arquivos

4.7

Projeto

A etapa do projeto aquela onde a abstrao do negcio comea a se materializar na realidade

de um software.

Com base no modelo de anlise, no modelo de UX e no documento de arquitetura, a equipe de

projeto ter como finalidade refinar o modelo de anlise, de forma que ele possa ser
implementado com os componentes que obedecem s regras da arquitetura.

Desse modo, as classes se tornam mais definidas, com atributos totalmente qualificados
nome e tipo e mtodos contendo assinaturas perfeitas. Nesta fase de projeto surgem as
classes auxiliares e de implementao. Ao final, temos um modelo que pode ser mapeado
diretamente para o cdigo, que de fato o vnculo entre as regras de negcio abstratas e a
realidade do software.

55

Alm disso, durante a fase de projeto a equipe tambm dever separar os objetos entre
camadas - cliente, servidor e outras que possam ser identificadas e definir interfaces com o
usurio por meio das pginas Web.

Ao particionar os objetos em suas camadas, precisamos conhecer quais camadas esto

disponveis para os objetos. Estas e outras respostas sero dadas pela arquitetura adotada para
o sistema. Por exemplo: caso o padro arquitetnico de cliente da aplicao Web seja o de
cliente Web magro, este no capaz de suportar objetos definidos na camada do cliente.
Desta forma, todos os objetos devero estar presentes na camada de servidor.

Neste momento, nota-se a importncia das pgina Web. A pgina Web atua como um
continer generalizado de interface com o usurio, unindo o navegador com o restante do
sistema. Para a modelagem de aplicaes Web, ento, vital capturar as pginas e representlas com a mesma preocupao concedida s classes e componentes do restante do sistema.

Partindo deste conceito a pgina Web um objeto como outro qualquer a modelagem de
pginas Web levanta questes referentes a como representar a dinmica de scripts que rodam
no servidor e outros scripts que rodam no cliente. Ou seja, temos comportamentos
completamente distintos dependendo da camada onde a pgina estar sendo processada.

A simples utilizao dos conceitos da UML no consegue representar de forma adequada esta
nova realidade. Por isso, os criadores da UML criaram uma maneira de estender a linguagem
de forma controlvel: a extenso de aplicao Web (WAE).

56

4.7.1

WAE Web Application Extension

A extenso de aplicao Web permite que se represente pginas Web e outros elementos
significativos do ponto de vista arquitetnico do modelo, juntamente s classes normalmente
utilizadas para todos os sistemas de software.
A seguir, sero apresentados os principais esteretipos, valores com tags e restries que
compem esta extenso da UML.
4.7.1.1 Viso Lgica
A WAE define trs esteretipos de classe principais:

Pgina do Servidor

Representa uma pgina Web dinmica, que contm scripts que so executados pelo servidor,
interagindo com recursos do lado do servidor, como bancos de dados, componentes de lgica
do negcio, sistemas externos, etc.

Server Page

As pginas de servidor s se relacionam com objetos no servidor

Pgina do Cliente

Representa uma pgina Web formatada em HTML com uma mistura de dados, apresentao e
lgica. Elas so apresentadas pelos navegadores, podendo conter scripts interpretados tambm
pelo navegador.
As pginas do cliente podem se associar a outras pginas do cliente e do servidor.

Cli ent Page

57

Formulrio HTML

Representa uma coleo de campos de entrada que so parte de uma pgina do cliente, sendo
mapeada diretamente para a tag <form> da HTML.

HTML Form

As relaes bsicas entre os elementos estereotipados WAE podem ser observadas abaixo:

Client Page

Form

<<buil d>>

Server Page

<<submit>>

Os principais esteretipos de associao da WAE so:

58

Relacionamento entre uma pgina no cliente e outra

pgina no cliente ou pgina no servidor. Representa o
<<link>>

elemento <a> da HTML. Possui um valor com tag de

nome parameters, que transmite seus valores junto com
a solicitao HTTP.
Relacionamento entre uma pgina do servidor e uma

<<build>>

pgina do cliente. Representa a construo da sada

HTML por parte da pgina do servidor.
Relacionamento entre um formulrio HTML e uma

<<submit>>

pgina do servidor. Todos os atributos de campo do

formulrio so enviados ao servidor, junto com a
solicitao HTTP.
Representa um comando de uma pgina do cliente para

<<redirect>>

solicitar outro recurso, podendo ser pginas do cliente ou

servidor
Relacionamento entre uma pgina do cliente e uma classe

<<object>>

lgica, geralmente um applet ou controle ActiveX.

Representa os elementos HTML <object> e <applet>
Associao entre uma pgina do servidor e pginas do

<<include>>

servidor ou cliente. Indica que a pgina includa

processada e seu contedo utilizado pela pgina pai.
Relacionamento entre uma pgina do servidor e outra

<<forward>>

pgina do servidor ou cliente. Representa a delegao de

processamento de uma solicitao do cliente de um
recurso para outra pgina do lado do servidor.

4.7.1.2 Viso de Componente

A viso de componente de um modelo UML ir representar os arquivos distribudos que
compem o sistema durante a sua execuo. A WAE define dois esteretipos de componentes
abstratos, que sero representados por esteretipos dependentes da linguagem utilizada
(<<JSP>>, <<ASPX>>, <<ASCX>>, <<XML>>, etc).
Os dois esteretipos definidos so:

Pgina Esttica

59

Representa um recurso que pode ser solicitado diretamente pelo navegador do cliente. Ela
produzida diretamente do sistema de arquivos para o cliente.

Pgina Esttica

Ela no pode implementar componentes lgicos que sero executados no servidor.

Pgina Dinmica

Representa um recurso que pode ser solicitado pelo navegador do cliente. Quando estiver
apontado pela associao <<forward>>, ocorre o processamento do lado do servidor. Os
resultados podem alterar o estado do servidor para construir algum HTML a ser transmitido.

Pgina Dinmica

<%
%>

A pgina dinmica deve implementar apenas uma pgina do servidor

A WAE tambm define um pacote de componentes:

Raiz Fsica

Representa uma abstrao de uma hierarquia de arquivos que contm recursos disponveis
solicitao. Ele nos remete diretamente para um diretrio do sistema de arquivos do servidor
Web. Para isto, seus valores de tag Web Location (ex: www.projetofinal.com.br ) e
Project Directory (ex: www.projetofinal.com.br/LucasAlenquer) so utilizados.
Raiz Fsica

4.7.2

Mapeando o projeto para o modelo UX

60

Formalizar a experincia do usurio em um modelo UML facilita o entendimento do que se

quer realizar por parte da equipe criativa responsvel pelo layout das telas e tambm
permite que a equipe de engenharia de software mantenha um mapeamento direto entre os
casos de uso e os modelos de projeto para o modelo UX.

Este mapeamento se d a partir de diagramas de classe contendo telas de UX e classes do

modelo de projeto ligadas atravs de relacionamentos de dependncia.

No exemplo abaixo, a tela Home estabelece um relacionamento de agregao com a tela de

cabealho, e sua plena visualizao depende das pginas no servidor WpgHome.aspx e
WctHeader.ascx:

Cabealho

WctHeader.ascx

Tela Home

WpgHome.aspx

Refinando a modelagem teremos o seguinte cenrio:

61

Elementos do modelo UX

Elementos do modelo de projeto

Cabealho

WctHeader.ascx
<<forward>>

Tela Home

<<build>>

WpgHome.aspx

FormulrioHome

WpgHome.html

FormHome

Desta forma permitiremos que as duas equipe possam trabalhar de forma relativamente
independente. A equipe de UX pode desenvolver o HTML e supor que o acesso a
determinado contedo estar disponvel. J a equipe de engenharia ir trabalhar com esboos
das pginas Web bastante simples, apenas para testar o seu funcionamento.

62

Neste captulo esto reunidos os artefatos gerados durante a realizao de uma iterao sobre
o sistema Livraria, onde novos requistos so introduzidos e o projeto ser orientado a objetos.
5

CAPTULO V Caso - Sistema Livraria - Artefatos Gerados

5.1
5.1.1

Documento de Viso - Sistema Livraria Descrio do problema

Uma livraria com lojas espalhadas pela cidade necessita realizar um correto gerenciamento
sobre seus processos, principalmente os que interferem no preo praticado dos artigos venda
e, conseqentemente, nos seus estoques.
Neste contexto, necessrio armazenar e acessar dados sobre as transaes que os
funcionrios das lojas esto envolvidos, como a definio/alterao de promoes nos preos
praticados e emprstimo de artigos para clientes, bem como limitar o acesso de alguns
funcionrios a partes do sistema cujas tarefas no lhe competem.
5.1.2

Partes interessadas envolvidas:

Funcionrios: sero eles os reais utilizadores do sistema.

Viso do Sistema : O sistema dever se comportar como um automatizador de procedimentos
antes executados manualmente e armazenados sob forma de papel.
5.1.3

Esboo da soluo de software:

importante ressaltar que a soluo de software a ser desenvolvida compreende uma nova
iterao sobre um sistema j existente e em fase de evoluo. Desta forma, alguns requisitos
e seus posteriores casos de uso j foram implementados e os requisitos abaixo mencionados
sero adicionados ao sistema.
Os requisitos bsicos os quais o sistema se destina so:

- Gerncia de Preo Promocional

O usurio poder escolher um determinado artigo e programar - ou cancelar - o perodo e o
valor de um preo promocional a ser praticado em uma determinada loja.
- Gerncia de Emprstimo
O usurio escolher um determinado artigo e sero armazenados dados referentes a um
emprstimo a um cliente em uma determinada loja, bem como os dados de sua posterior
devoluo.
O sistema dever informar o saldo da quantidade e do valor dos artigos que um cliente possui
sob emprstimo no momento.
- Cadastro de Usurio
O sistema dever tratar da insero e edio de informaes dos usurios do sistema, que
permitiro a sua entrada atravs de um login identificador e uma senha pessoal.
5.1.4

Esboo do escopo do projeto:

O sistema ser uma aplicao ASP.NET que ir permitir que o usurio edite preos
promocionais, gerencie emprstimos de artigos e realize cadastro e alterao de dados dos
usurios do prprio sistema.
Para realizar tais tarefas, sero utilizados os seguintes recursos:
1.

Classes ASP.NET com implementao em Visual Basic .NET;

2.

Pginas Web com extenso .aspx;

3.

Scripts do lado do cliente;

4.

Banco de Dados SQL Server;

5.

Stored Procedures , Funes e Views armazenadas no Banco de Dados determinado

O sistema ser composto por uma pgina central, que ir conter links para as pginas que iro
realizar os casos de uso desejados.

64

Cada pgina ter a responsabilidade de garantir a consistncia dos dados visualizados pelo
usurio atravs da conexo com o Banco de Dados, se utilizando de artefatos previamente
armazenados (Stored Procedures , Funes e Views) para capturar as informaes que
desejar.
Os scripts do lado do cliente tero como finalidade bsica poupar o servidor da aplicao de
requisies desnecessrias, realizando tarefas tais como verificao de dados de entrada do
usurio e outras que no necessitem de interao com o servidor.

Gerncia de Preo Promocional

Haver uma pgina que receber uma identificao do artigo especificado. Conhecendo o
artigo, surgir uma listagem com os valores e os perodos de validade dos preos
promocionais anteriormente registrados.
Haver um formulrio para entrada de dados referentes a um novo preo promocional ou a um
j existente (neste caso uma modificao de informaes).

Gerncia de Emprstimo

O usurio acessar uma pgina contendo uma listagem com os clientes que possuam
emprstimos realizados em cada loja. Cada nome de cliente, quando clicado, funcionar como
um link para uma nova pgina que mostrar os detalhes do emprstimo do cliente e na loja
especificados.

Cadastro de Usurio

O usurio acessar uma pgina contendo uma listagem com os usurios do sistema
cadastrados. Haver um link para uma nova pgina que ir conter um formulrio para entrada
de dados de cadastro de um novo usurio. Caso o usurio clique sobre o nome de um usurio
da listagem, a nova pgina que contem o formulrio ir surgir com o mesmo j preenchido
com os dados mais recentes do usurio escolhido.

65

5.2

Glossrio - Sistema Livraria

Artigo Qualquer item que esteja venda em qualquer uma das lojas existentes.
Cliente Pessoa Fsica ou Jurdica que se envolve em qualquer tipo de operao com a
empresa
Devoluo Movimento de entrada de estoque que se caracteriza quando o cliente ou
funcionrio retorna o(s) artigos(s) emprestado(s) loja de origem.
Emprstimo - Movimento de sada de estoque que se caracteriza quando o cliente ou
funcionrio obtm um ou mais artigos sob emprstimo junto loja de origem.
Funcionrio Qualquer pessoa que esteja contratada pela livraria em qualquer uma das lojas
existentes.
Loja Qualquer estabelecimento comercial que esteja em funcionamento sob a marca da
livraria.
Preo Promocional Preo de venda praticado para um determinado artigo em uma
determinada loja, tendo um valor expresso em moeda local e um perodo de validade prdefinido.
Produtor Pessoa jurdica responsvel pela produo de um artigo.
Usurio Qualquer pessoa fsica ou jurdica que possua acesso ao sistema da livraria e dele
se valha para executar tarefas ou obter informaes sobre a livraria.

66

5.3

Documento de Requisitos - Sistema Livraria -

Finalidade Determinar todas as funcionalidades e restries que o sistema dever obedecer.

importante ressaltar que os requisitos compreendem uma nova iterao sobre um sistema
j existente e em fase de evoluo. Desta forma, alguns requisitos e seus posteriores casos de
uso j foram implementados e os requisitos abaixo mencionados sero adicionados ao
sistema.
Verso 1.0
Colaboradores Lucas Lopes Alenquer
5.3.1

Requisitos Funcionais

5.3.1.1 Gerncia de Preo Promocional

Finalidade: O sistema dever permitir que o usurio escolha um determinado artigo e possa
programar - ou cancelar a data de incio, a data de trmino e o valor de um preo
promocional a ser praticado em uma determinada loja.

Cada artigo poder possuir um preo promocional diferente em cada loja da livraria.
As datas de incio e de trmino devero ser formatadas na ordem dia / ms / ano.
O preo promocional dever ser formatado como nmero real com duas casas decimais e com
a parte decimal separada por vrgula.

67

5.3.1.1.1 Requisito
O sistema dever permitir que o usurio visualize, dentre uma lista de artigos, aquele que
deseja programar um preo promocional.
Critrio de sucesso: O sistema deve mostrar o nome e o produtor do artigo escolhido.
5.3.1.1.2 Requisito
O sistema dever permitir que o usurio escolha a loja para qual deseja programar o preo
promocional do artigo selecionado.
Critrio de sucesso: O sistema deve mostrar uma lista com os dados das ltimas
programaes do artigo na loja selecionada: datas de incio e de trmino, preo de venda
programado e o nome do autor da programao
5.3.1.1.3 Requisito
O sistema dever permitir somente a entrada de preos promocionais cuja data de incio(dia
ms e ano) seja posterior data corrente. Caso contrrio, o usurio dever ser informado.
Critrio de sucesso: O sistema mostrar mensagem de confirmao de entrada do preo
promocional e mostrar a lista com os dados das programaes (datas, preo de venda
programado e o nome do autor da programao) j incluindo a nova entrada.
5.3.1.1.4 Requisito
O sistema dever permitir a entrada de quantos forem os preos promocionais programados,
desde que um perodo no se sobreponha a outro existente.
Critrio de sucesso: O sistema mostrar mensagem de confirmao de entrada do preo
promocional e mostrar a lista com os dados das programaes (datas, preo de venda
programado e o nome do autor da programao) j incluindo a nova entrada. Caso contrrio,
o usurio dever ser informado.

68

5.3.1.1.5 Requisito
O sistema dever permitir que se altere o valor de um preo promocional somente enquanto
sua data de entrada em vigor no tiver sido alcanada.
Critrio de sucesso: O sistema dever atualizar a lista com os dados dos preos promocionais
programados (datas, preo de venda programado e o nome do autor da programao). Caso
contrrio o usurio dever ser informado.
5.3.1.1.6 Requisito
O sistema dever permitir que o usurio altere as datas de incio e de trmino do preo
promocional programado, desde que o novo perdo no seja anterior data corrente e tambm
no seja posterior data de incio de um eventual prximo preo promocional.
Critrio de sucesso: O sistema dever atualizar a lista com os dados dos preos promocionais
programados (datas, preo de venda programado e o nome do autor da programao). Caso
contrrio o usurio dever ser informado.
5.3.1.1.7 Requisito
O sistema dever permitir que o usurio cancele uma programao de preo promocional cujo
perodo seja posterior data corrente.
Critrio de sucesso: O sistema dever atualizar a lista com os dados dos preos promocionais
programados (datas, preo de venda programado e o nome do autor da programao). Caso
contrrio o usurio dever ser informado.
5.3.1.2 Gerncia de Emprstimo
O sistema escolher um determinado artigo e permitir o armazenamento de dados
referentes a um emprstimo a um funcionrio em uma determinada loja, bem como o de sua
posterior devoluo.
O sistema dever informar o saldo da quantidade e valor dos artigos que o cliente possui sob
emprstimo no momento.

69

Somente funcionrios da livraria podero realizar emprstimos.

O saldo corresponde ao nmero de itens tomados emprestados pelo funcionrio subtrado do
nmero de itens devolvidos at o momento.
Um artigo jamais poder ser devolvido loja sem antes ter sido emprestado.
O movimento de emprstimo representa um decrscimo do estoque fsico, enquanto a
devoluo representa um acrscimo ao estoque fsico.
Um funcionrio poder realizar um emprstimo somente nas lojas as quais possui relao.
5.3.1.2.1 Requisito
O sistema dever permitir que o usurio visualize uma lista contendo os nomes dos
funcionrios e das lojas em que realizaram emprstimos, seu respectivo saldo e o valor em
moeda corrente dos itens ainda por devolver.

Critrio de sucesso: As informaes contidas na tela devem corresponder fielmente s

contidas na base de dados.
5.3.1.2.2 Requisito
O sistema dever permitir que o usurio escolha visualizar os detalhes de cada emprstimo
separadamente, composto pelo nome do funcionrio, da loja, de cada um dos artigos
emprestados, o seu preo de venda e a data de cada movimento de emprstimo e devoluo.
Critrio de sucesso: As informaes contidas na tela devem corresponder fielmente s
contidas na base de dados.
5.3.1.2.3 Requisito
O sistema dever permitir que o usurio insira o emprstimo de mais um item por ele
especificado, bem como sua quantidade.

70

Critrio de sucesso: O sistema mostrar mensagem de confirmao de entrada do novo

emprstimo e mostrar a lista atualizada com os dados dos movimentos, j incluindo o novo
emprstimo.

5.3.1.2.4 Requisito
O sistema dever permitir que o usurio insira a devoluo de um item por ele especificado,
bem como sua quantidade.
Critrio de sucesso: O sistema mostrar mensagem de confirmao de entrada da nova
devoluo e mostrar a lista atualizada com os dados dos movimentos, j incluindo a nova
devoluo.
5.3.1.2.5 Requisito
O sistema dever permitir que o usurio visualize apenas os artigos que o funcionrio ainda
est por devolver.
Critrio de sucesso: O sistema mostrar uma lista contendo apenas os artigos cujo saldo no
sejam iguais zero.
5.3.1.3 Gerncia de Usurio
O sistema dever tratar da insero e edio de informaes dos usurios do sistema, que
permitiro a sua entrada atravs de um login identificador e uma senha pessoal.
Cada usurio possuir um login composto por caracteres alfanumricos e senha de at 7
caracteres alfanumricos.
A senha do usurio dever ser criptografada e ento armazenada no sistema.
Cada usurio poder informar, alm de login e senha, seu nome, e-mail para contato e
telefone.
71

Cada usurio dever estar ligado a no mnimo uma loja.

Cada usurio dever estar ligado a no mnimo um departamento de uma loja.
Cada usurio dever possuir ao menos um privilgio de acesso ao sistema.
5.3.1.3.1 Requisito
O sistema dever permitir que o usurio visualize uma lista contendo todos os usurios do
sistema, indicando seus respectivos privilgios, lojas a que esto ligados e os departamentos a
que pertencem.
Critrio de sucesso: As informaes contidas na tela devem corresponder fielmente s
contidas na base de dados.
5.3.1.3.2 Requisito
O sistema dever permitir que o usurio altere as informaes de um usurio especificado.
Critrio de sucesso: O sistema mostrar uma lista atualizada com os usurios do sistema, j
contendo os dados alterados do usurio especificado.
5.3.1.3.3 Requisito
O sistema dever permitir que o usurio insira as informaes de um novo usurio.
Critrio de sucesso: O sistema mostrar uma lista atualizada com os usurios do sistema, j
contendo os dados do novo usurio.

72

5.3.2

Requisitos No Funcionais

5.3.2.1 Usabilidade
O sistema no dever se utilizar de elementos frame de HTML.
O sistema deve permitir que o usurio execute uma funo do sistema em no mximo quatro
cliques.
5.3.2.2 Desempenho
O sistema dever levar no mximo 8 segundos para executar suas funes e carregar suas
pginas no navegador do cliente.
5.3.2.3 Rotina
A manuteno do sistema dever ocorrer uma vez por semana quando em funcionamento
normal.
A correo de possveis falhas dever ocorrer uma vez por semana, porm nunca s sextasfeiras, por se tratar da vspera de fim de semana perodo de maior movimento nas lojas da
livraria.
O backup do sistema dever ocorrer todos os dias, ao trmino do horrio comercial.

73

A equipe dever possuir no mximo 12 horas para executar todas as tarefas mencionadas
anteriormente.
5.3.2.4 Segurana
Alm do controle de acesso ao sistema atravs de login e senha pessoal criptografada, o
sistema no ir exigir outras medidas preventivas, por se tratar de um sistema de Intranet que
no estar exposto a outros sistemas externos.
5.3.2.5 Hardware
As mquinas dos clientes devero possuir no mnimo 256MB de memria RAM e o
navegador Internet Explorer instalado. O servidor de banco de dados dever possuir no
mnimo 8GB de espao em disco.
5.3.2.6 Implantao
Todos os membros da equipe devero seguir o mesmo processo de alterao do
sistema. As atividades ocorrero na seguinte ordem:
1-

Verificar se h cpia do sistema no dia. Caso no haja, o integrante da equipe dever

cri-la no diretrio de backup;

2-

Copiar para o diretrio de pr-alterao todos os arquivos do sistema que foram

criados / modificados aps a data da ltima cpia anterior ao dia de hoje;

3-

Gerar um script com todos os objetos da base de dados que foram criados /

modificados aps a data da ltima cpia anterior ao dia de hoje;

4-

Filtrar os arquivos do sistema de modo a obter apenas aqueles que compem a

apresentao do sistema;

74

5-

Incluir todos os arquivos criados / alterados do sistema no diretrio de teste e gerar o

novo executvel;
6-

Enviar e-mail para a equipe contendo todos os arquivos do sistema e objetos da base

de dados criados / alterados e suas respectivas funcionalidades;

7-

Durante a fase de testes: caso surja algum problema, retornar com o sistema

armazenado como backup e reiniciar o processo at obter o resultado desejado.

5.4

Documento de casos de uso Sistema Livraria -

Neste documento estaro relacionados todos os casos de uso gerados para implementar os
requisitos descritos para a iterao de desenvolvimento de software do sistema Livraria.
5.4.1

Gerncia de preo promocional

<<include>>

Cancelar Preo Promocional

<<incl ude>>

Cadastrar Preo Promocional

Usuari o
<<incl ude>>

(f rom Actors)

Alterar Preo Promocional

Listar Preo Promocional

5.4.1.1 Casos de Uso

5.4.1.1.1 Listar Preo Promocional

75

Declarao de Meta: listar todos os preos promocionais cadastrados de um artigo

numa loja especificada.

-

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: O cdigo identificador do artigo deve ser conhecido.

Condies posteriores: Nenhuma

Questes importantes / Observaes : Nenhuma

1 O sistema exibe a pgina;

2 O usurio seleciona a loja;
3 O sistema exibe os preos promocionais do artigo na loja

Usurio

Sistema
Exibir pgina

Selecionar
Loja
Exibir Preos
Promocionais

76

5.4.1.1.2 Alterar Preo Promocional

-

Declarao de Meta: Editar preos promocionais cadastrados de um artigo numa loja

especificada.
-

Autores: Lucas Lopes Alenquer

Suposies: Deve existir ao menos um preo promocional cadastrado passvel de

alterao.
-

Condies prvias: O cdigo identificador do artigo deve ser conhecido.

Condies posteriores: Atualizao

Questes importantes / Observaes : Nenhuma

1 O usurio digita e envia o preo e a data inicial da promoo;

2 O sistema valida os dados de entrada. Em caso afirmativo, o sistema ir alterar a
promoo e chamar o caso de uso Listar Preos Promocionais. Do contrrio, ir para
atividade 2.1
2.1 - O sistema exibir uma mensagem de erro.

77

Usurio

Sistema

Digitar e enviar preo e

data de incio

Validar dados
de entrada

[Erro]

Exibir mensagem
de Erro ao alterar

[Ok]

Atualizar Preo
Promocional

Listar Preos
Promocionais

5.4.1.1.3 Cancelar Preo Promocional

-

Declarao de Meta: Excluir preos promocionais cadastrados de um artigo numa

loja especificada.
-

Autores: Lucas Lopes Alenquer

Suposies: Deve existir ao menos um preo promocional cadastrado passvel de

excluso.
-

Condies prvias: O cdigo identificador do artigo deve ser conhecido.

Condies posteriores: Atualizao

Questes importantes / Observaes : Nenhuma

1 O usurio solicita o cancelamento;
2 O sistema exibe mensagem do tipo Voc deseja cancelar realmente...?;
3 Caso o usurio confirme, faa a atividade 3.1; do contrrio, faa a atividade 3.2
3.1 O sistema ir excluir o preo promocional.
3.2 - O sistema nada faz
78

Usurio

Sistema

Solicitar
cancelamento
Exibir mensagem de confirmao
de cancelamento

[Ok]

Apagar Preo
Promocional

[No]
Listar Preos
Promocionais

5.4.1.1.4 Cadastrar Preo Promocional

-

Declarao de Meta: Inserir preos promocionais de um artigo numa loja

especificada.
-

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: O cdigo identificador do artigo deve ser conhecido.

Condies posteriores: Atualizao

Questes importantes / Observaes : Nenhuma

1 O usurio digita e envia o preo e a data inicial da promoo;

2 O sistema valida os dados de entrada. Em caso afirmativo, o sistema ir alterar a
promoo e chamar o caso de uso Listar Preos Promocionais. Do contrrio, ir para a
atividade 2.1
2.1 O sistema exibir uma mensagem de erro.
79

Usurio

Sistema

Digitar e enviar preo e

data de incio

Validar dados
de entrada

[Erro]

[Ok]

Inserir Novo Preo

Promocional

Exibir mensagem
de Erro

Listar Preos
Promocionais

5.4.2

Gerncia de emprstimo

<<incl ude>>

Inserir Emprstimo

<<incl ude>>

Usuari o

Inserir Devoluo

Listar Em prstimos

(f rom Actors)

5.4.2.1 Casos de Uso

5.4.2.1.1 Listar Emprstimos

80

Declarao de Meta: listar todos os emprstimos de artigos realizados por um

funcionrio numa loja especificada.

-

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: O cdigo identificador do funcionrio e da loja devem ser

conhecidos.
-

Condies posteriores: Nenhuma

Questes importantes / Observaes : Nenhuma

1 O sistema exibe a pgina;

2 O usurio escolhe a viso que deseja: dos emprstimos pendentes (atividade 2.1) ou do
histrico com todos os emprstimos e devolues(atividade 2.2)
2.1 O sistema exibe lista apenas com os artigos emprestados e ainda no devolvidos;
2.2 O sistema exibe lista com todos os emprstimos e devolues realizados pelo
funcionrio na loja;

81

Usurio

Sistema
Exibir pgina

Selecionar
Viso

[Pendentes]
Exibir Apenas
Pendentes

[Histrico]
Exibir Histrico

82

5.4.2.1.2 Inserir Emprstimos

-

Declarao de Meta: Cadastrar um emprstimo de um artigo realizado por um

funcionrio numa loja especificada.

-

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: O cdigo identificador do funcionrio e da loja devem ser

conhecidos.
-

Condies posteriores: Atualizao

Questes importantes / Observaes : Nenhuma

1 O usurio digita e envia o artigo e a quantidade;

2 O sistema valida os dados de entrada. Em caso afirmativo, o sistema ir inserir o
emprstimo e chamar o caso de uso Listar Emprstimos. Do contrrio, ir para a atividade
2.1;
2.1 O sistema exibir uma mensagem de erro.

Usurio

Sistema

Digitar e enviar Artigo e

Quantidade

Validar dados
de entrada

[Erro]

[Ok]

Exibir mensagem
de Erro

Inserir Novo
Emprstimo

Listar
Emprstimos

83

5.4.2.1.3 Inserir Devoluo

-

Declarao de Meta: Cadastrar uma devoluo de artigo realizada por um funcionrio

numa loja especificada.

-

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: O cdigo identificador do funcionrio e da loja devem ser

conhecidos. Deve existir ao menos um emprstimo do mesmo artigo

-

Condies posteriores: Atualizao

Questes importantes / Observaes : Nenhuma

1 O usurio digita e envia o artigo e a quantidade;

2 O sistema valida os dados de entrada. Em caso afirmativo, o sistema ir inserir a
devoluo e chamar o caso de uso Listar Emprstimos. Do contrrio, ir para a atividade 2.1
2.1 - O sistema exibir uma mensagem de erro.

Usurio

Sistema

Digitar e enviar Artigo e

Quantidade

Validar dados
de entrada

[Erro]

[Ok]

Exibir mensagem
de Erro

Inserir Nova
Devoluo

Listar
Emprstimos

84

5.4.3

Gerncia de Usurios

<<include>>

Cadastrar Usurio
<<include>>

Usuari o

Alterar Usurio

Listar Usurios

(f rom Actors)

5.4.3.1 Casos de Uso

5.4.3.1.1 Listar Usurios
-

Declarao de Meta: listar todos os usurios do sistema que esto cadastrados.

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: Nenhuma

Condies posteriores: Nenhuma

Questes importantes / Observaes : Nenhuma

1 O usurio seleciona a pgina;

2 O sistema exibe a pgina;
3 O usurio define critrios de filtro, tais como nome, login, loja, etc;
4 O sistema exibe os usurios que se encaixam nos critrios especificados

85

Usurio
Selecionar pgina

Sistema
Exibir pgina

Selecionar Critrios de
Filtro: Nome, Login, Loja, etc
Exibir Usurios

86

5.4.3.1.2 Cadastrar Usurios

-

Declarao de Meta: Inserir um novo usurio do sistema.

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: Nenhuma

Condies posteriores: Atualizao

Questes importantes / Observaes : Nenhuma

1 O usurio digita e envia os dados cadastrais do usurio (nome login, senha, lojas, etc);
2 O sistema valida os dados de entrada. Em caso afirmativo, o sistema ir inserir o usurio
e chamar o caso de uso Listar Usurios. Do contrrio, ir para a atividade 2.1
2.1 O sistema exibir uma mensagem de erro.

Usurio

Digitar e enviar dados

do usurio

Sistema

Validar dados
de entrada

[Erro]

[Ok]

Inserir Novo Usurio

Exibir mensagem
de Erro
Listar Usurios

87

5.4.3.1.3 Alterar Usurio

-

Declarao de Meta: Alterar dados de um usurio cadastrado do sistema.

Autores: Lucas Lopes Alenquer

Suposies: Nenhuma

Condies prvias: Deve existir ao menos um usurio cadastrado passvel de

alterao
-

Condies posteriores: Atualizao

Questes importantes / Observaes : Nenhuma

1 O usurio digita e envia os dados do usurio;

2 O sistema valida os dados de entrada. Se estiverem certos, ir atualizar os dados do
usurio (inclusiva senha caso tenha sido digitada) e chamar o caso de uso Listar Usurios;
do contrrio, faa a atividade 2.1;
2.1 O sistema exibir uma mensagem de erro.

88

Usurio

Digitar e enviar dados

do usurio

Sistema

Validar dados
de entrada

[Erro]

[Ok]
Digitou Senha?

Exibir mensagem
de Erro ao alterar

Listar Usurios

5.5

Sim

No

Atualizar Senha

Atualizar
Usurio

Documento de Anlise

Este documento ir apresentar o esboo do diagrama de relacionamentos entre as classes do

negcio envolvidas na iterao do desenvolvimento do sistema Livraria
5.5.1

Diagrama de classes

89

Usurio
CodUsuario : Guid
Login : String
Senha : By te [7]
Nome : String
E-mail : String
Telef one : String

Pri vilgio
0..*

0..*

1..*

1..*

CodPriv ilegio : Guid

Nom e : String

Loja
CodLoja : Guid
Nom e : String

New()
New()
Atualizar()

1
1..*

Funcionrio

Departamento
CodDepart amento : Integer
Nome : String

InserirEmprestimo()
GetSaldo()

<<Feito numa...>>

0..*

0..*

0..*

Emprstimo

0..*

new()
GetQtd()
GetValor()

Preo Promocional

Artigo

Quantidade : Integer
Data : Date

CodArtigo : guid
Nom e : String
Produtor : String
MostrarProm oes()

Preo : Currency
Inicio : Date
Fim : Date

0..*
GetDados()

0..*
Devoluo
Quantidade : Integer
Data : Date
new()

5.5.2

Caminhos de navegao

Este documento visa ilustrar os possveis caminhos que o usurio pode tomar ao navegar para
executar as funcionalidades do sistema descritas durante a iterao do desenvolvimento do
sistema Livraria.

90

Tela de procura
de Artigo
<<link>>

Tela Home

<<link>>

Tela de c adastro de
Preo Prom ocional

<<link>>

Tela de Gerncia
de Emprstimos

<<link>>

<<link>>

Tela de Gernci a
de Usurios

<<link>>

Tela de cadastro
de movi mento

T ela de Cadastro
de Usurio

A seguir sero listados os diagramas de seqncia envolvendo as telas e os objetos de negcio

especificados durante a iterao do desenvolvimento do sistema Livraria. Cada diagrama de
seqncia possui o seu respectivo caso de uso associado.

5.5.3

Diagramas de Seqncia

5.5.3.1 Cadastrar Preo Promocional

91

: Tela de cadastro de
Preo Promocional

: Artigo

: Preo
Promocional

: Usuario do
sistema

ReceberDadosEntrada

InserirPromocao

new

ExibirPromocoes

Seq-Listar
Promoo

5.5.3.2 Cancelar Preo Promocional

92

: Tela de cadastro de
Preo Promocional

: Artigo

: Preo
Promocional

: Usuario do
sistema

CancelarPromocao
MensagemConfirmacao

DeletePromocao

destroy

ExibirPromocoes

Seq-Listar
Promoo

5.5.3.3 Alterar Preo Promocional

93

: Tela de cadastro de
Preo Promocional

: Artigo

: Preo
Promocional

: Usuario do
sistema

ReceberDadosEntrada

EditarPromocao

update

ExibirPromocoes

Seq-Listar
Promoo

94

5.5.3.4 Listar Preos Promocionais

: Tela de cadastro de
Preo Promocional

: Artigo

: Preo
Promocional

: Usuario do
sistema

EscolherLoja
GetPromoes(Guid)

GetDados( )

ExibirPromocoes

95

5.5.3.5 Listar Usurios

: Tela de Gerncia
de Usurios

: Usurio

: Usuari o do
sistema

DadosFiltragem

GetDados

ExibirUsuarios

96

5.5.3.6 Atualizar Usurio

: Tela de Cadastro de
Usurio

: Usurio

: Tela de Gerncia de
Usurios

: Usuario do
sistema

AtualizarUsuario

Update

Seq-ListarUsuarios

97

5.5.3.7 Inserir Usurio

: Tela de Cadastro de
Usurio

: Usurio

: Tela de Gerncia de
Usuri os

: Usuario do
sistema

InserirUsuario

New

Seq-ListarUsuarios

98

5.5.3.8 Listar Emprstimos

: Tela de Gerncia de
Emprstimos
: Usuario do
sistema

: Funcionrio

: Emprstimo

CarregarEmprestimosPendentes
InserirEmprestimo(Guid, Guid, Integer, DateTime, Guid)

GetQtd(Loja)
GetValor( )

Exibir Emprestimos Pendentes

99

5.5.3.9 Listar Movimentos

: Tela de cadastro de
movimento

: Funcionrio

: Emprstimo

: Usuario do
sistema

SelecionaVisao

ListarMovimentos

GetDados

ExibirMovimentos

100

5.5.3.10 Inserir Emprstimo

: Tela de cadastro de
movimento

: Funcionrio

: Emprstimo

: Usuario do
sistema

Inserir Dados do Movi mento

InserirEmprestimo( )

new( )

ExibirMovimentos

101

5.5.3.11 Inserir Devoluo

: Tela de cadastro de
movimento

: Funcionrio

: Emprstimo

: Devoluo

: Usuario do
sistema

Inserir Dados do Movimento

InserirDevolucao( )

new( )

new( )

ExibirMovimentos

102

5.6

Documento de arquitetura

Este documento visa especificar a arquitetura sob a qual ser implementada as

funcionalidades da iterao do desenvolvimento do sistema Livraria.

Casos de uso arquitetonicamente significativos

Por se tratar de um projeto onde o foco estudar a engenharia de software aplicada a

aplicaes Web, nenhum dos casos de uso extrados para demonstrao so considerados
arquitetonicamente significativos.

Arquitetura candidata

A arquitetura candidata a ser utilizada na aplicao o .NET, da Microsoft. A linguagem a ser

utilizada ser o ASP.NET, que habilita a criao e o funcionamento de uma aplicao Web. A
linguagem escolhida para se conjugar ao ASP.NET para a codificao o Visual Basic.NET.
A escolha da arquitetura e da linguagem foi feita considerando a experincia anterior da
equipe com o ambiente Microsoft.
Os outros componentes a serem utilizados sero:

Navegador: Internet Explorer, por se tratar de um browser j existente nas

mquinas do cliente que ir utilizar a aplicao Intranet;

Protocolo de comunicao: HTTP

Pgina dinmica: pginas Web ASP.NET (.aspx)

Servidor de aplicao: o IIS, pela empresa desenvolvedora ser Microsoft

Partner

Servidor de banco de dados: o SQL Server, pela empresa desenvolvedora ser

Microsoft Partner e pelo banco comportar aplicao de tal porte.

103

A aplicao Web .NET define a pgina Web como a responsvel por manipular todos os
eventos do lado do cliente. A pgina MinhaPagina.aspx ser modelada como uma classe
<<server page>> associada a uma classe oculta MinhaPagina.vb, que ir possuir os cdigos
que manipulam os eventos e interagem com os objetos do negcio. Desta forma, o arquivo
MinhaPagina.aspx escrito quase todo em HTML, se preocupando apenas com a criao da
tela para o cliente.
A manipulao dos eventos do lado cliente poderia ser implementada no prprio arquivo
aspx, porm no recomendo esta prtica. No projeto, prefiro associar atravs do esteretipo
<<include>> o arquivo MinhaPagina.aspx a um arquivo Javascript MinhaPagina.js, cabendo
ao aspx fazer apenas as chamadas s funes do script.
A aplicao Web .NET tambm permite que se crie arquivos definidos como controles do
usurio user control. Estes arquivos (com a extenso ascx) so basicamente trechos de
pginas aspx, possuindo seus prprios controles e elementos HTML no cliente, bem como seu
cdigo oculto que manipula seus eventos. Desta forma, o arquivo ascx possui uma interface
com o cliente tanto quanto a pgina aspx. Porm, ele necessita da pgina aspx para ser
utilizado pelo usurio, bastando que no arquivo aspx exista a referncia ao user control,
quantas vezes o desenvolvedor julgar necessrio.
O esquema bsico de modelagem de pginas Web .NET a ser utilizado mostrado a seguir.
Nele, temos os relacionamentos existentes entre a pgina Web WpgHome.aspx com um user
control chamado WctHeader.ascx:

104

<<include>>

f(){
}

WctHeader.ascx.vb

WpgHome.js
<<buil d>>

WpgHome.html

WctHeader.ascx
<<submit>>

Formulri oHome

5.6.1

WpgHome.aspx.vb

WpgHome.aspx

Estratgia de reutilizao

Para usar da melhor forma a reutilizao no .NET, deve-se levar em conta que no pode haver
herana entre os arquivos .ascx e os .js. Porm, haver funes de script no lado do cliente
que sero utilizadas por grande parte das telas e sero, portanto, candidatas a serem agrupadas
em um prprio arquivo Javascript.
A reutilizao dos user controls se dar na medida em que a equipe identifique um trecho
de interface com funes bem definidas que se repetir na tela do usurio com freqncia.
Este trecho de interface ter, obviamente, uma representao HTML prpria e seus objetos de
interface iro disparar eventos tambm. Desta forma, este trecho ser candidato a ser
encapsulado em um arquivo ascx.
J as pginas Web .NET geradas pela ferramenta herdam de uma classe do framework
denominada Page, que j possui encapsulados diversos mtodos que facilitam a troca de
informaes entre o seu formulrio e o servidor. Porm, a pgina aspx no pode
105

simplesmente herdar de uma outra pgina aspx, pois cada elemento inserido na pgina aspx
possui uma representao nica em HTML, e no momento da construo do HTML da tela
as tags dos objetos da classe pgina herdada no sero encontradas.
Para que haja a reutilizao de pginas aspx, a equipe dever criar uma classe intermediria
que herde da classe Page. Esta classe intermediria dever ser herdada por todas as classes
das pginas Web aspx criadas durante o desenvolvimento. As pginas aspx devero conter
apenas seus elementos - de servidor e HTML e seus user controls, sem a presena de tags
<html>, <form>, etc.
A classe intermediria dever apenas conter mtodos, sem representao HTML. Estes
mtodos sero responsveis por construir o documento HTML a partir dos elementos
inseridos na pgina filha, retirando assim uma funo que caberia normalmente a prpria
pgina Web aspx.

A classe da pgina aspx, apesar de parecer acfala durante sua construo, permanecer
realizando a comunicao com os objetos do negcio, como se pode observar na figura
abaixo:

Usuario do
sistema

Interface

Controle

Entidade

Pgina Intermediria

(f rom Actors )

<<communicate>>

Pgina HTML

Pgina Aspx

Objetos de Negcio

Pgina Aspx.vb
<<communicate>>

<<communicate>>

Banco de Dados
Pgina aspx:
Duplo Papel

Imposio de
Projeto

Note a presena da pgina aspx na fronteira entre a interface e o controle do sistema. Isto se
deve ao fato da pgina aspx exercer o duplo papel de agregar os elementos de servidor e
106

HTML e ao mesmo tempo controlar a manipulao de eventos no servidor e dialogar com os

objetos de negcio atravs de sua superclasse aspx.vb.
Por sua vez, a classe aspx.vb tambm foi inserida na fronteira entre a camada de controle e de
entidade, quando na teoria ela deveria apenas se comunicar com os objetos de negcio.
5.6.2

Consideraes Finais

A aplicao Web nos impe alguns limites. E um deles nos faz considerar o trafgo de rede e
uma utilizao de banda eficiente que no prejudique os demais usurios da aplicao. Ao
requerer um objeto de negcio, a pgina aspx.vb ir fazer com que a classe v at a base de
dados e instancie o objeto. Isto dever ocorrer inmeras vezes durante a interao entre
usurio e sistema. At este momento nada de novo.

Dependendo do contexto da pgina Web, porm, o simples fato de instanciar um objeto pode
ser muito custoso. Imagine, por exemplo, uma tela de busca que apresente como resultado os
dados dos artigos da livraria que possuam a letra a no seu ttulo. Uma query bem formulada
ao banco de dados nos dar a resposta em pouco tempo. Em contrapartida, aguardar que o
sistema identifique os artigos retornados e os instancie - um a um - para ento exibi-los, alm
de exigir inmeras conexes ao banco retardar demais o tempo de carregamento da pgina
HTML resultante.
Levando tudo isto em considerao, a equipe dever identificar em quais momentos a pgina
dever conhecer ou informar ao usurio informaes que remetam a um todo (ou conjunto)
e a uma parte (elemento especfico). Provavelmente, as telas que necessitem de muitos
dados como a de resultado de busca sero fundamentalmente de consulta.
Desta maneira, o projeto no se enquadrar completamente no paradigma orientado a objetos
porque:
-

O comportamento dos objetos no estar encapsulado em seu interior, e

sim nas funes e procedures no banco de dados;

107

Os objetos no sero responsveis, exclusivamente, por fornecer seus

dados durante toda a execuo do sistema. Haver classes de suporte que iro fornecer dados
que remetem a um todo.

108

Captulo VI - Etapa Projeto

Neste captulo sero apresentados os modelos de classe e seus relacionamentos com todos os
detalhes.
6.1

Diagramas de Classes - Aperfeioado

Privilgio
CodPriv ilegio : Int eger
Nome : String
1..*
0..*

0..*

1..*

Usurio

Loja
1

Funcionrio

1..*
Departamento

0..*
1

Preo Promocional

0..*

<<Feito numa...>>
0..*

0..*

Artigo

Emprst imo

0..*

Usurio
CodUsuario : Guid
Login : String
Senha : Byte [7]
Nome : String
E-mail : String
Telefone : String
Departamentos : Collection
Lojas : Collection
Privilegios : Collection
Status : StatusUsuario
dr : SqlDataReader
CommandSQLServer : SqlCommand
SelectQuery_spUsuario_Select : String
SelectQuery_spListaDepartamentoUsuario : Stri ng
SelectQuery_spListaPrivilegioUsuario : Stri ng
SelectQuery_spListaLojaUsuario : String
Departamentos_Usuario : Collection
_TBDepartamentos : DataTable
_Privilegi os : Collection
_TBPrivilegios : DataTable
_Lojas : Collection
_TBLojas : DataTable
_IndStatus : Stri ng
Sql : InterfaceSQLServer
Coder : Codificacao
_DataSetUsuario : ClsDataSetUsuario
_AtualizaDataSet : DadosDeUsuario
_Privilegi oUsuario : DadosDePrivilegioUsuario
_DepartamentoLojaUsuari o : DadosDeDepartamentoLojaUsuario
New()
New()
New()
CarregarDadosUsuario()
CarregarPrivilegiosUsuario()
CarregarDepartamentosUsuario()
CarregarLojasUsuario()
PossuiPrivilegio()
PossuiPrivilegio()
InserirNovoUsuario()
AtualizarUsuario()
InserirPrivilegiosUsuario()
AtualizarPrivilegioUsuario()
InserirUsuarioDepartamentoLoj a()
AtualizaUsuarioDepartamentoLoja()
Gravar()
Departamentos()

110

Departamento
CodDepartamento : Integer
Nome : String
Natureza : NaturezaDepartamento
UnidadeCobertura : String
dr : SqlDataReader
_sql : InterfaceSqlServer
SelectQuery_spDepartamento_Select : Stri ng

Loja
CodLoja : Guid
Nome : String
EhMatriz : Boolean
dr : SqlDataReader
_sql : InterfaceSQLServer
SelectQuery_spGetLoja_Select : String

new()
CarregaDadosDepartamento()

New()

Funcionrio
_Nome : String
_telefone : String
_CodFuncionario : Guid
_Numero : String
_dr : SqlDataReader
_CommandSQLServer : SqlCommand
_SelectQuery_spGetDadosCliente : Stri ng
_SelectQuery_spListaEmprestimos : String
_SelectQuery_spListaEmprestimosLOJA : Stri ng
_InsertQuery_spCli enteMovimento_Insert : String
_TBEmprestimos : DataTabl e
_Sql : InterfaceSQLServer
Nome : String
CodFuncionario : Guid
Telefone : String
Numero : String
Emprestimos : Coll ection
SaldoDevedor : Integer
new()
CarregarEmpresti mos()
CarregarDadosFunci onario()
InserirEmprestimo()
InserirDevolucao()

Emprstimo
_Qtd : Integer
_Data : Date
_CodFunci onario : Guid
_CodArtigo : Guid
_CodLoja : Guid
_Saldo : integer
_Devolucoes : Collection
_dr : SqlDataReader
_sql : InterfaceSQLServer
_SelectQueryFnSaldoArti goMovimento : String
Saldo : Integer
new()
GetSaldoEmprestimo()
GetValor()

Artigo
CodArtigo : guid
Nome : String
Produtor : String
MostrarPromoes()
New()

111

Preo Promocional
Preo : Currency
Inicio : Date
Fim : Date
_DeleteQueryspArtigoPrecoVenda_Promocao_Delete : String
_SelectQueryspArtigoPrecoVenda_Promocao_Select : String
_ChangeQueryspArtigoPrecoVenda_Promocao_Change : String
_ComandoSQLGravarDados : SqlCommand
_Sql : InterfaceSQLServer
_dr : SqlDataReader
_Artigo : Artigo
_Loj a : Loja
_DataInicio : DateTime
_DataFim : DateTime
_Valor : Double
Artigo : Arti go
Loja : Loja
Valor : Doubl e
DataInicio : String
DataFim : String
New()
New()
PreparaComandoSQL()
Existe()
GravarNovosDados()
Excluir()

112

6.2

Caminhos de navegao

T ela de procura
de Artigo

Tela de c adastro de
Preo Promocional

Tela de
Confirmao

<<link>>
<<link>>

Tela Home

<<link>>

<<link>>

Tela de Gerncia
de Emprstimos

Tela de Gerncia
de Usuri os

<<link>>

<<link>>

Tela de cadastro
de movimento

Tela de Cadastro
de Usuri o

113

6.3

Pacote Login

6.3.1

Relacionamentos - Tela de Login

Pagina
(f rom Analy sis Model)

WpgLogin.aspx.vb

<<Certifica>>

(f rom Analy sis Model)

Usurio
(f rom Analy sis Model)

WctHeader.ascx.vb
(f rom Analy sis Model)

WpgLogin.aspx <<forward>>

WctHeader.ascx
(f rom Analy sis Model)

(f rom Analy sis Model)

<<link>>

114

CertificaUsuario
(from Analysis Model)

WpgLogin.aspx.vb
(f rom Analy sis Model)

txtUID : TextBox
txtPWD : TextBox
btnOK : Button

<<Certifica>>

DefinirScript()
btnOK_Click()

Command : SqlCommand
Tabela : DataTable
Usuari oExistente : Boolean
CodUsuario : Guid
NomeUsuario : String
New()
Encode()
Decode()

Usurio
(f rom Analy sis Model)

Codificacao
(f rom Analy sis Model)

Encode()
Decode()
New()

6.3.2

Diagramas de Seqncia

115

Login OK
: WpgLogin.aspx.vb

: CertificaUsuario

: Usurio

: WpgHome.aspx.vb

btnOK_Click(Object, EventArgs)

New(String, String)

Usurio Existente

New(Guid)

Redirect

116

Login Falho
: WpgLogin.aspx.vb

: Certifi caUsuario

btnOK_Click(Object, EventArgs)

New(String, String)

Usurio Inexistente / Invlido

AtiveLabel(Label, stri ng)

"Usurio Invlido"

117

6.4
6.4.1

Pacote Usurio
Relacionamentos Tela de Gerncia de Usurios

WpgUsuarios.aspx.vb

DgUsuarios

(f rom Analy sis Model)

(f rom Analy sis Model)

<<Preencher>>

Lista_de_Usuarios
WctOrdenaCol una.ascx

(f rom Analy sis Model)

(from Analysi s Model)

<<link>>

WctOrdenaCol una.ascx.vb

WpgUsuarios.as <<communicate>>
px

CodUsuario=

(from Analysis Model)

1..*

WctOrdenaCol una.ascx
(from Analysi s Model)
<<forward>>
WctHeader.ascx.vb

WpgUsuario.aspx

(f rom Analy sis Model)

WctHeader.ascx

6.4.1.1 Diagrama de Seqncia

118

Listar Usurios
: WpgUsuarios.aspx.vb

: ListagemUsuarios

: WctOrdenaColuna.ascx.vb

CarregaDataGrid(Boolean)

Clear( )

Os dados esto no
atributo Listagem

ReceptorPreparaNovoSort( )

dgUsuarios_ItemDataBound(Object, DataGri dItemEventArgs)

6.4.2

Relacionamentos Tela de Cadastro de Usurio

119

WpgUsuario.aspx.vb
(from Analysis Model)
txtNome : TextBox
txtLogin : TextBox
txtMail : TextBox
txtSenha : TextBox
txtRepitaSenha : TextBox
txtTelefone : TextBox
CheckBoxList_Loja : CheckBoxList
CheckBoxList_Departamento : CheckBoxList
CheckBoxList_Privilegio : CheckBoxList
LabelAviso : Label
chkPrivIrrestrito : CheckBox
chkUsuarioAtivo : CheckBox
lnkSalvar : LinkButton
lnkVoltar : LinkButton
Page_Load()
Salvar()
GeraListaMarcados()
TodosForamMarcados()
NenhumFoiMarcado()
lnkVoltar_Click()
lnkSalvar_Click()
chkPrivIrrestrito_CheckedChanged()
GetchkUsuarioAtivo()
CarregarListagens()
CarregarDadosUsuario()
MarcarLojasDoUsuario()
MarcarDepartamentosDoUsuario()
TentarMarcarPri vilegioIrrestrito()
MarcarPrivilegiosDoUsuario()
NovoUsuarioDi gitouLoginExistente()
NovoUsuarioDi gitouSenhaCorreta()
HouveProblemaAoAlterarSenha()
SenhaFoiDigitada()

<<communicate>>

Usurio

(f rom Analy s is Model)

Os relaciomentos entre
a tela e WctHeader o
mesmo

120

WpgUsuarios.aspx.vb

Usurio

(f rom Analy sis Model)

(f rom Analy sis Model)

<<redirect>>
WpgUsuario.aspx.vb

DadosDeUsuario

DadosDePrivilegioUsuario

(f rom Analy sis Model)

DadosDeDepartamentoLojaUsuario

ListagemPrivilegios

ListagemLojas

(f rom Analy sis Model)

(f rom Analy sis Model)

ListagemDepartamentos
(from Analysis Model)

ListagemLojas
_SelectQuery_VwLoja : String
_SelectQuery_spLi staLojaUsuario : String
_TBVwLoja : DataTable
_Sql : InterfaceSQLServer
Listagem : DataView
New()
New()
Clear()

ListagemDepartamentos
SelectQuery_Departamento : String
_TBDepartamento : DataTable
Sql : InterfaceSQLServer
Listagem : DataView
New()

ListagemPrivilegios
SelectQuery_Privilegio : Stri ng
_TBPrivil egio : DataTable
Sql : InterfaceSQLServer
Listagem : DataView
New()

121

DadosDeDepartamentoLojaUsuario
_CodUsuario : Guid
_DatAdapter_Usu_Dep_Loja : SqlDataAdapter
_DataSetUsuario : ClsDataSetUsuario
_Sql : InterfaceSQLServer
spUsuarioDepartamentoLoja_Select : SqlCommand
spUsuarioDepartamentoLoja_Insert : SqlCommand
spUsuarioDepartamentoLoja_Update : SqlCommand
spUsuarioDepartamentoLoja_Delete : SqlCommand
New()
CarregaTabelaUsuarioDepartamentoLoja()
DefinicaoDeParametros()
AtualizarDadosDepartamentoLojaUsuario()
GravarDadosDepartamentoLoja()
_DatAdapter_Usu_Dep_Loja_RowUpdating()

DadosDeUsuario
_CodUsuario : Guid
_DatAdapter_Usu_Privilegio : Sql DataAdapter
_DataSetUsuari o : ClsDataSetUsuario
_Sql : InterfaceSQLServer
spUsuarioPrivilegio_Select : SqlCommand
spUsuarioPrivilegio_Insert : SqlCommand
spUsuarioPrivilegio_Update : SqlCommand
spUsuarioPrivilegio_Delete : SqlCommand

_CodUsuario : Guid
_DatAdapter_Usuario : SqlDataAdapter
spUsuario_Sel ect : SqlCommand
spUsuario_Insert : SqlCommand
spUsuario_Update : SqlCommand
spUsuario_Del ete : SqlCommand
Coder : Codi ficacao
_Senha As String

New()
CarregaTabelaUsuarioPrivilegio()
DefinicaoDeParametros()
InserirPrivilegios()
AtualizarPrivilegioUsuario()
GravarDadosUsuarioPrivilegio()
_DatAdapter_Usu_Privilegio_RowUpdating()

New()
CarregaT abelaUsuario()
InserirDadosDeNovoUsuario()
Atuali zaDadosDeUsuario()
GravarDadosPessoaisUsuari o()
_DatAdapter_Usuario_RowUpdati ng()

DadosDePrivilegioUsuario

122

6.4.2.1 Diagramas de Seqncia

Inserir Usurio
: WpgUsuario.aspx.vb

: Usurio

: WpgUsuarios.aspx.vb

lnkSalvar_Click(Obj ect, EventArgs)

GeraListaMarcados(CheckBoxList)

InserirNovoUsuario(String, String, String, String, String, Stri ng)

InserirPrivilegiosUsuario(Collection)
InserirUsuarioDepartamentoLoja(Boolean, Bool ean, Collection, Collecti on)

Gravar( )

Redirect

123

Atualizar Usurio
: WpgUsuario.aspx.vb

: Usurio

: WpgUsuarios.aspx.vb

lnkSalvar_Cl ick(Obj ect, EventArgs)

GeraListaMarcados(CheckBoxList)

Atuali zarUsuario(String, String, String, String, Stri ng, String)

AtualizarPrivilegioUsuari o(Boolean, CheckBoxLi st)

AtualizaUsuarioDepartamentoLoja(Boolean, Bool ean, Collection, Col lection)

Gravar( )

Redirect

124

6.5
6.5.1

Pacote Promoo
Relacionamentos Tela de Promoes

125

DgArtigoPromocao
<<Preencher>>

WpgArtigoPromocao.aspx.vb

WpgArtigos.aspx

?CodArtigo=

Artigo

WpgArtigoPromo
cao.aspx

0..*

Preo Promocional

<<link>>

WctHeader.ascx.vb

ListagemArtigos
WctHeader.ascx

126

WctTextBoxData.ascx.vb

WpgArtigoPromocao.aspx.vb

(from Analysi s Model )

(from Analysis Model )

WctTextBoxDouble.ascx.vb
(from Analysis Model )
WpgArtigoPromoc
ao.aspx

Artigo

(f rom Analy sis Model)

<<build>>

(f rom Analy sis Model)

ListagemLojas

Preo Promocional

(f rom Analy sis Model)

(f rom Analy sis Model)

ListagemPrecosPromocionais
(from Analysis Model)

WpgArti goPromo
cao.html
<<incl ude>>

WpgArtigoPromocao.js
<<link>>

imgCancelar_OnClick()

WpgDialogo.aspx

ListagemPrecosPromocionais
_SelectQuery_spListaPrecoVendaPromoArtigo : String
_TBspListaPrecoVendaPromoArtigo : DataTable
_Sql : InterfaceSQLServer
Listagem : DataView
New()
Clear()

ListagemArtigos
_SelectQuery_VwArtigo : String
_TBVwArtigo : DataTabl e
Sql : InterfaceSQLServer
Listagem : DataView
New()
Clear()

127

6.5.2

Diagramas de Seqncia

Listar Promoes
: ListagemPrecosPromocionais

: WpgArtigoPromocao.aspx.vb

cmbLojas_SelectedIndexChanged(Object, EventArgs)

CarregaGrid(String)

New(Usuario, Artigo, Loja)

128

Cadastrar Promoo
: WpgArtigoPromocao.aspx.vb

: Preo
Promocional

lnkAtualizaPromo_Click(Object, EventArgs)

New(String, String, DateTime)

GravarNovosDados(Guid, Guid, DateTime, DateTime, Double)

ShowMessage(Integer)
CarregaGrid(String)

ListarPreos
Promocionais

Alterar Promoo
: WpgArtigoPromocao.aspx.vb

: Preo
Promocional

lnkAtual izaPromo_Click(Object, EventArgs)

New(String, String, DateTime)

GravarNovosDados(Guid, Guid, DateTime, DateTime, Double)

ShowMessage(Integer)
CarregaGrid(String)

ListarPreos
Promocionais

129

Cancelar Promoo
: WpgArtigoProm ocao.html

: WpgArtigoPromocao.js

imgCancelar_OnClick( )

:
WpgDialogo.aspx

: WpgArtigoPromocao.aspx.vb

: Preo
Promocional

Window.open

ret = "S"

Page_Load(Object, EventArgs)
New(String, String, DateTime)
Excluir( )

CarregaGrid(String)

ListarPreos
Promocionais

6.6
6.6.1

Pacote Emprstimo
Relacionamentos Tela de Gerncia de Emprstimos

130

Wpgemprestimos.aspx.vb
Page_Load()
CarregaGridClientesPendentes()
DgEmprestimos_ItemDataBound()
WctOrdenaCol unaReceptor_OrdenacaoPermiti da()
DgEmprestimos_PageIndexChanged()
chkFiltrar_CheckedChanged()
WctButtonLink1_Cl ick()

DgEmprestimos

1..*
WctOrdenaColuna.ascx
WpgEmprestimos.
aspx

WctHeader.ascx.vb

WctHeader.ascx

131

WctOrdenaColuna.ascx.vb
(from Analysis Model)

Wpgemprestimos.aspx.vb

WctButtonLink.ascx.vb

(from Analysis Model)

(f rom Analy sis Model)

ListagemEmprestimosPendentes
(from Analysis Model)

Artigo
(f rom Analy sis Model)

ListagemEmprestimosPendentes
_SelectQuery_spListaClientesEmprestimoPendente : String
_TBspListaClientesEmprestimoPendente : DataTable
_Sql : InterfaceSQLServer
Listagem : DataView
New()
New()
New()
Clear()

WctButtonLink.ascx.vb
lnkButton : LinkButton
Text : String
Wi dth : Unit
Height : Unit
Cli ck()

6.6.1.1 Diagramas de Seqncia

132

Listar Emprstimos
: Wpgemprestimos.aspx.vb

: ListagemEmprestimosPendentes

: WctOrdenaColuna.ascx.vb

CarregaGridClientesPendentes(Boolean)

New(Usuario, Boolean)

ReceptorPreparaNovoSort( )
DgEmprestimos_ItemDataBound(Object, DataGridItemEventArgs)

6.6.2

Relacionamentos Tela de Cadastro de Emprstimo

WctOrdenaCol una.ascx.vb

Funcionrio

(from Analysis Model)

ListagemMovimentosCliente

(f rom Analy sis Model)

(from Analysis Model)

ListagemArtigosClienteDevedor
(from Analysis Model)
WpgEmprestimo.aspx.vb

Artigo
(f rom Analy s is Model)

WctComboSearchTable.ascx.vb
(from Analysis Model)

ListagemLojas
(f rom Analy sis Model)

Loja
(f rom Analy sis Model)

WctTextBoxInteger.ascx.vb
(from Analysi s Model)

133

Emprstimo
WpgEmprestimo.aspx.vb

WpgEmprestimo.
aspx

Emprstimo

_Qtd : Integer
_Data : Date
_CodFuncionario : Guid
_CodArtigo : Guid
_CodLoja : Guid
_Saldo : integer
_Devolucoes : Collecti on
_dr : SqlDataReader
_sql : InterfaceSQLServer
_SelectQueryFnSaldoArti goMovimento : String
Saldo : Integer
new()
GetSaldoEmprestimo()
GetValor()

134

WctComboSearchTable.ascx.vb
txtInstancia : TextBox
cmbInstancia : DropDownList
btnProcurar : Im ageButton
btnEscolher : ImageButton
CodClasse : String
SearchProcedureName : String
NumItensRetornados : Integer
ItemChangedAutoPostBack : Boolean
TableName : String
ColumnValueField : String
ColumnTextFiel d : String
ColumnsToSearch : String
RealizeiBusca : Boolean
PermiteInstanciaNula : Boolean
RecebiCodInstancia : Boolean
CodInstancia : Guid
Modo : TipoModo
AutoPostBack : Boolean
CssClass : String
Wi dth : Unit
Bold : Boolean
TextoBusca : String
CodInstancia_Changed()
Modo_Changed()
Item_Changed()
InverterVisibilidade()
AplicarVisibilidade()
ProcurarInstanci a()
btnEscolher_Click()
Reset()
cmbInstancia_DataBind()
cmbInstancia_SelectedIndexChanged()
txtInstancia_TextChanged()
Ini cieBusca()
EstaProcurando : Boolean()
AddAttributeCombo()
Page_Load()

135

WctTextBoxInteger.ascx.vb

WctTextBoxDouble.ascx.vb

txtValor : TextBox
valValor : CustomValidator
IsValid : Boolean
AutoPostBack : Bool ean
Enabl ed : Bool ean
ReadOnly_ : Boolean
ErrorMessage : String
ClientID_txtVal or : String
MaxLength : Integer

txtValor : TextBox
valValor : CustomVali dator
litTipoVali dacao : Literal
TipoValidacao : ModoValidacao
IsValid : Boolean
ErrorMessage : String
Text : String
Width : Unit
MaxLength : Integer

valValor_ServerVali date()
txtValor_T extChanged()
AddAttribute()

valValor_ServerVali date()
AceitaSomenteVirgula()
AceitaPontoeVirgula()
txtValor_TextChanged()

WctTextBoxData.ascx.vb
txtData : T extBox
val Data : CustomValidator
lblErrorMessage : Label
IsValid : Boolean
ErrorMessage : String
Text : Stri ng
Width : Unit
val Data_ServerValidate()
EhData()

ListagemMovimentosCliente
SelectQuery_spListaMovimentoCli ente : Stri ng
_TBspListaMovimentoCliente : DataTabl e
Sql : InterfaceSQLServer
Listagem : DataView
New()
Clear()

ListagemArtigosClienteDevedor
SelectQuery_spListaMovimentoDevedor : String
_TBspListaMovimentoDevedor : DataT able
Sql : InterfaceSQLServer
Listagem : DataView
New()
Clear()

136

6.6.2.1 Diagramas de Seqncia

Listar Pendentes do Emprstimo

: WpgEmprestimo.aspx.vb

: ListagemArtigosClienteDevedor

lnkListar_Click(Object, EventArgs)

CarregaDados( )

SelecioneGrid( )

CarregaDataGridDevedor( )

New(Funcionario, Loja)

137

Listar Histrico do Emprstimo

: WpgEmprestimo.aspx.vb

: ListagemMovi mentosCliente

lnkLi star_Cl ick(Object, EventArgs)

CarregaDados( )

SelecioneGri d( )

CarregaDataGridMovimentos( )

New(Funcionario, Loja)

Inserir Emprstimo
: WpgEmprestimo.aspx.vb

: Artigo

: Funcionrio

lnkAdicionar_Click(Object, EventArgs)

New(Guid)
InserirEmprestimo(Guid, Guid, Integer, DateTime, Guid)
CarregaDataGridMovimentos( )

ResetPage( )

138

Inserir Devoluo
: WpgEmprestimo.aspx.vb

: Artigo

: Funcionrio

lnkAdici onar_Click(Object, EventArgs)

New(Guid)
InserirDevolucao(Gui d, Guid, Integer, DateTime, Gui d)

CarregaDataGridMovimentos( )

ResetPage( )

6.7

Classes Auxiliares

139

WctOrdenaColuna.ascx.vb
T ipoFiltro : Filtro
T ipoBusca : Busca
BuscaExata : Bool ean
PrepareiLista : Bool ean
EhBuscaExcl udente : Bool ean
Ordenei : Bool ean
EhReceptor : Bool ean
LinkT oolT ip : String
NomeTabelaItensLi sta : String
Gri dContenedor : Stri ng
IDPrioridade : Stri ng
T extoBuscaAbrange : String
Header : String
Comuni cador : String
Sort : Stri ng
CampoSort : Stri ng
DirecaoSort : String
NomeCampo : String
T extoFiltro : Stri ng
T extoBusca : String
SortInicial : String
PrepareSource()
Page_Load()
ZerarParametro()
PreparaComunicacaoReceptorEmissores()
ReceptorPreparaNovoSort()
PodeOrdenar()
OrdenacaoPermiti da()
QtdSortInicial()
QtdEmissor()
ReceptorReturnSortInicialKeySort()
ReceptorReturnDirecaoSortIni ci al KeySort()
ReceptorReturnEmi ssoresKeyNomeCampo()
ReceptorReturnEmi ssoresKeyID()
OrdenarCol una()
Locali zarReceptor()
Bool BotaoSortVisi vel ()
OrdenarCol una_ImageButton()
btnNomeCampo_Cl ick()
ProcurarControle()
NovoFiltro()
SetVisibil idade()
Comuni carEmissorReceptor()
ReceptorAtualizaSortInicial()
SetVisibil idadeT ipoFiltro()
PreparaLi sta()
GetT ableLi sta()
Page_PreRender()
PrepareSource()
ReceptorReset()
ReceptorColetaDadosEmissor()
NovoSort()
cmbNomeCampo_SelectedIndexChanged()
txtCampoFi ltro_TextChanged()

140

Pagina
_Form : HtmlForm
_DOCTYPE : string
_METAINFO : stri ng
_CLOSEDOC : string = </html>
_Title : Html GenericControl
_Body : HtmlGenericControl
_Link : HtmlGenericControl
_Privi legios : Col lection
_Sql : InterfaceSQLServer
_Script : HtmlGenericControl
CodPagina : String
UsuarioAtual : Usurio
PageTitle : String
CSSFile : String
ScriptFile : String
BodyOnKeyDownFunction : String
BodyOnLoadFunction : String
Form : HtmlForm
ConvStringToGUID()
AtiveLabel()
DesativeLabel()
IncluirItemCombo()
PageTitle()
CSSFile()
Form()
OnInit()
AddHTMLDocType()
AddHTMLMetaInfo()
AddHTMLBodyForm()
AddHTMLCloseDoc()
AddHTMLOpenDoc()
BuildPage()
GenerateHtmlForm()
PreRender()
AddControlsFromDerivedPage()
Load()
ConvDataParaBanco()
ConvNumRealParaBanco()
VerificarAcesso()
CarregarPrivilegiosPagina()
FormataShortData()
FormataPreco()
EhVazio()

141

InterfaceSqlServer

WctHeader.ascx.vb

Conexao : SqlConnection
ConnectionStri ng : Stri ng
Comando : SqlCommand
New()
New()
LerSelectBanco()
LerSelectBanco()
ExecutarComandoBanco()
ExecutarComandoBanco()
LerSQLCommand()
ConvDataParaBanco()
ConvNumRealParaBanco()
ConvStringToGUID()

lblTitulo : Label
lnkLogout : LinkButton
lnkHome : LinkButton
lblUID : Label
Titulo : String
Page_Load()
lnkTravessa_Click()
lnkLogout_Click()
Page_PreRender()
lnkHome_Click()
HaUsuarioLogado : Boolean()

WpgArtigos.aspx.vb

DgArtigos
<<Preencher>>

ListagemArtigos

WctOrdenaCol una.ascx

<<link>>

WpgArtigos.aspx

<<communicate>>

CodArtigo=

WctOrdenaCol una.ascx.vb
1..*

WctOrdenaColuna.ascx

<<forward>>
WpgArtigoPromo
cao.aspx

WctHeader.ascx.vb

WctHeader.ascx

142

6.8

Diagrama de Desdobramento

O diagrama de desdobramento evidencia que o Sistema Livraria funciona como uma

aplicao Intranet apenas em teoria, uma vez que todos os clientes se conectam ao servidor
WWW atravs da Internet. O acesso restrito pela existncia de senha.

Servidor
WWW

<<internet>>

Cliente_Livraria 1

<<internet>>

Servidor Banco
de Dados

<<internet>>

<<internet>>

Cliente_Livraria n

Cliente_Livraria 2

143

144

Resultados

Aplicando uma iterao sobre o processo de desenvolvimento do Sistema Livraria obteve-se

o acrscimo de funcionalidades ao sistema j em produo. So elas (resumidamente):
1 Cadastro e edio de usurios do sistema;
2 - Cadastro e edio de promoes de artigos cadastrados no sistema;
3 - Cadastro e gerenciamento de emprstimos de artigos concedidos a funcionrios da livraria
Ao longo do processo de desenvolvimento, foi observada a necessidade de realizar algumas
adaptaes ao ambiente de desenvolvimento, principalmente ao se constatar que alguns
conceitos da orientao a objetos ainda no eram atendidos pela verso da linguagem
utilizada. Porm, a implementao no inviabilizou um dos maiores objetivos da iterao que
era o de iniciar a construo de uma classe base para todas as telas do sistema, unificando
procedimentos e tornando mais fcil sua manuteno futura.
De modo geral, o resultado final correspondeu s expectativas geradas no incio da iterao,
sendo possvel vislumbrar futuras aes que possam dar continuidade e incrementar o
processo como um todo, como a incorporao de todos os conceitos da orientao a objetos
numa futura verso do ambiente de desenvolvimento (por exemplo a sobrecarga de
operadores) e a expanso das classes desenvolvidas para atender a novos requisitos sem
afetar os j desenvolvidos.

Concluso

Durante todo o estudo sobre o processo de desenvolvimento de uma aplicao Web e o

desenvolvimento de uma iterao sobre um projeto existente sob o paradigma orientado a
objetos, foi observado na prtica todas as dificuldades que um projeto real implica e algumas
concluses importantes foram extradas.
A primeira delas foi que o processo iterativo o que melhor se adapta s condies reais de
desenvolvimento de um sistema, que se inicia com o levantamento de requisitos e que ao
longo do tempo at determinado ponto - sofre todo tipo de alteraes.
Por causa destas modificaes a iterao desenvolvida ao longo do projeto se mostrou
bastante satisfatria, sendo capaz de evoluir sem nenhum nus ao restante do sistema j
implementado, e isto se deve muito ao isolamento que as classes e procedimentos conferem
modelagem.
O resultado mais concreto pode ser representado pelo surgimento de uma maior disciplina ao
se criar futuras telas para o sistema e a implementao da classe base Pagina, que permitir
um desenvolvimento mais acelerado das telas em futuras iteraes.
Tambm foi observado - forado pelas circunstncias e por imposies do projeto - que nem
sempre seguir risca o paradigma orientado a objetos resulta na melhor soluo para a
implementao do sistema. No caso especfico do sistema Livraria, trabalhar com grandes
quantidades de dados e com o servidor de aplicao tendo que acessar via Internet a base de
dados implica em algumas restries de acesso base de dados e uso de banda, que devem ser
consideradas.
A soluo implementada se baseou na utilizao de classes auxiliares responsveis
exclusivamente por uma grande lista de dados cujo estado no altera o estado do sistema. Isto
evitou que se instanciasse um objeto para cada linha retornada pelo banco de dados, abrindo

inmeros processos quando apenas uma nica query nos fornece a mesma resposta. Quando
o contexto de utilizao do sistema oferece a mudana de seu estado, as instncias das classes
surgem normalmente. Assim foram geradas classes como Artigo, Funcionrio, etc.

Alterando outro conceito do paradigma orientado a objetos, optou-se por realizar um

esvaziamento das classes, representada na transferncia da responsabilidade de alterar o
estado do sistema para os procedimentos e funes do banco de dados, cabendo aos mtodos
das classes apenas invoc-los adequadamente.
Esta deciso foi correta por realizar um isolamento entre o mundo conceitual (representado
pelas classes) e o mundo da informao (representado pelas funes e stored procedures em
SQL), permanecendo as assinaturas previamente acordadas como o elo de ligao. Desta
forma, a equipe de desenvolvimento de uma aplicao Web pode ser composta por pessoas
especialistas em banco de dados, mas no necessariamente especialistas em Web. Caberia a
elas, ento, desenvolver as mais eficientes funes e procedimentos que iro instanciar os
objetos da modelagem e garantir a segurana das informaes. Assim, os desenvolvedores
Web podem se preocupar com a melhor utilizao dos mtodos criados durante a realizao
dos casos de uso do sistema.

Fica aprendida a lio que o desenvolvimento de sistemas Web com objetos exige um esprito
mais conciliador com a viso estruturada, cabendo equipe perceber em qual momento esta
fronteira deve ser enfraquecida. Desta forma, um sistema Web orientado a objetos eficiente e
leve na execuo, desenvolvido com organizao e disciplina tem grandes chances de ser
conduzido com sucesso.

148

Bibliografia

1- Conallen, Jim - Desenvolvendo aplicaes Web com UML, Rio de Janeiro, Campus,
2003, 476p;
2- Fowler, Martin - UML Essencial Um breve guia para linguagem padro de
modelagem de objetos, Rio de Janeiro, Campus, 2003, 192p;
3- Pressman, Roger Engenharia de Software, So Paulo, Makron Books, 1995, 1056;
4- Martin, James - Princpios de Anlises e Projetos Baseados em Objetos, Rio de
Janeiro, Campus, 1994, 512p.