UNIP EaD

Projeto Integrado Multidisciplinar VII

Cursos Superiores de Tecnologia
MARCO AURÉLIO GIBELLATO NOGUEIRA

UM SISTEMA PARA O CONTROLE DE MATRÍCULAS DE CURSOS

Londrina
2019
 UNIP EaD
Projeto Integrado Multidisciplinar VII
Cursos Superiores de Tecnologia

UM SISTEMA PARA O CONTROLE DE MATRÍCULAS DE CURSOS

Marco Aurélio Gibellato Nogueira

RA: 1928745
CST Análise e Desenvolvimento de Sistemas
Semestre: 4

Londrina
2019
NOGUEIRA, Marco Aurélio Gibellato. Um sistema para o controle de matrículas
de cursos. 2019. 26f. Projeto Integrado Multidisciplinar VII (Curso Superior de
Tecnologia em Analise e Desenvolvimento de Sistemas) – Universidade Paulista
Interativa, Londrina.

RESUMO

Este trabalho apresenta uma análise de desenvolvimento para um sistema de

controle de matrículas e cursos. É composto por análises de artefatos que foram
produzidos na fase de análise de requisitos. O trabalho apresenta uma série de
diagramas referentes a fase de projeto (design). Diagramas que foram evoluídos a
partir dos artefatos da fase de análise de requisitos. O trabalho apresenta uma
revisão da arquitetura MVC, que é usada como base para o desenvolvimento da
arquitetura do projeto.

Palavras-chave: Arquitetura MVC. Diagramas de classes. Diagramas de sequência.

Fase de projeto. Engenharia de software.
NOGUEIRA, Marco Aurélio Gibellato. A system for controlling courses
enrollment. 26p. Integrated Multidisciplinary Project VII (Superior Course in
Technology in Analysis and Development of Systems) - Universidade Paulista
Interativa, Londrina.

ABSTRACT

This work presents a development analysis for a course and enrollment control
system. It consists of artifact analyzes that were produced in the requirements
analysis phase. The paper presents a series of diagrams referring to the design
phase. Diagrams that evolved from the requirements analysis phase artifacts. The
paper presents a review of the MVC architecture, which is used as a basis for the
development of the project architecture.

Keywords: MVC architecture. Class diagrams. Sequence diagrams. Project phase.

Software Engineering.
 SUMÁRIO

1 INTRODUÇÃO....................................................................................... 5
2 DESENVOLVIMENTO........................................................................... 6
2.1 CENÁRIO.................................................................................................. 6
2.2 OBJETIVO................................................................................................ 7
2.3 ATIVIDADES.............................................................................................. 7
2.3.1 Arquitetura de referência – MVC........................................................... 7
2.3.2 Diagrama de classes e diagramas de sequência – implementação..... 10
2.3.3 Diagrama de atividades......................................................................... 18
2.3.4 Diagrama de distribuição....................................................................... 19
3 CONCLUSÃO........................................................................................ 20
REFERÊNCIAS..................................................................................... 21
 5

1 INTRODUÇÃO

Este trabalho apresenta um projeto de desenvolvimento de um Sistema para

o Cadastro de Cursos e Alunos. O projeto consiste em analisar os artefatos que
foram criados na fase de análise de requisitos do projeto. Com estes artefatos
efetuar a evolução do desenvolvimento do projeto, aprofundando a análise de
domínio e do projeto esquemático do sistema. Foram analisados os casos de uso e
assim definido a composição de classes e comunicação entre elas.
No capítulo 2.1 apresentamos o cenário, o qual é constituído da
apresentação do sistema, no capítulo 2.2 apresentamos os objetivos específicos
pedidos como atividades para o trabalho, no capítulo 2.3 fazemos uma análise da
arquitetura MVC – Model-View-Controller e elaboramos a estrutura de classes que
devem compor o sistema, para os demais subcapítulo apresentamos diversos
diagramas: diagramas de classe de implementação, diagramas de sequência,
diagramas de atividades e diagramas de distribuição. No capítulo 3 concluímos.
 6

2 DESENVOLVIMENTO

2.1 CENÁRIO

O Manual do PIM VII, apresenta o seguinte cenário fictício:

Uma empresa de treinamentos resolveu contratar uma outra empresa para

