ANÁLISE E DESENVOLVIMENTO DE SISTEMAS Nota 9

Prévia do material em texto

UNIP EAD
Projeto Integrado Multidisciplinar
Cursos superiores de tecnologia 
PIM VII - PROJETO DE SISTEMA CONTROLE DE MATRICULAS
Macapá-Polo Fabran
2019
UNIP INTERATIVA
 Projeto Integrado Multidisciplinar 
Cursos superiores de tecnologia 
 PIM VII - PROJETO DE SISTEMA CONTROLE DE MATRICULAS 
KÁSSIO RAIMUNDO LIMA COUTINHO
RA: 1985186
Curso: Tecnologia em Análise e Desenvolvimento de Sistemas Semestre: 4º/2019
Macapá-Polo Fabran
 2019
 RESUMO
 Este PIM (Projeto Integrado Multidisciplinar) proposto pela universidade UNIP Interativa para este bimestre, busca refletir sobre a partir de teorias que procuram esclarecer o assunto das aulas de Projeto de Sistemas Orientado a Objetos, Programação Orientada a Objetos, Gestão de Qualidade e Empreendedorismo. Como ponto de partida propõe-se um trabalho de 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. O embasamento teórico se dará através de livros, visando à boa qualidade bibliográfica, Para tanto esta investigação apoia-se em referenciais bibliográficos que traduzem os enfoques teóricos a respeito do referido assunto. Para isso apresentaremos os diagramas necessários para a fase de projeto, começando pelo desenho de arquitetura MVC, 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 desenvolvidas na fase de análise. Por meio deles, será possível Promover uma avaliação das reais condições do desenvolvimento de um software, e assim, garantir a qualidade do produto que venha a atingir a expectativa do usuário ou cliente final. 
Palavras-chave: Tecnologia, Diagramas, UML, MVC, Sistemas.
ABSTRACT
This PIM (Integrated Multidisciplinary Project) proposed by UNIP Interactive University for this quarter, seeks to reflect on from theories that seek to clarify the subject of the Object Oriented Systems Design, Object Oriented Programming, Quality Management and Entrepreneurship classes. As a starting point we propose the construction of a free course registration control system, where it will be necessary to make the transition from the analysis phase to the design phase of the software development as well as the current market view. The theoretical basis will be through books, aiming at the good bibliographic quality. To this end, this research is based on bibliographical references that translate the theoretical approaches on the subject. For this we will present the necessary diagrams for the design phase, starting with the MVC architecture drawing. To make the transition from analysis to design, in this project we will present the implementation class diagrams, implementation sequence diagram, activity diagram and diagram. of distribution, all using the use case diagram and class diagram developed in the analysis phase. Through them, it will be possible to promote an assessment of the actual conditions of software development, and thus ensure the quality of the product that meets the expectation of the end user or customer.
Keywords: Technology, Diagrams, UML, MVC, Systems.
SUMÁRIO
1 INTRODUÇÃO
 O tema que será trabalhado fará abordagem a respeito da importância de serem desenvolvidos softwares de qualidade, com coerência e com todo suporte tal necessário para mercado ou aos consumidores finais.
Os conflitos advindos deste tema limitam-se nas especulações teóricas a respeito da abordagem da pratica. 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. 
O trabalho tem como objetivo geral buscar através de fundamentação teórica uma compreensão mais ampla a respeito do projeto de banco de dados bem como diagramas de classe, sequência e de distribuição, diminuindo a impalpabilidade do que será desenvolvido. 
A base teórica já existente sobre o assunto aqui discutido acredita na importância de se compreender, os objetivos específicos relacionados com este cenário volátil que trabalha com a hipótese de para se desenvolver um software de qualidade é preciso trabalho em equipe, 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.
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.1Camada 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, à 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. 
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çõesserão enviadas e qual combinação de views será utilizada para a exibição do retorno dos dados da model.
2.2 Unified ModelingLanguage – 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 elemento, relacionamentos, mecanismos de extensibilidade e diagramas, ele tem relação direta com a análise e o design orientado de objetos. 
	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 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. 
A UML programa uma modelagem com uma visão orientada a objetos. Através dela podemos definir as classes que compõe a nossa solução, seu atributos, métodos e como elas interagem entre si. Apesar da UML ter como base a orientação a objetos, não significa que a ferramenta e a linguagem utilizada para a implementação do modelo seja também orientada a objetos, embora seja recomendável. Este artigo não irá explorar os conceitos de orientação a objetos, e sim a implementação de um modelo UML simples, para início da documentação de 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 ira 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 de Estado, Diagrama de Atividade e Diagrama de Componentes.
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ítulo s 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 Desenhos da Arquitetura MVC
 Figura 1
