PROJETO INTEGRADO MULTIDISCIPLINAR VII

Prévia do material em texto

UNIP EaD 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
SISTEMA DE CONTROLE DE MATRICULAS DE CURSOS LIVRES 
PIM VII 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Hortolândia, SP 
2018 
 
UNIP EaD 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
SISTEMA DE CONTROLE DE MATRICULAS DE CURSOS LIVRES 
PIM VII 
 
Aluno: Rondinele Ramos Clemente 
RA: 1781384 
Curso: Analise e Desenvolvimento de Sistemas 
2º Semestre 
 
 
 
 
 
 
 
 
 
Hortolândia, SP 
2018 
 
Resumo 
 
 
O objetivo do Projeto Integrado Multidisciplinar VII é desenvolver as atividades da 
fase de projeto de um Sistema de Controle de Matriculas de Cursos Livres, para 
realização de cadastro de alunos, cursos e matriculas para cursos de curta duração. 
O cenário proposto pela UNIP EaD é de que uma empresa de treinamentos 
resolveu contratar uma empresa para construir um sistema para realizar o controle 
de matrículas de cursos livres. O arquiteto do projeto (da empresa contratada) teve 
de fazer uma viagem para atender um cliente no exterior. Para ocupar o seu lugar, 
nós fomos designados para conduzir o projeto até a sua volta. Todas as 
informações foram passadas por ele antes de viajar. A fase de análise já havia sido 
finalizada e agora, como tarefa, precisamos conduzir o projeto, passando da fase de 
análise para a fase de projeto (design). 
Serão aplicados neste projeto os conhecimentos adquiridos nas aulas das 
disciplinas de Projeto de sistema Orientados a Objeto, Programação Orientada a 
Objetos II, Gestão de Qualidade e Empreendedorismo. 
As atividades realizadas no projeto serão o desenho da arquitetura de referência 
utilizando MVC, o desenvolvimento do diagrama de classe de implementação e o 
diagrama de sequência de implementação para cada caso de uso, o 
desenvolvimento de um diagrama de atividades para o método privado da classe 
matrícula “calcularValorCurso()” e um diagrama de distribuição com os requisitos 
para implantação do sistema. 
 
 
 
 
 
 
 
