PIM V - Sistema de Reserva de Equipamentos (Colégio Vencer Sempre)

Prévia do material em texto

Unip EaD 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
Sistema de Reserva de Equipamentos 
(Colégio Vencer Sempre) 
 
 
 
 
 
 
 
 
 
Polo Paulista 
2020 
 
1 
 
 
 
Unip EaD 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
Sistema de Reserva de Equipamentos 
(Colégio Vencer Sempre) 
 
 
Silvio Agnoleto 
RA 1962510 
Curso: Análise e Desenvolvimento de 
Sistemas 
Semestre: 3º 
 
 
Polo Paulista 
2020 
 
2 
 
RESUMO 
Com os conhecimentos adquiridos nas disciplinas de Economia e Mercado, 
Engenharia de Software II, Projeto de Interface com Usuários e Programação 
Orientada a Objetos I; foi possível desenvolver a capacidade de identificação das 
necessidades bem como a proposição de uma solução técnica para o seguinte caso: 
um projeto de um sistema de reserva de equipamentos audiovisuais, que tem como 
propósito agilizar e controlar o empréstimo de equipamentos e recursos de apoio aos 
professores. Elencar, argumentar e justificar a utilização de cada metodologia utilizada 
nesse contexto foi o principal propósito desse trabalho, adquirir o conhecimento das 
etapas que compreendem o ciclo de vida do produto em questão, para poder com 
eficácia atender, custo, benefício, prazo e qualidade numa só tacada. Sendo assim, 
foram mapeados os agentes econômicos que atuam diretamente com a empresa e 
apresentado a viabilidade econômica para a implementação do projeto, indicando o 
prazo para a conclusão do projeto e o investimento financeiro necessário. Foram 
levantados os requisitos funcionais e não funcionais necessários, assim como as 
especificações de interfaces e das mensagens a serem exibidas, é nesta fase que se 
deve angariar o máximo de subsídios para suprir o projeto até a sua fase de 
encerramento. Requisitos de software é uma declaração do que um sistema deve ser, 
e quais características devem possuir. Um estudo sobre qual metodologia de 
qualidade de software, também foi realizado a fim de escolher qual metodologia frente 
as normas internacionais ISO, CMMI, MPS.br seria mais adequada à empresa, além 
disso, como o intuito do nosso trabalho era abranger todas as etapas do ciclo de vida 
do produto, não poderia ficar de fora a etapa de testes para os requisitos funcionais e 
o roteiro utilizado para eles. Finalizando a parte técnica do processo, foi desenvolvido 
um protótipo de interfaces com alta fidelidade explicando cada detalhe do 
funcionamento. Se fosse para fazer uma análise mais criteriosa da solução em si, eu 
diria, que apresentado os custos para confecção do software, a inviabilidade de 
desenvolvimento é praticamente certa, porém, poderíamos contornar isso, com 
parcerias e também desenvolvendo uma aplicação que pudesse ser generalista e de 
fácil utilização para um grupo bem maior de clientes e não apenas a instituição Vencer 
Sempre, mas esse assunto fica pra outra estória...até lá! 
Palavras-chave: Polimorfismo; Programação Orientada à Objetos; Protótipo; 
Requisitos Funcionais; Viabilidade Econômica. 
3 
 
ABSTRACT 
 With the knowledge acquired in the disciplines of Economics and Market, 
