UNIP INTERATIVA

Projeto Integrado Multidisciplinar

Cursos Superiores de Tecnologia

PROJETO INTEGRADO MULTIDICIPLINAR IV

Sistema em linguagem C para venda de ingressos de teatro

UNIP Interativa Polo Taquaral

2019

UNIP INTERATIVA
 Projeto Integrado Multidisciplinar

Cursos Superiores de Tecnologia

PROJETO INTEGRADO MULTIDICIPLINAR IV

Sistema em linguagem C para venda de ingressos de teatro

Nome: Patrik José Cypriano

RA: 1613557

Curso: Análise e Desenvolvimento de Sistemas

Semestre: Regime de Dependência

UNIP Interativa Polo Taquaral

2019
RESUMO

Baseado nas disciplinas de linguagem e técnicas de programação,

engenharia de software I e pesquisas realizadas em livros sobre linguagem de
programação C++, desenvolvemos o projeto solicitado neste PIM IV que consiste na
criação de um sistema para vendas de ingressos de teatro que fornece 50% de
desconto para estudantes, crianças de 02 a 12 anos, adultos a partir de 60 anos e
professores da rede pública. O sistema também deve permitir a venda de ingressos
com 100% de desconto para crianças carentes da rede pública às terças-feiras. O
sistema também precisa exibir na tela o ticket com nome da peça, data, hora e número
da poltrona, a disponibilidade de poltronas e impedir a duplicidade do mesmo para a
peça. Também desenvolveremos funcionalidades para a gestão do caixa registrando
todas as movimentações do dia e o saldo do fechamento.

Palavras chave: Programação Estruturada, C++, Engenharia de Software I,

Linguagem e Técnicas de Programação.
ABSTRACT

Based on the language and programming techniques, software engineering I

and research on books on the C++ programming language, we developed the project
called for in this PIM IV, which consists of the creation of a theater ticket sales system
that provides 50% of discount for students, children from 2 to 12 years, adults from 60
and teachers of the public network. The system should also allow the sale of tickets
with 100% discount for children in need of the public network on Tuesdays. The system
also needs to display the ticket with the name of the piece, date, time and number of
the chair, the availability of armchairs and prevent duplication of the same for the piece.
We will also develop functionalities for cash management by recording all the day’s
movements and the closing balance.

Keywords: Structured Programming, C++, Software Engineering I, Language and

Programming Techniques.
SUMÁRIO

1. Introdução ............................................................................................................. 7
2. Desenvolvimento .................................................................................................. 7
2.1. Programação estruturada .................................................................................. 7
2.1.1 Linguagem C ..................................................................................................... 8
2.1.2 Caso de teste 2 ................................................................................................. 9
2.1.3 Caso de teste 3 ............................................................................................... 10
2.1.4 Caso de teste 4 ............................................................................................... 11
2.1.5 Caso de teste 5 ............................................................................................... 12
2.1.6 Caso de teste 6 ............................................................................................... 14
2.1.7 Caso de teste 7 ............................................................................................... 15
2.1.8 Caso de teste 8 ............................................................................................... 17
2.1.9 Caso de teste 9 ............................................................................................... 18
2.1.10 Caso de teste 10 ............................................................................................ 20
2.2. Relatório de analises dos resultados ............................................................... 21
2.3. Avaliação heurística ........................................................................................ 22
2.3.1 Visibilidade do estado do sistema ................................................................... 22
2.3.2 Correlação entre o sistema e o mundo real ..................................................... 22
2.3.3 Liberdade e controle do usuário ...................................................................... 23
2.3.4 Consistência e padrões ................................................................................... 23
2.3.5 Prevenção de erros ........................................................................................ 23
2.3.6 Reconhecimento em vez de memorização ...................................................... 23
2.3.7 Flexibilidade e eficiência de uso ...................................................................... 24
2.3.8 Projeto estético e minimalista .......................................................................... 24
2.3.9 Suporte para o usuário no reconhecimento, no diagnóstico e na recuperação
de erros ..................................................................................................................... 24
2.3.10 Ajuda na documentação ................................................................................. 24
2.4 Relatório de falhas de usabilidade heurísticas .................................................... 24
2.4.1 Falha número 1 ............................................................................................... 25
2.4.2 Falha número 2 ............................................................................................... 26
2.4.3 Falha número 3 ............................................................................................... 27
2.4.4 Falha número 4 ............................................................................................... 28
2.4.5 Falha número 5 ............................................................................................... 29
2.5 Avaliação global .................................................................................................. 29
3. Conclusão ........................................................................................................... 30
4. Referências......................................................................................................... 31
 7

