instituto federal de educaÇÃo, ciÊncia e...

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA FLUMINENSE

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS

ELAINE CRISTINA DOS SANTOS RAMOS

PATRICK PINTO PINHEIRO

DESENVOLVIMENTO DE UMA APLICAÇÃO WEB PARA GESTÃO DE

REQUISITOS

Campos dos Goytacazes / RJ

2016




REQUISITOS

Trabalho de conclusão de curso apresen-tado ao Instituto Federal Fluminense, comoparte dos requisitos necessários para a con-clusão do Curso Superior de Tecnologia emAnálise e Desenvolvimento de Sistemas eobtenção do título de Analista de Sistemas.

Orientadora: Cibelle Degel Barbosa


2016




REQUISITOS

Trabalho aprovado. Campos dos Goytacazes / RJ, 01 de Julho de 2016:

Profª. Cibelle Degel Barbosa (Orientadora)

Doutora em Produção Vegetal / Universidade Estadual do Norte Fluminense – UENF

Instituto Federal de Educação, Ciência e Tecnologia Fluminense

Profº Breno Fabrício Terra Azevedo

Doutor em Informática na Educação/UFRGS


Profª Ana Silvia Ribeiro Escocard Santigado

Mestre em Pesquisa Operacional e Inteligência Artificial - UCAM/Campos



2016

Eu, Elaine, agradeço a Deus por ter chegado até aqui e dedico este trabalho a minha

mãe Antônia por todo sacrifício e dedicação à minha educação e em especial ao meu

marido Martinho, que foi muito importante me dando força e coragem e me apoiando

nos momentos de dificuldades não me deixando desistir em nenhum momento.

Eu, Patrick, dedico este árduo trabalho, unicamente a pessoa mais importante da

minha vida, minha mãe Ledimar (Ciquinha, como todos a chamam). Sem sombra de

dúvidas ela foi meu maior apoio, incentivo nos estudos e quem me fez sempre lutar

pelos meus sonhos.

Agradecimentos

Nossos sinceros agradecimentos primeiramente a Deus por toda a sabedoria e

força diante da realização desta pesquisa.

Aos nosso familiares, base de tudo. Se hoje estamos concluindo esta graduação,

eles foram a parte fundamental de todo apoio e incentivo.

À nossa orientada Cibelle que, em todos os momentos, esteve presente nos

auxiliando e avaliando nosso trabalho com críticas construtivas e estimulando a sua

conclusão.

Aos nossos queridos amigos de faculdade pela imensa e importante ajuda

em partes mais técnicas, sugerindo, critincando de forma a melhorar este trabalho e

também pelo incentivo e apoio.

Aos professores Breno e Ana Silvia que aceitaram fazer parte deste momento

tão especial que é conclusão de um curso superior.

Enfim, à todos, um muito obrigado.

“Dificuldades preparam pessoas comuns para

destinos extraordinários.” C.S. Lewis

Resumo

Esta pesquisa tem como principal objetivo o desenvolvimento de uma aplicação WEB

para o gerenciamento de requisitos de software capaz de reunir, em um único ambiente,

toda a documentação referente aos dados coletados do Cliente e modelados pelo

profissional de análise de sistemas, tais como regras de negócio, requisitos, imagens

de diagramas diversos e o glossário. Utilizando recursos ágeis e tecnológicos para

o desenvolvimento, o projeto abrange o uso da linguagem de programação Ruby

juntamente com o framework Rails, ambos voltados para a programação WEB. E

ainda, recursos de interface como o Bootstrap que, por sua vez, é utilizado como

aliado ao HTML. Todo o armazenamento ficou sob a responsabilidade do banco de

dados nativo do Ruby, o Sqlite. O que se almejou na ferramenta, especificamente em

seu desenvolvimento, foi a simplicidade da aplicação, tornando-a capaz de oferecer

ao usuário final uma ferramenta de fácil uso e manuseio para o armazenamento de

informações referentes ao desenvolvimento de outros sistemas.

Palavras-chave: Ruby; Rails; Análise de Sistemas.

Abstract

This research aims to develop a WEB Application for managing software require-

ments able to gather in a single environment, all documentation related to the data

collected from the customer and modeled by systems analysis professional, such as

rules business requirements, images of various diagrams and glossary. Using agile

and technological resources for development, the project covers the use of the Ruby

programming language with the Rails framework, both facing the WEB programming.

Also, interface features such as the Bootstrap which, in turn, is used as combined

with HTML. The entire storage was under the responsibility of native database Ruby,

the Sqlite. What craved the tool, specifically in its development, was the simplicity of

the application, making it able to offer the end user an easy use and handling tool for

information storage for the development of other systems.

Keywords: Ruby; Rails; Systems Analysis.

Lista de ilustrações

Figura 1 – Arquitetura MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figura 2 – Estrutura do Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figura 3 – Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . 21

Figura 4 – Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figura 5 – Criando uma RVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figura 6 – Criando o projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figura 7 – Estrutura de um projeto em Ruby on Rails . . . . . . . . . . . . . . . 30

Figura 8 – Exemplo da criação da tabela Projetos referenciando a tabela User 31

Figura 9 – Estrutura do Arquivo Routers . . . . . . . . . . . . . . . . . . . . . . 32

Figura 10 – Validação da folha de estilo . . . . . . . . . . . . . . . . . . . . . . . 33

Figura 11 – Página inicial da aplicação . . . . . . . . . . . . . . . . . . . . . . . . 34

Figura 12 – Tela de autenticação de usuário . . . . . . . . . . . . . . . . . . . . 34

Figura 13 – Tela de criaçao de novo usuário . . . . . . . . . . . . . . . . . . . . 35

Figura 14 – Tela de gerenciamento de projetos . . . . . . . . . . . . . . . . . . . 35

