PIM V - Análise e Desenvolvimento de Sitemas - Sistema de Reserva de Equipamentos

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas 
 
 
ALUNO - RA 
 
 
 
 
 
 
 
 
 
SISTEMA DE RESERVA DE EMPRÉSTIMO DE EQUIPAMENTOS E RECURSOS 
AUDIOVISUAIS - SREERA 
 
 
 
 
 
 
 
 
 
 
 
 
 
XXXXX 
XXXX
ALUNO - RA 
 
 
 
 
SISTEMA DE RESERVA DE EMPRÉSTIMO DE EQUIPAMENTOS E RECURSOS 
AUDIOVISUAIS - SREERA 
 
 
 
 
 
 
 
 
 
Projeto Integrado Multidisciplinar para obtenção do 
título de graduação no Curso Superior de Tecnologia 
em Análise e Desenvolvimento de Sistemas 
apresentado à Universidade Paulista – UNIP EaD. 
 
Orientadora: Profa. XXXXXXXXXX 
 
 
 
 
 
 
 
 
 
 
 
 
XXXXXX 
XXXX
RESUMO 
O projeto ao qual se refere esse trabalho diz respeito a elaboração de um 
sistema de reservas de equipamentos e recursos audiovisuais encomendado pelo 
Colégio Vencer Sempre. O Software tem o intuito de tornar o controle de empréstimos 
de equipamentos e recursos audiovisuais automatizado, assertivo e fácil de utilizar. 
Neste estudo será apresentado todo o ciclo para contratação da empresa de software, 
desde o mapeamento dos agentes econômicos, viabilidade econômica para 
implementação, prazo de entrega e investimento, além a parte de desenvolvimento 
como estudos requisitos funcionais e não funcionais e de negociação, tipo de 
metodologia usada, os testes de requisitos, passando pela parte do desenvolvimento 
de interface até a descrição técnica dos fundamentos de programação orientada a 
objetos: objeto, classes, herança e polimorfismo. Todos esses fundamentos e 
conceitos serão utilizados no contexto do software em questão. 
Será utilizada a metodologia MPS-BR para capacitação dos processos de maturidade 
e qualidade no processo de criação de software. O modelo MPS-BR tem como base 
a NBR ISO/IEC 12207 – Processo de Ciclo de Vida de Software, pelas emendas 1 e 
2 da norma internacional ISO/IEC 12207 e pela ISO/IEC 15504 – Avaliação de 
Processo, sendo assim este modelo esta em conformidade com as normas 
internacionais. 
 
PALAVRAS CHAVE: Economia e Mercado, Engenharia de Software, Projeto de 
Interface com Usuário, Programação Orientada a Objeto, MPS-BR. 
 
 
 
 
 
 
 
 
ABSTRACT 
The project to which this work refers concerns the development of a reservation 
system for equipment and audiovisual resources commissioned by Colégio Vencer 
Sempre. The Software aims to make the control of equipment loans and audiovisual 
resources automated, assertive and easy to use. 
In this study, the entire cycle for contracting the software company will be presented, 
from the mapping of economic agents, economic feasibility for implementation, 
delivery and investment time, in addition to the development part such as studies of 
functional and non-functional requirements and negotiation, type of methodology 
used, requirements testing, going through the interface development part to the 
technical description of the fundamentals of object-oriented programming: object, 
classes, inheritance and polymorphism. All these fundamentals and concepts will be 
used in the context of the software in question. 
The MPS-BR methodology will be used to train the maturity and quality processes in 
the software creation process. The MPS-BR model is based on NBR ISO/IEC 12207 
- Software Life Cycle Process, amendments 1 and 2 of the international standard 
ISO/IEC 12207 and ISO/IEC 15504 - Process Assessment, so this model it complies 
with international standards. 
 
KEYWORDS: Economics and Market, Software Engineering, User Interface Design, 
Object Oriented Programming, MPS-BR. 
 
 
 
 
 
 
 