1. INTRODUÇÃO
Nesta fase do curso, já conseguimos ter uma boa noção da complexidade e
alto custo para se desenvolver um software sob medida para gerenciar um
determinado tipo de negócio, vimos que existem diversas fases e vários tipos de
profissionais envolvidos na concepção do projeto, tais como, engenheiros de software,
analista de requisitos, programadores, testadores, gerente de projetos, entre outros.
Vimos também que para o desenvolvimento é necessário passar por vários processos
como a organização do projeto, programação, testes e implementação e por muitas
vezes uma série de alterações, possíveis erros e implementações de novas
funcionalidades podem atrasar o trabalho elevando o custo e atrasando o cronograma.
Esse tipo de situação vem desencorajando cada vez mais empresas e pequenos
negócios a utilizarem programas de computador para auxiliarem na gestão e
automatização dos processos que por muitas vezes são executados de modo
“arcaico” por funcionários que estão vulneráveis a erros, gerando retrabalho e
atrasando as operações do negócio.

O investimento em desenvolver um software sob medida para seu negócio

garante agilidade no processo e precisão nas informações salvas gerando resultado
a erro zero, caso o código fonte esteja correto.

1.1. Programação estruturada

O conceito de programação estruturada surgiu em 1966 apresentado por
Corrado Bohm e Guiseppe Jacopimi. Eles demonstraram que qualquer programa de
computador pode ser escrito com apenas três estruturas: decisões, sequencias e
loops. Mais tarde o modelo desenvolvido por Dijkstra mostra que o desenvolvedor
separa os programas em subseções, cada um com apenas um ponto de acesso e um
ponto de saída.

Diferente da programação orientada a objetos, esse modelo de programação

tem um menor consumo de memória RAM.
 8

1.2. Programação estruturada

Desenvolvida por Bjarne Stroustrup a linguagem C ++ é uma das linguagens
comerciais mais populares, muito utilizada também nos cursos de ciências da
computação e analise e desenvolvimento de sistemas pela base de utilizadores e
grande desempenho. Ela possui recursos de programação imperativos, orientado a
objetos e genéricos. C ++ e executado em muitas plataformas, como Windows,
Linux, Mac, etc.

No projeto a seguir utilizaremos a linguagem C ++ compilada no software

DEV C++ e toda sua interface será exibida com o auxílio do MS DOS.

2. DESENVOLVIMENTO

2.1.1 Caso de teste 2

Gerar um artigo para submissão com um autor cadastrado com sucesso
(nenhum campo pode ser branco).

O sistema recebeu todas as informações digitadas pelo usuário e não houve

erros, gerando a tela com o artigo e informações cadastradas como mostra a figura
abaixo.

2.1.2 Caso de teste 3

Gerar um artigo completo com três autores cadastrados com sucesso
(nenhum campo pode ser branco).

O sistema recebeu todas as informações digitadas pelo usuário, como foi

necessário cadastrar três autores, o usuário precisou incluir mais campos clicando no
botão com sinal de mais ao lado da palavra autor, com isso foi necessário também
cadastrar três titulações, três vínculos institucional e três e-mails de contato. Assim
como nos testes anteriores e não houve erros, gerando a tela com o artigo e
informações cadastradas como mostra a figura abaixo.
 9

2.1.3 Caso de teste 4

Gerar um artigo completo com três autores com e-mails inválidos (nenhum
campo pode ser branco).

Neste caso, ao informar os endereços de e-mails inválidos, o usuário recebe

uma mensagem de alerta solicitando endereços válidos e destacando o campo e-mail
na cor vermelha, porém ao clicar no botão gerar, o sistema gera o artigo completo
mesmo com os e-mails errados.

2.1.4 Caso de teste 5

Gere um artigo completo com três autores com os campos de autor em branco.

Para o quinto caso, o campo autor ficou sem receber dados, com isso o
sistema informou o usuário via pop-up o erro e sinalizou em vermelho o campo autor
impossibilitando a geração do artigo.

2.1.5 Caso de teste 6

Gerar um artigo completo com um autor cadastrado com sucesso (nenhum
campo pode ser branco) e limpar os dados sem gerar o artigo.
 10

Para este caso, foi preenchido o formulário completo e utilizado o botão limpar
para deletar as informações digitadas, porém os dados dos campos corpo do texto,
notas e referências bibliográficas não foram apagados.

2.1.6 Caso de teste 7

Gerar um artigo completo com um autor cadastrado com sucesso (nenhum
campo pode ser branco), criando no campo “corpo de texto” um texto com trechos
formatados em negrito, itálico, subscrito, sobrescrito e com texto justificado com
sucesso.

Neste caso de número 7, o usuário inseriu um texto com formatações

utilizando os recursos da própria caixa de texto do sistema.

2.1.7 Caso de teste 8

