PIM VII UNIP ADS – PROJETO DE SISTEMA CONTROLE DE MATRICULAS

Prévia do material em texto

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
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.
REFERENCIAL TEÓRICO
 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. 
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. 
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 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. 
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 paraa exibição do retorno dos dados da model. 
 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. 
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. 
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. 
 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, que realiza o encapsulamento do estado do sistema e efetua as mudanças de estado quando solicitado.
 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
 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. 
Diagramas de Classe de Implementação – Manter Curso
Figura 3 – Diagrama de Classe de Implementação – Manter Curso
Fonte: O Autor, 2017
Diagramas de Classe de Implementação – Manter Aluno
Figura 4 – Diagrama de Classe de Implementação – Manter Aluno
Fonte: O Autor, 2017
Diagramas de Classe de Implementação – Efetuar Matricula
Figura 5 – Diagrama de Classe de Implementação – Efetuar Matricula
Fonte: O Autor, 2017
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
Diagramas de Classe de Implementação – Efetuar Login
Figura 7 – Diagrama de Classe de Implementação – Efetuar Login
Fonte: O Autor, 2017
Diagramas de Classe de Implementação – Consultar Curso
Figura 8 – Diagrama de Classe de Implementação – Consultar Curso
Fonte: O Autor, 2017
Diagramas de Classe de Implementação – Consultar Matriculas
Figura 9 – Diagrama de Classe de Implementação – Consultar Matriculas
Fonte: O Autor, 2017
 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.
Diagramasde 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
Figura 13 – Diagrama de Sequência de Implementação – Consultar Curso
Fonte: O Autor, 2017
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
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
Diagramas de Sequência de Implementação – Efetuar Matricula
Figura 18 – Diagrama de Sequência de Implementação – Efetuar Matricula
Fonte: O Autor, 2017
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
Diagramas de Sequência de Implementação – Efetuar Login
Figura 20 – Diagrama de Sequência de Implementação – Efetuar Login
Fonte: O Autor, 2017
Diagramas de Sequência de Implementação – Consultar Curso
Figura 21 – Diagrama de Sequência de Implementação – Consultar Curso
Fonte: O Autor, 2017
Diagramas de Sequência de Implementação – Consultar Matriculas
Figura 22 – Diagrama de Sequência de Implementação – Consultar Matriculas
Fonte: O Autor, 2017
 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. 
Figura 23 – Diagrama de Atividade do método “calcularValorCurso()”
Fonte: O Autor, 2017
 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. 
Figura 24 – Diagrama de Distribuição
Fonte: O Autor, 2017
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.
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.