Palavras-chave: Arquitetura, referência, MVC, desenvolvimento, diagrama, classe, 
implementação, classe, requisitos e sistema. 
Abstract 
 
 
The objective of the Integrated Multidisciplinary Project VII is to develop the activities 
of the design phase of a Free Course Enrollment Control System for the registration 
of students, courses and enrollment for short courses. 
The scenario proposed by UNIP EaD is that a training company decided to hire a 
company to build a system to control the enrollment of free courses. The project 
architect (from the contracted company) had to take a trip to meet a client abroad. To 
take his place, we were assigned to conduct the project until his return. All the 
information was passed by him before traveling. The analysis phase had already 
been completed and now, as a task, we need to conduct the project from the 
analysis phase to the design phase. 
In this project the knowledge acquired in the classes of the disciplines of Project 
Oriented System, Object Oriented Programming II, Quality Management and 
Entrepreneurship will be applied in this project. 
The activities carried out in the project will be the design of the reference architecture 
using MVC, the development of the implementation class diagram and the 
implementation sequence diagram for each use case, the development of an activity 
diagram for the private method of the registration class "CalculateValueCourse ()" 
and a distribution diagram with the requirements for system deployment. 
 
 
 
 
 
 
 
 
Keywords: Architecture, reference, MVC, development, diagram, class, 
implementation, class, requirements and system. 
Lista de Ilustrações 
Figura 1 – Arquitetura Estática ........................................................................................ 9 
Figura 2 – Diagrama Entidade-Relacionamento .......................................................... 10 
Figura 3 – Diagrama de Classe de Implementação – Manter Curso .......................... 11 
Figura 4 – Diagrama de Classe de Implementação – Manter Aluno .......................... 11 
Figura 5 – Diagrama de Classe de Implementação – Efetuar Matricula .................... 12 
Figura 6 – Diagrama de Classe de Implementação – Gerar Relatório de Matricula . 12 
Figura 7 – Diagrama de Classe de Implementação – Efetuar Login .......................... 13 
Figura 8 – Diagrama de Classe de Implementação – Consultar Curso ..................... 13 
Figura 9 – Diagrama de Classe de Implementação – Consultar Matriculas .............. 14 
Figura 10 – Diagrama de Sequência de Implementação – Cadastrar Curso ............. 15 
Figura 11 – Diagrama de Sequência de Implementação – Alterar Curso .................. 15 
Figura 12 – Diagrama de Sequência de Implementação – Excluir Curso .................. 16 
Figura 13 – Diagrama de Sequência de Implementação – Consultar Curso ............. 16 
Figura 14 – Diagrama de Sequência de Implementação – Cadastrar Aluno ............. 16 
Figura 15 – Diagrama de Sequência de Implementação – Alterar Aluno ................... 17 
Figura 16 – Diagrama de Sequência de Implementação – Excluir Aluno .................. 17 
Figura 17 – Diagrama de Sequência de Implementação – Consultar Aluno.............. 17 
Figura 18 – Diagrama de Sequência de Implementação – Efetuar Matricula ............ 18 
Figura 19 – Diagrama de Sequência de Implementação – Gerar Relatório de 
Matriculas ........................................................................................................................ 18 
Figura 20 – Diagrama de Sequência de Implementação – Efetuar Login .................. 19 
Figura 21 – Diagrama de Sequência de Implementação – Consultar Curso ............. 19 
Figura 22 – Diagrama de Sequência de Implementação – Consultar Matriculas ...... 20 
Figura 23 – Diagrama de Atividade do método “calcularValorCurso()” ...................... 21 
Figura 24 – Diagrama de Distribuição........................................................................... 22 
 
 
Sumário 
1. Introdução................................................................................................................. 5 
2. REFERENCIAL TEORICO ....................................................................................... 6 
2..1. Model-View-Controller (MVC) ........................................................................................ 6 
2..2. Model-View-Controller (MVC) na Prática .................................................................... 6 
2..3. Camada View do MVC..................................................................................................... 6 
2..4. A Camada Model do MVC .............................................................................................. 6 
2..5. A Camada Controller do MVC ....................................................................................... 7 
2..6. Vantagens do Model-View-Controller (MVC) ............................................................. 7 
2..7. Unified Modeling Language (UML) .............................................................................. 7 
3. SISTEMA DE CONTROLE DE MATRICULAS DE CURSO LIVRE ...................... 8 
3.1. Desenho da Arquitetura MVC ....................................................................................... 9 
3.2. Diagrama Entidade-Relacionamento ........................................................................... 9 
3.3. Diagramas de Classe de Implementação ................................................................. 10 
3.4. Diagramas De Classe De Implementação – Manter Curso ...................................11 
3.5. Diagramas de Classe de Implementação – Manter Aluno .................................... 11 
3.6. Diagramas de Classe de Implementação – Efetuar Matricula ............................. 12 
3.7. Diagramas de Classe de Implementação – Gerar Relatório de Matricula ......... 12 
3.8. Diagramas de Classe de Implementação – Efetuar Login .................................... 13 
3.9. Diagramas de Classe de Implementação – Consultar Curso .............................. 13 
3.10. Diagramas de Classe de Implementação – Consultar Matriculas................... 14 
4. Diagramas de Sequência de Implementação .................................................... 14 
4.1. Diagramas de Sequência de Implementação – Manter Curso ............................. 15 
4.2. Diagramas de Sequência de Implementação – Manter Aluno ............................. 16 
4.3. Diagramas de Sequência de Implementação – Efetuar Matricula ...................... 18 
4.4. Diagramas de Sequência de Implementação – Gerar Relatório de Matriculas 18 
4.5. Diagramas de Sequência de Implementação – Efetuar Login ............................. 19 
4.6. Diagramas de Sequência de Implementação – Consultar Curso........................ 19 
4.7. Diagramas de Sequência de Implementação – Consultar Matriculas................ 20 
5. Diagrama de Atividades ....................................................................................... 20 
6. Diagrama de Distribuição ..................................................................................... 21 
7. Conclusão ............................................................................................................... 23 
8. Referencias ............................................................................................................. 24 
 
 
 