Figura 15 – Tela de índice de projetos . . . . . . . . . . . . . . . . . . . . . . . . 36

Figura 16 – Tela de cadastro de projeto . . . . . . . . . . . . . . . . . . . . . . . 36

Figura 17 – Tela do projeto criado . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figura 18 – Tela de cadastro de requisitos . . . . . . . . . . . . . . . . . . . . . . 38

Figura 19 – Tela de cadastro de regra de negócio . . . . . . . . . . . . . . . . . 38

Figura 20 – Tela de cadastro de glossário . . . . . . . . . . . . . . . . . . . . . . 39

Figura 21 – Tela de cadastro de diagrama . . . . . . . . . . . . . . . . . . . . . . 39

Figura 22 – Tela de projeto criada e formulários preenchidos . . . . . . . . . . . 40

Figura 23 – Visualização de diagrama . . . . . . . . . . . . . . . . . . . . . . . . 41

Lista de abreviaturas e siglas

CSS Cascading Style Sheets

HTML Hypertext Markup Language

JSF JavaServer Faces

MPS.Br Melhoria de Processos de Software Brasileiro

MVC Model, View and Controller

PMBOK Project Management Body of Knowledge

RVM Ruby Version Manager

UML Unified Modeling Language

URL Uniform Resource Locator

W3C World Wide Web Consortium

XML Extensible Markup Language

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Aplicações WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6 Trabalhos Semelhantes . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 MODELAGEM DO SISTEMA . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Regras de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Diagrama e Descrição dos Casos de Uso . . . . . . . . . . . . . . . . 20

3.3.1 Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2 Caso de Uso Manter Usuário . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.3 Caso de Uso Manter Projeto . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.4 Caso de Uso Manter Requisito . . . . . . . . . . . . . . . . . . . . . . 23

3.3.5 Caso de Uso Manter Regra de Negócio . . . . . . . . . . . . . . . . . 24

3.3.6 Caso de Uso Manter Imagens de Diagrama . . . . . . . . . . . . . . 25

3.3.7 Caso de Uso Manter Glossário . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Ferramentas e Recursos . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Criação do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Interface do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

APÊNDICES 45

APÊNDICE A – Instalação do Ruby on Rails . . . . . . . . . . . . . 46

12

1 INTRODUÇÃO

A busca por soluções de tecnologia da informação, que visam facilitar o cotidiano

da sociedade, tem sido um dos grandes desafios de desenvolvedores e profissionais

da área. Em análise de software é identificado uma gama de informações que precisam

ser organizadas e acessíveis de forma rápida, íntegra e com máxima precisão.

Diante desse cenário, esta pesquisa faz uma abordagem, no quesito desenvol-

vimento, sobre o Ruby. Trata-se de uma linguagem dinâmica, de código aberto com

foco na simplicidade e na produtividade. Segundo Fernandez (2008), o código Ruby é

mais fácil de ler e escrever, porque ele é mais delimitado para manter o domínio dos

problemas encontrados, em um estilo que está mais próximo da linguagem humana.

Este projeto enfatiza o levantamento de requisitos, uma vez que ele é uma

parte importante em um processo de desenvolvimento de software. Conseguir entender

exatamente aquilo que o Cliente deseja e documentar de forma correta e organizada, é

um fator determinante para o sucesso em uma Engenharia de Requisitos.

O presente trabalho está dividido em 5 capítulos, já incluindo esta Introdução.

O capítulo 1 também expõe o objetivo da pesquisa, o capítulo 2 apresenta todo o

embasamento teórico utilizado neste projeto. Coube aos capítulos 3 e 4 a modelagem

do sistema e metodologia utilizada, respectivamente. A conclusão ficou exposta no

capítulo 5 em conjunto com a proposta de trabalhos futuros.

1.1 Objetivo

Este estudo possui como principal objetivo, prover uma solução WEB que

auxilie no armazenamento de informações colhidas, organizadas e interpretadas por

meio da análise de requisitos para o desenvolvimento de um software. Dentre suas

características, destaca-se a documentação de todo o projeto em um único ambiente.

Seguindo essa linha, é possível obter uma análise organizada, visualmente clara e com

a possibilidade de consulta, edição e adição nas análises consolidadas.

Dessa forma, o sistema mantém os usuários e seus projetos. Os projetos serão

compostos pelos requisitos, regras de negócio, imagens de diagramas e glossários.

Todos os itens citados deverão ser mantidos pelo usuário, previamente cadastrado no

sistema, contando com uma tecnologia de autenticação e encriptação de senha.

13

1.2 Justificativa

A pesquisa elaborada visa desenvolver uma aplicação de gestão de análises

de software fazendo uso de tecnologias modernas e fáceis de utilizar, auxiliando o

desenvolvedor e facilitando o seu trabalho.

Quanto às funcionalidades, o software é capaz de oferecer ao usuário final um

ambiente de fácil uso, simples e compacto para o armazenamento de todos os dados.

Diante do exposto, este trabalho se justifica como um auxílio aos profissionais

da área de TI quanto à documentação de forma mais prática.

14

2 REFERENCIAL TEÓRICO

Este capítulo apresenta a fundamentação teórica utilizada neste projeto, visando

um maior entendimento e conhecimento das tecnologias e metodologias utilizadas.

2.1 Aplicações WEB

A evolução da Internet possibilitou o surgimento de aplicações WEB com recur-

sos semelhantes aos de aplicações desktop (SUPPI, 2012).

Kappel et al. (2006) explica que uma aplicação WEB trata-se de um sistema

de software que fornece recursos, como conteúdo e serviços, voltados para interação

usuário e browser WEB.

Pressman (2011) define as aplicações para WEB como “WebApps” e destaca a

