INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E...
Transcript of 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
ELAINE CRISTINA DOS SANTOS RAMOS
PATRICK PINTO PINHEIRO
DESENVOLVIMENTO DE UMA APLICAÇÃO WEB PARA GESTÃO DE
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
Campos dos Goytacazes / RJ
2016
ELAINE CRISTINA DOS SANTOS RAMOS
PATRICK PINTO PINHEIRO
DESENVOLVIMENTO DE UMA APLICAÇÃO WEB PARA GESTÃO DE
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
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
Profª Ana Silvia Ribeiro Escocard Santigado
Mestre em Pesquisa Operacional e Inteligência Artificial - UCAM/Campos
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
Campos dos Goytacazes / RJ
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.
• Requisitos: REQ02
• Regras de Negócios: RN01, RN02, RN03, RN04, RN05, RN07, RN08, RN09 e
RN10
• Ator: Usuário
• Cenário Principal:
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.
• Requisitos: REQ03
• Regras de Negócios: RN03 e RN04
• Ator: Usuário
• Cenário Principal:
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
4. O usuário clica no botão salvar.
5. O sistema valida os dados do requisito e salva.
6. O sistema exibe a tela Projetos Criados (figura 17).
• Cenário Alternativo 01 - Usuário necessita editar o requisito 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 Requisitos (figura 18).
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 6 do Cenário Principal.
• Cenário Alternativo 02 - Usuário necessita excluir o requisito 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 requisito.
5. O sistema retorna ao passo 6 do Cenário Principal.
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.
• Requisitos: REQ04
• Regras de Negócios: RN05 e RN06
• Ator: Usuário
• Cenário Principal:
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.
4. O usuário clica no botão salvar.
5. O sistema valida os dados da regra de negócios e salva.
6. O sistema exibe a tela Projetos Criados (figura 17).
• Cenário Alternativo 01 - Usuário necessita editar a regra de negócio 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 Regra de Negócios (figura 19).
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 6 do Cenário Principal.
• Cenário Alternativo 02 - Usuário necessita excluir a regra de negócio a par-
tir 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 a regra de negócio.
5. O sistema retorna ao passo 6 do Cenário Principal.
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.
• Requisitos: REQ05
• Regras de Negócios: RN07 e RN08
• Ator: Usuário
26
• Cenário Principal:
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.
4. O usuário clica no botão salvar.
5. O sistema valida os dados do diagrama e salva.
6. O sistema exibe a tela Projetos Criados (figura 17).
• Cenário Alternativo 01 - Usuário necessita editar o diagrama a partir do
passo 6 do Cenário Principal:
1. O usuário clica no botão editar.
2. O sistema exibe a tela Cadastrar Diagrama (figura 21).
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 6 do Cenário Principal.
• Cenário Alternativo 02 - Usuário necessita excluir o diagrama 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 excluir o diagrama.
5. O sistema retorna ao passo 6 do Cenário Principal.
• 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.
• Requisitos: REQ06
• Regras de Negócios: RN09 e RN10
• Ator: Usuário
• Cenário Principal:
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.
4. O usuário clica no botão salvar.
5. O sistema valida os dados do glossário e salva.
6. O sistema exibe a tela Projetos Criados (figura 17).
• Cenário Alternativo 01 - Usuário necessita editar o glossário a partir do
passo 6 do Cenário Principal:
1. O usuário clica no botão editar.
2. O sistema exibe a tela Cadastrar Glossário (figura 20).
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 6 do Cenário Principal.
• Cenário Alternativo 02 - Usuário necessita excluir o glossário 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 glossário.
5. O sistema retorna ao passo 6 do Cenário Principal.
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.
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.
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/.