Tcc Mara Santos

UNIVERSIDADE ESTADUAL DE MONTES CLAROS – UNIMONTES

Centro de Ciências Exatas e Tecnológicas – CCET

Departamento de Ciências da Computação – DCC

Curso de Sistemas de Informação

Maíra Gonçalves Santos

MODELAGEM DE UM SISTEMA DE CARDÁPIO ELETRÔNICO

Montes Claros - MG

Junho / 2011



Montes Claros - MG

Junho / 2011

Monografia apresentada ao curso de

Sistemas de Informação da

Universidade Estadual de Montes

Claros como exigência para

obtenção do grau de bacharel em

Sistemas de Informação.

Orientadora: Profª. Esp. SÔNIA

BEATRIZ DE OLIVEIRA E SILVA

MAIA.

M

o

n

o

g

r

a

f

i

a

a

p

r

e

s

e

n

t

a

d

a

a

o

c



Orientadora: Profª. Esp. SÔNIA BEATRIZ DE OLIVEIRA E SILVA MAIA

Membros:

________________________________

Professora Angélica de Souza Coimbra Franco

________________________________

Professor Guilherme Barbosa Vilela

Montes Claros - MG

Junho / 2011

Monografia apresentada ao curso de

Sistemas de Informação da

Universidade Estadual de Montes

Claros como exigência para

obtenção do grau de bacharel em

Sistemas de Informação.

Orientadora: Profª. Esp. SÔNIA

BEATRIZ DE OLIVEIRA E SILVA

MAIA.

M

o

n

o

g

r

a

f

i

a

a

p

r

e

s

e

n

t

a

d

a

a

o

c

u

r

s

o

À mamãe, meu maior

exemplo de garra e amor.

AGRADECIMENTOS

Agradeço a Deus pelas tantas graças e por ter me abençoado com garra, persistência e

determinação; a mamãe pelo amor, incentivo e apoio; ao meu namorado Gabriel, pelo

companheirismo, auxílios e amor; aos meus familiares e amigos, pela compreensão; a todos

os mestres, em especial a minha orientadora, professora Sônia Beatriz de Oliveira e Silva

Maia, pelos conhecimentos compartilhados e orientações; aos colegas, em especial a Carlos

Gilmar, pela colaboração; agradeço a todos aqueles que contribuíram para a realização deste

trabalho.

O sucesso nasce do querer, da determinação e da

persistência em se chegar a um objetivo. Mesmo não

atingindo o alvo, quem busca e vence obstáculos, no

mínimo fará coisas admiráveis. (José de Alencar)

RESUMO

O presente trabalho tem por objetivo realizar a modelagem de um sistema de cardápio

eletrônico, o E-Menu, que permita o gerenciamento dos pedidos e informatização dos

cardápios em restaurantes, proporcionando modernidade e agilidade aos estabelecimentos.

Para o desenvolvimento desse projeto foram seguidos os passos da metodologia PRAXIS com

o uso da ferramenta case ASTAH para construção dos diagramas do software. Os resultados

obtidos nesse trabalho foram satisfatórios, uma vez que foi possível visualizar através da

documentação gerada os principais diagramas da UML para este projeto.

Palavras-chave: Sistemas, UML, PRAXIS, Cardápios Eletrônicos, CASE.

ABSTRACT

This present paper has an objective to make a modeling of an electronic menu system, the E-

Menu, that allows the management of demands and computerization of restaurant's menus,

providing modernity and agility to establishments. For the development of this project were

followed in the footsteps of the methodology PRAXIS using the ASTAH case tool for

construction of diagrams of the software. The obtained results in this paper were satisfactory,

since it was possible to see through the generated documentation the main UML diagrams for

this project.

Keywords: Systems, UML, PRAXIS, Menus Electronics, CASE.

LISTA DE FIGURAS

Figura 1: Tipos de sistemas de informação em relação aos níveis organizações. .................... 21

Figura 2: Sistema de Informática e suas partes. ....................................................................... 24

Figura 3: Especificação formal no processo de software ......................................................... 25

Figura 4: Os cinco passos do ciclo de vida clássico. ................................................................ 28

Figura 5: Modelo em espiral ..................................................................................................... 30

Figura 6: Fases do Praxis. ......................................................................................................... 31

Figura 7: Exemplo de relacionamento de herança.................................................................... 37

Figura 8: Exemplo do diagrama de caso de uso. ...................................................................... 40

Figura 9: Exemplo de Atores. ................................................................................................... 40

Figura 10: Representação do Caso de Uso ............................................................................... 41

Figura 11: Exemplo Diagrama de Classe ................................................................................. 42

Figura 12: Exemplo de um Diagrama de Estados. ................................................................... 43

Figura 13: Diagrama de Contexto do E-Menu. ........................................................................ 50

Figura 14: Interface “E-Menu – Visualizar Cardápio”. ............................................................ 54

Figura 15: Diagrama de Estados “Visualizar Cardápio”. ......................................................... 55

Figura 16: Interface “E-Menu – Fazer Pedido”. ....................................................................... 57

Figura 17: Diagrama de Estados “Fazer Pedido”. .................................................................... 58

Figura 18: Interface “E-Menu – Visualizar Conta”. ................................................................. 60

Figura 19: Diagramas de Estados “Visualizar Conta”.............................................................. 60

Figura 20: Interface “E-Menu – Selecionar Forma de Pagamento”. ........................................ 62

Figura 21: Diagrama de Estados “Selecionar Forma de Pagamento”. ..................................... 63

Figura 22: Diagrama de Estados “Solicitar Auxílio” ............................................................... 65

Figura 23: Interface “E-Menu – Efetuar Login”. ...................................................................... 66

Figura 24: Diagrama de Estados “Efetuar Login”. ................................................................... 67

Figura 25: Interface “E-Menu – Abrir Mesa”; ......................................................................... 69

Figura 26: Diagrama de Estados “Abrir Mesa”. ....................................................................... 69

Figura 27: Interface “E-Menu – Gerenciar Produtos”. ............................................................. 71

Figura 28: Interface “E-Menu – Alterar Produto”. ................................................................... 72

Figura 29: Diagrama de Estados “Gerenciar Produtos”. .......................................................... 72

Figura 30: Interface “E-Menu – Gerenciar Mesas”. ................................................................. 75

Figura 31: Diagrama de Estados “Gerenciar Mesas”. .............................................................. 76

Figura 32: Interface “E-Menu – Gerenciar Pedidos”. .............................................................. 78

Figura 33: Diagrama de Estados “Fazer Pedido” ..................................................................... 79

Figura 34: Interface “E-Menu – Gerenciar Auxílios”. ............................................................. 81

Figura 35: Interface “E-Menu – Excluir Auxílios”. ................................................................. 81

Figura 36: Diagrama de Estados “Gerenciar Auxílios”. .......................................................... 82

Figura 37: Interface “E-Menu – Gerenciar tipos de Produtos”. ............................................... 84

Figura 38: Diagrama de Estados “Gerenciar Tipos de Produtos”. ........................................... 84

Figura 39: Diagrama de Estados “Gerenciar Contas”. ............................................................. 87

Figura 40: Interface “E-Menu – Gerenciar Usuários”. ............................................................. 89

Figura 41: Interface “E-Menu – Novo usuário”. ...................................................................... 89

Figura 42: Diagrama de Estados “Gerenciar Usuários”. .......................................................... 90

Figura 43: Diagrama de Estados “Emitir Relatório”. ............................................................... 92

Figura 44: Interface “E-Menu – Gerenciar Grupos”; ............................................................... 94

Figura 45: Diagrama de Estados “Gerenciar Grupos”.............................................................. 95

Figura 46: Diagrama de classes do “E-Menu”. ........................................................................ 97

LISTA DE QUADROS

Quadro 01 – Os reais benefícios do produto ............................................................................ 47

Quadro 02 – Usuários e Sistemas Externos .............................................................................. 48

Quadro 03 – Características dos usuários ................................................................................. 48

Quadro 04 – Interfaces com os usuários ................................................................................... 51

Quadro 05 – Fluxo do Caso de Uso “Visualizar Cardápio” ..................................................... 53

Quadro 06 – Comandos da Interface “E-Menu – Visualizar Cardápio” .................................. 55

Quadro 07 – Fluxo do Caso de Uso “Fazer Pedido”. ............................................................... 56

Quadro 08 – Campos da Interface “E-Menu – Fazer Pedido” ................................................. 58

Quadro 09 – Comandos da Interface “Fazer Pedido”............................................................... 59

Quadro 10 – Fluxo do Caso de Uso “Visualizar Conta” .......................................................... 59

Quadro 11 – Comandos da Interface “E-Menu – Visualizar Conta”. ...................................... 61

Quadro 12 – Fluxo do Caso de Uso “Selecionar Forma de Pagamento” ................................. 61

Quadro 13 – Campos da Interface “E-Menu – Selecionar Forma de Pagamento”................... 63

Quadro 14 – Comandos da Interface “E-Menu – Selecionar Forma de Pagamento”. ............. 64

Quadro 15 – Fluxo do Caso de Uso “Solicitar Auxílio” .......................................................... 64

Quadro 16 – Comandos da Interface “Solicitar Auxílio”. ........................................................ 65

Quadro 17 – Fluxo do caso de uso “Efetuar Login”................................................................. 66

Quadro 18 – Campos da Interface “E-Menu – Efetuar Login”. ............................................... 67

Quadro 19 – Comandos da Interface “Efetuar Login”. ............................................................ 68

Quadro 20 – Fluxo do caso de uso “Abrir Mesa”..................................................................... 68

Quadro 21 – Campos da Interface “E-Menu – Abrir Mesa”. ................................................... 70

Quadro 22 – Comandos da Interface “E-Menu – Abrir Mesa” ................................................ 70

Quadro 23 – Fluxo do Caso de Uso "Gerenciar Produtos" ...................................................... 70

Quadro 24 – Campos da Interface “E-Menu – Gerenciar Produtos” ....................................... 73

Quadro 25 – Comandos da Interface “Gerenciar Produtos”..................................................... 73

Quadro 26 – Fluxo do caso de uso “Gerenciar Mesas”. ........................................................... 74

Quadro 27 – Campos da Interface “E-Menu – Gerenciar Mesas”. .......................................... 76

Quadro 28 – Comandos da Interface “E-Menu – Gerenciar Mesas”. ...................................... 77

Quadro 29 – Fluxo do caso de uso “Gerenciar Pedidos”. ........................................................ 77

Quadro 30 – Comandos da Interface “E-Menu – Gerenciar Pedidos”. .................................... 79

Quadro 31 – Fluxo do Caso de Uso “Gerenciar Auxílios”....................................................... 80

Quadro 32 – Comandos da Interface “E-Menu – Gerenciar Auxílios”. ................................... 82

Quadro 33 – Fluxo do caso de uso “Gerenciar Tipos de Produtos”. ........................................ 83

Quadro 34 – Campos da Interface “E-Menu – Gerenciar Tipos de Produtos”. ........................ 85

Quadro 35 – Comandos da Interface “E-Menu – Gerenciar Tipos de Produtos”..................... 85

Quadro 36 – Fluxo do caso de uso “Gerenciar Contas” ........................................................... 86

Quadro 37 – Comandos da Interface “E-Menu – Gerenciar Contas”....................................... 87

Quadro 38 – Fluxo do Caso de Uso “Gerenciar Usuários” ...................................................... 88

Quadro 39 – Campos da Interface “E-Menu – Gerenciar Usuários” ...................................... 90

Quadro 40 – Comandos da Interface “Gerenciar Usuários”..................................................... 91

Quadro 41 – Fluxo do Caso de Uso “Emitir Relatório” ........................................................... 91

Quadro 42 – Comandos da Interface “Emitir Relatório” ......................................................... 93

Quadro 43 – Fluxo do Caso de Uso “Gerenciar Grupos”......................................................... 93

Quadro 44 – Campos da Interface “E-Menu – Gerenciar Grupos” .......................................... 95

Quadro 45 – Comandos da Interface “Gerenciar Grupos” ....................................................... 96

Quadro 46 – Classes Persistentes ............................................................................................. 98

LISTA DE SIGLAS

CASE Computer-Aided Software Engineering

EIS Executive Information Systems

IEEE Institute of Electrical and Electronics Engineer

OMG Object Management Group

PRAXIS Processo para Aplicativos Extensíveis Interativos

SAD Sistemas de Apoio à Decisão

SIE Sistemas de Informação Executiva

SIG Sistemas de Informações Gerenciais

SIO Sistemas de Informação Operacionais

SPT Sistemas de Processamento de Transações

UML Unified Modeling Language

SUMÁRIO

1 INTRODUÇÃO ..................................................................................................................... 16

2 FUNDAMENTAÇÃO TEÓRICA ........................................................................................ 19

2.1 Sistemas de Informação .................................................................................................. 19

2.1.1 Tipos de Sistemas de Informação ............................................................................ 21

2.1.1.1 Sistemas de Processamento de Transações (SPT) ............................................ 21

2.1.1.2 Sistemas de Informação Gerenciais (SIG)........................................................ 22

2.1.1.3 Sistemas de Apoio à Decisão (SAD) ................................................................ 22

2.1.1.4 Sistemas de Informação Executiva (SIE) ......................................................... 23

2.2 Engenharia de Software .................................................................................................. 23

2.2.1 Princípios da Engenharia de Software ..................................................................... 25

2.2.1.1 Formalidade ...................................................................................................... 25

2.2.1.2 Abstração .......................................................................................................... 26

2.2.1.3 Decomposição .................................................................................................. 26

2.2.1.4 Generalização ................................................................................................... 27

2.2.1.5 Flexibilização ................................................................................................... 27

2.2.2 Paradigmas de Engenharia de Software................................................................... 28

2.2.2.1 Ciclo de Vida Clássico ..................................................................................... 28

2.2.2.2 Paradigma Evolutivo ........................................................................................ 29

2.2.2.3 Paradigma Espiral ............................................................................................. 29

2.2.3 Processo para Aplicativos Extensíveis Interativos (PRAXIS) ................................ 30

2.3 Processo de Desenvolvimento de Software .................................................................... 31

2.3.1 Atividades Típicas de um Processo de Desenvolvimento ....................................... 32

2.3.1.1 Levantamento de Requisitos ............................................................................. 32

2.3.1.2 Análise de Requisitos ....................................................................................... 32

