UNIP INTERATIVA

Projeto Integrado Multidisciplinar

Cursos Superiores de Tecnologia

PIM VII – PROJETO DE SISTEMA CONTROLE DE MATRICULAS

São Paulo
2017
 UNIP INTERATIVA
Projeto Integrado Multidisciplinar
Cursos Superiores de Tecnologia

PIM VII - PROJETO DE SISTEMA CONTROLE DE MATRICULAS

Curso: Tecnologia em Análise e Desenvolvimento de Sistemas

Semestre: 2º/2017

São Paulo
2017
 RESUMO

Este PIM (Projeto Integrado Multidisciplinar) proposto pela universidade UNIP

Interativa para este bimestre, visa aplicar o conhecimento pelas aulas de Projeto de
Sistemas Orientado a Objetos, Programação Orientada a Objetos, Gestão de
Qualidade e Empreendedorismo. Este projeto propõe a construção de um sistema
de controle de matricula de cursos livres, onde será necessário fazer a transição da
fase de análise para a fase de projeto do desenvolvimento do software bem como a
visão de mercado atual. Para isso apresentaremos os diagramas necessários para a
fase de projeto, começando pelo desenho de arquitetura MVC, que será explicada
em um breve referencial teórico apontando as práticas adotadas nessa arquitetura e
seus elementos. Para efetuarmos a transição da análise para o design, nesse
projeto apresentaremos os diagramas de classe de implementação, diagrama de
sequência de implementação, diagrama de atividades e diagrama de distribuição,
todos utilizando o diagrama de caso de uso e diagrama de classes desenvolvidos na
fase de análise. O principal desafio deste projeto é demonstrar as dificuldades e
particularidades do desenvolvimento de um software, com todos os seus pré-
requisitos, visando à entrega de um produto com qualidade que venha a atingir a
expectativa do usuário ou cliente final.

Palavras-chave: Tecnologia, Diagramas, UML, MVC, Sistemas

 ABSTRACT

This PIM (Multidisciplinary Integrated Project) proposed by University UNIP Interativa

for this two-month period aims to apply the knowledge acquired by the classes of
Project of Object Oriented Systems, Object Oriented Programming, Quality
Management and Entrepreneurship. This project proposes the construction of a
system focused in control of registration of free courses, where it will be necessary to
make the transition from the analysis phase to the software development project
phase as well as the current market view. For this, we will present the necessary
diagrams for the design phase, starting with the design of the MVC architecture,
which will be explained in a brief theoretical reference pointing the practices adopted
in this architecture and its elements. In order to make the transition from analysis to
design, in this project we will present the implementation class diagrams,
implementation sequence diagram, activity diagram and distribution diagram, all
using the use case diagram and class diagram developed in the analysis. The main
challenge of this project is to demonstrate the difficulties and peculiarities of the
development of a software, with all its prerequisites, aiming at the delivery of a
product with quality that will reach the expectations of the user or end customer.

Key-words: Technology, Diagrams, UML, MVC, Systems.

 SUMÁRIO

