DESENVOLVIMENTO DE UM SISTEMA DE CHAMADOS
UTILI-ZANDO ASP.NET MVC
Niterói
2016
DESENVOLVIMENTO DE UM SISTEMA DE CHAMADOS
UTILI-ZANDO ASP.NET MVC
Trabalho de Conclusão de Curso subme-tido ao Curso de Tecnologia em Sistemas de Computação da Universidade Federal Fluminense como requisito parcial para obtenção do título de Tecnólogo em Sis-temas de Computação.
Orientador:
Douglas Paulo de Mattos
NITERÓI
2016
A474 Alves, Evandro Cordeiro
Desenvolvimento de um sistema de chamadas utilizando ASP.NET MVC / Evandro Cordeiro Alves. – Niterói, RJ : [s.n.], 2016.
102 f.
Projeto Final (Tecnólogo em Sistemas de Computação) – Universidade Federal Fluminense, 2016.
Orientador: Douglas Paulo de Mattos.
1. Desenvolvimento de software. 2. Arquitetura de software. 3. Framework orientado a objeto. 4. C# (Linguagem de programação de computador). I. Título.
EVANDRO CORDEIRO ALVES
DESENVOLVIMENTO DE UM SISTEMA DE CHAMADOS
UTILI-ZANDO ASP.NET MVC
Trabalho de Conclusão de Curso subme-tido ao Curso de Tecnologia em Sistemas de Computação da Universidade Federal Fluminense como requisito parcial para obtenção do título de Tecnólogo em Sis-temas de Computação.
Niterói, 01 de Dezembro de 2016.
Banca Examinadora:
____________________________________________________ Prof. Douglas Paulo de Mattos, MSc. – Orientador
UFF – Universidade Federal Fluminense
____________________________________________________ Prof. Igor Cesar Gonzalez Ribeiro, MSc. – Avaliador
AGRADECIMENTOS
A Deus, por ter me dado saúde e força para superar as dificuldades.
Aos meus pais, pelo amor, incentivo е apoio incondicional.
Ao mеυ orientador, pelo emprenho dedicado à elaboração deste trabalho.
Aos Colegas de curso pelo incentivo e troca de experiências.
A todos qυе direta оυ indiretamente fizeram parte dа minha formação, о mеυ muito obri-gado.
“Os que se encantam com a prática sem a ci-ência são como os timoneiros que entram no navio sem timão nem bússola, nunca tendo certeza do seu destino”.
RESUMO
Este projeto visa o desenvolvimento de um sistema de chamados utilizando ASP.NET MVC, um framework web gratuito para construção de web sites, aplicativos e serviços web. Possui regras de validação (tanto Client Side quanto Server Side), exibição e modelagem bem definidas, assim como a clara separação das camadas
Model, View e Controller, o que possibilita um ágil desenvolvimento. Para esse estudo
será usado a linguagem C#, apesar desse framework possibilitar o desenvolvimento com outras linguagens de programação.
O sistema de chamados também será usado para demostrar a implemen-tação da autenticação e segurança na utilização do framework citado.
Será descrito na primeira etapa a fundamentação teórica desde estudo, a evolução do padrão MVC, a arquitetura deste padrão de projeto, as vantagens da utilização, a validação dos dados e as anotações de código. Também será descrito, numa segunda etapa, a definição do problema, os requisitos, os diagramas e o projeto da interface, assim como a implementação do sistema de chamados propriamente dita.
Finalmente serão feitos os testes de software, utilizando alguns cenários para isso. Logo após haverá uma discussão sobre o uso do ASP.NET MVC e o resul-tado da implementação.
Abstract
This project aims to develop a ticketing system using ASP.NET MVC, a free web framework for building web sites, applications, and web services. It has vali-dation rules (both as Client Side Server Side), display and well-defined modelling, as well as clear separation of layers Model, View and Controller, which enables agile de-velopment. For this study will be used the C# language, though this framework enable development with other programming languages.
The ticketing system is also used to demonstrate the implementation of au-thentication and security in the use of the said framework.
Will be described in the first stage the theoretical basis from the study, the evolution of the MVC pattern, the architecture of this design pattern, the advantages of using the data validation and code annotations. It will also be described as a second step, the problem definition, requirements, diagrams and interface design, as well as the implementation of the so-called proper system.
Finally, the software testing will be done using some scenarios for this. Soon after there will be a discussion about using ASP.NET MVC and the result of implemen-tation.
LISTA DE ILUSTRAÇÕES
Figura 1 – Interação entre os componentes na aquitetura MVC. ... 22
Figura 2 – Classe Usuário com um campo Nome e o construtor padrão. ... 29
Figura 3 – Classe Usuário utilizado DataAnnotations. ... 30
Figura 4 – Exemplo de uso de expressão regular. ... 31
Figura 5 – Diagrama de Caso de uso. ... 37
Figura 6 – Modelagem de Dados. ... 42
Figura 7 – Diagrama de Classes. ... 43
Figura 8 – Projeto da tela de Login. ... 44
Figura 9 – Projeto da tela Principal do Solicitante ... 45
Figura 10 – Projeto da tela Principal do Técnico. ... 45
Figura 11 – Projeto da tela Consultar Chamados ... 46
Figura 12 – Projeto da tela Consultar Todos os Chamados. ... 47
Figura 13 – Projeto da tela de abertura de chamados ... 47
Figura 14 – Projeto da tela do chamado. ... 48
Figura 15 – Diagrama de pacotes ... 50
Figura 16 - Estrutura de pastas. ... 52
Figura 17 - Adiconado o Banco de Dados ... 54
Figura 18 - Adicionando a conexão. ... 55
Figura 19 - Estrutura atual ... 56
Figura 20 - Atributos gerados automaticamente. ... 57
Figura 21 - Atributos após edição ... 58
Figura 22 - Instância do banco de dados. ... 59
Figura 23 - ActionsResult do Login ... 59
Figura 24 – Criando uma view. ... 60
Figura 25 - View Login ... 61
Figura 26 - Configuração da rota padrão. ... 62
Figura 28 – Query para a criação de um novo usuário. ... 63
Figura 29 - Tela de Login ... 64
Figura 30 - ActionResult Index. ... 65
Figura 31 - Tela inicial do Usuário Regular ... 65
Figura 32 - ActionResult Create. ... 66
Figura 33 - Tela de abertura de chamado ... 67
Figura 34 - Campos ocultos da tela de criação de chamado. ... 67
Figura 35 - Tela de consulta do chamado como usuário regular ... 68
Figura 36 - Tela inicial do técnico. ... 69
Figura 37 – Tela de consulta de chamado como técnico ... 70
Figura 38 – ActionResult Edit. ... 71
Figura 39 - Adicionar comentário ... 72
Figura 40 - ActionResult Adicionar Mensagem. ... 72
Figura 41 - Tela de consulta de chamado contendo um coméntario ... 73
Figura 42 - Partial View _Comentários. ... 74
Figura 43 - Código para inserção da partial view ... 74
Figura 44 - Tela inicial do administrador ... 75
Figura 45 – ActionResult Index do controle GerenciaDeUsuarios ... 75
Figura 46 – Tela Gerenciar Usuários ... 76
Figura 47 – ActionResult Create do controller “GerenciaDeUsuarios” ... 77
Figura 48 – Tela Criar novo usuário. ... 78
Figura 49 – ActionResult Edit do controle “GerenciaDeUsuarios” ... 79
Figura 50 – Tela Editar usuário ... 80
Figura 51 – ActionResult Delete do controle “GerenciaDeUsuarios” ... 81
Figura 52 – Tela para deletar usuário. ... 82
Figura 53 – Validações da classe Usuário ... 83
Figura 54 – Validações da classe Mensagem ... 84
Figura 55 – Validações da classe Chamado ... 85
Figura 56 – Validações da classe Anexo ... 85
Figura 57 – Teste Funcional 1 - Login ... 88
Figura 58 – Teste Funcional 1 – Tela inicial ... 89
Figura 59 – Teste Funcional 1 – Abrir chamado ... 90
Figura 60 – Teste Funcional 1 – Lista de chamados abertos ... 91
Figura 62 – Teste Funcional 2 – Adicionar comentário ... 93
Figura 63 – Teste Funcional 2 – Tela do chamado com um comentário ... 94
Figura 64 – Teste Funcional 2 – Acidionar Anexo ... 95
Figura 65 – Teste Funcional 2 – Tela de chamado com um anexo ... 96
Figura 66 – Teste Funcional 3 – Tela principal do técnico ... 97
Figura 67 – Teste Funcional 3 – Tela do chamado acessada por um técnico ... 98
LISTA DE ABREVIATURAS E SIGLAS
ASP – Active Server Pages
HTML – HyperText Markup Language HTTP – Hypertext Transfer Protocol
IDE – Integrated Development Environment MVC – Model View Controler
VB – Visual Basic
CGI – Common Gateway Interface API - Application Programming Interface
SGBD - Sistema Gerenciador de Banco de Dados XML - Extensible Markup Language
CSS - Cascading Style Sheet OO - Orientação a Objetos
UML - Unified Modeling Language XSS - Cross-site scripting
SSL - Secure Sockets Layer CSRF - Cross-site request forgery UML - Unified Modeling Language
SUMÁRIO
1 INTRODUÇÃO ... 15
1.1 MOTIVAÇÃO ... 15
1.2 OBJETIVO ... 17
1.3 ORGANIZAÇÃO DO TRABALHO ... 17
2 Histórico - Uma visão geral sobre a criação e evolução dos frameworks de desenvolvimento. ... 18
3 Fundamentação Teórica. ... 20
3.1 Definição de Frameworks. ... 20
3.2 Arquitetura do Padrão de Projeto MVC. ... 21
3.2.1 Definição ... 21
3.2.2 A camada de Modelo (Model). ... 22
3.2.3 A camada de Controle (Controller). ... 23
3.2.4 A camada de Visão (View). ... 24
3.2.5 Vantagens e Desvantagens do uso do padrão MVC. ... 25
3.3 Framework de desenvolvimento para servidor web. ... 26
3.4 Framework ASP.NET MVC. ... 27
3.5 Validação de Dados. ... 28
3.6 Anotações de Código no ASP.NET MVC. ... 29
4 Sistema Proposto – “Sistema de Chamados” ... 32
4.1 Definição do problema – “Processo de Chamados”. ... 32
4.2 Solução Proposta. ... 32
4.3 Especificação. ... 34
4.3.1 Requisitos. ... 35
4.3.1.1 Requisitos Não-Funcionais...37
4.3.1.2 Requisitos Funcionais...38
4.3.2 Diagramas de Caso de Uso. ... 36
4.3.3 Descrição dos Casos de Uso. ... 37
4.3.4 Modelagem de Dados. ... 41
4.3.5 Banco de Dados. ... 43
4.3.6 Projeto da Interface do Software. ... 43
5 Implementação do Sistema. ... 48
5.2 Ambiente de desenvolvimento e linguagens utilizadas. ... 50
5.3 Interface Gráfica. ... 58
5.3.1 Interface do Usuário. ... 63
5.3.2 Interface do Técnico. ... 67
5.3.3 Interface do Administrador do Sistema. ... 73
5.4 Segurança do sistema. ... 81
5.5 Limitações. ... 85
6 Resultados e Teste do Software. ... 86
6.1 Teste funcional 01 ... 86 6.1.1 Resultado 01. ... 89 6.2 teste funcional 02 ... 89 6.2.1 Resultado 02 ... 94 6.3 Teste funcional 03 ... 95 6.3.1 Resultado 03. ... 97
7 Conclusão e Trabalhos Futuros ... 98
7.1 Resultados da Implementação. ... 98
7.2 Discussão sobre o uso do ASP.NET MVC. ... 99
7.3 Trabalhos Futuros. ... 99
1
INTRODUÇÃO
1.1 MOTIVAÇÃO
Quando uma empresa trabalha com uma tecnologia específica há muito tempo existe certa dificuldade de adaptação para uma nova forma de trabalho, espe-cialmente quando essa tecnologia se torna obsoleta.
Há cerca de 10 anos, o processo de criar uma simples aplicação baseada em Windows era um processo confuso, difícil e extremamente demorado. Antes do lançamento do Visual Basic 1.0, em maio de 1991, construir uma aplicação sofisticada em uma interface gráfica não era uma tarefa fácil.
Com a chegada do Visual Basic (VB), os programadores puderam, pela primeira vez, implementar aplicativos Windows em um ambiente gráfico intuitivo. Ao permitir que tanto programadores profissionais como amadores pudessem aumentar sua produtividade, o Visual Basic passou a representar uma verdadeira revolução quanto ao ambiente de desenvolvimento de aplicações baseadas na plataforma
Win-dows.
Com a popularização crescente da internet, ficou claro para os desenvol-vedores que havia uma grande deficiência referente a ferramentas para desenvolvi-mento nessa área. Nos primórdios da Web, toda a informação era provida diretamente ao Browser do cliente e era estática.
Em 1996, surgiu o Active Server Pages (ASP), que não é uma linguagem de programação, mas sim uma estrutura de bibliotecas básicas para processamento de linguagens de script no lado servidor para geração de conteúdo dinâmico na Web. Com o passar dos anos, o crescimento da Internet provocou uma grande demanda por aplicações Web e ficou perceptível que o ASP não era o suficiente.
Em meados de 2000, a Microsoft anunciou o .NET e foi aí então que surgiu o ASP.NET WebForms, que teve um crescimento vertiginoso, abrindo um novo cami-nho para o desenvolvimento de aplicações web de forma rápida.
Devido ao surgimento de novos Frameworks a forma de se desenvolver
softwares mudou consideravelmente. Os prazos de entrega ficaram menores e a
equipe de desenvolvimento aumentou, algumas vezes com pessoas em vários países diferentes trabalhando em um mesmo projeto, sem a necessidade de deslocamento. Isso foi possível graças a padrões de projeto robustos e confiáveis que supriam todas as limitações e todos os problemas das antigas Integrated Development Environments (IDEs).
Um dos problemas mais comuns ocorria quando, inadvertidamente, mais de uma pessoa alterava o mesmo trecho de um documento especifico. Isso causava falhas graves ou inconsistências na aplicação que estava sendo desenvolvida.
Inúmeros problemas podem surgir na construção de sistemas que contive-rem mistura de código de acesso a dados junto com a lógica de negócios, (que é a parte de um sistema que se encarrega das tarefas relacionadas com os processos de um negócio, tais como vendas, controle de inventário, contabilidade, etc.) e a apre-sentação (que é a parte do sistema que o usuário visualiza, tais como textos, imagens, formulários, etc.). Essas aplicações são difíceis de manter, pois qualquer alteração que se faça é preciso ter cuidado para não refletir em outras partes do sistema.
Devido a estes fatores, foi escolhido para este trabalho o framework ASP.NET Model View Controler (MVC), que, em comparação com os WebForms, pos-sui grandes vantagens tais como: separação de responsabilidades (cada camada com a sua), escalabilidade, fácil de testar, código reusável, manutenção facilitada, total controle do HyperText Markup Language (HTML) e JavaScript gerado, entre outros.
1.2 OBJETIVO
O objetivo deste trabalho é a apresentação do framework ASP.NET MVC, do padrão de projeto MVC, bem como apresentar um exemplo prático de seu uso, através do projeto e implementação de um sistema de chamados, exemplificando as-sim a maneira como um software é desenvolvido utilizando o MVC.
1.3 ORGANIZAÇÃO DO TRABALHO
O presente trabalho organiza-se sob a forma de sete capítulos sendo este, Capítulo 1, o capitulo de introdução. O Capitulo 2 traz um breve relato histórico sobre a criação e evolução dos frameworks de desenvolvimento, mostrando algumas de suas funcionalidades desde os primórdios de sua utilização. O Capitulo 3 aprofunda-se na fundamentação teórica, mostrando a definição de framework, a arquitetura do padrão de projeto MVC, o Framework ASP.NET MVC, como são feitas as validações de dados e as anotações de código. O Capitulo 4 se dedica a demonstrar o desenvol-vimento da aplicação proposta neste trabalho, mostrando a parte relevante de sua construção. Nele será possível acompanhar pontos como: requisitos, interface, limita-ções e algoritmos relevantes. O Capitulo 5 apresentará a implementação do Sistema, a interface gráfica, as dificuldades de seu desenvolvimento e suas limitações. O Ca-pitulo 6 trará uma sequência de testes realizados com o aplicativo, mostrando vários cenários, seus resultados e a conclusão obtida em cada caso. Finalmente, no Capítulo 7, a conclusão deste trabalho e sugestões de trabalhos futuros.
2 HISTÓRICO - UMA VISÃO GERAL SOBRE A CRIAÇÃO E
EVOLUÇÃO DOS FRAMEWORKS DE
DESENVOLVI-MENTO.
Desenvolver programas de computador nem sempre foi uma tarefa fácil. Nos primordios do desenvolvimento de Software o conhecimento técnico se restringia a poucas linguagens de programação, principalmente Fortran, e IDEs precárias, com poucos recursos e nenhuma ferramenta gráfica.
Quando tem que se solucionar um problema no desenvolvimento de um
software utilizam-se os Frameworks, que são um conjunto de conceitos padronizados,
práticas e critérios usados para se concentrar em um determinado tipo de problema que serve como referência e para enfrentar e resolver novos problemas de natureza semelhante.
Como já não é mais necessário resolver problemas que já foram resolvidos por outros programadores, a produtividade dos mesmos aumenta significativamente.
Uma das principais utilidades dos Frameworks é a comunicação com o Banco de dados. Como já existem bibliotecas para isso, se torna relativamente facil fazer essa comunicação, assim ajudando a diminuir o tempo de desenvolvimento do
software.
Nos primordios da Internet as paginas web eram inteiramente estáticas, es-critas unicamente em HTML e contendo apenas textos. Quaisquer alterações deve-riam ser executadas pelos próprios autores das páginas. Para solucionar esse pro-blema foi introduzido o padrão Common Gateway Interface (CGI) que servia para co-nectar sites com servidores web. Isso foi um problema, por que no padrão CGI cada chamada ao servidor iniciava em um processo separado, isso sobrecarregava os ser-vidores [1].
Nessa época surgiam pela primeira vez ambientes de desenvolvimento in-tegrado (IDE, do inglês Integrated Development Environment) e algumas linguagens especificamente para o uso na web como ColdFusion, PHP e Active Server Pages (ASP).
Durante muitos anos a linguagem mais popular foi o PHP, como ele podia-se fazer requisições, acessar banco de dados, interagir de forma dinamica com os
usuarios, entre muitas outras funções, e o resultado da programação continuava sendo exibido em HTML para os clientes.
A forma de se desenvolver software mudou, já para os usuários finais do sistema não houveram mudanças tão drasticas por que o conteudo continuava sendo gerado em HTML, mas para os programadores o HTML passou a ser um detalhe no desenvolvimento, agora chamado de Front-End (que é toda a parte da apresentação visual do site, estrutura hierarquica das informações e o design para a exibição dessas informações) e o restante da aplicação, que não existia anteriormente e não é relaci-onado a parte visual, foi chamado de Back-End (onde ficam os codigos que dinamizam o site e também onde se encontram as regras de negócio) [18].
A grande maioria das linguagens de programação usadas na criação de páginas web possuem bibliotecas que ajudam nas tarefas comuns, porém as aplica-ções web, muitas vezes, exigem bibliotecas específicas que são úteis em aplicaaplica-ções
web, como a criação de HTML, por exemplo [18].
É possivel criar aplicações web com praticamente qualquer linguagem de programação como C#, PHP, Python, Ruby, Pearl ou Java. Alguns dos maiores sites do mundo, os que recebem milhões de acessos simultaneos, utilizam as linguagens que possuem um rápido desenvolvimento e não necessáriamente a melhor perfor-mance, já que o serviço deve funcionar sem interrupção e mesmo assim são neces-sárias correções e atualizações constantes em seu codigo fonte.
Eventualmente surgiram Frameworks que supriam praticamente todas as necessidades dos desenvolvedores até então, como: Ruby on Rails, Zend Framework e .NET.
Com o advento desses novos Framework o desenvolvimento de software foi pa-dronizado. Qualquer novo desenvolvedor em um projeto, com conhecimento tecnico do Framework que está sendo utilizado, conhece exatamente toda a estrutura hierar-quica do projeto, assim facilitando sua integração, e evitando que eventuais vicios de programação comprometessem a qualidade do software.
3 FUNDAMENTAÇÃO TEÓRICA.
3.1 DEFINIÇÃO DE FRAMEWORKS.
A definição de Framework pode variar muito de acordo com os vários autores que escreveram sobre o tema. Uma das melhores definições é, segundo Gamma, " um conjunto de classes que cooperam entre si provendo assim um projeto reutiliável para um domínio específico de classes de sistema” [1]. Essa definição simples descreve perfeitamente o conceito necessário para seu entendimento básico, porém vai muito além disso.
Entende-se uma biblioteca como uma aplicação das regras de uma API (Application Programming Interface), que, por sua vez, define formas de se executar uma tarefa específica.
Framework também pode ser entendido como uma plataforma de
desen-volvimento. Possui grande interdependência entre seus componentes, o que eventu-almente pode se tornar um problema caso o desenvolvimento da aplicação ocorra de forma incorreta.
Sendo uma estrutura de suporte bem definida, o projeto de um software pode ser organizado e desenvolvido através dele. A principal função do Framework é facilitar o desenvolvimento de softwares, evitando contratempos com detalhes de baixo nível, permitindo aos desenvolvedores concentrar mais seu esforço e tempo no desenvolvimento e na aplicação das regras de negócio do sistema, do que se preocu-pando com detalhes de baixo nivel
Tipicamente, Frameworks oferecem suporte a vários programas assim como várias extensões, de modo que sua integração seja facilitada, ajudando a unir os diferentes componentes de um projeto.
Fora das aplicações de computador, os frameworks, podem ser conside-rado como um conjunto de processos utilizados para resolver um problema de tecno-logias complexas. É o esqueleto sobre o qual vários objetos são integrados para uma dada solução.
3.2 ARQUITETURA DO PADRÃO DE PROJETO MVC.
3.2.1 Definição
O MVC (acrônimo para Model-View-Controller) é um padrão arquitetural inventado por Trygve Reenskaug, em 1978 e, de acordo com Freeman [2], “é um conjunto de outros padrões de projetos trabalhando juntos em uma mesma estrutura”.
O MVC é um padrão de arquitetura que separa uma aplicação em três principais com-ponentes lógicos: o modelo (onde se encontram as regras de negócio), a visão (a parte do sistema que o usuário visualiza), e o controlador (responsável por ser o inter-mediario entre o modelo e a visão do sistema, entre outras funções). Cada um desses componentes são construídos para lidar com aspectos específicos de uma aplicação de desenvolvimento. De acordo com uma publicação do site www.devmedia.com.br, MVC é um dos frameworks mais antigos e mais utilizados atualmente [3].
A Figura 1 exemplifica a interação entre os componentes na arquiterura MVC. Quando um usuário faz alguma requisição em um site ele, na verdade, está interagindo somente com a camada de controle, o usuário final não tem acesso direto a logica do negócio. O controle é responsável por, de acordo com a solicitação rece-bida, recuperar informações da camada de modelo e enviar para o cliente a resposta formatada através de uma visão.
O cliente também pode, através de uma visão, interagir com o modelo, por exemplo para se logar (obter acesso) ao sistema. Porém, a camada de modelo nunca respoderá diretamente a visão, sempre ira se comunicar somente com a camada de contole.
Figura 1 – Interação entre os componentes na aquitetura MVC [4].
3.2.2 A camada de Modelo (Model).
O Modelo corresponde a todos os dados relacionados a lógica com que o usuário trabalha. Isso pode representar tanto os dados que estão sendo transferidos entre a Visão e os componentes do Controlador ou qualquer outra lógica de negócios de da-dos relacionada-dos. O modelo representa os dada-dos [5] e não dependem do controlador ou a visão.
As classes são utilizadas para armazenar e manipular estado, tipicamente numa base de dados de algum tipo.
Por exemplo, um objeto Cliente irá recuperar as informações do cliente no banco de dados, manipulá-lo e atualizá-lo de volta para o banco de dados ou usá-lo para pro-cessar dados.
Somente os dados são tratados no modelo, de acordo com regras especí-ficas (data não pode ser no futuro, e-mail deve ter um formato específico, o nome não pode ser maior do que x caracteres, etc).
O modelo é também conhecido como objeto de domínio ou entidade de domínio. Os objetos de domínio são armazenados na pasta Modelos, quando for uti-lizado, por exemplo, o framework ASP.NET. O modelo de domínio representa a pers-pectiva de aplicação para os dados a serem tratados, enquanto que um modelo de exibição é necessário para produzir o motor, as informações necessárias, que geram a Visão.
Assim, o modelo é a maior camada, a mais importante na maioria das apli-cações MVC. É por isso que é normalmente dividido em sub-camadas: Domínio, Ser-viço e acesso a dados. O modelo é normalmente exposto através do domínio, porque é lá onde você vai encontrar os métodos que o controlador irá chamar. Mas a camada de acesso a dados pertence ao modelo também. Tudo o que está relacionado à per-sistência de dados e lógica de negócios pertence a ele.
3.2.3 A camada de Controle (Controller).
Controladores funcionam como interlocutores entre os componentes do Modelo e os componentes da Visão, para processar toda a lógica de negócios e solicitações de entrada, manipular dados usando o componente de Modelo e interagir com os modos de exibição e, assim, renderizar o resultado. O controlador une a visão e o modelo [7]. O controlador gerencia as solicitações do usuário (recebido como requisi-ções HTTP GET ou POST, quando o usuário clica em elementos da interface gráfica do usuário para executar ações). Sua principal função é chamar e coordenar os recur-sos necessários / objetos necessários para executar a ação do usuário. Normalmente, o controlador irá chamar o modelo adequado para a tarefa e, em seguida, seleciona a visão adequada.
Por exemplo, o Controlador irá lidar com todas as interações e as entradas da Visão do cliente e atualizar o banco de dados usando os componentes do Modelo. O mesmo Controlador poderia ser utilizado para visualizar os dados do cliente.
O controlador utiliza os métodos de modelo para recuperar informações so-bre o objeto do aplicativo, para alterar o status do objeto e informar a visão soso-bre esta mudança. Em certo sentido, o controlador permite que um usuário possa fazer altera-ções e ver os resultados.
A aplicação web é normalmente composta por um conjunto de controladores, modelos e visões. O controlador pode ser estruturado como um controlador principal que recebe todas as solicitações e chama controladores específicos que lidam com ações para cada caso.
Um controlador utiliza ações (Actions) do controlador. Uma ação é um mé-todo em um controlador que é chamada quando se entra em uma determinada URL
na barra de endereços do navegador. Devido a isso, no framework ASP.NET MVC as URLs são amigavés, por exemplo “http://localhost/Produto/Index”, onde o controle Produto invoca a visão Index.
3.2.4 A camada de Visão (View).
O componente de Visão é usado para toda a lógica de interface do usuário do aplica-tivo. Oferece maneiras diferentes de apresentar os dados recebidos a partir do mo-delo. Eles podem ser Templates (um documento sem conteúdo, com apenas a apre-sentação visual e instruções sobre onde e qual tipo de conteúdo deve entrar) onde esses dados são preenchidos.
Visões não sabem como os dados serão mostrados para os usuários, eles somente apresentam esses dados [6].
Por exemplo, o ponto de vista do cliente que incluem todos os componentes de inter-face do usuário, tais como caixas de texto, menus suspensos, formulários, etc. que o utilizador final interage.
Um sistema pode ter várias visões de vários tipos diferentes que variam de acordo com os dispositivos que acessam. A visão não consiste em lógica de negócios na maioria dos projetos, e por boa prática não deve conter. Portanto, não importa qual a visão será utilizada no momento pois todas usam a mesma lógica de negócios do modelo e interagem com o controle da mesma forma.
A visão pode filtrar alguns aspectos do modelo ou destacar outros. Repre-senta os dados de entrada e saída em uma interface usando vários elementos, como botões, menus, caixas de diálogo, etc. Para ver o status dos objetos de aplicação, a visão consulta o modelo através do controlador.
As pastas de visões armazenam os arquivos (tipicamente HTML) relaciona-dos à tela do aplicativo (as interfaces de usuário). Esses arquivos podem ter as exten-sões html, asp, aspx, cshtml e vbhtml, entre outras dependendo da linguagem de pro-gramação utilizada e da IDE.
3.2.5 Vantagens e Desvantagens do uso do padrão MVC.
Entre as muitas vantagens da arquitetura MVC a que mais se destaca é a divisão clara de responsabilidades entre suas 3 camadas principais. A separação dos três compo-nentes, permite a reutilização da lógica de negócios entre aplicativos, assim como múltiplas interfaces de usuário podem ser desenvolvidas sem importar a base de có-digo, ou seja, como as regras de negocios não estão ligadas a nenhuma interface específica da aplicação, pode-se desenvolver interfaces para diversos dispositivos di-ferentes com resoluções de tela especificas utilizando para todas as interfaces as mesmas regras de negócio.
Interfaces de usuário tendem a mudar com mais frequência do que as re-gras de negócios (Diferentes cores, fontes, layouts de tela e níveis de suporte para novos dispositivos, como telefones celulares ou iPads). Como o modelo não depende da visão, adicionando novos tipos de visão para o sistema, geralmente, não afeta o modelo. Como resultado, o âmbito da mudança se restringe ao que foi modificado sem afetar outros componentes.
A modularidade eficiente no padrão MVC permite que qualquer um dos com-ponentes sejam alterados conforme o desejo do programador, inclusive o modelo. Al-terações em uma característica do programa não são acoplados a outras característi-cas, eliminando muitas situações desagradáveis de depuração. Além disso, o desen-volvimento dos vários componentes pode progredir em paralelo, uma vez que a inter-face entre os componentes é claramente definida.
O desenvolvedor do Modelo pode se concentrar exclusivamente nas imple-mentações de lógica de negócios, realizar alterações sem se importar com a aparên-cia da aplicação ou como é executada a comunicação com a mesma, sem haverliga-ção alguma com a lógica de negócios. Assim como os desenvolvedores de interface do usuário podem se concentrar exclusivamente nas telas da interface do usuário, sem se preocupar a com lógica de negócios.
As três camandas principais da arquitetura MVC, que são a visão, o contro-lador e o modelo, não são as unicas camadas que podem ser utilizadas no desenvol-vimento de uma aplicação. O MVC usualmente usa o modelo 3-tier ou seja, 3 cama-das, mas na verdade este é um modelo n-tier, onde podem haver quantas camadas forem necessárias.
Entre as desvantagens se destaca a complexidade. O padrão MVC possui uma complexidade alta se comparada a outras formas de desenvolvimento de
sof-tware, como a programação procedural por exemplo.
Também apresenta um alto custo em suas atualizações pois, caso seja ne-cessário atualizar um dos componentes, por exemplo adicionar um atributo novo mo-delo, obrigatoriamente será necessario atualizar também o controlador e a visão res-ponsável pela exibição do novo atributo.
3.3 FRAMEWORK DE DESENVOLVIMENTO PARA SERVIDOR WEB.
Um framework de aplicações web é um tipo de estrutura que permite o de-senvolvimento de sites dinâmicos, serviços web (Web Services) e aplicações web. A finalidade deste tipo de estrutura é permitir que os desenvolvedores criem aplicativos da web se concentrando nas especificações, aliviando a tarefa repetitiva típica asso-ciada a padrões comuns de desenvolvimento. A maioria dos frameworks para aplica-ções web fornecem os tipos de funcionalidade básica comuns, tais como templates para exibição de dados, gestão de sessões de usuário, armazenamento de cache do conteúdo do banco de dados e persistência de dados. Normalmente, frameworks de aplicação web também promover a reutilização e componentes de conectividade, bem como a reutilização de código e implementação de bibliotecas de acesso aos bancos de dados.
Entre os frameworks mais utilizados pelo mercado se destacam:
• ASP.NET MVC, que atualmente é o mais utilizado do mundo [8], uma de suas pedras angulares é o conceito de roteamento (routing), que permite que os aplicativos possam aceitar solicitações de URLs que não correspondem a arquivos físicos no servidor. Por exemplo, em ASP.NET Web Forms URLs têm o seguinte formato "http://cate-goria/website/products.aspx=dvd?", em que há fisicamente o ar-quivo Products.aspx na raiz do site. Em MVC o mesmo URL será parecido com "http://site/products/dvd" sem que o servidor web con-tenha necessariamente uma pasta products com uma subpasta dvd.
Por padrão, a rota ASP.NET MVC pede ao controlador a visão apro-priada dependendo da URL. Ou seja, no exemplo acima, vamos através do controlador products, exibir a visão DVD.
• AngularJS, é um framework de javascript desenvolvido pela em-presa Google. É usado para criar e manter aplicações web a partir de uma única página. Seu objetivo é aumentar o numéro de aplica-ções web utilizando MVC, em um esforço para tornar o desenvolvi-mento e teste mais fácil.
• Ruby on Rails, usado para construir aplicações da Web que aces-sam bancos de dados. Utiliza um conjunto de bibliotecas, automa-ções e convenautoma-ções destinadas a resolver problemas comuns no de-senvolvimento de uma aplicação web, de modo que o programador pode concentrar-se nos aspectos únicos e diferentes de seu projeto, em vez de problemas recorrentes [11]. Entre grandes aplicações
web que utilizam Ruby on Rails estão Twitter, Hulu e Github. É
man-tido através de uma comunidade ativa.
3.4 FRAMEWORK ASP.NET MVC.
Desde a primeira versão do framework .NET, o mesmo conta com um amplo suporte a construção de páginas web. Devido aos numerosos recursos que esta plataforma oferece, torna-se possível a construção de web sites e web services poderosos. Quanto à web sites, o ASP.NET oferece, desde seus primórdios, um recurso chamado web forms.
A sintaxe Razor (navalha em inglês) é baseada na linguagem de progra-mação C# (lê-se C sharp), e é a linguagem mais usada para construção de páginas
Web em ASP.NET MVC [12]. No entanto, a sintaxe Razor também suporta outras
linguagens como o Visual Basic, entretanto há limitações técnicas entre elas.
Além de administrar a complexidade, o padrão MVC torna o teste de apli-cativos mais fácil se comparado com Web Forms. ASP.NET oferece três frameworks para a criação de aplicações web: Web Forms, ASP.NET MVC, e ASP.NET Web
web com qualquer um deles. Cada framework tem como alvo um estilo de
desenvol-vimento diferente. Para este estudo foi escolhido ASP.NET MVC devido a sua facili-dade de desenvolvimento e sua flexibilifacili-dade.
3.5 VALIDAÇÃO DE DADOS.
No ASP.NET MVC a validação de dados é aplicada no modelo, porém para melhorar o desempenho do servidor também há validação na camada de visão. Normalmente essa validação da camada de visão é feita em JavaScript ou alguma outra linguagem que rode no lado do cliente, ou seja, que é executada no dispositivo que está aces-sando o servidor. Isso é útil pois evita, ou dificulta, que dados incorretos sejam envia-dos, diminuindo a quantidade de interações com servidor, o que afeta diretamente seu desempenho. A validação na camada de visão não é obrigatória, porem recomen-dada.
A validação aplicada no modelo ocorre através dos DataAnnotations, que são regras aplicadas nas classes usadas na aplicação. Funcionam como atributos para a classe, por exemplo pode-se definir que o campo “Nome” da classe “Usuário” é obrigatório e não pode ter mais de 80 caracteres, assim, definindo-se apenas uma vez esses atributos, toda vez a classe for instanciada, em qualquer lugar da aplicação, essa validação será utilizada, otimizando o desenvolvimento e garantindo homogenei-dade na validação, a Figura 2 mostra o exemplo de uma classe descrita.
3.6 ANOTAÇÕES DE CÓDIGO NO ASP.NET MVC.
As anotações de código implementam a validação das classes do modelo. O namespace DataAnnotations usa duas formas de validação, no lado do cliente
(Cli-ent-Side) e no lado do servidor (Server-Side). Quando se declara um atributo de
vali-dação como por exemplo campo requerido, os DataAnnotations geram automatica-mente a mesma validação no lado do cliente, incorporando as regras no código HTML gerado.
Algumas das validações mais utilizadas são:
• Required – O campo é obrigatório, no caso de um cadastro, por exemplo, o formulário não poderá ser submetido se que esse campo esteja preenchido com algum valor.
• StringLength – Define a quantidade máxima de caracteres que um campo pode possuir, quando a validação Client-Side é gerada o atributo StringLength se torna MaxLength.
• MinLength – Define a quantidade mínima de caracteres que um campo deve possuir.
• Range – Define, ao mesmo tempo, a quantidade mínima e máxima que um campo pode possuir, útil para campo de senha por exemplo.
• DisplayName – Define um texto que será exibido como Label (etiqueta) do campo.
A Figura 3 exemplifica o uso dos atributos citados. Note que foi usado tam-bém uma mensagem de erro diferente para cada validação utilizando o ErrorMessage. Deste modo pode-se exibir mensagens de erro diferentes dependendo do atributo que está sendo validado. Por exemplo o uso de MaxLength e MinLength no campo Lem-breteSenha foi usado para exibir mensagens de erro distintas dependendo da quanti-dade de caracteres inseridos, ao invés ser usado Range, que na prática tem o mesmo efeito que MaxLength e MinLength juntos, porém pode exibir somente uma mensagem de erro.
Figura 3 – Classe Usuário utilizado DataAnnotations.
Outro atributo muito usado é a expressão regular, usado principalmente para evitar que caracteres especiais sejam digitados ou para que sejam digitados so-mente números por exemplo. A figura 4 demostra o uso da expressão regular nos
DataAnnotations validando o formato do campo Email e exibindo uma mensagem de
erro caso seja digitado um caractere não numérico no campo idade.
4 SISTEMA PROPOSTO – “SISTEMA DE CHAMADOS”
Neste capitulo será demostrado o desenvolvimento de uma aplicação utili-zando OO (Orientação a Objetos) para demostrar o uso do framework ASP.NET MVC. Serão mostradas apenas as partes relevantes de sua construção e desenvolvimento, abordando cada fase de seu desenvolvimento. O código por completo poderá ser ob-tido no endereço https://github.com/EvandroCordeiro/TCC.
4.1 DEFINIÇÃO DO PROBLEMA – “PROCESSO DE CHAMADOS”.
A comunicação de empregados de uma empresa é de fundamental importância para a correta execução de várias atividades. Muitas dessas atividades utilizam ferramen-tas de trabalho como computadores e seus softwares. Porém, é muito comum que ocorram dúvidas ou problemas relacionados ao uso correto destas ferramentas.
O sistema proposto neste trabalho busca uma forma padronizada para a resolução destes problemas, no caso de problemas relacionados ao Hardware (parte física dos computadores) um técnico será notificado e se deslocará fisicamente para resolver o problema. No caso de problemas ou dúvidas relacionadas a Softwares, se-rão respondidas pelo próprio sistema de chamados.
O sistema de chamados também poderá ser utilizado para consulta no caso de problemas similares ocorrerem ajudando a agilizar sua resolução, assim como manter um registro formal de comunicação entre as partes envolvidas no processo para eventual auditoria interna por parte da empresa.
4.2 SOLUÇÃO PROPOSTA.
Levando em consideração o problema descrito na seção anterior, o objetivo da apli-cação proposta é padronizar e formalizar a comuniapli-cação na resolução de problemas de caracter técnico envolvendo equipamentos eletrônicos e seus softwares em uma
empresa. Nesta empresa, um setor de manutenção tem a necessidade de um sistema para gerenciar os serviços a ele solicitados.
O sistema deve permitir aos solicitantes abrirem chamados relativos a pro-blemas ou duvidas no uso de equipamentos ou no uso de programas de computador, podendo também anexar um arquivo ao chamado para a melhor compreensão do problema.
O Sistema de Chamados deve permitir que os técnicos respondam aos chamados dos solicitantes e, caso haja necessidade, também poderão incluir um ar-quivo na mensagem de resposta.
Os solicitantes que podem fazer solicitações ao Sistema de Chamados de-verão ter cadastro prévio no computador que guarda as informações de login de acesso da rede da Empresa, não sendo necessário o cadastro no Sistema de Cha-mados. Cada chamado aberto poderá conter várias respostas de ambas as partes envolvidas, até a resolução do problema.
O sistema proposto neste trabalho realiza a padronização e o controle de requisições de usuários, em que uma pessoa qualificada (técnico) é responsável por solucionar problemas específicos atribuídos a ela.
Cada usuário do sistema poderá abrir chamados informando problemas ocorri-dos e para isso, o usuário deverá descrevê-lo em detalhes. O sistema também permite o upload (envio) de anexos, como print screens (captura de tela), fotos ou documentos de texto que auxiliam na descrição do problema reportado pelo usuário.
Os usuários regulares (não técnicos) só podem visualizar os chamados abertos por eles mesmos e não podem alterar o status (estado) do chamado, por exemplo: os usuários não podem fechar um chamado, ou seja, marcá-lo como concluído. Por outro lado, os técnicos podem visualizar os chamados com qualquer status e de todos os usuários, porém eles não podem abrir novos chamados.
A comunicação entre o técnico e o usuário ocorre através da troca de mensa-gens dentro chamado relacionado. Ambos podem, a qualquer tempo, anexar arquivos e enviar novas mensagens. No caso da necessidade de o técnico ter de ir ao local reparar algo fisicamente, isso deverá ser informado em uma mensagem. Após o pro-blema ser resolvido, o técnico descreve como foi feita a resolução e o chamado é encerrado pelo mesmo.
A maior vantagem do Sistema de Chamados é a padronização da comuni-cação na resolução de problemas, desta maneira, caso ocorram problemas que já
tenham sido resolvidos, o técnico pode consultar as infomações contidas nos chama-dos anteriores para auxiliá-lo na resolução de problemas semelhantes, agilizando o processo
4.3 ESPECIFICAÇÃO.
As especificações deste software foram realizadas aplicando o padrão UML e com o padrão de projeto o modelo MVC. Utilizando como ferramenta a IDE Visual Studio
Comunity 2015 e o Banco de Dados SQL Server 2012 Express.
O sistema será dividido em 3 camadas.
A camada de Visão, responsável por toda a interface com o usuário, es-tando aqui as figuras e os formulários, principalmente, assim como qualquer elemento gráfico que venha a fazer parte do sistema de chamados, podendo inclusive haver mais de uma Visão para o mesmo Modelo. Isto pode ser particularmente útil para uma futura implementação do Sistema de Chamados (que não será feita neste estudo) para dispositivos com tamanhos de tela diferentes, como smarthphones e tablets. As-sim, desta maneira, reutiliza-se toda a lógica do modelo, evitando o retrabalho. A ca-mada de Visão exibirá para o usuário informações contidas no Banco de dados.
A camada de Modelo, que é a mais importante, será responsável por todas as regras de negócio, é aqui também onde se aplicam os DataAnnotations, que serão responsáveis por validarem os dados do Modelo. O modelo se comunica diretamente com o banco de dados para atender as requisições dos usuários do sistema. Aqui se fazem validações para garantir o estado consistente dos dados que serão gravados no bando de dados, assim como a recuparecão desses dados para exibição. Respo-sável também por “informar”, isto é, atualizar as informações, caso tenham sofrido alterações, nas outras camadas. No Sistema de Chamados que será desenvolvido neste estudo, a camada de Modelo conterá as validações de todas as entradas dos campos (inputs) que a aplicação possa vir a ter, assim, caso uma entrada seja usada em mais de uma Visão, não será necessária uma nova implementação.
A camada de controle, que é a camada intermediária entre as camadas de Visão e Modelo, será responsável por responder as requisições dos usuários, mani-pulando eventos, traduzindo-os como solicitações para a camada de Modelo, assim
como traduzir a resposta da Camada de Modelo para a Visão afim de que esta possa exibir ou informar corretamente (e somente) o que foi solicitado. No Sistema de Cha-mados a camada de Controle será responsável também por filtrar, isto é, realizar uma seleção das informações que deverão ser exibidas ou não, dependendo do perfil de acesso que foi utilizado pelo usuário (Solicitante ou Técnico), assim como restringir algumas funções do sistema usando o mesmo critério.
As três camadas são independentes umas das outras, o que agrega uma maior complexidade, porém agiliza o desenvolvimento e manutenção.
4.3.1 Requisitos.
Existe apenas dois atores que são usuários do sistema, podendo se com-portar das seguintes maneiras:
1. Solicitante – Realizando a abertura do chamado. 2. Técnico – Respondendo a uma solicitação.
4.3.1.1 Requisitos Não-Funcionais.
1. O sistema deve ser desenvolvido utilizando a linguagem C#. 2. O sistema deverá se comunicar com o SQL Server.
3. O sistema deve possibilitar a inclusão de um texto de até 300 caracteres. 4. O sistema deve possibilitar a inclusão de um arquivo nos formatos jpg, png, txt,
docx, pdf ou xlsx.
4.3.1.2 Requisitos Funcionais.
2. O sistema deve alertar o técnico para garantir que ele responda a uma solicita-ção em até 24 horas.
3. Ao consultar um chamado, o sistema deve exibir as mensagens relacionadas. 4. Ao consultar um chamado, caso exista um arquivo incluso, possibilitar gravação
em um diretório a ser informado pelo usuário.
5. O usuário que não for técnico só terá acesso aos chamados abertos por ele. 6. Exibir em cada mensagem de cada chamado a data e hora de sua inclusão no
sistema.
7. Exibir a data e hora de abertura e fechamento do chamado.
4.3.2 Diagramas de Caso de Uso.
A Figura 5 demostra as funcionalidades do sistema de chamado do ponto de vista dos usuários Solicitante e Técnico. Segundo Ivar Jacobson, podemos dizer que um caso de uso é um "documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo [13]. "
Figura 5 – Diagrama de Caso de uso.
4.3.3 Descrição dos Casos de Uso.
NOME:
Abrir Chamado.
DESCRIÇÃO SUCINTA:
Solicitante abre um ou mais chamados no sistema. ATORES:
1. Solicitante. PRÉ-CONDIÇÕES:
1. Solicitante logado no sistema. FLUXO BÁSICO:
1. O Solicitante, na tela principal do sistema, seleciona a opção de abertura de chamado.
2. O Solicitante seleciona a opção ”Abrir Chamado”. 3. O Sistema exibe a tela de abertura de chamado.
4. O Solicitante digita o Titulo, seleciona uma categoria e digita a descrição do problema.
4.1 O Solicitante pode anexar um arquivo no chamado, caso desejar.
5. O Sistema grava as informações, exibe a data e hora de abertura e redireciona para a Tela do item 3.
6. O Sistema exibe a data e hora de abertura do chamado. 7. O caso de uso é encerrado.
NOME:
Consultar Chamados Próprios. DESCRIÇÃO SUCINTA:
O Solicitante consulta um chamado que foi aberto por ele mesmo.
ATORES:
1. Solicitante.
FLUXO BÁSICO:
1. O Sistema exibe a tela principal do sistema. 2. O Solicitante seleciona um chamado aberto. 3. O Sistema exibe a tela do chamado selecionado.
3.1 Caso existam mensagens relacionadas o Sistema as exibe assim como suas respectivas datas e horas de inclusão.
NOME:
Modificar Chamado.
Solicitante ou Técnico responde chamado. ATORES:
1. Solicitante ou Técnico. PRÉ-CONDIÇÕES:
1. Ter executado o caso de uso “Abrir Chamado”. FLUXO BÁSICO:
1. O Sistema exibe a tela principal do sistema.
2. O Solicitante ou Técnico seleciona um chamado aberto. 3. O Sistema exibe a tela do chamado selecionado.
3.1 Caso existam mensagens relacionadas o Sistema as exibe assim como suas respectivas datas e horas de inclusão.
4. O Solicitante ou Técnico digita a resposta.
4.1 O Solicitante ou Técnico pode anexar um arquivo no chamado, caso desejar.
5. O Sistema grava as informações e redireciona para a Tela principal. 6. O caso de uso é encerrado.
NOME:
Consultar Todos os Chamados.
DESCRIÇÃO SUCINTA:
O Técnico consulta uma lista de chamados que tenham qualquer status.
ATORES: 1. Técnico.
1. Um Solicitante haver executado o caso de uso “Abrir Chamado”.
FLUXO BÁSICO:
1. O Sistema exibe a tela principal do sistema.
2. O Técnico seleciona a opção “Consultar Todos os Chamados”. 3. O Sistema exibe a tela com a lista de todos os chamados.
NOME:
Alterar Status do Chamado.
DESCRIÇÃO SUCINTA:
O Técnico consulta um chamado altera seu status.
ATORES: 1. Técnico.
PRÉ-CONDIÇÕES:
1. Um Solicitante haver executado o caso de uso “Abrir Chamado”. 2. Um Técnico haver executado o caso de uso “Modificar Chamado”. 3. Um Solicitante haver executado o caso de uso “Modificar Chamado”.
FLUXO BÁSICO:
1. O Sistema exibe a tela principal do sistema. 2. O Técnico seleciona um chamado aberto. 3. O Sistema exibe o chamado.
3.1 Caso existam mensagens relacionadas o Sistema as exibe assim como suas respectivas datas e horas de inclusão
NOME:
Fechar Chamado.
DESCRIÇÃO SUCINTA:
O Técnico altera o status de um incidente aberto. ATORES:
1. Técnico. PRÉ-CONDIÇÕES:
1. Um Solicitante haver executado o caso de uso “Abrir Chamado”.
2. Ter executado o caso de uso “Reponder Chamado” como Técnico ao menos uma vez.
FLUXO BÁSICO:
1. O Sistema exibe a tela principal do sistema. 2. O Técnico seleciona um chamado aberto.
3. O Sistema exibe a tela do chamado selecionado.
3.1 Caso existam mensagens relacionadas o Sistema as exibe assim como suas respectivas datas e horas de inclusão
4. O Técnico seleciona o status “Fechado”.
7. O Sistema grava as informações e redireciona para a Tela principal. 8. O Sistema exibe a data e hora de fechamento do chamado
9. O caso de uso é encerrado.
4.3.4 Modelagem de Dados.
A figura 6 demonstra a modelagem de dados, exemplificando as características do funcionamento e comportamento do sistema.
Figura 6 – Modelagem de Dados.
4.3.4.1 Diagrama de Classes.
A figura 7 exemplifica o Diagrama de Classes, que é a representação da estrutura e relações das classes que compõem o sistema de chamados.
Figura 7 – Diagrama de Classes.
4.3.5 Banco de Dados.
O sistema de chamados usará o Sistema Gerenciador de Banco de Dados (SGBD) SQL Server Express 2012 e usará a estrutura demostrada na seção Modelagem de dados.
4.3.6 Projeto da Interface do Software.
Nesta seção será exibido o projeto da interface do software, que representa uma pos-sivel renderização das Visões que serão apresentadas aos usuários do sistema. A figura 8 representa o projeto da tela inicial, onde se realiza o acesso ao sistema, a tela de Login. A figura 9 se refere ao projeto da tela Principal do Solicitante, contendo os botões de sair, abrir chamado e Consultar Chamados. O projeto da tela Principal para o Técnico é análogo, demostrada na figura 10.
Figura 9 – Projeto da tela Principal do Solicitante.
Figura 10 – Projeto da tela Principal do Técnico.
A figura 11 mostra o projeto da tela de Consultar Chamados, usada pelo Solicitante para consultar seus próprios chamados que possuam quaisquer status. A figura 12 é análoga para o Técnico, porém consultando os chamados de todos os Solicitantes de Sistema.
A interface do processo de abertura de Chamado está exemplificada na figura 13, e pode ser acessada unicamente através da tela principal do Solicitante. A figura 14 demostra o projeto da tela do chamado, é nela que se pode adicionar no-vas mensagens e, no caso do Técnico, alterar seu status.
Figura 11 – Projeto da tela Consultar Chamados.
Figura 13 – Projeto da tela de abertura de chamados.
5 IMPLEMENTAÇÃO DO SISTEMA.
Neste capítulo, será apresentada a implementação do Sistema de Chamados a fim de exemplificar o uso do modelo de arquitetura de software MVC, destacando par-tes relevanpar-tes do código desenvolvido.
A Seção 5.1 descreve a arquitetura do Sistema de Chamado, descrevendo seu modelo de implementação e como os módulos do sistema se comunicam entre si. Na Seção 5.2, é descrita a estrutura básica do sistema utilizando o framework ASP.NET MVC no ambiente de desenvolvimento Microsoft Visual Studio Community 2015. A Seção 5.3 discute a implementação da interface gráfica do usuário do sistema apre-sentando suas telas. A seção 5.4 é dedicada à discussão da segurança do padrão de projeto MVC. Por fim, na Seção 5.5, são mostradas as limitações do software proposto neste trabalho.
5.1 ARQUITETURA DE SOFTWARE.
No padrão MVC, as requisições dos usuários passam por um controle para aces-sar informações do modelo de dados. Entende-se requisições como qualquer ação que necessite de uma resposta do servidor.
Neste projeto de software, haverá dois controllers interagindo com quatro clas-ses, que compõem a camada de domínio. A Figura 15 mostra a arquitetura de software do sistema proposto através do diagrama de pacotes, que ilustra como a comunicação é realizada entre o front-end e back-end do Sistema de Chamado.
Figura 15 – Diagrama de pacotes
Na pacote model, existem as classes responsáveis por implementar as entida-des do modelo do sistema. Essas classes possuem diversas anotações sobre seus atributos (DataAnnotations) que refletem no comportamento da interface gráfica do sistema, isto é, nas classes responsáveis pela criação das telas do sistema que com-põem o pacote view. Por exemplo, quando é utilizada a anotação “[Required]” no atri-buto nome da classe Usuario, as classes do pacote view que implementam campos de entrada referentes ao nome da classe Usuario devem ser preenchidos pelo usuário do sistema. Dessa forma, isto auxilia o usuário a preencher corretamente os formulá-rios do sistema evitando que requisições inválidas sejam feitas para o servidor Web.
Como já foi mencionado antes neste estudo, a arquitetura MVC se baseia em três camadas com funções distintas. A camada de modelo contém as regras de negó-cio e as classes do domínio, conforme mostrado na Figura 15. A camada de controle contém validações e funciona como intermediária entre as outras duas camadas. E a camada de visão implementa a interface gráfica do usuário, sendo composta por ar-quivos que podem ser visualizados em um navegador e são tipicamente arar-quivos HTML.
5.2 AMBIENTE DE DESENVOLVIMENTO E LINGUAGENS UTILIZADAS.
Utilizando a IDE Microsoft Visual Studio Community 2015 a estrutura básica do MVC é criada automaticamente, porém algumas modificações nessa estrutura foram ne-cessárias a fim de destacar as camadas do MVC. Essas alterações serão apresenta-das mais adiante neste capítulo.
Apesar desta IDE permitir o desenvolvimento em diversas linguagens como
Vi-sual Basic, C++, Python e F#, para este estudo, a linguagem C# foi utilizada.
O banco de dados utilizado é o SQL Server Express 2012, que é uma versão gratuita, porém limitada da versão SQL Server 2012. Este é o sistema de gerencia-mento de banco de dados (SGBD - do inglês Data Base Management System ou DBMS) com maior compatibilidade e o que requer menor configuração quando usado em conjuto com qualquer versão do Visual Studio.
A figura 16 mostra a estrutura básica de um projeto MVC criado no Visual Studio. A seguir, cada item da estrutura será discutido.
Figura 16 - Estrutura de pastas
• Properties: Estrutura utilizada para definir as propriedades do projeto. Contém apenas, para este projeto especificamente, o arquivo
Assem-blyInfo.cs, que é utilizado para controlar os atributos do assembly, como
título do projeto, direitos autorais, versão, etc.
• References: Possui as referências dos assemblys adicionados no projeto. Por exemplo, a referência ao Entity Framework responsável pela comuni-cação com o Banco de Dados.
• App_Data: Utilizada para armazenar arquivos de banco de dados ou ar-quivo de dados, que podem ser arar-quivos XML.
• App_Start: Pasta utilizada para armazenar arquivos de configuração como os arquivos BundleConfig.cs (utilizado na configuração de Bundle e
Minification, que serve para compactar arquivos .css (Cascading Style Sheet ou folhas de estilo) e arquivos de script) [14], FilterConfig.cs
(utili-zado para registrar os filtros globais do MVC) e RouteConfig.cs (utili(utili-zado para registrar rotas) [15].
• Content: Pasta utilizada para armazenar os arquivos CSS que são utiliza-dos no projeto.
• Controllers: Contém os controles da aplicação. • Fonts: Pasta padrão utilizada pelo bootstrap.
• Models: Utilizada para armazenar o modelo da aplicação, representado pelas classes que representam as entidades do modelo e outras que são responsáveis pela comunicação com o banco de dados.
• Scripts: Armazena arquivos JavaScript.
• Views: Utilizada para armazenar todos os arquivos responsáveis por im-plementar a interface gráfica do usuário, ou seja, as páginas HTML. Para cada Controle existe uma subpasta dentro da pasta Views. Esta também contém uma pasta chamada Shared, que é utilizada para armazenar o arquivo _Layout.cshtml (que funciona como a Master Page da aplicação),
views (que são arquivos HTML) e partial views (também são arquivos
HTML, porém com a diferença de não possuir toda a estrutura de um ar-quivo HTML completo, é usado principalmente quando uma parte da um
view, como uma tabela por exemplo, precisa ser usada em varias outras views) que são compartilhados pelo projeto. Contém ainda dois arquivos
chamados ViewStart.cshtml (utilizado para configurar qual será a Master
Page. Por padrão, é a _Layout.cshtml) e Web.config (a funcionalidade
principal desse arquivo é proibir o acesso direto às views). • Favicon.ico: ícone que aparece no browser ao lado da URL.
• Global.asax: Utilizado para configurar eventos, por exemplo, quando a aplicação inicia ou é encerrada, etc.
• Package.config: Utilizado para controlar os pacotes que são utilizados no projeto.
• Project_Readme.html: Um arquivo de help (ajuda), que contém links ex-plicando as funcionalidades do ASP.NET MVC.
• Web.config: Utilizado para configurar appSettings, conexões de banco de dados, autenticação, autorização, referências de assemblys, etc.
O objetivo principal deste trabalho é a apresentação das vantagens da arquite-tura MVC. Como primeiro passo para a construção do software de exemplo, é adicio-nado na pasta App_Data um item do tipo SQL Server Database como mostrado na Figura 17. Isso cria um arquivo MDF, que é um banco de dados local.
Figura 17 - Adiconado o Banco de Dados
Após isso, é necessário criar as tabelas do banco de dados, esta etapa de mo-delagem não será mostrada aqui, porém para deixar claro, foram criadas quatro tabe-las: Anexo, Chamado, Mensagem e Usuario.
Em seguida, é adicionado ao projeto um novo item à pasta Models, que é res-ponsável pela comunicação com o bando de dados através do Entity Framework, ge-rando todas as entidades, ou seja, as classes (Anexo.cs, Chamado.cs, Mensagem.cs e Usuario.cs) automaticamente. A Figura 18 mostra a adição ao projeto do item
ADO.NET Entity Data Model. Este processo de criar primeiramente o banco de dados
Figura 18 - Adicionando a conexão
A figura 19 mostra a estrutura de arquivos atual do projeto, contendo as classes citadas anteriormente.
Figura 19 - Estrutura atual
As classes que foram geradas ainda necessitam de algumas validações e customiza-ções. A Figura 20 e 21 mostram os atributos da classe Chamado gerada automatica-mente e esses mesmos atributos após o uso do Data Annotation respectivaautomatica-mente. O processo de criação de Data Annotation é análogo para as outras classes do modelo. As anotações de atributos utilizadas são as seguintes:
• Key: Usado para definir a chave primária da tabela que uma determinada classe representa. Esta anotação pode ser dispensável quando é criado um atributo nomeado de Id, pois dessa forma o SGBD identifica-o como chave primária automaticamente.
• Required: Define o atributo como obrigatório, ou seja, não será possivel enviar uma requisição sem que exista valor atribuído.
• ErrorMessage: Mensagem de erro exibida quando o usuário violar alguma va-lidação.
• Display: Usado para exibir uma Etiqueta (Label) quando o atributo for utilizado. Caso não seja especificado um Label, o próprio nome do atributo é apresentado na tela do sistema. Conforme a Figura 21, o atributo DataInicio possui esta anotação com o valor ‘Data de Abertura’, assim este é o nome exibido na ge-ração da View.
• StringLength: Define o tamanho máximo de um campo (quando for gerada a
View).
• DisplayFormat: Usado para formatar o conteúdo de um campo. A Figura 21 mostra o uso desta anotação para formatar a data do atributo DataInicio, con-vertendo o formato DateTime (MM/dd/yyyy HH:MM:SS AM) para o fomato ‘dd/MM/yyyy’, ou seja, ‘dia/mês/ano’ de acordo com o formato brasileiro de data.
Figura 21 - Atributos após edição
.
Após a realização dos passos descritos previamente, foi criado o Controle, que é responsável pela comunicação entre o Modelo e a Visão. Na pasta Controllers, foi adicionada a classe HomeController. No Visual Studio, há a opção de criar um novo controle com algumas Actions (Ações) pré-definidas, como um template. Neste pro-jeto, foi usado para o HomeController o template “MVC 5 Controller with read/write
actions”, ou seja, um controle com ações de escrita e leitura. Isso significa que na
criação do controle já existem algumas ações prontas, que correspondem a Index,
Details, Edit (Get e Post), Create (Get e Post), Edit (Get e Post) e Delete (Get e Post).
As Actions get e post se diferenciam pelo fato de que as action get são acionadas quando o usuário requisita acesso a uma determinada view e as actions post são acionadas quando se subtmete um formulário de alguma view. Por exemplo, a action do tipo get permite ao usuário acessar a uma página de edição e com a action do tipo
Antes de começar a desenvolver as actions, é necessário instanciar o banco de dados para que ele possa ser acessado. Isso é implementado através do código mos-trado na Figura 22, especificado pela classe HomeController fora de qualquer action a fim de mantê-lo acessível por todas elas.
Figura 22 - Instância do banco de dados
5.3 INTERFACE GRÁFICA.
A partir deste ponto, as actions do Sistema de Chamados foram desenvolvidas come-çando com um sistema simples de login. A Figura 23 mostra o código das Actions do Login.
Essa parte do sistema verifica no banco de dados se existe algum registro com os dados informados no formulário de login e atribui esses valores a variáveis de sessão. Este folmulário é criado em uma view. Usando o menu de contexto (clicando com o botão direito do mouse) em qualquer lugar dentro da action, haverá a opção
“Add View” como mostrado na figura 24.
Figura 24 – Criando uma view
Ao se escolher essa opção é criada automaticamente (caso não exista) uma pasta com o nome do Controller (neste caso é “Home”) e dentro desta pasta será criada a view Login.cshtml (outro nome pode ser escolhido, porém o mais comum e homogenêo é que as views tenham os mesmos nomes das actions que as acessam), e o código gerado é mostrado na Figura 25.
Figura 25 - View Login
A Figura 25 contém alguns estilos inline devido a está página, especificamente, ser a única que não utiliza uma Master Page (Layout = null). Antes de executar o projeto pela primeira vez, deve-se alterar a rota padrão para que a aplicação se inicie sempre a partir do Login, conforme configurações realizadas no arquivo
Figura 26 - Configuração da rota padrão
Neste momento é necessario a inserção manual de ao menos um usuário no banco de dados para se ter acesso ao sistema. A figura 27 exemplifica o menu de contexto usado para se acessar a opção “New Query” da janela Server Explorer no
Visual Studio. Atraves dela é possivel executar a query mostrada na figura 28, que
cria o primeiro usuário do sistema, um administrador, pois através dele é possivel se adicionar outros usuários, não sendo mas necessário este procedimento.