2.3.1.3 Projeto ............................................................................................................... 33

2.3.1.4 Implementação.................................................................................................. 33

2.3.1.5 Teste ................................................................................................................. 34

2.3.1.6 Implantação ...................................................................................................... 34

2.4 Programação Orientada a Objetos .................................................................................. 35

2.4.1 Visão Geral .............................................................................................................. 35

2.4.2 Conceitos da Orientação a Objetos .......................................................................... 35

2.4.2.1 Objetos .............................................................................................................. 35

2.4.2.2 Classes .............................................................................................................. 36

2.4.2.3 Herança ............................................................................................................. 36

2.4.2.4 Polimorfismo .................................................................................................... 37

2.5 Unified Modeling Language (UML) .............................................................................. 38

2.5.1 Diagrama de Caso de Uso ....................................................................................... 39

2.5.2 Diagrama de Classe ................................................................................................. 41

2.5.3 Diagrama de Estados ............................................................................................... 42

2.6 Ferramentas Utilizadas ................................................................................................... 43

2.6.1 Ferramentas CASE (Computer Aided Software Engineering) ................................ 44

2.6.1.1 Astah Community .............................................................................................. 44

2.6.2 Visual Basic ............................................................................................................. 45

3 TRABALHO DESENVOLVIDO ......................................................................................... 46

3.1 Escopo do Produto .......................................................................................................... 46

3.1.1 Nome do Sistema e Componentes ........................................................................... 46

3.1.2 Missão do Produto ................................................................................................... 46

3.1.3 Limites do Produto .................................................................................................. 47

3.1.4 Benefícios do Produto ............................................................................................. 47

3.2 Perspectivas do Produto ................................................................................................. 48

3.2.1 Usuários e Sistemas Externos .................................................................................. 48

3.2.1.1 Descrição .......................................................................................................... 48

3.3 Diagrama de Contexto do E-Menu ................................................................................. 49

3.3.1 Interfaces de Usuários ............................................................................................. 51

3.3.1.1 Caso de Uso Visualizar Cardápio ..................................................................... 53

3.3.1.2 Caso de Uso Fazer Pedido ................................................................................ 56

3.3.1.3 Caso de Uso Visualizar Conta .......................................................................... 59

3.3.1.4 Caso de Uso Selecionar Forma de Pagamento ................................................. 61

3.3.1.5 Caso de Uso Solicitar Auxílio .......................................................................... 64

3.3.1.6 Caso de Uso Efetuar Login ............................................................................... 66

3.3.1.7 Caso de Uso Abrir Mesa ................................................................................... 68

3.3.1.8 Caso de Uso Gerenciar Produtos ...................................................................... 70

3.3.1.9 Caso de Uso Gerenciar Mesas .......................................................................... 74

3.3.1.10 Caso de Uso Gerenciar Pedidos...................................................................... 77

3.3.1.11 Caso de Uso Gerenciar Auxílios .................................................................... 80

3.3.1.12 Caso de Uso Gerenciar Tipos de Produtos ..................................................... 83

3.3.1.13 Caso de Uso Gerenciar Contas ....................................................................... 86

3.3.1.14 Caso de Uso Gerenciar Usuários .................................................................... 88

3.3.1.15 Caso de Uso Emitir Relatório ......................................................................... 91

3.3.1.16 Caso de Uso Gerenciar Grupos ...................................................................... 93

3.4 Diagrama de Classes Persistentes ................................................................................... 97

3.4.1 Classes Persistentes ................................................................................................. 98

4 DISCUSSÃO DOS RESULTADOS ..................................................................................... 99

5 CONSIDERAÇÕES FINAIS .............................................................................................. 100

REFERÊNCIAS ..................................................................................................................... 102

16

1 INTRODUÇÃO

A informática está presente em todos os segmentos da sociedade, seja em nossas

residências, locais de trabalho ou de lazer. Ficar atento à evolução da tecnologia se torna

fundamental para sobrevivência das empresas. Nesse contexto, estabelecimentos como

restaurantes, que ainda utilizam cardápios impressos e administram os pedidos dos clientes

através de blocos de anotações, precisam ser inseridos nas inovações tecnológicas buscando o

aperfeiçoamento dos seus serviços e modernização do ambiente.

Ter um restaurante informatizado depende de vários fatores, tais como

econômicos e culturais de cada estabelecimento. No entanto, nos dias atuais, com tantos

avanços tecnológicos, qualquer estabelecimento que deseja espaço no futuro deve equipar-se

com instrumentos adequados e eficientes.

O presente trabalho tem como objetivo geral realizar a modelagem de um sistema

de cardápio eletrônico, o E-Menu, onde o cliente poderá visualizar o cardápio do

estabelecimento, realizar pedidos e encerrar sua conta sem depender da presença do garçom,

podendo utilizar aparelhos como os tablets 1 para realizar essas funcionalidades. Para atender

ao objetivo geral, será necessário atender primeiramente aos seguintes objetivos específicos:

criar um módulo para visualização de cardápios, no qual serão apresentados os

produtos do estabelecimento e seus respectivos valores;

criar um módulo para realização de pedidos, onde será possível a escolha dos itens e

suas quantidades;

criar um módulo para encerramento de conta, no qual o cliente solicitará o fechamento

dos seus pedidos;

criar um módulo para gerenciamento de produtos, onde serão cadastrados os produtos

comercializados no estabelecimento;

criar um módulo para gerenciamento de pedidos, o qual permitirá a administração das

solicitações realizadas pelos clientes;

criar um módulo para gerenciamento de contas, permitindo a administração do

estabelecimento controlar o fechamento e abertura de mesas no sistema;

criar um módulo para emissão de relatórios.

1 Segundo Santos, os tablets são computadores portáteis, em formato de prancheta, que são acionados através de

cliques de uma caneta especial - ou touchscreens.

17

Espera-se, que ao final do presente trabalho, depois de atingido os objetivos geral

e específicos seja investigado e solucionado o seguinte problema: através da modelagem de

um sistema de cardápio eletrônico é possível visualizar seus benefícios para os restaurantes?

A cidade Montes Claros tem crescido e se desenvolvido bastante nos últimos

anos, aumentando as opções de lazer e surgindo novos restaurantes na cidade, os quais devem

procurar novidades e melhorias para atrair clientes.

A importância do presente trabalho se justifica na necessidade de modernização e

de melhorias nesses setores, vez que o sistema de cardápio eletrônico representa uma

inovação tecnológica para o norte de Minas Gerais.

O sistema de cardápio eletrônico oferece diversos benefícios como redução no

custo de mão de obra, já que o cardápio digital permite o auto-atendimento, não sendo

necessário o mesmo número de garçons que antes era preciso para o cardápio impresso. Além

disso, os cardápios eletrônicos modernizam o ambiente e atrai clientes de várias idades, pois

se trata de uma tecnologia recente, interativa, que aguça a curiosidade em utilizá-la. Agilidade

e praticidade para procedimentos básicos, como realização de pedidos e encerramento de

contas, são outras vantagens do sistema de cardápio eletrônico. Eles proporcionam maior

facilidade na alteração de produtos e na inclusão de novos itens no cardápio, uma vez que não

será necessário reimprimi-los. Além disso, o sistema permitirá alterações de leiautes e de

funcionalidades, de acordo com o estilo e necessidade de cada estabelecimento, possibilitando

a personalização do cardápio. Outra importante vantagem dos sistemas de cardápios

eletrônicos é a melhoria no atendimento, pois os funcionários terão mais disponibilidade para

recepcionar os clientes, realizar entrega de pedidos e atender a solicitações de auxílios.

Para se alcançar os objetivos do presente trabalho, foi utilizada a seguinte

metodologia: levantamento de requisitos do sistema proposto através de estudos; análise dos

dados obtidos para posterior escolha do processo de desenvolvimento de software adequado,

elaboração dos requisitos, análise e desenho do sistema, seguindo os passos do Processo para

Aplicativos Extensíveis Interativos – PRAXIS, e construção de alguns dos diagramas da

Unified Modeling Language - UML utilizando a ferramenta Astah Community.

Este trabalho está dividido em 6 capítulos cada um deles abordando assuntos de

conteúdo específicos sobre o tema proposto. O capítulo 2 refere-se à fundamentação teórica

do trabalho, abordando conceitos e descrevendo as ferramentas necessárias para modelagem

do sistema. O capítulo 3, por sua vez, aborda questões sobre o trabalho desenvolvido e sobre

os métodos utilizados para a realização do trabalho. O capítulo 4 apresenta os resultados

18

obtidos com o trabalho desenvolvido. O capítulo 5 contém as considerações finais sobre o

trabalho. E, por fim, são listadas as referências bibliográficas utilizadas para fundamentação

do trabalho.

19

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem por objetivo apresentar o embasamento teórico de todo o

trabalho, explorando os fundamentos, conceitos e técnicas que foram necessários ser

estudados através de um vasto acervo bibliográfico para desenvolvimento do trabalho.

2.1 Sistemas de Informação

A informação é um dos bens mais preciosos de uma organização, através dela é

possível tomar as melhores decisões para alcançar as metas de uma empresa. Padoveze (2000,

p. 43) conceitua informação como: “dado que foi processado e armazenado de forma

compreensível para seu receptor e que apresenta valor real percebido para suas decisões

correntes ou prospectivas”.

Segundo Meireles (2001, p.24), todas as organizações possuem uma cultura da

informação definida como: “o conjunto de valores, atitudes e comportamentos que

influenciam na forma como as pessoas, dentro da organização, avaliam, aprendem, recolhem,

organizam, processam, comunicam e utilizam a informação [...]”.

Laudon & Laudon (2007, p. 6) esclarece a importância das tecnologias e dos sistemas de

informações:

As empresas estão sempre tentando melhorar a eficiência de suas operações a fim de

conseguir maior lucratividade. Das ferramentas de que os administradores dispõem,

as tecnologias e os sistemas de informação estão entre as mais importantes para

atingir altos níveis de eficiência e produtividade nas operações, especialmente

quando combinadas com mudanças no comportamento da administração e nas

práticas de negócio.

A informação deve ser bem administrada para proporcionar benefícios para a

empresa. Meireles (2001, p.17), explica como isso deve ser feito:

20

[...] para que a sobrevivência da empresa seja assegurada, é necessário um grande

conjunto de causas, (contramedidas ou metas de sobrevivência) e, entre estas, está a

necessidade de informação ótima: informação certa, no tempo, no lugar e na forma

desejada. Isto implica decidir: o que deve ser informado, ou seja, a síntese dos dados

originais; por que se deve proceder à informação; quem informa ou deve ser

informado; como deve ser informado, isto é: a forma do relatório; e quando o

usuário deve ser informado: a especificação temporal a partir da qual a informação

deve estar disponível ou entregue.

Com a necessidade cada vez maior de uma melhor administração das informações

e com os avanços tecnológicos surgiram os sistemas de informação, que têm como principal

elemento a informação. Seus objetivos consistem em armazenar, tratar e fornecer informações

visando o apoio das funções e processos de uma organização.

Para Silva & Videira (2001, p.37), “um sistema de informação é um conjunto

integrado de recursos (humanos e tecnológicos) cujo objetivo é satisfazer adequadamente a

totalidade das necessidades de informação de uma organização e os respectivos processos de

negócio.”.

Um sistema de informação deve estar presentes nas organizações, como afirma

O’Neill & Nunes (2000, p.1),:

Um elemento intrínseco a qualquer organização é o seu sistema de informação,

constituído por pessoas, dados, procedimentos e equipamentos. O desenvolvimento

tecnológico veio permitir que toda a informação possa ser suportada em

computadores. Assim, ao nível das organizações, o sistema de informação tende a

ter um significativo suporte informático.

Assim sendo, um sistema de informação é composto por dois subsistemas: um

social e outro automatizado. O subsistema social inclui pessoas, processos, informações e

documentos, enquanto que o subsistema automatizado consiste em máquinas, computadores e

redes de comunicação que interligam os elementos do subsistema social.

21

2.1.1 Tipos de Sistemas de Informação

Existem várias formas de classificar os sistemas de informação. Neste trabalho a

classificação será feita de acordo com a finalidade principal de uso e pelo nível

organizacional, conforme é mostrado na figura 1.

Figura 1: Tipos de sistemas de informação em relação aos níveis organizações.

Fonte: AUDY, ANDRADE & CIDRAL, 2005, p. 117.

2.1.1.1 Sistemas de Processamento de Transações (SPT)

Também conhecido como Sistemas de Apoio as Operações Empresariais,

Sistemas de Controle ou Sistemas de Informação Operacionais (SIO).

De acordo com Audy, Andrade & Cidral, (2005, p.118), “os sistemas de

processamento de transações (SPT) são os sistemas de informação que executam e registram

as transações rotineiras que a organização realiza como parte de seus processos de negócio”.

Segundo Audy, Andrade & Cidral (2005), os SPT tendem a ser os primeiros

escolhidos pelas organizações quando estas decidem utilizar a tecnologia da informação, fato

que pode estar associado aos benefícios bastante visíveis da automação de operações

rotineiras.

22

2.1.1.2 Sistemas de Informação Gerenciais (SIG)

Segundo Audy, Andrade & Cidral (2005, p.119), “os sistemas de informação

gerencial (SIG) são os sistemas de informação que sintetizam, registram e relatam a situação

em que se encontram as operações da organização”.

Os sistemas de informação gerencial (SIG) oferecem suporte a decisões

estruturadas, ou seja, decisões repetitivas e rotineiras que envolvem procedimentos

padronizados.

De acordo com Audy, Andrade & Cidral (2005, p.120), “seu desenvolvimento e

utilização é facilitado quando a organização dispõem de processamento de transações já

implementados e uma cultura de gestão pautada no uso de indicadores ou na avaliação de

resultados”.

2.1.1.3 Sistemas de Apoio à Decisão (SAD)

Os sistemas de apoio à decisão (SAD) são sistemas projetados para que os

próprios usuários iniciem e controlem conforme suas necessidades e estilos de tomada de

decisão.

Audy, Andrade & Cidral (2005, p.121) definem esses sistemas:

Os sistemas de apoio a decisão (SAD) são os sistemas de informação que auxiliam

os gerentes de uma organização a tomar decisões semi-estruturadas, com base em

dados obtidos dos sistemas de informação gerencial, dos sistemas de processamento

