Documentação de Sistema

Autor: Gustavo de Sousa Zimmermann

Sumário
1 Introdução...................................................................................................................................3
1.1 Propósito do Documento.......................................................................................................3
1.2 Escopo...................................................................................................................................3
1.3 Definições e Siglas................................................................................................................3
2 Descrição Geral.............................................................................................................................4
2.1 Visão Geral do Produto.........................................................................................................4
2.2 Perspectivas do Produto........................................................................................................4
2.3 Funções do Produto...............................................................................................................4
2.4 Componentes de Evolução do Produto.................................................................................4
2.5 Limitações do Produto..........................................................................................................4
3 Requisitos Específicos..................................................................................................................5
3.1 Requisitos Funcionais...........................................................................................................5
3.2 Requisitos Não Funcionais....................................................................................................7
4 Matriz de Rastreabilidade.............................................................................................................8
4.1 Requisitos Funcionais x Requisitos Funcionais....................................................................8
6.2 UC2 – Caso de Uso: Gerir Questionário Gerencial............................................................13
6.3 UC3 – Caso de Uso: Gerir Questionário Individual...........................................................15
6.4 UC4 – Caso de Uso: Menu Sobre.......................................................................................17
6.5 UC5 – Caso de Uso: Sair do Aplicativo..............................................................................18
7 Diagrama de Classes (Modelo)...................................................................................................19
9.1 Handheld Basic...............................................................................................................22
9.2 Requerimentos................................................................................................................22
9.3 Instalando o Handheld Basic..........................................................................................22
10 Dificuldades Encontradas.........................................................................................................27
11 Considerações Finais................................................................................................................27
12 Bibliografia...............................................................................................................................28
1 Introdução

1.1 Propósito do Documento

O propósito deste documento é descrever e especificar uma ferramenta

computacional para apresentação e estudo do jogo de mesa chamado “Dungeons and
Dragons.
A essência de um RPG é que é uma experiência cooperativa em grupo.
(Gary Gygax). A partir dessa afirmação, podemos concluir que para que tenha uma
fluidez, é necessário que todos do grupo tenham um grande entendimento sobre as
regras e conceitos do sistema, o que não é muito encontrado entre iniciantes

Baseado nisso, este projeto se torna essencial já que novos jogadores

poderão ter um pontapé inicial neste mundo de fantasia complexo e gigante que é o
RPG (Role Playing Game).
O desenvolvimento deste trabalho envolve o desenvolvimento de uma
aplicação web que supra a necessidade de mestres de RPG terem que ensinar seus
jogadores, já que eles mesmos poderão ser auxiliados pelo site.

1.2 Escopo

O escopo do sistema é fornecer de forma organizada, centralizada e

automatizada as informações necessárias para o entendimento geral do jogo e para
auxiliar no processo de memorização dos jogadores.

1.3 Definições e Siglas

HB++ Handheld Basic - Evaluation Version - IDE de desenvolvimento

de aplicativos móveis.
VB Visual Basic - Linguagem de
Programação embutida no HB++ HD Disco rígido.
RAM

Memória principal. MB

Megabytes.
MHz Megahertz.
2 Descrição Geral
2.1 Visão Geral do Produto

De acordo com Douglas Rushkoff, à medida que a cultura popular se torna mais
presentista, nos afastamos do entretenimento como a experiência vicária de uma
narrativa — como assistir a história de outra pessoa — e muito mais em direção à
representação da própria história. Afastando-se dos mitos e em direção aos RPGs de
fantasia, longe dos filmes e em direção aos videogames.
Diante disso foram disponibilizados informações reunidas em uma aplicação
web desenvolvida no intuito de ajudar os novatos e veteranos a se integrarem melhor
com as regras disponíveis, através de questionários e quizzes.

2.2 Perspectivas do Produto

 O sistema deverá ser desenvolvido em módulo único;

 Criação de quizzes interativos que auxiliam os usuários.
 Informações reunidas e disponíveis para apresentação do jogo.

2.3 Funções do Produto

 Login;
 Dados sobre Classes e Raças;
 Questionário de memorização;
 Menu Sobre;
 Sair.
 Contato

2.4 Componentes de Evolução do Produto

O desenvolvimento deste sistema será realizado levando em

consideração a necessidade de facilitar-se a integração de jogadores ao sistema, por
ser um jogo muito complexo.

Desenvolvimento baseado em camadas. Neste nível macro, sendo as

seguintes definidas: Camada de Visão, Camada de Controle, Camada de Lógica de
Negócio, Camada de Modelo, Camada de Persistência e Base de Dados.

