Embed Size (px)
Citation preview
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA
SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTÔNIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
DAIANE DO NASCIMENTO SIMIÃO
JOSÉ ROBERTO MONICI BARRIONUEVO JUNIOR
PROJETO AMCORA – FERRAMENTA CASE MÓDULO DE GERÊNCIA DE MUDANÇAS
LINS/SP
1°SEMESTRE/2015
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA
SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTÔNIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
DAIANE DO NASCIMENTO SIMIÃO
JOSÉ ROBERTO MONICI BARRIONUEVO JUNIOR
PROJETO AMCORA – FERRAMENTA CASE MÓDULO DE GERÊNCIA DE MUDANÇAS
Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Título de Tecnólogo em Banco de Dados.
Orientador: Prof. Me. Fábio Lúcio Meira.
LINS/SP
1°SEMESTRE/2015
DAIANE DO NASCIMENTO SIMIÃO
JOSÉ ROBERTO MONICI BARRIONUEVO JUNIOR
PROJETO AMCORA – FERRAMENTA CASE MÓDULO DE GERÊNCIA DE MUDANÇAS
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins “Prof. Antonio
Seabra”, como parte dos requisitos necessários
para obtenção do Título de Tecnólogo em Banco de
Dados sob orientação do Prof. Me. Fábio Lúcio
Meira.
Data de Aprovação: 24 de Junho de 2015
______________________________________
Orientador Prof. Me. Fábio Lúcio Meira
______________________________________
Prof. Me. Adriano Bezerra
______________________________________
Prof. Me. Rodrigo Moura Juvenil Ayres
À Jandira (in memoriam), a melhor avó.
Daiane
AGRADECIMENTOS
Neste momento tão importante, gostaria de agradecer ao meu orientador Fábio
Lúcio Meira, por nos confiar este projeto e aos professores Adriano Bezerra e Rodrigo
Ayres por toda a ajuda e por nos fazer acreditar que seria possível.
Aos companheiros de projeto Felipe, Michael, Murilo e Jairo por toda a ajuda,
todos os sábados e domingos na faculdade, escrevendo e programando. E em
especial ao Junior por me escolher e deixar ser escolhido durante todo o curso e na
elaboração desse trabalho.
Ao Bruno Alves por toda a ajuda e suporte durante todo o curso, Nathan e
Carolina pela amizade e por me distrair nos momentos de tensão. Eu amo vocês.
Ao Bruno Henrique por sanar minhas dúvidas em horários e momentos
totalmente malucos e improváveis e por toda ajuda durante todo o período do curso.
À minha tia Júlia por todas impressões do trabalho e ajuda com vocabulários.
Por fim, à minha mãe, por todo o suporte, confiança e aguentar o meu mal humor
durante a quase todo o período de faculdade (e na vida) e ainda mais durante a
elaboração deste trabalho.
Daiane
Aos meus pais José Roberto e Janete, minha
irmã, Anaisa e minha noiva, Renata Mendes.
José Roberto
AGRADECIMENTOS
Primeiramente a Deus, por ter me dado saúde e força para superar meus
obstáculos e conseguir chegar onde estou.
Dediquei esse trabalho aos meus pais e aproveito para agradecê-los pelo
carinho e educação, pois sem eles, este e muitos dos meus sonhos não se realizariam.
À minha irmã, por todo o apoio durante a vida e por ser minha confidente. À minha
noiva, por estar ao meu lado nos momentos bons e ruins, por suportar enquanto fazia
este projeto e por me motivar nos momentos em que eu queria desistir. À minha sogra,
por sempre me ouvir e pelos conselhos dados.
Aos meus companheiros de projeto, Felipe Testoni, Jairo Martins, Michael
Paiva e Murilo Ralsen, que sempre estiveram unidos, independe dos problemas e que
por acreditarem que tudo seria possível, por toda a ajuda dada durante todo o curso
e não só no projeto. Por todas as semanas de provas com a nossa frase “Quem vai
chegar mais cedo para estudar? ”. Em especial, ao Michael e o Felipe, parceiros de
programação e de almoço no “Refúgio”.
Meus agradecimentos a minha amiga e parceira nesse trabalho, Daiane Simião
e à Nathan Delgado e Carolina Bicudo, amigos de faculdade e irmãos na amizade que
fizeram parte da minha formação e que vão continuar presentes em minha vida.
Ao meu orientador Professor Me. Fábio Lúcio Meira e aos professores Adriano
Bezerra e Rodrigo Ayres pelo apoio na elaboração desde trabalho.
À Faculdade de Tecnologia de Lins pela oportunidade de fazer o curso.
Junior
RESUMO
Quando um projeto ou software exige uma grande equipe de desenvolvimento, o
Gerente do Projeto encontra certa preocupação em fazer com que todos os
desenvolvedores entendam suas responsabilidades e cumpram com seus
compromissos. Esse é o intuito do Ambiente de Controle de Artefatos, o AmCorA.
Esse sistema visa auxiliar o gerente de projeto a ministrar e coordenar seu projeto. E
neste trabalho será apresentado o Módulo de Gerência do Sistema AmCora.
Apresentando os passos de um artefato e as mudanças relacionadas a ele. A visão
final é auxiliar o gerente do projeto a visualizar todas as mudanças relacionadas aos
artefatos, quem solicitou, quem aprovou e as mudanças feitas vinculadas as outras
partes do AmCorA. O Sistema AmCorA está sendo desenvolvido em plataforma para
Internet. A linguagem de programação utilizada para desenvolvimento será Java e o
Sistema Gerenciador de Banco de Dados é o MySQL.
Palavras-chave: AmCorA. Gerência de Mudança. Java. MySQL. Desenvolvimento de
Software. Engenharia de Software.
ABSTRACT
When a project or software requires a large team of development, the Project Manager
is some concern in making all developers understand their responsibilities and fulfill
their commitments. This is the purpose of Artifact Control Environment, the AmCorA.
This system aims to help the project manager to administer and coordinate your
project. And this work will be presented the Management Module AmCora system.
Featuring the steps of an artifact and changes related to it. The ultimate vision is to
assist the project manager to all the changes related to the artifacts, who requested,
who approved and the changes made linked to other parts of the AmCorA. The
AmCorA System is being developed for Internet platform. The programming language
used for development is Java and Database Management System is MySQL.
Keywords: AmCorA. Change Management. Java. MySQL. Software Development.
Software Engineering.
LISTA DE ILUSTRAÇÕES
Figura 1.1 Arquitetura MVC em Padrões WEB .......................................................... 9
Figura 1.2 Diagramas de UML ................................................................................. 10
Figura 1.3 Etapas Para Compilação e Execução de Um Programa Java ................. 12
Figura 2.1 Gráfico de Disciplinas, Fases e Iterações do RUP ................................... 17
Figura 2.2 Funções do Controle de Mudança .......................................................... 18
Figura 2.3 Funções do Gerenciador do Controle de Mudanças ............................... 21
Figura 2.4 Atividade de Exemplo Para o Gerenciamento e Controle de Solicitação de
Mudança.................................................................................................................... 22
Figura 2.5 Estados e Transições de Exemplo de Uma Solicitação de Mudança ...... 23
Figura 3.1 Diagrama de Caso de Uso – Gerência de Mudança ............................... 26
Figura 3.2 Diagrama de Classe AmCorA ................................................................. 27
Figura 3.3 Diagrama de Atividades – Manter Projeto ............................................... 28
Figura 3.4 Diagrama MVC – Manter Projeto ............................................................ 29
Figura 3.5 Diagrama de Sequência – Adicionar Projeto ........................................... 30
Figura 3.6 Diagrama de Sequência – Atualizar Projeto ............................................ 30
Figura 3.7 Diagrama de Atividades – Manter Vínculo .............................................. 31
Figura 3.8 Diagrama de Sequência – Adicionar Vínculo .......................................... 31
Figura 3.9 Diagrama de Sequência – Atualizar Vínculo ........................................... 32
Figura 3.10 Diagrama de Sequência – Excluir Vínculo ............................................ 32
Figura 3.11 Diagrama de Atividades – Manter Papeis ............................................. 33
Figura 3.12 Diagrama MVC – Manter Papeis ........................................................... 34
Figura 3.13 Diagrama de Sequência – Adicionar Papel ........................................... 35
Figura 3.14 Diagrama de Sequência – Atualizar Papel ............................................. 35
Figura 3.15 Diagrama de Sequência – Excluir Papel ................................................ 36
Figura 3.16 Diagrama de Atividades – Manter Membro ........................................... 37
Figura 3.17 Diagrama MVC – Manter Membro ......................................................... 38
Figura 3.18 Diagrama de Sequência – Adicionar Membro ....................................... 39
Figura 3.19 Diagrama de Sequência – Atualizar Membro ........................................ 39
Figura 3.20 Diagrama de Atividades – Manter Mudança ......................................... 40
Figura 3.21 Diagrama MVC – Manter Mudança ....................................................... 41
Figura 3.22 Diagrama de Sequência – Adicionar Mudança ..................................... 42
Figura 3.23 Diagrama de Sequência – Atualizar Mudança ...................................... 42
Figura 3.24 Diagrama de Sequência – Excluir Mudança ......................................... 43
Figura 3.25 Diagrama de Atividades – Gerar Histórico de Mudança ........................ 44
Figura 3.26 Diagrama de Sequência – Gerar Histórico de Mudança ....................... 45
Figura 3.27 Modelo de Entidade e Relacionamento do Banco de Dados ................. 46
Figura 4.1 Tela Inicial do Sistema AmCora .............................................................. 47
Figura 4.2 Formulário de Cadastro de Membro ........................................................ 48
Figura 4.3 Tela de Alteração Obrigatória de Senha ................................................ 48
Figura 4.4 Tela de Solicitação de Mudança .............................................................. 49
Figura 4.5 Tela com Formulário de Solicitação de Mudança ................................... 50
Figura 4.6 Tela de Visualização de Solicitação de Mudança .................................... 50
Figura 4.7 Tela de Aprovação ou Reprovação de Mudança .................................... 51
Figura 4.8 Tela do Botão de Histórico de Mudança .................................................. 52
Figura 4.9 Tela com Status de Mudança Aprovado ................................................. 52
Figura 4.10 Tela com Status de Mudança Reprovado .............................................. 53
Figura 4.11 Tela com Status de Mudança Finalizado ............................................... 53
LISTA DE TABELAS
Tabela 2.1 – Descrição dos Estados e Transições de um Exemplo de uma Solicitação
de Mudança ............................................................................................................. 23
LISTA DE ABREVIATURAS E SIGLAS
AmCorA – Ambiente de Controle de Artefatos
API – Aplication Programming Interface
C – Linguagem de Programação C
CM – Controle de Mudanças
CRM – Change Request Management
CSS – Cascading Style Sheet
DOM – Document Object Model
IBM – International Business Machina
IDE – Integrated Development Enrionment
GM-AmCorA – Gerenciamento de Mudança do AmCorA
GNU-GPL – General Public License
HTML – Hypertext Markup Language
J2SE – Java 2 Plataform Standart Edition
JDBC – Java Database Connectivity
JDK – Java Developement Kit
JEE – Java Enterprise Edition
JRE – Java Rumtime Enviroment
JPA – Java Persistente API
JS – JavaScript
JSP – Java Server Pages
MVC – Model View Control
ORM - Object Relational Mapping
POJOs – Pain Old Java Objects
UML – Unified Modeling Language
URL – Uniform Resource Locator
RUP – Rational Unified Process
SDK – Software Developement Kit
W3C – World Wide Web Consortium
XHTML – Extend Hypertext Markup Language
WHATWG – Web Hypertext Application Technology Working Group
XML – Extensible Markup Language
SUMÁRIO
INTRODUÇÃO ............................................................................................................ 6
1 FERRAMENTAS E TECNOLOGIAS ........................................................................ 8
1.1 IDE NETBEANS ............................................................................................. 8
1.2 FERRAMENTA MVC ...................................................................................... 8
1.3 MODELAGEM UML ..................................................................................... 10
1.4 BANCO DE DADOS MYSQL ....................................................................... 11
1.5 LINGUAGEM JAVA ...................................................................................... 12
1.5.1 Java Persistence API ................................ Erro! Indicador não definido.
1.6 HIBERNATE ................................................................................................. 13
1.7 HTML 5 ........................................................................................................ 14
1.8 JAVASCRIPT ............................................................................................... 14
1.8.1 JQuery ................................................................................................... 15
1.9 LINGUAGEM CSS3 ..................................................................................... 15
1.10 LESS ......................................................................................................... 16
1.11 TOMCAT ................................................................................................... 16
2 FUNDAMENTAÇÃO TEÓRICA ........................................................................ 17
2.1 CONTROLE DE MUDANÇAS ...................................................................... 17
2.2 GERENCIAMENTO DE CONTROLE DE MUDANÇAS ............................... 19
2.2.1 Atividades e Artefatos ............................................................................ 20
2.2.2 Iterações e Libertações ......................................................................... 20
2.2.3 Alteração no Software ........................................................................... 20
2.3 GERENCIAMENTO UNIFICADO DE MUDANÇAS...................................... 21
2.4 GERENCIAMENTO DE SOLICITAÇÃO DE MUDANÇA .............................. 21
3 SISTEMA DE GERÊNCIA DE MUDANÇAS DO AMCORA .............................. 26
3.1 DIAGRAMA DE CASO DE USO .................................................................. 26
3.2 DIAGRAMA DE CLASSE ............................................................................. 27
3.3 ESPECIFICAÇÕES DE HISTÓRIAS E DIAGRAMAS .................................. 28
3.3.1 Manter Projeto ....................................................................................... 28
3.3.2 Manter Vínculo....................................................................................... 30
3.3.3 Manter Papeis........................................................................................ 33
3.3.4 Manter Membro ..................................................................................... 36
3.3.5 Manter Mudança .................................................................................... 40
3.3.6 Gerar Histórico de Mudança .................................................................. 44
3.3.7 Banco de Dados .................................................................................... 45
4 IMPLEMENTAÇÃO DO SISTEMA .................................................................... 47
4.1 CADASTRO DE MEMBRO .......................................................................... 47
4.2 SOLICITAÇÃO DE MUDANÇA .................................................................... 49
4.3 VISUALIZAR SOLICICITAÇÃO .................................................................... 50
4.4 APROVAÇÃO OU REPROVAÇÃO DE MUDANÇA ..................................... 51
4.5 SITUAÇÃO DE MUDANÇA SOLICITADA .................................................... 51
CONCLUSÃO ............................................................................................................ 54
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 55
6
INTRODUÇÃO
O desenvolvimento de software está em ascensão na sociedade devido a uma
demanda gerada a partir da utilização de computadores nas mais diversas áreas do
conhecimento humano. Segundo Falbo (2005), existe a confusão entre desenvolver
softwares e programação e que isso está atribuído pela “forma em que as pessoas
são introduzidas nesta área de conhecimento, começando a desenvolver habilidades
de raciocínio lógico através da programação e estrutura de dados”. Não que isso seja
ruim, mas chega um ponto que certa programação individual não é a mais indicada,
como na geração de softwares para bancos ou outros serviços mais complexos do
que calcular a média ou converter temperaturas.
Neste processo, surgiu a Engenharia de Software que, ainda nas palavras de
Falbo “trata de aspectos relacionados ao estabelecimento de processos, métodos,
técnicas, ferramentas e ambientes de suporte ao desenvolvimento de software”. Os
problemas a serem tratados são analisados e dividido em menores partes e seus
subproblemas são resolvidos isoladamente. Assim, estabelece-se uma arquitetura
para apoio as resoluções dos problemas e utiliza-se de ferramentas para automatizar
o trabalho.
Neste cenário, muitas vezes não é possível conduzir o
desenvolvimento de software de maneira individual. Pessoas têm de trabalhar
em equipes, o esforço tem de ser planejado, coordenado e acompanhado,
bem como a qualidade do que se está produzindo tem de ser
sistematicamente avaliada. (FALBO, 2005, p. 02)
Este trabalho justifica-se a partir da necessidade de controlar as mudanças
efetuadas dentro de um projeto, auxiliando o gerente de projeto nas tomadas de
decisões, tendo como objetivo o desenvolvimento do módulo de Gerência e Controle
de Mudanças para o Ambiente de Controle de Artefatos, AmCorA, garantindo que as
mudanças sejam realizadas corretamente, sem que exista perda na atualização de
artefatos por falta de comunicação entre membros de uma mesma equipe e busca a
implementação adequada, documentando todas as atualizações e mudanças
efetuadas pelos usuários do sistema e outros envolvido. Estende-se por todo o ciclo
de desenvolvimento, exibindo como deve ser feita a alteração de requisitos,
documentação, componentes, nos testes e até nos modelos de design. Se não existir
a aplicação aquedada do que está sendo proposto pode ocorrer problemas no
7
desenvolvimento do projeto, e consequentemente não chegando ao resultado
esperado e muito menos atendendo as necessidades estabelecidas. Além disso, o
conceito do AmCorA é integrar outros módulos da Engenharia de Software e prover
uma solução ampla para desenvolvedores, desde o nascer do projeto e durante todo
o ciclo de vida do software.
Figura 1 – Arquitetura Proposta do AmCorA Fonte: Elaborada pelos autores, 2015
Sobre a organização do trabalho, este está estruturado em quatro capítulos. No
primeiro, estão detalhadas as tecnologias utilizadas para o desenvolvimento do
sistema, seguido do capitulo que apresenta a Gerência de Mudança de acordo com
os padrões RUP. No terceiro, apresenta-se a análise detalhada do sistema
desenvolvido, incluindo os diagramas de UML, fechando com o quarto capítulo que
contém as informações sobre a implementação do Gerenciamento de Mudança no
AmCorA.
8
1 FERRAMENTAS E TECNOLOGIAS
Neste capitulo serão descritas as tecnologias utilizadas no desenvolvimento do
trabalho. De forma simplificada, serão apresentados tópicos sobre a linguagem Java,
a IDE que será utilizada para desenvolvimento da aplicação, o banco de dados que
será utilizando e outras ferramentas empregadas no projeto.
1.1 IDE NETBEANS
O NetBeans, fundado em junho de 2000 pela Sun Microsystems, é um projeto
opensouce com utilizado por muitos desenvolvedores. Através de seu site, permite
que programadores do mundo inteiro acessem os recursos da comunidade NetBeans.
E é esta mesma comunidade que colabora e diversifica cada vez mais essa
ferramenta, tornando a mais estável e diversificada a cada atualização.
A NetBeans IDE é um ambiente de desenvolvimento totalmente livre, que
permite que programadores escrevam, compilem, depurem e instalem seus
programas, desenvolvendo ferramentas e soluções próprias. Essa IDE apresenta as
falhas de digitação, variáveis não declaradas, métodos inexistentes, e facilidade na
importação de bibliotecas e outros auxílios de ferramenta. É totalmente escrita em
Java e suporta qualquer linguagem de programação, não se restringindo a linguagem
que a IDE foi desenvolvida.
Por ser desenvolvida em Java, oferece suporte abrangente para todas as
tecnologias de especificação Java, sendo também a primeira IDE gratuita a oferecer
suportes a JDK 9, JDK 7, Java EE 7, aprimoramentos de HTML 5.
Uma de suas principais características é o Sistema de Projeto onde todas as
funções do IDE são fornecidos por módulos e todos eles podem ser utilizados a partir
de uma única instalação da IDE. Atualmente, está na versão 8.0.2, que será a versão
utilizada no desenvolvimento desse projeto.
1.2 FERRAMENTA MVC
O Model View Control (MVC), é uma padrão de desenvolvimento utilizado
principalmente em aplicações WEB para gerenciamento de interface. Esse módulo de
9
gerenciamento facilita o desenvolvimento e auxilia no entendimento da confirmação
dos dados que deverão ser apresentados ao usuário de forma correta e no
gerenciamento da aplicação e faz com que os usuários possam controla-las de
maneira adequada.
MVC é composto por três tipos de objetos. O modelo é o objeto de aplicação, a vista é a apresentação na tela e o controlador define a maneira como a interface do usuário reage às entradas do mesmo. Antes do MVC, os projetos de interface para o usuário tendiam em agrupar esses objetivos. MVC para aumentar a flexibilidade e a reutilização. (GAMMA et al. 2000, p. 20)
Assim também Gamma (2000) afirma que o “principal objetivo do MVC é separar
os dados lógicos de negócios (Model) da interface do usuário (View) e o fluxo da
aplicação (Controller) ”, tendo como ideia principal permitir que uma mensagem lógica
de negócios possa ser acessada e visualizada através de várias interfaces. O Model
não visualiza quantas ou quais interfaces que estão sendo exibidas para o usuário,
enquanto a View não se importa de onde esteja os dados, mas garante que sua
aparência refila o estado do modelo, quer dizer, sempre que os dados do modelo
mudam, ele comunica a View para que elas se atualizem.
Figura 1.1 – Arquitetura MVC em Aplicações Web Fonte: Baptistella, 2010, alterado pelo autor.
10
1.3 MODELAGEM UML
A modelagem de dados é essencial em projetos de software. Ele assegura que
a funcionalidade de negócios é correta e são satisfeitas todas as necessidades do
usuário final, assim como o design, requisitos, segurança e outras características que
devem ser identificadas antes da implementação de códigos (MACORATTI, 2000).
Unified Modeling Language (UML) é uma linguagem que auxilia na
especificação, visualização e documentação de sistemas de software, desde a
estrutura até o design. Segundo o OMG, ele aceita a modelagem de qualquer tipo de
aplicação, em execução em qualquer tipo de combinação de hardware, sistema
operacional, linguagem de programação e rede.
A UML possui diagramas para obter todas as visões e aspectos do sistema, e
estes são divididos em Estruturais, que são os diagramas de Classe, Objeto,
Componentes, Implementação, Pacotes e Estrutura; e os Comportamentais, que
contém os Diagramas de Caso de Uso, Estado, Atividades e Iteração.
Figura 1.2 – Diagramas de UML Fonte: Sampaio, 2011, p.19.
11
1.4 BANCO DE DADOS MYSQL
Segundo Milani (2007), a entrada do MySQL no mercado, dá-se a partir da
necessidade de armazenar dados e informações da melhor forma possível, em um
mercado onde o aumento da popularidade da Internet e automatização de processos
estão cada vez mais presentes em um mundo cada vez mais globalizado.
Em seguida, Milani (2007) descreve o MySQL como um “sistema gerenciador de
banco de dados (SGBD) relacional, de licença dupla, projetado inicialmente para
trabalhar com aplicações de pequeno e médio porte, mas que hoje, atende também
aplicações de grande porte e com até mais vantagens do que seus concorrentes”. Ele
possui todas as características de grande porte precisa, com o título de ser o maior
banco de dados opensource com capacidade para concorrer com programas similares
de código fechado.
Como dito anteriormente, de acordo com Milani (2007) o MySQL possui duas
licenças:
1) Uma de software livre baseada nas clausulas da GNU-GPL (General Public
License), onde os princípios são:
a) Utilização: Permitindo seu uso para qualquer propósito,
b) Distribuição: Livre distribuição do software dentro e fora da comunidade de
programação,
c) Didática: Permite o estudo de seu funcionamento a partir de seu código fonte
e,
d) Colaboração: Onde permite a alteração do código fonte a fim de evolução da
ferramenta;
2) E a de licença comercial, onde se pode embutir o MySQL dentro de aplicações,
obter pacotes e suportes diferenciados.
Por ser um programa escrito em C e C++, o MySQL roda na maioria dos
sistemas operacionais existentes no mercado, além de facilitar a portabilidade entre
diferentes plataformas.
12
1.5 LINGUAGEM JAVA
Segundo o site oficial, Java "é uma linguagem de programação e plataforma
computacional lançada pela primeira vez pela Sun Microsystems em 1995". É a
linguagem usada por grande parte dos desenvolvedores web e está presente nos mais
diversos tipos de dispositivos, sendo base para praticamente a linguagem base para
todos os tipos de aplicações em rede e o padrão global para o desenvolvimento de
conteúdo baseado na Web e softwares corporativos .
A grande quantidade de desenvolvedores utilizando o Java origina-se da
grande quantidade de interessados na linguagem, o que faz com as possibilidades de
utilização aumente e possibilite a implementação de várias aplicações onde algumas
tecnologias teriam grande vantagem.
O Java será utilizado no projeto principalmente por ser uma linguagem
familiarizada pelos autores e disponibilizada livremente pela Oracle. Seus ambientes
de desenvolvimento: JDK, SDK e J2SE que são pacotes que obtém as classes
existentes em Java que formam um API (Application Programming Interface). Além
desse, existe o JRE (Java Runtime Enviroment), outro pacote de compilador que faz
com o Java funcione nos computadores, e neste estão incluídos todos os
componentes para que qualquer aplicação funcione nas mais diversas plataformas.
Lembrando que o próprio compilador instala a Máquina Virtual que faz a relação com
os browsers instalados no computador e é muito ágil, facilitando a visualização dos
aplicativos utilizados.
Figura 1.3 - Etapas para compilação e execução de um programa Java. Fonte: Mendes, 2009, p21.
13
1.5.1 Java Persistence API
Java Persistence API (JPA) é um framework que surgiu para ser utilizado na
camada de persistência juntamente com outras ferramentas provedoras, como
Hibernate ou JDBC. Existe para que o programador aumente sua produtividade,
controlando módulos dentro do Java, assim os programadores possuem um padrão
de mapeamento de objetos para o Banco de Dados. (GONÇALVES, 2008).
1.6 HIBERNATE
Conforme Konda (2004), Hibernate é um Framework Open Source que tem como
uma de suas principais finalidades o Mapeamento Objeto Relacional, transformando
objetos definidos pelo desenvolvedor em dados tabulares para banco de dados como
o MySQL. Assim, ele facilita o trabalho do desenvolvedor, diminuindo a quantidade de
código para acessar o banco de dados e facilitando fazer a persistência dos dados,
um processo chamado de Object Relational Mapping (ORM).
As configurações iniciais do Hibernate são feitas em arquivos de configuração
XML. Este arquivo é chamado persistence.xml, e está alocado, geralmente, na pasta
META-INF criada na aplicação. E neste arquivo de configuração são definidas as
propriedades de conexão, alguns deles estão descritos abaixo:
hibernate.dialect – Propriedade que especifica ao Hibernate qual é o dialeto que
ele usará para realizar a comunicação com o banco.
javax.persistence.jdbc.driver - Propriedade que contém o nome da classe do
driver Java Database Connectivity (JDBC) que será utilizado na conexão com o
banco de dados.
javax.persistence.jdbc.url - Indica o URL de conexão com o banco.
javax.persistence.jdbc.user – Possui o nome do usuário do banco de dados.
javax.persistence.jdbc.password – Possui a senha do banco de dados que o
Hibernate irá utilizar para fazer a conexão.
14
1.7 HTML 5
HTML é a sigla para Hypertext Markup Language, ou linguagem para marcação
de texto.
Segundo SILVA (2014, p. 24), hipertexto é todo o conteúdo inserido em um
documento para web e que tem como característica a possibilidade de se interligar
com outro documento da web através de links, presentes nas páginas dos sites.
O HTML teve sua evolução por oito versões:
HTML
HTML+
HTML 2.0
HTML 3.0
HTML 3.2
HTML 4.0
HTML 4.01
HTML 5.
Em 2007, o Word Wide Web Consortium (W3C), pretendia encerrar o
desenvolvimento do HTML para dar lugar ao XHTML, e tornou pública sua decisão de
estudos em cima do HTML 5 que já vinha sendo desenvolvido pelo Web Hypertext
Application Techonology Working Group (WHATWG ou Grupo de Trabalho para
Tecnologias de Hipertexto em Aplicações para Web). Assim, os dois grupos juntos,
começam o desenvolvimento do HTML 5.
1.8 JAVASCRIPT
Sendo o HTML uma linguagem de marcação que é destinada a estruturação de
páginas web, não se podia aplicar a ela estilos visuais e de apresentação, até a versão
4.0. E também não possuía funcionalidades para incluir interatividade avançada à
página, e essas tarefas acabavam como função das linguagens de programação.
O JavaScript foi criado com o propósito de adicionar interatividade a uma página
web em seu entrelaçamento com o HTML. Sua primeira versão, desenvolvida pela
Netscape em parceria com a Sun Microsystems e denominada JavaScript 1.0, foi
15
lançada em 1995 e implementada em março de 1996 no navegador Netscape
Navigator 2.0. Logo após, durante uma época que foi chamada de “a guerra dos
browsers”, a Microsoft desenvolveu a linguagem JScript baseada em Visual Basic, e
que foi lançada juntamente com o navegador Internet Explorer 3.0 e era chamada de
JScript 1.0. (SILVA, 2010, p. 23).
Ainda conforme o mesmo autor:
JavaScript é uma linguagem desenvolvida para rodar do lado do cliente, isto
é, a interpretação e o funcionamento da linguagem dependem de
funcionalidades hospedadas no navegador do usuário. (SILVA, 2010, p.23)
Sendo assim, o funcionamento de módulos e formulários das páginas web
ligadas ao servidor, assim como a adição e processamento de dados, ficam de
responsabilidade das linguagens de programação. O JavaScript necessita apenas do
navegador do usuário para que seus scripts funcionem, ao contrário de linguagens de
programação, como PHP, Java e outros, precisam de um servidor local para suporte
com essas linguagens.
1.8.1 JQuery
Conforme Pan (2011, p. 25), “JQuery é uma biblioteca em JavaScript projetada
para simplificar as interações via script com o Document Objetc Model1”. Criada
principalmente para diminuir o peso de tarefas que anteriormente eram escritas em
JavaScript com Ajax, esta linguagem ganhou espaço principalmente por ser uma
ferramenta Open Source e em 2006 surgiu-se uma biblioteca que reunia todas as
funcionalidades do JS, para facilitar a vida do programador. A comunidade sempre
está criando novas e incríveis funcionalidades sobre a linguagem.
1.9 LINGUAGEM CSS3
Cascading Style Sheet ou CSS, são folhas de estilo em cascata. A melhor e mais
precisa definição de CSS, encontra-se na página inicial do CSS no site do W3C, e diz
1DOM é uma plataforma que representa como as marcações HTML são lidas pelo navegador.
16
que “folhas de estilo em cascata, são mecanismos simples para adicionar estilos
diferenciados aos documentos web”.
De acordo com Nakashima (2011), as CSSs têm como princípio marcar e
estilizar o HTML/XML. Como o HTML foi criada para ser uma linguagem de marcação
e estruturação de conteúdo, todas as funções de apresentação de um documento, fica
de responsabilidade do CSS.
A primeira proposta de implementação do CSS, surgiu em 1994 com Tim
Berners-Lee, desenvolvedor do navegador Nexus. Antes disso, o próprio Tim
considerava que esse tipo de tratamento deveria ser feito pelo navegador. Em 1996,
foram lançadas as CSS1 com recomendações oficiais do W3C (NAKASHIMA, 2011).
1.10 LESS
O Less é uma linguagem que será utilizada juntamente com o CSS, por ter a
mesma ideia e sintaxe praticamente igual. Foi criada com o intuito de incrementar a
produtividade e adquirir agilidade de programação. Segundo Lopes (2012), costuma-
se chamar está linguagem de pré-processador, por somente o browser compilar CSS.
A forma de utilização dele é ter um arquivo .less mas na finalização um .css compilado
com o comando lessc. Pode-se também executar com o JavaScript e compilar o Less
diretamente no browser, mas não é recomendado para a produção pelo alto tempo de
processamento e utilização de memória.
1.11 TOMCAT
Nas palavras de Luckow (2010), o Apache Tomcat é, ao mesmo tempo, um
contêiner de Servlets Java e um servidor Web, e seu suporte às tecnologias Java
Servlet e Java Server Pages (JSP) permitem que o Java funcione sem grandes
problemas em aplicações Web.
Este contêiner desenvolvido pela Apache Software Foundation, é distribuído
como software livre e foi criado dentro do projeto Apache Jakarta, e posteriormente foi
separado já que o projeto foi concluído. Hoje, sua implementação de referência é o
GlassFish. Seu servidor possui ferramentas de configuração e gerenciamento que
podem ser manualmente configurados em um arquivo XML.
17
2 FUNDAMENTAÇÃO TEÓRICA
Esse capítulo será abordado a apresentação geral sobre a Gerência de
Mudanças bem como apresenta os principais conceitos e características de um
sistema de Controle de Mudanças.
2.1 CONTROLE DE MUDANÇAS
O sistema de Gerenciamento de Configuração do AmCorA será baseado no
modelo do Rational Unified Process (RUP), uma plataforma da área de Engenharia
de Software que foi criada pela IBM e que reúne um conjunto de filosofias, princípios,
estruturas e linguagem que visam garantir que o planejamento e o desenvolvimento
de um software sejam bem-sucedidos. A Gerência de Mudança é uma das
disciplinas do RUP, parte do Sistema de Configuração, utilizada durante todo o ciclo
de vida de um produto, desde a iniciação do projeto e implementação e está
entrelaçada com a Gerência de Configuração, conforme ilustração abaixo:
Figura 2.1 – Gráfico de Disciplinas, Fases e Iterações do RUP Fonte: IBM, 2006.
18
Segundo a IBM (2006), a prática do Gerenciamento e Controle de Mudanças
(CM) é imprescindível para o desenvolvimento de software, pois é ele quem faz o
gerenciamento de espaços de trabalho, desenvolvimento paralelo, integração e
construções, facilitando o trabalho de analistas e desenvolvedores.
Figura 2.2 – Funções do Controle de Mudança Fonte: IBM, 2006.
Quando se possui vários programadores, organizados de equipes diferentes,
podendo até estar em diferentes localidades, trabalhando em um mesmo sistema,
pode ou não existir a ausência de disciplina no processo de desenvolvimento. Esse
controle certifica-se que não existam confusões e que os Produtos de Trabalho não
entrem em conflito. Os principais problemas no desenvolvimento de um software em
equipe, de acordo com a IBM (2006) são:
I. Atualização Simultânea: Que ocorre quando existe dois membros ou mais de
uma equipe trabalhando separadamente em um mesmo Produto de Trabalho,
e um membro a fazer as mudanças pode acabar sobrescrevendo o arquivo do
outro membro e desfazer alterações realizadas.
19
II. Notificação Limitada: Quando um ou mais desenvolvedores não são notificados
de atualizações feitas nos Produtos de Trabalho
III. Múltiplas Versões: Como em grande parte dos softwares, enquanto um cliente
está utilizando uma versão do sistema, um ou mais outras podem estar sendo
desenvolvidas e/ou testadas, e se forem encontrados problemas dentro delas,
pode ocorrer a propagação de erros, que resultam em correções e retrabalho.
Nas instruções do RUP são listados alguns dos principais benefícios de
utilização de um Sistema CM, sendo eles:
I. Controlar as versões que são utilizadas nos builds do software;
II. Suporte a métodos de desenvolvimento;
III. Garantir a integridade do produto final, além de correção do produto
configurado;
IV. Fornecer ambiente estável para desenvolvimento do produto;
V. Restringir as alterações nos Produtos de Trabalho de acordo com as condições
estabelecidas no projeto;
VI. Fornecer auditoria de acompanhamento do porquê e quando e por quem foi
feita a alteração dos Produtos de Trabalho (IBM, 2006).
Outra principal função de um Sistema de CM é o armazenamento de dados
detalhados de "contabilidade": quem, quando e porque um desenvolvedor criou uma
nova versão específica e quais versões de origens foram utilizadas em cada
construção. (IBM, 2006)
O CM os dados de todas as versões dos arquivos de origem dos artefatos, atuais
e históricas, de implementação, design, que definem determinadas versões de um
sistema ou seus componentes.
2.2 GERENCIAMENTO DE CONTROLE DE MUDANÇAS
Conforme o site da IBM (2006), Gerenciamento de Controle de Mudanças
(Change Request Management, CRM) "é um processo para garantir que os métodos
e procedimentos padronizados sejam utilizados para manipulação eficiente e rápida
de todas as mudanças, para minimizar o impacto de incidentes relacionados a
20
mudanças". Envolve principalmente os trabalhos das Equipes de Revisão de
Mudanças e do Conselho de Controle de Mudanças.
No início do projeto, o CRM pode ser relativamente informal. No decorrer do
projeto, ele vai se tornando mais rigoroso, visando garantir que recursos de teste e
documentação tratem corretamente de das mudanças, das possíveis mudanças e
assim, a perfeita execução no desenvolvimento do projeto.
Abaixo, os três tópicos que são, segundo a IBM, as principais atividades de
coordenação do CRM:
2.2.1 Atividades e Artefatos
Paralelamente com o desenvolvimento de software iterativamente, visa
monitorar as mudanças continuamente e facilitar a solução de possíveis problemas.
Parte do estabelecimento de passos e procedimentos quem podem ser repetidos no
Gerenciamento de Mudanças ou em outros artefatos de desenvolvimento.
2.2.2 Iterações e Libertações
Engloba o estabelecer e liberar uma baseline depois de testada no final de cada
iteração. É de grande importância, pois faz a manutenção dos elementos em cada
release e gerencia o impacto de cada atualização.
2.2.3 Alteração no Software
Faz o controle dos principais problemas no desenvolvimento de software e indica
soluções para eles, entre elas:
I. Os espaços de trabalho isolados reduzem a interferência entre membros da
equipe;
II. A propagação de mudança é melhor avaliada e controlada;
III. As mudanças são mantidas em um sistema mais robusto e personalizável e;
IV. Os fluxos de trabalho da mudança de requisitos é definido e pode haver
repetição.
21
O responsável por esse módulo é o Gerenciador de Controle de Mudanças.
Sua principal responsabilidade é entender os princípios do gerenciamento de
configuração, pois ela é importante para estimar impactos no custo e planejamento do
controle de mudanças. Essa responsabilidade pode ser dividida com o Conselho de
Controle de Mudanças, tendo representantes em todas as partes.
A Figura 2.3 ilustra as funções do Gerenciador de Mudança e seu lugar de
trabalho juntamente com o Gerenciamento de Configuração:
Figura 2.3 – Funções do Gerenciador de Controle de Mudanças Fonte: IBM, 2006.
2.3 GERENCIAMENTO UNIFICADO DE MUDANÇAS
O Gerenciamento Unificado de Mudanças (UCM) é responsável por gerenciar
todas as mudanças do desenvolvimento do sistema de software, dos requisitos até o
lançamento. Essa abordagem da Rational Software tem como principal aspecto a
unificação das atividades utilizadas no planejamento e acompanhamento do projeto,
além dos artefatos que sofrerem mudanças.
2.4 GERENCIAMENTO DE SOLICITAÇÃO DE MUDANÇA
A implementação do Gerenciamento de Mudança RUP, existe o Gerenciamento
de Solicitações de Mudança e sua definição se dá a partir de 5 passos, sendo eles:
I. Solicitação de Mudança – É um artefato usado para solicitar mudanças no
projeto. Todas as mudanças, históricos, datas e motivos ficam armazenados na
22
solicitação de mudanças e essas informações são importantes no fechamento
do projeto.
II. Comitê de Controle de Mudança – Representantes de todas as partes
interessadas do projeto, que supervisionam o processo de mudança.
III. Reunião de Revisão do Comitê – É – Todo o a reunião em que o Comitê de
Controle de Mudança avalia as solicitações de mudança. Análise se primeiro se
a solicitação é válida, após isso é decidido se a mudança está dentro ou fora dos
releases atuais, avaliando todos os níveis.
IV. Formulário de envio de Solicitação de Mudança – Formulário que aparece
quando é solicitada uma mudança pela primeira vez.
V. Formulário Combinado de Solicitação de Mudança – Formulário em que o comitê
avalia uma mudança e se ela foi aprovada ou não.
Figura 2.5 – Atividades de Exemplo para o Gerenciamento de Solicitação de Mudança Fonte: RUP, IBM. Modificado por FUNPAR, UFPR, 2001.
23
Além disso, durante os ciclos de vida da Solicitação de Mudança existem os
estamos e quem será notificado durante cada passo, e eles estão ilustrados abaixo e
descritos na tabela a seguir:
Figura 2.6 – Estados e Transições de Exemplo de uma Solicitação de Mudança Fonte: RUP, IBM. Modificado por FUNPAR, UFPR, 2001.
Estado Definição Controle de Acesso
Enviada Este estado é o resultado de 1) envio de uma nova Solicitação de Mudança, 2) atualização de uma Solicitação de Mudança existente ou 3) consideração de uma Solicitação de Mudança Adiada para um novo ciclo do release. A Solicitação de Mudança é colocada na fila de Revisão do CCB. Não ocorre atribuição de propriedade como resultado desta ação.
Todos os Usuários
Adiada A Solicitação de Mudança é determinada como válida, mas "fora do escopo" para os releases atuais. As Solicitações de Mudança Adiadas serão mantidas e reconsideradas para futuros releases. Um release-alvo
Administrador
24
pode ser atribuído para indicar o período durante o qual a Solicitação de Mudança pode ser Enviada e entrar novamente na fila de Revisão do CCB.
Gerente de Projeto
Duplicada Uma Solicitação de Mudança parece ser a cópia de outra solicitação que já foi enviada. As Solicitações de Mudança podem ser colocadas neste estado pelo Administrador de Revisão do CCB ou pelo membro da equipe responsável pela resolução. Quando a solicitação é colocada no estado Duplicada, o número da Solicitação de Mudança copiada é registrado (na guia Attachments do ClearQuest). O solicitante deve, primeiramente, consultar o banco de dados de Solicitação de Mudança e verificar se há solicitações duplicadas. Dessa forma, não será necessário seguir diversos passos do processo de revisão, o que economiza tempo. O solicitante da Solicitação de Mudança duplicada deve ser incluído na lista de notificação da solicitação original para obter informações sobre a resolução.
Administrador
Gerente de Projeto
Gerente de QE
Desenvolvimento
Recusada Uma Solicitação de Mudança é recusada quando Reunião de Revisão do CCB ou o membro da equipe atribuído determina que a solicitação é inválida ou é necessário que o solicitante forneça mais informações. Se já tiver alguma atribuição (Aberta), a Solicitação de Mudança será removida da fila de resolução e revisada novamente. Uma autoridade designada do CCB fica responsável pela confirmação. Não é exigida nenhuma ação do solicitante, a menos que haja necessidade. Nesse caso, o estado da Solicitação de Mudança passará para o estado Mais Informações. As novas informações da solicitação serão analisadas na Reunião de Revisão do CCB. Se a solicitação for confirmada como inválida, ela será Fechada pelo CCB e o solicitante será notificado.
Administrador
Gerente de Projeto
Gerente de Desenvolvimento
Gerente de Testes
Mais Informações
Não há dados suficientes para confirmar a validade de uma Solicitação de Mudança Recusada ou Duplicada. Automaticamente, a propriedade passa para o solicitante, que é notificado para que forneça mais dados.
Administrador
Aberta A Solicitação de Mudança foi considerada "no escopo" da atual release e aguarda uma resolução. Ela foi incluída na fila de resolução antes de um marco-alvo. Ela fica na "fila de atribuições". Os participantes da reunião são os únicos que têm autorização para abrir uma Solicitação de Mudança que esteja na fila de resolução. Se for encontrada uma solicitação de prioridade dois ou superior, ela deverá ser imediatamente observada pelo Gerente de QE ou Desenvolvimento. Nesse momento, eles podem decidir convocar uma Reunião de Revisão do CCB de emergência ou apenas abrir a Solicitação de Mudança imediatamente na fila de resolução.
Administrador
Gerente de Projeto
Gerente de Desenvolvimento
Departamento de QE
Atribuída Uma Solicitação de Mudança Aberta passa a ser responsabilidade do Gerente de Projeto, que deverá Atribuir Tarefas de acordo com o tipo de solicitação e, em seguida, atualizar a programação, se necessário.
Gerente de Projeto
Resolvida Significa que a resolução dessa Solicitação de Mudança foi concluída e está pronta para verificação. Se o solicitante for um membro do Departamento de QE, a propriedade passa automaticamente para ele. Pode ser também que ela passe para o Gerente de QE para ser feita uma reatribuição manual.
Administrador
Gerente de Projeto
25
Gerente de Desenvolvimento
Gerente de QE
Departamento de Desenvolvimento
Teste Reprovado
Estado da Solicitação de Mudança que falha durante a avaliação de um build de teste ou de release. A propriedade passa automaticamente para o membro da equipe que resolveu a solicitação.
Administrador
Departamento de QE
Verificada A Solicitação de Mudança foi Verificada em um build de teste e está pronta para ser incluída no release.
Administrador
Departamento de QE
Fechada A Solicitação de Mudança não requer mais atenção. Este é o estado final de uma Solicitação de Mudança. Somente o Administrador de Revisão do CCB pode fechar uma Solicitação de Mudança. Depois que a solicitação for Fechada, o solicitante receberá uma notificação por e-mail com o estado final da Solicitação de Mudança. Uma Solicitação de Mudança pode ser Fechada: 1) depois que a resolução Verificada é validada em um build de release, 2) quando o estado Recusada é confirmado ou 3) depois de confirmado que a solicitação é duplicada. No último caso, o solicitante será informado do estado da solicitação e essa informação será acrescentada à Solicitação de Mudança para futuras notificações (consulte as definições de estado "Recusada" e "Duplicada" para obter mais detalhes). Se o solicitante quiser argumentar contra algum fechamento, a solicitação deverá ser atualizada e Enviada novamente para revisão do CCB.
Administrador
Tabela 2.1 – Descrição dos Estados e Transições de uma Solicitação de Mudança Fonte: RUP, IBM. Modificado por FUNPAR, UFPR, 2001.
26
3 SISTEMA DE GERÊNCIA DE MUDANÇAS DO AMCORA
Esse capítulo apresenta a ferramenta de Gerenciamento de Mudança do
AmCorA (GM-AmCorA) desenvolvido nesse projeto, assim como os diagramas de
UML elaborados a partir do processo de análise do sistema, sendo eles os diagramas
de Caso de Uso, Diagrama de Atividade, Diagrama e Sequência e Diagrama MVC.
3.1 DIAGRAMA DE CASO DE USO
A Figura 3.1 apresenta o diagrama de caso de uso da ferramenta de GM-
AmCorA, elaborado após o levantamento dos requisitos de mudanças necessários
para o sistema. Nesta mesma figura também é apresentado as funções do ator
envolvido.
Figura 3.1 – Diagrama de Caso de Uso de Gerência de Mudanças Fonte: Elaborado pelos autores, 2015.
27
3.2 DIAGRAMA DE CLASSE
A figura 3.2 apresenta o diagrama de classe do Sistema AmCorA, desenvolvido
após análise do design da ferramenta. Esse diagrama envolve todas as classes
requeridas no sistema, inclusive as que não fazem parte diretamente do GM-AmCorA.
Figura 3.2 - Diagrama de Classes AmCorA Fonte: Elaborado pelos autores, 2015.
28
3.3 ESPECIFICAÇÕES DE HISTÓRIAS E DIAGRAMAS
Nesta sessão serão abordadas as interações do usuário com o Sistema AmCorA
apresentando suas funcionalidades. Serão representados através dos Diagramas de
Atividade, Diagramas MVC e Diagramas de Sequência, nesta ordem.
3.3.1 Manter Projeto
Consegue-se observar na Figura 3.3 os atributos das entidades relacionada com
a entidade Projeto e os passos de criação e atualização de um projeto. Qualquer
usuário cadastrado no sistema AmCorA, pode criar um novo projeto. Também fica
ilustrados nas Figuras 3.4, 3.5 e 3.6 validação e confirmação dos dados antes de
serem submetidos para a persistência no servidor.
Aplicando o conceito de Gerência de Mudanças, o Manter Projeto é importante
pois ele armazena as alterações do projeto durante o seu ciclo.
Figura 3.3 – Diagrama de Atividades – Manter Projeto Fonte: Elaborado pelos autores, 2015.
29
Figura 3.4 – Diagrama de MVC – Manter Projeto Fonte: Elaborado pelos autores, 2015.
30
Figura 3.5 – Diagrama de Sequência – Adicionar Projeto Fonte: Elaborado pelos autores, 2015.
Figura 3.6 – Diagrama de Sequência – Atualizar Projeto Fonte: Elaborado pelos autores, 2015.
3.3.2 Manter Vínculo
O caso de uso Manter Vínculo ilustra a vinculação de um papel a um membro,
para facilitar a visualização de quais são os membros que estão vinculados a este
31
artefato ou projeto. A Figura 3.7 exibe as atividades para o cadastro de um vínculo e
sua manutenção. As figuras 3.8, 3.9 e 3.10 mostram sua validão e confirmação dos
dados antes de ser submetidos a persistência no servidor.
Figura 3.7 – Diagrama de Atividade – Manter Vínculos Fonte: Elaborado pelos autores, 2015.
Figura 3.8 – Diagrama de Sequência – Adicionar Vínculo Fonte: Elaborado pelos autores, 2015.
32
Figura 3.9 – Diagrama de Sequência – Atualizar Vínculo Fonte: Elaborado pelos autores, 2015.
Figura 3.10 – Diagrama de Sequência – Excluir Vínculo Fonte: Elaborado pelos autores, 2015.
33
3.3.3 Manter Papeis
Os papeis definirão os membros que estão envolvidos na tarefa vinculada a seu
papel. Esse caso de uso é o que determina e aplica a responsabilidade
correspondente a cada membro ativo em uma determinada tarefa. Quando um
membro cria um projeto, este automaticamente recebe o papel de administrador do
Projeto, e somente o membro administrador do Projeto que determina o papel de cada
integrante. A Figura 3.11 e 3.12 apresentam os Diagramas de Atividade e MVC do
caso de uso Manter Papeis, e as Figuras 3.13, 3.14 e 3.15 apresentam os Diagramas
de Sequência Adicionar, Atualizar e Excluir Papel.
Figura 3.11 – Diagrama de Atividade – Manter Papeis Fonte: Elaborado pelos autores, 2015.
34
Figura 3.12 – Diagrama MVC – Manter Papeis Fonte: Elaborado pelos autores, 2015.
35
Figura 3.13 – Diagrama de Sequência – Adicionar Papel Fonte: Elaborado pelos autores, 2015.
Figura 3.14 – Diagrama de Sequência – Atualizar Papel Fonte: Elaborado pelos autores, 2015.
36
Figura 3.15 – Diagrama de Sequência – Excluir Papel Fonte: Elaborado pelos autores, 2015.
3.3.4 Manter Membro
Para ter acesso aos projetos, o membro deve ser cadastrado no sistema. O
Membro Administrador já tem acesso total ao sistema a partir de sua implementação
e outros usuários podem se cadastrar a qualquer momento para depois ser vinculados
a projetos. A Figura 3.16 apresenta o Diagrama de Atividades de Manter Membros, a
3.17 o Diagrama MVC e as Figuras 3.18 e 3.19 ilustram os Diagramas de Sequência
Adicionar e Alterar Membro.
37
Figura 3.16 – Diagrama de Atividade – Manter Membro Fonte: Elaborado pelos autores, 2015.
38
Figura 3.17 – Diagrama MVC – Manter Membro Fonte: Elaborado pelos autores, 2015.
39
Figura 3.18 – Diagrama de Sequência – Adicionar Membro Fonte: Elaborado pelos autores, 2015.
Figura 3.19 – Diagrama de Sequência – Atualizar Membro Fonte: Elaborado pelos autores, 2015.
40
3.3.5 Manter Mudança
Este Caso de Uso ilustra a principal atividade do GM-AmCorA, pois a partir dele
entende-se o funcionamento do Módulo de Gerência de Mudança, como essas
mudanças são armazenadas e o passo a passo desse processo.
Na Figura 3.20 apresenta-se o Diagrama de Atividades do Caso de Uso Manter
Mudança, seguido da Figura 3.21 ilustrando o Diagrama MVC. As Figuras 3.22, 3.23
e 3.24 mostram, respectivamente dos Diagramas de Sequência de Adicionar, Alterar
e Excluir Mudança.
Figura 3.20 – Diagrama de Atividades – Manter Mudança Fonte: Elaborado pelos autores, 2015.
41
Figura 3.21 – Diagrama MVC – Manter Mudança Fonte: Elaborado pelos autores, 2015.
42
Figura 3.22 – Diagrama Sequência – Adicionar Mudança Fonte: Elaborado pelos autores, 2015.
Figura 3.23 – Diagrama Sequência – Atualizar Mudança Fonte: Elaborado pelos autores, 2015.
43
Figura 3.24 – Diagrama Sequência – Excluir Mudança Fonte: Elaborado pelos autores, 2015.
44
3.3.6 Gerar Histórico de Mudança
Este caso de uso ilustra as mudanças que foram solicitadas e executadas
durante o tempo de projeto. A Figura 3.25 exibe o Diagrama de Atividades de Gerar
Histórico de Mudança, seguido da Figura 3.26 que apresenta o Diagrama de
Sequência dessa atividade.
Figura 3.25 – Diagrama de Atividades – Gerar Histórico de Mudanças Fonte: Elaborado pelos autores, 2015.
45
Figura 3.26 – Diagrama de Sequência – Gerar Histórico de Mudança Fonte: Elaborado pelos autores, 2015.
3.3.7 Banco de Dados
Nesta subseção é apresentado o Diagrama de Mapeamento para o Modelo
Relacional, expressão a organização dos dados do projeto no Banco de Dados.
Conforme descrito no capítulo 1, o SGBD utilizado no desenvolvimento do projeto foi
o MySQL, juntamente com o framework Hibernate, ferramenta que facilita a
persistência de dados. Na Figura 3.27 está apresentado o Diagrama de Modelo
Relacional.
46
Figura 3.27 – Modelo de Entidade e Relacionamento do Banco de Dados Fonte: Elaborado pelos autores, 2015.
47
4 IMPLEMENTAÇÃO DO SISTEMA
Neste capítulo estão expostas as interfaces gráficas do Sistema AmCorA no
que se diz pertinente ao módulo de Gerência de Mudanças. Junto com as telas,
contém alguns comentários sobre o funcionamento e detalhes da implementação do
sistema.
4.1 CADASTRO DE MEMBRO
Para acesso ao AmCorA é necessário que o Membro esteja cadastrado no
sistema. Sendo assim, na página inicial do projeto, do lado direito da tela, existe o
botão “Cadastre-se” para que o usuário realize seu cadastro, conforme é exibido na
Figura 4.1.
Figura 4.1 – Tela Inicial do Sistema AmCorA Fonte: Elaborado pelos autores, 2015.
Após clicar em “Cadastrar-se”, é exibido um formulário de cadastro de
membros, onde o usuário deverá fornecer os dados para o cadastro. O sistema gera
48
uma senha aleatória e envia para o e-mail fornecido no formulário, com esse processo
o sistema valida o e-mail usuário. Na figura 4.2 é exibido o formulário de cadastro de
membro.
Figura 4.2 - Formulário de Cadastro de Membro Fonte: Elaborado pelos autores, 2015.
Ao efetuar o primeiro login no sistema, a tela de alteração de senha é exibida
automaticamente, obrigando ao usuário que ele altere a senha de acesso ao Sistema
para uma senha que seja de sua preferência. Esta tela é apresentada na figura 4.3.
Figura 4.3 - Tela Alteração Obrigatória de Senha Fonte: Elaborado pelos autores, 2015.
49
4.2 SOLICITAÇÃO DE MUDANÇA
Qualquer membro do projeto pode solicitar a mudança de um artefato, para isso, ele
deve fazer o login no sistema, selecionar o Projeto onde se encontra o artefato no lado
esquerdo da tela, clicar na aba “Artefatos” na parte superior da tela, escolher do lado
direito, na arvore de dependência o artefato que ele deseja solicitar a mudança e logo
após clicar no botão “Solicitar Mudança”. Na Figura 4.4 é ilustrada a tela de Solicitação
de Mudança.
Figura 4.4 - Tela de Solicitação de Mudança Fonte: Elaborado pelos autores, 2015.
Após o membro clicar em “Solicitação de Mudança” o sistema exibe o formulário
para preenchimento dos dados da mudança do artefato. Nele o membro deve resumir
a mudança que ele deseja que seja feita e seleciona também qual o outro membro do
projeto será responsável em executar a mudança solicitada. Se os dados estiverem
corretos, ele clica em salvar e é criado a Solicitação de Mudança. Na Figura 4.5 é
exibida a tela com o formulário de Solicitação de Mudança.
50
Figura 4.5 – Tela com Formulário de Solicitação de Mudança Fonte: Elaborado pelos autores, 2015.
4.3 VISUALIZAR SOLICICITAÇÃO
Após feita a Solicitação de Mudança, o Membro que solicitou a mudança pode
visualizar a sua solicitação na tela de Resumo do sistema. Para isso, ele deve clicar
na aba de “Resumo” no topo da tela. Abaixo, aparecerá, no campo de histórico em cor
laranja, a mudança que foi solicitada, conforme é ilustrado na Figura 4.6 abaixo.
Figura 4.6 – Tela de Visualização da Solicitação de Mudança Fonte: Elaborado pelos autores, 2015.
51
4.4 APROVAÇÃO OU REPROVAÇÃO DE MUDANÇA
Após feita a Solicitação de Mudança, o membro selecionado como responsável
pela mudança deve aprovar ou não a mudança solicitada. Para isso, ele faz o login no
sistema, acessa a tela de resumo, igualmente explicado na tela anterior, e em cima
do campo da solicitação, ele consegue visualizar os botões de aprovação ou
reprovação da mudança solicitada. Se o membro clicar em cima do campo laranja, ele
consegue visualizar detalhadamente a mudança solicitada. Lembrando que, somente
os membros que foram escolhidos como responsáveis conseguem aprovar a
mudança solicitada. Na Figura 4.7 é exibida a tela de aprovação ou reprovação.
Figura 4.7 – Tela de Aprovação ou Reprovação da Mudança Solicitada Fonte: Elaborado pelos autores, 2015.
4.5 SITUAÇÃO DE MUDANÇA SOLICITADA
Também é possível visualizar a situação da mudança solicitada. Para isso, o
membro deve clicar no botão “Histórico” do lado direito da tela. Na Figura 4.8 é
ilustrada este botão.
52
Figura 4.8 – Tela do Botão do Histórico de Mudança Fonte: Elaborado pelos autores, 2015.
Feito isso, abre-se uma tela que mostra o status atual da mudança. Estes podem
ser “Aprovado”, “Reprovado” ou “Finalizado, conforme as figuras 4.9, 4.10 e 4.11 que
seguem abaixo.
Figura 4.9 – Tela do Status de Mudança Aprovado Fonte: Elaborado pelos autores, 2015.
53
Figura 4.10 – Tela do Status de Mudança Reprovado Fonte: Elaborado pelos autores, 2015.
Figura 4.11 – Tela do Status de Mudança Finalizado Fonte: Elaborado pelos autores, 2015.
54
CONCLUSÃO
A tecnologia da informação se tornou essencial para a rápida evolução de
organizações, gerando impactos nas estratégias de negócios. Dada esta importância,
o gerenciamento de projetos é cada vez mais necessário para que os mesmos sejam
executados de maneira eficaz, garantindo sua integridade, facilidade e rapidez na
programação e desenvolvimento de um software.
Na elaboração deste trabalho, foi permitido um conhecimento amplo sobre a
Gerência de Mudanças e sobre uma ferramenta completa de controle de artefatos. A
utilização desde tipo de ferramenta tende a crescer cada vez mais no setor de
desenvolvimento de projetos e é modelo para todas as áreas e não apenas na criação
de softwares.
Mesmo com todo o conhecimento adquirido durante o seu desenvolvimento,
existiram muitas dificuldades em relação ao trabalho, não apenas na pesquisa o
assunto como no desenvolvimento da ferramenta. Algumas dessas dificuldades foram
relação a falta de conhecimento sobre o assunto e o fato de usar novos plug-ins e
frameworks que não conhecíamos, mas que foram essenciais para a programação e
desenvolvimento do Sistema AmCorA.
A elaboração do trabalho em grupo foi ideal para que cada grupo focasse em um
módulo do Sistema AmCorA, deixando o sistema mais completo e ajudando quem,
posteriormente, assuma a responsabilidade dos módulos ainda não executados
integrando ainda mais funcionalidades ao sistema.
Este trabalho não termina aqui. Existem muitos outros passos do sistema a
serem implantados, não somente na Gerência de Mudança, mas em todos os módulos
do AmCorA. O AmCorA é um projeto amplo que pode ser incluída ainda mais
funcionalidades de acordo com as necessidades dos projetos e de seus
Gerenciadores.
55
REFERÊNCIAS BIBLIOGRÁFICAS
BAPTISTELLA, Adriano J. Abordando a Arquitetura MVC, e Design Patterns;
Obersver, Composite, Strategy. 2010. Disponível em
<http://www.linhadecodigo.com.br/artigo/2367/abordando-a-arquitetura-mvc-e-
design-patterns-observer-composite-strategy.aspx> Acesso em 07 jun. 2015
CAELUM. Java Para Desenvolvimento Web (Apostila do Curso). Disponível em
<http://www.caelum.com.br/apostila-java-web/> Acesso em 09 mar. 2015.
FALBO, Ricardo de A. Engenharia de Software (Notas de Aula). 2005. Disponível
em <http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/NotasDeAula.pdf>
Acesso em 04 jun. 2015.
GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de Software
Orientado a Objetos. 2. ed. Porto Alegre: Bookman, 2000.
GODOY, Fernando. O que é JSF?. 2011. Disponível em
<https://fernandogodoy.wordpress.com/2011/02/12/o-que-e-jsf/> Acesso em 20 fev.
2015.
GONÇALVES, Edson. Desenvolvendo Aplicações Web Com JSP, Servlets,
Javaserver Faces, Hibernate, EJB 3 Persistence e Ajax. 1. ed. Rio de Janeiro:
Editora Ciência Moderna Ltda., 2007.
GONÇALVES, Edson. Dominando Java Server Faces e Facelets Utilizando Spring
2.5, Hibernate e JPA. 1 ed. Rio de Janeiro: Editora Ciência Moderna Ltda., 2008.
IBM, Corp. Configuração e Gerenciamento de Mudanças. Disponível em <
http://www.wthreex.com/rup/v711_sp_ptbr/index.htm> Acesso em 02 abr. 2015
LOPES, Sérgio. CSS Fácil, flexível e dinâmico com LESS. Disponível em
<http://blog.caelum.com.br/css-facil-flexivel-e-dinamico-com-less/> Acesso em 10
mar. 2015.
56
LOTAR, Alfredo. Programando com ASP.NET MVC. 1 ed. São Paulo: Novatec
Editora Novatec LTDA., 2011. Disponível em <
http://novatec.com.br/livros/programando_aspnet-mvc/capitulo9788575222836.pdf>
Acesso em 05 mai. 2015.
MACORATTI, José Carlos. UML - Unified Modeling Language e Visual Modeler.
UML – Conceitos, Definições e Exemplos. 2010. Disponível em <
http://www.macoratti.net/uml_vb.htm> Acesso em 06 jun. 2015.
MILANI, André. MySQL: Guia do Programador. 1. ed. São Paulo: Novatec Editora,
2007.
NETBEANS. Bem-Vindo Ao NetBeans e ao Site www.netbeans.org. Disponível em
<https://netbeans.org/index_pt_PT.html> Acesso em 20 fev. 2015.
NETBEANS. Visão Geral do NetBeans. 2011. Disponível em
<https://netbeans.org/features/index_pt_BR.html> Acesso em: 20 fev. 2015.
OMG. Introduction To OMG's Unified Modeling Language™ (UML®). 2015.
Disponível em <http://www.omg.org/gettingstarted/what_is_uml.htm> Acesso em 02
jun. 2015
PAN, H. Conceitos básicos sobre JQuery. Disponível em
<https://software.intel.com/pt-br/articles/jquery-basics?language=es> Acesso em 07
mar. 2015.
PEREIRA, Altieri. JQuery: Entendendo alguns conceitos bem simples. Disponível
em <http://www.devmedia.com.br/jquery-entendendo-alguns-conceitos-bem-
simples/22935> Acesso em 09 mar. 2015.
RATIONAL SOFTWARE CORPORATION. Gerenciamento de Configuração e
Mudança: Conceitos. 2001. Disponível em <
http://www.funpar.ufpr.br:8080/rup/process/workflow/conf_mgt/cos_cm.htm> Acesso
em 15 abr. 2015
57
RATIONAL UNIFIED PROCESS. Gerência de Configuração e Mudanças.
<http://www.wthreex.com/rup/v711_sp_ptbr/index.htm> Acesso em 12 abr. 2015
RATIONAL UNIVERSITY. Rational Unified Process Fundamentals (Apostila de
Curso). 2002.
SILVA, Maurício S. JavaScript: Guia do Programador. 1 ed. São Paulo: Novatec
Editora, 2010.
THE APACHE SOFTWARE FUNDATION. Apache Tomcat. 1999. Disponível em <
http://tomcat.apache.org/> Acesso em 02 mai. 2015.
.