SUMÁRIO 
INTRODUÇÃO ...................................................................................................................... 5 
1. ANÁLISE DE FATORES ECONOMICOS E DE MERCADO ....................................... 6 
1.1. Agentes Econômicos ......................................................................................... 7 
1.2. Viabilidade, prazo e investimento ..................................................................... 8 
2. ENGENHARIA DE SOFTWARE ............................................................................... 10 
2.1. Requisitos funcionais e não funcionais ......................................................... 11 
2.2. Norma ISO/IEC 9126 ......................................................................................... 12 
2.3. Metodologia de processo de software – MPS.BR e o SREERA .................... 14 
2.4. Roteiro de testes .............................................................................................. 17 
3. INTERFACE ............................................................................................................. 19 
4. OBJETO, CLASSE, HERANÇA E POLIMORFISMO ............................................... 21 
CONCLUSÃO...................................................................................................................... 24 
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 25 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5 
INTRODUÇÃO 
Este estudo refere-se a um projeto de software de reservas de equipamentos 
audiovisuais de uma escola de ensino fundamental e médio chamada Colégio Vencer 
Sempre. Ao longo dos últimos anos a área educacional está aderindo gradativamente 
a utilização de ferramentas audiovisuais para criar uma dinâmica que apoie 
professores e alunos no processo de ensino e aprendizagem. 
Essa instituição de ensino disponibiliza vários tipos de equipamentos como: 
Datashow, TV com VCR, TV com DVD, Projetor de Slides, Sistemas de Áudio-
Microfone, Caixa Amplificada, Notebooks, Kits Multimidia, entre outros. 
Até o presente momento eles não tem um controle informatizado das alocações 
e isso está causando muitos desencontros e situações desagradáveis. Para evitar 
essas situações que será criado o SREERA – Sistema de Reserva de Empréstimo de 
Equipamento e Recursos Audiovisuais. 
A intensão é auxiliar professores, coordenadores a organizarem as alocações de 
equipamentos e recursos de maneira mais assertiva. Os usuários desse sistema 
poderão fazer o login, verificar a disponibilidade dos equipamentos e posteriormente 
marcarem a opção para utilizar na data desejada ou que melhor se adeque as suas 
necessidades. 
Para desenvolver este trabalho farei uso dos conhecimentos adquiridos durante 
o último bimestre onde tive contato com as disciplinas de Economia e Mercado, 
Engenharia de Software II, Projeto de Interface com o Usuário e Programação 
Orientada a Objetos I. 
Usando os conhecimentos de Economia e Mercado farei um mapeamento dos 
agentes econômicos que atuam diretamente com a empresa de software que 
fornecerá o sistema e apresentar a viabilidade econômica para implementação do 
projeto, indicando o prazo para conclusão e o investimento financeiro necessário para 
isso. 
Na disciplina de Engenharia de Software II vou propor a metodologia frente as 
normas de desenvolvimento de software qual será mais adequada, já que empresa 
de software ainda é pequena. Também vamos propor quais requisitos funcionais e 
6 
não funcionais e de negócios serão necessários para a confecção do sistema, além 
de elaborar um roteiro de teste para os requisitos mencionados. 
Projeto de Interface de Usuários vai servir como base para o desenvolvimento 
de protótipos de interface com alta fidelidade, detalhando o funcionamento da entrada, 
processamento e saída de dados. 
A Programação Orientada a Objetos I é disciplina que vai auxiliar a descrever 
tecnicamente os fundamentos sobre Objetos, Classes, Herança e Polimorfismo 
identificando esses conceitos no projeto do SREERA. 
 
1. ANÁLISE DE FATORES ECONOMICOS E DE MERCADO 
É fundamental a discussão da economia no desenvolvimento da sociedade, 
Adam Smith considerado o pai da economia moderna, foi um filósofo e economista 
Britânico nascido na Escócia. 
Sua obra mais conhecida, A Riquezadas Nações, continua sendo até hoje uma 
referencia para gerações de economistas, ele procurou demonstrar que a riqueza das 
nações era fruto da soma da atuação de cada indivíduo que, movidos por seus 
interesses promoviam o crescimento econômico e a inovação tecnológica. 
Desta forma, para ilustrar melhor essa ideia, vou destacar um trecho do livro O 
Livro da Economia (2013, p.66): 
No inicio do seu livro A Riqueza das Nações, Smith explica as 
diferenças entre a produção de uma coisa realizada por uma 
pessoa em todas as etapas e aquela realizada por diversas 
pessoas com uma tarefa para cada uma. Em 1976, Smith notou 
que se um homem faz um alfinete passando por todas as etapas 
necessárias ele “talvez não faça um alfinete em um dia”. Mas, ao 
dividir o processo entre diversos homens, cada qual se dedicando 
a uma só etapa, muitos alfinetes seriam feitos em um dia. 
 
 
 