5 
 
1. Introdução 
 
O nível de qualidade de um sistema de software pode ser traduzido não só 
pelo nível de atingimento de automatização das necessidades de negócio, 
mapeados na engenharia de requisitos, mas também, pelo nível de eficiência no 
qual a solução de software atinge essas necessidades e pelo custo-benefício do 
processo de desenvolvimento e construção dessa solução. 
Na fase de projeto, os modelos de projeto têm como objetivo representar as 
diversas visões da solução de um sistema de software. 
Qualquer que seja o modelo de processo adotado, a fase de projetos está sempre 
entre a fase de licitação e análise de requisitos e a construção ou desenvolvimento. 
O objetivo da fase de projetos é desenhar a solução para os problemas levantados 
na engenharia de requisitos, desenho esse que serve como guia para a construção. 
O projeto deve fornecer uma visão completa do software sempre tendo como norte 
o aspecto implementação. 
 
 
6 
 
2. REFERENCIAL TEORICO 
2..1. Model-View-Controller (MVC) 
É um padrão de arquitetura de aplicações que divide a aplicação em três 
camadas: a visão (view), o modelo (model), e o controlador (controller). 
O padrão MVC foi desenvolvido em 1979 por Trygve Reenskaug com a finalidade 
de ser utilizado como arquitetura para aplicativos desketop. Entretanto, o padrão se 
popularizou para uso em sistemas web, a partir da adesão de milhares de 
Frameworks de mercado. 
2..2. Model-View-Controller (MVC) na Prática 
Em termos práticos, e de forma resumido, utilizar do padrão MVC significa: 
Dividir a aplicação em camadas, sendo, uma da interface do usuário denominada 
View, uma para manipulação lógica de dados chamada Model, e uma terceira 
camada de fluxo da aplicação chamada Controller). 
Criando a possibilidade de exibir uma mesma lógica de negócios através de várias 
interfaces, isolando a camada de negócios (Model) das demais camadas do 
sistema, de forma a facilitar a sustentabilidade do código. 
A implementação do controlador deve permitir que esta camada receba os eventos 
da interface e os converta em ações no modelo. 
As camadas do Modelo MVC são: 
2..3. Camada View do MVC 
É a camada que exibe uma representação dos dados, de interface com 
usuário (view) também conhecida como cliente-side ela faz a exibição dos dados, 
utilizando-se de #HTML e/ou XML. É responsável por usar as informações 
modeladas para produzir interfaces de apresentação conforme a necessidade. 
2..4. A Camada Model do MVC 
É a camada que contem a estrutura de dado atrás de uma parte específica da 
aplicação usualmente portada em JSON, é responsável pela leitura, manipulação e 
validação de dados, e também de suas validações. Responsável por tratar as regras 
de negócio ela obtém os dados e os traduz em informações relevantes para serem 
7 
 
exibidas pela View, notifica a view e controller associados quando há uma mudança 
em seu estado. 
2..5. A Camada Controller do MVC 
A camada de controller exerce o controle de qual model deverá ser aplicado e 
qual view será mostrado ao usuário. Podemos dizer que esta camada faz uma 
gerência das outras duas camadas. 
O controller manipula e roteia as requisições dos usuários, interpreta as requisições 
submetidas pelo usuário e traduz em comandos que são enviados para o (Model) 
e/ou para a View). Valida as requisições dos usuários de acordo com as regras de 
autenticação e autorização. 
2..6. Vantagens do Model-View-Controller (MVC) 
Melhor nível de sustentabilidade, pois facilita a manutenção da aplicação 
Melhor performance, graças a separação em camadas 
Fácil transformação da interface, sem que haja necessidade de modificar a camada 
de negócio 
Melhor desempenho e produtividade, graças a estrutura de pacotes modulares 
A arquitetura modular permite aos desenvolvedores e designers trabalharem em 
paralelo 
Partes da aplicação podem ser modificadas sem a necessidade de alterar outras 
2..7. Unified Modeling Language (UML) 
No final dos anos 80 e início dos anos 90, tínhamos muitos conflitos de 
definições e nomenclaturas na área de modelagem. A escolha para utilização de um 
determinado padrão era definida mais pelo “gosto” pessoal do que por fatores 
técnicos oferecidos. Então, os três mais respeitados nomes nesse campo, cada qual 
com seu conceito e implementação de modelo, Ivar Jacobson (OOSE – Object 
Oriented Software Engineering), Grady Booch (The Booch Method) e James 
Rumbaugh (OMT –Object Modeling Technique) decidiram acabar com os debates e 
trabalhar juntos na definição de um modelo único, a partir dessa união surgiu a 
UML. 
A UML permite que você “desenhe” uma “planta” do seu sistema. A 
comparação ideal é a de um construtor que vai realizar um projeto sem antes ter 
8 
 