2.5 Limitações do Produto

O sistema terá a finalidade de ensinar jogadores iniciantes e veteranos

sobre regras do sistema Dungeons and Dragons.
3 Requisitos Específicos
3.1 Requisitos Funcionais

Requisito Funcional 1: O sistema deve ter os campos para realizar o

cadastro da conta e permitir ao usuário o login.
Requisitos de Dados: id, nome, gmail, senha.

RF1: Gestão de pessoas Estado: Proposto

Prioridade: Alta Estabilidade: Alta
Descrição: O sistema deve permitir a inserção dos dados dos usuários,ou seja, o
cadastro. Para iniciar a utilização do software por eles.

Requisito Funcional 2: O sistema deve permitir ao usuário realizar os

questionários, marcando apenas uma alternativa que achar a correta. Depois do término
será possível visualizar a porcentagem de erros e acertos.
Requisitos de Dados: perguntas de número 1-5 e com respostas ao final do
questionário.

RF2: Gerir Questionários Estado: Proposto

Prioridade: Alta Estabilidade: Alta
Descrição: O sistema deve permitir que o usuário cadastrado no sistema marque a
opção correta no questionário proposto em cada conteúdo.

Requisito Funcional 3: O sistema deve permitir ao usuário desenvolvedor a

inclusão, alteração, consulta e exclusão dos dados do questionário individual.
Requisitos de Dados: nome do respondente, perguntas 1 até a pergunta 5.

RF3: Gerir Questionário Individual Estado: Proposto

Prioridade: Alta Estabilidade: Alta
Descrição: O sistema deve permitir a manutenção dos dados do questionário. Para o
preenchimento do questionário é necessário que haja um usuário cadastrado.

Requisito Funcional 4: O sistema deve permitir a qualquer usuário que

consiga reportar erros,sugestões e dúvidas sobre o site.
Requisitos de Dados: não se aplica.

RF4: Contato Estado: Proposto

Prioridade: Alta Estabilidade: Alta
Descrição: O sistema deve permitir uma caixa de texto para o usuário reportar
qualquer coisa.
 Requisito Funcional 5: O sistema deve permitir a mobilidade do usuário
em selecionar qualquer item independente qual aba do site ele esteja .
Requisitos de Dados: itens do menu.

RF5: Menu Estado: Proposto

Prioridade: Alta Estabilidade: Alta
Descrição: O sistema deve permitir um menu interativo com todos os itens do site .
3.2 Requisitos Não Funcionais

Requisito Não Funcional 1: O sistema deve utilizar um sistema gerenciador

de bancos de dados que possibilite a integração ao sistema a ser desenvolvido (banco de
dados interno).

RNF1: Banco de Dados Estado: Proposto

Prioridade: Alta Estabilidade: Baixa Obrigatório
Descrição: O sistema deve utilizar um sistema gerenciador de bancos de dados que
possibilite a integração ao sistema a ser desenvolvido.

Requisito Não Funcional 2: O sistema deve possibilitar que todos os

relatórios e/ou gráficos sejam pré-visualizados antes do envio para a impressora, caso
existam.

RNF2: Pré-Visualização Estado: Proposto

Prioridade: Baixa Estabilidade: Baixa Desejável
Descrição: O sistema deve possibilitar que todos os relatórios e/ou gráficos sejam pré-
visualizados antes do envio para a impressora.

Requisito Não Funcional 3: O sistema deve possuir alta usabilidade,

constituindo facilidade para que os usuários aprendam a operá-lo, tempo e esforço
mínimos para que os usuários atinjam um nível aceitável de desempenho, mínimo
esforço físico e cognitivo dos usuários durante o processo de interação, disponibilização
de help e interfaces auto-explicativas e satisfação dos usuários.

RNF3: Usabilidade Estado: Proposto

Prioridade: Média Estabilidade: Média Desejável
Descrição: O sistema deve possuir alta usabilidade.

Requisito Não Funcional 4: O sistema deve ser desenvolvido utilizando a

linguagem Visual Basic.

RNF4: Linguagem Estado: Proposto

Prioridade: Alta Estabilidade: Alta Obrigatória
Descrição: O sistema deve ser desenvolvido utilizando a linguagem Visual Basic.

Requisito Não Funcional 5: O sistema deve ser desenvolvido utilizando

uma interface condizente às limitações dos dispositivos portáteis disponíveis atualmente
no mercado de modo a facilitar a operação do aplicativo.

RNF5: Interface Pequena Estado: Proposto