7 
1.1. Agentes Econômicos 
Iniciaremos a análise dos fatores econômicos e de mercado subdividindo os 
diferentes atores do cenário econômico em: 
 Famílias 
 Empresas 
 Governo 
 Setor Externo 
Na nossa análise vamos considerar empresas e famílias a qual ao meu ver se 
encaixa melhor a relação de troca de bens e serviços no caso especifico da 
contratação da empresa de software. 
O agente econômico Colégio Vencer Sempre demandou um serviço, da 
empresa de software, que por sua vez gerou renda para seus sócios e funcionários, 
os quais usaram essa renda para consumir outros bens e serviços. 
Segundo o livro texto de Economia e Mercado podemos afirmar sobre as 
famílias que: 
As Famílias englobam os agentes consumidores, isto é, 
são elas que detêm a posse dos fatores de produção, 
necessários às empresas para a criação de bens e 
serviços. (Manzalli, M. F.;Ditticio C, 2020, p.19). 
 
Abaixo, na figura 1, podemos verificar como acontecem as interações entre os 
agentes econômicos no mercado de bens e serviços: onde as empresas oferecem 
bens e serviços que são adquiridos pelas famílias; e no mercado de fatores de 
produção: fatores como trabalho, terra ou capital, oferecidos pelas famílias, que são 
contratados ou adquiridos pelas empresas. 
 
 
 
 
 
 
8 
Figura 1 – Fluxo Circular da Renda 
 Fonte: Dicionário Financeiro 
 
 
1.2. Viabilidade, prazo e investimento 
Este é um projeto de pequeno porte, seu desenvolvimento e programação não 
devem ter um custo muito alto, mas claro que para ter qualidade e garantir que esse 
software seja usado e possa ser atualizado posteriormente, é preciso adotar alguns 
processos de desenvolvimento, seguindo as normas de qualidade, para que mesmo 
sem o suporte da nossa empresa, ainda sim este software possa ser alterado por 
outros programadores. Este processo requer um pouco mais de investimento, porém 
garante a vida útil do software e faz valer o investimento. 
Usaremos como base da viabilidade e custo do projeto o tempo estimado para 
conclusão do projeto em relação ao salário dos desenvolvedores (analistas, 
programadores e os testers), assim como os custos da infraestrutura para 
desenvolver o projeto. 
O projeto vai contar com algumas fases: 
 Fase de diagnóstico 
 Concepção do projeto 
 Levantamento e análise de requisitos 
 Fase de desenvolvimento 
 Etapa de manutenção 
9 
 
Fase de diagnóstico: é o momento que temos o primeiro contato com o 
“problema” a necessidade do cliente, é importante extrair o máximo de informações. 
Concepção do projeto: a equipe passa a idealizar soluções definindo o 
problema a ser resolvido 
Levantamento e análise requisitos: os desenvolvedores constroem a 
documentação com informações detalhadas das funcionalidades do sistema. 
Fase de desenvolvimento: nessa etapa as primeiras linhas de código começam 
a ser escritas. 
Fase de manutenção: após a implementação do produto, iniciam-se as 
manutenções e ajustes do sistema visando uma melhor experiencia para o usuário. 
 
Abaixo será descrito o prazo e valor do investimento: 
 Planejamento (Fase de diagnóstico, Concepção do projeto e Análise de 
requisitos): 15 dias; 
 Desenvolvimento: 30 dias; 
 Manutenção (teste e entrega): 15 dias; 
 
Tempo total estimado para a conclusão do projeto: 60 dias 
 
De acordo com o levantamento feito em Março de 2022, segue abaixo os 
valores dos salários praticados: 
 
Quadro 1 – tabela de média dos salários em 03/2022 
Cargo Salário 
Gerente de Projetos R$ 4.700,00 
Analista de Sistema R$ 3.100,00 
Programador R$ 2.800,00 
Tester R$ 2.000,00 
Fonte: próprio Autor 2022 
 
 
 
