PIM IV - LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK

Prévia do material em texto

UNIP EAD 
PROJETO INTEGRADO MULTIDISCIPLINAR PIM IV CURSOS 
SUPERIORES DE TECNOLOGIA 
 
 
 
 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE UM SISTEMA EM LINGUAGEM C 
 
 
 
 
 
 
 
SUPERIOR TÉCNICO EM ANALISE E DESENVOLVIMENTO DE 
SISTEMAS 
 
 
 
 
 
 UNIP EAD SÃO GABRIEL DA CACHOEIRA 
2020 
 
 
 
UNIP EAD 
 
SUPERIOR TÉCNICO EM ANALISE E DESENVOLVIMENTO DE 
SISTEMAS 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE UM SISTEMA EM LINGUAGEM C 
 
 
 
 
 
 
 
 
 
 DIONES SAMPAIO ARAÚJO RA:1975397 
 
 
 
 
 
 
 
 
 
 
EAD SÃO GABRIEL DA CACHOEIRA 
2020
 
 
 
SUPERIOR TÉCNICO EM ANALISE E DESENVOLVIMENTO DE 
SISTEMAS 
 
 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE UM SISTEMA EM LINGUAGEM C 
 
 
 
 
 
 
 
 
Projeto integrado multidisciplinar Apresentado 
à Unip Ead como exigência do curso de 
superior técnico em análise e desenvolvimento 
de sistemas. 
 Orientador: Profa. Vanessa Lessa 
 
 
 
 
 
 
EAD SÃO GABRIEL DA CACHOEIRA 
2020 
https://ava.ead.unip.br/webapps/blackboard/execute/courseMain?course_id=_37709_1
 
 
 
RESUMO 
 
O presente projeto integrado multidisciplinar que está inserido no programa 
pedagógico dos cursos superiores de tecnologia da Universidade Paulista, consiste 
na elaboração um Desenvolvimento de um Sistema em Linguagem C, utilizada 
mediante das técnicas aprendidas. A elaboração será baseada conforme nos 
conhecimentos adquiridos nas disciplinas de: Linguagem e Técnicas de Programação, 
Engenharia de Software I. Com a organização da tabela de vendas de ingressos de 
teatro para contemplar valores para estudantes, crianças, adultos e professores da 
rede pública de ensino, adotada os métodos da linguagem C para o desenvolvimento 
de sistema. 
 
 
Palavras chaves: Sistema, Venda, Escola 
 
 
 
 
 
 
 
ABSTRACT 
 
 The present integrated multidisciplinary project that is inserted in the pedagogical 
program of the higher technology courses at the Universidade Paulista, consists of the 
elaboration of a Development of a System in Language C, used through the techniques 
learned. The preparation will be based on the knowledge acquired in the disciplines of: 
Language and Programming Techniques, Software Engineering I. With the 
organization of the theater ticket sales table to contemplate values for students, 
children, adults and public school teachers , C language methods were adopted for 
system development. 
 
 
Keywords: System, Sale, School 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO....................................................................................................6 
2. TÍTULO................................................................................................................6 
3. DESENVOLVIMENTO DE SISTEMA EM LINGUAGEM C.................................6 
4. MODELO DE PROCESSO..................................................................................7 
4.1. DESENVOLVIMENTO ÁGIL........................................................................................8 
4.1.2 MODELAGEM.....................................................................................................9 
 
4.1.3 METODOLOGIA................................................................................................11 
4.2 ESCOPO...........................................................................................................11 
4.2.1 MODELAGEM...................................................................................................12 
 
5.0 TELAS DO SISTEMA........................................................................................14 
 
5.1 CONFIGURAÇÃO DO SISTEMA......................................................................14 
 
5.2 ADICIONAR CARTAZ.......................................................................................15 
 
5.3 EXIBIR CARTAZ...............................................................................................16 
 
5.4 COMPRAR INGRESSO....................................................................................16 
 
5.5 HISTORICO DO CAIXA....................................................................................19 
 
5.6 REGRAS DO SISTEMA....................................................................................20 
 
CONCLUSÃO.............................................................................................................26 
 
REFERÊNCIAS..........................................................................................................27 
 
 
6 
 
 
1. INTRODUÇÃO 
 
 O Projeto Integrado Multidisciplinar IV, é um trabalho que consiste em apresentar 