sua simplicidade por intermédio de texto e informações gráficas com poucos recursos.

Porém, com a popularidade da WEB 2.0, ocorreu um grande avanço dessas aplicações,

que não só se restringem a modernos ambientes, mas oferecendo recursos avançados

ao usuário final, desde integração com bancos de dados até incorporando sistemas

comerciais.

2.2 UML

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é

uma linguagem de modelagem e não deve ser confundida com linguagem de programa-

ção. Segundo Guedes (2011), este tipo de linguagem é usado para modelar softwares

que seguem a linha “orientado a objeto”.

Guedes (2011) retrata tal modelagem como uma notação, cujo objetivo é servir

de base, para profissionais de engenharia de software definirem as características de

uma aplicação, analisando o seu comportamento desde requisitos, estrutura lógica e

dinâmica dos processos, até necessidades físicas na qual o software será implantado.

Para Booch, Jacobson e Rumbaugh (2006) uma empresa desenvolvedora de

software de sucesso é vista como aquela com a capacidade de entender e suprir as

necessidades de seus clientes. Ele afirma que um software bem desenvolvido capaz

de atender os requisitos propostos constitui uma parte primária, deixando os demais

itens como secundários. Para isso, uma boa equipe, ferramentas de qualidade e foco

são as premissas necessárias para uma boa codificação.

Em relação a representações gráficas, a UML mostra os seus vários aspectos

através de diversos tipos de diagramas. Furlan (1998) descreve um diagrama como uma

15

representação gráfica de um agrupamento de elementos de um modelo, exemplificado

como um gráfico conectado com arcos (em analogia aos relacionamentos) e vértices

(em analogia a outros elementos do modelo).

Melo (2011) explica que há duas categorias de diagramas: diagramas estruturais

ou estáticos e digramas comportamentais ou dinâmicos. Os estruturais têm por objetivo

representar as características que não sofrem modificação ao longo do tempo, cabendo

às representações comportamentais desempenhar o papel de demonstrar como o

sistema atua e responde às requisições e exibem tal evolução no decorrer do tempo.

Nesta pesquisa foram utilizados dois tipos de diagramas da UML para a reali-

zação da modelagem: diagrama de classes que se enquadra na categoria estático e

diagrama de caso de uso, representando a categoria comportamental.

2.3 Ruby

O Ruby é uma linguagem de programação que surgiu no Japão 1993, referenci-

ando o seu criador, Yukihiro Matsumoto e se tornou pública em 1995 (WILLIANS, 2007).

Por se tratar de uma linguagem multiplataforma, é comumente comparada com outras

linguagens como Perl e Python (COLLINGBOURNE, 2006).

Essa linguagem caracteriza-se por ser dinâmica, orientada a objeto possuir ca-

racterísticas funcionais. A proposta de seu criador, almejava uma linguagem que unisse

programação funcional com a imperatividade, sem perder o foco que era construir um

código legível (SOUZA, 2012).

Parte importante da linguagem, o RubyGems é retratado por Berube (2007)

como um sistema que gerencia pacotes para a linguagem Ruby e bibliotecas. Ele

permite a instalação e execução de outros pequenos trechos de código em Ruby na qual

é chamado de gems. Berube (2007) exemplifica o uso dessa tecnologia mencionando a

necessidade de um usuário em redimensionar fotos após a realização de upload. Toda

essa codificação poderia ser realizada manualmente, porém a instalação de uma gem

específica para tal serviço torna esse método mais rápido.

2.4 Rails

O Rails foi desenvolvido utilizando um modelo de arquitetura conhecida como

Model-View-controller (MVC). Este tipo de arquitetura define os modelos de dados, inter-

face de usuário e controlador lógico de um sistema, transformando-os em componentes

separados (WILLIANS, 2007)

Minetto (2007) destaca que a grande vantagem na utilização desse tipo de

arquitetura é separar a parte lógica da aplicação da parte de visualização. Dessa forma,

16

um trabalho realizado por uma equipe é favorecido, podendo um designer trabalhar

com o HTML e o CSS sem intervir no modelo da aplicação e sem comprometer as

regras de negócio dos controllers.

As três camadas dessa arquitetura são definidas conforme Figura 1. Em um

simples exemplo de um usuário requisitando a edição de um recurso “room”, Fuentes

(2014) acrescenta e explica a responsabilidade do router que é realizar o mapeamento

de rotas, ou seja, comunicar ao Rails quais URLs estão acessíveis e qual o controller

deverá ser requisitado.

Figura 1 – Arquitetura MVC

Para Fuentes (2014), o modelo MVC define a arquitetura interna do framework

e descreve as três camadas como:

• O Modelo é a camada que possui duas incumbências distintas: persistir os dados

da aplicação em um ou mais banco de dados e definir e aplicar as regras de

negócios do sistema.

17

• A camada de Apresentação possui o propósito de mostrar as ações dos resultados

e dados, utilizando uma interface HMTL com a tecnologia CSS ou até mesmo

representação em formato XML.

• O Controle é a camada que fica interposta entre a aplicação e a WEB. Ele atua

como um tradutor das informações advindas da interface WEB que podem ser

formulários ou até mesmo preceitos na URL e as envia para camada Model para

que a mesma realize suas funções. Com as soluções definidas, o controlador as

remete para a camada View.

2.5 Bootstrap

Spurlock (2013) define o bootstrap como um framework front-end e de código

livre cujo objetivo é a criação de websites responsivos. Essa facilidade permite a

junção de JavaScript, CSS e HTML contribuindo para o desenvolvimento de sites mais

exigentes sem a adição de uma codificação mais extensa.

A Estrutura do bootstrap pode ser visualizada conforme Figura 2 demonstrada

por Spurlock (2013):

Figura 2 – Estrutura do Bootstrap