Software Engineering II, User Interface Design and Object Oriented Programming I; it 
was possible to develop the ability to identify needs as well as the proposition of a 
technical solution for the following case: a project for an audiovisual equipment 
reservation system, which aims to streamline and control the loan of equipment and 
resources to support teachers . List, argue and justify the use of each methodology 
used in this context was the main purpose of this work, to acquire knowledge of the 
stages that comprise the life cycle of the product in question, in order to be able to 
effectively meet, cost, benefit, time and quality in a just putt. Therefore, the economic 
agents that work directly with the company were mapped and the economic feasibility 
for the implementation of the project was presented, indicating the deadline for the 
completion of the project and the necessary financial investment. The necessary 
functional and non-functional requirements were raised, as well as the specifications 
of interfaces and messages to be displayed, it is in this phase that the maximum 
subsidies must be raised to supply the project until its closing phase. Software 
requirements is a statement of what a system should be, and what characteristics it 
should have. A study on which software quality methodology was also carried out in 
order to choose which methodology according to the international standards ISO, 
CMMI, MPS.br would be more suitable for the company, in addition, as the purpose of 
our work was to cover all stages of the product life cycle, the testing stage for the 
functional requirements and the roadmap used for them could not be left out. Finishing 
the technical part of the process, a prototype of interfaces with high fidelity was 
developed explaining every detail of the operation. If it were to make a more careful 
analysis of the solution itself, I would say that given the costs for making the software, 
the unfeasibility of development is practically certain, however, we could get around 
this, with partnerships and also developing an application that could be generalist. and 
easy to use for a much larger group of customers and not just the Vencer Semper 
institution, but this subject is for another story ... until then! 
 
Keywords: Polymorphism; Object Oriented Programming; Prototype; 
Functional Requirements; Economic viability. 
 
4 
 
SUMÁRIO 
1 INTRODUÇÃO ............................................................................................... 05 
2 DESENVOLVIMENTO ................................................................................... 06 
2.1 Estudo de Viabilidade ..................................................................................... 06 
2.2 Requisitos ....................................................................................................... 07 
2.3 Modelos de Qualidade .................................................................................... 09 
2.4 Testes ............................................................................................................. 10 
2.5 Protótipos de interfaces com alta fidelidade .................................................... 12 
2.5.1 Início e Login ...................................................................................................12 
2.5.2 Perfil ................................................................................................................13 
2.5.3 Equipamentos .................................................................................................14 
2.5.4 Agenda ............................................................................................................16 
2.5.5 Notificações e Chat .........................................................................................17 
2.5.6 Configurações .................................................................................................18 
2.5.7 Menu ...............................................................................................................19 
2.5.8 Fim ..................................................................................................................20 
2.6 Programação Orientada a Objetos – Elementos ............................................. 21 
2.6.1 Objeto e Classe .............................................................................................. 21 
2.6.2 Herança e Polimorfismo .................................................................................. 23 
3 CONCLUSÃO ................................................................................................. 26 
REFERÊNCIAS ..............................................................................................27 
 
5 
 
INTRODUÇÃO 
Tão importante quanto o conhecimento técnico, está a habilidade prática 
relacionada ao mesmo, para o desenvolvimento correto das aplicações em problemas 
existentes, proporcionando assim, soluções bem mais do que satisfatórias. Afinal de 
contas a teoria e a prática já demonstraram que nem sempre falam a mesma língua, 
e estar alinhado em ambas é essencial para o bom desempenho acadêmico e 
profissional. 
A proposta a seguir, visa através de técnicas aprendidas neste último bimestre, 
transformar conhecimento adquirido em “SABER”, para isso será necessário aplicar 
na pratica o aprendizado em questão. 
Através das disciplinas de Economia e Mercado, Engenharia de Software II, 
Projeto de Interface com Usuários e Programação Orientada a Objetos I; 
desenvolveremos capacidade de identificação das necessidades bem como a 
proposição de uma solução técnica para um projeto de um sistema de reserva de 
equipamentos audiovisuais. 
Antigamente, o professor para ministrar suas aulas utilizava apenas giz, lousa, 
livros e seu conhecimento para apresentar o conteúdo de sua disciplina aos seus 
alunos, considerando o aumento de informações a serem apresentadas em cada 
disciplina, o comportamento da nova geração dos alunos que são totalmente ligados 
à tecnologia e às ferramentas de interação humano-computador, a área educacional 
está aderindo gradativamente na utilização ferramentas audiovisuais para apoiar a 
dinâmica das aulas, o trabalho a seguir tem como propósito agilizar e controlar o 
empréstimo de equipamentos e recursos de apoio aos professores. 
 
 
 
 
 
 
6 
 