construir um sistema para realizar o controle de matrículas de cursos livres.
Depois de um mês de trabalho, o arquiteto do projeto (da empresa
contratada) teve de fazer uma viagem para atender um cliente no exterior.
Para ocupar o seu lugar, você (grupo do PIM) foi designado para conduzir o
projeto até a volta do arquiteto. Antes de viajar, no entanto, o arquiteto lhe
passou todas as informações. Ele informou que a fase de análise acabara
de ser finalizada e agora, como tarefa, você deverá conduzir o projeto,
passando da fase de análise para a fase de projeto (design). Os artefatos
que ele lhe entregou estão apresentados a seguir: [os artefatos estão como
anexos] (UNIVERSIDADE PAULISTA, 2019, p. 23).

Os artefatos foram organizados como 3 anexos deste trabalho: Anexo A –

apresenta os requisitos do sistema, como quais funcionalidades devem haver no
sistema; Anexo B – é uma continuação do texto do Anexo A, apresenta uma última
funcionalidade e os casos de uso elucidados para o sistema; e o Anexo C –
apresenta um diagrama de classes criado na fase de análise do projeto.

2.2 OBJETIVO

O objetivo deste trabalho, é cumprir as atividades solicitadas pelo manual

referente para a fase de projeto (design), a fase seguinte após a fase de análise de
requisitos, segundo Albin (2003 apud VERSOLATTO, 2015b, p. 84) “[…] a
arquitetura de software pode ser dividida em cinco fases [...]”: fase de análise de
requisitos; fase de projeto (design); fase de implementação e testes; e a fase de
implantação. As atividades pedidas no manual para esta fase de projeto são:

1. desenho da arquitetura de referência utilizando MVC (utilizar o diagrama

de classes ou de objetos para representar os principais elementos.);
2. para cada Caso de Uso, desenvolver o diagrama de classe de
implementação e o diagrama de sequência de implementação;
3. diagrama de atividades para o método privado “calcularValordoCurso();
4. diagrama de distribuição com os requisitos para implantação do sistema.
(UNIVERSIDADE PAULISTA, 2019, p. 26)
 7

2.3 ATIVIDADES

As atividades para este trabalho foram divididas em subcapítulos deste

capítulo, no subcapítulo 2.3.1, apresentamos o desenho da arquitetura do software
para o controle de matrículas, utilizando o padrão de arquitetura para
desenvolvimento de software, Model, View e Controller (MVC).
No subcapítulo 2.3.2 apresentamos os diagramas de classe de
implementação e o diagrama de sequência de implementação.
No subcapítulo 2.3.3 apresentamos o diagrama de atividades para o método
“calcularValordoCurso()”.
No subcapítulo 2.3.4 apresentamos o diagrama de distribuição.

2.3.1 Arquitetura de referência – MVC

O padrão de arquitetura MVC,

[…] propõem a divisão lógica da aplicação em três camadas: model, view e

controller. A camada Model ou modelo é responsável por objetos que
representem o domínio da aplicação, por exemplo, as regras de negócio; a
camada View ou visão representa a interface com o usuário; e a camada
Controller tem como objetivo o gerenciamento do fluxo da aplicação
Buschmann (et al, 2007 apud VERSOLATTO, 2015b, p. 91).

Na Figura 1 clareamos a ideia sobre o padrão MVC.

Figura 1 – Definição das camadas MVC

Fonte: autoria própria, com Draw.io em uso, inspirado em Hegarty (2011, p.18)

A Figura 1 simboliza a divisão das 3 camadas, utilizamos faixas dupla-

amarela de ‘proibido ultrapassar’ para demonstrar que não é permitido haver
comunicação entre as classes do campo View e as classes do campo Model. A faixa
 8

branca simples tracejada simboliza ‘permitido ultrapassar’, demostrando que deverá

haver comunicação das classes que estão no campo Controller tanto com as classes
do campo View como com as classes que estiverem no campo Model.
O fator importante nesse padrão de desenvolvimento, é o de que a camada
Controller faça a intermediação da comunicação entre a View e o Model.
A View nunca pode ter acesso diretamente ao Model. “Todas as estruturas
são manipuladas inicialmente por Controllers, servindo, assim, como base para a
implementação e apresentação de dados pela camada View.” (MARINHO, 2015,
grifo nosso).
Para cumprir o modelo de comunicação entre classes na arquitetura MVC,
foi necessário evoluir o diagrama de classes que nos foi apresentado – Anexo C, foi
necessário alterar a estrutura de classes e reorganizar os seus componentes, assim
originando a Figura 2. A Figura 2 apresenta um diagrama de objetos para
representar principais elementos do software.