1 INTRODUÇÃO ...................................................................................................... 5
2 REFERENCIAL TEÓRICO ................................................................................... 6
2.1 Arquitetura MVC ................................................................................................ 6
2.1.1 Camada Model ............................................................................................... 6
2.1.2 Camada View ................................................................................................. 6
2.1.3 Camada Controller ......................................................................................... 7
2.2 Unified Modeling Language - UML .................................................................... 7
3 PROJETO DE SISTEMA CONTROLE DE MATRICULAS ................................... 9
3.1 Desenho da Arquitetura MVC ............................................................................ 9
3.2 Diagrama Entidade-Relacionamento ............................................................... 10
3.3 Diagramas de Classe de Implementação ........................................................ 11
3.3.1 Diagramas de Classe de Implementação – Manter Curso ........................... 11
3.3.2 Diagramas de Classe de Implementação – Manter Aluno ........................... 12
3.3.3 Diagramas de Classe de Implementação – Efetuar Matricula...................... 12
3.3.4 Diagramas de Classe de Implementação – Gerar Relatório de Matricula .... 13
3.3.5 Diagramas de Classe de Implementação – Efetuar Login ........................... 13
3.3.6 Diagramas de Classe de Implementação – Consultar Curso ....................... 14
3.3.7 Diagramas de Classe de Implementação – Consultar Matriculas ................ 14
3.4 Diagramas de Sequência de Implementação .................................................. 15
3.4.1 Diagramas de Sequência de Implementação – Manter Curso ..................... 16
3.4.2 Diagramas de Sequência de Implementação – Manter Aluno ..................... 17
3.4.3 Diagramas de Sequência de Implementação – Efetuar Matricula ................ 19
3.4.4 Diagramas de Sequência de Implementação – Gerar Relatório de Matriculas
19
3.4.5 Diagramas de Sequência de Implementação – Efetuar Login ..................... 20
3.4.6 Diagramas de Sequência de Implementação – Consultar Curso ................. 20
3.4.7 Diagramas de Sequência de Implementação – Consultar Matriculas .......... 21
3.5 Diagrama de Atividades .................................................................................. 21
3.6 Diagrama de Distribuição ................................................................................ 22
4 CONCLUSÃO ..................................................................................................... 24
REFERÊNCIAS ......................................................................................................... 25
 5

1 INTRODUÇÃO

Hoje, nas mais diferentes áreas do conhecimento humano têm gerado uma
grande e crescente demanda por soluções computadorizadas. Com essa elevada
demanda muitas vezes os softwares desenvolvidos chegam ao mercado ou
consumidores finais sem qualidade, sem coerência ou até mesmo sem um suporte a
tal software.
Desenvolver um software de qualidade que atenda o cliente e seus requisitos
é um trabalho para o engenheiro de software, mas para isso é necessário utilizar o
processo de software, que consiste em vários modelos, porem todos tem em
comum, 4 (quatro) atividades fundamentais, que são elas: A especificação, onde é
definido o software e suas restrições; O desenvolvimento, que é responsável pelo
projeto e sua programação; a validação, que tem como principal característica
verificar se as necessidades do cliente foram atendidas e o mesmo pode ser
modificado para atender as novas tecnologias do mercado.
Na atividade de desenvolvimento, independente do processo que o
engenheiro de software tenha escolhido tem o projeto de software, onde através de
um documento e seus requisitos levantados mais a análise efetuada na fase de
especificação, projeta-se o software estabelecendo a sua arquitetura, projeto de
banco de dados bem como diagramas de classe, sequência e de distribuição,
diminuindo a impalpabilidade do que será desenvolvido.
Com este cenário volátil nem sempre é possível conduzir o desenvolvimento
de software de maneira individual. O trabalho em equipe se torna essencial para que
seja atingida a meta e a excelência no desenvolvimento do software, assim
atendendo o cliente em todas as instâncias e expectativa de qualidade.
Este projeto tem o objetivo de construir a documentação de design para um
sistema de controle de matricula de cursos livres, visando demonstrar de forma
conceitual os artefatos solicitados neste projeto.
 6

2 REFERENCIAL TEÓRICO

2.1 Arquitetura MVC

MVC (Model, View, Controller) é um padrão de arquitetura de software criado

na década de 70 e desenvolvido para ser usado em projetos de interface visual em
Smaltalk, linguagem de programação que ganhou grande reconhecimento junto com
o C++ na época, mesmo após esses anos de sua criação ainda é um pattern
aplicável em diversas aplicações, principalmente em aplicações web.
Essa arquitetura consiste na separação do código fonte em três camadas,
estando preocupado em separar a informação de sua apresentação, separando os
dados (Model), da interface com o usuário (View) e do fluxo da aplicação
(Controller), com a intenção de que uma mensagem da lógica de negócios possa ser
acessada e visualizada através de várias interfaces.

2.1.1 Camada Model

A camada model ou modelo é a camada que contém a lógica da aplicação,

