PIM V

Prévia do material em texto

SÃO PAULO / SP 
2023 
 
 
 
 
UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
 
 
Curso Superior de Tecnologia em 
 
Análise e Desenvolvimento de Sistemas 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABÍLIO JOSE GOMES FERREIRA - 2278382 
CAMILLA REGINA ANDRADE - 2328941 
JULIO CESAR SANTOS GOMES - 219339 
LUAN CARDOSO DE JESUS – 2200284 
LUCAS HENRIQUE DA SILVA LEMOS - 2121004 
RODRIGO VIEIROS SILLOS – 2278208 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Sistema de Reserva de Equipamentos 
 
 
 
 
SÃO PAULO / SP 
2023 
 
 
 
Projeto Integrado Multidisciplinar em 
Análise e Desenvolvimento de Projetos 
 
 
 
 
 
 
 
 
 
 
 
 
 
Projeto Integrado Multidisciplinar para obtenção do título de tecnólogo em Análise e 
desenvolvimento de sistema, apresentado à Universidade Paulista – UNIP EaD. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABÍLIO JOSE GOMES FERREIRA - 2278382 
CAMILLA REGINA ANDRADE - 2328941 
JULIO CESAR SANTOS GOMES - 219339 
LUAN CARDOSO DE JESUS – 2200284 
LUCAS HENRIQUE DA SILVA LEMOS - 2121004 
RODRIGO VIEIROS SILLOS – 2278208 
 
 
Sistema de Reserva de Equipamentos 
 
 
 
 
 
 
 
RESUMO 
Este trabalho académico visa desenhar todo o ciclo de vida de um contrato de 
software que irá gerir a reserva de equipamentos audiovisuais para escolas 
primárias e secundárias, em particular o "Colégio Vencer Sempre", desde o 
orçamento, previsão de custos, cronograma de entrega, divisão do projeto e suas 
fases, Passam pelas etapas de investigação, análise e documentação de requisitos 
(funcionais e não funcionais), protótipos de alta fidelidade, especificações de 
interface, até as etapas mais técnicas de codificação em linguagens orientadas a 
objetos, testes, entrega de produto, implementação com usuários. Todo o processo 
de software e método utilizado na implementação do sistema serão documentados 
para obtenção de um produto de alta qualidade, utilizando o método MPS.br para ter 
acesso a práticas de engenharia de software, testes (incluindo scripts inteiros, casos 
de sucesso e falha, tabelas de execução de testes), negociações de mercado e pós-
venda, visando o crescimento de novas empresas de software que buscam se 
consolidar no mercado. 
 
Palavras-chaves: Sistema para reservas. Programação orientada à objetos. Projeto 
De software. Roteiro de testes. MPS.br. 
 
 
 
 
ABSTRACT 
 
This academic work aims to design the entire life cycle of a software contract that will 
manage the reservation of audiovisual equipment for primary and secondary schools, 
in particular "Colégio Vencer Semper", from the budget, cost forecast, delivery 
schedule, division of the project and its phases, going through the stages of 
investigation, analysis and documentation of requirements (functional and non-
functional), high-fidelity prototypes, interface specifications, to the more technical 
stages of coding in object-oriented languages, testing, delivery of product, 
implementation with users. The entire software process and method used to 
implement the system will be documented to obtain a high quality product, using the 
MPS.br method to gain access to software engineering practices, tests (including 
entire scripts, success and failure cases , test execution tables), market and after-
sales negotiations, aiming at the growth of new software companies that seek to 
consolidate themselves in the market.implementations, all in line with best practices 
and based on the software quality approach. 
Keywords: Reservation system. Object Oriented Programming. Software Project. 
Test roadmap. MPS.br 
 
 
 
SUMÁRIO 
1 INTRODUÇÃO ..................................................................................................... 3 
2 DESENVOLVIMENTO ......................................................................................... 4 
2.1 Economia e Mercado ...................................................................................... 4 
2.1.1 Sistema ......................................................................................................... 4 
2.1.2 Viabilidade econômica .................................................................................. 4 
2.1.3 Projeto do software ....................................................................................... 5 
2.1.4 Prazo para a conclusão do projeto................................................................ 6 
2.1.5 Investimento financeiro necessário ............................................................... 6 
3 Engenharia de Software II ................................................................................. 7 
3.1.1 Especificações de interfaces ......................................................................... 8 
3.1.2 Metodologia MPS.BR .................................................................................... 9 
3.1.3 Planejamento de teste para os requisitos funcionais .................................. 11 
3.2 Projeto de Interface com o Usuário ............................................................ 16 
3.3 Programação Orientada a Objetos I ............................................................ 18 
3.3.1 Classes e objetos ........................................................................................ 18 
3.3.2 Herança e Polimorfismo .............................................................................. 19 
4 CONCLUSÃO .................................................................................................... 20 
REFERÊNCIAS ......................................................................................................... 21 
 3 