Prioridade: Alta Estabilidade: Alta Obrigatória
Descrição: O sistema deve ser desenvolvido utilizando uma interface condizente às
limitações dos dispositivos portáteis disponíveis atualmente no mercado de modo a
facilitar a operação do aplicativo.
4 Matriz de Rastreabilidade
4.1 Requisitos Funcionais x Requisitos Funcionais

RF1 RF2 RF3 RF4 RF5

RF1
RF2 x
RF3 x
RF4
RF5

4.2 Requisitos Funcionais x Requisitos Não Funcionais

RF1 RF2 RF3 RF4 RF5

RNF1 x x x x x
RNF2
RNF3 X x x x x
RNF4 X x x x x
RNF5 X x x x x
5 Diagrama de Casos de Uso

UC1: Gerir Empresa

Ator: Administrador
Descrição: O caso de uso é utilizado para descrever o registro da empresa a ser
avaliada nos questionários.

UC2: Gerir Questionário Gerencial

Ator: Gestor
Descrição: O caso de uso é utilizado para descrever o registro dos questionários
gerenciais.

UC3: Gerir Questionário Individual

Ator: Desenvolvedor
Descrição: O caso de uso é utilizado para descrever o registro dos questionários
individuais.
UC4: Menu Sobre
Ator: Todos os Usuários
Descrição: O caso de uso é utilizado para descrever um menu about sobre o autor e a
pesquisa que originaram os questionários.

UC5: Sair do Aplicativo

Ator: Todos os Usuários
Descrição: O caso de uso é utilizado para descrever a ação de finalização do
aplicativo.

6 Especificação de Casos de Uso

6.1 UC1 – Caso de Uso: Gerir Empresa

Ator Principal:
Administrador

Sumário:
O caso de uso é utilizado para descrever a primeira ação do Administrador que é a de
incluir os dados da Empresa no qual irá trabalhar. O objetivo deste caso de uso é
possibilitar o cadastramento da empresa, pois sem o cadastramento da empresa fica
impossibilitado o acesso aos questionários Gerencial e Individual.

Pré-Condições:
Não Aplicável.

Fluxo Principal:
1 O sistema exibe a tela de cadastro da empresa.
2 O sistema exibe uma lista de empresas previamente cadastrada.

Fluxos Alternativos:
Não Aplicável.

Subfluxo: Operação Incluir

1 O administrador abre a tela principal com alguns campos desabilitados;
2 O sistema solicita a entrada dos seguintes dados: ID, Nome (empresa),
Contato (endereço da empresa) e Telefone (empresa);
3 O administrador informa ao sistema os dados solicitados;
4 O administrador confirma os dados informados;
5 O sistema cadastra o projeto.
Subfluxo: Operação Alterar/Visualizar
1 O sistema efetua a leitura do registro a partir da empresa escolhida.
2 O sistema exibe os dados da empresa escolhida (ID, Nome, Contato e
Telefone);
3 Se desejar, o administrador tem a opção de alterar os dados da empresa;
4 O sistema altera os dados cadastrais da empresa selecionada.

Requisitos de interface:
1 As empresas devem ser exibidas por meio de uma lista de empresas;
2 O administrador poderá pesquisar por nome da empresa;

Interface Principal do Sistema Interface Principal

Preenchida Regras de Negócio:

RN1: Os campos obrigatórios são: Nome e Contato da empresa;
6.2 UC2 – Caso de Uso: Gerir Questionário Gerencial

Ator Principal:
Gestor.

Sumário:
O caso de uso é utilizado para descrever a ação do Gestor que visa extrair informações
relativas à equipe. Deve ser respondido pelo gestor responsável que compreenda a
realidade da equipe e do desenvolvimento realizado, podendo ser um gerente ou
profissional de nível de responsabilidade equivalente.

Pré-Condições:
Não Aplicável.

Fluxo Principal:
1. O sistema exibe as telas que possuem as perguntas em relação à equipe de
desenvolvimento.

Fluxos Alternativos:
Não Aplicável.

Subfluxo: Operação Incluir

1 O gestor abre cada tela e responde cada pergunta;
2 O sistema solicita a entrada da resposta ou respostas caso a pergunta seja
para marcar mais de uma opção;
3 O gestor avança, retrocede ou sai do sistema;
4 O sistema armazena os dados informados;

Subfluxo: Operação Alterar/Visualizar

1. O sistema efetua a leitura do registro a partir da empresa escolhida.
3 Se desejar, o gestor tem a opção de alterar os dados relacionados às suas
respostas;
4 O sistema altera as respostas do gestor.