DESENVOLVIMENTO 
Estudo de Viabilidade 
O estudo de viabilidade indica se o esforço em desenvolver a ideia vale a pena, 
visa tanto a tomada de decisão, como a sugestão de possíveis alternativas de solução, 
contempla se o projeto pode ou não ser feito, se o produto final irá ou não beneficiar 
os usuários interessados, e qual das alternativas entre as possíveis soluções é a 
melhor. 
Baseado no nosso conhecimento técnico, devemos observar se os prazos dos 
projetos são razoáveis. Alguns projetos são iniciados com prazos específicos e 
precisamos determinar se os prazos são obrigatórios ou apenas desejáveis pelo 
cliente. Além disso devemos julgar se os possíveis benefícios de solucionar o 
problema são ou não vantajosos, tão logo os requisitos específicos e soluções sejam 
identificados, devemos levar em consideração os custos e benefícios de cada 
alternativa, isso é chamado de análise de custo-benefício. 
Com esses conceitos definidos, segue o estudo de viabilidade: 
Tabela 1 – Estudo Viabilidade 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
7 
 
Requisitos 
Figura 1 - Stakeholders 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
Figura 2 – Requisitos Funcionais 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
Figura 3 – Requisitos Funcionais (continuação) 
 
 
 
 
 
 
 
 
 
8 
 
Figura 4 – Requisitos Não Funcionais 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Figura 5 – Especificação de Interfaces 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
Figura 6 – Modelo Banco de Dados 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
9 
 
Modelos de qualidade 
Atualmente existem modelos de qualidade baseados na engenharia que 
ajudam as empresas a estabelecer e seguir padrões. Podemos citar como exemplos 
destes modelos o CMMi (Capability Maturity Model Integration ou Modelo Integrado 
de Maturidade em Capacitação) e o MPS.BR - Processo de Melhoria do Software 
Brasileiro. O objetivo principal dos modelos de qualidade é fazer com que toda a 
equipe esteja trabalhando no mesmo foco, assegurando um processo de software 
com mais qualidade e garantir a produção de software mais competitivo no mercado 
interno e externo. 
A utilização desse tipo de metodologia pode trazer muitos benefícios, tais como: 
redução de custos com retrabalho/manutenção, diminuição de erros entregues na 
versão final ao cliente etc. Com mais tempo disponível, a equipe pode investir em 
melhorias e novos planejamentos. 
Apesar dos dois modelos de desenvolvimento terem sido criados com o mesmo 
propósito, o foco de atuação dos modelos é diferente um do outro. Enquanto o 
MPS.BR é um modelo criado em função das médias e pequenas empresas, o CMMi 
tem um foco global mais voltado para as empresas de maior porte. Contudo apesar 
dessas diferenças é possível afirmar que na realidade brasileira os modelos são 
complementares. 
As médias e pequenas empresas adotam o MPS.BR com o objetivo de 
conseguir alcançar uma padronização e qualidade no processo com mais velocidade 
e de baixo custo. Uma vez alcançada essa padronização a empresa já se encontra 
qualificada para tentar obter a certificação CMMi. 
Nossa empresa adotará o modelo de qualidade MPS.BR, e uma vez já sabendo 
das dificuldades na implantação, estamos buscando mitigar os problemas futuros, 
formando um grupo de pessoas muito interessadas e com baixíssima resistência a 
mudanças e aceitação de novas regras e padrões. Optamos também por fazer essa 
implantação num momento de condição financeira favorável. Apesar de sermos uma 
empresa nova, nosso planejamento rigoroso nos permite tal aquisição, mesmo com 
os altos custos de certificação. 
 
 
 
 
 
 
10 
 
Testes 
Em teste de software é impossível testar exaustivamente uma aplicação, pois 
cobrir todos os cenários seria muito custoso. A não ser que a aplicação que está sendo 
testada seja muito simples e com parâmetros de entradas limitados. Nesse caso, 
devemos calcular o esforço dos testes baseando-se nos riscos e prioridades. Antes 
de iniciarmos uma sprint é essencial realizarmos um planejamento das atividades de 
testes que consiste em: 
 Definir um cronograma de atividades: quais as atividades que devem ser 