10 
A equipe para este projeto será composta por: 
 Gerente de projetos: 1 profissional 
 Analista de Sistemas: 1 profissionais 
 Programador: 1 profissionais 
 Testers: 1 profissional 
 
Quadro 2 – Custo para desenvolvimento do software 03/2022 
Cargo Salário 
Gerente de Projetos R$ 4.700,00 
Analista de Sistema R$ 3.100,00 
Programador R$ 2.800,00 
Tester R$ 2.000,00 
Total por mês R$ 12.600,00 
Total para o Projeto R$ 25.200,00 
Fonte: próprio Autor 2022 
 
O custo para o desenvolvimento do projeto é composto pelo valor dos salários 
dos envolvidos durante os 60 dias. Custo total: R$ 25.200,00. 
Dos quais poderão ser pagos 50% na assinatura do contrato e o restante na 
entrega do software. 
 
Resumo das condições comerciais: 
 Prazo para o Projeto: 60 dias. 
 Valor total: R$ 25.200,00. 
 Forma de pagamento: 50% na assinatura do contrato e o restante na 
entrega do software. 
 
2. ENGENHARIA DE SOFTWARE 
Todo projeto de software precisa seguir práticas de gerência de projetos, 
buscando organização, produtividade e qualidade. A Engenharia de Software 
oferece mecanismos para se planejar e gerenciar processos de desenvolvimento de 
software com qualidade e atendendo as necessidades do solicitante de software. 
11 
No ramo da Engenharia de software é muito usado tecnologias, métodos ágeis 
e práticas que englobam banco de dados, ferramentas de programação, linguagens 
de programação, padrões de projeto de software, processos de software e qualidade 
de software. Dentre os fundamentos científicos, o uso de modelos abstratos é muito 
usado para guiar o os profissionais envolvidos no projeto, especificações, 
implementação e manutenção do software, na busca incessante da melhoria de 
qualidade dos produtos. 
 
Segundo (Sommerville, I.,2011) a engenharia de software é importante por dois 
motivos: 
 Cada vez mais indivíduos dependem dos sistemas de software avançado, 
temos de ser capazes de produzir sistemas confiáveis econômica e 
rapidamente. 
 O custo a longo prazo é menor quando se usar os métodos e técnicas de 
engenharia de software. 
 
O processo de software é uma sequencia de atividades que leva à produção de 
um produto de software levando em conta quatro atividades fundamentais: 
 Especificação de Software - clientes e engenheiros definem o software a ser 
produzido e as restrições da sua operação. 
 Desenvolvimento de software – o software é projetado e programado. 
 Validação de software – onde o software é verificado para garantir que é o 
produto cumpri as solicitações do cliente. 
 Evolução do software – fase em que o software é modificado para atender os 
requisitos do cliente e do mercado. 
 
2.1. Requisitos funcionais e não funcionais 
Em engenharia de software os conceitos de requisitos funcionais e não 
funcionais são essenciais para o sucesso do software, eles representam as funções, 
propriedades e as possíveis restrições que o software precisa ter para atingir os 
objetivos. 
 
12 
Conceitos de Requisitos Funcionais e não Funcionais: 
 Requisitos Funcionais – este requisito refere-se ao comportamento do 
software, diz respeito as entradas, processamentos e saídas que o sistema vai 
desempenhar. Os requisitos funcionais podem ser divididos em requisitos de 
negócio (requisitos referentes ao negócio/atividade em que o software será 
usado), requisitos de usuário (este diz respeito às necessidades do usuário ao 
utilizaro sistema) e requisitos técnicos (sobre as necessidades ou restrições 
técnicas). 
 Requisitos não funcionais – são os critérios que qualificam os requisitos 
funcionais, estão diretamente ligadas as restrições e qualidades especificas. 
Requisitos Funcionais do SREERA 
 O Software deve permitir o controle das reservas dos equipamentos, 
registrando data e hora, usuário solicitante e local de uso do equipamento. 
 O sistema deverá ter a possibilidades de se cadastrar usuários, salas e 
equipamentos 
 O sistema deverá ter alertas para usuários com relação as suas reservas. 
 O software será desenvolvido em C#, utilizando o Visual Studio da Microsoft. 