de transações e de fontes externas.

Assim sendo, os SAD procuram disponibilizar dados e técnicas para análise de

problemas e oportunidades, devendo ser flexíveis e amigáveis na medida em que é o tomador

de decisão que irá modelar a situação a ser analisada. AUDY, ANDRADE & CIDRAL

(2005).

23

2.1.1.4 Sistemas de Informação Executiva (SIE)

Também chamados de Sistema de Suporte à Decisão de Estratégia, Sistema de

Informação Executivo, ou em inglês, Executive Information Systems (EIS).

O conceito dos sistemas de informação executiva – SIE pode ser entendido pela

definição de Audy, Andrade & Cidral (2005, p.122):

Os sistemas de informação executiva (SIE) são os sistemas de informação que

auxiliam os executivos do nível estratégico da organização a tomar decisões não-

estruturadas, a partir da disponibilização de um ambiente computacional e de

comunicação que permita fácil acesso a dados internos e externos da organização.

Esses sistemas não são projetados inicialmente para solucionar problemas

específicos, e sim, para fornecer ferramentas que possibilitam aos executivos compreender

situações de negócio, identificar problemas e oportunidades, decidir alternativas de atuação.

AUDY, ANDRADE & CIDRAL (2005).

2.2 Engenharia de Software

Pressman (2006, p.1) conceitua de maneira breve o que é o software de

computador: “é o produto que os profissionais de software constroem e, depois, mantêm ao

longo do tempo. Abrange programas que executam em computadores de qualquer tamanho e

arquitetura, conteúdo que é apresentado ao programa a ser executado e documentos tanto em

forma impressa quanto virtual que combinam todas as formas de mídia eletrônica.”

Para Paula Filho (2003, p.2):

o software é a parte programável de um sistema de informática. Ele é um elemento

central: realiza estruturas complexas e flexíveis que trazem funções, utilidade e valor

ao sistema. Mas outros componentes são indispensáveis: as plataformas de

hardware, os recursos de comunicação de informação, os documentos de diversas

naturezas, as bases de dados e até os procedimentos manuais que se integram aos

automatizados.

24

Este conceito pode ser mais bem observado de acordo com o esquema da figura 2,

onde é mostrado um sistema de informática com suas quatro partes distintas.

Figura 2: Sistema de Informática e suas partes.

Fonte: PAULA FILHO, 2003, p.3.

Para a elaboração de softwares é importante que sejam percorridos uma sequência de

passos, um roteiro, o qual favorece a elaboração de um produto de alta qualidade. Esse roteiro é

definido como processo de software. Segundo Paula Filho (2003, p.11), “um processo é definido

quando tem documentação que detalha: o que é feito (produto), quando (passos), por quem (agentes),

as coisas que usa (insumos) e as coisas que produz (resultados).”

Neste contexto, surge a engenharia de software, definida por Carvalho & Chiossi

(2001, p.5) como:

Uma disciplina que reúne metodologias, métodos e ferramentas a ser utilizados,

desde a percepção do problema até o momento em que o sistema desenvolvido deixa

de ser operacional, visando resolver problemas inerentes ao processo de

desenvolvimento e ao produto de software.

O conceito acima deve ser aplicado ao desenvolvimento de softwares visando à

melhoria da qualidade do produto que está sendo desenvolvido, agilidade no processo e,

consequentemente, implicando em redução nos custos para a empresa.

25

2.2.1 Princípios da Engenharia de Software

Durante a fase de desenvolvimento de softwares podem ser aplicados diversos

princípios que auxiliam na escolha das metodologias, métodos e ferramentas apropriadas para

esse processo. Alguns desses princípios são descritos a seguir.

2.2.1.1 Formalidade

Sommerville (2003) sugere três níveis de especificação de software: os requisitos

de usuário, os requisitos do sistema e a especificação de projeto de software. Para ele, essa

última fase, que é a construção de uma especificação completa, consistente e precisa, serve

como base para implementação do sistema e pode ser uma especificação formal.

Segundo Sommerville (2003, p. 164), “criar uma especificação formal força uma

análise detalhada dos sistemas, o que geralmente revela erros e inconsistências na

especificação informal de requisitos”.

A figura 3 mostra que as atividades de projeto e de especificação podem ser

realizadas paralelamente.

Figura 3: Especificação formal no processo de software.

Fonte: SOMMERVILLE, 2003, p. 165.

26

2.2.1.2 Abstração

O termo abstração pode ser entendido pela definição de Pfleeger (2004, p.24):

“uma abstração é a descrição de um problema com um nível de generalização que nos permite

concentrar nos principais aspectos do problema, sem nos perdermos nos detalhes”.

Carvalho & Chiossi (2001, p. 6) explicam as diferentes abstrações:

Podem existir diferentes abstrações da mesma realidade, cada uma fornecendo uma

visão diferente da realidade e servindo para diferentes objetivos. Quando requisitos

de uma aplicação são analisados e especificados, desenvolvedores de software

constroem modelos da aplicação proposta. Esses modelos podem ser expressos de

várias formas, dependendo do grau de formalidade desejado.

Assim sendo, a abstração permite diminuir a complexidade de algo, selecionando

apenas as partes desejadas, uma vez que na orientação a objetos é importante analisar as

partes para entender o todo.

2.2.1.3 Decomposição

Carvalho & Chiossi (2001, p. 7) explicam que “uma das maneiras de lidar com a

complexidade é subdividir o processo em atividades específicas, provavelmente atribuídas a

especialistas de diferentes áreas”. Sendo assim, o processo de decomposição visa

Para Carvalho & Chiossi (2001), é possível também decompor o produto em

subprodutos, definidos de acordo com o sistema que está sendo desenvolvido. Essa

decomposição traz inúmeras vantagens, como permitir que atividades do processo de

desenvolvimento sejam executadas paralelamente.

27

2.2.1.4 Generalização

As autoras Carvalho & Chiossi (2001, p.7) explicam que “o princípio da

generalização é importante, pois, sendo mais geral, é bem possível que a solução para o

problema tenha mais potencial para ser reutilizada”.

Carvalho & Chiossi (2001, p.8) apontam os cuidados que devem ser tomados com

a generalização:

Uma solução generalizada pode ser mais custosa, em termos de velocidade de

execução ou tempo de desenvolvimento. Portanto, é necessário avaliar os problemas

de custo e eficiência para decidir se vale a pena desenvolver um sistema

generalizado em vez de atender a especificação original.

Entre as vantagens da generalização está a da possibilidade de permitir que o

desenvolvedor projete um componente que seja utilizado em mais de um ponto do sistema de

software desenvolvido, em vez de ter várias soluções especializadas.

2.2.1.5 Flexibilização

Segundo Carvalho & Chiossi (2001), o princípio da flexibilização, que diz

respeito tanto ao processo como aos produtos de software, é necessário no processo de

desenvolvimento para permitir que o produto possa ser modificado com facilidade.

O processo deve ter flexibilidade suficiente para permitir que partes ou

componentes do produto desenvolvido possam ser utilizados em outros sistemas, bem como a

sua portabilidade para diferentes sistemas computacionais. CARVALHO & CHIOSSI (2001,

p.8).

28

2.2.2 Paradigmas de Engenharia de Software

De acordo com Carvalho & Chiossi (2001), os paradigmas são modelos de

processos que possibilitam o controle do processo de desenvolvimento ao gerente e a

obtenção da base para produzir de maneira eficiente ao desenvolvedor, tendo como função

diminuir os problemas encontrados na fase de desenvolvimento do software. A seguir são

descritos os três paradigmas mais utilizados.

2.2.2.1 Ciclo de Vida Clássico

Para Carvalho & Chiossi (2001, p.9), o ciclo de vida clássico “é um paradigma

que utiliza um método sistemático e sequencial, em que o resultado de uma fase se constitui

na entrada de outra”. A escolha por esse tipo de paradigma depende da complexidade da

aplicação, uma vez que aplicações mais simples e bem entendidas demandam menos

formalidade e aplicações maiores e mais complexas podem necessitar de uma maior

decomposição do processo para garantia dos resultados almejados.

A figura 4 apresenta as atividades compreendidas pelo ciclo de vida clássico.

Figura 4: Os cinco passos do ciclo de vida clássico.

Fonte: CARVALHO & CHIOSSI, 2001, p.9.

29

2.2.2.2 Paradigma Evolutivo

Segundo Carvalho & Chiossi (2001, p.14), “o paradigma evolutivo é baseado no

desenvolvimento e implementação de um produto inicial, que é submetido aos comentários e

críticas do usuário; o produto vai sendo refinado através de múltiplas versões, até que o

produto de software almejado tenha sido desenvolvido”.

Carvalho & Chiossi (2001, p.17) explicam quando utilizar esse tipo de paradigma

e suas vantagens:

O desenvolvimento evolutivo é mais apropriado para sistemas pequenos, pois os

problemas de mudanças no sistema atual podem ser contornados através da

reimplementação do sistema todo quando mudanças substanciais se tornam

necessárias. Uma outra vantagem deste tipo de abordagem é que os testes podem ser

mais efetivos, visto que testar cada versão do sistema é provavelmente mais fácil do

que testar o sistema todo no final.

Carvalho & Chiossi (2001) acreditam que o paradigma evolutivo costuma ser

mais efetivo que o ciclo de vida clássico no desenvolvimento de softwares que atendam aos

requisitos do usuário, entretanto, apresenta alguns problemas como pobreza de estruturação e

falta de visibilidade do processo sob a perspectiva de engenharia e do gerenciamento.

2.2.2.3 Paradigma Espiral

O processo espiral reflete o fato de que os requisitos afetam as decisões do projeto

e vice-versa e, assim, faz sentido interligar esses processos. SOMMERVILLE (2007).

Sommerville (2007) explica ainda que o processo se inicia pelo centro e cada

volta do espiral pode acrescentar detalhes aos requisitos e ao projeto. É possível que o novo

conhecimento adquirido durante os processos de requisito e de projeto faça com que a

declaração do problema precise sofrer alterações. O processo finaliza quando a revisão e

avaliação mostram que os requisitos e o projeto são suficientemente detalhados para que se

inicie a próxima fase do processo.

30

A figura 5 ilustra o modelo em espiral.

Figura 5: Modelo em espiral

Fonte: SOMMERVILLE, 2007, p. 20

“A diferença mais importante entre o paradigma espiral e os outros paradigmas é a

análise de risco. [...] Os riscos podem ser diminuídos, ou mesmo sanados, através da

descoberta de informações que venham a diminuir a incerteza com relação ao

desenvolvimento”. CARVALHO & CHIOSSI (2001, p.18).

2.2.3 Processo para Aplicativos Extensíveis Interativos (PRAXIS)

Segundo Paula Filho (2003), o PRocesso para Aplicativos eXtensíveis InterativoS

– Praxis é desenhado para suportar projetos com duração de, no máximo, 1 (um) ano, com

ênfase no desenvolvimento de aplicativos gráficos interativos, baseados na tecnologia

orientada a objetos.

31

O processo Praxis é dividido de acordo com as fases mostradas na figura 6.

Figura 6: Fases do Praxis.


Segundo Paula Filho (2003), a UML é a notação de modelagem utilizada no

Praxis, em todos os passos em que for aplicável.

O Praxis apresenta diversas vantagens, como: ser baseado na tecnologia orientada

a objetos; possuir como notação de análise e desenho a UML, ter padrões conforme os do

Institute of Eletrical and Eletronic Engineer – IEEE; possuir elementos do Processo

Unificado e ser um processo iterativo; poder ser utilizado para fins didáticos e comerciais,

com a possibilidade de ser reproduzido e alterado livremente; garantir o nível 3 (três) do

Capability Maturity Model Integration – CMMI. É possível destacar algumas das suas

desvantagens, como, ter pouca divulgação, ainda não sendo usado em escala nacional e exigir

muita documentação. PAULA FILHO (2003).

No presente trabalho, esse processo será seguido até a fase de construção, não

correspondendo ao desenvolvimento do sistema, apenas da sua implementação, com

modelagem e construção de interfaces gráficas.

2.3 Processo de Desenvolvimento de Software

O processo de desenvolvimento de softwares envolve as atividades de

levantamento de requisitos, análise dos requisitos, projeto, implementação, testes e

implantação. Essas atividades serão descritas com mais detalhes nos tópicos seguintes.

32

2.3.1 Atividades Típicas de um Processo de Desenvolvimento

A seguir serão abordadas as fases necessárias para o desenvolvimento do

software.

2.3.1.1 Levantamento de Requisitos

Entender os requisitos de um problema está entre as tarefas mais difíceis da

engenharia de software. Isso se deve ao fato de que na maioria das vezes os usuários finais

não conseguem definir qual é sua real necessidade, e, ainda que saibam, elas vão se

modificando ao longo projeto. PRESSMAN (2006).

De acordo com Paula Filho (2003, p.29), “os requisitos devem ser levantados a

nível tão detalhado quanto necessário para que cliente, usuários e desenvolvedores se ponham

de acordo quanto a eles”. Esse detalhamento é importante para que não haja desentendimentos

entre o que o cliente solicita e o que o engenheiro de software compreende que ele deseja.

Durante essa fase que são realizadas as primeiras atividades do fluxo de análise, identificação

das classes envolvidas no processo e seus respectivos relacionamentos.

2.3.1.2 Análise de Requisitos

É nessa fase que a especificação dos requisitos torna-se confiável o suficiente para

servir de base ao planejamento detalhado do restante do projeto, existindo informação

suficiente para planejar as atividades de um grupo de garantia da qualidade. PAULA FILHO

(2003).

Segundo Paula Filho (2003, p.31), “as atividades iniciais de Análise dos

Requisitos levam à identificação de classes que representem adequadamente os conceitos

expressos nos requisitos, e à descoberta dos respectivos atributos e relacionamentos”.

33

Nessa fase deve ser feito o refinamento da identificação e organização das classes

e seus relacionamentos, bem como a identificação dos atributos, realização dos casos de uso e

revisão da análise. PAULA FILHO (2003).

O levantamento dos requisitos visa capturar as necessidades dos usuários em

relação ao produto, expressas na linguagem destes usuários; enquanto a análise dos requisitos

confecciona um modelo conceitual do produto, o qual é usado para validar os requisitos

levantados e para planejar o desenvolvimento posterior. PAULA FILHO (2003).