realizadas, as etapas a serem seguidas e a ordem cronológica de execução; 
 Alocação de recursos: quem realiza as atividades e quais 
ferramentas/técnicas serão utilizadas; 
 Definir marcos de projeto: data de início e fim de cada macro atividade. 
 
Tabela 2 – Roteiro de Testes 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
11 
 
Tabela 3 – Roteiro de Testes (continuação) 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
No exemplo acima (Tabelas 2 e 3), o roteiro de testes possui duas localizações: 
“Menu > Equipamentos” e “Menu > Configurações”. A primeira localização possui um 
objeto de teste (Operações referentes à inclusão de equipamentos), o qual possui 
dois casos de teste diferentes, mas que estão relacionados ao mesmo domínio do 
objeto de teste. A segunda localização também possui um objeto de teste (Verificação 
da mudança de permissões), o qual possui um caso de teste. 
Observe que cada caso de teste possui um contador, este contador irá 
identificar o caso de teste no momento de elaborar o Relatório de Defeitos. Com o 
contador, o desenvolvedor poderá reproduzir cada passo dos casos de teste que não 
passaram. 
Outro item do caso de teste é a criticidade, este item é opcional, no entanto é 
bastante importante para uma boa realização dos testes. Com ele é possível ordenar 
os casos de teste de acordo com a sua criticalidade para o projeto. Os casos de teste 
com criticidade mais altas devem ser executados antes, para não correr o risco de 
eles não serem executados por falta de tempo. 
 
 
 
 
 
 
 
12 
 
Protótipos de interfaces com alta fidelidade 
Início 
Com o propósito de homenagear aqueles que apenas com seu amor pelo ato 
de ensinar e com muitos poucos recursos sustentaram gerações e gerações de 
alunos, a abertura do aplicativo BOOKED, vem ilustrada com recursos tecnológicos 
de outrora, materializando um conceito de que a tecnologia é um meio importante detransmitir conhecimento, porém são os metres e professores que detém a guarda e a 
didática correta para o compartilhamento do mesmo. 
O app consiste numa solução com a finalidade de agilizar e controlar o 
empréstimo de equipamentos e recursos de apoio aos professores e dos demais 
colaboradores. 
Figura 7 – Tela Início 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada/Processamento/Saída – Não 
 
Login 
Iniciando a descrição das telas do app, temos a tela de Login. O cadastro de 
usuários pode ser feito através de API ou SDK do Facebook, Twitter ou Google. Caso 
o usuário não possua conta alguma nesses sites ou se a empresa (instituição de 
ensino) preferir, pode ser utilizado o Active Directory (AD) para tal. Se nenhuma das 
alternativas atender ao cliente, o cadastro pode ser feito manualmente pelo 
Administrador, caso a caso. 
 
13 
 
Figura 8 – Tela Login 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada: Usuário e Senha 
Processamento: Validação dos Dados 
Saída: Aceite de Entrada no Sistema e Direcionamento para Tela Perfil 
 
Perfil 
Uma vez logado, o app direcionará para a tela do Perfil. Nessa tela você tem 
suas informações pessoais e profissionais atuais, que você poderá escolher se são 
compartilhadas ou não com aqueles que interagem com você nessa solução. Além de 
visualizar a composição de ensino que está relacionada a você neste momento. Quais 
são as turmas, os locais (sala, laboratório, auditório, quadra) onde as aulas são 
ministradas, bem como os horários. 
Figura 9 – Tela Perfil 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
14 
 
Entrada: Dados Pessoais do Usuário e sua Composição de Ensino 
Processamento: Validação do Conteúdo dos Campos 
Saída: Gravação no Banco de Dados 
 