1 INTRODUÇÃO 
O presente projeto integrador multidisciplinar tem sua essência na 
então necessidade de criação de um novo sistema de reservas de equipamentos 
para os docentes da instituição de ensino, tendo em vista que o sistema em uso se 
tornou obsoleto, por ser relativamente antigo e não atender às necessidades atuais 
do público alvo. A partir da implementação do novo sistema, tornar-se-á possível a 
realização de reservas de equipamentos de forma remota, ou seja, sem que haja a 
necessidade de o docente estar presencialmente na instituição. As reservas poderão 
ser feitas a partir de qualquer dispositivo conectado à rede mundial de 
computadores, desde que o usuário se autentique no sistema a partir das 
credenciais que detém na instituição. 
 
 4 
2 DESENVOLVIMENTO 
2.1 ECONOMIA E MERCADO 
 
2.1.1 Sistema 
Em desenvolvimento de software, um agente de software é 
um programa de computador que pode operar autonomamente e efetuar tarefas 
singulares sem a direta supervisão humana. Num contexto geral duas comunidades 
científicas se destacam com trabalhos e pesquisas na área de agente de software. A 
comunidade da Inteligência Artificial Distribuída e a comunidade dos Sistemas 
Distribuídos. Sabemos que o desenvolvedor é o profissional que escreve e cria 
softwares, que podem ser websites, programas de computadores pessoais ou 
empresariais, sistemas operacionais, redes sociais, aplicativos de celular e outros 
dispositivos, entre outras infinitas possibilidades. 
O Colégio Vencer Sempre, tem coordenadores responsáveis em 
contratar desenvolvedores capacitados e experiente para desenvolver o software 
que será um sistema que vai dar apoio aos professores da escola e ajudará os 
alunos desta escola. 
2.1.2 Viabilidade econômica 
Compra e/ou licenciamento: 
A maioria dos softwares são vendidos com licenças percentuais e 
demandam um pagamento anual para o recebimento dos últimos updates e acesso 
ao suporte. Além disso, conforme a necessidade da empresa aumenta, podem ser 
necessárias licenças extras para novos usuários. 
Instalação e infraestrutura: 
Por vezes um setup inicial é requerido, mesmo que não seja 
desejado customizar ou integrar o software com outros sistemas. No geral, este 
custo envolve a instalação de um melhor hardware, a configuração da basede 
dados e a garantia que todos os usuários terão o software funcionando 
 5 
perfeitamente. 
Customização e integração: 
Softwares proprietários tendem a ser mais customizáveis. Essa 
característica faz com que compradores desse tipo de serviço gastem mais com 
customização e integração. Como consequência disso, quanto mais customizado é 
um programa, mais complementos e upgrades serão necessários. 
Migração e treinamento: 
Estes custos estão presentes em praticamente toda aquisição de 
novas ferramentas e tecnologias. Uma correta migração inibe problemas futuros e 
colaboradores bem treinados extrairão o melhor do novo software. 
Manutenção e suporte: 
Pacotes podem ser negociados já na aquisição e representam entre 
15% a 22% do preço de licenciamento inicial. Nesses pacotes estão: a manutenção 
anual, melhorias e correções de falhas. 
Por fim, a maior viabilidade financeira vai ser em contratar a equipe 
e investir em computadores próprios para a escola para um laboratório especifico. 
2.1.3 Projeto do software 
Um modelo de processo de software é uma representação abstrata 
de um processo de software. Cada modelo de processo representa um processo a 
partir de uma perspectiva particular, de uma maneira que proporciona apenas 
informações parciais sobre o processo (SOMMERVILLE 1995). Abaixo constam 
alguns modelos de processos de softwares que serão abordados no artigo: 
• O modelo em cascata; 
• Desenvolvimento evolucionário; 
• Desenvolvimento iterativo o Modelo de desenvolvimento espiral; o 
Modelo de desenvolvimento incremental. 
• Desenvolvimento baseado em componentes existem outros 
modelos além dos citados acima, que Pressman (2006) coloca em seu livro, mas o 
artigo não entrará em detalhes nesses modelos ele são: 
• Modelo Incremental; 
• Modelo RAD; 
• Modelo de Desenvolvimento Concorrente; 
 6 