toda a planta que defina estrutura a ser construída. A experiência do construtor 
garante, até certo ponto, o sucesso do projeto. Mas, com certeza, uma vez feito o 
planejamento, o “cálculo estrutural”, o desenho da planta, a garantia de sucesso 
antes, durante e depois da efetivação da construção é incomparavelmente maior. O 
mesmo acontece com um projeto de software. 
um sistema, utilizando dois diagramas implementados pela UML que são o 
“Diagrama de Casos e Uso” e o “Diagrama de Classes”. 
Os diagramas têm como objetivo representar, através de um conjunto de elementos, 
como o sistema irá funcionar e como cada peça do sistema irá trabalhar e interagir 
com as outras. Outra vantagem vem da facilidade de leitura dos diagramas que 
compõe a UML, além da facilidade de confeccioná-los, pois existem inúmeras 
ferramentas para modelagem de dados orientados a objetos (ferramentas Case), 
dentre elas o Rational Rose, o Model Maker, e o Poseidom UML. Além dos 
diagramas citados a UML disponibiliza outros diagramas, dentre os quais podemos 
citar o Diagrama de Objetos, Diagrama de Sequência, Diagrama de Colaboração, 
Diagrama deEstado, Diagrama de Atividade e Diagrama de Componentes. 
3. SISTEMA DE CONTROLE DE MATRICULAS DE CURSO LIVRE 
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. 
 
9 
 
3.1. Desenho da Arquitetura MVC 
Figura 1 – Arquitetura Estática 
 
Fonte: Autoria Própria, 2018. 
 
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, 
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. 
10 
 
Figura 2 – Diagrama Entidade-Relacionamento 
 
Fonte: Autoria Própria, 2018. 
 
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 
11 
 
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.4. Diagramas De Classe De Implementação – Manter Curso 
Figura 3 – Diagrama de Classe de Implementação – Manter Curso 
 
Fonte: Autoria Própria, 2018. 
 
3.5. Diagramas de Classe de Implementação – Manter Aluno 
Figura 4 – Diagrama de Classe de Implementação – Manter Aluno 
 
Fonte: Autoria Própria, 2018. 
 
12 
 
3.6. Diagramas de Classe de Implementação – Efetuar Matricula 
 
Figura 5 – Diagrama de Classe de Implementação – Efetuar Matricula 
 
Fonte: Autoria Própria, 2018. 
 
3.7. 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: Autoria Própria, 2018. 
 
13 
 
3.8. Diagramas de Classe de Implementação – Efetuar Login 
 
Figura 7 – Diagrama de Classe de Implementação – Efetuar Login 
 
Fonte: Autoria Própria, 2018. 
 
3.9. Diagramas de Classe de Implementação – Consultar Curso 
Figura 8 – Diagrama de Classe de Implementação – Consultar Curso 
 
Fonte: Autoria Própria, 2018. 
 
14 
 
3.10. Diagramas de Classe de Implementação – Consultar Matriculas 
Figura 9 – Diagrama de Classe de Implementação – Consultar Matriculas 
 
Fonte: Autoria Própria, 2018. 
 
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. 
15 
 
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. 
4.1. Diagramas de Sequência de Implementação – Manter Curso 
Figura 10 – Diagrama de Sequência de Implementação – Cadastrar Curso 
 