todas as disciplinas estudadas no bimestre. O presente trabalho visa em descrever as 
todas práticas que envolva as etapas de desenvolvimento de um sistema de venda de 
ingressos de teatro para inserida no polo da UNIP, pesquisado conforme nos livros, 
sites, abordadas pelas disciplinas de: Linguagem e Técnicas de Programação; 
Engenharia de Software I. A necessidade do teatro apresentado é tão grande na 
organização de vendas de ingressos específicos aos telespectadores e aos demais 
públicos. Para alcançar objetivos foi possível organizar os valores de ingresso ao 
teatro, dos estudantes, alunos e professores, utilizadas as técnicas do projeto de 
desenvolvimento de um sistema em linguagem C, como a metodologia, a modelagem 
e algoritmos mais relevantes para a viabilidade da solução. Neste sentido 
possibilitando em trazer uma interface amigável nos limites de soluções DOS, 
mensagens de validação de entradas, evoluções permitidas com pouco impactos. 
 
2. TÍTULO 
 
Sistema de Venda de Ingressos de Teatro. 
 
 
3. DESENVOLVIMENTO DE SISTEMA EM LINGUAGEM C 
 
 Para iniciarmos o Desenvolvimento de sistema em linguagem C, foi considerado 
na instituição do polo UNIP em obter uma sala de teatro, com esta implantação na 
estrutura da unidade, obteve a necessidade de um sistema de venda, com suas 
respectivas projeções de atendimento aos telespectadores, estudantes, crianças, 
adultos, e professores da rede pública e ao demais simpatizantes da unidade. Ao 
deparar com os requisitos, a equipe do PIM IV ficou responsável do projeto de 
implantar sistema de venda de ingressos. 
Para chegar até o cenário de se vender um ingresso uma série de etapas anteriores 
deve ser realizada, tal como capacidade de assentos do teatro, peças em cartaz, valor 
dos ingressos, entre outros. Para melhor compreensão segue os passos e tomada de 
uma orientação que elucida como realizar o projeto adotada a engenharia de software 
como norteadora. Por esta razão com o intuito de buscar embasamento teórico e 
7 
 
 
fundamentar o conhecimento produzido, foi realizada o desenvolvimento de sistema 
de venda de ingressos para instituição da UNIP. 
 
4. MODELO DE PROCESSO 
Um modelo de processo genérico para engenharia de software consiste num 
conjunto de atividades metodológicas e de apoio, ações e tarefas a realizar. Cada 
modelo de processo, dentre os vários existentes, pode ser descrito por um fluxo de 
processo diferente. Descrição de como as atividades metodológicas, ações e tarefas 
são organizadas sequencial e cronologicamente. Segundo (AMBLER, 98) padrões de 
processo são utilizados para resolver problemas comuns encontrados como parte do 
processo de software. 
Os modelos de processo prescritivos são aplicados há anos, num esforço para 
organizar e estruturar o desenvolvimento de software. Cada um desses modelos 
sugere um fluxo de processosligeiramente diferente, mas todos realizam o mesmo 
conjunto de atividades metodológicas genéricas: comunicação, planejamento, 
modelagem, construção e emprego. 
Os modelos de processo sequenciais, tais como o de cascata e o modelo V, são 
os paradigmas da engenharia de software mais antigos. Eles sugerem um fluxo de 
processos linear que, frequentemente, é inadequado para considerar as 
características dos sistemas modernos (por exemplo, contínuas alterações, sistemas 
em evolução, prazos apertados). Entretanto, eles têm, realmente, aplicabilidade em 
situações em que os requisitos são bem definidos e estáveis. 
Modelos de processos incremental são iterativos por natureza e produzem 
rapidamente versões operacionais do software. Modelos de processos evolucionários 
reconhecem a natureza iterativa e incremental da maioria dos projetos de engenharia 
de software e são projetados para adequar mudanças. Esses modelos, como 
prototipação e o modelo espiral, produzem rapidamente artefatos de software 
incrementais (ou versões operacionais do software). Podem ser adotados para ser 
aplicados por todas as atividades de engenharia de software desde o desenvolvimento 
de conceitos até a manutenção do sistema a longo prazo. 
Modelo de processo concorrente possibilita que uma equipe de software 
represente elementos iterativos e concorrentes de qualquer modelo de processo. 
Modelos especializados incluem o modelo baseado em componentes (que enfatiza a 
8 
 
 
montagem e a reutilização de componentes); o modelo de métodos formais (que 
encoraja uma abordagem matemática para o desenvolvimento e a verificação de 
software); e o modelo orientado a aspectos (que considera interesses cruzados que 
se estendem por toda a arquitetura do sistema). O Processo Unificado é um processo 
de software “dirigido a casos práticos, centrado na arquitetura, iterativo e incremental”, 
desenvolvido como uma metodologia para os métodos e ferramentas da UML. 
 