2.3.1.3 Projeto

Nessa fase são aplicadas as técnicas e princípios para definição de um artefato, um

processo ou um sistema em detalhes suficientes para permitir sua realização. O projeto é

também a parte mais artística e criativa do processo de desenvolvimento de software e poucas

regras podem ser escritas para guiá-lo. GUSTAFSON (2003).

Gustafson (2003) identifica as fases do projeto: (1) projeto dos dados, onde são

produzidas as estruturas dos dados, (2) projeto arquitetural, responsável pelas unidades

estruturais – classes, (3) projeto de interface, que especifica as interfaces entre unidades e (4)

projeto procedimental, onde são especificados os algoritmos de cada método.

2.3.1.4 Implementação

“Essa fase visa detalhar e implementar o desenho através de componentes de

código e de documentação associada”. PAULA FILHO (2003).

Paula Filho (2003), existem algumas que contribuem para o bom relacionamento

com o usuário durante a fase de implementação. São elas:

técnicas de desenho e implementação que reduzam os custos de modificações

ocasionais (desenho robusto e extensível, código bem documentado etc.);

pontos de controle freqüentes e visíveis para o cliente.

34

O desenvolvimento incremental, baseado em um desenho arquitetônico robusto,

seguido de liberações bem planejadas, atende a estes requisitos. As próprias liberações se

constituem em resultados intermediários concretos, muito mais eficazes que relatórios de

progresso, quanto ao convencimento dos clientes. PAULA FILHO (2003).

2.3.1.5 Teste

Essa atividade tem como objetivo verificar os resultados da fase anterior, a

implementação. A atividade de teste de um processo na execução de um projeto piloto de

avaliação de processo. PAULA FILHO (2003).

De acordo com o Paula Filho (2003), no modelo Praxis, os testes são divididos em

alfas e betas. Os testes alfas são responsáveis pela realização dos testes de aceitação, no

ambiente dos desenvolvedores, juntamente com elaboração da documentação de usuário,

enquanto os testes bestas, realizados posteriormente, são responsáveis pelos testes de

aceitação no ambiente dos usuários.

2.3.1.6 Implantação

A fase de implantação é a fase final do desenvolvimento de softwares, onde o

sistema é colocado a disposição de uma comunidade de usuários. Trata das atividades que

garantem a disponibilização física do sistema para seus usuários, como planejamento, redes,

sistemas operacionais e sistemas de banco de dados. PAULA FILHO (2003).

O software entregue fornece benefícios ao usuário final, mas também fornece

feedback útil para a equipe de software, o qual deve ser usado para fazer modificações

imediatas, caso necessário, definir futuras modificações, fazer alterações necessárias para

acomodar as alterações e revisar o plano para que o próximo incremento reflita as

modificações. PRESSMAN (2006).

35

2.4 Programação Orientada a Objetos

Para que seja possível o entendimento da orientação a objetos será feito

primeiramente uma abordagem geral e, posteriormente, estudado seus principais conceitos.

2.4.1 Visão Geral

A fundamentação da orientação a objetos consiste na possibilidade de definir

novos tipos de dados que combinam membros de dados e funções que trabalham sobre esses

dados; esses tipos de dados são as classes. MIZRAHI (2006).

A proposta da orientação a objetos, segundo Matos (2002, p. 20) é “permitir que

os programadores organizem os programas da mesma forma que as nossas mentes enxergam

os problemas: não como um conjunto de espaços de memória, mas como um conjunto de

coisas que fazem parte do problema”.

2.4.2 Conceitos da Orientação a Objetos

A seguir são apresentados os principais conceitos relacionados à orientação a

objetos.

2.4.2.1 Objetos

De acordo com Paula Filho (2003, p. 120), “nas metodologias de modelagem

orientadas a objetos, as entidades do domínio do problema são representadas por objetos.”

36

As partes de um modelo criado de alguma parte do mundo no computados são os

objetos, os quais devem ser categorizados e descritos por uma classe. KÖLLING & BARNES

(2009)

Kölling & Barnes (2009, p. 2) explicam essa relação dos objetos com as classes:

“os objetos são criados a partir de classes. A classe descreve o tipo do objeto; os objetos

representam instanciações individuais da classe”.

2.4.2.2 Classes

“Uma classe nada mais é que a criação de uma estrutura geral de onde objetos

podem ser derivados”. MATOS (2002, p. 22).

Segundo Sintes (2002, p.8), “uma classe define todas as características comuns a

um tipo de objeto. Especificamente, a classe define todos os atributos e comportamentos

expostos pelo objeto”.

Uma classe é representada por um retângulo que pode possuir até três divisões. A

primeira divisão armazena o nome da classe; a segunda, os atributos da classe; e a terceira, os

métodos. GUEDES (2007).

2.4.2.3 Herança

O relacionamento de herança existe entre classes de natureza mais geral

(superclasses, classes base) e suas especializações (subclasses, classes derivadas). A

identificação de superclasses é feita quando são localizados atributos ou operações comuns a

um grupo de classes. Nas subclasses devem ser localizadas as operações ou atributos que só

se aplicam a um subconjunto das instâncias de uma classe. PAULA FILHO, (2003).

37

O conceito de herança pode ser compreendido pela explicação de Page-Jones

(2001, p. 33):

A herança (de D a partir de C) é a habilidade que uma classe D tem implicitamente

definida em cada um dos atributos e operações da classe C, como se esses atributos e

operações tivessem sido definidos com base na própria classe D. C é caracterizada

como uma superclasse de D. Em contrapartida, D é caracterizada como um sublasse

de C.

Uma classe herda de outra se todos os objetos desta classe são casos especiais de

objetos de outra classe, capazes de exibir o mesmo comportamento desta, mas possivelmente

com responsabilidades adicionais e um estado mais rico. HORSTMANN (2007, p. 65).

A figura 7 ilustra um exemplo do relacionamento de herança entre classes.

Figura 7: Exemplo de relacionamento de herança.


2.4.2.4 Polimorfismo

A palavra polimorfismo se origina de duas palavras gregas que significam muitas

e formas, sendo assim, algo que é polimórfico pode assumir muitas formas. PAGE-JONES

(2001).

38

No contexto da orientação a objetos, o termo polimorfismo pode ser definido

como “a característica de chamar métodos de um objeto sem especificar o tipo exato dele é

conhecido” MIZRAHI (2006, p.184).

2.5 Unified Modeling Language (UML)

Aprovada em 1997 pela Object Management Group (OMG), a Unified Modeling

Language (UML), que pode ser traduzida por Linguagem de Modelação Unificada, surgiu

devido à necessidade de um padrão para a modelagem de sistemas que fosse aceito e utilizado

amplamente.

“A UML é uma família de notações gráficas, apoiada por um metamodelo único,

que ajuda na descrição e no projeto de sistemas de software, particularmente daqueles

construídos utilizando o estilo orientado a objetos (OO).” FOWLER (2005, p. 22)

De acordo com O’Neill & Nunes (2000, p.3):

Pelo fato de utilizar um conjunto de símbolos padrão, a UML funciona como um

meio de comunicação entre os diversos processos, utilizadores, gestores e equipe de

desenvolvimento. A linguagem pode ser utilizada para documentar o sistema ao

longo de todo o ciclo de desenvolvimento, começando com a tarefa inicial de análise

de processos de negócio da organização e prolongando-se até a tarefa de

manutenção evolutiva do sistema informático.

Silva & Videira (2001) apresentam algumas características da UML:

é independente do domínio de aplicação (i.e., pode ser usado em projetos de diferentes

características, tais como sistemas cliente/servidor tradicionais; sistemas baseados na

Web; sistemas de informação geográficos; sistemas de tempo real);

é independente do processo ou metodologia de desenvolvimento;

é independente das ferramentas de modelação;

apresenta mecanismos potentes de extensão;

39

agrega um conjunto muito significativo de diferentes diagramas/técnicas dispersos por

diferentes linguagens (e.g., diagramas de casos de utilização, de classes, de objetos, de

colaboração, de atividades, de estados, de componentes, e de instalação).

A seguir serão descritos os principais diagramas da UML: diagrama de caso de

uso, diagrama de classe e diagrama de estados.

2.5.1 Diagrama de Caso de Uso

Segundo Matos (2002), os diagramas de casos de usos são formados por atores e

casos de uso. Um ator deve ter associações exclusivamente para casos de uso, componentes

ou classes - a exceção que um ator herde o papel de outro.

Os relacionamentos entre esses elementos podem ser:

entre atores: generalização;

entre casos de usos: generalização, extensão e inclusão;

entre atores e casos de uso: associação.

Para Guedes (2007, p. 38), “este diagrama procura, por meio de uma linguagem

simples, demonstrar o comportamento externo do sistema, buscando apresentar o sistema por

uma perspectiva do usuário, demonstrando as funções e os serviços oferecidos e quais

usuários poderão utilizar o sistema”.

40

A representação dos casos de uso é mostrada na figura 8.

Figura 8: Exemplo do diagrama de caso de uso.

Fonte: MATOS, 2002, p.39.

Os atores representam os papéis desempenhados pelos diversos usuários que

poderão utilizar ou interagir com os serviços e funções do sistema. GUEDES (2007, p. 38). A

figura 9 exemplifica a representação dos atores na UML.

Figura 9: Exemplo de Atores.

Fonte: GUEDES, 2007, p.39.

Os atores se associam com os casos de uso (do inglês use case), os quais

representam as funções e serviços do produto. Segundo Matos (2002, p. 35), “internamente,

um caso de uso é uma sequência de ações que permeiam a execução completa de um

comportamento esperado para o sistema”.

41

Segundo Guedes (2007, p. 39), “os casos de uso costumam ser documentados,

demonstrando qual o comportamento pretendido para o caso de uso em questão e quais

funções ele executará quando for solicitado”. Essa documentação é bastante flexível, não

existindo um formato específico para ela. Pode ser feitas através de outros diagramas, como o

diagrama de sequência ou o diagrama de atividade.

Os casos de usos são representados graficamente através de um círculo oval com

uma frase em seu interior representando determinada ação, como mostrado na figura 10.

Figura 10: Representação do Caso de Uso.

Fonte: GUEDES, 2007, p. 39.

Dentre os relacionamentos que podem ocorrer entre os casos de uso, os dois

principais são de inclusão e exclusão. Os relacionamentos de inclusão ocorrem entre

diferentes casos de usos e indicam obrigatoriedade, sendo assim, quando dois casos de uso

possuem esse tipo de associação, a execução de um implica na execução obrigatória do outro.

Por outro lado, as associações de extensão devem ser utilizadas quando é desejado um

comportamento opcional num caso de uso, devendo ser executado somente com alguma

condição satisfeita. PAULA FILHO (2003).

2.5.2 Diagrama de Classe

“Na UML, a classe é representada por um retângulo dividido em três

compartimentos que contêm, respectivamente, o nome da classe, os atributos e as operações.”

PAULA FILHO (2003, p. 573).

Matos (2002, p. 43), destaca a importância das classes em aplicações orientadas a

objetos:

na verdade, são a real estrutura de dados, ou seja, o objetivo final para o início da

etapa de programação;

42

dar ao programador a noção do domínio do problema;

projetar uma solução de implementação ao problema;

traçar perspectivas de escalabilidade ao sistema (onde e como o sistema pode crescer

em termos funcionais).

A figura 11 apresenta um exemplo do diagrama de classe e suas associações.

Figura 11: Exemplo Diagrama de Classe

Fonte: MATOS, 2007, p.54

2.5.3 Diagrama de Estados

Segundo Guedes (p. 118, 2007), “este diagrama representa o comportamento de

um elemento por meio de um conjunto de transições de estados.”. O autor afirma também

que, apesar de muitas vezes o elemento modelado ser uma instância de uma classe, é possível

43

modelar o comportamento de um caso de uso ou até mesmo o comportamento de um sistema

completo.

Existem alguns importantes conceitos relacionados com o diagrama de estado,

como o de transição, evento e estado. Estado, segundo Matos (p. 77), é a “condição em que

uma instância se encontra.” Um estado pode demonstrar a espera pela ocorrência de um

evento, a reação a um estímulo, a execução de alguma atividade ou a satisfação de alguma

condição. GUEDES (2007).

Os conceitos de evento e transição estão relacionados entre si, como explica

Matos (p. 77, 2002) “quando ocorre um evento, significa que uma instância deixará um estado

e chegará ao outro”. Por outro lado, a transição, “representa um evento que causa uma

mudança no estado de um objeto, gerando um novo estado.” GUEDES (p. 119, 2007).

A figura 12 ilustra um exemplo do diagrama de estados, onde é apresentada a

transição entre os estados “acesa” e “apagada”.

Figura 12: Exemplo de um Diagrama de Estados.

Fonte: SILVA & VIDEIRA, 2001, p. 215.

2.6 Ferramentas Utilizadas

Os tópicos a seguir se referem às ferramentas que foram necessárias ser utilizadas

para o desenvolvimento do trabalho.

44

2.6.1 Ferramentas CASE (Computer Aided Software Engineering)

Os autores Silva & Videira (2001, p. 423) definem CASE como:

Conjunto de técnicas e ferramentas informáticas que auxiliam o engenheiro de

software no desenvolvimento de aplicações, com o objetivo de diminuir o respectivo

esforço e complexidade, de melhorar o controle do projeto, de aplicar

sistematicamente um processo uniformizado e de automatizar algumas atividades,

nomeadamente a verificação da consistência e qualidade do produto final e a

geração de artefatos.

As primeiras ferramentas CASE surgiram no mercado no início da década de 80,

auxiliando na documentação, análise e na construção de diagramas e desenhos. Com o tempo,

foram surgindo ferramentas cada vez mais completas, como explica Silva & Videira (2001,

p.400):

A introdução dos conceitos da orientação por objetos veio de alguma forma

revolucionar o mercado, quer porque uma parte significativa das ferramentas

tradicionais teve que se "reinventar", e incorporar novas técnicas de modelação

integradas (ou não) com as abordagens estruturadas já existentes.

Para Silva & Videira (2001), um dos principais objetivos que se pretende alcançar

com a utilização das ferramentas CASE é a construção de um ambiente integrado que permita

uma abordagem desde a concepção até a implementação dos sistemas de informação.

2.6.1.1 Astah Community