• Modelo de Métodos Formais; 
• Processo Unificado 
2.1.4 Prazo para a conclusão do projeto 
A escola tem um prazo de três meses para concluir este projeto. 
2.1.5 Investimento financeiro necessário 
A definição de um escopo pode fazer um software variar de 30 mil 
reais em demandas maiores. Dessa forma, para chegar em um software com alto 
investimento, não precisa de muito esforço. 
 
 
De maneira grosseira, 60% dos custos são custos de 
desenvolvimento, 40% são custos de teste. 
 7 
3 ENGENHARIA DE SOFTWARE II 
Definição 
Requisitos não-funcionais são os requisitos relacionados ao uso da 
aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, 
disponibilidade, manutenibilidade e tecnologias envolvidas. Não é preciso o cliente 
dizer sobre eles, pois eles são características mínimas de um software de qualidade, 
ficando a cargo do desenvolvedor optar por atender esses requisitos ou não. 
Demonstram qualidade acerca dos serviços ou funções 
disponibilizadas pelo sistema. Ex.: tempo, o processo de desenvolvimento, padrões, 
etc. 
Surgem conforme a necessidade dos usuários, em razão de 
orçamento e outros fatores. 
Podem estar relacionados à confiabilidade, tempo de resposta e 
espaço nas mídias de armazenamento disponíveis. 
Caso ocorra falha do não atendimento a um requisito não funcional, 
poderá tornar todo o sistema ineficaz. Ex.: requisito confiabilidade em um sistema de 
controle de voos. 
Classificação dos Requisitos Não-Funcionais 
Requisitos de produtos: Requisitos que especificam o 
comportamento do produto. Ex. portabilidade; tempo na execução; confiabilidade, 
mobilidade, etc. 
Requisitos da organização: Requisitos decorrentes de políticas e 
procedimentos corporativos. Ex. padrões, infraestrutura, etc. 
Requisitos externos: Requisitos decorrentes de fatores externos ao 
sistema e ao processo de desenvolvimento. Ex. requisitos de interoperabilidade, 
legislação, localização geográfica etc. 
Requisitos de facilidade de uso. Ex.: usuários deverão operar o 
sistema após um determinado tempo de treinamento. 
Requisitos de eficiência. Ex.: o sistema deverá processar n 
requisições por um determinado tempo. 
Requisitos de confiabilidade. Ex.: o sistema deverá ter alta 
disponibilidade, por. Exemplo, 99% do tempo. 
Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer 
 8 
plataforma. 
Requisitos de entregue.: um relatório de acompanhamento deverá 
ser fornecido toda segunda-feira. 
Requisitos de implementação.: Ex.: o sistema deverá ser 
desenvolvido na linguagem Java. 
Requisitos de padrões.: Ex. uso de programação orientada a objeto 
sob a plataforma A. 
Requisitos de interoperabilidade.:Ex. o sistema deverá se comunicar 
com o SQL Server. 
Requisitos éticos. Ex.: o sistema não apresentará aos usuários 
quaisquer dados de cunho privativo. 
Requisitos legais. Ex.: o sistema deverá atender às normas legais, 
tais como padrões, leis, etc. 
Requisitos de Integração. Ex.: o sistema integra com outra 
aplicação. > 
3.1.1 Especificações de interfaces 
Os métodos formais aplicados na área da Engenharia 
de Software veem-no como uma construção matemática e procuram descrever o 
comportamento dos sistemas de forma rigorosa e abstracta, libertando assim a 
especificação de pormenores de implementação concreta. Em IHC, para além 
do Software é necessário considerar também o utilizador, com as suas 
características de imprevisibilidade, imprecisão, incorreção, etc. Deste modo, a 
investigação na área tem sido conduzida basicamente segundo uma de duas 
perspectivas: 
• Numa, é dado ênfase ao ponto de vista do utilizador. Tendo 
como principal preocupação os aspectos psicológicos, cognitivos e sociológicos da 
interação, procuram desenvolver-se teorias que modelem o seu comportamento. À 
classe de modelos produzidos nesta área de estudo chamaremos Modelos 
Cognitivos. 
• Na outra, os investigadores focam mais o ponto de vista do 
sistema, preocupando-se com os aspectos relacionados com a Engenharia 
de Software, considerando muitas vezes que os aspectos ergonómicos só por 
 9 