sendo responsável pelas regras de negócio, representando a informação (dados)
dos formulários e as regras SQL para manipular dados do banco, obtendo e
convertendo os dados de maneira que tenham conceitos significativos em sua
aplicação, assim como processar, validar, associar e outras funções relativas ao
tratamento dos dados.
O modelo atua isoladamente e não tem conhecimento de quais serão a ou as
interfaces que terá de atualizar, ele apenas acessa à base de dados e deixa os
dados prontos para o controlador encaminhar para a visão correta.

2.1.2 Camada View

A camada view ou visão é a camada de apresentação com usuário, a

interface, ela é responsável por exibir uma representação dos dados modelados nos
quais os usuários interagem diretamente, que proporcionará a entrada de dados e a
visualização de respostas geradas, os dados da camada view podem ser
 7

apresentados em diversos formatos, dependendo do tipo da aplicação, como

arquivos XML, HTML, vídeos, áudios entre outros.
A view deve sempre garantir que sua apresentação reflita o estado do
modelo, quando os dados do modelo mudam, o modelo notifica as camadas view
que dependem dele e então cada view pode ou não se atualizar dependendo da
necessidade, desta maneira permitindo ligar muitas views a um modelo e assim
fornecendo diferentes apresentações.
Essa camada não contém códigos relacionados à lógica de negócios, então
todo o processamento é feito pela model e só então ele repassa para a view.

2.1.3 Camada Controller

A camada controller ou controlador é camada responsável pela intermediação

entre as camadas model e view, essa camada é que define o comportamento da
aplicação, gerenciando e interpretando as requisições dos usuários e retornando
uma interação entre as camadas model e view.
A controller não tem a responsabilidade de buscar ou exibir dados, ela
trabalha apenas controlando e mapeando as ações, decidindo qual model usar,
quais solicitações serão enviadas e qual combinação de views será utilizada para a
exibição do retorno dos dados da model.

2.2 Unified Modeling Language - UML

A linguagem de modelagem unificada (UML) é uma linhagem para

visualização, especificação, construção e documentação de artefatos de um
software em desenvolvimento, que nos permite modelar elementos,
relacionamentos, mecanismos de extensibilidade e diagramas, ela tem uma relação
direta com a análise e o design orientado a objetos.
A UML não é um método de desenvolvimento, não sendo responsável por
dizer o que fazer ou como desenhar o sistema, mas ajuda a visualizar o desenho do
sistema e a comunicação entre a equipe de análise e desenvolvimento, e apesar de
também não ser uma linguagem de programação, existem ferramentas que podem
ser usadas para gerar código em várias linguagens por meio dos diagramas UML.
 8

A UML é controlada pelo Object Management Group (OMG – Grupo de

gerenciamento de objetos, em tradução livre), responsável por supervisionar a
definição e manutenção das especificações UML, permitindo assim aos engenheiros
e programadores usarem uma única linguagem para diversas finalidades durante as
fases do ciclo de vida do software e para os tamanhos de sistemas.
A UML é composta por muitos elementos de modelo que representam as
diferentes partes de um sistema de software, esses elementos são utilizados para
criar diagramas que representam determinada parte, ou um ponto de vista do
sistema, como diagrama de caso de uso, diagrama de classe, diagrama de
sequência, diagrama entidade-relacionamento, diagrama de atividade, diagrama de
distribuição entre outros.
 9

3 PROJETO DE SISTEMA CONTROLE DE MATRICULAS

Este projeto é desenvolvido com base em um desenho de arquitetura de

referência utilizando MVC, que explicamos nos capítulos anteriores em nosso
referencial teórico.
Apresentaremos nos subcapítulos a seguir os diagramas elaborados para
todos os casos de uso levantados na fase de análise do projeto, utilizando como
base o desenho da arquitetura MVC mostrado na Figura 1, sendo esses diagramas
os diagramas de classes de implementação e diagramas de sequência de
implementação, também apresentaremos o diagrama de atividade do método
“calcularValorCurso()” da classe Matricula, o diagrama entidade-relacionamento do
banco de dados da aplicação e o diagrama de distribuição do sistema, explicaremos
brevemente os tipos de diagramas que estaremos apresentando o que eles
representam e como funciona sua aplicação.