Para a construção dos diagramas deste trabalho foi utilizada a ferramenta CASE

ASTAH. Criada em 1996 pela companhia japonesa ChangeVision e nomeada como JUDE –

acrônimo de Java and UML Developers Environmen (Ambiente para desenvolvimento de

Java e UML), a ferramenta foi desenvolvida na plataforma Java, permitindo portabilidade

para qualquer sistema operacional que possua máquina virtual Java. SBROCCO (2001)

45

Segundo Sbrocco (2001), em 1999, a ferramenta JUDE começou a ser

disponibilizada como software livre e, cinco anos mais tarde, passou a ser comercializada em

diferentes versões. Três anos mais tarde, JUDE foi renomeado para ASTAH depois de receber

as preocupações dos usuários alemães, que ressaltou a semelhança do nome do produto com a

palavra alemã Jude, que remete para um homem judeu.

2.6.2 Visual Basic

Segundo Mabbut, o Visual Basic, foi criado pela Microsoft2 em 1991, para tornar

mais fácil escrever programas para computador do sistema operacional Windows. A base do

Visual Basic é uma linguagem de programação anterior chamada BASIC que foi inventado

pelo Dartmouth College, os professores John Kemeny e Thomas Kurtz. Visual Basic é muitas

vezes referida usando apenas as iniciais, VB. O ambiente permite a construção de interfaces

agradáveis com facilidade de manuseio.

2 A Microsoft é uma empresa multinacional que surgiu há 37 anos e trabalha oferecendo softwares, serviços,

soluções e suporte.

Fonte: http://www.microsoft.com/about/pt/br/default.aspx

46

3 TRABALHO DESENVOLVIDO

3.1 Escopo do Produto

Para compor o escopo do E-menu, descreve-se informações básicas e seus

características desses produtos, tais como nomes, componentes, missão e limite.

3.1.1 Nome do Sistema e Componentes

Nome do sistema de cardápio eletrônico

E-Menu

Principais componentes do E-Menu

Os principais componentes do E-Menu são:

realização de pedidos;

encerramento de contas;

gerenciamento de pedidos realizados;

gerenciamento dos usuários com acesso ao sistema;

gerenciamento das solicitações de auxílios;

gerenciamento dos produtos do cardápio;

gerenciamento de mesas;

gerenciamento de contas;

emissão de relatórios.

3.1.2 Missão do Produto

Gerenciar os produtos e pedidos realizados por clientes em estabelecimentos,

através de um sistema de cardápio eletrônico.

47

3.1.3 Limites do Produto

Os limites do E-Menu são:

o E-Menu não fará o controle financeiro dos estabelecimentos;

o E-Menu não irá interagir com periféricos, como impressora.

3.1.4 Benefícios do Produto

Os reais benefícios do produto são mostrados no quadro 1.

QUADRO 1

Os reais benefícios do produto

Número de Ordem Benefício Valor para o cliente

1

2

3

4

5

6

Redução de custos

Agilidade nos atendimentos

Modernização do ambiente

Facilidade de realizar alterações

Segurança no fechamento da

conta

Diminuição dos erros em

pedidos

Desejável

Essencial

Desejável

Essencial

Essencial

Essencial

Fonte: Resultados obtidos.

48

3.2 Perspectivas do Produto

3.2.1 Usuários e Sistemas Externos

3.2.1.1 Descrição

Os usuários e sistemas externos são apresentados no quadro 2.

QUADRO 2

Usuários e Sistemas Externos

Número de

Ordem

Ator Definição

1

2

3

4

Cliente

Garçom

Balconista

Gerente

Pessoal responsável pela visualização do cardápio, realização de

pedidos e solicitação de encerramento de contas.

Pessoal responsável pela abertura de mesas.

Pessoal responsável pela administração dos pedidos, mesas,

contas, produtos e auxílios.

Pessoal responsável pelo gerenciamento de todo o sistema.

Fonte: Resultados Obtidos.

3.2.1.1 Características dos Usuários

As características dos usuários são apresentadas no quadro 3.

QUADRO 3

Características dos usuários

(Continua)

Número

de Ordem

Ator

Frequência

de uso

Nível de

instrução

Proficiência

na aplicação

Proficiência em

informática

1

2

Cliente

Garçom

Diário

Diário

Ensino

Fundamental

Ensino

Fundamental

Operacional

Operacional

Básica

Básica

49

(Conclusão)

Número

de Ordem

Ator

Frequência

de uso

Nível de

instrução

Proficiência

na aplicação

Proficiência em

informática

3

4

Balconista

Gerente

Diário

Diário

2º Grau

2º Grau

Operacional

Operacional

Intermediária

Intermediária


3.3 Diagrama de Contexto do E-Menu

O diagrama de contexto do E-Menu é apresentado na figura 13.

50

Figura 13: Diagrama de Contexto do E-Menu.


51

3.3.1 Interfaces de Usuários

As interfaces com usuários são apresentados no quadro 4 para os diagrama de

contexto do E-Menu.

QUADRO 4

Interfaces com os usuários

(Continua)

Número

da Ordem

Nome

Ator

Caso de Uso

Descrição

1

2

3

4

5

6

7

8

9

10

Interface “E-Menu –

Visualizar Cardápio”


Fazer Pedido”


Visualizar Conta”


Encerrar Conta”


Selecionar Forma de

Pagamento”


Solicitar Auxílio”


Abrir mesa”


Efetuar Login”


Novo produto”


Alterar produto”.

Cliente

Cliente

Cliente

Cliente

Cliente

Cliente

Garçom

Garçom/

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Visualizar

Cardápio

Fazer Pedido

Visualizar Conta

Encerrar Conta

Selecionar Forma

de Pagamento

Solicitar Auxílio

Abrir mesa

Efetuar Login

Gerenciar

Produtos

Gerenciar

Produtos

Interface para

visualização de itens

disponíveis para

pedido.

Interface para

realização de pedidos.

Apresenta os pedidos

já realizados e o atual

valor da conta.

Interface para encerrar

conta.

Permite selecionar a

forma de pagamento

da conta. Apresenta

três opções: dinheiro,

cartão ou cheque.

Interface para solicitar

presença de um

garçom na mesa.

Interface para abertura

de uma nova mesa.

Interface para realizar

login e ter acesso ao

sistema.

Interface para

cadastrar um novo

produto no cardápio.

Interface para editar

dados de um produto.

52

(Continua)

Número

da Ordem

Nome

Ator

Caso de Uso

Descrição

11

12

13

14

15

16

17

18

19

20

21

22

23


Alterar produto”.


Cadastrar mesa”


Alterar mesa”


Excluir mesa”


Alterar status

pedido”


Alterar status

auxílio”


Cadastrar Tipo -

produto”


Alterar Tipo -

produto”


Alterar produto”


Contas”


Contas”


Cadastrar

funcionário”


Alterar dados

funcionário”

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Balconista/

Gerente

Gerente

Gerente

Gerenciar

Produtos

Gerenciar Mesas

Gerenciar Mesas

Gerenciar Mesas

Gerenciar Pedidos

Gerenciar

Auxílios

Gerenciar tipos de

produtos

Gerenciar tipos de

produtos

Gerenciar tipos de

produtos

Gerenciar Contas

Gerenciar Contas

Gerenciar

Funcionários

Gerenciar

Funcionários

Interface para excluir

um produto.

Interface para

cadastrar mesas no

sistema.

Interface para alterar

mesas no sistema.


mesas no sistema.


status dos pedidos no

sistema.


status dos pedidos de

auxílios no sistema.

Interface para

cadastrar tipos de

produtos no sistema.


tipos de produtos no

sistema.


tipos de produtos no

sistema.

Interface para

visualizar os pedidos

de encerramento de

contas.


pedidos de

encerramento de

contas.

Interface para

cadastrar funcionários

sistema.


dados dos funcionários

53

Número

da Ordem

Nome

Ator

Caso de Uso

Descrição

24

25

26

27

28


Excluir funcionário”


Emitir Relatório”.


Novo Grupo”


Alterar Grupo”


Excluir Grupo”

Gerente

Gerente

Gerente

Gerente

Gerente

Gerenciar

Funcionários

Emitir Relatório

Gerenciar grupos

de usuários

Gerenciar grupos

de usuários

Gerenciar grupos

de usuários


funcionários no

sistema.

Interface para gerar

relatório diário do

sistema.

Interface para

cadastrar grupos de

usuários sistema.


grupos de usuários

sistema


grupos de usuários

sistema


3.3.1.1 Caso de Uso Visualizar Cardápio

O fluxo do caso de uso Visualizar Cardápio é apresentado no quadro 5.

QUADRO 5

Fluxo do Caso de Uso “Visualizar Cardápio”.

(Continua)

Sumário: O Cliente visualiza todas as opções do cardápio.

Ator Primário: Cliente.

Pré-condições: 1 A mesa já foi aberta pelo garçom.

Fluxo Principal

1 O E-Menu exibe a interface do “E-Menu – Visualizar Cardápio.

Subfluxos

Não se aplica.

(Conclusão)

54

(Conclusão)

Fluxos Alternativos

1 O cliente clica em “detalhes”, sendo exibindo os detalhes do produto;

2 O cliente clica em “Adicionar”, adicionando um item ao seu pedido;

3 O cliente clica em “Minha Conta”, exibindo a interface “E-Menu – Visualizar Conta”.


A figura 14 mostra a interface “E-Menu – Visualizar Cardápio”.

Figura 14: Interface “E-Menu – Visualizar Cardápio”.


55

A figura 15 mostra o Diagrama de Transição de Estados – “Visualizar Cardápio”.

Figura 15: Diagrama de Estados “Visualizar Cardápio”. Fonte: Resultados Obtidos.

Os comandos da Interface “E-Menu – Visualizar Cardápio” são apresentados no

quadro 6.

QUADRO 6

Comandos da Interface “E-Menu – Visualizar Cardápio”.

Número Nome Ação Restrições

1

2

Exibir E-Menu

– Cardápio

Visualizar

detalhes

Exibe as opções do cardápio

Exibe os detalhes do produto, como curiosidades,

quantidade de calorias e imagem.

-

-


56

3.3.1.2 Caso de Uso Fazer Pedido

O fluxo do caso de uso Fazer Pedido é apresentado no quadro 7.

QUADRO 7

Fluxo do Caso de Uso “Fazer Pedido”.

Sumário: O cliente realiza pedidos no sistema.


Pré-condições: 1 A mesa já foi aberta pelo garçom;

2 O E-Menu está na tela “E-Menu – Visualizar Cardápio”.

Fluxo Principal

1 O cliente visualiza os itens do cardápio;

2 O cliente clica no botão “+”, escolhendo a quantidade de itens desejada;

3 O cliente clica no botão “Adicionar”, adicionando os itens ao pedido;

4 O cliente envia seus pedidos ao sistema.

Subfluxos

Não se aplica.

Fluxos Alternativos

1 O cliente realiza o passo 3 e retorna ao cardápio para adicionar mais itens ao seu pedido;

2 O cliente clica em “Minha Conta”, exibindo a tela com os pedidos já realizados e respectivos

valores.


57

A figura 16 mostra a interface “Visualizar Cardápio – Fazer Pedido”.

Figura 16: Interface “E-Menu – Fazer Pedido”.


58

A figura 17 mostra o Diagrama de Transição de Estados – “Visualizar Cardápio –

Fazer Pedido”.

Figura 17: Diagrama de Estados “Fazer Pedido”.


Os campos da Interface “E-Menu – Fazer Pedido” são apresentados no quadro 8.

QUADRO 8

Campos da Interface “E-Menu – Fazer Pedido”

Número Nome Descrição Valores Válidos Formato Tipo Restrição

1

2

ID

Qtde_I

tem

Identificação do

pedido.

Quantidade

desejada de cada

item.

Caracteres

numéricos.

Caracteres

numéricos.

Até 6

caracteres.

Até 2

caracteres.

Integer

Integer

Auto-

incremento,

gerado pelo

sistema.

-


59

Os comandos da Interface “E-Menu – Fazer Pedido” são apresentados no quadro 9.

QUADRO 9

Comandos da Interface “Fazer Pedido”.


1

2

3

4

Exibir E-Menu

– Cardápio

Selecionar

quantidade do

item

Adicionar item

ao pedido

Enviar Pedido

Exibe as opções do cardápio

Permite escolher a quantidade do item que deseja

pedir

Adiciona o item, com sua respectiva quantidade, ao

pedido

Envia lista de pedidos ao sistema

-

-

-

-


3.3.1.3 Caso de Uso Visualizar Conta

O fluxo do caso de uso Visualizar Conta é apresentado no quadro 10.

QUADRO 10

Fluxo do Caso de Uso “Visualizar Conta”.

Sumário: O cliente visualiza seus pedidos e valores.



Fluxo Principal

1 O cliente clica no botão visualizar conta;

2 2 O E-Menu exibe os pedidos já realizados e seus valores.

Subfluxos

1 Não se aplica.

Fluxos Alternativos

1 O cliente clica em “Finalizar conta”, encerrando seus pedidos;

2 O cliente retorna ao cardápio.


60

A figura 18 mostra a interface “e-Menu – Visualizar Conta”.

Figura 18: Interface “E-Menu – Visualizar Conta”.


A figura 19 mostra o Diagrama de Transição de Estados – “Visualizar Conta”.

Figura 19: Diagramas de Estados “Visualizar Conta”.


61

Os comandos da Interface “E-Menu – Visualizar Conta” são apresentados no

quadro 11.

QUADRO 11

Comandos da Interface “E-Menu – Visualizar Conta”.


1

2

Exibir E-Menu

– Minha Conta

Encerrar

Exibe a interface com os pedidos já realizados e a

soma de seus valores

Solicita encerramento da conta

-

-


3.3.1.4 Caso de Uso Selecionar Forma de Pagamento

O fluxo do caso de uso Selecionar Forma de Pagamento é apresentado no quadro

12.

QUADRO 12

Fluxo do Caso de Uso “Selecionar Forma de Pagamento”

Sumário: O cliente escolhe a forma de pagamento.


Pré-condições: 1 A mesa já foi aberta pelo garçom;

2 O E-Menu está na interface “E-Menu – Visualizar Conta”.

Fluxo Principal

1 Se o cliente confirmar o encerramento da conta, o E-Menu exibe a interface “E-Menu –

Selecionar Forma de Pagamento”;