Requisitos de interface:
1 As perguntas devem ser respondidas de acordo com a realidade da empresa;
2 O gestor poderá avançar, retroceder e sair do sistema.
 Primeira tela do Questionário Gerencial

Regras de Negócio:
RN1: Os campos obrigatórios são: uma ou mais respostas de acordo com a pergunta;
6.3 UC3 – Caso de Uso: Gerir Questionário Individual

Ator Principal:
Desenvolvedor.

Sumário:
O caso de uso é utilizado para descrever a ação do Desenvolvedor que visa extrair
informações relativas aos indivíduos pertencentes à equipe. Deve ser respondido por
cada um dos membros da equipe independente da sua função.

Pré-Condições:
Não Aplicável.

Fluxo Principal:
1. O sistema exibe as telas que possuem as perguntas em relação aos indivíduos da
equipe.

Fluxos Alternativos:
Não Aplicável.

Subfluxo: Operação Incluir

1 O desenvolvedor abre cada tela e responde cada pergunta;
2 O sistema solicita a entrada da resposta da pergunta neste questionário só
uma opção pode ser marcada;
3 O desenvolvedor avança, retrocede ou sai do sistema;
4 O sistema armazena os dados informados;

Subfluxo: Operação Alterar/Visualizar

1. O sistema efetua a leitura do registro a partir do desenvolvedor.
3 Se desejar, o desenvolvedor tem a opção de alterar os dados relacionados às
suas respostas;
4 O sistema altera as respostas do desenvolvedor.

Requisitos de interface:
1 As perguntas devem ser respondidas de acordo com a necessidade da equipe;
2 O desenvolvedor poderá avançar, retroceder e sair do sistema.
 Primeira tela do Questionário Individual

Regras de Negócio:
RN1: Os campos obrigatórios são: uma ou mais respostas de acordo com a pergunta;
6.4 UC4 – Caso de Uso: Menu Sobre

Ator Principal:
Administrador, Gestor e Desenvolvedor.

Sumário:
O caso de uso é utilizado para descrever a ação de todos os atores que visa um menu
about sobre o autor e a pesquisa que originaram os questionários.

Pré-Condições:
Não Aplicável.

Fluxo Principal:
1 O sistema exibe a tela que possui as informações sobre quem originou a
pesquisa.

Fluxos Alternativos:
Não Aplicável.

Requisitos de interface:
1.1 As Mostra um texto com os dados de que originou a pesquisa;
6.5 UC5 – Caso de Uso: Sair do Aplicativo

Ator Principal:
Administrador, Gestor e Desenvolvedor.

Sumário:
O caso de uso é utilizado para descrever a ação de todos os atores que visa de
finalização do aplicativo.

Pré-Condições:
Não Aplicável.

Fluxo Principal:
1. O sistema retorna ao menu do dispositivo móvel.

Fluxos Alternativos:
Não Aplicável.
7 Diagrama de Classes (Modelo)
8 Atributos das Classes de Domínio
9 Tecnologia Utilizada
9.1 Handheld Basic

Também conhecido como HB++, o Handheld Basic é uma ferramenta de

desenvolvimento totalmente orientada a objetos seguindo as novas tendências no mundo
da programação.

Com este novo conceito o HB++ revoluciona ao distribuir novos conceitos de objetos já
prontos facilitando a vida do programador, um exemplo é o "Grid" ou o "RecordSet". O
PalmOS não reconhece instruções SQL porem o HB++ vem equipado com uma série de
Bibliotecas que possibilitam o uso de uma série de instruções muito parecidos com as
utilizadas no SQL.

Seu IDE é muito semelhante ao do VB e o código fonte possui a mesma lógica de

programação utilizada no VB6.

9.2 Requerimentos

Antes de instalar a ferramenta devemos conhecer os requisitos mínimos para se executar

o HB++:

Windows® 98 ou superior, Windows® NT 4.0 (service pack 3 recomendado) ou

superior, Windows® 2000 ou Windows® XP;
Pentium 233 Mhz;
Super VGA vídeo card;
64 MB de RAM;
Os dados acima foram retirados do site: http://www.handheld-basic.com

9.3 Instalando o Handheld Basic

O processo de instalação do Handheld basic é semelhante a de qualquer outro aplicativo