4.1 DESENVOLVIMENTO ÁGIL 
 
Em uma economia moderna, as condições de mercado mudam rapidamente, 
tanto o cliente quanto o usuário final devem evoluir e novos desafios competitivos 
surgem sem aviso. Os desenvolvedores têm de assumir uma abordagem de 
engenharia de software para permitir que permaneçam ágeis — definindo processos 
que sejam manipuláveis, adaptáveis, sem excessos, somente com o conteúdo 
essencial que possa adequar-se às necessidades do moderno mundo de negócios. 
Uma filosofia ágil para a engenharia de software enfatiza quatro elementos-chave: 
a importância das equipes que se auto organizam, que tenham controle sobre o 
trabalho por elas realizado, sobre a comunicação e sobre a colaboração entre os 
membros da equipe e entre os desenvolvedores e seus clientes; o reconhecimento de 
que as mudanças representam oportunidades e ênfase na entrega rápida do software 
para satisfazer o cliente. 
A Extreme Programming (XP) é o processo ágil mais amplamente utilizado. 
Organizada em quatro atividades metodológicas, planejamento, projeto, codificação e 
testes, a XP sugere um número de técnicas poderosas e inovadoras que possibilitam 
a uma equipe ágil criar versões de software frequentemente, propiciando recursos e 
funcionalidade estabelecidos anteriormente, e, então, priorizando os envolvidos. 
Outros modelos de processos ágeis também enfatizam a colaboração humana e 
a auto-organização das equipes, mas definem suas próprias atividades metodológicas 
e selecionam diferentes pontos de ênfase. Por exemplo, segundo (HIGHSMITH, 2000) 
ASD usa um processo iterativo que incorpora um planejamento cíclico iterativo, 
métodos de levantamento de requisitos relativamente rigorosos, e um ciclo de 
desenvolvimento iterativo que incorpora grupos focados nos clientes e revisões 
técnicas formais como mecanismos de feedback em tempo real. De acordo com 
9 
 
 
(SCHWABER, 2001) O Scrum enfatiza o uso de um conjunto de padrões de software 
que se mostrou efetivo para projetos com cronogramas apertados, requisitos mutáveis 
e aspectos críticos de negócio. Cada padrão de processo define um conjunto de 
tarefas de desenvolvimento e permite à equipe Scrum construir um processo que se 
adapta às necessidades do projeto. O método de desenvolvimento de sistemas 
dinâmicos (DSDM) (STAPLETON, 1997) defende o uso de um cronograma de tempos 
definidos (janela de tempo) e sugere que apenas o trabalho suficiente seja requisitado 
para cada incremento de software para facilitar o movimento ao incremento seguinte. 
Crystal (COCKBURN,2005) é uma família de modelos de processos ágeis que podem 
ser desenvolvidos para uma característica específica de um projeto. 
O desenvolvimento dirigido a funcionalidades (FDD) é ligeiramente mais “formal” 
que os outros métodos, mas ainda mantém agilidade ao focar a equipe do projeto no 
desenvolvimento de funcionalidades validadas pelo cliente que possam ser 
implementadas em duas semanas ou menos (PALMER, 2002). O desenvolvimento de 
software enxuto (LSD) adaptou os princípios de uma fabricação enxuta para o mundo 
da engenharia de software. A modelagem ágil afirma que modelagem é essencial para 
todos os sistemas, mas a complexidade, tipos e tamanhos de um modelo devem ser 
balizados pelo software a ser construído. Segundo (AMBLER, 2006) o processo 
unificado ágil (AUP) adota a filosofia de “serial para o que é amplo” e “iterativa para o 
que é particular” para o desenvolvimento de software. 
 