experimentação poderão ser analisados. Temos então Modelos 
Estruturais e Modelos de Especificação da Interface (principalmente Especificação 
do Diálogo). 
Independentemente do seu tipo, um bom modelo deverá possuir, 
idealmente, as seguintes características: 
• A especificação deverá ser de fácil leitura. 
• Deverá ser preciso e formal, não deixando dúvidas quanto ao 
comportamento do sistema. 
• Deverá facilitar a verificação da consistência. 
• Deverá ser suficientemente poderoso, de modo a permitir 
especificar sistemas minimamente complexos. 
• Deverá especificar apenas o que o sistema faz e não como o 
faz. 
• Deverá permitir a construção de um protótipo a partir da 
especificação da interface. 
• A sua estrutura deverá estar relacionada com o modelo mental 
que o utilizador tem do sistema. 
 
3.1.2 Metodologia MPS.BR 
A metodologia MPS.br foi criada 2003, pela coordenação da 
SOFTEX -Associação da Promoção da Excelência do Software Brasileiro, com o 
apoio do MCTI - Ministério da Ciência, Tecnologia e Inovação, da FINEP - 
Financiadora de Estudos e Projetos e do SEBRAE - Serviço Brasileiro de Apoio às 
Micro e Pequena Empresas e BID/FUMIN - Banco Interamericano de 
Desenvolvimento, com o intuito de contribuir para um a maior competitividade das 
micro e pequenas empresas brasileiras produtoras de softwares, apoiando-as 
através da divulgação e adoção de modelos de melhoria de processo de software. 
Com a aplicação da metodologia, o mercado produziria produtos e 
serviços com padrões de qualidades internacionais. Nesta metodologia, é realizada 
uma avaliação e certificação das empresas em qualidade de processo de software, 
assim como as realizadas pela metodologia CMMI, porém com adaptação a 
realidade brasileira. 
 10 
Prevê uma graduação de níveis para as empresas avaliadas. O 
MPS.br tem em seu escopo um conjunto de modelos referenciais, guias de 
implementação, avaliação e aquisição. Essas guias podem ser obtidasgratuitamente 
no site da SOFTEX. A metodologia MPS.br tende a ser mais leve em relação a os 
demais modelos existentes, atingindo um maior número de empresas que tenham 
capacidade em alcançá-las. 
Os custos para aplicação são considerados médios, e por isso foi a 
metodologia escolhida para aplicação na empresa que produzirá o software para 
reserva de equipamentos. O MPS.br tem como base técnica as normas IS 
O/IEC12207:2008 [ISO/IEC, 2008a], IS O/IEC 20000:2011 [ISO/IEC, 2011] e 
ISO/IEC15504-2 [ISO/IEC, 2003]. 
A implementação do MPS-BR exige a aplicação de 
vários processos referentes ao produto de software. Para alcançarmos o nível F 
precisamos implementar os seguintes processo: 
Gerência de Requisitos (Evolução do nível G) – O propósito do 
processo gerência de Requisitos é gerenciar os requisitos do produto e dos 
componentes do produto do projeto e identificar inconsistências entre os requisitos, 
os planos do projeto e os produtos de trabalho do projeto; 
Gerência de Projetos (Evolução do nível G) ? O propósito do 
processo gerência de Projetos é estabelecer e manter planos que definem 
as atividades, recursos e responsabilidades do projeto, bem como 
prover informações sobre o andamento do projeto que permitam 
a realização de correções quando houver desvios significativos no desempenho do 
projeto; 
Gerência de Portfólio (Opcional)? O propósito desse processo é 
iniciar e manter projetos que sejam necessários, suficientes e sustentáveis, de forma 
a atender os objetivos estratégicos da organização, é dispensável para empresas 
que tem apenas um produto e não tem a necessidade de gerenciar vários projetos 
diferentes ao mesmo tempo; 
Gerência de Aquisição (Opcional)? O propósito desse processo é 
gerenciar a aquisição de produtos que satisfaçam às necessidades expressas 
pelo adquirente, é opcional para empresas que não necessitam adquirir produtos a 
parte; 
Gerência de Configuração? Tem o propósito de estabelecer e 
 11 