O download do Bootstrap é composto por três pastas: css, js e img. Com o

objetivo de simplificar o desenvolvimento, estes arquivos são adicionados na raiz do

projeto (SPURLOCK, 2013).

18

2.6 Trabalhos Semelhantes

Existem alguns programas desenvolvidos e que possuem objetivos próximos

ao que é proposto nesta pesquisa. Os trabalhos são: “Aplicativo WEB com JSF 2.0 e

PrimeFaces para o Gerenciamento de Requisitos de Software” (COL; NESELLO, 2014);

“Software de Controle e Gerenciamento de Documentos de Projetos” (LUIZ, 2009) e

“Fermine como ferramenta de apoio à implantação do nível G do MPS.Br” (CINDRA et

al., 2010).

A aplicação web desenvolvida por COL e NESELLO (2014) visou a construção

de um software para o gerenciamento de requisitos de software utilizando a plaforma

JSF juntamente com biblioteca PrimeFace, retradado pelos autores como um framework

de código aberto. O banco de dados utilizado foi o MySQL.

Luiz (2009) abordou conceitos do PMBOK para o desenvolvimento de uma

aplicação capaz de manter projetos quanto ao seu cronograma, prazos e entregá-

veis. A UML foi utilizada como metodologia para a pesquisa e a linguagem JAVA como

codfificação do software. Todo o armazemento do sistema ficou sob responsabilidade

do MySQL.

Referenciando a pesquisa realizada por alunos do Instituto Federal Fluminense,

diferente dos demais trabalhos citados, desenvolveram um plugin para que o mesmo

fosse utilizado no Redmine, ferramenta já existente que possui como objetivo realizar

o gerenciamento de tarefas de projetos, sendo a mesma desenvolvida utilizando a

tecnologia Ruby on Rails.

Fermine, nome dado à extensão desenvolvida que, antes seria uma aplicação,

foi incorporada ao Redmine. Cindra et al. (2010) explicam que ela é capaz de manter

um repositório único de artefatos da engenharia de requisitos e incorporar a criação de

tarefas automáticas no Redmine com o objetivo que todo requisito inserido no sistema

gerasse uma tarefa para o gerente do projeto. Essa premissa foi capaz de atender não

somente a gerência de requisitos, como também a gerência de projetos adequanto

todo o fluxo ao nível G do MPS.Br (Melhoria de Processos de Software Brasileiro)

Diante das pesquisas similares expostas, o diferencial deste trabalho fica mais

nítido quando se compara as tecnologias utlizadas. A escolha do Ruby on Rails como

linguagem de programação atual, flexível e voltada para WEB, bem como o banco de

dados já incorporado, torna este desenvolvimento de aplicação mais simples. Voltado

para públicos semelhantes dos trabalhos citados, a simplicidade de interface e usabili-

dade fazem do “CADProject”, nome dado à aplicação, uma ferramenta de auxílio desde

o público mais iniciante.

19

3 MODELAGEM DO SISTEMA

A aplicação desenvolvida, nomeada “CADProject”, oferecerá suporte a profissio-

nais e alunos da área de tecnologia da informação quanto à coleta de dados de análise

de software mantendo-os agrupados e disponibilizados em um único ambiente.

O sistema mantém os usuários e seus projetos. Os projetos serão compostos

pelos requisitos, regras de negócio, imagens de diagramas e glossários. Todos os

itens citados deverão ser mantidos pelo usuário, previamente cadastrado no sistema,

contando com uma tecnologia de autenticação e encriptação de senha.

Neste capítulo serão apresentadas as funcionalidades da aplicação, requisitos

funcionais, regras de negócio e os diagramas de classe e caso de uso.

3.1 Requisitos

O sistema CADProject possui seis requisitos definidos. São eles:

• REQ01: O sistema deve permitir a manutenção de usuário com os campos: e-mail

e senha.

• REQ02: O sistema deve permitir a manutenção do projeto com os campos: nome

e mini mundo.

• REQ03: O sistema deve permitir a manutenção dos requisitos com os campos:

sigla, nome, descrição, tipo e prioridade.

• REQ04: O sistema deve permitir a manutenção das regras de negócio com os

campos: sigla, nome e descrição.

• REQ05: O sistema deve permitir a manutenção das imagens dos diagramas com

os campos: nome, tipo e arquivo.

• REQ06: O sistema deve permitir a manutenção do glossário com os campos: sigla

e descrição.

3.2 Regras de Negócio

As regras de negócio dos sistema são listadas abaixo:

• RN01 - O usuário deve estar associado a um ou mais projetos.

• RN02 - O projeto deve estar associado a somente um usuário.

20

• RN03 - O projeto deve estar associado a um ou mais requisitos.

• RN04 - O requisito deve estar associado a somente um projeto.

• RN05 - O projeto deve estar associado a uma ou mais regras de negócio.

• RN06 - A regra de negócio deve estar associada a somente um projeto.

• RN07 - O projeto deve estar associado a um ou mais diagramas.

• RN08 - O diagrama deve estar associado a somente um projeto.

• RN09 - O glossário deve estar associado a somente um projeto.

• RN10 - O projeto deve estar associado um ou mais glossários.

• RN11 - O usuário deve se cadastrar antes de iniciar um projeto.

• RN12 - A senha de acesso ao sistema deverá conter 8 caracteres alfanuméricos.

• RN13 - O sistema só permitirá acesso aos dados após autenticação.

3.3 Diagrama e Descrição dos Casos de Uso

Neste capítulo é apresentado o diagrama de caso de uso do sistema bem como

a descrição de cada caso.

3.3.1 Diagrama de Caso de Uso

Abaixo é apresentado o diagrama de caso de uso do sistema, formado por um

único ator, o usuário:

21