Equipamentos 
Através do menu, representado pelas três linhas paralelas no canto superior 
esquerdo, você navegará por todo o sistema, dando flexibilidade a solução, evitando 
assim intermináveis idas e vindas de telas e botões. Lembrando que a quantidade de 
professores com mais de 45 anos de idade varia entre 20-30% do total por instituição 
em média dependendo do grupo escolar (Tabela 4) e apresentar soluções que 
facilitem a experiencia de todos e torne o aprendizado de novas tecnologias algo mais 
agradável é uma exigência atual. 
Tabela 4 – Estatísticas MEC / Faixa Etária Professores 
 
 
 
 
 
 
Existem duas formas de se cadastrar um equipamento: A primeira é feita pela 
instituição através do Administrador, geralmente quando se inicia o uso da ferramenta, 
cadastrando todos os recursos existentes e disponíveis de uma única vez. A segunda 
é feita pelo próprio usuário, já na rotina do dia-a-dia. Qual a diferença? O cadastro 
feito pelo Administrador é disponibilizado automaticamente aos usuários, já o feito 
pelo usuário, fica em standby até que o Administrador faça uma revisão dos dados 
inseridos, podendo ou não liberar o mesmo para ser visualizado. 
Como cada item pode vir a ter mais de uma unidade, foi criada uma tabela 
paralela para administrar o estoque e vinculada a isso uma tabela de cores que irão 
15 
 
fazer fundo a imagem mostrando se o bem está disponível em sua total quantidade, 
em quantidade parcial ou se todas as unidade daquele recurso estão reservadas ou 
em uso. 
AZUL – Quantidade do Bem Totalmente Disponível. 
Por exemplo, se houver três roteadores no estoque, os três estão aguardando 
para ser utilizados. 
VERDE – Quantidade do Bem Parcialmente Disponível. 
Agora ao invés de três roteadores, apenas dois estão disponíveis para ser 
utilizados. 
LARANJA – Quantidade do Bem Esgotado para Reserva. 
Existem dois tipos de usuários aqueles que estão sempre se antecipando as 
situações e aqueles que só lembram das premissas momentos antes da necessidade. 
Para este segundo caso é que essa tabela de cores cairá como uma luva. Ela tem a 
finalidade de evitar uma etapa do processo, que é o agendamento. Você não precisa 
entrar no item, depois ir para a Agenda procurar a hora e aí descobrir que o bem não 
está disponível para ser reservado. Um auxílio e não um impedimento, ideal para 
reservas imediatas, porem permite reservas futuras. 
 
Figura 10 – Tela Equipamentos 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
 
16 
 
Entrada 1: Dados dos Equipamentos 
Processamento 1: Validação do Conteúdo dos Campos 
Saída 1: Gravação no Banco de Dados 
Entrada 2: Escolha do Equipamento a Ser Reservado 
Processamento 2: Verificação da Disponibilidade do Item 
Saída 2: Direcionamento para a Tela Agenda 
 
Agenda 
A tela de Agenda faz parte do Menu também, podendo ser acessada 
diretamente, com o intuito de mostrar ao usuário os agendamentos existentes para 
cada bem, sejam suas reservas ou de terceiros. Mas ela também faz parte da rotina 
que vem da tela Equipamentos, quando da reserva ser chamada por lá. E se eu 
quiser fazer a reserva por aqui? Pode também, escolhe o dia e o horário e a tela 
Equipamento será aberta para que escolha o bem. 
 
Figura 11 – Tela Agenda 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada 1: Informação Oriunda da Tela Equipamentos 
Processamento 1: Verificação da Disponibilidade de agenda 
Saída 1: Reserva do Bem e Envio Mensagem Tela Notificações 
 
17 
 
Entrada 2: Escolha da Data a Ser Reservado 
Processamento 2: Verificação da Disponibilidade da Data 
Saída 2: Direcionamento para a Tela Equipamentos 
 
Notificações 
A tela de Notificações, irá mostrar informes da instituição, colocados pelo 
Administrador, e outros oriundos de departamentos diversos, como no exemplo, o 
departamento de suporte. Mostrará as reservas efetivadas e as devoluções também. 
E apresentará os novos integrantes do grupo de trabalho que passaram a possuir 
acesso aos recursos disponíveis a serem reservados. 
Figura 12 – Tela Notificações 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada: Mensagem Oriunda de Outras Rotinas 
Processamento e Saída: Não 
 