Requisitos Não Funcionais do SREERA 
 Funcionalidade 
 Confiabilidade 
 Usabilidade 
 Eficiência 
 Manutenibilidade 
 Portabilidade 
 
2.2. Norma ISO/IEC 9126 
A norma ISO/IEC 9126 é uma referência técnica mundialmente utilizada para 
garantir a qualidade de um produto de software que foi elaborada pela ISO e pelo 
IEC em 1991 e posteriormente, 1996, publicada no Brasil como NBR/13596. 
13 
Dentro desta norma constam seis categorias de características de qualidade do 
produto de software divididas em subcaracterísticas que são avaliadas por métricas 
quantitativas. A norma propõe um conjunto de atributos de qualidade chamado de 
modelo de referência, conforme a figura abaixo. 
Figura 2 – Modelo de Referência da norma ISO/9126 
 
Fonte: Wikipedia. 
Essa norma para qualidade de produto de software define um conjunto de 
parâmetros com o objetivo de padronizar as normas da família 9000 da ISO e 
consiste nas seguintes partes: 
 Modelo de Qualidade. 
 Métricas Externas. 
 Métrica Internas. 
 Métricas de qualidade de uso 
Os conceitos e detalhes de cada característica e sua composição são descritos 
abaixo: 
 Funcionalidade - descreve o que o software faz. 
Subcaracterísticas: Adequação/Acurácia/Interoperabilidade/Segurança de 
acesso/Conformidade. 
 
 Confiabilidade – descreve a capacidade do software realizar as tarefas sem 
falhas. 
Subcaracterísticas: Maturidade/Tolerância a falhas/Recuperabilidade. 
 
 Usabilidade – descreve quão fácil se dá a interação do usuário com o 
sistema. 
Subcaracterísticas: 
Inteligibilidade/Apresentabilidade/Operacionalidade/Atratividade. 
 
14 
 Eficiência – Descreve a relação do desempenho e os recursos utilizados. 
Subcaracterísticas: Tempo de resposta/Utilização de recursos. 
 
 Manutenibilidade – Descreva a facilidade das alterações no sistema. 
Subcaracterísticas: Analisabilidade/Modificabilidade/Estabilidade/Testabilidade. 
 
2.3. Metodologia de processo de software – MPS.BR e o SREERA 
O MPS.BR é uma metodologia de Melhoria de Processo de Software Brasileiro, 
foi criado em 2003 pela Associação para Promoção da Excelência do Software 
Brasileiro (Softex), com o objetivo de incentivar pequenas e médias empresas 
brasileiras de produção de software a implantar um modelo de qualidade e melhoria 
de software. 
O Modelo MPS.BR tem o selo de qualidade de software reconhecido somente 
no Brasil, mas nem por isso deixa de ser um ótimo modelo, pois ele está alinhado 
aos padrões e normas internacionais ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 
25000 e também com o CMMI. Somente a título de curiosidade o MPS.BR é um 
requisito básico para empresas que pretendem fornecer software para o governo 
Brasileiro. 
O alinhamento do MPS.BR com os demais modelos de qualidade 
internacionais ajuda as empresas a compreenderem os componentes envolvidos no 
desenvolvimento, na aquisição de software e também a executarem projetos de 
forma mais eficiente. 
O modelo do MPS.BR está dividido em 4 componentes, 7 níveis de maturidade 
e 19 processos distribuídos nos níveis. 
 Componentes – são os modelos de referência para desenvolvimento, 
aquisição e avaliação de software. 
 Níveis de maturidade – são a classificação que as empresas recebem de 
acordo com a avaliação. 
 Processos distribuídos nos níveis – são as atividades que as empresas 
precisam praticar para atingir os níveis de maturidade do modelo. 
 