Fonte: Autoria Própria, 2018. 
 
Figura 11 – Diagrama de Sequência de Implementação – Alterar Curso 
 
Fonte: Autoria Própria, 2018. 
16 
 
Figura 12 – Diagrama de Sequência de Implementação – Excluir Curso 
 
Fonte: Autoria Própria, 2018. 
 
Figura 13 – Diagrama de Sequência de Implementação – Consultar Curso 
 
Fonte: Autoria Própria, 2018. 
 
4.2. Diagramas de Sequência de Implementação – Manter Aluno 
Figura 14 – Diagrama de Sequência de Implementação – Cadastrar Aluno 
 
Fonte: Autoria Própria, 2018. 
 
17 
 
Figura 15 – Diagrama de Sequência de Implementação – Alterar Aluno 
 
Fonte: Autoria Própria, 2018. 
 
Figura 16 – Diagrama de Sequência de Implementação – Excluir AlunoFonte: Autoria Própria, 2018. 
 
Figura 17 – Diagrama de Sequência de Implementação – Consultar Aluno 
 
Fonte: Autoria Própria, 2018. 
 
18 
 
4.3. Diagramas de Sequência de Implementação – Efetuar Matricula 
 
Figura 18 – Diagrama de Sequência de Implementação – Efetuar Matricula 
 
Fonte: Autoria Própria, 2018. 
 
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: Autoria Própria, 2018. 
 
19 
 
4.5. Diagramas de Sequência de Implementação – Efetuar Login 
 
Figura 20 – Diagrama de Sequência de Implementação – Efetuar Login 
 
Fonte: Autoria Própria, 2018. 
 
4.6. Diagramas de Sequência de Implementação – Consultar Curso 
 
Figura 21 – Diagrama de Sequência de Implementação – Consultar Curso 
 
Fonte: Autoria Própria, 2018. 
 
20 
 
4.7. Diagramas de Sequência de Implementação – Consultar Matriculas 
 
Figura 22 – Diagrama de Sequência de Implementação – Consultar Matriculas 
 
Fonte: Autoria Própria, 2018. 
 
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. 
 
21 
 
Figura 23 – Diagrama de Atividade do método “calcularValorCurso()” 
 
Fonte: Autoria Própria, 2018. 
 
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. 
 
22 
 
Figura 24 – Diagrama de Distribuição 
 
Fonte: Autoria Própria, 2018. 
 
23 
 
7. Conclusão 
Neste projeto é possível compreender que, para o desenvolvimento de um 
software seguro e de qualidade é necessário desde o início um bom gerenciamento 
do projeto, seguindo todas as suas etapas, tendo uma equipe forte, capacitada e o 
mais importante bem entrosada e com o mesmo nível de informação, sempre 
mantendo o foco nas necessidades e satisfação dos clientes. 
Foi possível no PIM VII colocar em pratica todo o conhecimento adquirido 
neste bimestre, principalmente nas habilidades estudas na matéria de “Projeto de 
Sistema Orientado a Objeto” com ênfase na fase de projeto (designer). 
Com foco e utilizando das ferramentas que foram propostas podemos 
desenvolver o trabalho e entregar um resultado bem detalhado. 
 
24 
 
8. Referencias 
MCGLAUGHLIN, 1991, p. 209 apud PRESSMAN, 2006. Livro Texto Unidade I – 
Projeto de Sistemas Orientado a Objetos: Editora Sol, 2015. 
MEDEIROS, E. Desenvolvendo Software com UML 2.0: Definitivo, Makron Books, 
2006. 
FREEMAN & FREEMAN, Eric & Elizabeth. Padrões de Projetos: Seu cérebro em 
padrões de projetos. Rio de Janeiro: ALTABOOKS, 2007. 
GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de software 
Orientado a Objetos. Porto Alegre: Bookman, 2000. 
PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional 7 
Edição. AMGH, 2011. 
SCHACH, S. Engenharia de software: os paradigmas clássicos e orientado a 
objetos. 7. Edição. ArtMed, 2010. 
HORSTMANN, C. Padrões e projetos orientados a objetos, 2ª Edição. Bookman, 
2007.