PIM V - Análise e Desenvolvimento de Sistemas

Prévia do material em texto

2
UNIVERSIDADE PAULISTA - UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia
KAIQUE VINICIUS LIMA ALBANO – RA: 2071753
ALEXANDRE GUSTAVO LONGHI – RA: 2064482
FÁBIO CAMPOS BARRETO – RA: 2057861
JOÃO CARLOS ARAÚJO AZEVEDO – RA: 2071048
JEAN PEREIRA LOURENÇO – RA: 2060236
PROJETO INTEGRADO MULTIDISCIPLINAR V
SOFTWARE DE RESERVA DE EQUIPAMENTOS AUDIOVISUAIS PARA O COLÉGIO VENCER SEMPRE
SANTO ANTÔNIO DO DESCOBERTO – GO
2021 
UNIVERSIDADE PAULISTA - UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia
KAIQUE VINICIUS LIMA ALBANO – RA: 2071753
ALEXANDRE GUSTAVO LONGHI – RA: 2064482
FÁBIO CAMPOS BARRETO – RA: 2057861
JOÃO CARLOS ARAÚJO AZEVEDO – RA: 2071048
JEAN PEREIRA LOURENÇO – RA: 2060236
PROJETO INTEGRADO MULTIDISCIPLINAR V
SOFTWARE DE RESERVA DE EQUIPAMENTOS AUDIOVISUAIS PARA O COLÉGIO VENCER SEMPRE
Projeto Integrado Multidisciplinar apresentado como exigência parcial para conclusão do 3º semestre do Curso Superior de Análise e Desenvolvimento de Sistemas, apresentado à Universidade Paulista – UNIP EaD.
Orientadora: Prof. Patrícia Toffolo.
SANTO ANTÔNIO DO DESCOBERTO – GO
2021
RESUMO
O presente trabalho tem como objetivo apresentar a elaboração de um sistema para um colégio com o propósito de reservar equipamentos audiovisuais para o suporte dos professores em suas atividades. O sistema que se tem no momento é manual, o que torna sua utilização precária, por isso a elaboração de um sistema digital, que facilite a forma de controlar o uso dos equipamentos, é de suma importância, pois possibilita à gestão o melhor controle dos prazos de devolução e aos colaboradores a organização das reservas. O sistema apresentado tem como alicerce conceitos de engenharia de software, economia, interface de usuário e programação orientada a objetos. A intenção primordial do presente trabalho é elucidar, respectivamente de acordo com seus conceitos-base, a adequação da aplicação às normas de qualidade na produção de softwares, sua viabilização financeira, seu projeto de interface – a ser implementado futuramente – e sua estrutura lógica.
Palavras-chave: Economia e mercado, engenharia de software, interface de usuário, programação orientada a objeto.
ABSTRACT
The present work aims to present the elaboration of a system for a school for the purpose of reserving audiovisual equipment which support teachers in their activities. The current system is manual, which makes its use precarious, therefore the development of a digital system which facilitates the control of equipment usage is of paramount importance, as it allows managers to better control the return deadlines and employees to organize reservations. The system presented is based on concepts of software engineering, economics, user interface and object-oriented programming. The main intention of the present work is to elucidate, respectively according to its basic concepts, the compliance of the application to the quality standards in the production of software, its financial viability, its interface design – to be implemented in the future – and its logical structure.
Keywords: Economy and market, software engineering, user interface, object-oriented programming.
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................... 06
2 ECONOMIA E MERCADO ................................................................................................. 08
2.1 Agentes Econômicos .......................................................................................................... 08
3 ENGENHARIA DE SOFTWARE ........................................................................................ 09
3.1 ISO/NBR 9126 ................................................................................................................... 09
3.2 Requisitos Funcionais ........................................................................................................ 09
3.3 Requisitos Não Funcionais ................................................................................................. 10
3.4 Regras e Requisitos de Negócio ......................................................................................... 12
3.5 Testes Funcionais de Interface ........................................................................................... 14
3.6 Modelo de Qualidade para Processo de Software ............................................................... 16
3.7 Teste de Software ............................................................................................................... 18
3.8 Casos de Teste .................................................................................................................... 20
3.9 Roteiros de Testes .............................................................................................................. 21
3.10 Relatório de Análise de Testes .......................................................................................... 27 
4 PROJETO DE INTERFACE DO USUÁRIO ....................................................................... 28
5 PROGRAMAÇÃO ORIENTADA A OBJETOS .................................................................. 38
5.1 Classes e Objetos ................................................................................................................ 38
5.2 Herança e Polimorfismo ..................................................................................................... 39
6 CONCLUSÃO ...................................................................................................................... 40
7 REFERÊNCIAS .................................................................................................................... 41
1 INTRODUÇÃO
O presente trabalho acadêmico trata da elaboração teórico-prática de uma situação-problema apresentada na disciplina Projeto Integrado Multidisciplinar V, do terceiro semestre do curso Superior Técnico em Análise e Desenvolvimento de Sistemas, na instituição Universidade Paulista – UNIP. A disciplina em questão tem como objetivo gerar um fomento contextual à interdisciplinaridade fundamental à formação do aluno e, neste caso específico, busca relacionar as disciplinas Economia e Mercado, Projeto de Interface com o Usuário, Programação Orientada a Objeto I e Engenharia de Software II.
O foco da situação problema em questão é discutir e elaborar, em etapas, um sistema para o Colégio Vencer, para auxiliar no sistema de reserva de equipamentos audiovisuais, que há tempos é manual. A decisão veio por parte do próprio colégio, pois muitos professores não conseguem utilizar os recursos que necessitam. O novo sistema de reserva surge com o intuito de providenciar equipamentos de informática e vídeo (por exemplo: DATA-SHOWS, TV com VCR, TV com DVD, Projetor de Slides, Sistemas de Áudio Microfone, Caixa Amplificada, Notebooks, Kits Multimídia etc.) para colaboradores da empresa de forma intuitiva, ágil e organizada.
Partindo-se de tal foco, é estabelecido que a empresa contratada precisa, com o auxílio da disciplina Economia e Mercado, verificar a viabilidade econômica do software elaborado, qual investimento financeiro será realizado e o prazo para conclusão do projeto, além de mapear os fornecedores e colaboradores envolvidos. Em um segundo momento, com apoio da disciplina de Engenharia de Software II, o próximo passo é estruturar, documentar e definir os requisitos funcionais, não funcionais e de negócio, bem como decidir qual norma de qualidade se aplica melhor à empresa, montar o planejamento para os requisitos funcionais e apresentar o roteiro de testes. Então, com base na disciplina Projeto de Interface com o Usuário, também serão verificadas as especificações da interface e as mensagens a serem exibidas.
Com relação à última, para a elaboração do produto, serão construídos protótipos de interface, o que pode ser realizado em qualquer software, que possuem como pilar a engenhariade software, particularizando-se cada tela de interface e explicando-se a entrada, o processamento e a saída de dados. Por fim, com o auxílio da Programação Orientada a Objeto I, objetiva-se descrever teoricamente os fundamentos sobre: objeto, classe, herança e polimorfismo, além de identificá-los no sistema desenvolvido.
Vale, ainda, ressaltar que, para a melhor elaboração possível do presente trabalho, são aqui utilizadas referências tanto dos livros didáticos de cada disciplina, desenvolvidos por professores conteudistas da própria instituição UNIP, quanto de outros importantes autores especializados em cada uma das áreas do conhecimento que tangem o projeto.
2 ECONOMIA E MERCADO
2.1 Agentes Econômicos
Os agentes econômicos são todas as pessoas físicas e jurídicas que fazem o sistema econômico funcionar, no momento, e de forma simplificada, os agentes que atuam no ramo econômico são os seguintes: agente de família, empresa, governo e setor externo. No projeto apresentado, os agentes que atuam diretamente com a nossa empresa são os agentes de empresa e família.
Agente de família é um conceito que representa todos aqueles que, de uma única forma, exercem o papel de consumidores, adquirindo bens e serviços.
Já os agentes de empresa são todos aqueles que produzem e proporcionam bens e serviços, que de maneiras diversas colaboram com a economia do país.
Figura 1: Agentes Econômicos (Autoria própria).
Este projeto tem como finalidade a criação de um software e, considerando-se sua viabilidade econômica, estão envolvidos de forma direta um analista de negócios, dois programadores, dois designers e um líder de negócio. Assim, analisando-se de uma perspectiva financeira, seu custeamento ficará em R$60.000,00 (sessenta mil reais), e com um processo de 30 a 45 dias, pois ficará em desenvolvimento a interface e o código fonte do sistema, sempre focando-se no intuito de melhorar e facilitar suas ações.
3 ENGENHARIA DE SOFTWARE
3.1 ISO/NBR 9126
Utilizamos o padrão ISO/NBR 9126, como sugerido no manual do PIM, o qual padroniza as qualidades do software, que são divididas em seis características, conforme a imagem a seguir.
Figura 2: Características do padrão ISO/NBR 9126 (Fonte: https://pt.wikipedia.org/wiki/ISO/IEC_9126).
A norma ISO/IEC 9126 é uma referência técnica mundial para a qualidade de um produto de software elaborada pela ISO e pelo IEC em 1991 e publicada no Brasil em 1996 como NBR/13596. Ela fornece um modelo geral que define seis categorias de características de qualidade do produto de software, divididas em subcaracterísticas. Estas podem ser avaliadas por meio de métricas quantitativas. Tal conjunto permite dizer se o software satisfaz as necessidades e os padrões estabelecidos pelos desenvolvedores e pelos usuários (ISO, 2001). IEC significa International Electrotechnical Commission e é uma organização internacional sem fins lucrativos que desenvolve padrões sobre tecnologias elétricas e eletrônicas, inclusive sobre software, presente em mais de 150 países.
3.2 Requisitos Funcionais
Os requisitos funcionais são de extrema importância, porque é por meio deles que abordaremos todas as necessidades do software. Trata-se, pois, de um parâmetro de tudo aquilo que precisamos para começar a construí-lo. Tudo aquilo que o cliente pedir será abordado nesse requisito, todos os elementos que forem da necessidade dele, como incluir, excluir e alterar nomes, produtos, consultas, geração de relatórios etc.
Parte da etapa de licitação, os requisitos funcionais são todos os problemas e necessidades que devem ser atendidos e resolvidos pelo software por meio de funções ou serviços. Alguns exemplos desse tipo de requisito são: inserir dados em um formulário, buscar pratos específicos em um cardápio, consultar o status de um pedido, realizar compras, comunicar-se com um atendente, alterar informações de um registro e elaborar relatórios.
Tudo o que for relacionado a uma ação a ser feita é considerado uma função. Também é importante lembrar que, quanto menos ambíguos e mais objetivos forem os requisitos funcionais, maior será a qualidade do software gerado.
Dessa forma, lista-se a seguir os requisitos funcionais do software abordado no presente trabalho:
· RF001 – Incluir cadastro de equipamentos audiovisuais.
· RF002 – Excluir cadastro de equipamentos audiovisuais.
· RF003 – Alterar cadastro de equipamentos audiovisuais.
· RF004 – Consultar cadastro de equipamentos audiovisuais.
· RF005 – Consultar equipamentos agendados.
· RF006 – Consultar equipamentos não agendados.
· RF007 – Alterar situação do equipamento se será agendado ou está sendo devolvido.
· RF008 – Consultar tempo estimado do equipamento com o professor.
· RF009 – Incluir professores ensino fundamental e médio.
· RF010 – Excluir professores ensino fundamental e médio.
· RF011– Alterar professores ensino fundamental e médio.
· RF012 – Consultar professores com equipamento agendados.
· RF013 – Consultar professores com equipamento não agendados.
· RF014 – Alterar situação do professor se pode agendar um equipamento ou se está devolvendo um equipamento.
· RF015 – Professor que agendou algum equipamento estará em bloqueio no software enquanto não houver a devolução do equipamento.
· RF016 – Professor terá um prazo para entregar o equipamento, caso ultrapasse o limite da entrega, o software mostrará uma mensagem de limite de prazo ultrapassado.
3.3 Requisitos Não Funcionais
Diferente dos requisitos funcionais, os requisitos não funcionais, apesar de seu nome parecer que seja algo sem utilidade, na verdade representam uma das partes mais úteis do software, porque aqui é parte indireta a qual o cliente não vê e nem precisa ter conhecimento sobre. São os meios e métodos que farão funcionar aquilo que o cliente solicitou, como a velocidade de resposta do software, em que sistema funcionará e seus níveis de segurança.
Uma vez que os Requisitos Funcionais definem o que o sistema fará, a Engenharia de Software afirma que os Requisitos Não Funcionais definem como o sistema fará, embora não seja tão clara assim essa definição. Os Requisitos Não Funcionais não estão relacionados diretamente às funcionalidades de um sistema. Também chamados de atributos de qualidade, ainda assim esses requisitos são de grande importância no desenvolvimento do sistema. Tratados geralmente como premissas e restrições técnicas de um projeto, os Requisitos Não Funcionais são praticamente todas as necessidades que não podem ser atendidas através de funcionalidades.
Geralmente mensuráveis, os Requisitos Não Funcionais definem características e impõem limites ao sistema, como método de desenvolvimento, tempo, espaço, sistema operacional, dentre outros. Sua medida pode ser determinada e é importante que seja associada ou referenciada com relação a cada requisito não funcional. Para ficar mais claro, temos alguns exemplos de propriedades e suas métricas: o tamanho pode ser medido em Kbytes e número de Chip de RAM; a velocidade está ligada ao tempo de utilização da tela, ou transações processadas por segundos; a métrica da portabilidade é o número de sistema-alvo; a facilidade de uso pode ser medida pelo número de janelas ou o tempo de treino; a confiabilidade tem ligação com o tempo médio que o sistema pode vir a falhar, a disponibilidade ou até mesmo a taxa de ocorrência de falhas.
Tendo-se essa fundamentação sobre o conceito em mente, lista-se, a seguir, os Requisitos Não Funcionais presentes na elaboração do sistema em pauta:
· RNF001 - Será desenvolvido em C# Windows Form App.
· RNF002 - Terá as funções de excluir, incluir e alterar as máquinas agendadas e não agendadas, assim como os professores que irão alugar as máquinas audiovisuais, e transparece um relatório sobre as quantidades de máquinas agendadas e não agendadas.
· RNF003 - Capacidade de rodar em ambiente Windows.
· RNF004 - Será um software offline, o que traz mais segurança para o usuário, assim como seu sistema de login com senha.
· RNF005 - Para cada usuário haverá um login e uma senha, não poderá haver dois acessosde um mesmo login ao mesmo tempo.
· RNF006 – Haverá a opção de impressão de relatórios em PDF, Excel e Word.
· RNF007 - Como se trata de um software simples feito no ambiente Visual Studio, não haverá falhas com frequência.
· RNF008 - Caso houver falhas, será oferecido um suporte online das 9:00 às 18:00 para auxiliar e fazer correções de bugs.
· RNF009 - Em caso de falhas críticas, haverá um banco de dados SQL SERVER que armazenará todos os registros.
· RNF010 - Software com capacidade de até 50 usuários em acesso simultâneo. Caso entrem mais de 50 usuários, haverá lentidão no software e até mesmo falha. 
· RNF011 - O software será construído via Windows Form App, com acesso fácil às principais funcionalidades.
· RNF012 - Um usuário sem experiência em computação pode aprender como usar o sistema em até 2 dias.
· RNF013 - Sistema será em português do Brasil e em caso de erros apresentará mensagens simples ao usuário ativo.
· RNF014 - Quando iniciar um cadastro de um novo professor ou máquina audiovisual, o registro processa os dados e atualiza em até 5 segundos.
· RNF015 - Ao consultar os relatórios após alguma atualização, os resultados estarão disponíveis em 5 segundos.
· RNF016 - Pode-se acessar até duas abas ao mesmo tempo.
· RNF017 - O sistema usa 100 MB de memória de uma máquina.
3.4 Regras e Requisitos de Negócio
São as regras de negócio que vão definir o passo-a-passo de cada tela do nosso software, como elas reagem, que tipo de restrições têm, seus limites, o que cada campo, botão e tabela irá trazer como funcionalidade. Elas guiarão o comportamento e definirão como, onde e por quê.
Elas ajudarão muito a entendermos, em tempo real, qual tem sido o desempenho do software e se ele está trazendo benefícios ou malefícios para a empresa. 
Como o próprio termo sugere, são regras que servem para definir ou restringir alguma ação nos processos de uma empresa. São declarações que irão descrever como determinadas operações devem ser realizadas e se há algum limite que precisa ser aplicado.
· RNG001 - O cliente, ao executar o software, verá os campos de login e senha, e o sistema só permitirá seu acesso com credenciais válidas e criadas pelo responsável principal do sistema.
· RNG002 - Ao acessar o sistema, aparecerão cinco plataformas, a primeira de cadastros de novos professores e máquinas, a segunda de agendar máquina, a terceira para consultar a situação atual dos agendamentos, a quarta para consultar os equipamentos cadastrados, a quinta para consultar professores cadastrados e sempre um botão para sair do sistema ou voltar uma página.
· RNG003 - Ao clicar em cadastro, aparecerão as opções de cadastrar máquinas audiovisuais ou novos professores e o botão de voltar à página anterior. Após o clique em uma das opções, serão exibidos os campos necessários para o preenchimento e botões de cadastrar e sair.
· RNG004 - Ao clicar em agendar máquina, será exibido um relatório de todas as máquinas disponíveis e as que estão perto do prazo de devolução, além da opção de agendar equipamento.
· RNG005 - Ao clicar em agendar, a tela mostrará outro relatório contendo todos os professores cadastrados.
· RNG006 - Ao selecionar o professor e clicar em agendar, o sistema mudará a situação do professor e equipamento, de não disponível para agendamento, e exibirá uma mensagem ao usuário indicando o agendamento feito com sucesso.
· RNG007 - Então o relatório de consulta será atualizado, e exibirá o prazo final da devolução em que o professor deve entregar o produto.
· RNG008 - Ao voltar à aba principal e clicar em consultar agendamentos, será mostrado um relatório contendo todos os agendamentos com a relação de equipamento, professor e datas de retirada e devolução.
· RNG009 - Ao clicar em consultar equipamentos, será mostrada uma relação com todos os equipamentos, status de agendamento (agendado ou não) e haverá a opção de excluir ou agendar cada um dos produtos listados. E, ao realizar qualquer uma dessas operações, o relatório será atualizado e mostrará uma mensagem de atualizações feitas.
· RNG010 - Ao clicar em consultar professores, será mostrada uma relação com todos os professores, equipamentos que agendaram e a opção de alterar, excluir ou agendar um equipamento para cada um dos professores listados. E, ao realizar qualquer uma dessas operações, o relatório será atualizado e mostrará uma mensagem de atualizações feitas.
· RNG012 - Em caso de atraso na devolução de máquinas, na plataforma consultar o relatório de tais professores que estão em atraso mostrará a mensagem de atraso e exibirá a opção de estender o prazo.
3.5 Testes Funcionais de Interface
Em seguida, iremos apresentar uma relação contendo o campo, tipo de campo e regras de negócio, na qual abordaremos o tamanho dos campos, as mensagens que cada botão apresentará caso seja efetuado, por exemplo, um login com credenciais incorretas, que tipo de mensagem será apresentada para o usuário, e se o login e senha estiverem certos, que tipo de mensagem aparecerá para possibilitar uma ação. Serão listados quais campos podem aceitar valores nulos, quais não podem, quais campos aceitam só números ou só textos e quais são suas funções dentro do software.
Além dos casos de testes relacionados às regras de negócio abordadas até aqui, existem os casos de testes relativos ao comportamento técnico das telas ou interfaces. Esses casos de testes são importantes para garantir que a interface faça as verificações necessárias para tornar o software mais robusto e confiável com relação aos dados de entrada. Abaixo traremos as especificações da interface.
	Login e Senha
	Nº
	Elemento
	Descrição
	Tamanho/Tipo
	Formato
	Validação
	1
	Campo
	Login
	Alfa (100)
	Alinhado à esquerda
	Não nulo
	2
	Campo
	Senha
	Alfa (100)
	Senha com caracteres especiais em: *
	Não nulo
	3
	Botão 
	Entrar 
	-
	-
	Acessa menu principal
	4
	Botão 
	Sair
	-
	-
	Sai do sistema
	Nº
	Elemento
	Descrição
	Situação
	Mensagem de exibição
	Ação
	1
	Botão 
	Entrar 
	Credenciais inválidas
	"Usuário ou senha inválidos"
	Impede acesso ao menu principal
	2
	Caixa de Mensagem
	-
	Credenciais válidas
	"Login efetuado com sucesso"
	Retorno indicando credenciais corretas
	Menu Principal
	Nº
	Elemento
	Descrição
	Tamanho/Tipo
	Formato
	Validação
	1
	Botão 
	Cadastrar novo professor ou equipamento
	-
	-
	Entra no menu de cadastro de professores ou equipamentos
	2
	Botão 
	Agendar Equipamento
	-
	-
	Exibe os equipamentos disponíveis
	3
	Botão 
	Consultar Agendamentos
	-
	-
	Exibe os equipamentos agendados
	4
	Botão 
	Consultar Equipamentos
	-
	-
	Exibe os equipamentos cadastrados
	5
	Botão 
	Consultar Professores
	-
	-
	Exibe professores e suas reservas
	6
	Botão 
	Sair
	-
	-
	Sai do sistema
	Menu Cadastrar Novo Professor ou Equipamento
	Nº
	Elemento
	Descrição
	Tamanho/Tipo
	Formato
	Validação
	1
	Botão 
	Cadastrar novo equipamento
	-
	-
	Exibe campos para cadastro de máquina
	2
	Botão 
	Cadastrar novo professor
	-
	-
	Exibe campos para cadastro de professor
	3
	Botão 
	Voltar
	-
	-
	volta ao menu principal
	4
	Campo
	Insira o tipo de equipamento
	Alfa (100)
	Alinhado à esquerda
	Não nulo e sem repetições
	5
	Campo
	Quantidade
	numérico (Max)
	números inteiros
	Maior que zero
	6
	Campo
	Insira o nome do professor
	Alfa (200)
	Alinhado à esquerda
	Não nulo e sem repetições
	Menu Agendar Equipamento
	Nº
	Elemento
	Descrição
	Tamanho/Tipo
	Formato
	Validação
	1
	Campo
	ID
	numérico (Max)
	números inteiros
	Gerado de forma automática
	2
	Campo
	Tipo
	Alfa (100)
	Alinhado à esquerda
	Tipo de equipamento que foi cadastrado
	3
	Campo
	Adicionado
	Data e hora
	Data e hora
	Gerado de forma automática
	4
	Campo
	Digite o ID do equipamento que deseja agendar
	numérico (Max)
	números inteiros
	Maior que zero 
	5
	Botão 
	Voltar
	-
	-
	volta ao menu principal
	6
	Campo
	ID
	numérico (Max)
	números inteiros
	Obtém o ID de forma automática de cada professor cadastrado
	7
	Campo
	Nome
	Alfa (200)
	Alinhado à esquerda
	Nome do professor que foi cadastrado
	8
	Campo
	Equipamentos Agendados
	numérico(Max)
	números inteiros
	Quantos equipamentos professor tem cadastrado.
	9
	Campo
	Digite o ID do equipamento que deseja agendar
	numérico (Max)
	números inteiros
	Não pode ser menor que 0 
	10
	Campo
	data de agendamento
	Data (10)
	Data (10)
	 Data deve ser uma data valida
	11
	Campo
	data de retorno
	Data (10)
	Data (10)
	 Data deve ser uma data valida e maior que a data de agendamento
	12
	Botão 
	Voltar
	-
	-
	volta ao menu principal
	Nº
	Elemento
	Descrição
	Situação
	Mensagem de exibição
	Ação
	1
	Caixa de Mensagem
	-
	Quando é feito um agendamento
	"Agendamento feito com sucesso!"
	Um retorno de que foi feito o agendamento com sucesso
	Menu Consultar Agendamentos
	Nº
	Elemento
	Descrição
	Tamanho/Tipo
	Formato
	Validação
	1
	Campo
	ID Equipamento
	numérico (Max)
	números inteiros
	Obtém o ID de forma automática de cada equipamento cadastrado
	2
	Campo
	Nome Equipamento
	Alfa (100)
	Alinhado à esquerda
	tipo de equipamento que foi cadastrado
	3
	Campo
	ID Professor
	numérico (Max)
	números inteiros
	ID do professor que reservou o equipamento
	4
	Campo
	Nome Professor
	Alfa (200)
	Alinhado à esquerda
	Nome do professor que agendou o equipamento
	5
	Campo
	Data Agendamento
	Data (10)
	Data (10)
	Data do agendamento
	6
	Campo
	Data devolução
	Data (10)
	Data (10)
	Data da devolução 
	7
	Botão 
	Voltar
	-
	-
	volta ao menu principal
	Menu Consultar Equipamentos
	Nº
	Elemento
	Descrição
	Tamanho/Tipo
	Formato
	Validação
	1
	Campo
	ID Equipamento
	numérico (Max)
	números inteiros
	Obtém o ID de forma automática de cada equipamento cadastrado
	2
	Campo
	Tipo Equipamento
	Alfa (100)
	Alinhado à esquerda
	tipo de equipamento que foi cadastrado
	3
	Campo
	Está Reservado? 
	Alfa (3)
	Sim/Não
	Apenas a opção de sim ou não ser o equipamento está reservado
	4
	Campo
	ID Professor
	numérico (Max)
	números inteiros
	ID do professor que reservou o equipamento
	5
	Botão 
	Voltar
	-
	-
	volta ao menu principal
	Menu Consultar Professores
	Nº
	Elemento
	Descrição
	Tamanho/Tipo
	Formato
	Validação
	1
	Campo
	ID Professor
	numérico (Max)
	números inteiros
	Obtém o ID de forma automática de cada professor cadastrado
	2
	Campo
	Nome do professor
	Alfa (200)
	Alinhado à esquerda
	Nome do professor cadastrado
	3
	Campo
	Quantidade de Reservas
	numérico (Max)
	números inteiros
	Mostra quantas reservas tem cada professor
	4
	Campo
	Alguma devolução em Atraso?
	Alfa (3)
	Sim/Não
	Apenas a opção de sim ou não ser o professor está com algum equipamento fora do prazo
	5
	Botão 
	Voltar
	-
	-
	volta ao menu principal
3.6 Modelo de Qualidade para Processo de Software
MPS.BR ou então Melhoria De Processos Do Software Brasileiro é um modelo de qualidade criado com o objetivo de incentivar empresas de pequeno ou médio porte que têm seu foco em produção de software. Esse modelo é focado em processos que possuem custos e tem sua atenção voltada à realidade brasileira, por isso tem seu selo restrito ao Brasil. Ele foi escolhido devido a seu foco aqui no Brasil e sua transparência em seus componentes, um método com mais facilidade de subir de níveis de maturidade, menos complexo que seus outros “irmãos”.
Esse modelo foi criado levando em conta os modelos internacionalmente conhecidos, sendo eles: ISO/IEC 15504, ISO/IEC 12207, ISO/IEC 25000 e CMMI (Capability Maturity Model Integration).
O modelo é divido em 4 componentes, 7 níveis de maturidade e 19 processos. Sendo assim, os componentes são modelos que fazem alusão ao desenvolvimento, aquisição e avaliação de software. A maturidade é referente à posição que as empresas recebem de acordo com os componentes, e os processos são as práticas que as organizações precisam ter para alcançar os níveis de maturidade do modelo.
	MODELO
	ESPECIFICAÇÃO
	Modelo de referência para software
	Inclui as condições dos níveis de maturidade, processo e atributos do processo para adquirir e implementar.
	Modelo de referência para serviços
	Inclui as condições dos níveis de maturidade, processos e atributos do processo para o fornecimento de serviços de informática.
	Modelo de avaliação
	Inclui as condições para os avaliadores-líderes, avaliadores-adjuntos e as instituição avaliadoras.
	Modelo de negócio
	Seu intuito é focado em demonstrar as regras de negócio para colocação dos modelos de referência de software e de serviços pelas instituições implementadoras e para também o método de avaliação pelas instituições avaliadoras.
Os níveis de maturidade são divididos em 7, logo pensamos que assim será mais difícil de avançar, ou demorado, mas trata-se do contrário. Pelo fato de haver 7 níveis, tem-se maiores chances de subir os níveis em menos tempo, eles servem como indicador de evolução da qualidade, mostram o estágio de melhoria, são sequencias e dependentes um do outro. Os níveis são divididos de forma alfabética, do melhor ao “pior”, como mostrados abaixo:
· NÍVEL A: Otimização.
· NÍVEL B: Gerenciamento quantitativo.
· NÍVEL C: Definido.
· NÍVEL D: Largamente definitivo.
· NÍVEL E: Parcelamento definido.
· NÍVEL F: Gerenciado.
· NÍVEL G: Parcialmente gerenciado.
	NIVEL DE MATURIDADE
	PROCESSOS
	A- Otimizado
	· Não há processos específicos
	B- Gerenciamento quantitativo
	· Não há processos específicos
	
C- Definido
	· Gerência de decisões
· Gerência de riscos
· Desenvolvimento para reutilização
	
D- Largamente definido
	· Desenvolvimento de requisitos
· Projeto e construção do produto
· Integração do produto
· Verificação
· Validação
	
E- Parcialmente definido
	· Definição do processo organizacional
· Avaliação e melhoria do processo organizacional
· Gerência para reutilização
· Gerência de recursos humanos
	
F- Gerenciado
	· Garantia de qualidade
· Gerência de configuração
· Medição
· Aquisição
· Gerência de protfólio
	G- Parcialmente gerenciado
	· Gerência de requisitos
· Gerência de projetos
Tendo-se em vista que os níveis A e B variam muito conforme a necessidade da empresa, a tabela acima exibe que “não há processos”.
3.7 Teste de Software
Com o objetivo de garantir a qualidade do software produzido, emprega-se, no projeto aqui apresentado, técnicas de teste elaboradas e direcionadas especificamente para o sistema em pauta. Quanto à importância dessa etapa, Ribeiro (2015, p. 104) afirma que:
Atualmente, o grau de exigência dos usuários com a qualidade dos produtos de software está cada vez maior. A complexidade das aplicações em relação à granularidade, a segurança e a integração com outros sistemas e o aumento da concorrência no mercado de software tornam os testes uma atividade essencial e indispensável, com equipes exclusivas e dedicadas a essas ações, com o objetivo de garantir e controlar a qualidade do sistema.
Além disso, o autor indica que “as definições sobre testes de software variam, mas todas convergem para os conceitos básicos de encontrar defeitos em um software que está sendo testado, conferir se está de acordo com os requisitos definidos pelo usuário e verificar se realiza o que deveria ser feito”. Por isso, é fundamental aliar o desenvolvimento do projeto em si às etapas de testes devidamente planejados, roteirizados e executados.
Outro fator importante no emprego de técnicas de teste de software durante seu desenvolvimento, além das implicâncias para com a qualidade final do produto, é o fator custo, que tem sua relação com os testes descrita na seguinte afirmação de Myers (2004, apud RIBEIRO, 2015, p. 107): “quanto mais cedo for descoberto e corrigido o defeito, menor será o seu custo para o projeto, pois esse custo cresce até dez vezes a cada fase para a qual o projeto do software avança”. Conceitua-se essa máxima como a Regra de 10 de Myers.
Assim, para integrar as fases de testes ao desenvolvimento do sistema aqui descrito, recorremos ao Modelo V, conforme ilustrado na figura a seguir:
Figura 3: Modelo V do processo de testes (RIBEIRO, 2015, p. 108).
E, de forma a estabelecer a metodologia prática aqui empregada, adotamos o seguinte fluxo, a fim de chegarmos à elaboração dos roteiros de testes da forma mais sólida e completapossível:
Figura 4: Processo de criação do roteiro de testes (RIBEIRO, 2015, p. 109).
Observa-se que, na representação acima, tem-se como ponto inicial o estabelecimento de requisitos e protótipos de telas, ambos os quais foram definidos anteriormente. Por isso, a seguir, damos continuidade ao processo pela definição dos casos de teste aplicáveis e, então, partimos para a elaboração dos roteiros de testes.
3.8 Casos de Teste
No presente momento, emprega-se a técnica de testes funcionais ou técnica caixa-preta, a qual se sustenta na especificação inicial do sistema, é construída na fase de levantamento de requisitos e tem como unidade básica os casos de teste, que podem ser definidos como “situações de sucesso e insucesso na execução de determinadas funcionalidades” (RIBEIRO, 2015, p. 115). Sobre os testes funcionais, o autor afirma, ainda, que:
Focadas nas necessidades ditadas pelos usuários e transformadas em requisitos pelos analistas de sistemas, as situações de testes criadas devem atestar que o software faz exatamente o que foi solicitado e que funciona corretamente. (Id., ibid., p. 121)
E, sobre os casos de teste e como se aplicam de forma prática na engenharia de software, Ribeiro (2015, p. 122) expõe:
Um caso de teste ou um cenário de teste é uma situação que o sistema apresenta para a qual, dada uma informação de entrada, será gerada uma saída esperada pelo usuário. Por exemplo, você quer testar um software para uma calculadora simples com quatro operações. Todas as operações precisam ser testadas, e, para cada uma, um conjunto de valores precisa ser verificado para constatar se está fazendo o cálculo correto.
Além disso, o autor especifica que, para a elaboração dos casos de teste, são necessários dois elementos fundamentais: os requisitos – funcionais e de negócios – e um protótipo de telas visual, ambos apresentados anteriormente.
Contudo, adota-se no presente trabalho o conceito de TDD (Test Driven Development ou Desenvolvimento Orientado a Testes), que, basicamente, consiste em uma técnica que é “parte da metodologia XP e utilizado em diversas outras metodologias, além de poder ser utilizada livremente” (DEVMEDIA, 2013). O blog ainda aponta que “o TDD transforma o desenvolvimento, pois deve-se primeiro escrever os testes, antes de implementar o sistema. Os testes são utilizados para facilitar no entendimento do projeto”.
Dessa forma, os testes realizados e aqui apresentados são realizados sobre uma aplicação lógica que servirá como base abstrata para a produção do software em si, que ocorrerá em um segundo momento e contará com os requisitos funcionais, não funcionais e de negócios, somados ao projeto de interface e à estrutura lógica empregada para testes.
Com base no exposto acima, chega-se aos casos de teste elencados a seguir, estruturados sobre os requisitos funcionais e de negócio do sistema, que servirão como base para a execução dos roteiros de testes em sequência – nota-se que os casos de teste apresentados não são extensivos, ou seja, não cobrem todas as funcionalidades que o software poderá apresentar em sua fase final de produção, contudo são suficientes para elucidar a base lógica, permitindo que seja testada, comprovando a qualidade do software e conferindo menor saturação de dados ao presente trabalho:
· Realizar login.
· Incluir cadastro de equipamento audiovisual.
· Excluir cadastro de equipamento audiovisual.
· Agendar equipamento para professor.
· Consultar agendamentos realizados.
3.9 Roteiros de Testes
Com base nos casos de testes listados acima, são elaborados e apresentados, em seguida, os roteiros de testes, que consistem, cada um, em “uma descrição detalhada do passo a passo para a execução do sistema, a fim de verificar cada caso de teste identificado na fase anterior” (RIBEIRO, 2015, p. 124). Vale ressaltar que, ainda segundo o autor, cada roteiro de testes deve conter as seguintes informações: nome do caso de testes, procedimento inicial, descrição detalhada e evidência de realização. Com base nesse modelo, seguem os roteiros aplicados aos casos de teste elencados anteriormente:
Primeiro, temos a realização do login do usuário, que será testada de forma positiva, ou seja, com credenciais corretas apenas. O sistema inclui mensagens de erro e redirecionamentos em caso de usuário ou senha incorretos, porém a representação dos testes ficaria extensa demais para o trabalho.
	Caso de teste: Realizar login com sucesso.
	Procedimento inicial: abrir o programa.
	ID
	Passo para execução
	Entrada
	Resultado esperado
	1
	Sistema exibe mensagem pedindo para o usuário inserir seu nome de usuário para login
	-
	Campo exibido: nome de login
	2
	Usuário informa nome de usuário válido e pressiona Enter
	admin
	Sistema exibe próxima mensagem
	3
	Sistema exibe mensagem pedindo para o usuário inserir sua senha para login
	-
	Campo exibido: senha de login
	4
	Usuário informa senha válida e pressiona Enter
	123456
	Sistema exibe mensagem de login realizado com sucesso, limpa a tela e então exibe o menu principal
Figura 5: Roteiro de teste para caso “realizar login”.
Uma vez testada a tela de login do usuário, parte-se à inclusão e exclusão de cadastros de equipamentos, na ordem: incluir cadastro de equipamento audiovisual, excluir cadastro de equipamento audiovisual. Os procedimentos de inclusão e exclusão de cadastros de professores são imensamente semelhantes aos que seguem, com a diferença fundamental de originarem-se de opções distintas nos menus do sistema.
	Caso de teste: Incluir cadastro de equipamento audiovisual.
	Procedimento inicial: abrir o programa, realizar login e selecionar a opção 1 (cadastrar novo professor ou equipamento).
	ID
	Passo para execução
	Entrada
	Resultado esperado
	1
	Sistema exibe mensagem pedindo para o usuário inserir 1 para incluir novo equipamento ou 2 para incluir novo professor
	-
	Campo exibido: selecionar opção
	2
	Usuário insere a opção desejada e pressiona Enter
	1
	Sistema exibe próxima tela
	3
	Sistema exibe mensagem pedindo para o usuário inserir o nome do tipo de equipamento
	-
	Campo exibido: nome do novo tipo de equipamento
	4
	Usuário informa nome do novo tipo de equipamento e pressiona Enter
	retroprojetor
	Sistema exibe próxima mensagem
	5
	Sistema exibe mensagem pedindo para o usuário inserir a quantidade disponível do novo tipo de equipamento
	-
	Campo exibido: quantidade do novo tipo de equipamento
	6
	Usuário informa quantidade do novo tipo de equipamento e pressiona Enter
	3
	Sistema exibe mensagem de sucesso na inclusão, limpa a tela e retorna à tela de incluir novo equipamento ou professor
Figura 6: Roteiro de teste para caso “incluir cadastro de equipamento audiovisual”.
	Caso de teste: Excluir cadastro de equipamento audiovisual.
	Procedimento inicial: abrir o programa, realizar login e selecionar a opção 4 (consultar equipamentos).
	ID
	Passo para execução
	Entrada
	Resultado esperado
	1
	Sistema exibe mensagem pedindo para o usuário inserir o ID do equipamento que deseja excluir
	-
	Campo exibido: selecionar ID de equipamento
	2
	Usuário insere o ID desejado e pressiona Enter
	1
	Sistema exibe próxima tela
	3
	Sistema exibe opções de realizar agendamento (1) ou excluir equipamento (2), pedindo para o usuário inserir o número da opção desejada
	-
	Campo exibido: escolher opção desejada
	4
	Usuário informa o número da opção desejada e pressiona Enter
	2
	Sistema exibe próxima mensagem
	5
	Sistema exibe mensagem de confirmação, pedindo para o usuário inserir 1 para confirmar ou 0 para cancelar e voltar
	-
	Campo exibido: inserir 1 para confirmar exclusão de equipamento
	6
	Usuário insere a opção desejada e pressiona Enter
	1
	Sistema exibe mensagem de exclusão realizada com sucesso, limpa a tela e então retorna ao menu principal
Figura 7: Roteiro de teste para caso “excluir cadastro de equipamento audiovisual”.
Não demonstramos aqui os testes das funcionalidades de consulta de equipamentos audiovisuais cadastrados e de professores cadastrados, uma vez que os procedimentos de exclusão,em si, já passam pelas telas de consulta.
Contudo, abrimos espaço para a demonstração do roteiro de testes da função primordial do sistema: o agendamento de equipamentos audiovisuais para professores.
	Caso de teste: Agendar equipamento para professor.
	Procedimento inicial: abrir o programa, realizar login e selecionar a opção 2 (realizar agendamento de equipamento).
	ID
	Passo para execução
	Entrada
	Resultado esperado
	1
	Sistema exibe mensagem pedindo para o usuário inserir o ID do equipamento que deseja agendar
	-
	Campo exibido: selecionar ID de equipamento
	2
	Usuário insere o ID desejado e pressiona Enter
	2
	Sistema exibe próxima tela
	3
	Sistema exibe mensagem pedindo para o usuário inserir o ID do professor que deseja agendar o equipamento escolhido
	-
	Campo exibido: selecionar ID de professor
	4
	Usuário insere o ID desejado e pressiona Enter
	1
	Sistema exibe próxima tela
	5
	Sistema exibe mensagem pedindo para o usuário inserir a data de agendamento para retirada do equipamento escolhido
	-
	Campo exibido: inserir data de retirada do equipamento
	6
	Usuário insere a data de retirada do equipamento, no formato dd/MM/aaaa e pressiona Enter
	15/04/2021
	Sistema exibe próxima tela
	7
	Sistema exibe mensagem pedindo para o usuário inserir a data para devolução do equipamento escolhido
	-
	Campo exibido: inserir data de devolução do equipamento
	8
	Usuário insere a data de retirada do equipamento, no formato dd/MM/aaaa e pressiona Enter
	25/04/2021
	Sistema exibe mensagem de agendamento realizado com sucesso, limpa a tela e então retorna ao menu principal
Figura 8: Roteiro de teste para caso “realizar agendamento de equipamento”.
Uma vez realizado o agendamento, partimos para o teste da funcionalidade que verifica se a função primária do sistema – realizar agendamentos de equipamento audiovisual para professores – está sendo cumprida de forma devida e com persistência de dados: a consulta de agendamentos realizados.
	Caso de teste: Consultar agendamentos realizados.
	Procedimento inicial: abrir o programa e realizar login.
	ID
	Passo para execução
	Entrada
	Resultado esperado
	1
	Sistema exibe opções do menu principal e mensagem pedindo para o usuário inserir o número correspondente à opção desejada
	-
	Campo exibido: escolher opção desejada
	2
	Usuário insere o número desejado e pressiona Enter
	3
	Sistema exibe próxima tela
	3
	Sistema exibe listagem de agendamentos realizados, incluindo dados como ID do equipamento e do professor envolvidos, tipo de equipamento, nome do professor e datas de retirada e devolução agendadas
	-
	Campo exibido: pressione qualquer tecla para retornar ao menu principal
	4
	Usuário pressiona qualquer tecla
	-
	Sistema limpa a tela e retorna ao menu principal
3.10 Relatório de Análise de Testes
Observa-se, pela definição dos casos de teste e posterior realização dos roteiros de teste, que as principais funcionalidades descritas nos requisitos funcionais e de negócio do sistema aqui abordado possuem funcionamento notável – ao menos no que diz respeito à estrutura lógica da aplicação.
Assim, legitima-se a ideia de definir, estruturar e aplicar conceitos de qualidade de software como garantia da funcionalidade plena e satisfação dos requisitos de um programa. No caso do software de agendamento de equipamentos audiovisuais para o Colégio Vencer, aplicar os conceitos de qualidade que tangem a Engenharia de Software foi impactou diretamente o planejamento e a execução do projeto, de forma a torná-lo possível, completo e satisfatório.
Entende-se, contudo, que os testes, conforme mencionado anteriormente, devem ser parte integrante de todo o processo de desenvolvimento, não somente durante sua elaboração, como até sua produção e entrega ao cliente – e possivelmente quando houver futuras implementações no programa, em se tratando de um SaaS (Software as a Service, ou Software como Serviço), por exemplo. Por isso, os procedimentos descritos nesta seção não limitam as possibilidades e a necessidade de se realizar testes no software em questão, será preciso manter a metodologia de desenvolvimento aliado à realização de testes nas demais fases, como na implementação da interface gráfica de usuário.
4 PROJETO DE INTERFACE DO USUÁRIO
A interface do usuário é por onde humano e máquina irão se comunicar, então é um aspecto fundamental a todo projeto de software.
No desenvolvimento de um projeto de software que envolve a interação homem-computador, a interface com o usuário é fundamental para o sucesso do sistema (SOMMERVILLE, 2003).
Nosso sistema de reserva de equipamentos audiovisuais trabalha de forma off-line e foi desenvolvido em C# Windows Form App. A seguir apresenta-se as telas principais do sistema. 
Ao iniciar o sistema, temos a tela de login, que necessita as informações de usuário e senha para acesso ao sistema.
O menu principal é composto de seis botões com funções específicas, sendo:
· Cadastro de Professores e Equipamentos.
· Agendamento de Equipamentos.
· Consultar Agendamentos.
· Consultar Equipamentos.
· Consultar Professores.
· Sair.
O menu Cadastrar Novo Professor ou Equipamento permite que o usuário faça o cadastro de novos professores e equipamentos, sendo composto por três botões.
Escolhendo a opção de cadastro de equipamento, será exibida a tela acima, onde será solicitado o nome do equipamento e a quantidade, no banco de dados será atribuído de forma automática pelo sistema um ID único para cada equipamento cadastrado.
Na opção de cadastro de professores, é necessário informar o nome do professor, seu e-mail e escolher se ele leciona no ensino fundamental ou médio. Ao confirmar será atribuído de forma automática pelo sistema um ID único para cada professor.
Para realizar o agendamento de um equipamento, o usuário deverá fazer uma pesquisa que pode conter o nome ou parte do nome do equipamento, bem como uma pesquisa em todos os equipamentos clicando no botão pesquisar, sendo que, ao deixar o campo equipamento em branco, serão exibidos todos os equipamentos disponíveis. 
Para agendar algum equipamento basta um duplo clique sobre o equipamento disponível na lista exibida.
 
Depois de selecionado o equipamento na tela anterior, o usuário deverá informar o nome do professor e as datas de saída e retorno do equipamento.
Ao término será exibida uma mensagem de que o agendamento foi feito com sucesso.
Caso o professor tenha algum equipamento com data de devolução vencida, será exibida a tela acima.
Na opção de consultar os agendamentos, é exibida uma lista de todos os equipamentos em uso, com data de saída, retorno e o nome do professor que está usando.
 Na opção de consultar os equipamentos, é exibida uma lista de todos os equipamentos. Em caso de estar em uso, é exibido o ID do professor que está com o equipamento. Também é possível escolher exibir somente os equipamentos livres que estão disponíveis para uso ou somente os que estão em uso e, ao escolher listar somente os agendados, é exibida a data prevista de devolução. Com um duplo clique no equipamento, é possível fazer a alteração ou exclusão do equipamento.
 
Na opção de consultar os professores, é exibida a tela acima, onde podemos ver se o professor possuir alguma reserva e se está dentro do prazo de devolução do equipamento.
Além das telas principais acima, de acordo com os requisitos funcionais, ainda teremos telas para realizar:
· Alteração e exclusão de equipamentos professores;
· Fazer a devolução dos equipamentos;
· Alterar a situação de um professor, caso possua equipamento fora do prazo pode-se informar que não é possível fazer a reserva de um novo equipamento.
Tela de alteração ou exclusão de professores. Caso deseje fazer alterações elas devem ser informadas nos campos e utilizar o botão confirma para salvar.
 Após a alteração feita, o usuário receberá a mensagem de que foi feita com sucesso.
 Em caso de exclusão, o usuário poderá receber dois avisos:
· Se o professor tiver equipamentos em uso ele não poderá ser excluído e será exibida a mensagem informandoque não é possível excluir;
· Se não houver equipamentos em uso ele será excluído e mostrada a mensagem de exclusão com sucesso.
Tela de alteração ou exclusão de professores. Caso deseje fazer alterações, elas devem ser informadas nos campos e utilizar o botão confirma para salvar.
Após a alteração feita, o usuário receberá a mensagem de que foi feita com sucesso.
Em caso de exclusão, o usuário poderá receber dois avisos:
· Se o equipamento estiver em uso ele não poderá ser excluído e será exibida a mensagem informando que não é possível excluir;
· Se o equipamento não estiver em uso ele será excluído e mostrada a mensagem de exclusão com sucesso.
Tela de devolução de equipamentos.
5 PROGRAMAÇÃO ORIENTADA A OBJETOS
Segundo Prof. Helder Frederico Lopes (2021, p. 9), a primeira linguagem de programação que utilizou os conceitos de programação orientada A objetos foi a Simula 67, criada por Ole-Johan Dahl e Kristen Nygaard em 1967, porém esse paradigma de programação só passou a ser largamente utilizado na atualidade. O autor (LOPES, 2021, p. 24) ainda afirma que a maioria das linguagens de programação atuais utilizam orientação a objetos, podendo citar: Java, C#, C++, Delphi, entre outras, que apesar de terem diferenças entre si, seguem os mesmos princípios e conceitos. Segundo Prof. Helder Frederico Lopes (2021, p. 64), a ideia principal da POO é aproximar o mundo real do virtual, ou seja, uma simulação de episódios do cotidiano replicados no computador. O programador deve retratar através de objetos e a interação entre esses objetos, soluções para problemas reais, transcritos em uma linguagem de programação.
O autor (LOPES, 2021, p. 12) ainda afirma que uma das grandes vantagens da programação orienta a objetos está na facilidade de se fazer manutenções em sistemas legados, deixando seu custo menor em relação a outras formas de programação, além da reutilização contínua de código. Os principais conceitos da POO são: objetos, classes, herança e polimorfismo.
5.1 Classes e Objetos
Segundo Prof. Helder Frederico Lopes (2021, p. 14), um objeto é uma parte do sistema de computador, que possui em suas propriedades um conjunto de dados e procedimentos para manipulação desses dados. Pode-se dizer que um sistema com orientação a objetos é a soma de diversos “objetos” que se comunicam, em conjunto ou individualmente, para resolução de problemas. Do ponto de vista da programação, um objeto pode ser comparado à uma variável em uma vertente de programação convencional. Segundo Prof. Helder Frederico Lopes (2021, p. 143), a variável possui um espaço em memória que armazena seu estado atual (valor), e possui um conjunto de operações e comandos que podem ser aplicados a ela. Da mesma forma um objeto adquire um espaço em memória para guardar seu estado atual (valor), podendo ser, aqui, um conjunto de atributos, além de um conjunto de operações que podem ser aplicados ao objeto (chamados aqui de métodos). As classes definem um tipo de dado no sistema, sendo formadas por dados (atributos) e comportamentos (métodos). Após a definição de uma classe, vários objetos podem ser criados a partir da mesma, ou seja, a classe é o elemento que dá a forma para os objetos.
· Classe: utilizamos classes para modelar os dados, como acontece por exemplo com as classes Professor e Equipamento, que agrupam dados e são utilizadas para organizar nosso código de forma a abstrair os conceitos do negócio em si.
· Objeto: no caso da classe Professor, sempre que vamos adicionar um novo cadastro de colaborador ao sistema, instanciamos essa classe na forma de um objeto para que cada professor tenha seus próprios dados, como nome e ID.
5.2 Herança e Polimorfismo
Segundo Prof. Helder Frederico Lopes (2021, p. 143), a herança e o polimorfismo surgem com o objetivo de reutilização de códigos implementados previamente, a fim de diminuir o tempo de implementações futuras e repetição de código fonte. Remetendo às classes e objetos anteriormente especificados, quando se cria um objeto ou uma nova classe a partir de uma classe mãe, o objeto ou classe filhos “herda” todos os atributos e métodos da classe mãe, dessa forma não existe a necessidade de reprogramação dos métodos pré-existentes. Chamamos essa característica de herança. Segundo Prof. Helder Frederico Lopes (2021, p. 135), o polimorfismo tem como significado “várias formas”. Para a programação orientada a objetos, pode-se entender que polimorfismo é a característica de um método ou atributo de possuir comportamentos diversos ou apresentar diferentes formas em sua execução e resposta, podendo ser utilizado em classes diversificadas da sua hierarquia.
· Herança: ainda com base na classe Professor, vemos que ela herda os campos ID, Data de Criação e Data de Modificação da classe Registro, que por sua vez é a classe pai.
· Polimorfismo: este conceito não é aplicado em nosso projeto.
6 CONCLUSÃO
O sistema em pauta foi elaborado seguindo a diretriz principal de auxiliar o Colégio Vencer Sempre a controlar e organizar as reservas de equipamentos audiovisuais por professores e demais funcionários de forma ágil, simples e, na medida do possível, automatizada. Utilizando a linguagem C#, o padrão de qualidade ISO/NBR 9126 e a ferramenta Visual Studio Community 2019, foi possível desenvolver uma estrutura lógica que pode servir como base para a produção de um software – constituído por essa estrutura base, somada à aplicação de uma estrutura de interfaces – que possa ser, de fato, utilizado pela instituição, junto com credenciais de acesso – usuário e senha – para acesso dos colaboradores – professores, auxiliares administrativos, coordenadoria e recepcionistas.
O sistema de login do software consiste em exigir que o usuário entre com usuário e senha predefinidos em arquivo em formato JSON, uma vez que, para um modelo de persistência de dados mais robusto, seria necessária a utilização de uma linguagem de banco de dados, como o MySQL ou o Microsoft SQL Server. Contudo, a verificação de usuário pode ser realizada na forma concebida – distribuição de credenciais pela própria empresa fornecedora do software – garantindo-se segurança ao sistema da mesma forma.
Em seguida à autenticação do usuário, o software permite que ele realize diversas funções relacionadas ao objetivo base do sistema – reservar e controlar reservas de equipamentos audiovisuais –, como: consultar, excluir, editar e cadastrar professores, consultar, excluir, editar e cadastrar equipamentos e, é claro, consultar, excluir, editar e realizar novas reservas. O sistema conta, também, como retornos às telas anteriores para auxiliar a interação humano-máquina e mensagens que exibem o status atual de funcionamento do programa e a aceitação ou não de entradas do usuário.
Ao final do projeto, concluímos que é possível desenvolver um software simples que auxilie em tarefas administrativas utilizando-se a linguagem C# e os conceitos de orientação a objetos, que mimetizam as regras de negócio sobre as quais o programa se constrói. Porém, somente com a aplicação dos conceitos de qualidade e testes providos pela Engenharia de Software é possível garantir que o sistema cumpra seus requisitos explicitados pelo cliente. Além disso, no presente ano de 2021, nota-se que é inviável produzir de forma definitiva um software sem a elaboração de uma Interface Gráfica com o Usuário, por isso deixamos essa parte devidamente estruturada para posterior aplicação.
7 REFERÊNCIAS
BIANCHI, L. Qualidade de produtos de software. Bianchi. Disponível em: <http://www.
bianchi.pro.br/edutec/qualsoft.php> Acesso em: 04 de abr. de 2021.
CANGUÇU, R. O que são Requisitos Funcionais e Requisitos Não Funcionais? Codificar, 2021. Disponível em: <https://codificar.com.br/requisitos-funcionais-nao-funcionais/>. Acesso em: 02 de abr. de 2021.
CUNHA, F. Requisitos funcionais e não funcionais: o que são? Mestres da Web, 2020. Disponível em: <https://mestresdaweb.com.br/fabrica-de-software/requisitos-funcionais-e-nao-funcionais-o-que-sao/>. Acesso em: 02 de abr. de 2021.
DAIANY. Oque é MPS-BR? Blog da qualidade, 2013. Disponível em: <https://blogdaqualidade.com.br/o-que-e-o-mps-br/>. Acesso em: 27 de Mar. de 2021
Estudo de Viabilidade de Software. Monitoria de Engenharia de Software, 2016. Disponível em: <https://monitoriadeengenhariadesoftware.wordpress.com/2016/09/06/estudo-de-viabilidade-de-software/> Acesso em: 10 de abr. de 2021.
LOPES, H. F.; ITO, O. T. Programação Orientada a Objetos I. São Paulo: Editora Sol, 2015.
O que é fluxo circular de renda. Dicionário financeiro, 2017. Disponível em: <https://www.dicionariofinanceiro.com/o-que-e-fluxo-circular-de-renda/amp/>. Acesso em: 07 de abr. de 2021.
OLIVEIRA, W. O que são regras de negócio e quais as vantagens de aplicá-las em uma empresa. Heflo, 2018. Disponível em: <https://www.google.com.br/search?q=requisitos
+de+neg%C3%B3cio+exemplos&sxsrf=ALeKk038bP7VBrQ_xJavEkw4dswnlQqedg:1617400562075&source=lnms&tbm=isch&sa=X&ved=2ahUKEwiUwNjPxuDvAhURVN8KHQ8EBU4Q_AUoAXoECAEQAw&biw=1366&bih=625#imgrc=D8DoqTM5VCOBcM> Acesso em: 03 de abr. de 2021.
PHILIPPE, J. Descrição dos Requisitos Não Funcionais. DSC. Disponível em 2001: <http://
www.dsc.ufcg.edu.br/~jacques/cursos/proj/gerenciadesenv/naofuncionais.htm>Acesso em: 04 de abr. de 2021.
REIS, T. Agentes econômicos: Quais são e como eles atuam na economia? Suno, 2020. Disponível em: <https://www.suno.com.br/artigos/agentes-economicos/>. Acesso em: 03 de abr. de 2021.
Requisitos Não-Funcionais. Trt9, 2021. Disponível em: <https://www.trt9.jus.br/pds/pdstrt9
/guidances/guidelines/supporting_requirements_8ED0BB6B.html> Acesso em: 03 de abr. de 2021.
RIBEIRO, A. L. D. Engenharia de Software II. São Paulo: Editora Sol, 2015.
SENGINK, W. C. Quanto custa um software personalizado. Ubistart Blog, 2018. Disponível em: <https://www.ubistart.com/blog/quanto-custa-um-software-personalizado/#:~:text=A%20
defini%C3%A7%C3%A3o%20de%20um%20escopo,n%C3%A3o%20precisa%20fazer%20muito%20esfor%C3%A7o.>. Acesso em: 05 de abr. de 2021.
TDD: fundamentos do desenvolvimento orientado a testes. DevMedia, 2013. Disponível em: <https://www.devmedia.com.br/tdd-fundamentos-do-desenvolvimento-orientado-a-testes/
28151>. Acesso em: 02 de abr. de 2021.
VENTURA, P. O que é Requisito Funcional. Até o momento, 2016. Disponível em: <https://
www.ateomomento.com.br/o-que-e-requisito-funcional/> Acesso em: 04 de abr. de 2021.