Figura 3 – Diagrama de Caso de Uso

3.3.2 Caso de Uso Manter Usuário

• Descrição: O sistema deve permitir a manutenção de usuário com os campos:

e-mail e senha.

• Requisitos: REQ01

• Regras de Negócios: RN11, RN12 e RN13

• Ator: Usuário

• Cenário Principal:

1. Na tela inicial do sistema (figura 11), o usuário clica no botão login.

2. O sistema exibe a tela de Login (figura 12).

3. O usuário digita e-mail e senha e clica no botão login.

4. O sistema verifica e validade do e-mail e da senha.

5. O sistema exibe a tela de Gerenciamento (figura 14).

• Cenário Alternativo 01 - Novo Usuário a partir do passo 2 do cenário princi-

pal:

1. O usuário clica na opção Novo usuário.

22

2. O sistema exibe a tela de Cadastro de Usuário (figura 13).

3. O usuário preenche os campos e-mail, senha e confirmar senha.

4. O usuário clica no botão criar usuário.

5. O sistema valida o e-mail e a senha criada pelo usuário.

6. O sistema retorna ao passo 5 do cenário principal.

3.3.3 Caso de Uso Manter Projeto

• Descrição: O sistema deve permitir a manutenção do projeto com os campos:

nome e minimundo.


• Regras de Negócios: RN01, RN02, RN03, RN04, RN05, RN07, RN08, RN09 e

RN10

• Ator: Usuário


1. Na tela de Gerenciamento (figura 14), o usuário clica no botão criar projeto.

2. O sistema exibe a tela de Cadastrar Projeto (figura 16).

3. O usuário preenche os campos nome do projeto e mini mundo.

4. O usuário clica no botão salvar.

5. O sistema valida os dados do projeto e salva.

6. O sistema exibe a tela Projetos Criados (figura 17).

• Cenário Alternativo 01 - Usuário necessita editar o projeto a partir do passo

6 do Cenário Principal:

1. O usuário clica no botão editar.

2. O sistema exibe a tela de Cadastrar Projeto (figura 16).

3. O usuário realiza as edições necessárias e clica no botão salvar.

4. O sistema valida as edições feitas pelo usuário.

5. O sistema retorna ao passo 5 do cenário principal.

23

• Cenário Alternativo 02 - Usuário necessita excluir o projeto a partir do

passo 6 do Cenário Principal:

1. O usuário clica no botão excluir.

2. O sistema exibe a mensagem “Você tem certeza?”.

3. O usuário clica no botão OK.

4. O sistema exclui o projeto.

5. O sistema exibe a tela Meus Projetos (Figura 15).

6. O usuário clica no botão voltar.

7. O sistema retorna ao passo 1 do Cenário Principal.

• Cenário Alternativo 03 - Usuário necessita gerenciar seus projetos:

1. Na tela de Gerenciamento (figura 14), o usuário clica no botão gerenciar projetos.

2. O sistema exibe a tela Meus Projetos (figura 15).

3. O usuário clica no botão abrir.

4. O sistema exibe a tela Projetos Criados (figura 17) e mostra o projeto criado com

sua as informações.

3.3.4 Caso de Uso Manter Requisito

• Descrição: O sistema deve permitir a manutenção dos requisitos com os campos:

sigla, nome, descrição, tipo e prioridade.


• Regras de Negócios: RN03 e RN04

• Ator: Usuário


1. Na tela de Projetos Criados (figura 15), o usuário clica no botão criar requisito.

2. O sistema exibe a tela de Cadastrar Requisitos (figura 18).

3. O usuário preenche os campos sigla do requisito, nome do requisito, descrição

do requisito, tipo do requisito e prioridade.

24


5. O sistema valida os dados do requisito e salva.


• Cenário Alternativo 01 - Usuário necessita editar o requisito a partir do



2. O sistema exibe a tela de Cadastrar Requisitos (figura 18).




• Cenário Alternativo 02 - Usuário necessita excluir o requisito a partir do





4. O sistema exclui o requisito.


3.3.5 Caso de Uso Manter Regra de Negócio

• Descrição: O sistema deve permitir a manutenção das regras de negócios com

os campos: sigla, nome e descrição.



• Ator: Usuário


1. Na tela Projetos Criados (figura 17), o usuário clica no botão criar regra de

negócio.

25

2. O sistema exibe a tela de Cadastrar Regra de Negócios (figura 19).

3. O usuário preenche os campos sigla da regra, nome da regra e descrição.


5. O sistema valida os dados da regra de negócios e salva.


• Cenário Alternativo 01 - Usuário necessita editar a regra de negócio a partir

do passo 6 do Cenário Principal:


2. O sistema exibe a tela de Cadastrar Regra de Negócios (figura 19).




• Cenário Alternativo 02 - Usuário necessita excluir a regra de negócio a par-

tir do passo 6 do Cenário Principal:




4. O sistema exclui a regra de negócio.


3.3.6 Caso de Uso Manter Imagens de Diagrama

• Descrição: O sistema deve permitir a manutenção das imagens dos diagramas

com os campos: nome, tipo e arquivo.



• Ator: Usuário

26


1. Na tela Projetos Criados (figura 17), o usuário clica no botão criar diagrama.

2. O sistema exibe a tela de Cadastrar Diagrama (figura 21).

3. O usuário preenche os campos nome do diagrama, tipo do diagrama e arquivo.


5. O sistema valida os dados do diagrama e salva.


• Cenário Alternativo 01 - Usuário necessita editar o diagrama a partir do



2. O sistema exibe a tela Cadastrar Diagrama (figura 21).




• Cenário Alternativo 02 - Usuário necessita excluir o diagrama a partir do





4. O sistema excluir o diagrama.


• Cenário alternativo 03 - Usuário necessita visualizar a imagem do diagrama