2 O cliente clica na forma de pagamento desejada;

3 O E-Menu emite a mensagem “Agradecemos a preferência! Volte Sempre!”.

Subfluxos

Não se aplica.

Fluxos Alternativos

1 O cliente retorna a interface “E-Menu – Visualizar Cardápio”;

2 O cliente clica no botão “Solicitar Auxílio”.


62

A figura 20 mostra a interface “E-Menu – Selecionar Forma de Pagamento”.

Figura 20: Interface “E-Menu – Selecionar Forma de Pagamento”.


63

A figura 21 mostra o Diagrama de Transição de Estados – “Selecionar Forma de

Pagamento”.

Figura 21: Diagrama de Estados “Selecionar Forma de Pagamento”.


Os campos da Interface “E-Menu – Selecionar Forma de Pagamento” são

apresentados no quadro 13.

QUADRO 13

Campos da Interface “E-Menu – Selecionar Forma de Pagamento”


1 ID

Identificação da

forma de

pagamento

selecionada

Opção

Lógico Integer Auto-

incremento,

gerado pelo

sistema.


64

Os comandos da Interface “Selecionar Forma de Pagamento” são apresentados no

quadro 14.

QUADRO 14

Comandos da Interface “E-Menu – Selecionar Forma de Pagamento”.


1

2

3

4

5

Exibir “E-

Menu – Minha

Conta”

Selecionar

Forma de

Pagamento

Encerrar

Confirmar

Cancelar

Exibe a interface com os pedidos já realizados e a

soma de seus valores

Exibe as opções de pagamento disponíveis

Encerra a conta, retornando o somatório dos

pedidos realizados

Confirma a forma de pagamento selecionada

Cancela a forma de pagamento selecionada

-

-

-

-

-


3.3.1.5 Caso de Uso Solicitar Auxílio

O fluxo do caso de uso Solicitar Auxílio é apresentado no quadro 15.

QUADRO 15

Fluxo do Caso de Uso “Solicitar Auxílio”

Sumário: O cliente solicita auxílio na mesa.



Fluxo Principal

1 O usuário clica no botão “Solicitar Auxílio”;

2 O E-Menu emite uma mensagem “Aguarde, iremos até a sua mesa!”.

Subfluxos

Não se aplica.

Fluxos Alternativos

Não se aplica.


65

A figura 22 mostra o Diagrama de Transição de Estados – “Solicitar Auxílio”.

Figura 22: Diagrama de Estados “Solicitar Auxílio”


Os campos da Interface “E-Menu – Solicitar Auxílio” são apresentados no quadro

16.

QUADRO 16

Comandos da Interface “Solicitar Auxílio”.


1 Solicitar

Auxílio

Gera pedido para que um garçom compareça até a

mesa

-


66

3.3.1.6 Caso de Uso Efetuar Login

O fluxo do caso de uso Efetuar Login é apresentado no quadro 17.

QUADRO 17

Fluxo do caso de uso “Efetuar Login”

Sumário: O usuário realiza login no sistema.

Atores Primários: Garçom / Balconista / Gerente.

Pré-condições: 1 O E-Menu deve estar na tela de login

Fluxo Principal

1 O usuário informa o usuário e senha e clica no botão “Login”.

Subfluxos

1 Se o usuário ou senha forem inválidos, o sistema retornará a mensagem: “Usuário/Senha

Inválidos”.

Fluxos Alternativos

Não se aplica.


A figura 23 mostra a interface “E-Menu – Efetuar Login”.

Figura 23: Interface “E-Menu – Efetuar Login”.


67

A figura 24 mostra o Diagrama de Transição de Estados – “Efetuar Login”.

Figura 24: Diagrama de Estados “Efetuar Login”.


Os campos da Interface “E-Menu – Efetuar Login” são apresentados no quadro

18.

QUADRO 18

Campos da Interface “E-Menu – Efetuar Login”.


1

2

Usuário

Senha

Usuário do E-

Menu

Senha do usuário

Caracteres

alfanuméricos

Caracteres

alfanuméricos

Até 10

caracteres

Até 15

caracteres

String

String

Obrigatório/

Alterável

Obrigatório/

Alterável


68

Os comandos da Interface “E-Menu – Efetuar Login” são apresentados no quadro

19.

QUADRO 19

Comandos da Interface “Efetuar Login”.


1

Efetuar

Login

Verificar se usuário senha são cadastrados no banco de

dados e se os campos foram preenchidos corretamente.

-


3.3.1.7 Caso de Uso Abrir Mesa

O fluxo do caso de uso Abrir Mesa é apresentado no quadro 20.

QUADRO 20

Fluxo do caso de uso “Abrir Mesa”.

Sumário: O garçom abre uma nova mesa.

Ator Primário: Garçom.

Pré-condições: 1 O garçom deve ter realizado login no sistema.

Fluxo Principal

1 O garçom seleciona uma mesa dentre uma lista das que estão disponíveis;

2 O E-Menu exibe a tela de “Cardápio”.

Subfluxos

Não se aplica.

Fluxos Alternativos

Não se aplica.


69

A figura 25 mostra a interface “Abrir Mesa”.

Figura 25: Interface “E-Menu – Abrir Mesa”;


A figura 26 mostra o Diagrama de Transição de Estados – “Abrir Mesa”.

Figura 26: Diagrama de Estados “Abrir Mesa”.


70

Os campos da Interface “E-Menu – Abrir Mesa” são apresentados no quadro 21.

QUADRO 21

Campos da Interface “E-Menu – Abrir Mesa”.


1

ID

Identificação da

mesa

Caracteres

numéricos.

Opção Lógico Obrigatório


Os comandos da Interface “E-Menu – Abrir Mesa” são apresentados no quadro 22.

QUADRO 22

Comandos da Interface “E-Menu – Abrir Mesa”


1

Escolher

número da

mesa

É aberta uma lista com as mesas disponíveis para que o

garçom selecione uma para abertura

-


3.3.1.8 Caso de Uso Gerenciar Produtos

O fluxo do caso de uso Gerenciar Produtos é apresentado no quadro 23.

QUADRO 23

Fluxo do Caso de Uso “Gerenciar Produtos”.

(Continua)

Sumário: O Balconista/Gerente gerencia os produtos no sistema.

Atores Primários: Balconista/Gerente.

Pré-condições: 1 O Balconista/Gerente deve ter realizado login no sistema.

Fluxo Principal

1 Se o Balconista/Gerente acessar “Produtos” e depois clicar em “Novo produto” o sistema exibirá a

interface “Cadastrar Novo Produto”;

2 Se o Balconista/Gerente selecionar um produto e clicar no link “Editar” abrirá a interface “Alterar

Dados do Produto”;

3 Se o Balconista/Gerente selecionar um produto e clicar no link “Remover” irá excluir o produto

selecionado.

Subfluxos

71

(Conclusão)

Subfluxos

1 Se passo 1, o E-Menu exibirá a interface “Cadastrar Novo Produto”;

2 O Balconista/Gerente a insere os dados do produto e clica em “Salvar”;

3 Se o Balconista/Gerente clicar em “Cancelar” retornará a interface “E-Menu – Produtos”;

4 Se passo 2, o E-Menu exibirá a interface “Alterar Dados do Produto”;

5 O Balconista/Gerente altera os dados do produto e clica em “Confirmar”;

6 Se o Balconista/Gerente clicar em “Cancelar” retornará a interface “E-Menu – Produtos”;

7 Se passo 3, o E-Menu emite uma mensagem: “Tem certeza que deseja excluir esse produto?”;

8 O Balconista/Gerente clica em “Confirmar” e o produto é excluído;

9 Se o Balconista/Gerente clicar em “Cancelar” retornará a interface “E-Menu – Produtos”.

Fluxos Alternativos

1 Se o Gerente clicar no link “Grupos” ele irá para interface “E-Menu – Grupos”;

2 Se o Gerente clicar no link “Usuários” ele irá para interface “E-Menu – Usuários”;

3 Se o Balconista/Gerente clicar no link “Tipos Produtos” ele irá para interface “E-Menu – Tipos

Produtos”;

4 Se o Balconista/Gerente clicar no link “Pedidos” ele irá para interface “E-Menu – Pedidos”;

5 Se o Balconista/Gerente clicar no link “Auxílios” ele irá para interface “E-Menu – Auxílios”;

6 Se o Balconista/Gerente clicar no link “Cardápio” ele irá para interface “E-Menu – Cardápio”;

7 Se o Balconista/Gerente clicar no link “Gerenciar Contas” ele irá para interface “E-Menu –

Gerenciar Contas”;

8 Se o Gerente clicar no link “Emitir Relatório” ele irá para interface “E-Menu – Emitir Relatório”;

10 Se o Balconista/Gerente clicar no link “Sair” ele irá para interface “E-Menu – Sair”.


A figura 27 mostra a interface “E-Menu – Gerenciar Produtos”.

Figura 27: Interface “E-Menu – Gerenciar Produtos”.


72

A figura 28 mostra a interface “E-Menu – Alterar Produto”.

Figura 28: Interface “E-Menu – Alterar Produto”.


A figura 29 mostra o Diagrama de Transição de Estados – “Gerenciar Produtos”.

Figura 29: Diagrama de Estados “Gerenciar Produtos”.


73

Os campos da Interface “E-Menu – Gerenciar Produtos” são apresentados no

quadro 24.

QUADRO 24

Campos da Interface “E-Menu – Gerenciar Produtos”


1

2

3

4

5

ID

Nome

Descrição

Preço

Imagem

Código de

identificação do

produto.

Nome do

produto.

Detalhes do

produto

Valor do

produto.

Imagem do

produto.

Caracteres

numéricos.

Caracteres

alfanuméricos.

Caracteres

alfanuméricos.

Caracteres

numéricos.

Caracteres

numéricos.

Até 6

caracteres.

Até 8

caracteres.

Até 200

caracteres.

Até 5

caracteres.

Tamanho

máximo de

100Kb.

Integer

String

String

Moeda

String

Auto-

incremento,

gerado pelo

sistema.

-

Obrigatório /

Alterável

As imagens

devem ser no

formato

JPEG.

Fonte: Resultados obtidos

Os comandos da Interface “E-Menu – Gerenciar Produtos” são apresentados no

quadro 25.

QUADRO 25

Comandos da Interface “Gerenciar Produtos”.

(Continua)


1

2

3

4

5

Exibir Gerenciador

de Produtos

Cadastrar

Salvar

Editar

Excluir

Exibe a interface para gerenciar Produtos

Exibe a interface para cadastro de Produtos

Salva os Produtos na base de dados do sistema

Exibe a interface para editar informações dos

Produtos

Exclui o(s) Produto(s) selecionado(s) no

sistema

-

-

-

-

-

74

(Conclusão)


6

7

8

Confirmar

Cancelar

Selecionar

Confirma Alteração/Exclusão de informações

dos Produtos no sistema

Cancela a operação e retorna a interface

anterior

Seleciona um Produto ao clicar no seu link

-

-

-


3.3.1.9 Caso de Uso Gerenciar Mesas

O fluxo do caso de uso Gerenciar Mesas é apresentado no quadro 26.

QUADRO 26

Fluxo do caso de uso “Gerenciar Mesas”.

(Continua)

Sumário: O Balconista/Gerente gerencia as mesas do estabelecimento.



Fluxo Principal

1 Se o Balconista/Gerente acessar “Mesas” e depois clicar em “Nova Mesa” o sistema exibirá a

interface “Cadastrar Nova Mesa”;

2 Se o Balconista/Gerente selecionar uma mesa e clicar no link “Editar” abrirá a interface “Alterar

Dados da Mesa”;

3 Se o Balconista/Gerente selecionar uma mesa e clicar no link “Remover” irá excluir a mesa

selecionada.

Subfluxos

1 Se passo 1, o E-Menu exibirá a interface “Cadastrar Nova Mesa”;

2 O Balconista/Gerente insere os dados da mesa e clica em "Salvar";

3 Se o balconista clicar em “Cancelar" retornará a interface “E-Menu – Mesas”;

4 Se passo 2, o E-Menu exibirá a interface “Alterar Dados da Mesa";

5 O Balconista/Gerente altera os dados da mesa e clica em "Confirmar";

6 Se o Balconista/Gerente clicar em "Cancelar" retornará a interface “E-Menu – Mesas”;

7 Se passo 3, o E-Menu emite uma mensagem: “Tem certeza que deseja excluir essa mesa?”;

8 O Balconista/Gerente clica em “Confirmar” e a mesa é excluída;

9 Se o Balconista/Gerente clicar em “Cancelar” retornará a interface “E-Menu – Mesas”.

75

(Conclusão)

Fluxos Alternativos




Produtos”;

4 Se o Balconista/Gerente clicar no link “Produtos” ele irá para interface “E-Menu – Produtos”;









A figura 30 mostra a interface “E-Menu – Gerenciar Mesas”.

Figura 30: Interface “E-Menu – Gerenciar Mesas”.


76

A figura 31 mostra o Diagrama de Transição de Estados – “Gerenciar Mesas”.

Figura 31: Diagrama de Estados “Gerenciar Mesas”.


Os campos da Interface “E-Menu – Gerenciar Mesas” são apresentados no quadro

27.

QUADRO 27

Campos da Interface “E-Menu – Gerenciar Mesas”.


1

2

ID

Descrição

Número de

identificação da

mesa

Descrição do

número de lugares

e outros detalhes

da mesa.

Caracteres

numéricos.

Caracteres

alfanuméricos.

Até 6

caracteres

Até 100

caracteres

Integer

String

Auto-

incremento,

gerado pelo

sistema.

-


77

Os comandos da Interface “E-Menu – Gerenciar Mesas” são apresentados no quadro

28.

QUADRO 28

Comandos da Interface “E-Menu – Gerenciar Mesas”.


1

2

3

4

5

6

7

8

Exibir Gerenciador

de Mesas

Cadastrar

Salvar

Editar

Excluir

Confirmar

Cancelar

Selecionar

Exibe a interface para gerenciar Mesas

Exibe a interface para cadastro de Mesas

Salva as Mesas na base de dados do sistema

Exibe a interface para editar informações das

Mesas

Exclui a(s) Mesa(s) selecionada(s) no sistema


das Mesas no sistema


anterior

Seleciona uma Mesa ao clicar no seu link

-

-

-

-

-