4.1.2 MODELAGEM 
A prática de engenharia de software envolve princípios, conceitos, métodos e 
ferramentas aplicados por engenheiros da área ao longo de todo o processo de 
desenvolvimento. Cada projeto de engenharia de software é diferente. Ainda assim, 
uma gama de princípios genéricos se aplica ao processo como um todo e à prática de 
cada atividade metodológica independentemente do projeto ou do produto. 
Um conjunto de princípios essenciais auxilia na aplicação de um processo de 
software significativo e na execução de métodos efetivos de engenharia de software. 
Quanto ao processo, os princípios essenciais estabelecem uma base filosófica que 
orienta a equipe durante essa fase de desenvolvimento. Quanto ao nível relativo à 
prática, os princípios estabelecem uma série de valores e regras que servem como 
10 
 
 
guia ao se analisar um problema, projetar uma solução, implementar e testar uma 
solução e, por fim, disponibilizar o software para a sua comunidade de usuários. 
Princípios de comunicação enfatizam a necessidade de reduzir ruído e aumentar 
a dimensão conforme o diálogo entre o desenvolvedor e o cliente progride. Ambas as 
partes devem colaborar para que ocorra a melhor comunicação. 
Princípios de planejamento proporcionam roteiros para a construção do melhor 
mapa para a jornada rumo a um sistema ou produto completo. O plano pode ser 
projetado para um único incremento de software ou pode ser definido para o projeto 
inteiro. Independentemente da situação, deve indicar o que será feito, quem o fará e 
quando o trabalho estará completo. 
Modelagem abrange tanto análise quanto projeto, descrevendo representações 
do software que se tornam progressivamente mais detalhadas. O objetivo dos 
modelos é solidificar a compreensão do trabalho a ser feito e providenciar orientação 
técnica aos implementadores do software. Os princípios de modelagem servem como 
infraestrutura para os métodos e para a notação utilizada para criar representações 
do software. 
Construção incorpora um ciclo de codificação e testes no qual o código-fonte 
para um componente é gerado e testado. Os princípios de codificação definem ações 
genéricas que devem ocorrer antes da codificação ser feita, enquanto está sendo 
criada e após estar completa. Embora haja muitos princípios de testes, apenas um é 
dominante: teste consiste em um processo de execução de um programa com o intuito 
de encontrar um erro. 
Disponibilização ocorre na medida em que cada incrementode software é 
apresentado ao cliente e engloba a entrega, o suporte e o feedback. Os princípios 
fundamentais para a entrega consideram o gerenciamento das expectativas dos 
clientes e o fornecimento ao cliente de informações de suporte apropriadas sobre o 
software. O suporte exige preparação antecipada. 
Feedback permite ao cliente sugerir mudanças que tenham valor agregado e 
fornecer ao desenvolvedor informações para o próximo ciclo de engenharia de 
software. 
 
 
 
11 
 
 
4.1.3 METODOLOGIA 
 
O desenvolvimento do presente trabalho que consiste na elaboração de um 
sistema de vendas de ingressos para um teatro empregado o método AUP, com o 
propósito de buscar conhecimento e alcançar os objetivos propostos. 
O AUP é uma versão simplificada do RUP (Rational Unified Process). Descreve 
uma abordagem simples e fácil de entender para o desenvolvimento de aplicações de 
software de negócio usando técnicas ágeis e conceitos do RUP. Nessa abordagem, 
tenta-se manter o Agile Unified Process o mais simples possível. Compreende 4 fases 
seriais (Concepção, Elaboração, Construção e Transição) e 7 atividades iterativas 
(modelagem, implementação, testes, Implantação, Gerenciamento de configuração, 
Gerenciamento de Projeto, Ambiente). 
 
 4.2 ESCOPO 