manter a integridade de todos os produtos de trabalho de um processo ou projeto e 
disponibilizá-lo a todos os envolvidos; 
Gerência de Medição? Tem o propósito 
de coletar, armazenar, analisar e relatar os dados relativos aos produtos 
desenvolvidos e aos processos implementados na organização e em seus projetos, 
de forma a apoiar os objetivos organizacionais; 
Gerência da Qualidade? O propósito desse processo é assegurar 
que os produtos de trabalho e a execução dos processos estão em conformidades 
com os planos e recursos definidos. 
A implantação do modelo MPS-BR tem como principal benefício o 
melhoramento na qualidade dos produtos aumentando assim a competitividade da 
empresa em relação aos outros produtos da mesma linha de mercado. 
 
3.1.3 Planejamento de teste para os requisitos funcionais 
Teste de Software 
Teste de software é uma das atividades do processo de 
desenvolvimento de sistema de software que visa executar um programa de modo 
sistemático com o objetivo de encontrar falhas. Perceba que isto requer verificação e 
validação de software. Nesse sentido, definir quando as atividades de verificação e 
validação iniciam e terminam, como os atributos de qualidade serão avaliados e 
como os releases do software serão controlados, são questões que devem ser 
acompanhadas ao longo do processo de software. 
Vale ressaltar que teste não deve ser a última atividade do processo 
de desenvolvimento de software. Ela ocorre durante todo o processo, como 
exemplificado na visão geral do processo RUP (Rational Unified Process) mostrado 
na Figura 1. 
 12 
 
 
Figura 1. Visão geral do RUP. 
 
E, além de encontrar falhas, testes objetivam aumentar a 
confiabilidade de um sistema de software, isto é, aumentar a probabilidade de que 
um sistema continuará funcionando sem falhas durante um período de tempo. 
Embora seja desejável testar um sistema por completo, deve-se ter 
em mente que a atividade de teste assegura apenas encontrar falhas se ela(s) 
existirem, mas não asseguram sua ausência. Portanto, as atividades devem ser 
disciplinadas a fim de identificar a maioria dos erros existentes. Note que realizar os 
testes de software implica em responder às questões: 
1. Quais atributos da qualidade deverão ser testados? 
2. Quem realizará os testes? 
3. Quais recursos serão utilizados? 
4. Quais as dependências entre os atributos de qualidade? 
5. Quais as dependências entre as atividades de 
desenvolvimento? 
6. Como o processo e a qualidade do sistema de software serão 
acompanhados? 
 
Na seção seguinte, um exemplo do conjunto de seções de um plano 
de teste é apresentado com o objetivo de ilustrar como as informações pertinentes 
 13 
ao teste de software poderiam ser tratadas e documentas. Não há, portanto, o 
objetivo de ser completo, pois cada sistema possui suas peculiaridades que devem 
ser consideradas caso a caso. 
Plano de Teste 
O plano de teste é um dos documentos produzidos na condução de 
um projeto. Ele funciona como: 
Um ‘integrador’ entre diversas atividades de testes no projeto; 
Mecanismo de comunicação para os stakeholders (i.e. a equipe de 
testes e outros interessados); 
Guia para execução e controle das atividades de testes. 
 
O plano de teste, que pode ser elaborado pelo gerente de projeto ou 
gerente de testes, visa planejar as atividades a serem realizadas, definir os métodos 
a serem empregados, planejar a capacidade necessária, estabelecer métricas e 
formas de acompanhamento do processo. Nesse sentido, deve conter: 
Introdução com identificação do projeto (definições, abreviações, 
referências), definição de escopo e objetivos; 
Conjunto de requisitos a serem testados; 
Tipos de testes a serem realizados e ferramentas utilizadas; 
Recursos utilizados nos testes; 
Cronograma de atividades (e definição de marcos de projeto). 
 