Chat 
Uma tela com a funcionalidade em questão tem a finalidade de abrir negociação 
em caso de poucos recursos para grande demanda de necessidade, mas pode 
também ser utilizada como auxílio no planejamento do uso racional dos recursos ou 
simplesmente para conversar. 
 
18 
 
Figura 13 – Tela Chat 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada: Mensagem Digitada pelo Usuário 
Processamento: Encapsulamento / Envio da Mensagem para Usuario Destino 
Saída: Impressão da Mensagem Digitada na Tela 
 
Configurações 
Reunidas numa mesma tela, as Configurações pertinentes ao usuário dão ao 
mesmo, a possibilidade de restringir ou permitir acessos em diversas categorias do 
aplicativo. No exemplo em questão, está permitido ao Administrador mudar as 
agendas feitas pelo usuário, mas aos colegas de trabalho não. O nome do usuário 
não aparecerá junto as reservas, para que não venham incomodá-lo depois querendo 
alterar suas reservas. Está permitido chamadas no chat através de vídeo chamada, 
mas sempre dentro do horário de trabalho e a manutenção do histórico das conversas 
realizadas. 
 
 
 
 
 
 
19 
 
Figura 14 – Tela Configurações 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada: Aceite da Mudanca de SET para cada Item Configurado (ON/OFF) 
Processamento: Alteração das Permissões Alteradas 
Saída: Gravação dos Parâmetros Atuais após Alteração 
 
Menu 
A tela permite acesso direto a todas as funcionalidades do aplicativo. E traz um 
link para a loja afim de que o app seja avaliado quanto a qualidade e amplitude da 
solução. 
Figura 15 - Menu 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada/Processamento/Saída – Não 
 
 
20 
 
Fim 
Finalizamos o aplicativo com uma tela similar a inicial mostrando agora o 
desenvolvedorbem como o patrocinador do aplicativo. 
Figura 16 – Tela Fim 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
Entrada/Processamento/Saída – Não 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
21 
 
Programação Orientada a Objetos - Elementos 
Definição de objeto 
No paradigma de orientação a objetos, tudo pode ser potencialmente 
representado como um objeto. Sob o ponto de vista da programação, um objeto não 
é muito diferente de uma variável no paradigma de programação convencional. Por 
exemplo, quando se define uma variável, essa variável tem: 
 um espaço em memória para registrar o seu estado atual (um valor); 
 um conjunto de operações associadas que podem ser aplicadas a ela, 
através dos operadores (soma, subtração, inversão de sinal, 
multiplicação, divisão inteira, resto da divisão inteira, incremento, 
decremento). 
Da mesma forma, quando se cria um objeto, esse objeto adquire um espaço 
em memória para armazenar seu estado (os valores de seu conjunto de atributos, 
definidos pela classe) e um conjunto de operações que podem ser aplicadas ao objeto 
(o conjunto de métodos definidos pela classe). 
Definição de classe 
Uma classe é um gabarito para a definição de objetos. Através da definição de 
uma classe, descreve-se que propriedades -- ou atributos -- o objeto terá. 
Além da especificação de atributos, a definição de uma classe descreve 
também qual o comportamento de objetos da classe, ou seja, que funcionalidades 
podem ser aplicadas a objetos da classe. Essas funcionalidades são descritas através 
de métodos. Um método nada mais é que o equivalente a um procedimento ou 
função, com a restrição que ele manipula apenas suas variáveis locais e os atributos 
que foram definidos para a classe. 
 
 
 
22 
 
Em UML (Unified Modeling Language), a representação fica assim: 
Figura 17 – Classe 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
A especificação de uma classe é composta por três regiões: 
Nome da classe 
Um identificador para a classe, que permite referenciá-la posteriormente. 
Atributos 
O conjunto de propriedades da classe. Para cada propriedade, especifica-se: 
 nome: um identificador para o atributo. 
 tipo: o tipo do atributo (inteiro, real, caráter, etc.) 
 valor_default: opcionalmente, pode-se especificar um valor inicial para o 