a partir do passo 6 do Cenário Principal:

1. O usuário clica no botão visualizar diagrama.

2. O sistema exibe a tela Visualização do Diagrama (figura 23).

3. O usuário clica no botão voltar se desejar retornar ao passo 6 do Cenário Principal.

27

3.3.7 Caso de Uso Manter Glossário

• Descrição: O sistema deve permitir a manutenção do glossário com os campos:

sigla e descrição.



• Ator: Usuário


1. Na tela projetos Criados (figura 17), o usuário clica no botão criar glossário.

2. O sistema exibe a tela Cadastrar Glossário (figura 20).

3. O usuário preenche os campos sigla e descrição.


5. O sistema valida os dados do glossário e salva.


• Cenário Alternativo 01 - Usuário necessita editar o glossário a partir do



2. O sistema exibe a tela Cadastrar Glossário (figura 20).




• Cenário Alternativo 02 - Usuário necessita excluir o glossário a partir do





4. O sistema exclui o glossário.


28

3.4 Diagrama de Classes

O diagrama de classes apresentado na figura 4 é representado por uma estrutura

1 para N, totalizando seis tabelas.

Figura 4 – Diagrama de Classes

29

4 METODOLOGIA

Neste capítulo será apresentado todo o processo realizado no desenvolvimento

da aplicação WEB proposta para a gestão de requisitos. Esse processo vai desde a utili-

zação das ferramentas apropriadas para a construção do programa até a demonstração

das telas para o usuário final.

4.1 Ferramentas e Recursos

Visando desenvolver um software que atendesse às necessidades atuais de

tecnologias, o Ruby foi a linguagem de programação escolhida para esta pesquisa uma

vez que é voltada para aplicações WEB, de fácil codificação devido à integração com a

arquitetura MVC através do framework Rails e a possibilidade de trabalho com outras

funcionalidades através das gems.

O processo de instalação do ambiente de programação deu-se em duas etapas:

instalação do Ruby e a instalação do Rails. Essa integração oferece um ambiente

completo para o desenvolvimento de aplicações WEB, podendo ser acrescido de

diversas funções.

Fazendo uso do recurso RubyGems, foi realizada a criação de um ambiente

virtual chamado RVM, através da instalação de uma gem para tal uso. Esse recurso

permite gerar ambientes atendendo à necessidade de criação de projetos distintos

que utilizam gems específicas sem que haja incompatibilidade entre eles. A Figura 5

demonstra a criação de uma RVM com o nome “appweb_tcc”:

Figura 5 – Criando uma RVM

4.2 Criação do Projeto

Com o Rails e Ruby instalados e a RVM criada, o primeiro passo foi criar o

projeto propriamente dito. Utilizando um simples comando no terminal foi possível criar

uma estrutura de projeto. Nas figuras 6 e 7 é possível identificar esse comando e a

respectiva estrutura criada em consequência à sua execução.

30

Figura 6 – Criando o projeto

Figura 7 – Estrutura de um projeto em Ruby on Rails

31

Além de uma estrutura de pastas, o Rails gera um arquivo importante na raiz do

projeto: Gemfile. Este arquivo é responsável por armazenar todas as gems utilizadas

no projeto, bem como o framework Rails. Abaixo, segue a descrição de cada pasta na

qual teve interação de desenvolvimento:

• app: nesta pasta, estão contidas as pastas models, views e controllers, integrantes

da arquitetura MVC, bem como a pasta “assets”, responsável pelo CSS.

• bin: armazenas arquivos importantes na inicialização do Rails.

• config: contêm parâmetros de configuração tanto do projeto quanto do banco de

dados.

• db: contêm todas as migrações referente ao banco de dados. Neste projeto foi

utilizado o banco de dados “sqlite”, uma vez que o mesmo atende a necessidade

do software e é nativo no Ruby.

Os demais arquivos e pastas foram utilizados com a configuração padrão do

Ruby.

O projeto consta com uma estrutura vomposta por seis tabelas conforme di-

agrama de classes apresentado no capítulo 3.4. Para realizar as ligações entre as

tabelas, foi executado o comando para gerar formulários juntamente com os campos

e seus respectivos tipos. Todas as tabelas, com exceção do formulário User foram

criadas com referências entre si no ato de cada geração conforme Figura 8:

Figura 8 – Exemplo da criação da tabela Projetos referenciando a tabela User

Uma das premissas do projeto é produzir um software em que o usuário pudesse

realizar uma autenticação. Para isso há duas formas: codificar tudo manualmente ou

utilizar uma gem para acelerar o processo e facilitar a implementação do recurso. Como

o objetivo é agilidade e praticidade e o Ruby permite isso, foi optado por usar uma gem

chamada devise.

O devise é uma solução versátil para autenticação com base na plataforma

Rails (PLATAFORMATEC, 2016). Sua tecnologia é composta por dez módulos, porém

apenas uma parcela dessas soluções foi utilizada no projeto.

Outra funcionalidade requerida pelo software foi a possibilidade de realizar o

upload de imagens. Este campo está presente no formulário Diagrama e, da mesma

32

forma empregada na autenticação de usuários, foi usada uma gem chamada paperclip.

Trata-se de uma biblioteca para tratamento de arquivos em forma de anexo. Possui

como pré-requisito a instalação do pacote “ImageMagick” cujo objetivo é realizar o

tratamento de imagens.

Para que o sistema associasse automaticamente um projeto à um usuário,

utilizamos o parâmetro “current_user” no arquivo “projetos_controller.rb” da pasta

“Controllers” para atribuir o ID do usuário com sessão corrente ao projeto no ato de sua

criação: “@projetos = @user.projetos [:current_user]”.

Para associar as tabelas Diagramas, Glossarios, Regras de Negocio e Requisi-