Mediante a pesquisa forneceu os insumos necessários para o desenvolvimento 
do projeto, também deixou em abertos alguns pontos do projeto importantes como: O 
Sistema é para um único Teatro? O Teatro possui mais de uma sala? Devem-se 
distinguir as vendas feitas em dinheiro das feitas em cartão? O sistema deve 
considerar vendas de ingresso feitas em outros pontos comerciais (mercados, lojas, 
entre outros). Portanto para fechar um escopo algumas decisões de projeto foram 
realizadas dentro do que estava em aberto para definir o produto a ser desenvolvido. 
Das decisões de projeto definiu-se o seguinte: 
● O Sistema de Venda de Ingresso será projetado para um único teatro e não 
para uma rede; 
● O Teatro possuirá uma única sala de apresentação; 
● Todos os dados serão trabalhados em memória, logo, esse sistema não 
trabalhará com banco de dados tampouco com sistema de armazenamento de dados 
em arquivos; 
● O escopo do sistema será a gestão somente dos ingressos vendidos pelo 
sistema; 
● Não se fará distinção se a compra do ingresso foi realizada por dinheiro ou 
cartão; 
● O número de poltrona é gerado automaticamente pelo sistema, ou seja, não 
há uma interface onde o usuário escolhe seu assento; 
12 
 
 
● O sistema apresentará uma interface onde o operador do sistema poderá 
cadastrar as informações de sistema como lotação do teatro e preços; 
● O sistema apresentará uma interface onde o operador do sistema poderá criar 
o cartaz de exibição do teatro, ou seja, as peças em exibição; 
● O sistema apresentará uma interface para realizar a venda de ingressos; 
● O sistema apresentará uma interface para exibir o histórico do caixa do dia. 
A IDE de desenvolvimento, exigência do projeto, utilizada foi o Dev C++. A 
versão utilizada nesse projeto foi a 5.11, build de 27 de abril de 2015 baixada no site 
da bloodshed (http://www.blodshed.net) e o compilador do código fonte foi o TDM-
GCC do site (http://www.tdm-gcc.tdragon.net/). 
 
4.2.1 MODELAGEM 
No Processo Unificado Ágil (Agile Unified Process – AUP) a modelagem consiste 
de representações UML do universo do negócio e do problema, contudo segundo 
(AMB 2006) para permanecerem ágil estas representações devem ser 
suficientemente boas e adequadas. 
Apesar da modelagem UML está fortemente relacionada com o conceito de 
objetos e por isso está muito próxima das linguagens orientadas a objetos, ela permite 
distinguir as principais entidades do sistema e seus relacionamentos. 
Assumindo que um dos valores que se procurar agregar nessa solução é sua 
adaptação a futuras melhorias com o menor impacto possível a modelagem UML pode 
trazer luz nesse quesito deixando claras as entidades envolvidas no sistema e 
deixando a cargo da linguagem e da tecnologia adotada a melhor forma de programá-
las. 
Da Análise do problema exposto modelou-se duas entidades principais TPeca e 
TTicket (Tabela 1). 
TPca TTicket 
-id 
-Tdata 
-nome 
-cont 
 -id 
-id_peca 
-poltrona 
-tp_ingresso 
 
1..* 
0...* 
+criar 
-exibir 
 +criar 
-imprimir 
Tabela 1: Modelagem UML das principais entidades. 
http://www.blodshed.net/
http://www.tdm-gcc.tdragon.net/
13 
 
 
A linguagem C não é orientada a objetos, mas permite a criação de classes e 
uma possível implementação para a modelagem da Figura 1 seria criar duas classes.h 
com definições da classe e suas respectivas classes c com as implementações dos 
métodos. Porém, por simplificação e não ter que alterar o Makefile do DevC++ para 
compilar mais de uma classe para passar os arquivos objetos .o e linkar com o arquivo 
principal para gerar o executável, trabalho este que pode funcionar em algumas IDEs 
e compiladores, e em outras não conforme configuração, optou-se por uma 
abordagem mais simples e implementou-se as entidades todas no arquivos principal 
para que o código fonte fosse facilmente copilado por qualquer usuário com qualquer 
nível de experiência na linguagem C e na IDE Dev C++. 
 
 
Figura 1: Implementação de entidades como estrutura em C. 
 
A ideia principal desse sistema é assim que configurada todas as variáveis do 
sistema trabalhar com uma coleção de peças que são selecionadas pelos usuários na 
hora de efetuar uma compra de ingresso, atendidas as condições para venda a 
estrutura Ticket é instanciada com as informações necessárias para impressão. 
Foram criadas duas estruturas auxiliares para armazenamento da data hora da 
sessão de exibição da peça e outra estrutura para armazenar os valores dos diferentes 
tipos de ingresso (inteira e meia). 
 
 
 
 
14 
 
 
5.0 TELAS DO SISTEMA 
A interface inicial do sistema apresenta 6 (seis) opções ao usuário: 
1. Configuração do Sistema: Nessa opção o usuário define as variáveis 
de operação do sistema como capacidade de lotação do teatro e valores dos ingressos 
na modalidade inteira e meia. 
2. Adicionar Cartaz: Nessa opção o operador do sistema insere quantas 
peças estão em cartaz e os principais dados delas como data de exibição, nome, 
sessão (horário que será exibida) 
3. Exibir Cartaz: Opção que exibe todas as peças que foram adicionadas 
ao cartaz que estão em exibição (pode-se vender ingressos) 
4. Comprar Ingressos: Opção que operacionaliza a Compra/Venda de 
Ingressos 
5. Histórico do Caixa do Dia: Opção que exibe em tela um extrato com 
todas as operações de caixa (entradas e saídas) e no fim exibe o correspondente 
saldo desse histórico. 
6. Sair: Opção para saída do sistema. 
 
Tela Inicial. 
 
 
5.1 CONFIGURAÇÕES DO SISTEMA 
 Na tela abaixo vemos a interface onde se define a capacidade de lotação do teatro. 
Tão logo essa informação é processada o sistema pede para se fornecer a tabela de 
preços dos ingressos. 
15 
 
 
 
Configuração do sistema definindo a capacidade do teatro 
 
 
 
 
 
 
 
 
 
 
Valores do Ingressos 
 
5. 2 ADICIONAR CARTAZ 
Na opção de Adicionar Cartaz é solicitado primeiramente o fornecimento da 
quantidade de peças que serão adicionadas e sequencialmente o preenchimento de 
cada uma das informações da peça conforme ilustrado. 
16 
 
 
Tela de cadastro de peças 
 
5.3. EXIBIR CARTAZ 
 
A Tela de exibição de cartaz mostra todas as peças em exibição e suas principais 
informações em ordem de inserção, cada peça possui um identificador global único 
que a distingue no sistema. 
 
 
5.4. COMPRAR INGRESSO 
 
 Na compra de ingressos o sistema lista as peças em exibição para que se selecione 
aquela que se deseja comprar o ingresso conforme abaixo. 
 
 
 
17 
 
 
Tela de compra de ingressos. 
 
 
Após a seleção da peça o usuário deve optar por uma modalidade deingresso: 
inteira, meia ou gratuita conforme os requisitos de projeto. 
Tela de compra de ingressos 
 
 
 
 
 
 
 
 
18 
 
 
Em seguida o sistema aguarda que se informe quanto foi dado para pagamento 
do ingresso para calcular o troco e finalizar a compra. 
Tela de compra de ingressos 
 
 
 
19 
 
 
 Depois de realizada a compra conforme requisito do projeto o sistema 
imprime o ticket com as informações da peça. 
 
 
 
5.5. HISTORICO DO CAIXA 
A opção de histórico do caixa do dia registra todas os lançamentos de caixa, ou 
seja, entradas e saídas e as exibe como em um extrato de banco no fim desse extrato 
é exibido o saldo do caixa. 
Tela de extrato e saldo do caixa 
 
 
20 
 
 
5.6. REGRAS DO SISTEMA 
 O problema proposto tem em suas especificações algumas regras que precisaram 
ser atendidas a primeira delas é a tabela de preços que foi tratada nessa solução por 
meio de uma estrutura de dados e ilustrado. Além disso, uma série de validações 
foram implementadas para cumprir as regras que comtemplam a meia-entrada. Para 
avaliar em qual categoria o usuário se enquadra o sistema solicita as informações de 
número de carteira (para estudantes e professores da rede pública de ensino) e idade 
para classifica-los como estudante, criança de 0-12 anos, adultos com mais de 60 
anos conforme ilustrado. 
 Telas do sistema validando os critérios para contemplar a meia-entrada. 
 
 
21 
 
 
Tanto a carteira nacional do estudante como a carteira nacional do professor são 
formadas por uma sequência de 12 dígitos sendo os dois primeiros letras do alfabeto 
e os 10 seguintes dígitos decimais. Como não temos acesso ao algoritmo de validação 
dessa sequência de caracteres só foi possível validar o layout (Figura 14), ou seja, se 
o tamanho é 12 e da forma [a-Z][a-Z] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] 
[0-9]. 
Código fonte para validação do número da Carteira Nacional do Professor. 
 
 
 
Outra regra também predefinida é a contemplação de ingresso com 100% de 
desconto para crianças carente da rede pública de ensino às terças feiras. Aqui 
encontrou-se uma dificuldade que é como definir que a criança é carente então por 
decisão de projeto como não se tem os instrumentos necessários para fazer essa 
checagem validamos se o comprador do ingresso é uma criança da rede pública de 
ensino e para tal precisou-se apenas solicitar a data de nascimento para certificar que 
é uma criança (aqui adotamos como critério a idade inferior a 18 anos como condição 
suficiente) e a carteirinha nacional do estudante (para certificar que pertence a rede 
pública de ensino) a última condição que se verificou é se o dia é uma terça-feira já 
que o desconto só é válido para esse dia da semana. A lógica de programação pode 
ser consultada. 
 
 
 
 
 
22 
 
 
Código que valida a contemplação de ingresso com 100% de desconto 
 
No trecho de código, faz-se a chamada a duas funções a valida_carteira() e a 
calcula_idade(). A função calcula_idade() cujo código pode ser, solicita a data de 
nascimento do comprador e compara com a data atual do sistema retornando a idade 
em anos (valor inteiro). 
Note que a função valida todas as entradas do usuário para certificar que os valores 
fornecidos para dia são válidos e dentro do intervalo de [1-31], o mesmo para mês 
cujo intervalo é de [1-12] e quanto ao ano não são aceitos somente valores positivos 
e não superiores ao ano atual do sistema. Para a comparação da entrada do usuário 
com a data atual do sistema utilizou-se a struct tm da biblioteca <time.h> essa struct 
contém vários membros para cada componente da data hora como listado a seguir: 
● tm_sec: segundo após o minuto, intervalo de 0 a 60; 
● tm_min: minutos após a hora, intervalo de 0 a 59; 
● tm_hour: horas desde a meia-noite, intervalo de 0 a 23; 
● tm_mday: dia do mês, intervalo de 1 a 31; 
● tm_mon: meses desde janeiro, intervalo de 0 a 11; 
● tm_year: anos desde 1900 
● tm_wday: dias da semana desde domingo, intervalo de 0 a 6; 
● tm_yday: dias desde 1 de janeiro, intervalo de 1 a 365; 
tm_isdst: flag pra horário de verão, 0 se não estiver em uso e maior que zero 
caso contrário. 
23 
 
 
Trecho do código da funcão calcula_idade(). 
 
No código para comparar o ano somamos à variável p_fim->tm_year 1900 que 
é exatamente a quantidade de anos que tm_year não conta (conta desde 1900 até 
hoje). Também como o intervalo de mês é de 0 a 11 somamos 1 para que a 
comparação de mês fique correta. 
O algoritmo primeiramente calcula a diferença de anos e depois checa o mês para ver 
se precisa diminuir o valor uma vez que se o mês de nascimento for menor que o mês 
atual significa que ainda vai completar aquela idade e que atualmente a idade é a 
diferença de anos menos 1. O mesmo acontece quando o mês de aniversário do 
comprador coincide com o mês do sistema, devemos verificar o dia, se o dia de 
aniversário do comprador for menor que o dia atual do sistema também devemos 
subtrair 1 ao cálculo. 
Outra regra explícita do requisito do sistema é concernente a emissão de ticket 
que deve apresentar uma gama de informações geradas pelo sistema. Por 
discricionariedade não foi adicionado uma interface para o comprador escolher o seu 
assento o sistema escolhe o assento automaticamente. Todas as demais regras de 
24 
 
 
limites como não vender mais ingressos para peças com lotação esgotada foram 
implementadas conforme ilustrado. 
Regras de Limite implementadas no sistema. 
 
A última requisição do sistema consistia na gestão do caixa onde o sistema deve 
informar todas as movimentações do dia e o saldo do fechamento. Esse controle foi 
realizado no sistema por meio de um vetor float *extrato, que é preenchido a medida 
que um ingresso é vendido com sucesso, sendo inserido no vetor os valores entrados 
em caixa (valor de pagamento) e os valores de saída, isto é, o troco, calculados 
conforme o tipo do ingresso, no caso do troco os valores são armazenados com o 
25 
 
 
valor negativo. Essa escolha foi para facilitar a impressão do extrato do dia podendo 
assim distinguir os lançamentos de crédito ( C ) dos lançamentos de débito ( D ), outra 
vantagem dessa adoção é que o saldo consiste simplesmente da soma dos elementos 
desse vetor. 
Tela de lançamentos do dia do caixa. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
26 
 
 
CONCLUSÃO 
 
 Esse projeto ponderou as técnicas, engenharia de software para o 
desenvolvimento de um sistema de venda de ingressos para teatro implantada no polo 
da UNIP. Conforme das pesquisas adotadas, foram aplicadas da metodologia AUP 
(Agile unifield Process) por ser um meio termo entre o desenvolvimento procedural e 
o Ágil. Após ser compreendida da metodologia e etapas, houve a possível 
identificação nos elementos e especificação dos requisitos para modelação do 
sistema. 
E implementando na melhoria das validações de entrada de console, interface com o 
usuário, adaptação na estrutura de dados para aceitar mais de um teatro, e adição 
que cada teatro tenha mais de uma sala. 
Na interface gráfica, foi aprofundada na pesquisa sobre o ncurses, para que tenha o 
melhor desempenho nas maquinas Linux, unix, e sua implementação para o Windows 
o ipcurses, foram aplicados alguns testes de interface com resultado do sistema bem 
amigável, e com código totalmente ilegível. Com as dificuldades encontradas no 
isolamento da parte do código em classes para não deixar o restante do código mais 
compreensível, foi optado por nessa versão não trabalhar com elas, outra razão 
também para não adotar essa biblioteca foi que ela só funcionou para versões antigas 
do Dev C++. O lpcurses pode ser encontrado no sourceforge no projetoDevPacks mas 
está descontinuado. 
Nos outros aspectos relevantes é que, nesse projeto foi possível aprofundar os 
conhecimentos multidisciplinares engenharia de software, lógica de programaçãoe 
da linguagem C propriamente dita. 
Pois os mesmos foram apreendidos inúmeras formas diferentes de se fazer validação 
de entrada do console, estilos de programação e ainda despertou um novo olhar para 
as necessidades da instituição da UNiP, concretizado no desenvolvimento de um 
sistema de vendas de ingressos de teatro. 
 
 
 
 
 
REFERÊNCIAS 
 
Internet 
 
AMBLER, S., Process Patterns: Building Large-Scale Systems Using Object 
Technology, 1st ed.: Cambridge University Press, 1998. 582 p. 
AMBLER, S., “The Agile Unified Process (AUP)”, 2006. Disponível em: 
<www.ambysoft.com/ unifiedprocess/agileUP.html>. Acesso em: 10/10/2019. 
BAETJER, Jr., H., Software as Capital: An Economic Perspective on Software 
Engineering, 1st ed.: IEEE Computer Society Press, 1997, p. 85. 
COCKBURN, A., Crystal Clear: A Human Powered Methodology for Small Teams 
(Agile Software Development Series), 1st ed.: Addison-Wesley, 2005. 
HIGHSMITH, J., Adaptive Software Development: An Evolutionary Approach to 
Managing Complex Systems: Dorset House Publishing, 2000. 
PALMER, S.; FELSING, J., A Practical Guide to Feature Driven Development, 1st 
ed.: Prentice Hall, 2002, 304 p. 
SCHWABER, K.; BEEDLE, M., Agile Software Development with SCRUM, 1st ed.: 
Pearson, 2001, 176 p. 
STAPLETON, J., DSDM Dynamic System Development Method: The Method in 
Practice, 1st ed.: Addison-Wesley, 1997, 192 p.