atributo. 
 visibilidade: opcionalmente, pode-se especificar o quão acessível é um 
atributo de um objeto a partir de outros objetos. 
Métodos 
O conjunto de funcionalidades da classe. Para cada método, especifica-se 
sua assinatura, composta por: 
 nome: um identificador para o método. 
 tipo: quando o método tem um valor de retorno, o tipo desse valor. 
23 
 
 lista de argumentos: quando o método recebe parâmetros para sua 
execução, o tipo e um identificador para cada parâmetro. 
 visibilidade: como para atributos, define o quão visível é um método a 
partir de objetos de outros classes. 
As técnicas de programação orientada a objetos recomendam que a estrutura 
de um objeto e a implementação de seus métodos devem ser tão privativos como 
possível. Normalmente, os atributos de um objeto não devem ser visíveis 
externamente. Da mesma forma, de um método deve ser suficiente conhecer apenas 
sua especificação, sem necessidade de saber detalhes de como a funcionalidade que 
ele executa é implementada. 
Definição de Herança 
Herança é um mecanismo que permite que características comuns a diversas 
classes sejam fatoradas em uma classe base, ou superclasse. A partir de uma classe 
base, outras classes podem ser especificadas. Cada classe derivada ou subclasse 
apresenta as características (estrutura e métodos) da classe base e acrescenta a elas 
o que for definido de particularidade para ela. 
Sendo uma linguagem de programação orientada a objetos, Java oferece 
mecanismos para definir classes derivadas a partir de classes existentes. É 
fundamental que se tenha uma boa compreensão sobre como objetos de classes 
derivadas são criados e manipulados, assim como das restrições de acesso que 
podem se aplicar a membros de classes derivadas. Também importante para uma 
completa compreensão da utilização desse mecanismo. 
Definição de Polimorfismo 
Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma 
mesma superclasse podem invocar métodos que têm a mesma identificação 
(assinatura) mas comportamentos distintos, especializados para cada classe 
derivada, usando para tanto uma referência a um objeto do tipo da superclasse. A 
decisão sobre qual o método que deve ser selecionado, de acordo com o tipo da 
24 
 
classe derivada, é tomada em tempo de execução, através do mecanismo de ligação 
tardia. 
No caso de polimorfismo, é necessário que os métodos tenham exatamente a 
mesma identificação, sendo utilizado o mecanismo de redefinição de métodos. Esse 
mecanismo de redefinição não deve ser confundido com o mecanismo de sobrecarga 
de métodos. 
É importante observar que, quando polimorfismo está sendo utilizado, o 
comportamento que será adotado por um método só será definido durante a 
execução. Embora em geral esse seja um mecanismo que facilite o desenvolvimento 
e a compreensão do código orientado a objetos, há algumas situações onde o 
resultado da execução pode ser não-intuitivo. 
Algumas aplicações dos conceitos ao sistema criado: 
 
Figura 18 – Exemplo de Objeto e Classe 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
 
 
 
 
25 
 
Figura 19 – Exemplo de Herança 
 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
Figura 20 – Exemplo de Polimorfismo 
 
 
 
 
 
 
 
 
 
 
 Fonte: Silvio Agnoleto (Própria) 
 
 
 
26 
 