tos ao projeto criado foi utilizado o conceito de rotas encadeadas, o que faz com que as

tabelas dependentes do formulário Projetos recebam a chave estrangeira automatica-

mente no momento de sua criação. Na Figura 9 é apresentado o arquivo “Routers.rb”,

responsável por armazenar as rotas do sistema:

Figura 9 – Estrutura do Arquivo Routers

Essas associações permitem que apenas o usuário criador de um determinado

projeto possa visualizá-lo. O mesmo vale para a tabela de projetos que somente exibe

os itens com seu ID associado, criando uma espécie de partição.

4.3 Interface do Sistema

O Projeto foi desenvolvido utilizando os conceitos de HTML e CSS. O Bootstrap,

abordado no capítulo 3.5, foi utilizado com o intuito de reduzir a quantidade de código

nos arquivos da pasta Views, responsáveis pela interface do sistema.

O download da pasta contendo os arquivos do Bootstrap foi realizado a partir do

site oficial do desenvolvedor e utilizado apenas o arquivo “bootstrap.css”. Este arquivo

33

contêm todos os recursos para serem aplicados nos arquivos de HTML. Não foi feito o

uso do JavaScript no desenvolvimento.

Como o Boostrap baixado não ofereceu todos os recursos necessários, foi

criado outra folha de estilo nomeada de “style.css”. Neste arquivo foram criados novos

parâmetros de interface para adequação da interface gráfica.

O arquivo de CSS criado especificamente para o projeto foi validado no site

da W3C. O Consórcio World Wide Web (W3C) é um consórcio internacional no qual

organizações filiadas, uma equipe em tempo integral e o público trabalham juntos para

desenvolver padrões para a WEB (W3C, 2011).

Conforme Figura 10, a folha de estilo foi validada sem erros:

Figura 10 – Validação da folha de estilo

O acesso ao sistema é realizado através da URL http://localhost:3000/ e pode

ser acessada de qualquer navegador para desktop. A seguir, são apresentadas as telas

do software desenvolvido.

A página inicial da aplicação apenas possui o botão “Login”, cabendo ao

usuário apenas um clique para o direcionamento para a página do formulário “sign_in”,

conforme Figura 11.

34

Figura 11 – Página inicial da aplicação

A autenticação dar-se por intermédio do e-mail cadastrado e a senha. Caso o

usuário não possua cadastro no sistema, o mesmo poderá ser realizado através o link

“Novo Usuário”, conforme demonstra a Figura 12:

A tela exibida na Figura 13 demonstra a tela em decorrência do usuário não

possuir cadastro no sistema e clicar no link de “Novo Usuário”:

Figura 12 – Tela de autenticação de usuário

35

Figura 13 – Tela de criaçao de novo usuário

Com uma sessão ativa no sistema, o usuário é direcionado para a tela de geren-

ciamento, conforme Figura 14. Nesta visualização, o usuário conta com a presença de

dois botões: “Gerenciar Projetos”, que o direcionará para a tela de índice de projetos

de acordo com a Figura 15 e “Criar Projeto”, que irá gerar um novo projeto, em acordo

com a Figura 16:

Figura 14 – Tela de gerenciamento de projetos

36

Figura 15 – Tela de índice de projetos

Figura 16 – Tela de cadastro de projeto

A etapa inicial para a criação de um novo projeto demonstrada na Figura 16,

permite que o usuário crie um nome para o mesmo e vincule um mini mundo. Ao

clicar no botão “Salvar”, o sistema é direcionado para a tela onde serão inseridos os

requisitos, regras de negócio, imagens de diagramas e glossários conforme Figura 17:

37

Figura 17 – Tela do projeto criado

As telas referentes ao cadastro de requisitos, regras de negócio e glossários

são exibidas nas figuras 18, 19 e 20. O usuário apenas deverá preencher os campos

de cada formulário e clicar no botão “Salvar”. O botão “Salvar” irá armazenar os dados

e vinculá-los ao projeto corrente e, em seguida, retornar a tela principal do projeto.

A tela “Cadastrar Requisitos”, demonstrada na Figura 18, ainda conta com

suas opções de seleção: Tipo de requisito e Prioridade. O campo “Tipo do requisito”

permite o usuário classificar o requisito em “Funcional” ou “Não Funcional”. Já o campo

“Prioridade” exibe as possibilidade de definir a prioridade do requisito inserido em

“Baixa”, ”Média” e ”Alta”.

38

Figura 18 – Tela de cadastro de requisitos

Figura 19 – Tela de cadastro de regra de negócio

39

Figura 20 – Tela de cadastro de glossário

Utilizando a gem paperclip foi possível habilitar um botão para que o usuá-

rio pudesse selecionar um arquivo de imagem do disco local ou mídia removível e

armazená-la de forma correta no banco de dados para posterior visualização. A Figura

21 ilustra o formulário “Diagramas” com o campo nome do diagrama, a classificação

do tipo do diagrama em “Dinâmico” ou “Estático” e o botão para selecionar a imagem

a ser inserida. A opção de salvar oferece os mesmos recursos que os dos demais

formulários citados acima:

Figura 21 – Tela de cadastro de diagrama

Com todos os formulários preenchidos, o sistema exibe a tela de projetos com

40

as informações salvas no banco de dados, habilitando os botões “Editar” e “Excluir” em

cada item, conforme Figura 22:

Figura 22 – Tela de projeto criada e formulários preenchidos

Excepcionalmente, o formulário de Digramas exibe um botão chamado “Visuali-

zar Diagrama” e exibe as informações conforme evidenciado na Figura 23:

41

Figura 23 – Visualização de diagrama

Com todos os dados catalogados e armazenados, o sistema permite ao usuário