3.1 Desenho da Arquitetura MVC

Figura 1 – Arquitetura Estática

Fonte: O Autor, 2017

Na Figura 1 temos o desenho da arquitetura MVC do sistema, onde as

classes que estão na camada View, servem para enviar eventos dos usuários para a
camada Controller e exibir as respostas desses eventos, a camada Controller é
responsável por mapear esses eventos e efetuar atualizações na camada Model,
 10

que realiza o encapsulamento do estado do sistema e efetua as mudanças de

estado quando solicitado.

3.2 Diagrama Entidade-Relacionamento

O Diagrama Entidade-Relacionamento, também chamado de Diagrama ER ou

apenas DER, é a representação gráfica de um MER (Modelo Entidade-
Relacionamento), que como o nome sugere, é um modelo conceitual utilizado na
Engenharia de Software para descrever as entidades envolvidas em um domínio de
negócios, com seus atributos e como ele se relacionam entre si.
Esse diagrama facilita a comunicação entre os integrantes da equipe, pois
oferece uma linguagem comum utilizada tanto pelo analista, responsável por
levantar os requisitos, e os desenvolvedores, responsáveis por implementar aquilo
que foi modelado.
Na Figura 2, temos a solução do DER proposto para o sistema, de acordo
com o diagrama de classes desenvolvido na fase de análise do projeto.

Figura 2 – Diagrama Entidade-Relacionamento

Fonte: O Autor, 2017

 11

3.3 Diagramas de Classe de Implementação

Considerado por muitos autores como um dos mais importantes diagramas da

UML, a principal característica de um diagrama de classes é permitir a visualização
das classes que irão compor o sistema, representando seus atributos e métodos e
demonstrar como as classes se relacionam entre si.
Apresentaremos a seguir todos os diagramas de classe de implementação
desenvolvidos com base no diagrama de casos de uso que foi desenhado na fase
de análise do projeto.
Cada caso de uso possuirá seus diagramas específicos utilizando como base
o desenho da arquitetura MVC mostrado na Figura 1, foi adicionado as classes
estereótipos para facilitar ainda mais a identificação a qual camada cada classe
pertence. A classe View representa a tela que o usuário interage, a classe Controller
é responsável por fazer a ligação entre a camada visual e a camada de negócio e as
classes com o estereótipo Model representam as classes de modelo de domínio que
são responsáveis por implementar o que o sistema irá fazer, também temos as
classes DAO que são classes responsáveis por fazer a ligação com o banco de
dados utilizando de métodos da classe Conexão. Também é de responsabilidade da
classe Controller manter o Log, que é o registro de todas as atividades efetuadas no
sistema.

3.3.1 Diagramas de Classe de Implementação – Manter Curso

Figura 3 – Diagrama de Classe de Implementação – Manter Curso

 12

Fonte: O Autor, 2017

3.3.2 Diagramas de Classe de Implementação – Manter Aluno

Figura 4 – Diagrama de Classe de Implementação – Manter Aluno

Fonte: O Autor, 2017

3.3.3 Diagramas de Classe de Implementação – Efetuar Matricula

Figura 5 – Diagrama de Classe de Implementação – Efetuar Matricula

 13

Fonte: O Autor, 2017

3.3.4 Diagramas de Classe de Implementação – Gerar Relatório de Matricula

Figura 6 – Diagrama de Classe de Implementação – Gerar Relatório de Matricula

Fonte: O Autor, 2017

3.3.5 Diagramas de Classe de Implementação – Efetuar Login

Figura 7 – Diagrama de Classe de Implementação – Efetuar Login

Fonte: O Autor, 2017

 14

3.3.6 Diagramas de Classe de Implementação – Consultar Curso

Figura 8 – Diagrama de Classe de Implementação – Consultar Curso

Fonte: O Autor, 2017