Gerar um artigo completo com um autor cadastrado com sucesso (nenhum
campo pode ser branco), anexando no campo “corpo do texto” uma imagem de um
arquivo com sucesso.

Visto que no campo de “corpo de texto” não havia nenhum botão para inserção
de imagem, o usuário tentou copiar e colar uma imagem, mas mesmo assim o sistema
não aceitou apresentando a seguinte mensagem.

2.1.8 Caso de teste 9

Gerar um artigo completo com um autor cadastrado com sucesso (nenhum
campo pode ser branco), anexando no campo “Notas” uma URL de um arquivo com
sucesso e criando um texto formatado à esquerda e em negrito.
 11

No caso de número 9, foi inserido no campo “notas” uma URL de um arquivo

em PDF e um texto alinhado à esquerda em negrito, o sistema gerou o relatório sem
erros.

2.1.9 Caso de teste 10

Testes de interface. Além dos casos de testes relacionados às regras de
negócio, será necessário criar os testes relativos ao comportamento técnico da tela
do sistema.

2.1. Relatório de analises dos resultados

Nos testes dos casos 1, 2 e 3 não houve erros pois os dados foram
preenchidos corretamente sem campos em branco, já no caso 4 o campo que
armazena o e-mail de contato do autor possui uma validação que apresenta uma
mensagem de erro ao usuário caso ele informe um endereço de e-mail inválido, porém
nada o impede de gerar o artigo caso ele clique no botão gerar, mesmo com o e-mail
errado. No caso 5 já não é permitido a geração do artigo caso o campo autor esteja
em branco, o sistema sinaliza ao usuário via pop-up a necessidade de verificar o
campo autor e permanece na tela do formulário.

Para testar a funcionalidade de limpeza dos campos no caso 6, foi preenchido

o formulário e utilizado o botão limpar, sem gerar o artigo, neste recurso há uma falha,
 12

todos os campos são apagados menos o corpo do texto, notas e referências

bibliográficas.

Analisando alguns recursos existentes no campo corpo do texto para o caso

7, foi gerado um texto com formatações em negrito, itálico, subscrito, sobrescrito e
alinhamento justificado, não foi possível inserir uma imagem como foi solicitado no
caso 8 pois não há este recurso neste campo. No caso 9 o sistema gerou sem erros
também o artigo pois o campo nota aceita links e formatação por possuir os mesmos
recursos do campo corpo texto.

Os testes de interface e comportamento do sistema foram realizados no caso

10, nesses testes foi verificado algumas falhas do tipo campos que não estão
validados caso o usuário não informe nenhum valor.

Um sistema com muitas falhas, campos sem validação, ausência de

mensagens de orientação ao usuário dificulta muito o trabalho até mesmo do usuário
mais experiente, é de extrema importância desenvolver sistemas que facilita ao
máximo os processos, que sejam de fácil operação, robustos, eficientes, pois temos
que ter em mente que diferentes tipos de usuários vão utiliza-lo.

2.2. Avaliação Heurística

Podemos dizer que uma avaliação heurística nada mais é que uma análise da
interação do homem e computador, o termo avaliação heurística começou a ser
utilizado no início da década de 90 por Jakob Nielsen e Rolf Molich. Nielsen
apresentou dez heurísticas de usabilidade que serão utilizadas para avaliar o sistema
de formatação de artigo acadêmicos disponibilizado pela UNIP.

2.3.1 Visibilidade do estado do sistema

 O sistema apresenta contadores de caracteres fazendo com que o usuário não
ultrapasse a quantidade permitida.
 Quando informado um e-mail inválido o sistema exibe uma mensagem de erro
via pop-up e sinaliza o campo em vermelho.
 Todos os campos exceto corpo do texto, notas e referências bibliográficas
ficam com borda azulada quando está ativo ou recebendo informação.

2.3.2 Correlação entre o sistema e o mundo real

 Botão com sinal de adição (+) para incluir mais autores
 13

 Para excluir os campos inseridos dos autores poderia ser utilizado o sinal de
subtração ( - ) para o usuário compreender a operação contraria de adicionar
mais autores, ao invés de utilizar um X como está no sistema.

2.3.3 Liberdade e controle do usuário

 Após a geração do artigo o usuário não tem a opção de imprimir o documento
gerado através de um botão, sem que ele precise utilizar teclas de atalhos ou
recurso do navegador.
 Dar ao usuário a possibilidade de editar o artigo através de um botão editar ou
voltar para que ele possa retornar a tela inicial e fazer as devidas alterações.

2.3.4 Consistência e padrões

 Não existe uma ordem na demonstração dos erros, por exemplo, ao clicar no