Em outras palavras, um plano de teste deve definir: 
Os itens a serem testados: o escopo e objetivos do plano devem ser 
estabelecidos no início do projeto. 
Atividades e recursos a serem empregados: as estratégias de testes 
e recursos utilizados devem ser definidas, bem como toda e qualquer restrição 
imposta sobre as atividades e/ou recursos. 
Os tipos de testes a serem realizados e ferramentas empregadas: os 
tipos de testes e a ordem cronológica de sua ocorrência são estabelecidos no plano. 
Critérios para avaliar os resultados obtidos: métricas devem ser 
definidas para acompanhar os resultados alcançados. 
 
 14 
Perceba que o planejamento é necessário a fim de antecipar o que 
pode ocorrer e, portanto, provisionar os recursos necessários nos momentos 
adequados. Isto significa coordenar o processo de teste de modo a perseguir a meta 
de qualidade do produto (sistema de software). 
Exemplificando o Plano de Teste 
O plano de teste contém um conjunto de informações que permite ao 
gerente de projeto não apenas coordenar as atividades de testes de um projeto, mas 
também monitorar seu progresso e verificar se o executado está em conformidade 
com o planejado. A Tabela 1 apresenta uma relação dos itens consideradas 
imprescindíveis em um plano de teste. A relação de itens não pressupõe a intenção 
de ser completo, mas de apontar os itens considerados como obrigatórios num plano 
de teste de uma instituição. 
 
Itens de um Plano de Teste Conteúdo 
1. Introdução Contém uma identificação do projeto, 
descrição dos objetivos do documento, 
o público ao qual ele se destina e 
escopo do projeto a ser desenvolvido. 
Pode adicionalmente conter termos e 
abreviações usadas, além de informar 
como o plano deve evoluir. 
2. Requisitos a serem 
testados 
Esta seção descreve em linhas gerais 
o conjunto de requisitos a serem 
testados no projeto a ser desenvolvido, 
comunicando o que deve ser 
verificado. Exemplos de requisitos a 
serem testados são: desempenho, 
segurança, interface de usuário, 
controle de acesso, funcionalidades.3. Estratégias e ferramentas 
de teste 
Apresenta um conjunto de tipos de 
testes a serem realizados, respectivas 
técnicas empregadas e critério de 
finalização de teste. Além disso, é 
 15 
listado o conjunto de ferramentas 
utilizadas. 
4. Equipe e infraestrutura Contém descrição da equipe e da 
infraestrutura utilizada para o 
desenvolvimento das atividades de 
testes, incluindo: pessoal, 
equipamentos, software de apoio, 
materiais, dentre outros. Isto visa 
garantir uma estrutura adequada para 
a execução das atividades de testes 
previstas no plano. 
 
5. Cronograma de atividades Contém uma descrição de marcos 
importantes (milestones) das 
atividades (incluindo as datas de início 
e fim da atividade). Apenas marcos 
relevantes devem ser listados, ou seja, 
aqueles que contribuirão nas 
atividades de testes. Por exemplo: 
projeto de testes, execução de testes 
ou avaliação de testes. 
6.Documentação 
complementar 
Apresenta-se uma relação dos 
documentos pertinentes ao projeto. 
Tabela 1 – Relação de itens de um plano de Teste. 
 
O conteúdo exato das seções que compõem um plano de teste, 
geralmente, difere de instituição para instituição. 
 
 16 
 
3.2 PROJETO DE INTERFACE COM O USUÁRIO 
 
Um protótipo de usuário de alta fidelidade ainda é uma simulação, 
no entanto, agora parece muito real. De fato, em muitos protótipos de alta fidelidade, 
você precisa prestar muita atenção para ver que não é real. Os dados que você vê 
são muito realistas, mas não são reais, o que significa que não são ao vivo. 
Por exemplo, se eu procuro um tipo específico de mountain bike, ela 
sempre volta com o mesmo conjunto de bicicletas de montanha, mas se eu prestar 
muita atenção, não são as bicicletas reais que eu pedi. Percebo que sempre que 
procuro sempre são as mesmas, independentemente do preço ou estilo que eu 
especificar. Agora, se você estiver tentando testar a relevância dos resultados da 
pesquisa, essa não seria a ferramenta certa para o trabalho, mas se você estiver 
tentando obter uma boa experiência geral de compra, provavelmente isso é bom, 
rápido e fácil de executar. 
Existem muitas ferramentas para criar protótipos de usuário de alta 
fidelidade – para todos os tipos de dispositivos, como por exemplo, o Sketch (meu 
preferido), Adobe XD e Figma. As ferramentas são geralmente projetadas para 
designers. Também é o caso de alguns designers preferirem codificar manualmente 
seus protótipos de usuário de alta fidelidade, o que é bom desde que sejam rápidos 
e estejam dispostos a considerar o protótipo como descartável. 
 
 
Entrada: Atividade de captar e agrupar os dados primários. Em um 
 17 