3.3.7 Diagramas de Classe de Implementação – Consultar Matriculas

Figura 9 – Diagrama de Classe de Implementação – Consultar Matriculas

Fonte: O Autor, 2017

 15

3.4 Diagramas de Sequência de Implementação

O diagrama de sequência procura determinar a sequência de eventos e troca

de mensagens entre vários objetos em um determinado contexto (caso de uso,
operação, etc), ou seja, quais operações devem ser disparadas entre os objetos
envolvidos e em qual ordem para a realização desse contexto.
A representação das informações é feita na forma em que o tempo flui, de
cima para baixo no diagrama, mostrando assim a ordem que as interações são feitas
e facilitando a compreensão delas.
Em um diagrama de sequência a representação do tempo de vida de um
objeto (lifeline) é feita por linhas verticais, essas linhas são preenchidas por barras
verticais que indicam exatamente quando objeto passou a existir e quando esse
objeto deixa de existir é adicionado um “X” a parte inferior da lifeline. As linhas
horizontais representam as mensagens trocadas entre os objetos, acompanhadas
com um rótulo contendo o nome da mensagem, e opcionalmente, os parâmetros,
linhas horizontais tracejadas representam os retornos das mensagens. Também
podemos ter mensagens enviadas para o mesmo objeto representando as
interações.
Para a criação destes diagramas é necessário a utilização dos diagramas de
classe e casos de uso, já que o diagrama de sequência trata das interações de
objetos de um determinado caso de uso.
Apresentaremos a seguir todos os diagramas de sequência de
implementação desenvolvidos com base no diagrama de classes e diagrama de
caso de uso que foram desenhados na fase de análise do projeto. Cada caso de uso
possuirá seus diagramas específicos, utilizando a arquitetura MVC e seguindo o
desenho mostrado na Figura 1, para os casos de uso do tipo “crud” (incluir, alterar,
consultar e excluir) apresentaremos um diagrama de sequência para cada uma
dessas atividades.
 16

3.4.1 Diagramas de Sequência de Implementação – Manter Curso

Figura 10 – Diagrama de Sequência de Implementação – Cadastrar Curso

Fonte: O Autor, 2017

Figura 11 – Diagrama de Sequência de Implementação – Alterar Curso

Fonte: O Autor, 2017

Figura 12 – Diagrama de Sequência de Implementação – Excluir Curso

Fonte: O Autor, 2017

 17

Figura 13 – Diagrama de Sequência de Implementação – Consultar Curso

Fonte: O Autor, 2017

3.4.2 Diagramas de Sequência de Implementação – Manter Aluno

Figura 14 – Diagrama de Sequência de Implementação – Cadastrar Aluno

Fonte: O Autor, 2017

Figura 15 – Diagrama de Sequência de Implementação – Alterar Aluno

Fonte: O Autor, 2017

 18

Figura 16 – Diagrama de Sequência de Implementação – Excluir Aluno

Fonte: O Autor, 2017

Figura 17 – Diagrama de Sequência de Implementação – Consultar Aluno

Fonte: O Autor, 2017

 19

3.4.3 Diagramas de Sequência de Implementação – Efetuar Matricula

Figura 18 – Diagrama de Sequência de Implementação – Efetuar Matricula

Fonte: O Autor, 2017

3.4.4 Diagramas de Sequência de Implementação – Gerar Relatório de

Matriculas

Figura 19 – Diagrama de Sequência de Implementação – Gerar Relatório de Matriculas

Fonte: O Autor, 2017

 20

3.4.5 Diagramas de Sequência de Implementação – Efetuar Login

Figura 20 – Diagrama de Sequência de Implementação – Efetuar Login

Fonte: O Autor, 2017

3.4.6 Diagramas de Sequência de Implementação – Consultar Curso

Figura 21 – Diagrama de Sequência de Implementação – Consultar Curso

Fonte: O Autor, 2017

 21

3.4.7 Diagramas de Sequência de Implementação – Consultar Matriculas