15 
Estrutura dos modelos de referência do MPS.BR: 
Modelo de referência para software: Contém as definições dos níveis de 
maturidade, processos e atributos do processo para aquisição e implementação, em 
nível de boas práticas e sugestões de implementação. 
Modelo de referência para serviços: Contém as definições dos níveis de 
maturidade, processos e atributos do processo para a prestação de serviços de 
informática. Está em conformidade com os requisitos da norma ISO/IEC 15504-2. 
Método de avaliação: Contém os requisitos para os avaliadores-líderes, os 
avaliadores-adjuntos e as Instituições Avaliadoras (IAs). Está em conformidade com 
os requisitos da norma ISO/IEC 15504-2. 
Modelo de negócio: Descreve as regras de negócio para implementação dos 
modelos de referência de software e de serviços pelas instituições implementadoras 
e para o método de avaliação pelas instituições avaliadoras (IA). 
Níveis de maturidade do modelo MPS.BR: 
Os níveis de maturidade são indicadores da evolução da qualidade de melhoria 
da implementação de processos de software na empresa. 
Os 7 níveis de maturidade de software são: 
 Nível A: Otimizado 
-Não há processos específicos. 
 
 Nível B: Gerenciado Quantitativamente 
-Não há processos específicos. 
 
 Nível C: Definido 
-Gerência de decisões. 
-Gerência de riscos. 
-Desenvolvimento para reutilização. 
 
 
16 
 Nível D: Largamente Definido 
-Desenvolvimento de requisitos. 
-Projeto e construção do produto. 
-Integração do produto. 
-Verificação. 
-Validação. 
 
 Nível 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. 
 
 Nível F: Gerenciado 
-Garantia de qualidade. 
-Gerência da configuração. 
-Medição 
-Aquisição 
-Gerência de portifólio 
 
 Nível G: Parcialmente Gerenciado 
-Gerência de projetos. 
-Gerência de requisitos. 
 
Metodologia escolhida para o SREERA – MPS.BR 
A empresa responsável pela implantação do software ainda está em fase 
inicial, é uma empresa nova, ainda em fase de estruturação, por isso a norma 
MPS.BR é que melhor se enquadra para o desenvolvimento deste software, ainda 
assim ela atenderá as normas brasileiras com a implementação do de nível de 
maturidade G – Parcialmente Gerenciado com os processos de Gerência de projetos 
e Gerência de requisitos. 
 
17 
A figura abaixo ilustra bem os níveis de maturidade: 
Figura 3 – níveis de maturidade do MPS.BR 
 
Fonte: Promove Soluções 
 
2.4. Roteiro de testes 
 
Caso do Teste: CT1 
Localização Tela de Login 
Caso do teste Efetuar o Login 
Procedimento 1- Abrir o sistema pelo icone na área de trabalho 
2- Caso seu usuário não esteja cadastrado, cadastre o 
usuário 
3- Efetue o login digitando usuário e senha 
Resultado esperado Login efetuado com sucesso! 
Exceção usuário não cadastrado ou nome de usuário e senha 
inválida 
18 
 
 
 
 
Caso do Teste: CT2 
Localização Tela cadastro 
Caso do teste Cadastrar equipamento 
Procedimento 1- a partir da tela principal clicar em cadastro 
2- cadastro de equipamento 
3- efetue o cadastro do equipamento 
Resultado esperado Equipamento cadastrado com sucesso 
Exceção Equipamento não cadastrado 
Caso do Teste: CT3 
Localização Tela reserva 
Caso do teste Reservar equipamento 
Procedimento 1- a partir da tela principal clicar em reservar 
equipamento 
2- efetuar a reserva preenchendo modelo do 
equipamento, data, hora e sala desejada 
3- revisar os dados e confirmar 
Resultado esperado A reserva foi efetuada com sucesso 
Exceção A reserva não foi efetuada 
Caso do Teste: CT4 
Localização Tela reserva 
Caso do teste Consultar reserva 
Procedimento 1- a partir da tela principal clicar em consultar reserva 
2- efetuar a consulta pesquisando por 
data/usuário/equipamento 
Resultado esperadoMostra resultado da consulta na tela 
Exceção Reserva não encontrada 
Caso do Teste: CT5 
Localização Tela reserva 
Caso do teste Editar reserva 
Procedimento 1- a partir da tela inicial clicar em consultar reserva 
2- efetuar a consulta pesquisando por 
data/usuário/equipamento 
3- clicar no botão editar reservar 
4- alterar conforme a necessidade 
5- revisar e confirmar alteração 
6- reserva alterada 
Resultado esperado Editar reserva 
Exceção Esse usuário não tem permissão para alterar essa reserva 
19 
3. INTERFACE 
É pela interface que o usuário interage como sistema, é por ela que o usuário 
se comunica com o sistema, entretanto segundo Rocha e Baranauskas (2003), este 
conceito evoluiu e levou a inclusão de aspectos cognitivos e emocionais do usuário 
durante a comunicação. 
Figura 4 – Tela de Login 
 