Figura 2 – Estrutura de classes e comunicação entre classes pré login – MVC

Fonte: autoria própria, com Visual Studio e Draw.io em uso

Na Figura 2, do lado esquerdo, vemos a estrutura de pastas e documentos

(classes), organizadas no padrão de arquitetura MVC. No lado direito da Figura 2
temos o diagrama de objetos, neste caso também representando as classes.
A interface do usuário é representada pela classe Interface, que está no
campo View, A Interface deve se comunicar com a classe AcessoController, que
também se comunica com a classe AcessoController. A classe AcessoController
pode se comunicar com a classe AtendenteController ou AlunoController, quais são
responsáveis por se comunicar com suas respectivas classes Model.
 9

As classes Model por sua vez, consultam o banco de dados para a verificar
a existência do login (cadastro) do usuário e permitir login. “A camada Modelo é
responsável por efetuar um espelhamento das tabelas que são construídas no
banco de dados.” (MARINHO, 2011p. 123).
A classe AcessoController deve conter apenas os atributos e métodos
referentes as regras de acesso ao sistema, assim como as outras classes devem ter
apenas componentes relativos a sua pertinência. “A construção orientada a objetos
associada ao padrão MVC permite o perfeito isolamento das funções e a evolução
da aplicação.” (RIBEIRO, 2015, p. 153).
A Figura 3 apresenta a mesma estrutura de classes, mas agora
representando a comunicação após o login ser efetuado.

A classe AcessoController sai de cena, com o login efetuado a comunicação

se torna direta com as classes AlunoController e AtendenteController. Também se
torna disponível a comunicação com as classes CursoController e
MatrículaController.

Figura 3 – Estrutura de classes e comunicação entre classes pós login – MVC

Fonte: autoria própria, com Visual Studio e Draw.io em uso

Dessa forma foi possível manter o intuito do padrão de arquitetura MVC, de

forma que a classe do campo View não faz comunicação direta com as classes do
campo Model. As classes do campo Controller, tanto na Figura 2 quanto na Figura 3,
atuam fazendo a comunicação entre o campo View e o campo Model.
 10

Devemos mencionar que para este projeto usamos apenas uma classe no
campo View, no entanto, dependendo do grau de complexidade, o número de
classes para a Interface pode ser revisto.

2.3.2 Diagramas de classe e diagramas de sequência – implementação

Neste subcapítulo apresentamos para cada caso de uso, diagramas de

classe de implementação e diagramas de sequência de implementação, diagramas
respectivamente chamados de estático e dinâmicos.
Diagramas estáticos, ou seja, “[…] demonstram a estrutura física dos
elementos e não envolvem a passagem do tempo, isto é, não mostram a dinâmica
das coisas, mas simplesmente sua organização.” (COSTA, 2014, p. 143). Já os
diagramas dinâmicos, “[…] mostram a interação ativa que o sistema suporta;
detalham a interação dos elementos estruturais dos diagramas estáticos” (COSTA,
2014, p. 144).
Na fase de projeto, a atividade de projeto de dados e classes, é realizado o
refinamento do diagrama de classes do domínio (VERSOLATTO, 2015b, p. 70).
“Fase na qual os requisitos são transformados em sistema de software. Quando são
projetados e construídos os componentes de software e suas integrações.”
(VERSOLATTO, 2015a, p. 15).
O diagramas foram criados a partir dos casos de uso apresentados no
Anexo B, os casos de uso são:
a) manter curso;
b) manter aluno;
c) efetuar matrícula;
d) gerar relatórios de matrículas;
e) efetuar login;
f) consultar curso e;
g) consultar matrícula.
Para promover uma melhor visualização dos diagramas, organizaremos os
diagramas um uma sequência que mostrará para cada caso de uso: primeiro o
diagrama de classe; e em segundo o seu respectivo diagrama de sequência. Os
diagramas devem seguir a ordem em que aparecem nas alíneas.
 11

A Figura 4 apresenta o diagrama de classe de implementação do caso de

uso (a) manter curso.

Figura 4 – Diagrama de classe de implementação – Manter Curso

Fonte: autoria própria, com Rational Rose em uso