Na figura 1 temos o desenho da arquitetura MCV do sistema Quando o usuário entra no site uma requisição é lançada para a máquina que hospeda o sistema, lá é papel do controlador receber os dados enviados e fazer alguma ação, usando ou não dados do modelo para complementar essa ação, e por fim criando uma visão de retorno para o usuário, que é retornada em uma resposta.
3.2 Diagramas Entidade-Relacionamento
Um diagrama entidade relacionamento (ER) é um tipo de fluxograma que ilustra como “entidades”, p. ex., pessoas, objetos ou conceitos, se relacionam entre si dentro de um sistema. Diagramas ER são mais utilizados para projetar ou depurar bancos de dados relacionais nas áreas de engenharia de software, sistemas de informações empresariais, educação e pesquisa. Também conhecidos como DERs, ou modelos ER, usam um conjunto definido de símbolos, tais como retângulos, diamantes, ovais e linhas de conexão para representar a interconectividade de entidades, relacionamentos e seus atributos. Eles espelham estruturas gramaticais, onde entidades são substantivos e relacionamentos são verbos.
Diagramas ER estão relacionados com diagramas de estrutura de dados (DEDs), que incidem sobre as relações de elementos dentro de entidades em vez de relações entre as próprias entidades. Diagramas ER são também muitas vezes utilizados junto com diagramas de fluxo de dados (DFDs), que mapeiam o fluxo de informações para processos ou sistemas.
O objetivo é criar um sistema de Controle de Matrículas de Cursos Livres para realizar o cadastro de alunos, cursos e matrícula de usuários para cursos de curta duração. Para isso, os seguintes requisitos precisam ser atendidos. 
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.
O sistema será utilizado por atendentes e alunos matriculados. Todo acesso ao sistema é feito em terminais na escola por meio de login e senha.
O atendente poderá realizar as seguintes ações: Manter cursos: o atendente cadastra os cursos que abrangem 2 áreas diferentes: informática e artes. Todos os tipos de cursos possuem código, nome, data de início, data de término, horário, número de vagas e valor.
Figura 2
 
3.3 Diagrama de Classe de Implementação 
A linguagem UML procura fornecer meios para auxiliar no levantamento dos requisitos que irão constituir um sistema, além de recursos para a modelagem de estruturas que farão parte do mesmo. O fato da UML ser um padrão de grande aceitação no mercado também se deve, em grande parte, à forte integração desta com conceitos da Orientação a Objetos (OO). Como muitos sistemas são concebidos a partir da aplicação de práticas e técnicas de OO, a elaboração de documentos modelando os componentes esperados é feita atualmente a partir de diagramas UML.
O objetivo deste trabalho é apresentar um resumo dos diferentes diagramas disponibilizados pela UML, abordando ainda de que forma estes recursos podem ser úteis em sistemas baseados em elementos da Orientação a Objetos. Permitindo saber quem está apontando para quem, através da representação gráfica da navegabilidade. Além disto, é possível compreender melhor de que lado está à responsabilidade.
A figura 3 permite a visualização de um conjunto de classes, detalhando atributos e operações (métodos) presentes nesta última, assim como prováveis relacionamentos entre essas estruturas. Este tipo de representação pode incluir ainda definições de interfaces.
3.3.1 Diagrama de Classe de Implementação – Manter Curso
Figura 3
3.3.2 Diagrama de Classe de Implementação – Manter Aluno
Figura 4
3.3.3 Diagrama de Classe de Implementação – Efetuar Matricula 
Figura 5
3.3.4 Diagrama de Classe de Implementação – Gerar Relatório de Matricula 
Figura 6
3.3.5 Diagrama de Classe de Implementação – Efetuar Login
Figura 7
3.3.6 Diagrama de Classe de Implementação – Consultar Curso
Figura 8
3.3.7 Diagrama de Classe de Implementação – Consultar Matriculas 
Figura 9
3.4 Diagrama de Sequência Implementação 
 