-

-

-


3.3.1.10 Caso de Uso Gerenciar Pedidos

O fluxo do caso de uso Gerenciar Pedidos é apresentado no quadro 29.

QUADRO 29

Fluxo do caso de uso “Gerenciar Pedidos”.

(Continua)

Sumário: O Balconista/Gerente gerencia os pedidos realizados pelos clientes.



Fluxo Principal

1 O Balconista/Gerente clica em “Pedidos”;

2 O E-Menu exibe uma lista com os pedidos realizados pelos clientes;

78

(Conclusão)

Fluxo Principal

3 O Balconista/Gerente clica em “Alterar”, alterando os itens que já estão prontos para entrega;

4 O Balconista/Gerente confirma a alteração o pedido é alterado no sistema.

Subfluxos

1 Se passo 4 o cliente clicar em cancelar, o sistema retorna a interface “E-Menu – Pedidos”;

2 Se passo 4 o cliente clicar em “Remover”, todo o pedido é excluído do sistema.

Fluxos Alternativos



3 Se o Balconista/Gerente clicar no link “Mesas” ele irá para interface “E-Menu – Mesas”;


Produtos”;






9 O Gerente clicar no link “Emitir Relatório” ele irá para interface “E-Menu – Emitir Relatório”;



A figura 32 mostra a interface “E-Menu – Gerenciar Pedidos”.

Figura 32: Interface “E-Menu – Gerenciar Pedidos”.


79

A figura 33 mostra o Diagrama de Transição de Estados – “Gerenciar Pedidos”.

Figura 33: Diagrama de Estados “Fazer Pedido” Fonte: Resultados obtidos

Os comandos da Interface “E-Menu – Gerenciar Pedidos” são apresentados no

quadro 30.

QUADRO 30

Comandos da Interface “E-Menu – Gerenciar Pedidos”.


1

2

3

4

5

6

Exibir interface

E-Menu –

Pedidos

Editar

Marcar como

atendido

Confirmar

Cancelar

Visualizar

Detalhes

Exibe a interface com a lista de pedidos realizados

pelos clientes.

Altera o status de um item do pedido

O pedido é removido da lista de pedidos

pendentes

Confirma a exclusão do pedido

Cancela a operação e retorna a interface anterior

Exibe os detalhes da solicitação de encerramento

de conta.

-

-

-

-

-

-


80

3.3.1.11 Caso de Uso Gerenciar Auxílios

O fluxo do caso de uso Gerenciar Auxílios é apresentado no quadro 31.

QUADRO 31

Fluxo do Caso de Uso “Gerenciar Auxílios”.

Sumário: O Balconista/Gerente administra os pedidos de auxílios realizados pelos

clientes.



Fluxo Principal

1 O balconista clica em “Auxílios”;

2 O balconista seleciona o auxílio que foi solicitado há mais tempo e clica em “Marcar como

atendido”;

3 O pedido de auxílio é removido da lista.

Subfluxos

Não se aplica.

Fluxos Alternativos





Produtos”;









81

A figura 34 mostra a interface “E-Menu – Gerenciar Auxílios”.

Figura 34: Interface “E-Menu – Gerenciar Auxílios”.


A figura 35 mostra a interface “E-Menu – Excluir Auxílios”.

Figura 35: Interface “E-Menu – Excluir Auxílios”.


82

A figura 36 mostra o Diagrama de Transição de Estados – “Gerenciar Auxílios”.

Figura 36: Diagrama de Estados “Gerenciar Auxílios”.


Os comandos da Interface “E-Menu – Gerenciar Auxílios” são apresentados no

quadro 32.

QUADRO 32

Comandos da Interface “E-Menu – Gerenciar Auxílios”.


1

2

Exibir interface

E-Menu –

Auxílios

Marcar como

atendido

Exibe a interface com a lista de pedidos de

auxílios realizados pelos clientes.

O pedido é removido da lista de pedidos

pendentes

-

-


83

3.3.1.12 Caso de Uso Gerenciar Tipos de Produtos

O fluxo do caso de uso Gerenciar Tipos de Produtos é apresentado no quadro 33.

QUADRO 33

Fluxo do caso de uso “Gerenciar Tipos de Produtos”.

Sumário: O balconista gerencia os tipos de produtos no sistema.



Fluxo Principal

1 Se o Balconista/Gerente acessar “Tipos Produtos” e depois clicar em “Novo Tipo” o sistema exibirá

a interface “Cadastrar Novo Tipo de Produto”;

2 Se o Balconista/Gerente selecionar um produto e clicar no link “Editar” abrirá a interface “Alterar

Tipo de Produto”;

3 Se o Balconista/Gerente selecionar um produto e clicar no link “Remover” irá excluir o tipo de

produto selecionado.

Subfluxos

1 Se passo 1, o E-Menu exibirá a interface “Cadastrar Novo Tipo de Produto”;

2 O Balconista/Gerente insere os dados do novo tipo de produtos e clica em “Salvar”;

3 Se o Balconista/Gerente clicar em “Cancelar" retornará a interface “E-Menu – Tipos Produtos”;

4 Se passo 2, o E-Menu exibirá a interface “Alterar Dados do Tipo de Produto";

5 O Balconista/Gerente altera os dados do tipo do produto e clica em "Confirmar";

Subfluxos

6 Se o Balconista/Gerente clicar em "Cancelar" retornará a interface “E-Menu – Tipos

Produtos”;

7 Se passo 3, o E-Menu emite uma mensagem: “Tem certeza que deseja excluir esse tipo de

produto?”;

8 O Balconista/Gerente clica em “Confirmar” e o tipo do produto é excluído;

9 Se o balconista clicar em “Cancelar” retornará a interface “E-Menu – Tipos Produtos”.

Fluxos Alternativos

1 Se o Gerente clicar no link “Grupos” ele irá para interface “E-Menu – Grupos”; 1 Se o Gerente clicar no link “Usuários” ele irá para interface “E-Menu – Usuários”;


3 Se o Balconista/Gerente a clicar no link “Produtos” ele irá para interface “E-Menu – Produtos”;









84

A figura 37 mostra a interface “E-Menu – Gerenciar Tipos de Produtos”.

Figura 37: Interface “E-Menu – Gerenciar tipos de Produtos”.


A figura 38 mostra o Diagrama de Transição de Estados – “Gerenciar Tipos de

Produtos”.

Figura 38: Diagrama de Estados “Gerenciar Tipos de Produtos”.


85

Os campos da Interface “E-Menu – Gerenciar Tipos de Produtos” são


QUADRO 34

Campos da Interface “E-Menu – Gerenciar Tipos de Produtos”.


1

2

3

ID

Nome

Descrição

Identificação do

tipo do produto

Nome do tipo do

produto.

Descrição ou

observações do

tipo do produto.

Caracteres

numéricos.

Caracteres

alfanuméricos.

Caracteres

alfanuméricos.

Até 6

caracteres

Até 30

caracteres

Até 100

caracteres

Integer

String

String

Auto-

incremento,

gerado pelo

sistema.

Obrigatório /

Alterável

-


Os comandos da Interface “E-Menu – Gerenciar Tipos de Produtos” são


QUADRO 35

Comandos da Interface “E-Menu – Gerenciar Tipos de Produtos”.


1

2

3

4

5

6

7

8

Exibir Gerenciador

de Tipos de

Produtos

Cadastrar

Salvar

Editar

Excluir

Confirmar

Cancelar

Selecionar

Exibe a interface para gerenciar Tipos de

Produtos

Exibe a interface para cadastro de Tipos de

Produtos

Salva os Tipos de Produtos na base de dados

do sistema


Tipos de Produtos

Exclui o Tipo de Produto selecionado no

sistema


dos Tipos de Produtos no sistema


anterior

Seleciona um Tipo de Produto ao clicar no seu

link

-

-

-

-

-

-

-

-


86

3.3.1.13 Caso de Uso Gerenciar Contas

O fluxo do caso de uso Gerenciar Contas é apresentado no quadro 36.

QUADRO 36

Fluxo do caso de uso “Gerenciar Contas”.

Sumário: O Balconista/Gerente gerencia os pedidos de encerramento de contas

solicitados.



Fluxo Principal

1 O Balconista/Gerente clica em “Contas”;

2 O sistema retorna a interface “E-Menu - Contas”;

3 O Balconista/Gerente seleciona um pedido de encerramento de mês, clicando em “Detalhes”;

4 O Balconista/Gerente clica no link “Marcar como atendido”;

5 O sistema emite uma mensagem: “Esta ação irá retirar a solicitação da lista”;

6 O Balconista/Gerente confirma a exclusão, retirando a solicitação da lista.

Subfluxos

1 Se no passo 4 o Balconista/Gerente clicar em cancelar, o sistema retorna para a interface “E-Menu –

Contas”

Fluxos Alternativos



3 Se o Balconista/Gerente clicar no link “Usuários” ele irá para interface “E-Menu – Usuários”;

4 Se o Balconista/Gerente clicar no link “Tipo Produtos” ele irá para interface “E-Menu – Tipos de

Produtos”;





9 Se o 1 Se o Gerente clicar no link “Emitir Relatório” ele irá para interface “E-Menu – Emitir

Relatório”;



87

A figura 39 mostra o Diagrama de Transição de Estados – “Gerenciar Contas”.

Figura 39: Diagrama de Estados “Gerenciar Contas”.


Os comandos da Interface “E-Menu – Gerenciar Contas” são apresentados no

quadro 37.

QUADRO 37

Comandos da Interface “E-Menu – Gerenciar Contas”


1

2

3

4

5

Exibir Gerenciador

de Contas

Visualizar detalhes

Excluir

Confirmar

Cancelar

Exibe a interface para gerenciar Pedidos de

encerramento de contas.

Exibe os detalhes da solicitação de

encerramento de conta.

Interface solicitando exclusão do pedido de

encerramento de conta selecionado no sistema.

Confirma a exclusão do pedido de

encerramento de conta.

Cancela a exclusão e retorna a interface

anterior.

-

-

-

-

-


88

3.3.1.14 Caso de Uso Gerenciar Usuários

O fluxo do caso de uso Gerenciar Usuários é apresentado no quadro 38.

QUADRO 38

Fluxo do Caso de Uso “Gerenciar Usuários”.

Sumário: O gerente administra os funcionários com acesso ao sistema.

Ator Primário: Gerente.

Pré-condições: 1 O gerente deve ter realizado login no sistema.

Fluxo Principal

1 Se o Gerente acessar “Usuários” e depois clica em “Novo usuário” o sistema exibirá a interface

“Cadastrar Novo usuário”;

2 Se o Gerente selecionar um usuário e clicar no link “Editar” abrirá a interface “Alterar Dados do

Usuário”;

3 Se o Gerente selecionar um funcionário e clicar no link “Remover” irá excluir o usuário

selecionado.

Subfluxos

1 Se passo 1, o E-Menu exibirá a interface “Cadastrar Novo Usuário”;

2 O Gerente insere os dados do novo usuário e clica em “Salvar”;

3 Se o Gerente clicar em “Cancelar" retornará a interface “E-Menu – Usuários”;

4 Se passo 2, o E-Menu exibirá a interface “Alterar Dados do Usuários”;

5 O Gerente altera os dados do funcionárioe clica em "Confirmar";

6 Se o Gerente clicar em “Cancelar” retornará a interface “E-Menu – Usuários”;

7 Se passo 3, o E-Menu emite uma mensagem: “Tem certeza que deseja excluir esse usuário?”;

8 O Gerente clica em “Confirmar” e o tipo do produto é excluído;

9 Se o Gerente clicar em “Cancelar” retornará a interface “E-Menu – Usuários”.

Fluxos Alternativos


2 Se o Gerente clicar no link “Mesas” ele irá para interface “E-Menu – Mesas”;

3 Se o Gerente clicar no link “Tipos Produtos” ele irá para interface “E-Menu – Tipos Produtos”;

4 Se o Gerente clicar no link “Produtos” ele irá para interface “E-Menu – Produtos”;

5 Se o Gerente clicar no link “Pedidos” ele irá para interface “E-Menu – Pedidos”;

6 Se o Gerente clicar no link “Auxílios” ele irá para interface “E-Menu – Auxílios”;

7 Se o Gerente clicar no link “Cardápio” ele irá para interface “E-Menu – Cardápio”;

8 Se o Gerente clicar no link “Gerenciar Contas” ele irá para interface “E-Menu – Gerenciar Contas”;


10 Se o Gerente clicar no link “E-Menu – Sair” ele irá para interface “Sair”.


89

A figura 40 mostra a interface “E-Menu – Gerenciar Usuários”.

Figura 40: Interface “E-Menu – Gerenciar Usuários”.


A figura 41 mostra a interface “E-Menu – Novo usuário”.

Figura 41: Interface “E-Menu – Novo usuário”.


90

A figura 42 mostra o Diagrama de Transição de Estados – “Gerenciar Usuários”.

Figura 42: Diagrama de Estados “Gerenciar Usuários”. Fonte: Resultados obtidos.

Os campos da Interface “E-Menu – Gerenciar Usuários” são apresentados no

quadro 39.

QUADRO 39

Campos da Interface “E-Menu – Gerenciar Usuários”.


1

2

3

4

ID

Nome

Usuário

Senha

Identificação do

usuário

Nome do

funcionário

Nome de usuário

para acesso ao

sistema

Senha do

funcionário

Caracteres

alfanuméricos.

Caracteres

alfanuméricos.

Caracteres

alfanuméricos.

Caracteres

alfanuméricos.

Até 6

caracteres

Até 30

caracteres

Até 10

caracteres

Até 15

caracteres

Integer

String

String

String

Auto-

incremento,

gerado pelo

sistema.

Obrigatório /

Alterável

Obrigatório /

Alterável

Obrigatório /

Alterável


91

Os comandos da Interface “E-Menu – Gerenciar Usuários” são apresentados no

quadro 40.

QUADRO 40

Comandos da Interface “Gerenciar Usuários”.


1

2

3

4

5

6

7

8

Exibir Gerenciador

de Usuários

Cadastrar

Salvar

Editar

Excluir

Confirmar

Cancelar

Selecionar

Exibe a interface para gerenciar usuários

Exibe a interface para cadastro de usuários

Salva os usuários na base de dados do sistema


usuários

Exclui o(s) usuário(s) selecionado(s) do

sistema