A Figura 5 apresenta o diagrama de sequência, também referente ao caso

de uso (a), manter curso.

Figura 5 – Diagrama de sequência de implementação – Manter Curso

Fonte: autoria própria, com Rational Rose em uso

 12

A Figura 6 apresenta o diagrama de classe de implementação do caso de

uso (b) manter aluno.

Figura 6 – Diagrama de classe de implementação – Manter Aluno

Fonte: autoria própria, com Rational Rose em uso

A Figura 7 apresenta o diagrama de sequência, também referente ao caso

de uso (b), manter aluno.

Figura 7 – Diagrama de sequência de implementação – Manter Aluno

Fonte: autoria própria, com Rational Rose em uso

 13

A Figura 8 apresenta o diagrama de classe de implementação do caso de

uso (c) efetuar matrícula.

Figura 8 – Diagrama de classe de implementação – Efetuar Matrícula

Fonte: autoria própria, com Rational Rose em uso

A Figura 9 apresenta o diagrama de sequência, também referente ao caso

de uso (c), efetuar matrícula.

Figura 9 – Diagrama de sequência de implementação – Efetuar Matrícula

Fonte: autoria própria, com Rational Rose em uso

 14

A Figura 10 apresenta o diagrama de classe de implementação do caso de

uso (d) gerar relatórios de matrículas.

Figura 10 – Diagrama de classe de implementação – Gerar Relatório Matrículas

Fonte: autoria própria, com Rational Rose em uso

A Figura 11 apresenta o diagrama de sequência, também referente ao caso

de uso (d), gerar relatórios matrículas.

Figura 11 – Diagrama de sequência de implementação – Gerar Relatório Matrículas

Fonte: autoria própria, com Rational Rose em uso

 15

A Figura 12 apresenta o diagrama de classe de implementação do caso de

uso (e) efetuar login.

Figura 12 – Diagrama de classe de implementação – Efetuar Login

Fonte: autoria própria, com Rational Rose em uso

A Figura 13 apresenta o diagrama de sequência, também referente ao caso

de uso (e), efetuar login.

Figura 13 – Diagrama de sequência de implementação – Efetuar Matrícula

Fonte: autoria própria, com Rational Rose em uso

 16

A Figura 14 apresenta o diagrama de classe de implementação do caso de

uso (f) consultar curso.

Figura 14 – Diagrama de classes de implementação – Consultar Curso

Fonte: autoria própria, com Rational Rose em uso

A Figura 15 apresenta o diagrama de sequência, também referente ao caso

de uso (f), consultar curso.

Figura 15 – Diagrama de sequência de implementação – Consultar Curso

Fonte: autoria própria, com Rational Rose em uso

 17

A Figura 16 apresenta o diagrama de classe de implementação do caso de

uso (g) consultar matrícula.

Figura 16 – Diagrama de classes de implementação – Consultar Matrícula

Fonte: autoria própria, com Rational Rose em uso

A Figura 17 apresenta o diagrama de sequência, também referente ao caso

de uso (g), consultar matrícula.

Figura 17 – Diagrama de sequência de implementação – Consultar Matrícula

Fonte: autoria própria, com Rational Rose em uso

 18

Neste ponto finalizamos a apresentação dos diagramas de classe de

implementação e diagramas de sequência dos casos de uso. Em seguida no
subcapítulo 2.3.3 apresentamos o diagrama de atividades.

2.3.3 Diagrama de atividades

Neste subcapítulo apresentamos o diagrama de atividades para o método

privado “calcularValordoCurso()”.

O diagrama de atividade é muito semelhante ao fluxograma tradicional, pois

ambos representam o fluxo sequencial de atividades de um processo.
Todavia, o diagrama de atividade, além de representar o fluxo sequencial e
suas possíveis ramificações, assim como o fluxograma, representa também
o paralelismo e a concorrência na execução dessas atividades. (BOOCH;
JACOBSON; RUMBAUGH, 2006 apud VERSOLATTO, 2015a, p. 92).

A Figura 18 apresenta o diagrama de atividades para o método privado

“calcularValordoCurso()”.

Figura 17 – Diagrama de atividades do método “calcularValordoCurso()”

Fonte: autoria própria, com Rational Rose em uso

No diagrama de atividades podemos ver uma sequência de atividades para