Fonte: próprio autor 
 
Figura 5 – Cadastro de Usuário 
 
Fonte: próprio autor 
20 
Figura 6 – Cadastro de Equipamento 
 
Fonte: próprio autor 
 
Figura 6 – Tela de Reserva 
 
Fonte: próprio autor 
21 
4. OBJETO, CLASSE, HERANÇA E POLIMORFISMO 
 
Figura 7 – Classes e Objetos 
 
Fonte: próprio autor 
OBJETO 
Objetos podem ser considerados uma imitação do comportamento intrínseco 
de entidades reais. Tal como em sistemas reais, em uma POO não é viável abrir um 
objeto e olhar em seu interior e tampouco alterar seu estado. Nesse paradigma, a 
única forma de fazer evoluir um programa é permitir que objetos compartilhem dados 
entre si a partir de trocas explícitas de mensagens. Como exemplo, considere a 
seguinte situação: A esposa de um jovem casal se encontra no segundo mês de 
gravidez. No meio da noite, a grávida acorda com uma azia terrível. Como é natural, 
a mulher pede que seu marido providencie um antiácido para ela. Sob a ótica da 
POO, poderíamos representar a cena da seguinte maneira: 
• O objeto marido recebe uma mensagem do objeto esposa. 
• O objeto marido responde à mensagem da esposa mediante uma ação 
(buscar antiácido). 
 • A esposa não tem que dizer ao marido onde ele deve procurar, é 
responsabilidade dele procurar pelo antiácido. 
• Ao objeto esposa basta ter emitido uma mensagem ao objeto marido. 
 
CLASSES 
O desenvolvimento de classes é o resultado da abstração. Uma vez definidos 
os devidos escopos, teremos condições de pensar em termos de classes. É fácil 
22 
notar que muitos objetos possuem características estruturais semelhantes, embora 
todo objeto seja único. Um bom exemplo disso são os objetos que recebem a 
denominação genérica de “carro”. 
Todos os carros possuem uma mesma estrutura, ou seja, todos os objetos 
carro implementam os mesmos métodos e mantêm informações sobre os mesmos 
atributos. O fato de que cada objeto mantém seus próprios atributos de forma 
encapsulada confere uma identidade única a cada objeto e também permite que dois 
objetos possam, eventualmente, possuir valores iguais para seus atributos. Esses 
grupos de objetos com estruturas semelhantes são definidos em termos de classes. 
 Classes consistem na unidade básica da construção de um programa OO e 
definem o conjunto de atributos mantidos por um conjunto de objetos e o 
comportamento que esses objetos devem respeitar. 
Figura 8 – representação de Classes 
 
Fonte: macorati.net 
POLIMORFISMO 
O polimorfismo está relacionado com o conceito de herança, especificamente 
em relação a métodos. O mecanismo de herança permite a criação de classes a 
partir de outras já existentes com relações “é-um-tipo-de”, de forma que, a partir de 
uma classe genérica, classes mais especializadas possam ser criadas. Quando uma 
nova classe necessita de todos os atributos e métodos de uma já existente, porém a 
nova classe possui a execução de um ou mais métodos diferenciados, é possível 
herdarmos todos os métodos e atributos da classe original e realizar a alteração do 
comportamento do método somente na nova. 
23 
A partir desse momento, para todo objeto que se utilizar da nova classe e 
executar o método em questão, será executado o método novo, e não o original. O 
polimorfismo permite a manipulação de instâncias de classes que herdam de uma 
mesma classe ancestral de forma unificada: podemos escrever métodos que 
recebam instâncias de uma classe C, e os mesmos métodos serão capazes de 
processar instâncias de qualquer classe que herde da classe C, já que qualquer 
classe que herde de C é-um-tipo-de C. 
Desta forma, duas ou mais classes derivadas de uma mesma superclasse 
podem invocar métodos que têm o mesmo nome mas comportamentos distintos, 
especializados para cada classe derivada, usando para tanto uma referência a um 
objeto do tipo da superclasse. Polimorfismo, ter muitas formas. Em termos de 
programação, muitas formas significa que um único nome pode representar um 
código diferente, selecionado por algum mecanismo automático. 
HERANÇA 
Herança é um recurso das linguagens de programação orientadas a objeto que 
permite a definição de uma classe base que, por sua vez, fornece uma 
funcionalidade específica (dados e comportamento), e a definição de classes 
derivadas que herdam ou substituem essa funcionalidade. 
Figura 9 – Herança 
 