o controle sobre o projeto, podendo editá-lo para correções ou até mesmo para inclusão

de outros itens.

42

5 CONCLUSÃO

A partir da gama de tecnologias para WEB disponíveis atualmente, a escolha

da linguagem de programação Ruby para o desenvolvimento do software proposto,

proporcionou um ambiente flexível e de fácil utilização. O conceito MVC foi claramente

exposto e utilizado, confirmando a sua praticidade e facilitando o trabalho em equipe.

O Bootstrap aliado aos conceitos de HTML mostrou-se eficaz na agilidade de produção

de interface gráfica.

O trabalho evidenciou que o objetivo da pesquisa foi alcançado, fazendo uso

das tecnologias e metodologias contidas neste projeto. A possibilidade de se obter

informações de uma análise de software, em um único ambiente de forma clara,

demonstra o cumprimento dos esforços almejados. Trabalho que foi possível através

de recursos simples, porém com o auxílio de ferramentas poderosas.

O embasamento teórico adquirido durante a pesquisa abre um leque para

diversas novas funcionalidades e recursos, que ainda podem ser implantados, e que

são expostos a seguir.

5.1 Trabalhos Futuros

Durante o desenvolvimento da aplicação, foram identificadas melhorias e implan-

tação de novos recursos que podem ser aplicados em futuros trabalhos, na continuidade

dessa pesquisa:

• Inclusão do botão “Gerar PDF” na página principal do projeto para que o usuário

possa ter um relatório com todas as informações cadastradas;

• Criação de um módulo que permita o registro da especificação dos casos de uso

dos sistemas mantidos.

• Hospedagem na WEB da aplicação desenvolvida, facilitando a acessibilidade do

software;

• Cadastro de usuários utilizando os dados das principais redes sociais, permitindo

inclusive a expansão de informações de perfil.

43

Referências

BERUBE, D. Practical Ruby Gems. [S.l.]: Apress, 2007.

BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: Guia do Usuário. . Rua Sete deSetembro, 111 - 16° Andar, 20050-006 - Centro - Rio de Janeiro - RJ - Brasil: ElseverEditora Ltda., 2006.

CINDRA, J. S. et al. Fermine como ferramenta de apoio à implantação do nível G doMPS.Br. In: Congresso de Tecnologia da Informação. [S.l.: s.n.], 2010. v. 6. ISSN2447-5920.

COL, A. D.; NESELLO, F. A. APLICATIVO WEB COM JSF 2.0 E PRIMEFACES PARAGERENCIAMENTO DE REQUISITOS DE SOFTWARE. Dissertação (Monografia) —UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ CÂMPUS PATO BRANCO,Pato Branco, 2014.

COLLINGBOURNE, H. The Little Book of Ruby. 2006.

FERNANDEZ, O. THE RAILS WAY. Citeseer, 2008.

FUENTES, V. B. Ruby on Rails: Coloque sua aplicação web nos trilhos. [S.l.]: ACasa do Código, 2014.

FURLAN, J. D. Modelagem de Objetos através da UML – the Unified ModelingLanguage. São Paulo: Makron Books, 1998.

GUEDES, G. T. A. UML 2 - Uma Abordagem Prática . Segunda. São Paulo: Novatec,2011.

KAPPEL, G. et al. Web engineering. [S.l.]: John Wiley & Sons, 2006.

LUIZ, V. A. Software de Controle e Gerenciamento de Documentos de Projetos.Dissertação (Monografia) — Universidade Regional de Blumenau, Blumenau, 2009.

MELO, A. C. Desenvolvendo Aplicações com UML 2.2. [S.l.]: Brasport, 2011.

MINETTO, E. L. Frameworks para Desenvolvimento em PHP. São Paulo: Novatec,2007.

PLATAFORMATEC. Devise. 2016. Acesso em 28 Maio. 2016. Disponível em:<https://github.com/plataformatec/devise>.

PRESSMAN, R. S. Engenharia de Software: Uma abordagem profissional. 7. ed.Porto Alegre: McGraw Hill, 2011.

SOUZA, L. Ruby: Aprenda a programar a linguagem mais divertida. São Paulo: ACasa do Código, 2012.

SPURLOCK, J. Bootstrap. [S.l.]: O’Reilly Media, Inc., 2013.

SUPPI, L. F. P. DESENVOLVIMENTO DE APLICAÇÕES UTILIZANDO O FRAMEWORKZEND. REPOSITÓRIO DE RELATÓRIOS-Sistemas de Informação, v. 1, n. 2, 2012.

https://github.com/plataformatec/devise

44

W3C. Sobre o W3C. 2011. Acesso em: 24 Maio. 2016. Disponível em:<http://www.w3c.br/Sobre/.>

WILLIANS, J. Rails Solutions: Ruby on Rails Made Easy. 2007.

http://www.w3c.br/Sobre/.

Apêndices

46

APÊNDICE A – Instalação do Ruby on Rails

No terminal do Ubuntu, executar os comandos abaixo:

1. curl -sSL https://get.rvm.io | bash -s stable –rails;

2. curl -sSL https://rvm.io/mpapis.asc | gpg –import -;

3. sudo apt-get install ruby (requer acesso de administrador na estação);

4. gem install rvm;

5. rvm gemset create appweb;

6. gem install rails (executar dentro da RVM criada)

Copiar a pasta do projeto para um diretório a escolha do usuário e no terminal

navegar até a pasta do software. A partir deste ponto, executar os comandos abaixo:

1. bundle install;

2. rake db:migrate

Para executar o programa, siga os passos abaixo:

1. No terminal, executar o comando “rails s” e aguardar o servidor carregar;

2. No navegador de Internet, acessar a URL: http://localhost:3000/.

instituto federal de educaÇÃo, ciÊncia e...

Documents