solicitar o valor de um curso.
O usuário efetua login, consulta o curso qual gostaria de saber o valor, em
seguida consulta o aluno e consulta as matrículas, assim o sistema vai ou não
acusar que o aluno já realizou algum outro curso: caso não tenha feito nenhum
curso, o sistema apresenta o valor inteiro; se o aluno já houver realizado outro curso,
então o sistema deverá elaborar o cálculo de desconto de acordo com as instruções
contidas na nota, após o cálculo, apresenta o valor do curso ao aluno.
 19

2.3.4 Diagramas de distribuição

Neste subcapítulo apresentamos o diagrama de distribuição. O “[…]

diagrama de distribuição, ou de implantação, mostra como os componentes são
configurados para execução, em “nós” de processamento. (LARMAN, 2007 apud
VERSOLATTO, 2015b, p. 135).

A Figura 18 apresenta o diagrama de distribuição.

Figura 18 – Diagrama de distribuição

Fonte: autoria própria, com Rational Rose em uso

O diagrama de distribuição apresenta os dispositivos que deverão fazer

parte da infraestrutura. Efetuando a divisão de responsabilidades, aumentamos a
capacidade de processamento do servidor da aplicação, além de diminuir a
exposição do sistema a algum problema grave.
Aconselhamos que o backup seja realizado em dispositivos físicos móveis
de armazenamento, tipo pen drive, para aumentar a segurança em caso de alguma
catástrofe sugerimos que seja criado uma redundância do banco de dados em
nuvem, assim como seu backup.
 20

3 CONCLUSÃO

Concluímos que um projeto de desenvolvimento de software é complexo e

possui vários métodos de análise para seu refinamento. Ao trabalhar sobre o
Sistema para o Cadastro de Cursos e Alunos foi possível compreender a
necessidade dos artefatos de um projeto de software.
A engenharia de requisitos e as modelagens de dados são matérias com
conteúdo e referencial bibliográfico extenso, que devem ser revisitadas
constantemente para uma melhor assimilação e prática profissional.
Por fim, a respeito das contribuições para a formação acadêmica e
profissional, este trabalho nos proporcionou o contato com a literatura acerca do
tema; além de propiciar a prática de elaboração de diagramas e o uso dos softwares
específicos para este fim.
 21

REFERÊNCIAS

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 6023:

informação e documentação: referências: elaboração. Rio de Janeiro: ABNT, 2018.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 6024:

informação e documentação: numeração progressiva das seções de um documento:
apresentação. Rio de Janeiro, ABNT, 2012.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 10520:

informação e documentação: citações em documentos: apresentação. Rio de
Janeiro: ABNT, 2002.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 14724:

informação e documentação: trabalhos acadêmicos: apresentação. Rio de Janeiro:
ABNT, 2011.

COSTA, Ivanir. Engenharia de software I. São Paulo: Editora Sol, 204.

HEGARTY, Paul. Developing applications for iOS: mvc. [curso CS193p, Stanford
University]. Stanford, 2011. Disponível em: http://web.stanford.edu/class/cs193p/cgi-
bin/drupal/system/files/lectures/Lecture%201_1.pdf. Acesso em: 06 out. 2019.

MARINHO, Salatiel L. Desenvolvimento de software para internet. São Paulo:

Editora Sol, 2011.

RIBEIRO, André L. Engenharia de software II. São Paulo: Editora Sol, 2015.

UNIVERSIDADE PAULISTA. Manual do projeto integrado multidisciplinar VII.

UNIP – Universidade Paulista Interativa, 2019.

VERSOLATTO, Fábio R. Análise de sistemas orientada a objetos. São Paulo:

Editora Sol, 2015a.

VERSOLATTO, Fábio R. Projeto de Sistemas Orientado a Objetos. São Paulo:

Editora Sol, 2015b.
 22

ANEXO A – Artefato recebido do arquiteto do projeto, página 1

Fonte: Manual do PIM VII (UNIVERSIDADE PAULISTA, 2019, p. 24)

 23

ANEXO B – Artefato recebido do arquiteto do projeto, página 2

Fonte: Manual do PIM VII (UNIVERSIDADE PAULISTA, 2019, p. 25)

 24

ANEXO C – Artefato recebido do arquiteto do projeto, página 3

Fonte: Manual do PIM VII (UNIVERSIDADE PAULISTA, 2019, p. 26)