CONCLUSÃO 
O desenvolvimento de softwares é uma prática que exige muita organização e 
planejamento. Se o objetivo é oferecer um produto de qualidade sem ter gastos 
exorbitantes em sua criação, é fundamental definir estratégias para otimizar os 
processos do início ao fim. É interessante entender que os processos podem ser 
compreendidos como um conjunto de atividades que são organizadas a fim de definir, 
desenvolver, testar e manter o software. 
É muito comum que empresas desenvolvedoras inexperientes prometam algo 
que não conseguem cumprir, prejudicando assim sua reputação e causando prejuízo 
financeiro, assim, é importante não perder de vista que esses processos servem como 
um alicerce bastante sólido para suas atividades, mas também podem ser ajustados 
ao seu ambiente de desenvolvimento. 
Nenhum produto ou serviço é oferecido por uma empresa sem que o lucro e o 
custo sejam calculados previamente e o valor final do software seja satisfatório, 
nenhum software pode ser desenvolvido sem que antes seus objetivos sejam 
estabelecidos em detalhes. Estou falando da expectativa e das necessidades do 
cliente. Afinal, a qualidade real depende de atender a certas demandas, e isso só pode 
ser feito em parceria com quem pretende comprar o software. 
Fazer o levantamento dos requisitos é um dos processos mais importantes do 
desenvolvimento, pois é isso que vai guiar o time em todas as outras etapas, até a 
conclusão do projeto, trata-se da “materialização” do que foi solicitado pelo cliente e a 
formalização de tudo o que foi requisitado, além disso se faz necessário considerar 
outros aspectos fundamentais: a arquitetura do sistema, a linguagem de programação 
utilizada, o Sistema Gerenciador de Banco de Dados (SGBD), o design da interface 
gráfica etc. 
Definido tudo isso, vem a fase de desenvolvimento do código. Vale destacar 
que, a partir desse processo, algumas etapas podem trabalhar em paralelo, por isso, 
é fundamental investir em uma comunicação eficiente entre as equipes. 
Seguindo o fluxo, é chegada a hora dos testes, ou seja, é hora de verificar se 
as especificações atendem às demandas com eficiência.Devem ser testados tanto os 
requisitos funcionais, quanto os não funcionais (tecnologia utilizada, performance, 
usabilidade, etc), para otimizar esse processo, é importante que os problemas ou bugs 
encontrados sejam rapidamente repassados ao time de desenvolvimento. 
Após a entrega do software, acompanhado de um documento que informa qual 
é o seu objetivo, além de detalhar suas características, o cliente pode ter algumas 
solicitações de ajustes. Por isso, é fundamental contar com um processo de suporte 
para atender a essa demanda e garantir a qualidade do produto, equipe essa 
responsável também pela manutenção que é um período de garantia do 
funcionamento do software, podendo ser dividida em dois níveis: corretiva e evolutiva, 
na qual o escopo inicial é alterado e, consequentemente, o prazo final pode ser 
afetado. 
Ações simples, porém, desprezadas por uma quantidade ainda grande de 
empresas e desenvolvedores autônomos, mas que oferecem grandes benefícios. 
27 
 
REFERÊNCIAS 
[DENNIS, 2005] DENNIS, Alan. Análise e Projeto de Sistemas. Rio de Janeiro, LTC, 
2005. 
[Lima,2005] LIMA, Adilson da Silva. UML 2.0: do requisito à solução. 1 ed. São 
Paulo: Érica, 2005. 
[Ahern, 2001] DENNIS M. AHERN, AARON CLOUSE, e RICHARD TURNER, CMMI 
Distiled: A Practical Introduction to Integrated Process Improvement, SEI Series 
in Software Engineering, Addison-Wesley, 306 pages, 2001. 
[Pressman, 2002] PRESSMAN, R. Engenharia de Software. Rio de Janeiro: 
McGraw-Hill, 2002. 
[Campos, 1992] CAMPOS, VICENTE TQC – Controle da Qualidade Total. Belo 
Horizonte: Bloch Ed, 1992. 
[ISO. 2000] ISO 9001:2000. Quality Management Systems. Requirements, 2000. 
[Maldonado, 2001] – Qualidade de Software, Teoria e prática. São Paulo: Pearson, 
2001. 
[MCT,1996] MCT . Qualidade no setor de software brasileiro: 1995. Brasília, DF. 
http://www.mct.gov.br 
[Weber, 2001] WEBER, K.C,; ROCHA, A.R.C e NASCIMENTO, C.J. Qualidade e 
produtividade em software, 4ª edição renovada. São Paulo, Makron Books, 2001.