sistema de folha de pagamento, a entrada pode corresponder aos cartões de horas 
dos empregados. Processamento: Conversão dos dados em saídas úteis. Envolve 
cálculos, comparações, ações alternativas e guarda de dados para uso futuro. 
Saída: Envolve a produção de informações úteis, na forma de documentos, relatórios 
e dados de transações. Para um computador as impressoras e as configurações de 
tela são dispositivos de saída comuns. Feedback: é uma saída utilizada para ajustes 
ou modificações nas atividades de entrada ou processamento. O feedback é 
importante para administradores e tomadores de decisão. 
É composto por software, hardware, bancos de dados, 
telecomunicações, pessoas e procedimentos, que estão configurados para coletar, 
manipular, armazenar e processar dados em informação. 
 18 
 
3.3 PROGRAMAÇÃO ORIENTADA A OBJETOS I 
A primeira linguagem de programação que utiliza os conceitos de 
programação orientada à objetos foi a Simula 67, criada por Ole-Johan Dahl eKristen 
Nygaard em 1967, porém esse paradigma de programação só passou a ser 
largamente utilizado na atualidade. A maioria das linguagens de programações 
atuais utilizam orientação à objetos, podendo citar: Java, C#, C++, Deplhi entre 
outras, que apesar de terem diferenças entre si, seguem os mesmos princípios e 
conceitos. 
A ideia principal da POO é aproximar o mundo real do mundo 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. 
Uma das grandes vantagens da programação orientada à objetos 
está na facilidade de 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. 
3.3.1 Classes e objetos 
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 à 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 e m uma programação convencional. 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, adquirir 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 
 19 
objeto (chamados aqui de métodos). As cl asses definem um tipo de dado no 
sistema, sendo formada 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. No sistema de reservas 
de equipamentos temos a classe “Cadastro” que possui como atributo o campo 
nome, e possui como métodos: “Cancelar”, “Excluir” e “Sal var e Novo”. A partir da 
classe “Cadastro” foram criados os objetos “Cadastro de Usuários”, “Inventário” e 
“Reservas. 
3.3.2 Herança e Polimorfismo 
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. 
O polimorfismo tem como significado “várias formas”. Para a 
programação orientada à 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. Ainda sobre o projeto do sistema de 
equipamentos para reserva do “Colégio Vencer Sempre”, a classe “Cadastro” 
comporta os atributos e a implementação dos métodos “Cancelar”, “Excluir” e “Salvar 
e Novo” estão contidas nela, não sendo necessário implementar tais métodos no s 
objetos filhos “Cadastro de Usuários”, “Inventário” e “Reservas”, utilizando assim, 
herança e polimorfismo na projeção do sistema. 
 
 
 20 
4 CONCLUSÃO 
Diante a proposta de ensino do projeto integrador multidisciplinar 
podemos concluir dizendo que a utilização de uma programação orientada à objetos 
será parte deste projeto, visando diminuição no tempo de codificação, reutilização de 
código fonte, utilizando classes, herança e polimorfismo em sua constituição, 
gerando ainda custos menores na produção do sistema. E a elaboração deste 
trabalho traz para o aluno o conhecimento aprofundado sobre o desenvolvimento da 
pesquisa cientifica. 
. 
 21 
REFERÊNCIAS 
 
UNIP - Universidade Paulista. Economia e Mercado. São Paulo, 2020.UNIP - Universidade Paulista. Programação Orientada à Objetos I. São Paulo, 
2020. 
UNIP - Universidade Pau lista. Projeto de Interface com o Usuário. São Paulo, 
2020. 
UNIP - Universidade Paulista. Engenharia de Software II. São Paulo, 2020. 
ANICHE, Maurício. Test-Driven Development: Teste e Design no mundo real. 
SãoPaulo: Casa do Código, 2014. 
PRESSMAN, ROGER S. Engenharia de Software. McGra w-Hill, 2006. 
SINTES, Tony. Aprenda programação orientada a objetos em 21 dias. São 
Paulo: PearsonEducation do Brasil, 2002.