desenvolvido para a plataforma Windows. Para efetuar o download do Handheld Basic
acesse o site oficial do Handheld Basic http://www.handheld- basic.com. Veja a
seqüência de figuras com os principais passos de instalação:
Figura 1 - Informações do Setup
Nesta tela você encontra as informações básicas para instalação, o HB++ não irá
reiniciar o PC depois de a instalação, porém nesta tela ele informa que é muito
importante esta operação ao terminar a instalação. Clique em Next para continuar.

Figura 2 Termo de Licença.

Nesta janela você encontra o termo de licença do Handheld Basic, lembre-se para
prosseguir na instalação você deve aceitar todos os termos, para isso clique em "I accept
the terms in the license agreement", ao selecionar esta opção o botão Next será ativado,
então agora clique em "Next".

Figura 3 Dados de Usuário.

Nesta tela o setup pede informações sobre o usuário, tais como Nome e Empresa a
qual este trabalha. Preencha os campos e clique em "Next".
 Figura 4 Diretório de Instalação e Atalhos

Informe o diretório ao qual o HB++ deve ser instalado e as opções de acesso a este
aplicativo, logo após clique em "Next".

Figura 5 Diretórios de Aplicações Auxiliares.

Aqui você encontra as informações básicas de aplicativos auxiliares que você já possui
em seu PC tais como local aonde o POSE está instalado e principal editor de BitMap.
Repare que neste ponto eu já possuo o POSE instalado em meu PC. Caso você não
tenha o POSE instalado você terá que entrar na configuração do Handheld Basic para
configurá-lo.

Até agora o Setup só pediu informações para a instalação, ou seja, nenhum componente
ou arquivo foi instalado em seu PC. Com o fim das configurações básicas de instalação
será exibido uma tela informando que o setup está pronto para transferir e instalar o
Handheld Basic em seu PC e que é necessário clicar em "Finish" para completar testa
tarefa.
 Figura 6 Fim das configurações.

Logo após, o setup instala o HB++ em seu PC e informa o resultado da Instalação,

conforme a imagem abaixo:

Figura 7 Resultado da Instalação do Handheld Basic.

10 Dificuldades Encontradas
As principais dificuldades encontradas são causadas pela inexperiência da dupla
na programação para dispositivos móveis e também na tecnologia de programação.
Primeiramente, o Handheld Basic HB++ provê uma série de funcionalidades que
facilitam o desenho de interfaces para dispositivos móveis, mas isso implica em certo
nível de complexidade, a falta de uma camada de persistência de dados interna dificulta
muito a programação para dispositivos móveis.
O HB++ tem um pequeno suporte que permite a persistência de algumas
informações como se possuísse uma base de dados interna, mas por ser uma IDE nova
ela ainda tem os alguns probleminhas, como a sincronização e exportação desses dados
para o desktop, isso foi uma das grandes dificuldades encontradas pelos integrantes da
equipe, então fica para trabalhos futuros a implementação e exportação dos dados de
forma consistente para que esses dados sejam recolhidos de forma automática e que
seja usado para devidos fins.

11 Considerações Finais
O propósito deste documento é descrever e especificar uma ferramenta
computacional para dispositivo móvel para apoio a coleta de dados de questionário para
obtenção de dados para avaliação de requisitos de qualidade de software.
Diante de diversas tecnologias disponíveis no Mercado, a utilização do Handheld
Basic (HB++) foi uma escolha levando em consideração a sua facilidade de
Programação.
A aplicação apresentada se mostrou satisfatória, pois o sistema atendeu a todas as
expectativas dos desenvolvedores por possuir telas dinâmicas e características que
tentam amenizar as dificuldades encontradas na computação móvel.
12 Bibliografia
AMBLER, S. The Elements of UML Style. Cambridge University Press. 2003.

BOGGS, W; BOGGS, M. Mastering UML with Rational Rose 2002. Sybex; Pap/Cdr edition.
2002.

BOEHM, B. AND TURNER, R. (2004a). Balancing Agility and Discipline: A Guide for the
Perplexed. Addison-Wesley, Boston.

ERIKSSON, H. E; PENKER, M. UML Toolkit. Wiley. 1997.

FOWLER, M; KOBRYN, C; BOOCH, G. Uml Essencial. Bookman. 3rd Edition. 2000.

SOARES, L. S. (2007). Obtenção de Requisitos para Customização de Processo de

Desenvolvimento de Software. Master’s Thesis. Universidade Federal de Viçosa. CCE/DPI.
Dissertação de Mestrado.

WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos.

Editora Campus. Rio de Janeiro: Elsevier, 2004.

PRESSMAN, R. S. (2005). Software Engineering: A Practitioner’s Approach, volume 6.

McGraw-Hill.

http://www.handheld-basic.com/