Fonte: Alura.com 
 
24 
CONCLUSÃO 
Ao apresentar este estudo e trabalhar na solução dos problemas propostos no 
PIM V, foi possível entender melhor a maneira como as disciplinas estudas no ultimo 
bimestre se integram e em alguns momentos até se fundem no mesmo sentido. 
O Software de agendamento de equipamentos, segue as normas de qualidade 
de software, no caso aqui foi escolhida a MPS.BR, além de manter as boas práticas 
em relação a criação de códigos, manutenção e ciclo de vida do software. 
O SREERA – Sistema de Reserva de Empréstimo de Equipamento e Recursos 
Audiovisuais, será implementado de maneira satisfatória atendendo o cliente e 
contribuindo para a organização e melhoria dos serviços no Colégio Vencer Sempre. 
Neste trabalho foi utilizado os conhecimentos com as disciplinas de Economia e 
Mercado, Engenharia de Software II, Projeto de Interface com o Usuário e 
Programação Orientada a Objetos I. 
Usando os conhecimentos de Economia e Mercado foi mapeado dos agentes 
econômicos que atuam diretamente com a empresa de software, além de apresentar 
a viabilidade econômica para implementação do projeto, indicando o prazo para 
conclusão e o investimento financeiro necessário para isso. 
Em Engenharia de Software II foi proposto a metodologia de desenvolvimento 
de software MPS.BR, já que empresa de software ainda é pequena. Foi descrito 
também os requisitos funcionais e não funcionais necessários para a confecção do 
sistema, além de elaborar um roteiro de teste para os requisitos mencionados. 
Projeto de Interface de Usuários vai servir como base para o desenvolvimento 
de protótipos de interface com alta fidelidade, detalhando o funcionamento da entrada, 
processamento e saída de dados. 
A Programação Orientada a Objetos I é disciplina foi feito um descritivo 
tecnicamente os fundamentos sobre Objetos, Classes, Herança e Polimorfismo. 
 
 
 
25 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
Manzalli, Maurício Felippe; Ditticio, Claudio. Economia e Mercado. 1 Ed. São Paulo: 
Editora Sol, 2020. 
O Livro da Economia. Tradução de Carlos Mendes Rosa. São Paulo: Globo, 2013. 
Smith, A. A riqueza das nações: investigação sobra a natureza e suas causas. 
Coleção os Economistas. São Paulo: Abril Cultural, 1983. 
Sommerville, I. Engenharia de Software. 9 ed. São Paulo: Pearson, 2011. 
Rocha, H.V.; BARANAUSKAS, M. C. C. Design e avaliação de interfaces humano-
computador. Campinas: Nied/Unicamp,2003. 
 
Figuras e Ilustrações 
Figura 1 – Fluxo Circular de Renda 
Disponível em <https://www.dicionariofinanceiro.com/o-que-e-fluxo-circular-de-
renda/>, acessado em 30/03/2022 
Figura 2 – Modelo de Referência da norma ISO 9126 
Disponível em:<https://pt.wikipedia.org/wiki/ISO/IEC_9126>, acessado em 
10/04/2022. 
Figura 3 – Níveis de maturidade do MPS.BR 
Disponível em <https://promovesolucoes.com/mps-br/niveis-mps-br/>,acessado em 
12/04/2022. 
Figura 8 – Representação de Classes 
Disponível em < https://www.macoratti.net/18/09/c_base2.htm>, acessado em 
15/04/2022. 
Figura 9 – Herança 
Disponível em < https://www.alura.com.br/conteudo/csharp-parte-3-heranca-
interfaces-polimorfismo>, acessado em 15/04/2022.