botão gerar deixando os dados do autor em branco, o sistema sinaliza primeiro
o campo e-mail onde o correto seria primeiramente sinalizar o campo nome,
titulação, vínculo institucional e por último seguindo a ordem e-mail.

2.3.5 Prevenção de erros

 Caso o usuário clique no botão limpar por engano nenhuma mensagem de
confirmação aparece para evitar que os dados sejam deletados.
 O sistema possui corretor ortográfico porém ele não funciona nos campos
corpo do texto, notas e referências bibliográficas.
 Quando o usuário informa o e-mail inválido e ignora a mensagem de erro é
possível mesmo assim gerar o arquivo com o e-mail errado.
 A falha no botão limpar, pode levar o usuário a gerar o arquivo com as
informações erradas contidas nos campos corpo do texto, notas e referências
bibliográficas visto que esses campos não estão sendo apagados pelo recurso.

2.3.6 Reconhecimento em vez de memorização

 O sistema é bem intuitivo, simples e possui um fluxo de ação bem definido,
todos os campos possui identificação, para facilitar a operação deveria ser
incluído ícones e placeholder que são exemplos dos dados a serem digitados
dentro dos campos.
 14

2.3.7 Flexibilidade e eficiência de uso

 O sistema poderia ter o recurso de autocomplete a partir de dados preenchidos
anteriormente.
 Utilizar o plugin bootstrap tags input nos campos de palavras-chave e
keywords.

2.3.8 Projeto estético e minimalista

 O sistema possui um layout simples, facilitando o entendimento do usuário,
layouts com muita informação e poluição visual dificulta a utilização.
 O sistema poderia avisar o usuário que alguns campos não estão preenchidos.

2.3.9 Suporte para o usuário no reconhecimento, no diagnóstico e na

recuperação de erros
 As mensagens de erros por pop-up esclarecem de forma clara e simples o que
deve ser feito para corrigir o erro, más acredito que poderia ser incluído em
outros campos de extrema importância como título.

2.3.10 Ajuda e documentação

 Por mais que o sistema seja simples e bem intuitivo ele não possui
documentação disponível nem botão de ajuda para consultar possíveis dúvidas
sobre como operá-lo.

2.3. Relatório de falhas de usabilidade heurísticas

A seguir apresentamos um relatório baseado nas falhas de usabilidade
heurísticas contendo a identificação dos itens envolvidos, uma imagem da tela
demonstrando a violação, avaliação global do sistema inspecionado e o grau de
severidade para cada uma das violações seguindo a tabela abaixo.

Grau de severidade Tipo Descrição

0 Sem importância Não afeta a operação da
interface
1 Cosmético Não há necessidade
imediata de solução
 15

2 Simples Problema de baixa

prioridade (pode ser
reparado)
3 Grave Problema de alta
prioridade (deve ser
reparado)
4 Catastrófico Muito grave, deve ser
reparado de qualquer
forma

2.4.1 Falha número 1

Local da falha: Formulário (Tela inicial).

Descrição da falha: Na tela inicial a faixa do topo de contagem de caracteres não fica
vermelha quando o usuário excede o valor de 42.000 disponíveis como nos campos
resumo e abstract.

Heurística violada: 1 – Visibilidade do estado do sistema.

Grau de severidade: 2 (a cor se mantendo verde pode confundir o usuário e ele não
se atentar que já excedeu o número de caracteres).

2.4.2 Falha número 2

Local da falha: Formulário (Tela inicial).

Descrição da falha: Os campos título, título em inglês, resumo, palavras-chave,

abstract, keywords, corpo do texto, notas e referências bibliográficas não aparecem
nenhuma sinalização de que estão vazias.

Heurística violada: 8 – Projeto estético e minimalista.

Grau de severidade: 2 (sem as informações que os campos estão em branco o

usuário terá que refazer a operação).
 16

2.4.3 Falha número 3

Local da falha: Formulário (Tela inicial).

Descrição da falha: Os campos autor, titulação, vínculo institucional e e-mail do

contato são obrigatórios e sinalizados via pop-up que precisam ser preenchidos, más
se deixar todos os campos em branco e o usuário tentar gerar o artigo o sistema
sinaliza primeiro e campo e-mail, neste caso ele poderia seguir a ordem dos campos,
primeiro autor, titulação, vinculo institucional e por último e-mail.

Heurística violada: 4 – Consistência e padrões.

Grau de severidade: 3 (como esta informação é obrigatória e de extrema importância

a correção deste problema).

3. CONCLUSÃO
Para diferentes tipos de operações e a .
 17

4. REFERÊNCIAS
SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Pearson. 2013

Techopedia. Structure Programming

Disponível em: https://www.techopedia.com/definition/16413/structured-

programming. Acesso 20 de maio de 2019.