Figura 22 – Diagrama de Sequência de Implementação – Consultar Matriculas

Fonte: O Autor, 2017

3.5 Diagrama de Atividades

O diagrama de atividades é utilizado para modelar o aspecto comportamental

de um processo, seu objetivo é mostrar o fluxo de atividades de um determinado
processo e suas relações e dependências, preocupando-se em descrever os passos
a serem percorridos para a conclusão de um método ou algoritmo especifico,
possibilitando a visão dos procedimentos efetuados para a execução de uma
atividade.
Todo diagrama de atividades deve possuir um início, marcado por um círculo
preenchido, e um fim, representado por um círculo preenchido com um aro branco
na extremidade, para a representação das ações utilizamos um retângulo de bordas
arredondadas ligados por setas que representam os fluxos de controle, para a
representação de decisões utilizamos um losango.
Na Figura 23, é apresentado o diagrama de atividade para o método privado
“calcularValorCurso()” da classe Matricula, esse método calcula o valor do curso a
ser cobrado do aluno, onde um aluno que já tenha cursado outro curso tem o direito
a 5% de desconto, em caso de ter cursado dois cursos tem o direito a 10% de
desconto e se já tenha cursado três ou mais cursos, o direito a 15% de desconto.
 22

Figura 23 – Diagrama de Atividade do método “calcularValorCurso()”

Fonte: O Autor, 2017

3.6 Diagrama de Distribuição

O diagrama distribuição ou implantação captura a topologia (ambiente) de

hardware de um sistema, é uma representação gráfica da visão estática de
funcionamento de um sistema, mostrando os relacionamentos entre os componentes
de software e hardware no sistema, focando na organização da arquitetura física em
que o software irá ser implementado e executado, contendo somente os elementos
essências à compreensão desse aspecto, fornecendo detalhes consistes com seu
nível de abstração.
O diagrama de distribuição tem como seu elemento básico os Nós, que
representam os computadores configurados para execução, as associações entre os
Nós, que são suas ligações e os Artefatos, que representam as entidades físicas do
mundo real.
Na Figura 24, apresentamos o diagrama de distribuição elaborado para a
execução do sistema proposto neste projeto.
 23

Figura 24 – Diagrama de Distribuição

Fonte: O Autor, 2017

 24

4 CONCLUSÃO

Tendo em vista os aspectos levantados e propostos neste projeto, usando os

conhecimentos adquiridos nas matérias deste bimestre, para conseguir atingir o
objetivo do trabalho exposto, conseguimos utilizar tais conhecimentos de análise e
desenvolvimento de projetos. Visando sempre a qualidade e levando em
consideração todo o trabalho vimos que precisamos ter uma visão empreendedora
para que o software atenda aos requisitos abordados pelo cliente e supra as suas
necessidades. Em suma devemos seguir uma estrutura, que neste trabalho é
representado pelos diagramas, onde cada um tem suas devidas necessidades e
funções as quais precisam estar claras e objetivas, conseguimos identificar a
utilidade em se adotar a arquitetura MVC para o desenvolvimento de sistemas,
constatando os benefícios de desenvolvimento e qualidade de produto que esse
padrão nos oferece. Com isso minimizasse os erros de desenvolvimento agregando
qualidade no produto final.
 25

REFERÊNCIAS

PRESSMAN, Roger S.. Engenharia de Software: uma abordagem profissional. 7 ed.

AMGH, 2011.

SCHACH, S. Engenharia de software: os paradigmas clássicos e orientado a

objetos. 7. ed. ArtMed, 2010.

GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de software

Orientado a Objetos. Porto Alegre: Bookman, 2000.

FREEMAN & FREEMAN, Eric & Elizabeth. Padrões de Projetos: Seu cérebro em
padrões de projetos. Rio de Janeiro: ALTABOOKS, 2007.

HORSTMANN, C. Padrões e projetos orientados a objetos, 2ª Edição. Bookman,

2007.

MEDEIROS, E. Desenvolvendo Software com UML 2.0: Definitivo, Makron Books,

2006.