TCC EVANDRO CORDEIRO ALVES - Portal - IdUFF€¦ · Nos primórdios da Web, toda a informação era...
103
UNIVERSIDADE FEDERAL FLUMINENSE EVANDRO CORDEIRO ALVES DESENVOLVIMENTO DE UM SISTEMA DE CHAMADOS UTILI- ZANDO ASP.NET MVC Niterói 2016
Transcript of TCC EVANDRO CORDEIRO ALVES - Portal - IdUFF€¦ · Nos primórdios da Web, toda a informação era...
UNIVERSIDADE FEDERAL FLUMINENSE EVANDRO CORDEIRO ALVES
DESENVOLVIMENTO DE UM SISTEMA DE CHAMADOS UTILI-ZANDO ASP.NET MVC
Niterói 2016
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.
Orientador: Douglas Paulo de Mattos
NITERÓI 2016
Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF
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.
CDD 005.71
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
UFF – Universidade Federal Fluminense
Dedico este trabalho a minha esposa.
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”.
Leonardo da Vinci
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.
Palavras-chaves: ASP.NET MVC, Desenvolvimento web e C#.
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.
Keywords: ASP.NET MVC, Web Development e C#.
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 27 – Menu de contexto do Server Explorer .................................................... 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 61 – Teste Funcional 2 – Tela de detalhes do chamado .............................. 92
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
Figura 68 – Teste Funcional 3 – Chamado fechado ................................................. 99
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.1 ARQUITETURA DE SOFTWARE. ............................................................... 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
8 Referências Bibliográficas ................................................................................ 101
15
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.
16
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.
17
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.
18
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
19
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 aplicaçõ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.
20
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.
21
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.
22
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 relacionados. O modelo representa os dados [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.
23
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 sobre 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
24
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.
25
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.
26
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.
27
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 convençõ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 Pa-
ges. Todos os três frameworks são estáveis e maduros, e pode-se criar aplicações
28
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 flexibilidade.
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.
Figura 2 – Classe Usuário com um campo Nome e o construtor padrão.
29
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.
30
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.
Figura 4 – Exemplo de uso de expressão regular.
31
32
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 comunicação na resolução de problemas
de caracter técnico envolvendo equipamentos eletrônicos e seus softwares em uma
33
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á
34
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
35
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.
1. O sistema não deve permitir a inclusão de um arquivo menor que 5 megabytes.
36
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]. "
37
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.
38
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.
DESCRIÇÃO SUCINTA:
39
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.
PRÉ-CONDIÇÕES:
40
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
4. O Técnico altera o status do chamado.
41
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.
42
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.
43
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.
44
Figura 8 – Projeto da tela de Login.
45
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.
46
Figura 11 – Projeto da tela Consultar Chamados.
Figura 12 – Projeto da tela Consultar Todos os Chamados.
47
Figura 13 – Projeto da tela de abertura de chamados.
Figura 14 – Projeto da tela do chamado.
48
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 relevantes 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.
49
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.
50
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 arquivos
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.
51
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 arquivos 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 (utilizado
para registrar rotas) [15].
• Content: Pasta utilizada para armazenar os arquivos CSS que são utiliza-
dos no projeto.
52
• 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.
53
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
e, a partir dele, as classes é denominado Database First.
54
Figura 18 - Adicionando a conexão
A figura 19 mostra a estrutura de arquivos atual do projeto, contendo as classes
citadas anteriormente.
55
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 respectivamente. 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.
56
• 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 20 - Atributos gerados automaticamente
57
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
post, ele pode salvar as alterações realizadas na página.
58
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.
Figura 23 - ActionsResult do Login
59
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.
60
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 RouterCon-
fig.cs mostrado na Figura 26.
61
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.
62
Figura 27 – Menu de contexto do Server Explorer
Figura 28 – Query para a criação de um novo usuário
Logo após essa alteração, pode-se executar a aplicação e a página Login
será exibida, como mostrado na Figura 29.
63
Figura 29 - Tela de Login
5.3.1 Interface do Usuário.
Conforme descrito nos capítulos anteriores, o usuário regular do sistema (aquele que
não é técnico ou administrador) pode realizar as seguites ações: visualizar os próprios
chamados abertos, visualizar uma lista com um histórico de todos os chamados que
o próprio abriu, abrir novos chamados, comentar um chamado e anexar um arquivo.
A action para exibir a lista de chamados abertos, que é a tela inicial do usuário
regular, está ilustrada na Figura 30. Como a tela Index é a tela inicial de todos os tipos
de usuários, foi criada a validação nessa action para selecionar a página conforme o
tipo de usuário.
A tela contendo os chamados abertos está exibida na Figura 31, em que existe
a opção de abrir um novo chamado e a opção de consultar cada um dos chamados
abertos. Na criação dessa view, foi usado o tamplate ‘List’ e a classe de modelo “Cha-
mado”.
64
Figura 30 - ActionResult Index
Figura 31 - Tela inicial do Usuário Regular
As actions para abertura de um novo chamado são mostradas na Figura 32 e a
tela de abertura de novo chamado está exibida na Figura 33. Para implementar esta
tela, foi usado o template “Create” e novamente a classe de modelo “Chamado”. No
caso desta tela, o sistema necessita de algumas informações essenciais além dos
65
dados preenchidos pelo usuário no formulário para a gravação no banco de dados.
Essas informações correspondem ao identificador do usuário, a hora atual e o status
do chamado, que são carregadas em campos ocultos na tela e enviadas juntamente
com os dados preenchidos pelos usuários. Os campos ocultos utilizados na tela de
criação de chamados estão descritos na Figura 34.
Figura 32 - ActionResult Create
66
Figura 33 - Tela de abertura de chamado
Figura 34 - Campos ocultos da tela de criação de chamado
A Figura 35 exibe a tela de consulta de um chamado aberto, que é acessível
pelo link “Abrir” mostrado na Figura 31.
67
Figura 35 - Tela de consulta do chamado como usuário regular
5.3.2 Interface do Técnico.
O técnico tem acesso aos chamados de todos os usuários, realiza a abertura de no-
vos chamados, altera o status e prioridade dos chamados e exclui chamados fecha-
dos, os quais não podem ser alterados pelos técnicos. A página inicial do técnico está
mostrada na Figura 36, listando os chamados presentes no sistema. Para sua criação,
foi usada a mesma Action mostrada na Figura 30.
68
Figura 36 - Tela inicial do técnico
A tela de consulta de chamado do técnico é análoga à tela ilustrada na
Figura 35, porém ela permite que os campos status do chamado e prioridade possam
ser alterados pelo técnico, como mostrado na Figura 37. Para implementação dessa
tela, foi usado o template “Edit” e o código de sua Action é descrito na Figura 38.
69
Figura 37 – Tela de consulta de chamado como técnico
70
Figura 38 – ActionResult Edit
O técnico deve responder aos usuários que abriram o chamado
adicionando mensagens ao chamado através do botão “Adicionar comentário”. A tela
para inserir comentários está ilustrada na Figura 39 e o código implementado para
sua construção está descrito na Figura 40. Após a inserção do comentário, a tela de
consulta do chamado passa a exibí-lo conforme Figura 41.
71
Figura 39 - Adicionar comentário
Figura 40 - ActionResult Adicionar Mensagem
72
Figura 41 - Tela de consulta de chamado contendo um coméntario
Para implementar a adição das mensagens à tela de consulta de chamado
foi utilizada uma partial view, componente do ASP.NET que permite renderizar uma
view dentro de outra, mostrada na Figura 42 e adicionando-a a view “Edit”, que cor-
responde a tela de consulta de chamado, conforme mostrado na Figura 43.
73
Figura 42 - Partial View _Comentários
Figura 43 - Código para inserção da partial view
5.3.3 Interface do Administrador do Sistema.
Os administradores do sistema podem adicionar novos usuários, técnicos ou mesmo
outros adminstradores, alterar seus logins e senhas, além de realizar as mesmas
ações dos técnicos. É o único tipo de usuário que pode reabrir um chamado fechado.
A tela inicial do administrador, ilustrada na Figura 44, é análoga à tela mostrada na
Figura 36, porém com uma opção a mais: “Gerenciar usuários”.
74
Figura 44 - Tela inicial do administrador
Para a gerência dos usuários, foi criado um outro Controle chamado “GerenciaDeU-
suarios” contendo algumas das action usadas no controle Home. Entretanto, o con-
trole “GerenciaDeUsuarios” apresenta diferenças de implementação, por exemplo a
action Index do controle “GerenciaDeUsuarios” retorna uma lista de usuários do sis-
tema e o controle “Home” retorna uma lista de chamados. As outras actions do con-
trole “GerenciaDeUsuarios” funcionam de forma semelhante, usando sempre a classe
Usuário e não a classe Chamado. A tela de gerenciar usuários pode ser acessada
através da action mostrada na Figura 45, que compõe o controle “GerenciaDeUsua-
rios”, e a view criada a partir dela está mostrada na Figura 46.
Figura 45 – ActionResult Index do controle GerenciaDeUsuarios
75
Figura 46 – Tela Gerenciar Usuários
Na tela de gerenciamento de usuário, é possível criar, apagar e editar usuários. Para
a criação de um novo usuário foi usado a action “Create”, mostrado na Figura 47, e a
view, em que foi utilizado o template “Create”, mostrada na Figura 48.
76
Figura 47 – ActionResult Create do controller “GerenciaDeUsuarios”
77
Figura 48 – Tela Criar novo usuário
Para a tela de edição de usuário, foi usado o template “Edit” e a action mostrada na
Figura 49. A interface dessa tela é ilustrada na Figura 50.
78
Figura 49 – ActionResult Edit do controle “GerenciaDeUsuarios”
79
Figura 50 – Tela Editar usuário
A action e a interface da tela para deletar um usuário estão mostradas nas figuras 51
e 52 respectivamente.
80
Figura 51 – ActionResult Delete do controle “GerenciaDeUsuarios”
81
Figura 52 – Tela para deletar usuário
5.4 SEGURANÇA DO SISTEMA.
Para evitar acessos não autorizados ao sistema proposto, foi implementado uma tela
de login, em que os usuários devem fornecer suas credenciais, isto é, nome de usuário
e senha. A partir dessas informações, o sistema consulta a base de dados a fim de
validar o acesso. Caso as credenciais sejam inválidas, o acesso é negado.
Existem muitas maneiras de um uma pessoa mal intencionada realizar upload de ar-
quivos ou outros tipos de conteúdo maliciosos para a aplicação. Tais ataques não só
podem danificar os dados, como também podem tornar a aplicação indisponível.
82
Há um tipo de ataque chamado de Cross-site scripting (XSS), em que se injeta código
JavaScript no lado cliente em um campo texto de uma página para que esse trecho
de código seja executado quando a página for requisitada. Isso permite obter dados
de formulário e informações de segurança potencialmente sensíveis.
Uma maneira comum para evitar o carregamento de entrada maliciosa para um site é
limitar o comprimento e tipo de entrada que os usuários estão autorizados a fornecer.
Para isso, pode-se remover a capacidade de enviar as etiquetas (tags), filtrando os
caractéres "<" (menor que) e ">" (maior que).
Como regra geral, a entrada aceitável para o site deve ser tão limitada quanto possí-
vel, ou seja, a entrada deve possuir o tamanho, conteúdo e tipo de dados esperados
para um determinado campo [16].
Para este estudo, foram usados os DataAnnotations das classes do sistema. Assim,
a Figuras 53 apresenta a implementação da validação dos campos da classe “Usuá-
rio” e a Figura 54 para a classe “Mensagem”. Além disso, as validações para as clas-
ses “Chamado” e “Anexo” são apresentadas nas Figuras 55 e 56 respectivamente.
Figura 53 – Validações da classe Usuário
83
Figura 54 – Validações da classe Mensagem
Figura 55 – Validações da classe Chamado
84
Figura 56 – Validações da classe Anexo
Outra maneira comum e relativamente simples de explorar uma aplicação
Web é através de escutas usando um utilitário de captura de dados de rede para lo-
calizar registros e respostas de solicitações HTTP. Sem a proteção contra espiona-
gem e violação, um atacante pode alterar o conteúdo de uma solicitação HTTP cap-
turado e reenviar para o servidor. Este tipo de ataque é comumente referido como um
“ataque de repetição de mensagem” (do inglês message replay attack). Mesmo que o
site exija autenticação, ele processa o pedido como se viesse a partir do cliente, pois
contém um token de segurança legítimo. Requisições HTTP podem ser alteradas para
fazer com que o site se comporte de forma indesejada, apagando ou modificando
dados, ou fazendo com que um grande número de operações seja executado. Uma
maneira comum de diminuir as chances de um ataque deste tipo é exigir comunicação
via Secure Sockets Layer (SSL). Quando se usa SSL em um Navegador em modo
não-anônimo, impede-se de capturar qualquer conteúdo sensível no tráfego HTTP,
evitando a adulteração da mensagem [16]. Entretanto, o SSL não foi implementado
neste trabalho.
Cross-site request forgery (CSRF) ocorre quando comandos maliciosos são
enviados para um site a partir do navegador de um usuário confiável. Um atacante
constrói um elemento HTML aparentemente inofensivo em um site diferente, que faz
uma requisição ao site de destino e tenta fazer algo malicioso se passando por um
usuário confiável. CSRF tem grande potencial para danificar o site que está sendo
explorado. Um atacante pode potencialmente alterar ou excluir dados, ou executar um
grande número de transações indesejadas no site alvo [16].
85
No software proposto deste trabalho, não foi implementado a proteção contra
CSRF.
5.5 LIMITAÇÕES.
O sistema proposto neste estudo possui algumas limitações que serão discutidas
a seguir. Conforme foi citado no capítulo anterior, determinadas medidas de segu-
rança não foram utilizadas no Sistema de Chamados devido a limitações técnicas.
O sistema de login funciona utilizando variáveis de sessão, o que obriga a realizão de
validações em quase todas as actions dos controles da aplicação, pois caso tenha
ocorrido um timeout (evento que indica que um limite de tempo predeterminado esgo-
tou-se sem que algum outro evento esperado ocorresse), não deve ser permitida a
execução de ação alguma e deve-se fazer o redirecionamento para a página de login.
Isto também evita o acesso indevido pelos usuários a endereços não permitidos. Visto
que este trabalho tem como objetivo mostrar o uso do framework ASP.NET MVC atra-
vés da implementação do sistema proposto, este possui funcionalidade limitadas,
apresentando uma modelagem de dados simples e não adequada para representar o
contexto real em que o sistema está inserido. Além disso, não existe um workflow
(sequência de passos necessários para automatizar processos) no Sistema de Cha-
mados, dificultando a verificação do andamento da resolução de um problema. Ou
seja, o sistema não oferece meios suficientes para gerenciar de forma adequada os
chamados abertos.
86
6 RESULTADOS E TESTE DO SOFTWARE.
Neste capítulo serão realizados testes funcionais no software desenvolvido,
usando como base os casos de uso discutidos no Capítulo 4. A fim de facilitar a com-
preensão dos testes realizados, todas as ações feitas durante os testes serão mostra-
das através de figuras que ilustram as telas do sistema.
6.1 TESTE FUNCIONAL 01
No primeiro teste funcional, será realizado o caso de uso “Abrir Chamado”. A Figura
57 mostra a realização do login, em que o usuário utilizado foi cadastrado previamente
por um administrador do sistema.
Figura 57 – Teste Funcional 1 - Login
Em seguida, será mostrado a tela principal do usuário, como mostrado na
Figura 58, e a partir dela pode-se acessar a opção “Abrir novo chamado”.
87
Figura 58 – Teste Funcional 1 – Tela inicial
A Figura 61 mostra a tela de abertura de um novo chamado já com os dados
preenchidos. O próximo passo é clicar no botão “Criar novo chamado”.
88
Figura 59 – Teste Funcional 1 – Abrir chamado
O sistema redireciona automaticamente para a tela principal, que apresenta
o registro do chamado criado, como mostrado na Figura 60, finalizando o teste do
caso de uso “Abrir Chamado”.
89
Figura 60 – Teste Funcional 1 – Lista de chamados abertos
6.1.1 Resultado 01.
O primeiro teste funcional foi executado com sucesso, não apresentando nenhuma
falha durante a criação de um novo chamado, conforme os passos do caso de uso
seguidos e mostrados nas Figuras 57 a 60. Assim, o processo de abertura de cha-
mado está funcionando conforme o esperado e descrito no caso de uso mencionado
no inicio desta seção. O tempo despendido neste teste foi cerca de dois minutos de-
monstrando que o processo de criação de um novo chamado é rápido e simples.
6.2 TESTE FUNCIONAL 02
No segundo teste funcional, será realizado o caso de uso “Modificar Chamado”, que
tem início na tela principal do usuário, como mostrado na Figura 60. Em seguida, a
opção “Abrir” é selecionada no registro do chamado a ser editado e, então, o sistema
mostra a tela do chamado conforme a Figura 61.
90
Figura 61 – Teste Funcional 2 – Tela de detalhes do chamado
A partir de então, a opção “Adicionar comentário”deve ser selecionada para
que o sistema possa seguir para a tela mostrada na Figura 62.
91
Figura 62 – Teste Funcional 2 – Adicionar comentário
Após adicionar o comentário, a opção “Criar” deve ser selecionada para
que o sistema apresente novamente a tela de chamado com o novo comentário inse-
rido, conforme a Figura 63.
92
Figura 63 – Teste Funcional 2 – Tela do chamado com um comentário
Como fluxo alternativo deste caso de uso, pode-se adicionar um anexo ao
chamado. Para isso, deve-se utilizar o botão “Adicionar anexo” como mostrado na
Figura 63. A tela para inclusão de anexo está mostrada na Figura 64.
93
Figura 64 – Teste Funcional 2 – Acidionar Anexo
Quando se clica em “Browse” (ou em qualquer lugar dentro do único input
disponível) abre-se um pop-up para a seleção de um arquivo a ser anexado. Para este
teste, foi usado a imagem de um mouse, chamada “mouse.jpg”.
Após essa seleção, a opção “Adicionar” deve ser selecionada para que o
sistema mais uma vez redirecione para a tela do chamado, apresentando o arquivo
de imagem anexado, conforme a Figura 65, finalizando o teste do caso de uso “Modi-
ficar Chamado”.
94
Figura 65 – Teste Funcional 2 – Tela de chamado com um anexo
6.2.1 Resultado 02
Conforme foi mostrado no teste 2, o caso de uso “Modificar Chamado” foi realizado
com sucesso. Foram realizados todos os passos do caso de uso, incluindo o fluxo
alternativo referente à adição de um anexo. O pop-up de seleção de arquivo não foi
mostrado aqui, porém não apresentou qualquer falha durante o teste. O sistema de
chamados funcionou conforme o esperado neste teste, não apresentando nenhum
erro.
95
6.3 TESTE FUNCIONAL 03
Neste terceiro teste funcional, será realizado o caso de uso “Alterar status do cha-
mado”, que possui início na tela principal do técnico, após realizar o login conforme já
foi mostrado no primeiro teste. A tela principal do técnico é análoga à tela principal do
usuário regular, com a diferença de que a tela do técnico exibe os chamados de todos
os usuários e para o usuário regular, somente são exibidos seus próprios chamados.
A tela principal do técnico está mostrada na Figura 66.
Figura 66 – Teste Funcional 3 – Tela principal do técnico
Após selecionar a opção “Abir” para ter acesso à tela do chamado, o técnico
pode alterar opções que o usuário regular não poderia, conforme mostrado na Figura
67.
96
Figura 67 – Teste Funcional 3 – Tela do chamado acessada por um técnico
Partindo do pressuposto que o problema descrito no chamado já tenha sido
sanado, o técnico deve clicar no campo “StatusChamado”, que na Figura 67 possui o
valor “Aberto”, e alterá-lo para “Fechado”. Logo após isso, deve-se clicar em “Salvar
alterações” (opção esta que também não está disponível para o usuário regular). O
97
sistema irá redirecionar para a tela principal com a atualização realizada, conforme
mostrado na Figura 68, finalizando o teste do caso de uso Alterar status do chamado.
Figura 68 – Teste Funcional 3 – Chamado fechado
6.3.1 Resultado 03.
Este teste demonstrou o processo de fechamento de uma chamado passando por
todos passos necessários para isso. Nenhuma das telas apresentou erro durante a
execução do teste, nem ocorreram travamentos devido a consultas no banco de da-
dos. Entretanto, este teste não garante que o sistema venha ter um comportamento
adequado para um número grande acessos simultâneos.
98
7 CONCLUSÃO E TRABALHOS FUTUROS
Neste capítulo, serão apresentados os resultados da implementação de acordo
os testes realizados. Também serão discutidos o uso do framework ASP.NET MVC
no desenvolvimento do Sistema de Chamados e trabalhos futuros.
7.1 RESULTADOS DA IMPLEMENTAÇÃO.
Conforme os testes realizados no capítulo anterior, pode-se verificar que o sistema de
chamados implementado neste trabalho cumpre todos os requisitos propostos. Além
disso, essa implementação exemplifica o uso do ASP.NET MVC alcançando o objetivo
deste trabalho.
Com a utilização do software há uma padronização e registro de ocorrências
relacionadas a problemas. Sua resolução fica registrada e pode ser consultada para
solucionar problemas parecidos.
O framework utilizado proporcionou agilidade e organização durante o desenvol-
vimento. O modelo utilizado neste trabalho foi o Database First, primieramente foi de-
senvolvido o bando de dados e, apartir dele e utilizando o Entity Framework, foram
geradas as classes do Sistema de Chamados (a camada de Modelo). Esse modelo
de desenvolvimento tem a vantagem de não ser necessário o desenvolvimento do
modelo pois ele é gerado (ou atualizado) automaticamente apartir do Banco de Dados.
O MVC proporcinou o desaclopamento da interface de usuário com o modelo da
aplicação, assim as camadas podem ser desenvolvidas independentemente. Caso
houvessem mais desenvolvedores trabalhando, não ocorreriam erros devido a altera-
ção simultanea de um trecho de código qualquer pois eles trabalhariam em camadas
diferentes.
O sofware desenvolvido contém falhas, assim como qualquer outro software, e
sua utilidade depende da necessidade da empresa/instituição/grupo.
99
7.2 DISCUSSÃO SOBRE O USO DO ASP.NET MVC.
Este trabalho utilizou o framework ASP.NET MVC para implementar o Sistema de
Chamados a fim de mostrar como um software é desenvolvido baseando-se na arqui-
tetura model-view-controller. Este framework proporcina, através da IDE Microsoft Vi-
sual Studio, uma maneira ágil de se realizar o desenvolvimento de um software. A
estrutura de apresentação do ASP.NET MVC é leve, altamente testável e integrada
aos recursos ASP.NET [17], facilitando o processo de desenvolvimento. Conforme
demonstrado ao decorrer deste estudo, existem muitas opções de configurações au-
tomáticas. Uma delas é a opção de utilizar um gerenciador de autenticação denomi-
nado ASP.NET Identity. Entretanto, este recuros não foi utilizado neste trabalho para
não agregar complexidade na modelagem do banco de dados.
O MVC é um design pattern (padrão de arquitetura de software) que existe desde
1979 e é muito conhecido entre os desenvolvedores de sofware. Muitas aplicações
web hoje se beneficiam desde padrão. Algumas aplicações utilizam mais de um de-
sign pattern, por exemplo o MVC e o Web Forms [17].
Os Data Annotation foram usados na validação dos campos/formulários no lado
do cliente (client-side) e as mesmas validações foram feitas no Controller (server-
side), essa dupla validação protege a aplicação de muitos ataques como alqueles ci-
tados no tópico 5.4.
A estrutura ASP.NET MVC é “Uma estrutura extensível e conectável. Os componentes
da estrutura ASP.NET MVC são desenvolvidos para serem facilmente substituídos ou
personalizados.” [17].
7.3 TRABALHOS FUTUROS.
Com a implementação do Sistema de Chamados utilizando o framework ASP.NET
MVC, o trabalho apresentou como a arquitetura MVC pode facilitar o desenvolviemnto
de um sistema. Além disso, o desenvolvimento do sistema possibilitou a prática de
conceitos importantes nas estapas do desenvolvimento do software. Para especifica-
ção dos requisitos do sistema, foram utilizados recursos da Linguagem de Modelagem
100
Unificada (UML) como os diagramas de casos de uso e de atividades. Na modelagem
de dados, os diagramas de classes foram utilizados para definir as entidades do mo-
delo. Ademais, ferramentas como a IDE Microsoft Visual Studio Community e SQL
Server Express foram usadas durante o desenvolvimento.
A fim de tornar o Sistema de Chamados mais adequado para os usuários e
acrescentar esse estudo com outras técnicas de desenvolvimento de software, os se-
guintes as atividades podem ser realizadas:
• Implementar mecanismos de segurança apontados no Seção 5.5.
• Permitir a remoção de mensagens pelos usuários com perfil de admini
trador.
• Criar um workflow para que todas as partes envolvidas possam estar sem-
pre cientes das novas alterações no chamado.
• Realizar um estudo sobre outras formas de desenvolvimento de softwares
como o Code First, visto que neste estudo foi utilizado a abordagem Da-
tabase First.
101
8 REFERÊNCIAS BIBLIOGRÁFICAS
1. GAMMA, Erich et al. Padrões de projeto: soluções reutilizáveis de software orientado a objetos, 2002.
2. FREEMAN, Eric e FREEMAN, Elizabeth. Padrões de Projetos: Seu cérebro em padrões de projetos, 2007.
3. MEDEIROS, Higor. Introdução ao Padrão MVC. <http://www.devme-
dia.com.br/introducao-ao-padrao-mvc/29308> Acesso em 28 jul. 2016.
4. POPOVIC, Jovan. ASP.NET MVC3 Razor With jQuery For Beginners. <http://www.codeproject.com/Articles/344292/ASP-NET-MVC-Razor-With-
jQuery-For-Beginners> Acesso em 28 jul. 2016.
5. FREEMAN, ER, FREEMAN, EL., SIERRA, K., BATES, B. Head First Design
Patterns. O’Reilly Media, 2004.
6. BUSCHMANN, F., MEUNIER, R. ROHNERT, H., SOMMERLAD, P. STAL, M.
Pattern-Oriented Software Architecture, 1996.
7. KRASNER, Glenn E. e POPE, Stephen T. A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System. <http://www.math.sfedu.ru/smalltalk/gui/mvc_krasner_and_pope.pdf> Acesso
em 17 abr. 2016.
8. GITHUB score. Find your new favorite web framework. <http://hotfra-
meworks.com/> Acesso em 17 abr. 2016.
9. Google. Angular JS. <https://docs.angularjs.org/misc/faq> Acesso em 17 abr.
2016.
10. JUNIOR, Luiz Antonio da Silva. O movimento do código aberto. <https://www.vivaolinux.com.br/artigo/O-movimento-do-codigo-aberto> Acesso
em 17 abr. 2016.
11. RUBY. Welcome to Rails. <http://api.rubyonrails.org/> Acesso em 17 abr.
2016.
12. MICROSOFT. Get Started with ASP.NET. <http://www.asp.net/get-started>
Acesso em 28 jul. 2016.
102
13. BOOCH, G., RUMBAUGH, J. and JACOBSON, I. Unified Modeling Lan-guage User Guide, 2nd Edition, Addison-Wesley Object Technology Series, 2005.
14. HADDAD, Renato. ASP.NET - Uso de Bundle e Minification no ASP.NET MVC 4 e ASP.NET Web Forms 4.5. <https://msdn.microsoft.com/pt-br/li-
brary/dn168847.aspx> Acesso em 06 set. 2016.
15. HADDAD, Renato. Configurar Rotas no ASP.NET. <https://msdn.micro-
soft.com/pt-br/library/dn423988.aspx> Acesso em 06 set. 2016.
16. MICROSOFT. Project Silk: Client-Side Web Development for Modern Browsers - Chapter 12: Security. <https://msdn.microsoft.com/en-us/li-
brary/hh404095.aspx?f=255&MSPPError=-2147217396> Acesso em 13 set.
2016.
17. MICROSOFT. ASP.NET MVC Overview. <https://msdn.microsoft.com/pt-br/li-
brary/dd381412%28v=vs.108%29.aspx> Acesso em 13 set. 2016.
18. MICROSOFT. Web application development is different. <
https://www.oreilly.com/ideas/web-application-development-is-different-and-
better> Acesso em 20 dez. 2016.