dos usuários no sistema


anterior

Seleciona um usuário ao clicar no seu link

-

-

-

-

-

-

-

-


3.3.1.15 Caso de Uso Emitir Relatório

O fluxo do caso de uso Emitir Relatório é apresentado no quadro 41.

QUADRO 41

Fluxo do Caso de Uso “Emitir Relatório”

(Continua)

Sumário: O Sistema emite relatórios por períodos.



92

(Conclusão)

Fluxo Principal

1 O Gerente clica na opção “Emitir Relatório”

2 O Gerente seleciona o período do qual ele deseja emitir relatório, podendo ser diário, semanal,

mensal ou semestral;

3 O E-Menu emite o relatório selecionado.

Subfluxos

Não se aplica.

Fluxo Alternativos







7 Se o Gerente clicar no link “Auxílios” ele irá para interface " E-Menu – Auxílios”;


9 Se o Gerente clicar no link “Gerenciar Contas” ele irá para interface “E-Menu – Gerenciar Contas”;

10 Se o Gerente clicar no link “Sair” ele irá para interface “E-Menu – Sair”.


A figura 43 mostra o Diagrama de Transição de Estados – “Emitir relatório”.

Figura 43: Diagrama de Estados “Emitir Relatório”.


93

Os comandos da Interface “E-Menu – Emitir Relatório” são apresentados no

quadro 42.

QUADRO 42

Comandos da Interface “Emitir Relatório”


1

2

Exibir E-Menu

– Emitir

Relatório

Selecionar

período

Exibe a interface para emissão de relatórios

Seleciona o período para emissão do relatório

-

-


3.3.1.16 Caso de Uso Gerenciar Grupos

O fluxo do caso de uso Gerenciar Grupos é apresentado no quadro 43.

QUADRO 43

Fluxo do Caso de Uso “Gerenciar Grupos”.

(Continua)

Sumário: O Gerente administra os grupos que pertencerão seus funcionários.



Fluxo Principal

1 Se o Gerente acessar “Grupos” e depois clica em “Novo Grupo” o sistema exibirá a interface

“Cadastrar Novo Grupo”;

2 Se o Gerente selecionar um grupo e clicar no link “Editar” abrirá a interface "Alterar Grupo”;

3 Se o Gerente selecionar um funcionário e clicar no link “Remover” irá excluir o grupo selecionado.

Subfluxos

1 Se passo 1, o E-Menu exibirá a interface “Cadastrar Novo Grupo”;

2 O Gerente insere os dados do novo grupo e clica em “Salvar”;

3 Se o Gerente clicar em “Cancelar" retornará a interface “E-Menu – Grupos”;

4 Se passo 2, o E-Menu exibirá a interface “Alterar Dados do Grupo”;

5 O Gerente altera os dados do grupo e clica em "Confirmar";

94

(Conclusão)

Subfluxos

6 Se o Gerente clicar em “Cancelar” retornará a interface “E-Menu – Grupos”;

7 Se passo 3, o E-Menu emite uma mensagem: “Tem certeza que deseja excluir esse grupo?”;

8 O Gerente clica em “Confirmar” e o tipo do produto é excluído;

Se o Gerente clicar em “Cancelar” retornará a interface “E-Menu – Grupos”.

Fluxos Alternativos






6 Se o Gerente clicar no link “Auxílios” ele irá para interface “E-Menu – Auxílios”;


8 Se o Gerente clicar no link “Gerenciar Contas” ele irá para interface “E-Menu – Gerenciar

Contas”;


10 Se o Gerente clicar no link “Sair” ele irá para interface “E-Menu – Sair”.


A figura 44 mostra a interface “E-Menu – Gerenciar Grupos”.

Figura 44: Interface “E-Menu – Gerenciar Grupos”;


95

A figura 45 mostra o Diagrama de Transição de Estados – “Gerenciar Grupos”.

Figura 45: Diagrama de Estados “Gerenciar Grupos”


Os campos da Interface “E-Menu – Gerenciar Grupos” são apresentados no

quadro 44.

QUADRO 44

Campos da Interface “E-Menu – Gerenciar Grupos”.


1

2

3

ID

Nome

Descrição

Identificação do

grupo de

usuários.

Nome do grupo.

Descrição do

grupo.

Caracteres

alfanuméricos.

Caracteres

alfanuméricos.

Caracteres

alfanuméricos.

Até 6

caracteres

Até 30

caracteres

Até 100

caracteres

Integer

String

String

Auto-

incremento,

gerado pelo

sistema.

Obrigatório /

Alterável

-


96

Os comandos da Interface “Gerenciar Grupos” são apresentados no quadro 45.

QUADRO 45

Comandos da Interface “Gerenciar Grupos”.


1

2

3

4

5

6

7

8

Exibir Gerenciador

de Grupos

Cadastrar

Salvar

Editar

Excluir

Confirmar

Cancelar

Selecionar

Exibe a interface para gerenciar grupos

Exibe a interface para cadastro de grupos

Salva os grupos na base de dados do sistema


grupos

Exclui grupo(s) selecionado(s) do sistema


dos grupos no sistema


anterior

Seleciona um grupo ao clicar no seu link

-

-

-

-

-

-

-

-


97

3.4 Diagrama de Classes Persistentes

A figura 46 mostra o diagrama de classes persistentes do sistema.

Figura 46: Diagrama de classes do “E-Menu”.


98

3.4.1 Classes Persistentes

O quadro 36 mostra as classes persistentes do sistema.

QUADRO 46

Classes Persistentes

Número de

ordem

Nome Restrição

1

2

3

4

5

6

7

8

Grupo

TipoProduto

Produto

Item

Pedido

Mesa

Auxílio

Contas

Informação relativa aos grupos de usuários que acessam o

sistema.

Informação relativa aos tipos de produtos que serão

cadastrados no sistema.

Informação relativa aos produtos que serão cadastrados no

sistema.

Informação relativa aos itens que estarão presentes nos

pedidos.

Informação relativa aos pedidos que serão realizados

através do E-Menu.

Informação relativa às mesas do estabelecimento.

Informação relativa aos pedidos de auxílios

Informação relativa às contas de cada mesa aberta no

sistema.


99

4 DISCUSSÃO DOS RESULTADOS

O presente trabalho permitiu a modelagem de sistema de cardápio eletrônico, o E-

Menu, com base na metodologia Praxis. Foram utilizadas as ferramentas Astah Community

(versão gratuita) para construção dos diagramas e o Visual Basic para o desenvolvimento do

protótipo de interfaces.

Durante a fase de modelagem foram construídos o diagrama de contexto,

diagrama de estados e diagrama de classes. Estes diagramas esboçam o modelo do sistema, e

a partir da descrição dos fluxos, passos e apresentação das interfaces conseguiu-se apresentar

um modelo para o sistema.

Através da modelagem foi possível visualizar os diversos benefícios que um

sistema de cardápio eletrônico fornece aos restaurantes. São eles: (a) segurança no

encerramento de contas, uma vez que não há enganos sobre pedidos, valores e quantidades de

itens solicitados por cada cliente; (b) agilidade no atendimento; (c) modernização do

ambiente; (d) redução de custos; (e) facilidade de alterações de produtos e valores nos

cardápios

Enfim, os resultados obtidos com a realização deste trabalho foram satisfatórios,

atingindo os objetivos estipulados e propondo a modelagem sólida de um sistema de cardápio

eletrônico que permite viabilidade para sua implementação e implantação.

100

5 CONSIDERAÇÕES FINAIS

O aprendizado adquirido durante o desenvolvimento deste trabalho foi muito

importante para o crescimento pessoal e profissional, concluindo essa etapa com a aplicação

dos principais conceitos estudados durante o curso, o que poderá ser de grande auxílio em

trabalhos posteriores.

Permitiu-se também o entendimento da importância da modelagem de sistemas

utilizando a Engenharia de Software e a UML, as quais serviram de base para a modelagem

do E-Menu.

As maiores dificuldades para realização desse trabalho ocorreram durante a fase

de especificação do sistema, pois se trata de um assunto recente, com poucos materiais

publicados, fazendo necessário muito estudo e observações para responder às dúvidas que

foram surgindo ao longo do projeto.

Com o trabalho desenvolvido, conclui-se que o modelo de um sistema de cardápio

eletrônico, poderá trazer resultados expressivos para os restaurantes, especialmente para

aqueles da cidade de Montes Claros, por se tratar de um município em constante crescimento

e desenvolvimento, onde a população se encontra rodeada de opções de lazer e os

estabelecimentos devem procurar modernidade, agilidade, melhoria no atendimento e novas

formas de atrair clientes.

Sendo assim, é possível concluir que o presente trabalho, que tinha como

problema inicial: através da modelagem de um sistema de cardápio eletrônico é possível

visualizar seus benefícios para os restaurantes? – atingiu o seu objetivo geral: propor a

modelagem de um sistema de cardápio eletrônico, sendo necessário para isso, atender aos

objetivos específicos: (a) criar um módulo para visualização de cardápios, no qual serão

apresentados os produtos do estabelecimento e seus respectivos valores; (b) criar um módulo

para realização de pedidos, onde será possível a escolha dos itens e suas quantidades; (c) criar

um módulo para encerramento de conta, no qual o cliente solicitará o fechamento dos seus

pedidos; (d) criar um módulo para gerenciamento de produtos, onde serão cadastrados os

produtos comercializados no estabelecimento; (e) criar um módulo para gerenciamento de

pedidos, o qual permitirá a administração das solicitações realizadas pelos clientes; (f) criar

um módulo para gerenciamento de contas, permitindo a administração do estabelecimento

101

controlar o fechamento e abertura de mesas no sistema; (g) criar um módulo para emissão de

relatórios.

Para elaboração de trabalhos futuros indica-se a implementação do sistema

proposto, a inclusão de outros idiomas no E-Menu, como inglês e espanhol, o que facilitará a

comunicação do ambiente com estrangeiros. Indica-se também a interação do sistema com

periféricos, como impressora e o surgimento de janelas indicando a chegada de novos

pedidos.

102

REFERÊNCIAS

AUDY, Jorge Luis Nicolas; ANDRADE, Gilberto Keller de; CIDRAL, Alexandre.

Fundamentos de Sistemas de Informação. Porto Alegre: Bookman, 2005.

BARNES, David; KÖLLING, Michel. Programação Orientada a Objetos com Java.

Tradução Edson Furmankiewicz. 4. Ed. São Paulo: Pearson Prentice Hall, 2009

CARVALHO, Ariadne M. B. Rizzoni; CHIOSSI, Thelma C. dos Santos. Introdução à

Engenharia de Software. São Paulo: Editora da UNICAMP, 2001.

FOWLER, Martin. UML essencial: um breve guia para a linguagem-padrão de

modelagem de objetos. Trad. João Tortello. 3. ed. Porto Alegre: Bookman, 2005.

GUEDES, Gilleanes T. A. UML 2: guia prático. São Paulo: Novatec Editora, 2007.

GUSTAFSON, David A. Teoria e problemas de engenharia de software. Porto Alegre:

Bookman, 2003.

HORSTMANN, Cay. Padrões e Projeto Orientados a Objetos. Trad. Bernardo Copstein. 2.

ed. Porto Alegre: Bookman, 2007

LAUDON, Kenneth C.; LAUDON, Jane P. Sistemas de Informações Gerenciais. 7. ed. São

Paulo: Pearson Education, 2007.

MABBUT, Dan. What is Visual Basic? Disponível em:

<http://visualbasic.about.com/od/applications/a/whatisvb.htm>. Acesso em: 11/05/2011.

MATOS, Alexandre Veloso de. UML: Prático e Descomplicado. São Paulo: Érica, 2002.

MEIRELES, Manuel. Sistemas de Informação: quesitos de excelência dos sistemas de

informações operativos e estratégicos. São Paulo: Arte & Ciência, 2001.

MICROSOFT. Somar para multiplicar. Disponível em:

http://www.microsoft.com/about/pt/br/default.aspx. Acesso em: 11/05/2011.

http://visualbasic.about.com/od/applications/a/whatisvb.htm

http://www.microsoft.com/about/pt/br/default.aspx

103

MIZRAHI, Victorine Viviane. Treinamento em linguagem C++, módulo 2. São Paulo:

Makron Books, 1990.

PADOVEZE, Clóvis Luís. Contabilidade gerencial: um enfoque e sistemas de informação

contábil. São Paulo: Atlas, 1997.

PAGE-JONES, Meilir. Fundamentos do Desenho Orientado a Objetos com UML. Trad.

Celso Roberto Paschoa. São Paulo: Makron Books, 2001.

PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, métodos e

padrões. 2ª ed. Rio de Janeiro: LTC, 2003.

PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. Trad. Dino

Franklin. 2ª ed. São Paulo: Prentice Hall, 2004.

PRESSMAN, Roger S. Engenharia de Software. Trad. Rosângela Delloso Penteado. 2ª ed.

São Paulo: McGraw-Hill, 2006.

SANTOS, Márcio. A onda dos Tablets. Disponível em:

<http://www.universowap.com.br/antenado/a-onda-dos-tablets/>. Acesso em: 20/05/2011.

SBROCCO, José Henrique Teixeira de Carvalho. UML 3.2 – Teoria e Prática. 1ª ed. Rio de

Janeiro: Editora Érica, 2011.

SILVA, Aberto Manuel Rodrigues da; VIDEIRA, Carlos Alberto Escaleira. UML,

Metodologias e Ferramentas CASE. 1ª ed. Editora: Centro Atlântico, Ltda, 2001.

SILVA, Douglas Marcos da. UML – Guia de Consulta Rápida. São Paulo: Novatec, 2001.

SINTES, Anthony. Aprenda Programação Orientada a Objetos em 21 dias.

Tradução:João Eduardo Nóbrega Tortello. São Paulo: Pearson, 2002.

SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. Trad. André Maurício de Andrade

Ribeiro. São Paulo: Addison Wesley, 2003.

_______________. Engenharia de software. 8ª ed. Trad. Selma Shin Shimizu Melnikoff,

Reginaldo Arakaki, Edílson de Andrade Barbosa. São Paulo: Pearson Addison-wesley, 2007.

http://www.universowap.com.br/antenado/a-onda-dos-tablets/

104

WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a

Objetos. Rio de Janeiro: Elsevier, 2004.

Documents

Tcc Mara Santos