Tcc Mara Santos
-
Upload
farlley-barbosa -
Category
Documents
-
view
14 -
download
0
Transcript of 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
Maíra Gonçalves Santos
MODELAGEM DE UM SISTEMA DE CARDÁPIO ELETRÔNICO
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
Maíra Gonçalves Santos
MODELAGEM DE UM SISTEMA DE CARDÁPIO ELETRÔNICO
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
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.
Fonte: PAULA FILHO, 2003, p.25.
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.
Fonte: PAULA FILHO, 2003, p.143.
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
Fonte: Resultados Obtidos.
3.3 Diagrama de Contexto do E-Menu
O diagrama de contexto do E-Menu é apresentado na figura 13.
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”
Interface “E-Menu –
Fazer Pedido”
Interface “E-Menu –
Visualizar Conta”
Interface “E-Menu –
Encerrar Conta”
Interface “E-Menu –
Selecionar Forma de
Pagamento”
Interface “E-Menu –
Solicitar Auxílio”
Interface “E-Menu –
Abrir mesa”
Interface “E-Menu –
Efetuar Login”
Interface “E-Menu –
Novo produto”
Interface “E-Menu –
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
Interface “E-Menu –
Alterar produto”.
Interface “E-Menu –
Cadastrar mesa”
Interface “E-Menu –
Alterar mesa”
Interface “E-Menu –
Excluir mesa”
Interface “E-Menu –
Alterar status
pedido”
Interface “E-Menu –
Alterar status
auxílio”
Interface “E-Menu –
Cadastrar Tipo -
produto”
Interface “E-Menu –
Alterar Tipo -
produto”
Interface “E-Menu –
Alterar produto”
Interface “E-Menu –
Contas”
Interface “E-Menu –
Contas”
Interface “E-Menu –
Cadastrar
funcionário”
Interface “E-Menu –
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.
Interface para excluir
mesas no sistema.
Interface para alterar
status dos pedidos no
sistema.
Interface para alterar
status dos pedidos de
auxílios no sistema.
Interface para
cadastrar tipos de
produtos no sistema.
Interface para alterar
tipos de produtos no
sistema.
Interface para excluir
tipos de produtos no
sistema.
Interface para
visualizar os pedidos
de encerramento de
contas.
Interface para excluir
pedidos de
encerramento de
contas.
Interface para
cadastrar funcionários
sistema.
Interface para alterar
dados dos funcionários
53
Número
da Ordem
Nome
Ator
Caso de Uso
Descrição
24
25
26
27
28
Interface “E-Menu –
Excluir funcionário”
Interface “E-Menu –
Emitir Relatório”.
Interface “E-Menu –
Novo Grupo”
Interface “E-Menu –
Alterar Grupo”
Interface “E-Menu –
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
Interface para excluir
funcionários no
sistema.
Interface para gerar
relatório diário do
sistema.
Interface para
cadastrar grupos de
usuários sistema.
Interface para alterar
grupos de usuários
sistema
Interface para excluir
grupos de usuários
sistema
Fonte: Resultados Obtidos.
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”.
Fonte: Resultados Obtidos.
A figura 14 mostra a interface “E-Menu – Visualizar Cardápio”.
Figura 14: Interface “E-Menu – Visualizar Cardápio”.
Fonte: Resultados obtidos.
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.
-
-
Fonte: Resultados Obtidos.
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.
Ator Primário: Cliente.
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.
Fonte: Resultados Obtidos.
57
A figura 16 mostra a interface “Visualizar Cardápio – Fazer Pedido”.
Figura 16: Interface “E-Menu – Fazer Pedido”.
Fonte: Resultados obtidos.
58
A figura 17 mostra o Diagrama de Transição de Estados – “Visualizar Cardápio –
Fazer Pedido”.
Figura 17: Diagrama de Estados “Fazer Pedido”.
Fonte: Resultados Obtidos.
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.
-
Fonte: Resultados Obtidos.
59
Os comandos da Interface “E-Menu – Fazer Pedido” são apresentados no quadro 9.
QUADRO 9
Comandos da Interface “Fazer Pedido”.
Número Nome Ação Restrições
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
-
-
-
-
Fonte: Resultados Obtidos.
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.
Ator Primário: Cliente.
Pré-condições: 1 A mesa já foi aberta pelo garçom.
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.
Fonte: Resultados Obtidos.
60
A figura 18 mostra a interface “e-Menu – Visualizar Conta”.
Figura 18: Interface “E-Menu – Visualizar Conta”.
Fonte: Resultados obtidos.
A figura 19 mostra o Diagrama de Transição de Estados – “Visualizar Conta”.
Figura 19: Diagramas de Estados “Visualizar Conta”.
Fonte: Resultados Obtidos.
61
Os comandos da Interface “E-Menu – Visualizar Conta” são apresentados no
quadro 11.
QUADRO 11
Comandos da Interface “E-Menu – Visualizar Conta”.
Número Nome Ação Restrições
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
-
-
Fonte: Resultados Obtidos.
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.
Ator Primário: Cliente.
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”.
Fonte: Resultados obtidos.
62
A figura 20 mostra a interface “E-Menu – Selecionar Forma de Pagamento”.
Figura 20: Interface “E-Menu – Selecionar Forma de Pagamento”.
Fonte: Resultados obtidos.
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”.
Fonte: Resultados obtidos.
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”
Número Nome Descrição Valores Válidos Formato Tipo Restrição
1 ID
Identificação da
forma de
pagamento
selecionada
Opção
Lógico Integer Auto-
incremento,
gerado pelo
sistema.
Fonte: Resultados obtidos.
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”.
Número Nome Ação Restrições
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
-
-
-
-
-
Fonte: Resultados obtidos.
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.
Ator Primário: Cliente.
Pré-condições: 1 A mesa já foi aberta pelo garçom.
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.
Fonte: Resultados obtidos.
65
A figura 22 mostra o Diagrama de Transição de Estados – “Solicitar Auxílio”.
Figura 22: Diagrama de Estados “Solicitar Auxílio”
Fonte: Resultados obtidos.
Os campos da Interface “E-Menu – Solicitar Auxílio” são apresentados no quadro
16.
QUADRO 16
Comandos da Interface “Solicitar Auxílio”.
Número Nome Ação Restrições
1 Solicitar
Auxílio
Gera pedido para que um garçom compareça até a
mesa
-
Fonte: Resultados obtidos.
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.
Fonte: Resultados obtidos.
A figura 23 mostra a interface “E-Menu – Efetuar Login”.
Figura 23: Interface “E-Menu – Efetuar Login”.
Fonte: Resultados obtidos.
67
A figura 24 mostra o Diagrama de Transição de Estados – “Efetuar Login”.
Figura 24: Diagrama de Estados “Efetuar Login”.
Fonte: Resultados obtidos.
Os campos da Interface “E-Menu – Efetuar Login” são apresentados no quadro
18.
QUADRO 18
Campos da Interface “E-Menu – Efetuar Login”.
Número Nome Descrição Valores Válidos Formato Tipo Restrição
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
Fonte: Resultados obtidos.
68
Os comandos da Interface “E-Menu – Efetuar Login” são apresentados no quadro
19.
QUADRO 19
Comandos da Interface “Efetuar Login”.
Número Nome Ação Restrições
1
Efetuar
Login
Verificar se usuário senha são cadastrados no banco de
dados e se os campos foram preenchidos corretamente.
-
Fonte: Resultados obtidos.
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.
Fonte: Resultados obtidos.
69
A figura 25 mostra a interface “Abrir Mesa”.
Figura 25: Interface “E-Menu – Abrir Mesa”;
Fonte: Resultados obtidos.
A figura 26 mostra o Diagrama de Transição de Estados – “Abrir Mesa”.
Figura 26: Diagrama de Estados “Abrir Mesa”.
Fonte: Resultados obtidos.
70
Os campos da Interface “E-Menu – Abrir Mesa” são apresentados no quadro 21.
QUADRO 21
Campos da Interface “E-Menu – Abrir Mesa”.
Número Nome Descrição Valores Válidos Formato Tipo Restrição
1
ID
Identificação da
mesa
Caracteres
numéricos.
Opção Lógico Obrigatório
Fonte: Resultados obtidos.
Os comandos da Interface “E-Menu – Abrir Mesa” são apresentados no quadro 22.
QUADRO 22
Comandos da Interface “E-Menu – Abrir Mesa”
Número Nome Ação Restrições
1
Escolher
número da
mesa
É aberta uma lista com as mesas disponíveis para que o
garçom selecione uma para abertura
-
Fonte: Resultados obtidos.
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”.
Fonte: Resultados obtidos.
A figura 27 mostra a interface “E-Menu – Gerenciar Produtos”.
Figura 27: Interface “E-Menu – Gerenciar Produtos”.
Fonte: Resultados obtidos.
72
A figura 28 mostra a interface “E-Menu – Alterar Produto”.
Figura 28: Interface “E-Menu – Alterar Produto”.
Fonte: Resultados obtidos.
A figura 29 mostra o Diagrama de Transição de Estados – “Gerenciar Produtos”.
Figura 29: Diagrama de Estados “Gerenciar Produtos”.
Fonte: Resultados obtidos.
73
Os campos da Interface “E-Menu – Gerenciar Produtos” são apresentados no
quadro 24.
QUADRO 24
Campos da Interface “E-Menu – Gerenciar Produtos”
Número Nome Descrição Valores Válidos Formato Tipo Restrição
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)
Número Nome Ação Restrições
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)
Número Nome Ação Restrições
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
-
-
-
Fonte: Resultados obtidos
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.
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 “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
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 “Produtos” ele irá para interface “E-Menu – Produtos”;
5 Se o Balconista/Gerente clicar no link “Pedidos” ele irá para interface “E-Menu – Pedidos”;
6 Se o Balconista/Gerente clicar no link “Auxílios” ele irá para interface “E-Menu – Auxílios”;
7 Se o Balconista/Gerente clicar no link “Cardápio” ele irá para interface “E-Menu – Cardápio”;
8 Se o Balconista/Gerente clicar no link “Gerenciar Contas” ele irá para interface “E-Menu –
Gerenciar Contas”;
9 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”.
Fonte: Resultados obtidos
A figura 30 mostra a interface “E-Menu – Gerenciar Mesas”.
Figura 30: Interface “E-Menu – Gerenciar Mesas”.
Fonte: Resultados obtidos.
76
A figura 31 mostra o Diagrama de Transição de Estados – “Gerenciar Mesas”.
Figura 31: Diagrama de Estados “Gerenciar Mesas”.
Fonte: Resultados obtidos
Os campos da Interface “E-Menu – Gerenciar Mesas” são apresentados no quadro
27.
QUADRO 27
Campos da Interface “E-Menu – Gerenciar Mesas”.
Número Nome Descrição Valores Válidos Formato Tipo Restrição
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.
-
Fonte: Resultados obtidos
77
Os comandos da Interface “E-Menu – Gerenciar Mesas” são apresentados no quadro
28.
QUADRO 28
Comandos da Interface “E-Menu – Gerenciar Mesas”.
Número Nome Ação Restrições
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
Confirma Alteração/Exclusão de informações
das Mesas no sistema
Cancela a operação e retorna a interface
anterior
Seleciona uma Mesa ao clicar no seu link
-
-
-
-
-
-
-
-
Fonte: Resultados obtidos
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.
Atores Primários: Balconista/Gerente.
Pré-condições: 1 O Balconista/Gerente deve ter realizado login no sistema.
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
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 “Mesas” ele irá para interface “E-Menu – Mesas”;
4 Se o Balconista/Gerente clicar no link “Tipos Produtos” ele irá para interface “E-Menu – Tipos
Produtos”;
5 Se o Balconista/Gerente clicar no link “Produtos” ele irá para interface “E-Menu – Produtos”;
6 Se o Balconista/Gerente clicar no link “Auxílios” ele irá para interface “E-Menu – Auxílios”;
7 Se o Balconista/Gerente clicar no link “Cardápio” ele irá para interface “E-Menu – Cardápio”;
8 Se o Balconista/Gerente clicar no link “Gerenciar Contas” ele irá para interface “E-Menu –
Gerenciar Contas”;
9 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”.
Fonte: Resultados obtidos
A figura 32 mostra a interface “E-Menu – Gerenciar Pedidos”.
Figura 32: Interface “E-Menu – Gerenciar Pedidos”.
Fonte: Resultados obtidos.
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”.
Número Nome Ação Restrições
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.
-
-
-
-
-
-
Fonte: Resultados obtidos
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.
Atores Primários: Balconista/Gerente.
Pré-condições: 1 O Balconista/Gerente deve ter realizado login no sistema.
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
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 “Mesas” ele irá para interface “E-Menu – Mesas”;
4 Se o Balconista/Gerente clicar no link “Tipos Produtos” ele irá para interface “E-Menu – Tipos
Produtos”;
5 Se o Balconista/Gerente clicar no link “Produtos” ele irá para interface “E-Menu – Produtos”;
6 Se o Balconista/Gerente clicar no link “Pedidos” ele irá para interface “E-Menu – Pedidos”;
7 Se o Balconista/Gerente clicar no link “Cardápio” ele irá para interface “E-Menu – Cardápio”;
8 Se o Balconista/Gerente clicar no link “Gerenciar Contas” ele irá para interface “E-Menu –
Gerenciar Contas”;
9 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”.
Fonte: Resultados obtidos
81
A figura 34 mostra a interface “E-Menu – Gerenciar Auxílios”.
Figura 34: Interface “E-Menu – Gerenciar Auxílios”.
Fonte: Resultados obtidos.
A figura 35 mostra a interface “E-Menu – Excluir Auxílios”.
Figura 35: Interface “E-Menu – Excluir Auxílios”.
Fonte: Resultados obtidos.
82
A figura 36 mostra o Diagrama de Transição de Estados – “Gerenciar Auxílios”.
Figura 36: Diagrama de Estados “Gerenciar Auxílios”.
Fonte: Resultados obtidos.
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”.
Número Nome Ação Restrições
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
-
-
Fonte: Resultados obtidos
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.
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 “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”;
2 Se o Balconista/Gerente clicar no link “Mesas” ele irá para interface “E-Menu – Mesas”;
3 Se o Balconista/Gerente a clicar no link “Produtos” ele irá para interface “E-Menu – 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”.
Fonte: Resultados obtidos.
84
A figura 37 mostra a interface “E-Menu – Gerenciar Tipos de Produtos”.
Figura 37: Interface “E-Menu – Gerenciar tipos de Produtos”.
Fonte: Resultados obtidos.
A figura 38 mostra o Diagrama de Transição de Estados – “Gerenciar Tipos de
Produtos”.
Figura 38: Diagrama de Estados “Gerenciar Tipos de Produtos”.
Fonte: Resultados obtidos.
85
Os campos da Interface “E-Menu – Gerenciar Tipos de Produtos” são
apresentados no quadro 34.
QUADRO 34
Campos da Interface “E-Menu – Gerenciar Tipos de Produtos”.
Número Nome Descrição Valores Válidos Formato Tipo Restrição
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
-
Fonte: Resultados obtidos
Os comandos da Interface “E-Menu – Gerenciar Tipos de Produtos” são
apresentados no quadro 35.
QUADRO 35
Comandos da Interface “E-Menu – Gerenciar Tipos de Produtos”.
Número Nome Ação Restrições
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
Exibe a interface para editar informações dos
Tipos de Produtos
Exclui o Tipo de Produto selecionado no
sistema
Confirma Alteração/Exclusão de informações
dos Tipos de Produtos no sistema
Cancela a operação e retorna a interface
anterior
Seleciona um Tipo de Produto ao clicar no seu
link
-
-
-
-
-
-
-
-
Fonte: Resultados obtidos.
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.
Atores Primários: Balconista/Gerente.
Pré-condições: 1 O Balconista/Gerente deve ter realizado login no sistema.
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
1 Se o Gerente clicar no link “Grupos” ele irá para interface “E-Menu – Grupos”;
2 Se o Balconista/Gerente clicar no link “Mesas” ele irá para interface “E-Menu – Mesas”;
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”;
5 Se o Balconista/Gerente clicar no link “Produtos” ele irá para interface “E-Menu – Produtos”;
6 Se o Balconista/Gerente clicar no link “Pedidos” ele irá para interface “E-Menu – Pedidos”;
7 Se o Balconista/Gerente clicar no link “Auxílios” ele irá para interface “E-Menu – Auxílios”;
8 Se o Balconista/Gerente clicar no link “Cardápio” ele irá para interface “E-Menu – Cardápio”;
9 Se o 1 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”.
Fonte: Resultados obtidos.
87
A figura 39 mostra o Diagrama de Transição de Estados – “Gerenciar Contas”.
Figura 39: Diagrama de Estados “Gerenciar Contas”.
Fonte: Resultados obtidos.
Os comandos da Interface “E-Menu – Gerenciar Contas” são apresentados no
quadro 37.
QUADRO 37
Comandos da Interface “E-Menu – Gerenciar Contas”
Número Nome Ação Restrições
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.
-
-
-
-
-
Fonte: Resultados obtidos
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
1 Se o Gerente clicar no link “Grupos” ele irá para interface “E-Menu – Grupos”;
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”;
9 Se o Gerente clicar no link “Emitir Relatório” ele irá para interface “E-Menu – Emitir Relatório”;
10 Se o Gerente clicar no link “E-Menu – Sair” ele irá para interface “Sair”.
Fonte: Resultados obtidos.
89
A figura 40 mostra a interface “E-Menu – Gerenciar Usuários”.
Figura 40: Interface “E-Menu – Gerenciar Usuários”.
Fonte: Resultados obtidos.
A figura 41 mostra a interface “E-Menu – Novo usuário”.
Figura 41: Interface “E-Menu – Novo usuário”.
Fonte: Resultados obtidos.
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”.
Número Nome Descrição Valores Válidos Formato Tipo Restrição
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
Fonte: Resultados obtidos
91
Os comandos da Interface “E-Menu – Gerenciar Usuários” são apresentados no
quadro 40.
QUADRO 40
Comandos da Interface “Gerenciar Usuários”.
Número Nome Ação Restrições
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
Exibe a interface para editar informações dos
usuários
Exclui o(s) usuário(s) selecionado(s) do
sistema
Confirma Alteração/Exclusão de informações
dos usuários no sistema
Cancela a operação e retorna a interface
anterior
Seleciona um usuário ao clicar no seu link
-
-
-
-
-
-
-
-
Fonte: Resultados obtidos.
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.
Ator Primário: Gerente.
Pré-condições: 1 O gerente deve ter realizado login no sistema.
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
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 Gerente clicar no link “Mesas” ele irá para interface “E-Menu – Mesas”;
4 Se o Gerente clicar no link “Tipos Produtos” ele irá para interface “E-Menu – Tipos Produtos”;
5 Se o Gerente clicar no link “Produtos” ele irá para interface “E-Menu – Produtos”;
6 Se o Gerente clicar no link “Pedidos” ele irá para interface “E-Menu – Pedidos”;
7 Se o Gerente clicar no link “Auxílios” ele irá para interface " E-Menu – Auxílios”;
8 Se o Gerente clicar no link “Cardápio” ele irá para interface “E-Menu – Cardápio”;
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”.
Fonte: Resultados obtidos
A figura 43 mostra o Diagrama de Transição de Estados – “Emitir relatório”.
Figura 43: Diagrama de Estados “Emitir Relatório”.
Fonte: Resultados obtidos.
93
Os comandos da Interface “E-Menu – Emitir Relatório” são apresentados no
quadro 42.
QUADRO 42
Comandos da Interface “Emitir Relatório”
Número Nome Ação Restrições
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
-
-
Fonte: Resultados obtidos
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.
Ator Primário: Gerente.
Pré-condições: 1 O gerente deve ter realizado login no sistema.
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
1 Se o Gerente clicar no link “Usuários” ele irá para interface “E-Menu – Usuários”;
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”;
9 Se o Gerente clicar no link “Emitir Relatório” ele irá para interface “E-Menu – Emitir Relatório”;
10 Se o Gerente clicar no link “Sair” ele irá para interface “E-Menu – Sair”.
Fonte: Resultados obtidos
A figura 44 mostra a interface “E-Menu – Gerenciar Grupos”.
Figura 44: Interface “E-Menu – Gerenciar Grupos”;
Fonte: Resultados obtidos.
95
A figura 45 mostra o Diagrama de Transição de Estados – “Gerenciar Grupos”.
Figura 45: Diagrama de Estados “Gerenciar Grupos”
Fonte: Resultados obtidos.
Os campos da Interface “E-Menu – Gerenciar Grupos” são apresentados no
quadro 44.
QUADRO 44
Campos da Interface “E-Menu – Gerenciar Grupos”.
Número Nome Descrição Valores Válidos Formato Tipo Restrição
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
-
Fonte: Resultados obtidos
96
Os comandos da Interface “Gerenciar Grupos” são apresentados no quadro 45.
QUADRO 45
Comandos da Interface “Gerenciar Grupos”.
Número Nome Ação Restrições
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
Exibe a interface para editar informações dos
grupos
Exclui grupo(s) selecionado(s) do sistema
Confirma Alteração/Exclusão de informações
dos grupos no sistema
Cancela a operação e retorna a interface
anterior
Seleciona um grupo ao clicar no seu link
-
-
-
-
-
-
-
-
Fonte: Resultados obtidos
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”.
Fonte: Resultados obtidos.
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.
Fonte: Resultados obtidos.
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.
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.