Diagrama de sequência (ou Diagrama de Sequência de Mensagens) é um diagrama usado em UML (Unified Modeling Language), representando a sequência de processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos em classes diferentes, pode ser difícil determinar a sequência global do comportamento. O diagrama de sequência representa essa informação de uma forma simples e lógica. 
Um diagrama de sequência descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. Ele registra o comportamento de um único caso de uso e exibe os objetos e as mensagens passadas entre essesobjetos no caso de uso. Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído a partir do Diagrama de Casos de Usos. Primeiro, define-se qual o papel do sistema (Use Cases), depois, é definido como o software realizará seu papel (Sequência de operações). 
O diagrama de sequência dá ênfase à ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Entende-se por mensagens os serviços solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitações. 
Em seguida será feito uma breve a apresentação de todos os diagramas de sequência de implementação desenvolvidos com base no diagrama de classes e diagramas de caso de usos que foram desenhados na fase de análise do projeto. Cada caso do tipo CRUD (incluir, alterar, consultar e excluir) será detalhado por meio de diagrama de sequencia.
3.4.1Diagrama de Sequência de Implementação - Manter Curso
3.4.2 Diagrama de Sequência de Implementação - Manter Aluno
3.4.3 Diagrama de Sequência de Implementação – Gerar Relatório de Matriculas
3.4.4 Diagrama de Sequência de Implementação – Consultar Curso
3.4.5 Diagrama de Sequência de Implementação – Consultar Matriculas
3.5 Diagramas de atividades
O diagrama de atividades é um fluxograma do cenário, ou seja, é a sequência lógica que deve ser seguida.
No contexto da UML, o Diagrama de Atividades é um diagrama comportamental (que especifica o comportamento do software), e através dele podemos modelar partes do comportamento de um software. O diagrama de atividades, como citado, tem como objetivo principal a especificação do comportamento do software, do ponto de vista funcional, ou seja, das suas funcionalidades. É muito semelhante a um fluxograma, uma ferramenta utilizada há muitas décadas, principalmente na administração.
E ainda, como para qualquer outro modelo que segue a notação UML, o objetivo de um diagrama é especificar o que será posteriormente projetado, ou diretamente construído, diminuindo assim o nível de abstração do escopo, facilitando o entendimento sobre o que tem ser feito pelo programador, por exemplo.
Com isso, programadores, por exemplo, pode entender de uma maneira “mais lógica” e “menos abstrata” o que deverá ser codificado no modelo executável. Entenderemos isso melhor mais à frente.
Na figura abaixo é exibido um modelo de diagrama de atividades para o método privado da classe matrícula “calcularValorCurso()”, esse método calcula o valor do curso e ainda oferece descontos de 5% a 15% de desconto que para alunos egresso.
3.6 Diagramas de Distribuição
O diagrama de distribuição é o diagrama estrutural responsável por estabelecer a relação entre os recursos de infraestrutura e artefatos do sistema, em outras palavras, ele mapeia arquitetura do hardware às necessidades do software a ser implantado. Esse diagrama é basicamente implementado com “nós”, “associações entre nós”.
Também conhecido como diagrama de implantação, o mesmo é um forte aliado para descrição de sistemas complexos e distribuídos onde os hardwares envolvidos tem um papel crucial na execução da aplicação. Claro que todos os softwares são codependentes do hardware, porém em alguns casos o hardware se torna o recurso mais prioritário.
O diagrama de distribuição mostra a arquitetura física da aplicação, mostrando o que deve ser instalado em cada camada física. O propósito deste modelo de diagrama é documentar os itens envolvidos a fim de tornar ágil o processo de implantação de software. A  Figura abaixo apresenta um exemplo deste diagrama de distribuição com os requisitos para implantação do sistema.
4 CONCLUSÃO
Considerando o que fora apresentado nesse projeto, pode-se concluir que o projeto de software é um tanto complexo, uma vez que depende em muito de um vasto e diferenciado conhecimento e de uma postura de empenho e força de vontade por parte do desenvolvedor para que atenda aos requisitos sugeridos pelo cliente, por consequência, atenda as suas expectativas. Para tanto, é preciso, antes de qualquer coisa, conhecer as novas teorias que embasam os estudos dos dos diagramas, aobnde casa um tem uas devidas necessidades e funções. Contudo, uma nova postura do MVC ajudará a desenvolver métodos mais eficazes e acessíveis para todos. 
Entretanto, destacamos um cenário de crescimento nesse processo, o qual tem se traduzido em conquistas significativas para o mercado do nosso país. Isso pode ser visto com o desempenho e credibilidade dos profissionais envolvidos na area que fazem parte do cenário, contribuindo para o progresso dessa clientela sem medir esforços para modificar o quadro existente em relação a qualidade de produto que esse padrão nos oferece. 
REFERÊNCIAS 
PRESSMAN, Roger S.. Engenharia de Sofware : uma abordagem profissional . 7 ed. 
AMGH, 2011. 
SCHACH, S . Engenharia de software: os paradigmas clássicos e orientado a 
Objetos. 7. e d . A rtMed, 2010. 
GAMMA, Erich et al . Padrões de Projeto: Soluções reutilizáveis de software 
Orientado a Objetos. Porto Alegre: Bookma n, 2000. 
FREEMAN & FREEMAN, Eric & Elizabeth. Padrões de Projetos: Seu cérebro em 
padrões de projetos. Rio de Janeiro: A LTA B OOK S , 20 07. 
HORSTMANN , C . Padrões e projetos orientados a objetos, 2ª Edição. Bookman, 
2007. 
MEDEIROS, E. Desenvolvendo Software com U ML 2.0: Definitivo, Makro n Books, 
2006.