Eduardos Gabriel PDF

UNIVERSIDADE DO SUL DE SANTA CATARINA
EDUARDO CLAUMANN NEIS
GABRIEL DIAS JUNCKES
FERRAMENTA WEB PARA MODELAGEM DE DIAGRAMAS UML COM

INTEGRAÇÃO À FERRAMENTA DESKTOP.
PALHOÇA
2014

INTEGRAÇÃO À FERRAMENTA DESKTOP
Trabalho de Conclusão de Curso apresentado

ao Curso de Graduação em Sistemas de
Informação da Universidade do Sul de Santa
Catarina, como requisito parcial à obtenção do
título de Bacharel em Sistemas de Informação.
Orientadora: Profª. Vera Rejane Niedersberg Schuhmacher, Msc.
Coorientador: Prof. Jean Carlos Rossa Hauck, Dr.
PALHOÇA
2014

INTEGRAÇÃO À FERRAMENTA DESKTOP
Este Trabalho de Conclusão de Curso foi julgado

adequado à obtenção do título de Bacharel em
Ciência da Computação e aprovado em sua
forma final pelo Curso de Graduação em Ciência
da Computação da Universidade do Sul de Santa
Catarina.
Dedicamos este trabalho aos nossos
familiares, que depositaram confiança e
investiram em nossos sonhos. As pessoas
que convivemos dentro do curso,
especialmente ao professor Jean Carlos
Rossa Hauck e a professora Vera Rejane
Niedersberg Schuhmacher, os quais foram
indispensáveis para a realização deste
trabalho.
AGRADECIMENTOS
Eduardo Claumann Neis
Agradeço acima de tudo a Deus, por ter me dado saúde, sabedoria e

principalmente força para superar toda e qualquer dificuldade no meio desta jornada.
A toda minha família, em especial meus pais Edemir e Sirleide por ter me
suprido com todo amor necessário, incentivo e apoio nos momentos difíceis, fazendo
com que este meu sonho se tornasse realidade.
A UNISUL, sobretudo ao corpo docente que participou de forma efetiva desta
etapa importante em minha vida. Sem vocês, nada disso seria possível.
E a todos que de forma direta ou indireta tiveram paciência e fizeram parte deste
processo. A vocês, meu muito obrigado.
Gabriel Dias Junckes
Agradeço a minha família, por estar sempre presente em minha vida, pelo amor,
apoio e compreensão.
Aos meus pais Adilso e Eliziana e namorada Juliana, pelo exemplo, amizade,
carinho e apoio.
A todos os professores, especialmente ao professor Jean Hauck, pelo auxilio na
realização deste trabalho.
E também, a todos amigos e colegas que de alguma forma ajudaram na
conclusão desta minha etapa
“Tente uma, duas, três vezes e se possível tente a quarta, a quinta e quantas vezes for
necessário. Só não desista nas primeiras tentativas, a persistência é amiga da conquista.
Se você quer chegar aonde à maioria não chega, faça o que a maioria não faz.”.
(Bill Gates).
RESUMO
A Tecnologia da Informação (TI) se evidencia pelo crescente destaque nas

organizações, não somente como um apoio para o negócio, mas como fator estratégico
às decisões organizacionais. Por isso, viu-se a necessidade de investir no planejamento e
na realização de uma modelagem para desenvolver softwares. A ferramenta
desenvolvida para este trabalho de conclusão de curso vem ao encontro da necessidade
de se ter uma fase de modelagem para o desenvolvimento e o sucesso do software. Com
base nessa demanda, foi criada uma solução web para a modelagem de diagramas UML,
mais especificamente diagramas de caso de uso, e que integre esses diagramas com uma
ferramenta desktop – Enterprise Architect. A ferramenta deve apoiar a mobilidade do
usuário possibilitando o trabalho fora da jornada de horário comercial, ou até mesmo de
forma remota da empresa, muitas vezes com o apoio do cliente ao seu lado. A
ferramenta proposta foi desenvolvida com o intuito de satisfazer a necessidade de
potenciais usuários que necessitem modelar diagrama de caso de uso, mas que não
fiquem restritos a locais específicos.
Palavras chaves: Ferramenta Web, Diagramas de Caso de Uso, Modelagem de

Software.
ABSTRACT
The Information Technology (IT) is evidenced by the increasing prominence in

organizations, not only as a support for the business, but as a strategic factor to
organizational decisions. Therefore we saw the need to invest in planning and
realization of a modeling to develop softwares. The tool developed for this study meets
the need of having a modeling phase to the development and success of the software.
Based on this demand, was created a web solution for modeling UML diagrams, more
specifically using case diagrams, and that integrates these diagrams with a desktop tool
- Enterprise Architect. The tool must support user mobility enabling work outside of
commercial hours, or even work remotely, often with the support of the customer at his
side. The proposed tool has been developed in order to satisfy the needs of potential
users that require modeling use case diagram, but that they are not restricted to specific
locations.
Keywords: Web Tool, Use Case Diagram, Software Modeling.

LISTA DE ILUSTRAÇÕES
Figura 1 - Camadas da Engenharia de Software............................................................. 22

Figura 2 - Diagramas UML do ICONIX ........................................................................ 28
Figura 3 – Diagramas UML ........................................................................................... 32
Figura 4 - Interface da ferramenta Microsoft Visio 2010 ............................................... 38
Figura 5 - Interface da ferramenta Dia ........................................................................... 39
Figura 6 - Interface da ferramenta Enterprise Architect versão 9.0 ............................... 40
Figura 7 - Interface da ferramenta case Draw.io ............................................................ 41
Figura 8 - Arquitetura de modelagem UML via browser. .............................................. 45
Figura 9 - Processo realizado pelo usuário da ferramenta web. ..................................... 46
Figura 10 - Atores do sistema proposto .......................................................................... 49
Figura 11 - Requisitos Funcionais .................................................................................. 50
Figura 12 - Requisitos Não Funcionais .......................................................................... 51
Figura 13 - Diagramas de caso de uso ............................................................................ 53
Figura 14 - Diagrama de Domínio.................................................................................. 56
Figura 15 - Diagrama de Robustez ................................................................................. 57
Figura 16 - Diagrama de Classe ..................................................................................... 58
Figura 17 - Diagrama de Sequência ............................................................................... 60
Figura 18 - Tecnologias utilizadas.................................................................................. 63
Figura 19 - Tela de introdução da ferramenta ................................................................ 66
Figura 20 - Tela para cadastrar usuário .......................................................................... 67
Figura 21 - Tela Fazer Login .......................................................................................... 68
Figura 22 - Tela Selecionar Projeto ................................................................................ 69
Figura 23 - Tela Projetos Cadastrados ............................................................................ 70
Figura 24 - Tela Formulário de Projetos ........................................................................ 71
Figura 25 - Tela Lista de Diagramas .............................................................................. 72
Figura 26 - Tela Formulário de Diagramas .................................................................... 73
Figura 27 - Tela de modelagem do Caso de Uso. ........................................................... 74
LISTA DE QUADROS
Quadro 1 - Descrição dos atores do sistema. .................................................................. 48

Quadro 2 - Lista de Requisitos Funcionais do sistema proposto .................................... 50
Quadro 3 - Lista de requisitos não funcionais do sistema proposto ............................... 52
Quadro 4 - Cadastrar Diagrama ...................................................................................... 53
Quadro 5 - Ferramentas utilizadas e suas necessidades ................................................. 63
LISTA DE TABELAS
Tabela 1 - Consistência da ferramenta ........................................................................... 75

Tabela 2 - Eficiência da ferramenta ................................................................................ 76
Tabela 3 – Satisfação com a ferramenta ......................................................................... 76
Tabela 4 – Facilidade da ferramenta............................................................................... 76
Tabela 5 – Usabilidade da Ferramenta ........................................................................... 77
LISTA DE SIGLAS
CASE - Computer-Aided Software Engineering

CRUD - Create, Read, Update, Delete
EA - Enterprise Architect
ES – Engenharia de Software
GNU - General Public License
OMG - Object Management Group
OO - Orientação a Objetos
SWEBOK - Software Engineering Body of Knowledge
TCC – Trabalho de Conclusão de Curso
TI – Tecnologia da Informação
UML - Unified Modeling Language
UNISUL – Universidade do Sul de Santa Catarina
URL – Uniform Resource Locator
SUMÁRIO
1. INTRODUÇÃO ..................................................................................................... 15
1.1. PROBLEMÁTICA .............................................................................................. 17
1.2. OBJETIVOS ........................................................................................................ 18
1.2.1. Objetivo Geral ................................................................................................ 18
1.2.2. Objetivos Específicos ..................................................................................... 18
1.3. JUSTIFICATIVA .................................................................................................. 18
1.4. ESTRUTURA DA MONOGRAFIA ...................................................................... 19
2 REVISÃO BIBLIOGRÁFICA ............................................................................. 21
2.1 ENGENHARIA DE SOFTWARE ...................................................................... 21
2.1.1 Surgimento da Engenharia de Software ...................................................... 23
2.1.2 Porque usar engenharia de Software? ......................................................... 24
2.2 ARQUITETURA E MODELOS DE SOFTWARE ............................................ 24
2.2.1 Arquitetura de Software................................................................................ 24
2.2.2 Ciclo de Vida do Software ............................................................................. 25
2.2.3 Modelos de ciclo de vida do software ........................................................... 25
2.2.3.1 Modelo Cascata ............................................................................................ 26
2.2.3.2 Modelo Espiral ............................................................................................. 26
2.2.3.3 Modelo Incremental ..................................................................................... 26
2.2.3.4 Modelo Prototipação .................................................................................... 27
2.2.4 Abordagem ICONIX ........................................................................................ 27
2.3 MODELAGEM DE SOFTWARE ...................................................................... 29
2.3.1 Linguagem UML ............................................................................................ 29
2.3.2 Diagramas UML ............................................................................................ 31
2.3.3 Diagrama de Caso de Uso ............................................................................. 33
2.4 FERRAMENTAS DE UML................................................................................ 36
2.4.1 Ferramenta Visio ........................................................................................... 37
2.4.2 Ferramenta Dia .............................................................................................. 38
2.4.3 Ferramenta Enterprise Architect ................................................................. 39
2.4.4 Draw.io ............................................................................................................ 40
2.5 JUSTIFICATIVA DA SELEÇÃO DA FERRAMENTA ................................... 41
3 METODOLOGIA ................................................................................................. 43
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA .............................................. 43
3.2 ETAPAS METODOLÓGICAS ........................................................................... 44
3.3 PROPOSTA DE SOLUÇÃO............................................................................... 44
3.4 DELIMITAÇÕES ................................................................................................ 47
4 MODELAGEM DA PROPOSTA DE SOLUÇÃO ........................................... 48
4.1 ATORES.............................................................................................................. 48
4.2 REQUISITOS FUNCIONAIS ............................................................................. 49
4.3 REQUISITOS NÃO FUNCIONAIS ................................................................... 51
4.4 DIAGRAMA DE CASO DE USO ...................................................................... 52
4.5 DIAGRAMA DE DOMÍNIO .............................................................................. 55
4.6 DIAGRAMA DE ROBUSTEZ ........................................................................... 56
4.7 DIAGRAMA DE CLASSE ................................................................................. 58
4.8 DIAGRAMA DE SEQUÊNCIA ......................................................................... 59
4.9 CONSIDERAÇÕES FINAIS .............................................................................. 61
5 DESENVOLVIMENTO DA PROPOSTA DE SOLUÇÃO .............................. 62
5.1 TECNOLOGIAS E FERRAMENTAS ............................................................... 62
5.2 HISTÓRICO DE DESENVOLVIMENTO ......................................................... 65
5.3 APRESENTAÇÃO DO SISTEMA ..................................................................... 65
5.4 VALIDAÇÃO OU AVALIAÇÃO DA PROPOSTA .......................................... 74
6 CONCLUSÕES E TRABALHOS FUTUROS ................................................... 78
6.1 CONCLUSÕES ................................................................................................... 78
6.2 TRABALHOS FUTUROS .................................................................................. 79
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 80
APÊNDICES ................................................................................................................. 83
APÊNDICE A – DETALHAMENTO DOS CASOS DE USO ................................. 84
APÊNDICE B – PROTÓTIPOS DE TELA ............................................................... 88
APÊNDICE C – CRONOGRAMA ............................................................................. 93
APÊNDICE D – CÓDIGO ........................................................................................... 94
APÊNDICE E – QUESTIONÁRIO ............................................................................ 94
1. INTRODUÇÃO
O mundo atual está tecnologicamente acirrado demais, onde organizações

estão cada vez mais competitivas para manterem-se fortes no mercado.
“Competição é uma das palavras de ordem no mundo corporativo. Assim
como as organizações, os executivos competem entre si, na medida em que todos
almejam o mesmo objetivo, que é o sucesso. E não há lugar nos primeiros lugares do
pódio para todo mundo.” (BARROS Jr, s.d).
A área da Tecnologia da Informação (TI) tem gerado vantagem competitiva
usada para os mais variados segmentos:
Como a tecnologia está cada vez mais inserida no negócio, podemos até nos
arriscar a dizer que no futuro não teremos mais TI fazendo parte do negócio,
mas o próprio negócio sendo TI. O tempo em que existia um setor de TI
isolado, definitivamente, já passou. As empresas que ainda estão no estágio
de buscar alinhamento entre TI e negócios perderam o trem. (TAURION,
2013).
O contexto do mercado atual exige softwares sofisticados a custos de

desenvolvimento competitivos. Essas condições refletem diretamente nas empresas, que
se tem adaptado constantemente com sistemas cada vez mais elaborados e que supram
suas necessidades pontuais.
Se antes o gestor de TI, muitas vezes, se preocupava apenas com gigabytes e
termos técnicos voltados à área de infraestrutura como servidores e sistemas
operacionais, agora precisa se preparar para buscar assuntos pertinentes à qualidade e ao
gerenciamento do desenvolvimento do software.
Diante desse cenário, Palácios (2003) diz que “a tecnologia de hoje permite
que você controle seu negócio de uma maneira nunca vista antes, a distância deixou de
ser um obstáculo, os sistemas se tornaram mais amigáveis, os custos diminuíram e a
segurança aumentou, [...]”.
A implementação de softwares corporativos necessita um trabalho
colaborativo entre os mais diversos setores dentro de uma organização, e não somente
entre o gestor de TI e a diretoria, por exemplo. Precisam trabalhar sinergicamente todas
15
as lideranças e todas precisam ter bem alinhados os objetivos que aquele software
deverá apresentar para se colocar em prática o desenvolvimento do mesmo.
Nesse sentido, “sabe-se que uma organização deve operar como uma
unidade, com todas as suas partes em eficiente coordenação e um permanente processo
sinérgico entre seus membros”. (MOGGI, 2011).
Assim, para que não haja esforços desnecessários e dinheiro mal investido,
faz-se necessário fazer um levantamento completo e detalhado do cenário atual,
entender o objetivo para o qual o software será empregado, alinhar ideias e pensamentos
de lideranças, fazer um mapeamento, caso o projeto já esteja em andamento, ou modelar
todos os processos do início, para o desenvolvimento do software.
Segundo Vieira (2014), os softwares têm falhas próprias e específicas, mas
todos os projetos são semelhantes em diversos aspectos. Um dos elementos que
contribuem para o sucesso de um software é a realização de uma fase de modelagem no
seu desenvolvimento, que será amplamente abordada neste trabalho.
Segundo a SWEBOK1 (2013, tradução nossa), a modelagem fornece ao
engenheiro de software uma abordagem organizada e sistemática da representação dos
aspectos significativos do software, facilitando estudos, tomadas de decisão sobre o
software e a comunicação entre stakeholders sobre essas decisões.
A modelagem é uma parte central de todas as atividades que levam à
implantação de um bom software. (BOOCH; RUMBAUGH, JACOBSON. 2000. p. 3).
Se bem utilizada, ela pode reduzir alguns dos maiores riscos de qualquer projeto de
software, que são a qualidade da entrega e o tempo previsto.
Para estruturar este trabalho, será utilizada a modelagem mais empregada
atualmente, a Unified Modeling Language (UML) 2, uma linguagem não proprietária
que dispensa licenças para usar, permite modelar sistemas orientado a objetos, cuja
visualização dos diagramas, dependendo da ferramenta, ocorre de maneira prática,
facilitando a comunicação entre as pessoas.
1
O Software Engineering Body of Knowledge (SWEBOK) é um guia usado como referência para
assuntos relacionados à Engenharia de Software. Está disponível no endereço: <
http://www.computer.org/portal/web/swebok>.
2
A Unified Modeling Language (UML) é uma forma de padronizar as linguagens de modelagem. Está
disponível no endereço: <http://www.omg.org/spec/UML/2.4.1/>
16
1.1. PROBLEMÁTICA
O desenvolvimento de um software para cobrir alguma necessidade, em

questão, apesar de parecer prático, pode trazer um resultado não esperado, caso não seja
correspondido à altura. Essa solução requer planejamento entre gestores, modelagens
criadas com os usuários que irão fazer uso desse software, desenvolvimento de acordo
com o que está previamente documentado e presente na modelagem, validação com os
usuários que irão fazer seu uso e testes exaustivos previamente antes de colocar em
funcionamento.
Embora as ferramentas para modelar diagramas de caso de uso sejam mais
comuns em ambientes corporativos, viu-se como uma limitação seu uso caso seja
necessário à visualização de outros lugares que não fazem uso dessas ferramentas
localmente, ou de lugares remotos e fora do ambiente corporativo.
Essa necessidade se deu porque hoje pessoas não trabalham apenas em um
ambiente, elas estão espalhadas e existem equipes multidisciplinares alocadas em
diferentes pontos, ou até mesmo filiais pelo mundo que não se restringem no mesmo
horário de trabalho, sendo assim, para esses profissionais que fazem uso de ferramentas
de modelagem, ter um local específico para modelar pode virar um problema.
Pode-se encontrar uma lista de ferramentas para modelagem UML,
especificamente diagramas de caso de uso no seguinte endereço:
<http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools>.
Com essa limitação das ferramentas de modelagens apenas locais, faz-se
necessário uma ferramenta web que possibilite essa modelagem e que integre com uma
ferramenta local, e que a mesma ferramenta permita o inverso também, ou seja, da
modelagem via ferramenta desktop e a sua integração para visualizar a partir da
ferramenta web.
Para auxiliar na modelagem UML, a ferramenta escolhida para uso é uma
que tem grande aceitação no mercado corporativo, que é a Enterprise Architect (EA).
Entretanto, essa ferramenta não possui atualmente uma interface web para modelagem
UML. Neste sentido, a proposta deste trabalho consiste na criação de uma ferramenta
web para possibilitar a modelagem de diagramas UML, mais especificamente diagramas
de caso de uso, que permitem desta forma a integração com a ferramenta desktop.
17
1.2. OBJETIVOS
1.2.1. Objetivo Geral
Desenvolver e avaliar uma ferramenta web para modelagem de diagramas

de caso de uso da notação UML, integrada a uma ferramenta de modelagem desktop.
1.2.2. Objetivos Específicos
investigar a importância da modelagem para o desenvolvimento de

softwares;
analisar, a partir da linguagem UML, a modelagem de diagramas de
Caso de Uso;
analisar e modelar a integração com a ferramenta Enterprise Architect;
implementar a ferramenta web de modelagem UML;
testar e validar o sistema desenvolvido;
1.3. JUSTIFICATIVA
A realização de testes nos softwares remete a real necessidade de se planejar

muito bem os fluxos antes mesmo de executá-los. Assim, uma boa tratativa para que
tudo ocorra bem é a modelagem dos diagramas de Caso de Uso, que é um dos principais
diagramas para descrever a funcionalidade do sistema, aliado com a participação do
usuário final como colaborador participativo no desenvolvimento.
Atualmente, existem diversas ferramentas corporativas para modelar
sistemas orientados a objetos. Uma listagem dessas ferramentas pode ser encontrada no
18
seguinte endereço:
http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools, entretanto
seus usos são limitados a computadores locais. Por isso, justifica-se a necessidade desse
presente trabalho, para dar apoio à modelagem dos diagramas de caso de uso através da
web com integração a ferramentas desktop.
A criação dessa ferramenta web, batizada como “UML Discovery”, surgiu
da necessidade de se modelar diagramas de caso de uso através da notação UML para o
desenvolvimento de softwares em locais fora do ambiente corporativo, pois as
ferramentas de mercado atuais não permitem a modelagem via web ou por dispositivos
móveis com a integração a uma ferramenta desktop, o que limita a sua aplicação quando
um analista estiver em campo, quando não tiver acesso a uma ferramenta local ou até
mesmo quando seu uso for restrito.
1.4. ESTRUTURA DA MONOGRAFIA
Este trabalho encontra-se dividido em 6 (seis) capítulos. O primeiro capítulo

é referente à introdução do tema, sobre a problemática em questão, os objetivos gerais e
específicos atrelados com o desenvolvimento do assunto e a justificativa da relevância
desse tema.
O segundo capítulo é responsável pelos conceitos teóricos sobre a crise do
software, a importância da engenharia de software e, principalmente, sobre a
modelagem, os ciclos de vida de um software e uma revisão sobre a abordagem
ICONIX, a utilização da notação UML, os diagramas de caso de uso e, por fim, sobre as
ferramentas para modelar e uma avaliação sobre a escolhida.
O terceiro capítulo apresenta o planejamento da pesquisa, de como serão
alcançados os objetivos a partir da metodologia utilizada, bem como a proposta de uma
solução.
O quarto capítulo é a definição da modelagem, o escopo do
desenvolvimento e os detalhes de desenvolvimento para solução deste trabalho.
O quinto capítulo descreve detalhadamente o sistema, suas telas feitas
através de protótipos e a validação do sistema.
19
O sexto capítulo é a respeito da conclusão que se consegue obter e os
objetivos atingidos referentes ao desenvolvimento deste trabalho.
20
2 REVISÃO BIBLIOGRÁFICA
Neste capítulo, são abordados diversos assuntos pertinentes à área de engenharia

de software que são importantes para o desenvolvimento deste trabalho.
Primeiramente, é realizado um estudo sobre de como nasce a engenharia de
software e seus modelos de ciclo de vida. Em sequência, são descritos os padrões de
modelagem de software, trazendo como referência uma das mais bem aceitas notações
do ambiente corporativo, que é a UML e seus diagramas de modelagem, dando
destaque, apenas, ao que estará disponível na ferramenta web, o diagrama de Caso de
Uso. E, por fim, são apresentadas ferramentas que realizam essa modelagem,
referenciando-se, então, com o software comercial com melhor custo benefício do
mundo corporativo, o EA.
Esses assuntos que são tratados no presente trabalho darão maior fundamentação
teórica para o desenvolvimento da ferramenta proposta, visando à melhor sustentação
científica, atendendo as necessidades do desenvolvimento e do entendimento do
trabalho.
2.1 ENGENHARIA DE SOFTWARE
A definição para engenharia de software, segundo BAUER (1972, apud

PRESMAN, 2011, p. 39), é “o estabelecimento e uso de sólidos princípios de
engenharia para que se possa obter economicamente um software que seja confiável e
que funcione eficientemente em máquinas reais.”.
Segundo SWEBOK (2013, tradução nossa), a engenharia de software é “a
aplicação de uma sistemática, disciplinada, abordagem quantificável para o
desenvolvimento, operação e manutenção de software; isto é, a aplicação da engenharia
de software”.
Para Peters e Pedrycz (2001), uma das vantagens de se iniciar projetos,
utilizando conceitos relacionados à área de engenharia de software, são a agilidade e a
21
simplificação, devido à enorme disponibilidade de ferramentas úteis para seu
desenvolvimento.
Nesse sentido, de acordo com Sommerville (2003), a Engenharia de Software
(ES) é responsável em todos os ângulos pela produção do software, ou seja, desde os
estágios iniciais até a fase de manutenção desse sistema.
De acordo com Pressman (2011), a ES é dividida em camadas, incluindo o
compromisso organizacional com a qualidade. Pode-se dividir então a engenharia de
software em: Métodos, ferramentas, processos e qualidade.
Os métodos resumem em “como fazer” para se construir um software, ou seja,
fornecem informações técnicas de como desenvolver o software. As ferramentas
permitem apoio automatizado ou semi-automatizado aos métodos e os processos são um
conjunto de ações e tarefas que acontecem na criação de algum produto de trabalho,
mantendo os métodos e as ferramentas interligados, possibilitando o desenvolvimento
do software dentro do prazo. Já, a gestão da qualidade promove o aperfeiçoamento
contínuo de processos, mantendo-se como elemento chave na engenharia de software.
A Figura 1, a seguir, mostra as camadas segundo Pressman (2011):
Figura 1 - Camadas da Engenharia de Software
Autor: Pressman (2011, p. 39).
Pode-se, então, entender que o objetivo dos modelos abstratos da engenharia de

software é atender as fases de definição, desenvolvimento e manutenção, visando à
organização, disciplina, produtividade, manutenção e, acima de tudo, da qualidade do
software a baixo custo.
22
2.1.1 Surgimento da Engenharia de Software
A chamada crise do software, “[...], que começou a ser utilizada já na década de

60, tem historicamente aludido a um conjunto de problemas recorrentemente
enfrentados no processo de desenvolvimento – construção, implantação e manutenção –
de Software.” (MAFFEO, Bruno. 1992 p. 2).
A crise do software, instalada na década de 60, teve grande culpa ocasionada
pela inexistência da engenharia de software, destacando que os métodos existentes na
época não eram bons o suficiente para o desenvolvimento de softwares complexos.
Os principais problemas, segundo Sommerville (2003), eram os projetos de
grande porte, pois apresentavam, muitas vezes, anos de atraso. Os custos totais
passavam do previsto, o software final não era totalmente confiável, além de ser
insatisfatório o desempenho para quem utilizava, era difícil de manter.
Para Silva (2006), a ideia de Engenharia de Software (ES) surgiu por volta de
1970 com o intuito de tentar contornar a crise do software que se estava vivendo, dando
assim um passo para se usar a engenharia, ou seja, tornando o desenvolvimento de
programas mais sistemático e controlado.
Segundo Naur e Randell:
Para ser eficaz, o desenvolvimento de sistemas de software exige uma

abordagem de engenharia. A necessidade de uma abordagem desse tipo foi
sugerida pela primeira vez em uma conferência da OTAN em 1968 (1969,
apud PETERS; PEDRYCZ. 2001, p. 4).
De acordo com Harel (1992, apud PETERS; PEDRYCZ, 2001, p. 07), “o desafio
da engenharia de software é encontrar formas de capturar a construção conceitual de
sistemas complexos.”.
Ainda, assim, a ES é uma disciplina relativamente nova para Sommerville

(2003). Segundo ele, esse conceito surgiu pela primeira vez em uma conferência feita
para discutir a chamada “crise do software”. Para ele, apenas a experiência de
desenvolvimento não bastava, sendo assim, na época, vários projetos importantes
sofreram atrasos e apresentavam custos maiores do que o previsto.
23
2.1.2 Porque usar engenharia de Software?
Segundo Peters e Pedrycz (2001), a ES é uma aproximação de engenharia

necessária para evitar o pior no desenvolvimento de software, pois ela tem a facilidade
de ser uma abordagem extremamente prática, ordenada e com possibilidade de medir.
De acordo com Sommerville (2003), a ES abrange todas as áreas do software,
desde o começo do desenvolvimento até o fim do mesmo. Essas etapas passam pela
produção, desde a sua especificação, envolvendo seu desenvolvimento, acompanhando
até sua fase final, que é a manutenção. Ela alcança todas as atividades que estão
cobertas no projeto de software, apresentando métodos mais eficazes para o seu
desenvolvimento, com o objetivo de melhorar a produção em qualidade, diminuindo
custos e respeitando os prazos de entrega.
A engenharia de software usada é importante justamente pelo fato de ter sido
criada para melhorar a qualidade do software, aumentando a produtividade e
contribuindo, assim, para a constante evolução do mesmo, respeitando os prazos
estabelecidos e diminuindo os custos.
2.2 ARQUITETURA E MODELOS DE SOFTWARE
2.2.1 Arquitetura de Software
Segundo Silva, Gomide e Petrillo (2003, p. 107), “arquitetura de software é uma

visualização conceitual da estrutura de um aplicativo. Nela são definidos todos os
componentes de hardware e software que formam uma aplicação.”.
Ainda para Martins (2002), a arquitetura define como serão projetados e
agrupadas fisicamente as partes do sistema.
24
2.2.2 Ciclo de Vida do Software
Para Sommerville (2003), o chamado ciclo de vida do software é um conjunto de

atividades e resultados que trazem como produto final um software.
De acordo com Pressman (2011), os processos de software não são garantia de
que o software será entregue dentro do prazo, nem que estará de acordo com o que o foi
solicitado pelo cliente e, muito menos, que apresentará qualidade. Para que isso
aconteça, os processos devem estar atrelados às práticas consistentes da engenharia de
software.
O ciclo de vida do software é um conjunto estruturado de atividades que são
necessárias para que ocorra o desenvolvimento do software, não podendo ser
confundido com modelos de ciclo de vida, pois ele descreve as fases pelas quais o
software irá passar, enquanto os modelos de ciclo de vida são representações desses
processos.
2.2.3 Modelos de ciclo de vida do software
Para Sommerville (2003, p. 36), o conceito de modelagem de processos do

software seria:
[...] uma representação abstrata de um processo de software. Cada modelo de

processo representa um processo a partir de uma perspectiva particular, de
uma maneira que proporciona apenas informações parciais sobre o processo.
A escolha do modelo dependerá da complexidade do sistema que o cliente solicitar, o

tempo que a equipe tem disponível e o custo que se quer alcançar. Existem diversos
modelos de ciclo de vida do software existentes, entretanto, a seguir, serão abordados
apenas os modelos em cascata, espiral, incremental e de prototipação.
25
2.2.3.1 Modelo Cascata
O modelo cascata acontece por etapas. Segundo Sommerville (2003), a cada

estágio aprovado, ele é aceito e o desenvolvimento do software evolui, prosseguindo
para o estágio adiante.
Segundo Peters e Pedrycz (2001), o modelo em cascata é o mais antigo de todos,
descrevendo uma sequência de processos do software, começando pelos conceitos e
finalizando com a manutenção.
Também chamado de “ciclo de vida clássico”, esse modelo, segundo Pressman
(2011), sugere que o desenvolvimento do software aconteça de forma sequencial e
sistemática, começando pela comunicação com o cliente e levantando suas
necessidades, avançando pelas fases de planejamento, seguindo pela modelagem, pela
construção e, por fim, pelo emprego do software, onde acontece a entrega, o suporte e o
feedback.
2.2.3.2 Modelo Espiral
O modelo de ciclo de vida espiral, segundo Peters e Pedrycz (2001), combina as

características positivas do modelo em cascata e as versões anteriores do sistema do
modelo de prototipação.
Este modelo de ciclo de vida foi criado como um somatório das melhores
características do modelo de prototipagem e do modelo em cascata.
2.2.3.3 Modelo Incremental
Para Sommerville (2003), no modelo incremental, os clientes identificam quais

funções são mais relevantes e menos relevantes, definindo as entregas de cada estágio
com suas funcionalidades particulares. Quando um incremento é entregue, os clientes já
26
podem colocá-lo em operação, fazendo com que a funcionalidade melhore a cada fase
de entrega.
O modelo incremental “tem seu foco voltado para a entrega de um produto
operacional com cada incremento. Os primeiros incrementos são versões seccionadas do
produto final, mas eles realmente possuem capacidade para atender ao usuário e
também oferecem uma plataforma para avaliação do usuário.”. (PRESSMAN, 2011, p.
62).
2.2.3.4 Modelo Prototipação
De acordo com Peters e Pedrycz (2001), o modelo de prototipação é produzido

de forma que clientes e desenvolvedores verifiquem as implementações preliminares,
antes mesmo de o software estar terminado.
Seu uso, “independentemente da forma como é aplicado, quando os requisitos
são obscuros, o paradigma da prototipação auxilia os interessados a compreender
melhor o que está para ser construído.” (PRESSMAN, 2011, p. 63).
Esse modelo foi criado para atender as necessidades tanto dos desenvolvedores
quanto dos usuários, possibilitando que se tenha uma integração entre os mesmos,
fazendo com que o desenvolvedor crie uma amostra (protótipo) do software que será
construído.
2.2.4 Abordagem ICONIX
A abordagem ICONIX permite a utilização de recursos da UML para acrescentar

aos recursos usados nas fases do ICONIX, caso seja necessário. (SILVA et al., 2007).
A metodologia ICONIX é um processo prático que unifica métodos de
orientação a objetos em um único método, mais completo, simples e com objetivo de
cobrir o ciclo de vida de desenvolvimento de uma aplicação (SOUZA, 2011). Utiliza
diagramas a partir da linguagem UML e foi escolhido como a metodologia para modelar
27
o sistema deste presente trabalho, pois permite modelar e desenvolver o software de
forma eficiente.
A Figura 2, abaixo, aborda os cinco diagramas da UML que a metodologia
ICONIX utiliza, são eles: os diagramas de domínio, de caso de uso, robustez, sequência
e classe.
Figura 2 - Diagramas UML do ICONIX
Fonte: Iconix Process.
Os diagramas de domínio, de caso de uso, robustez, sequência e classe serão

tratados com maior ênfase no capítulo de modelagem.
28
2.3 MODELAGEM DE SOFTWARE
A modelagem pode ser entendida como parte indispensável para o

desenvolvimento do software, trazendo a realidade dos negócios e evitando problemas
futuros na hora de executar o produto final. “Um modelo é uma abstração de algo com a
finalidade de entendê-lo antes de construí-lo.” (BLAHA, RUMBAUGH, 2006, p. 17).
Na opinião de Booch, Rumbaugh e de Jacobson (2000), a modelagem faz
entender o sistema e, dependendo o tipo do cenário, faz com que seja mais interessante
o uso da modelagem textual, entretanto, em outras situações, como no caso da
linguagem de modelagem unificada, será usada a modelagem gráfica, trazendo maiores
benefícios no momento da compreensão da abstração do sistema.
Segundo a Object Management Group3 (2005, tradução nossa), “usando um
modelo, os responsáveis pelo sucesso de um projeto de desenvolvimento de software
podem assegurar-se de que a funcionalidade dos negócios é completa e correta, são
atendidas as necessidades do usuário final, [...].”.
2.3.1 Linguagem UML
Cada desenvolvedor pode estabelecer seus próprios critérios para modelagem,

entretanto a “UML é a linguagem-padrão para a elaboração da estrutura de projetos de
software”. (BOOCH; RUMBAUGH; JACOBSON. 2000, p.14). Assim, fornece um
vocabulário específico com finalidades de se comunicar com algo ou alguém,
representando uma relação entre a realidade do sistema e a abstração do mesmo.
A OMG é uma organização internacional, sem fins lucrativos, que estabelece
padrões na área da computação, especificamente com orientação a objetos. A OMG
adotou a UML, em 1997, como linguagem padrão para modelagem e tem passado por
diversas versões, encontrando-se atualmente, na versão 2.4.1.
3
Organização internacional que padroniza assuntos pertinentes a aplicações Orientadas a Objetos.
Disponível em:< http://www.omg.org/>
29
Segundo Groffe (2014), “o fato de a UML ser um padrão de grande aceitação no
mercado também se deve, em grande parte, à forte integração desta com conceitos
da Orientação a Objetos (OO).”.
A UML é uma forma de padronizar a modelagem orientada a objetos, facilitando
assim a comunicação com outras aplicações, simplificando os sistemas através da
alteração do nível de complexidade e da compreensão dos processos.
Ela não guia um desenvolvedor em como fazer análise e projeto orientado a
objetos, ou qual o processo de desenvolvimento a ser seguido (LARMAN, 1999). Ela
serve como facilitador para o desenvolvedor, diminuindo os riscos de um software que
não atenda às necessidades do usuário final.
A UML apresenta como principais objetivos a visualização, a especificação, a
construção e a documentação de um software. A seguir, será apresentado, de forma
resumida, o que cada objetivo representa:
a) Visualizar
O objetivo visualizar, para Booch, Rumbaugh e Jacobson (2000), é a

possibilidade do uso da UML com modelos explícitos, facilitando a comunicação entre
desenvolvedores, pois se trata de uma linguagem universal para todos. Pessoas que
estabelecem linguagens próprias acabam tornando a compreensão mais difícil e estarão
sujeitas a cometerem erros.
Assim, “um desenvolvedor poderá usar a UML para escrever seu modelo, e
qualquer outro desenvolvedor, ou até outra ferramenta, será capaz de interpretá-lo sem
ambiguidades.” (BOOCH; RUMBAUGH; JACOBSON. 2000 p. 15).
b) Especificar
A característica especificar, na opinião de Booch, Rumbaugh e Jacobson (2000), é

que a UML atende a todas as decisões importantes em termos de análise, projeto e
implementação que devem ser tomadas para o desenvolvimento e implementação de
sistemas complexos de software. A linguagem refere-se à construção de uma
modelagem com uma forma de entendimento padrão e completa, não cabendo
duplicidade nos sentidos.
30
c) Construir
De acordo com os autores Booch, Rumbaugh e Jacobson (2000, p.16), “a UML é

capaz de representar tudo que possa ser melhor expresso em termos gráficos, enquanto
as linguagens de programação representam o que é melhor expresso em termos
textuais.”.
A UML é uma representação gráfica que não está amarrada a apenas uma
linguagem de programação, podendo ser usada por diversas linguagens. Diante desse
aspecto, podem-se criar softwares a partir da modelagem de acordo com a necessidade
de cada um, e o inverso também é possível, ou seja, modelar diagramas UML a partir
das linhas de código.
d) Documentar
A documentação é um facilitador, quando se trata do controle de um sistema.

Empresas que tratam os esforços de seus desenvolvedores como algo relevante,
certamente, possuem maneiras de guardar não somente o produto final, mas também
materiais que podem servir como pesquisas futuras, evitando, assim, o retrabalho e o
deslocamento de energia desnecessária dos desenvolvedores.
Segundo Booch, Rumbaugh e Jacobson (2000, p. 17), a respeito da documentação:

A UML abrange a documentação da arquitetura do sistema e de todos os seus
detalhes. A UML também proporciona uma linguagem para a expressão de
requisitos e para a realização de testes. Por fim, a UML oferece uma
linguagem para a modelagem das atividades de planejamento do projeto e de
gerenciamento de versões.
2.3.2 Diagramas UML
Para Martins (2002), a UML permite criar diversos tipos de diagramas existentes,
cada um com sua função particular, servindo para modelar partes específicas do sistema.
Para os fundadores da linguagem de modelagem unificada, os diagramas “são

desenhos para permitir a visualização de um sistema sob diferentes perspectivas; nesse
sentido, um diagrama constitui uma projeção de um determinado sistema.”. (BOOCH;
RUMBAUGH; JACOBSON. 2000, p. 25).
31
Os diagramas são representações gráficas de vários tipos de elementos da
modelagem, ou seja, são criadas perspectivas para auxiliar o entendimento do modelo.
Na versão 2.4.1, disponível no endereço: http://www.omg.org/spec/UML/2.4.1/,
existem quatorze diagramas de modelagem, sendo divididos em três grupos: Estruturais,
Comportamentais e de Interação, conforme a Figura 3 a seguir.
Figura 3 – Diagramas UML
Fonte: Adaptado da OMG [2007].
Desta forma, podem-se citar os diagramas conforme o grupo da UML 2.4.1:
Diagramas de estrutura: Diagrama de classes, diagrama de componentes,

diagrama de objetos, diagrama de estrutura composta, diagrama de
implementação, diagrama de pacote e diagrama de perfil.
Diagrama de Comportamento: Diagrama de Atividades, diagrama de casos de
uso e diagrama de Máquina de estado.
Diagrama de Interação: Diagrama de Sequência, diagrama Global de
Interação, diagrama de comunicação e diagrama de sincronização.
32
Embora existam 14 diagramas na versão do UML 2.4.1, para este presente
trabalho será dado ênfase apenas no de diagramas de caso de uso, pois são esses
diagramas que estarão presentes na ferramenta web para modelagem.
2.3.3 Diagrama de Caso de Uso
Para Martins (2002, p. 90), os diagramas de caso de uso têm por finalidade
buscar tudo que é relacionado aos requisitos funcionais de um sistema, através da
validação com o usuário final.
Os diagramas de caso de uso são considerados “representações das
funcionalidades externamente observáveis do sistema e dos elementos externos ao
sistema que interagem com ele.” (BEZERRA, 2003, p. 45).
Segundo Booch, Rumbaugh e Jacobson (2000, p. 217), os casos de uso também
servem para “ajudar a validar a arquitetura e para verificar o sistema à medida que ele
evolui durante seu desenvolvimento.”.
Assim, esses diagramas têm como grande finalidade modelar o que o sistema
deve fazer, do ponto de vista do usuário, envolvendo um conjunto de casos de uso e
atores. Seu entendimento é simples, fazendo com que a riqueza dos detalhes seja
dispensável, tornando-se o diagrama mais utilizado entre o usuário final e os
desenvolvedores.
A seguir, são apresentados os conceitos de Caso de Uso, atores e os
relacionamentos estabelecidos entre eles:
a) Caso de Uso
Um caso de uso é uma sequência de interações entre um sistema e um agente

externo em que representa quem faz o que neste sistema. (BEZERRA, 2003, p. 46).
Segundo Martins (2002), os casos de uso permitem agrupar o sistema em partes
a partir de sua funcionalidade, sendo que cada parte do sistema deverá produzir algo útil
ao ator.
33
Para Jacobson (1992, apud LARMAN, 1999, p. 68), o caso de uso é “um
documento narrativo que descreve a sequência de eventos de um ator que usa um
sistema para completar um processo.”.
O caso de uso é considerado uma funcionalidade que o ator (usuário) irá realizar
no sistema. A seguir, é apresentada qual a finalidade do ator sobre um diagrama de caso
de uso.
b) Ator
Segundo a OMG (2011, p. 598, tradução nossa), na parte de documentação da

notação, “um ator especifica um papel desempenhado por um utilizador ou qualquer
outro sistema que interage com o objeto.”.
Para Larman (1999, p. 70), “um ator é uma entidade externa ao sistema que, de
alguma maneira, participa da história do caso de uso. Ele estimula o sistema com
eventos de entrada ou recebe algo do mesmo.”.
Cada ator representa aqueles objetos que se comportam de uma maneira
específica em relação ao sistema. Segundo Blaha e Rumbaugh (2006, p.136), os atores
podem ser entendidos como um conjunto de “objetos que se comunicam diretamente
com o sistema, mas não são parte dele”.
Os atores são representações de seres humanos ou dispositivos a partir de seus
papéis que irão interagir com o sistema. “Os atores podem ser usuários ou máquinas, e
todos deles devem ser descritos com detalhes, [...].”. (MARTINS, 2002, p. 92).
A seguir, é apresentada qual a finalidade dos relacionamentos no diagrama de
caso de uso:
c) Relacionamento
Os casos de uso e os atores, citados acima, não existem isoladamente. Assim,

eles têm relacionamentos entre si, organizados em grupos de relacionamento por
generalização, inclusão e extensão. A seguir, será tratado cada um desses grupos:
1) Generalização
Segundo Blaha e Rumbaugh (2006, p. 155), um relacionamento por
generalização “pode mostrar variações específicas em um caso de uso mais geral, de
forma análoga à generalização entre casos de uso”.
34
Uma generalização é um relacionamento entre itens considerados classes-mãe e
tipos mais específicos desses itens, que são chamados de classes-filhas. (BOOCH;
RUMBAUGH, JACOBSON. 2000. p. 63).
Para Bezerra (2003), um relacionamento de generalização é evidente o reuso.
Este relacionamento pode ser feito entre atores ou entre casos de uso, e tem
características de herdar atribuições do mais genérico. É usado como herança entre
casos de uso, quando um comportamento mais genérico é adicionado a um mais
específico.
2) Inclusão
Para OMG (2011, p. 604, tradução nossa), um relacionamento de inclusão
“define que um caso de uso contém o comportamento definido em outro caso de uso.”.
Para Bezerra (2003), o relacionamento de inclusão está atribuído somente aos
casos de uso. Esse relacionamento serve para agrupar dois ou mais casos de uso que
incluem uma sequência comum e que podem ser descritas a outros casos de uso.
Um relacionamento de inclusão é entendido que o comportamento de um caso
de uso é incluído a partir de outro. São usados normalmente para evitar descrever o
mesmo fluxo de eventos diversas vezes. (BOOCH; RUMBAUGH, JACOBSON. 2000).
Um relacionamento de inclusão é usado quando o mesmo comportamento se
repete mais de uma vez em um caso de uso.
Segundo Blaha e Rumbaugh (2006, p. 153), a relação include “incorpora um
caso de uso dentro da sequência de comportamento de outro caso de uso. Um caso de
uso Include é como uma sub-rotina”.
3) Extensão
Para a OMG (2011, p. 601, tradução nossa), esse relacionamento “especifica que
o comportamento de um caso de uso pode ser estendido pelo comportamento de outro
(geralmente suplementar) do caso de uso”.
Para Booch, Rumbaugh e Jacobson (2000. p. 226), um relacionamento de
extensão entre casos de uso “significa que o caso de uso base incorpora implicitamente
o comportamento de outro caso de uso em um local especificado indiretamente pelo
caso de uso estendido.”.
Para Bezerra (2003), um relacionamento de extensão é usado para modelar
sequências de interação que podem ser inseridas ao caso de uso.
35
Segundo Martins (2002), o relacionamento extend modifica apenas alguns
passos estendidos do mesmo, ou seja, somente o caso de uso estendido de outro
modificará em partes. É usado quando um comportamento opcional de um caso de uso
precisar ser usado.
2.4 FERRAMENTAS DE UML
É grande o número de ferramentas disponíveis atualmente para a geração de

diagramas UML. “Existem desde soluções gratuitas e que contam com um bom suporte
para a elaboração de representações baseadas nesta linguagem, passando ainda por
softwares proprietários dotados de uma ampla gama de recursos.” (GROFFE, 2014).
Para Pressman (2011, p. 40):
As ferramentas de Engenharia de Software fornecem suporte automatizado

ou semiautomatizado para o processo e para os métodos. Quando as
ferramentas são integradas, de modo que as informações criadas por uma
ferramenta possam ser usadas por outra, é estabelecido um sistema para o
suporte ao desenvolvimento do software, denominado engenharia de software
com o auxílio do computador.
Segundo Fuggeta (1993, apud SOMMERVILLE, 2003, p.54), “as ferramentas

apoiam as tarefas de processo individuais, como a verificação da consistência de um
projeto, a compilação de um programa, a comparação de resultados de testes, entre
outras”.
Para o apoio desta sessão e para seleção das ferramentas foi colocado como
pesquisa no Google o assunto “UML Tools” e o endereço que possui uma grande lista
de ferramentas para modelagem UML atualizadas é:
http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools. Como a lista
das ferramentas está organizada em ordem alfabética, não foram usados critérios por
ordem de posicionamento, sendo assim, foi tentado selecionar as ferramentas, usando
critérios por facilidade na busca das informações e disponibilidade para pesquisas.
Dentre as diversas opções de mercado presentes na lista, serão apresentadas

apenas quatro ferramentas baseadas em computadores que auxiliam em atividades
relacionadas à área de engenharia de software, chamados de programas auxiliares para
36
Engenharia de Software ou Computer-Aided Software Engineering (CASE). Os critérios
para seleção dessas ferramentas foi na facilidade da obtenção de informações e na
disponibilidade para pesquisas, conseguindo dessa forma diversificar bastante o
potencial de cada ferramenta escolhida. Dentre as diversas características das
ferramentas selecionadas, destacam-se softwares bem estabelecidos no mercado, com
ferramentas pagas, ferramentas gratuitas e disponíveis para download e ferramentas
web, que tem grande proximidade e relação com a proposta do presente trabalho.
Essas ferramentas têm como objetivo principal ajudar na elaboração dos

diagramas de Caso de Uso. Das quatro ferramentas, serão expostas duas versões pagas,
que serão a ferramenta Visio, da fabricante Microsoft; e a ferramenta Enterprise
Architect, da fabricante Sparx Systems, uma versão gratuita, que será a ferramenta Dia,
4
cuja licença faz parte da General Public License (GNU) e é um software livre e a
quarta ferramenta será o Draw.io, ferramenta web gratuita que tem relação com a
proposta do presente trabalho.
2.4.1 Ferramenta Visio
A ferramenta Visio5, que tem como fabricante a Microsoft6, permite gerar

diversos tipos de gráficos, como, organogramas, fluxogramas, entre outras modelagens
de dados, aceitando inclusive a notação UML.
Embora seja uma ferramenta paga, sua utilização é extremamente fácil pelo
simples fato da sua interface ser bem organizada, o que compensa seu custo x benefício
na hora de adquiri-la. Segundo a Microsoft (2014), esse programa tem ajudado diversos
usuários a simplificar informações que antes eram complexas por meio de diagramas
simplificados e fáceis de entender. A Figura 4, a seguir, ilustra a interface da
ferramenta.
4
Licença que garante a liberdade de compartilhamento e modificação o software livre. Está disponível no
endereço: <https://www.gnu.org/>
5
Apresentação da ferramenta Visio, disponível no endereço da Microsoft:
<http://office.microsoft.com/pt-br/visio/>.
6
Site do fabricante da Ferramenta Visio, disponível em: < http://www.microsoft.com/pt-
br/default.aspx>.
37
Figura 4 - Interface da ferramenta Microsoft Visio 2010
Fonte: Microsoft.
2.4.2 Ferramenta Dia
A ferramenta case Dia7 é um software livre, disponibilizado sob os termos da

GNU e encontrado na SourceForge8 para download. Com grande aceitação por quem
utiliza por ser um software simples de se usar, é uma das ferramentas não comerciais
mais bem conceituadas atualmente. Apresenta uma característica muito importante, que
é o fato de ser multiplataforma, ou seja, funciona em Windows, Linux e Mac.
Segundo o fabricante DIA (2014), ele suporta mais de 30 diagramas diferentes,

contando, por exemplo, com fluxogramas, modelagem utilizando a linguagem UML e
organogramas. Serve para auxiliar os desenvolvedores de software na integração e na
7
Disponível para download no seguinte endereço: < http://sourceforge.net/projects/dia-installer/>
8
Repositório de software livre na web.
38
criação dos diagramas UML com a implementação da lógica. A Figura 5, a seguir,
ilustra a interface da ferramenta.
Figura 5 - Interface da ferramenta Dia
Fonte: Dia.
2.4.3 Ferramenta Enterprise Architect
A ferramenta EA9, cujo fabricante é a Sparx Systems10, é uma das ferramentas

mais baixadas atualmente no Superdownloads, que está disponível no endereço:
http://www.superdownloads.com.br/busca?q=uml&s=Windows, e será referência para a
continuação deste presente trabalho. Voltada para a área de engenharia de software, é
uma ferramenta de modelagem visual que compreende diversas notações, sobretudo na
linguagem UML, seguindo os princípios da OMG.
É um software pago, disponibilizando apenas um tempo de teste, entretanto é
extremamente completa em todos os aspectos: desde a parte de construção de sistemas
9
Ferramenta de modelagem baseada na linguagem UML. Disponível no endereço:
< http://www.sparxsystems.com/products/ea/index.html>
10
Site do fabricante da Ferramenta EA, disponível em: < http://www.sparxsystems.com/>.
39
de software; modelagem de processos de negócio até a geração de códigos em Java, C#,
C++, Python entre outros.
Segundo a Sparx Systems, a ferramenta que atualmente está na versão 11, é
baseada em padrões abertos, como na linguagem UML, BPMN e SysML. Possui
recursos avançados de simulação, ferramentas de teste, controle de versão,
gerenciamento de requisitos, análise e processamento de modelos. A interface do EA
pode ser vista na Figura 6 a seguir.
Figura 6 - Interface da ferramenta Enterprise Architect versão 9.0
Fonte: Elaboração dos autores (2014).
2.4.4 Draw.io
A ferramenta case Draw.io11 é uma solução web para modelagem de diversos

desenhos, especialmente diagramas. Solução essa que permite escolher para salvar os
desenhos com o Google Drive, pelo Dropbox, pelo próprio dispositivo físico ou similar
e também no próprio navegador, permitindo que se tenha uma cópia de segurança em
qualquer um destes ambientes.
11
Disponível para uso no seguinte endereço: <https://www.draw.io/>
40
Essa ferramenta, que necessita somente de uma conexão com a internet, é
gratuita e apresenta particularidades que se assemelham com o presente trabalho, pois é
uma solução de modelagem web, entretanto não faz a integração dos desenhos da
modelagem com a ferramenta desktop Enterprise Architect (EA), que será a proposta no
decorrer deste projeto.
A ferramenta apresenta uma interface simples e faz com que se torne de alta
usabilidade, permitindo ainda a exportação de formatos .JPG e .PNG. A interface do
draw.io pode ser vista na Figura 7 a seguir.
Figura 7 - Interface da ferramenta case Draw.io
Fonte: Página do draw.io.
2.5 JUSTIFICATIVA DA SELEÇÃO DA FERRAMENTA
Embora tivesse diversas ferramentas de modelagem disponíveis para utilização

na lista, sendo possível escolher uma entre as mais variadas características possíveis,
como ferramentas de modelagem via web, por desktop ou mobile, pagas ou gratuitas
para download, para este presente trabalho é usada a ferramenta CASE Enterprise
Architect (EA).
41
Os critérios de seleção foram de acordo com as características oferecidas pela
ferramenta, como usabilidade, eficiência, confiabilidade, custo benefício, por ser uma
ferramenta que preenchia os critérios atuais para modelagem UML, pelo fato de ser de
domínio do orientador e, sobretudo, maior conhecimento dos autores.
42
3 METODOLOGIA
Neste capítulo, é abordada a metodologia científica de pesquisa usada para o

desenvolvimento deste presente trabalho, assim como as etapas metodológicas, a
proposta de solução e suas delimitações.
Segundo Rodrigues (2006), a metodologia científica consiste no estudo, na geração
e na avaliação de diferentes métodos, das técnicas aplicadas e dos processos que são
utilizados na investigação e resolução de problemas, com o princípio de
desenvolvimento do conhecimento científico.
Para Demo (1987, p. 19-20, apud RODRIGUES, 2006, p. 19), a metodologia trata
das formas de se fazer ciência, cuidando dos procedimentos, das ferramentas e dos
caminhos.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
Demo (1996, p. 34, apud SILVA; MENEZES, 2005, p. 19) descreve a pesquisa
como uma “atividade cotidiana, considerando-a como uma atitude, um questionamento
sistemático crítico e criativo, mais a intervenção competente na realidade, ou o diálogo
crítico permanente com a realidade em sentido teórico e prático.”.
As pesquisas são classificadas de diversas formas, mas principalmente pela sua
natureza e sobre um ponto de vista para abordagem do problema. Assim, para o presente
trabalho, será estudada a pesquisa aplicada como natureza e a pesquisa qualitativa como
forma de abordagem do problema.
Segundo Silva e Menezes (2005), a pesquisa aplicada tem como objetivo obter o
conhecimento para a prática e para solução de problemas específicos.
Quanto à classificação do ponto de vista da forma de abordagem, a pesquisa
qualitativa será utilizada por não usar recursos e métodos estatísticos, fazendo com que
o pesquisador analise seus dados indutivamente.
43
3.2 ETAPAS METODOLÓGICAS
Para a sequência deste presente trabalho, foi necessário dividir, em etapas, todos
com o mesmo grau de importância, para que o objetivo final conseguisse ser alcançado.
A seguir, serão apresentadas, resumidamente, as etapas propostas para o
desenvolvimento:
Introdução: Esta etapa inicial é a definição do tema, problemática, objetivos

gerais, objetivos específicos e justificativos;
Levantamento Teórico: Nesta etapa, é realizado todo o levantamento teórico
para que seja dada continuidade no desenvolvimento do trabalho, sendo
realizadas pesquisas bibliográficas para esclarecer melhor os assuntos
pertinentes ao presente trabalho;
Análise da estrutura de dados da ferramenta Enterprise Architect: Para esta
etapa, será feito um estudo detalhado da performance da ferramenta e as
integrações que ela pode realizar com ferramentas externas;
Modelagem do sistema: Para esta etapa serão utilizados diagramas definidos
pela UML. A metodologia de desenvolvimento de software será a partir do
ICONIX, que tem como principais diagramas o de domínio, casos de uso,
robustez, sequência e classe;
Desenvolvimento do sistema: Essa etapa é realizada, após a modelagem, com
toda a fundamentação teórica obtida. Será a parte em que o sistema começa a
ganhar corpo através da codificação, testado e validado por profissionais
atuantes da área.
Validação: Essa será a última etapa do trabalho, em que serão apresentados os
resultados obtidos e a descrição deles.
3.3 PROPOSTA DE SOLUÇÃO
Apresentada como fundamentação teórica no capítulo 2 deste presente trabalho,

a modelagem de software se não for padronizada entre os desenvolvedores, será difícil
44
sua compreensão, pois trará um vocabulário específico para cada um. Nesse caso, será
usada a UML, pois, além de ser uma linguagem de padronização da modelagem, é
também de grande aceitação no mercado.
A proposta de solução para o presente trabalho tem por objetivo desenvolver um
sistema web que faça a modelagem de diagramas de caso de uso, utilizando a linguagem
UML, contando com uma arquitetura de software que busque auxiliar quem precisa
modelar diagramas fora de ambientes desktops, tornando-se dessa forma prático e com
maior disponibilidade.
A modelagem será possível fazer através de navegadores, sendo indispensável
então o uso da internet. Após a modelagem, o usuário poderá fazer a integração com a
ferramenta desktop EA. O usuário também poderá optar por fazer a modelagem dos
diagramas via desktop que será sincronizada com o sistema web, integrando com
ambientes web e locais.
A Figura 8, a seguir, ilustra em alto nível a arquitetura tecnológica da solução
que será disponibilizada para o usuário.
Figura 8 - Arquitetura de modelagem UML via browser.
Fonte: Os Autores (2014).
Trazendo a visão mais detalhada do processo, o usuário acessa o sistema web

através de um navegador. Efetua o cadastro, informando o Login e a senha para então
ser possível iniciar a sessão. Ao acessar o sistema web, o usuário vai abrir a página de
45
projetos e, em seguida, adicionar um novo projeto, sendo que esse passo pode ser
realizado tanto no sistema web, quanto na ferramenta Enterprise Architect, que é
desktop.
A próxima etapa em que o usuário vai navegar até a página denominada
Diagrama, pode então dar início a modelagem. Depois de criar a modelagem do
diagrama de caso de uso, a imagem modelada deve ser salva. Tendo salvado a
modelagem, automaticamente conecta-se ao banco de dados do EA. O usuário recebe
então uma mensagem com feedback da ação.
A Figura 9, a seguir, apresenta, em alto nível, o processo realizado pelo usuário
até a conclusão da modelagem.
Figura 9 - Processo realizado pelo usuário da ferramenta web.
Fonte: Os autores (2014).
46
3.4 DELIMITAÇÕES
Como apresentado na proposta de solução, o sistema tem seu foco de

modelagem na web, sendo a internet uma limitação de uso.
Para padronizar a modelagem na ferramenta web proposta, será utilizada a
notação UML. Entretanto, como esta linguagem possui 14 diagramas na versão 2.4.1 e o
projeto é grande, num primeiro momento, será dada ênfase apenas em um diagrama, que
será o Diagrama de Caso de Uso.
47
4 MODELAGEM DA PROPOSTA DE SOLUÇÃO
Este capítulo apresenta a modelagem do sistema proposto como solução. Serão

abordados alguns diagramas da modelagem Unified Modeling Language (UML) que,
segundo Martins (2002), é uma linguagem padrão para documentar projetos de
software.
Os diagramas que contemplam este capítulo são os que fazem parte do processo
de desenvolvimento de software ICONIX, sendo considerados diagramas utilizados
nesse processo de desenvolvimento: Diagrama de Caso de Uso; Diagrama de Domínio;
Diagrama de Robustez; Diagrama de Classe e Diagrama de Sequência.
Deve-se ressaltar que, neste capítulo, não será dada grande ênfase na questão de
embasamento teórico para os assuntos pertinentes à UML e ao ICONIX por já terem
sido tratados no capítulo 2.
4.1 ATORES
Segundo Bezerra (2003), qualquer interação que se tenha entre um elemento

externo e um sistema são denominados ator. A interação, que é citada pelo autor, seria a
troca de informações com o sistema, seja por envio ou recebimento.
O Quadro 1, a seguir, apresenta os atores do sistema proposto e suas respectivas
descrições.
Quadro 1 - Descrição dos atores do sistema.

Ator Descrição
Usuário Responsável por operacionalizar o uso do sistema. Tem acesso a
funcionalidades do sistema, exceto ao gerenciamento de projetos e
de usuários
Administrador Responsável por todas as funcionalidades do sistema. Tem acesso
completo, permitindo gerenciar os usuários do sistema, criar novos
projetos e novos diagramas.
Fonte: Os autores, 2014.
48
A Figura 10, a seguir, apresenta a hierarquia entre os atores.
Figura 10 - Atores do sistema proposto
4.2 REQUISITOS FUNCIONAIS
Os requisitos funcionais e não funcionais foram introduzidos na modelagem,

pois fizeram parte das análises realizadas pelos autores sobre o problema, culminando
de certa forma em ajuda na elaboração dos Casos de Uso.
Para Pressman (2011, p. 127), os requisitos funcionais “[...] fornecem o
mecanismo apropriado para entender aquilo que o cliente deseja, analisando as
necessidades, avaliando a viabilidade, negociando uma solução razoável, especificando
a solução sem ambiguidades, [...]”.
Para Bezerra (2002, p. 20), “um requisito é uma condição ou capacidade que
deve ser alcançada ou possuída por um sistema ou componente deste para satisfazer um
contrato, padrão, especificação ou outros documentos formalmente impostos.”.
Os requisitos funcionais levantados para o sistema proposto são apresentados a
seguir na Figura 11.
49
Figura 11 - Requisitos Funcionais
O Quadro 2, a seguir, lista os requisitos funcionais da ferramenta proposta:
Quadro 2 - Lista de Requisitos Funcionais do sistema proposto

REQUISITO DESCRIÇÃO
FUNCIONAL (RF)
RF001 Sistema deve permitir cadastrar projetos
RF002 Sistema deve permitir cadastrar usuários
RF003 Sistema deve controlar o acesso dos usuários
RF004 Sistema deve permitir o desenho de diagrama de Caso de Uso, segundo
definido na UML 2.4.1
RF005 Sistema deve fazer integração com banco de dados da ferramenta
Enterprise Architect versão 11
RF006 Sistema deve listar todos os diagramas de Caso de Uso, registrados na
ferramenta Enterprise Architect
RF007 Sistema deve permitir editar e excluir diagrama de Caso de Uso já
existente na ferramenta Enterprise Architect
RF008 Sistema deve permitir o relacionamento de usuário a um projeto
50
4.3 REQUISITOS NÃO FUNCIONAIS
Para Koscianski e Soares (2007, p. 179), “Os requisitos não-funcionais

descrevem restrições ao software de forma geral. Não são, portanto, relativos
diretamente às funções desempenhadas pelo produto.”.
Segundo Sommerville (2003, p.83), os requisitos não funcionais “são restrições
sobre os serviços ou as funções oferecidos pelo sistema. Entre eles destacam-se
restrições de tempo, restrições sobre o processo de desenvolvimento, padrões, entre
outros”.
Requisitos não funcionais se referem à qualidade e às restrições do
funcionamento do sistema. (SOMMERVILLE, 2011).
De acordo com a Figura 12 a seguir, são requisitos não funcionais para este
projeto:
Figura 12 - Requisitos Não Funcionais
O Quadro 3, a seguir, lista os requisitos não funcionais da ferramenta proposta
51
Quadro 3 - Lista de requisitos não funcionais do sistema proposto
REQUISITO NÃO DESCRIÇÃO
FUNCIONAL
(RNF)
RNF001 Deve ser possível acessar o sistema via web.
RNF002 O sistema deve ser compatível com o navegador Google Chrome, versão
37.
RNF003 Sistema deve executar em servidor Windows com .NET Framework 4.5.
RNF004 Sistema deve usar banco de dados SQL Serve Express 2014
RNF005 Em caso de problema de conexão, a ferramenta executa o rollback da
operação.
4.4 DIAGRAMA DE CASO DE USO
Para Bezerra (2003), os diagramas de caso de uso são visões externas do sistema
em que se tem um relacionamento representado por: Atores, casos de uso e
relacionamento entre eles.
Na opinião de Booch, Rumbaugh e de Jacobson (2000), “Os casos de uso podem
ser aplicados para captar o comportamento pretendido do sistema que está sendo
desenvolvido, sem ser necessário especificar como esse comportamento é
implementado.”.
A Figura 13, a seguir, apresenta os diagramas de caso de uso provenientes dos
requisitos funcionais e dos requisitos não funcionais, que se encontram nos itens 4.2 e
4.3, respectivamente.
52
Figura 13 - Diagramas de caso de uso
O quadro 4, a seguir, especifica o Caso de Uso “UC003 - Cadastrar Diagrama”.

Os demais casos de uso se encontram no APÊNDICE A – Detalhamentos dos casos de
uso.
Quadro 4 - Cadastrar Diagrama

Titulo UC003 - Cadastrar Diagrama
Pré- Precisa estar conectado como Usuário
Condição
Fluxos Listar
1. Usuário clica na opção Diagrama no menu.

2. Sistema exibe uma lista de projetos.
3. Usuário seleciona o projeto.
4. Sistema valida se projeto está selecionado
5. Sistema obtém os dados para conexão no EA
6. Sistema se conecta no bando de dados do EA
Exceção: 6a. Erro de conexão do banco de dados do EA
7. Sistema acessa o banco de dados do EA para obter a lista de todos os
Diagramas de Classe
8. Sistema direciona Usuário para a página de Diagrama
9. Sistema exibe uma lista de com todos os Diagramas
Base: 9a. Criar
53
Base: 9b. Excluir
Base: 9c. Alterar
Criar
1. Usuário clica em no botão Novo.

2. Sistema exibe o formulário de um novo Diagrama.
3. Usuário preenche as informações e clica em salvar.
4. Sistema valida as informações.
Exceção: 4a. Informações de formulário inválidas
5. Sistema obtém as informações para acessar o banco de dado do EA
6. Sistema se conecta no banco de dados do EA
7. Sistema salva os dados do novo diagrama no banco do EA
8. Sistema habilita painel para desenha diagrama
9. Usuário arrasta os elementos para o painel
10. Usuário clica no elemento.
11. Sistema abre formulário para edição dos detalhes do elemento
12. Usuário preenche os detalhes
13. Usuário faz as conexões entre os elementos
14. Usuário clica em salvar
15. Sistema converte o diagrama em formato da aplicação
16. Sistema valida todos os dados enviados
17. Sistema obtém as informações para acessar o banco de dado do EA
18. Sistema se conecta no banco de dados do EA
19. Sistema salva diagrama no EA
20. Sistema exibe mensagem de sucesso
Alterar
1. Usuário clica em Alterar no diagrama selecionado

2. Sistema obtém dados do projeto para conexão com o banco de dados
do EA
3. Sistema se conecta com o banco de dados do EA
4. Sistema busca dados no banco de dados do EA
5. Sistema converte dados para aplicação
6. Sistema exibe diagrama no painel de edição
7. Usuário edita o diagrama
8. Usuário arrasta os elementos da barra de menu para o painel de edição
9. Usuário clica no elemento
10. Sistema exibe formulário para editar os detalhes do elemento
11. Usuário edita os detalhes
12. Usuário cria conexões entre os elementos
13. Usuário clica em salvar
14. Sistema converte dados para aplicação
15. Sistema valida todos os dados
54
do EA
18. Sistema salva no banco do EA
Excluir
1. Usuário clica no botão Excluir no diagrama selecionado

2. Sistema exibe mensagem de confirmação
3. Usuário confirma a ação (clica no botão OK)
do EA
6. Sistema excluir o registro do banco de dados do EA
7. Sistema exibe mensagem de sucesso.
Erro de conexão do banco de dados do EA
1. Sistema não consegue se conectar no banco de dados do EA

2. Sistema exibe a mensagem "Não foi possível se conectar no Banco de
Dados do EA, por favor revisar os dados de cadastro do projeto."
Informações de formulário inválidas
1. Sistema identifica informações incorretas

2. Sistema exibe mensagem de Erro ao Usuário
4.5 DIAGRAMA DE DOMÍNIO
Para Blaha e Rumbaugh (2006, p. 189), o diagrama de domínio “mostra a

estrutura estática do sistema do mundo real e a organiza em partes utilizáveis.”. Assim,
o diagrama de domínio descreve os objetos do mundo real e seus relacionamentos.
A Figura 14, a seguir, apresenta o diagrama de domínio deste projeto.
55
Figura 14 - Diagrama de Domínio
4.6 DIAGRAMA DE ROBUSTEZ
O diagrama de robustez explica os comportamentos, relacionando-os ao modelo

de objeto. Análise de robustez consiste em analisar cada caso de uso e transformá-lo em
objetos.
A Figura 15, a seguir, apresenta o diagrama de robustez deste projeto.
56
Figura 15 - Diagrama de Robustez
57
4.7 DIAGRAMA DE CLASSE
Segundo Booch, Rumbaugh e Jacobson (2000, p. 104), os diagramas de classe

são compostos por um conjunto de classes, interfaces e colaborações e seus
relacionamentos.
Descrevem quais objetos e quais tipos de objetos que o sistema apresenta e os
relacionamentos estáticos entre eles, além disso, mostram as propriedades e as
operações de uma classe. (Fowler, 2005). Os diagramas de classe são considerados
visões estáticas de um sistema a partir de uma modelagem e são encontrados,
frequentemente, em sistemas orientados a objetos.
A Figura 16, a seguir, apresenta o diagrama de classe do sistema proposto
Figura 16 - Diagrama de Classe
58
4.8 DIAGRAMA DE SEQUÊNCIA
Silva et al. (2007) explicam que o maior objetivo no diagrama de sequência é

apontar o funcionamento do sistema em tempo de execução.
Segundo Martins (2002, p. 103), o diagrama de sequência “mostra a troca de
mensagens entre as classes na realização de um caso de uso. É utilizado para mostrar
como um cenário específico de um caso de uso será implementado”.
Um diagrama de sequência serve para mostrar os eventos gerados pelos atores
reconhecidos pelo sistema. (LARMAN, 1999). O diagrama de robustez serve como
referência para esse diagrama, pois descreve a sequência de funcionamento.
A Figura 17, a seguir, apresenta o diagrama de sequência do sistema proposto.
59
Figura 17 - Diagrama de Sequência
60
4.9 CONSIDERAÇÕES FINAIS
Neste capítulo, foram apresentados os diversos diagramas que compoem toda a

visão conceitual do futuro do sistema. Os diagramas seguiram o modelo ICONIX, por
terem como objetivo comunicar e avaliar o comportamento abstrato do sistema sob a
ótica de um usuário final.
O próximo capítulo aborda todos os detalhes técnicos das ferramentas que serão
utilizadas para o desenvolvimento da solução proposta.
61
5 DESENVOLVIMENTO DA PROPOSTA DE SOLUÇÃO
Neste capítulo, será apresentado o desenvolvimento da solução proposta e tudo que

está associado a este tema, como as questões técnicas necessárias para que o
desenvolvimento não sofra desvios, a forma que será apresentada, as ferramentas
utilizadas no processo de desenvolvimento, as tecnologias utilizadas, o procedimento
metodológico durante do desenvolvimento, algumas figuras que demonstrem um
protótipo do sistema e outros pontos.
5.1 TECNOLOGIAS E FERRAMENTAS
Para o desenvolvimento do sistema proposto, foram utilizadas ferramentas e

tecnologias que dessem todo o suporte necessário para se obter êxito no
desenvolvimento da ferramenta, e posteriormente na sua conclusão. Diante da
necessidade do cenário atual, foram utilizadas ferramentas sem custo obtidas com o
propósito de estudo e que os autores encontrassem mais facilidade e afinidade para o
desenvolvimento.
A Figura 18 a seguir ilustra as ferramentas utilizadas.
62
Figura 18 - Tecnologias utilizadas
No Quadro 5 a seguir, será feita uma breve descrição sobre as ferramentas

utilizadas e qual a real necessidade em utilizá-las.
Quadro 5 - Ferramentas utilizadas e suas necessidades

Tecnologia Breve Descrição Necessidade
Microsoft .NET O Microsoft .NET é um framework que A tecnologia se faz necessária
Framework versão 4.5 proporciona uma variedade de serviço para para o uso do C#.
diversos aplicativos em execução. Também
oferece uma biblioteca de classes que os
desenvolvedores podem utilizar para a
criação do seu aplicativo.
C# C# é uma linguagem de desenvolvimento Linguagem escolhida a partir do

orientada a objeto, compatível com o conhecimento técnico dos
Microsoft .NET Framework. Com ela é autores.
possível criar aplicações robustas e seguras.
JavaScript JavaScript é uma linguagem de Recurso essencial para a
programação baseada em scripts, é construção do Editor de Caso de
executada em cliente-side. Uso.
CSS O Cascading Style Sheets (CSS) é Por questões de boas práticas e

composta por camada, é utilizada para a aos recursos que possibilitam
63
definição de apresentação de elementos de melhorar a visualização da
uma página web. Sua maior vantagem é aplicação.
efetuar a separação entre o formato e o
conteúdo da página.
HTML 5 HyperText Markup Language (Linguagem Devido ao sistema ser web a

de marcação de hipertexto), ou seja, o linguagem se torna fundamental.
HTML, é utilizada em grande parte de das
aplicações web. Sua principal característica
são as TAG compostas por comando em
inglês ou numérico que permitem estruturar
o conteúdo.
Microsoft Visual Microsoft Visual Studio, é uma IDE que A IDE auxilia no
Studio 2013 proporciona desenvolver aplicativos para a desenvolvimento da aplicação,
plataforma Microsoft .NET, também podendo proporcional muita
utilizada para criação e gerenciamento do agilidade.
banco de dados SQL Server.
Microsoft SQL Server É o principal serviço para processamento, A escolha se deu pela
2008 segurança e armazenamento de dados. compatibilidade com o
Enterprise Architect e .NET
Framework.
Enterprise Architect A ferramenta desenvolvida pela Sparx Principal ferramenta que faz a
System, a ferramenta permite o integração entre web/desktop.
desenvolvimento da modelagem UML. A
ferramenta foi utilizada para a modelagem
do sistema e a própria integração.
JSUML2 JSUML2 é uma biblioteca de JavaScript A biblioteca potencializou em

com licença de código fonte aberta cujo a grande parte o desenvolvimento,
licença é licença GNU GPL v3. economizamos muito tempo na
Desenvolvida por estudantes da criação do Editor.
universidade de Códoba, Espanha, a
biblioteca disponibiliza as ferramentas para
a criação de caso de uso, com todos os
elementos.
Visual Studio Online Se trata de um repositório que faz o Para controle e segurança do
controle e versionamento do código fonte, o nosso projeto, todo o código
seu uso é grátis até 5 usuários e seu serviçofonte ficou armazenado nesse
fica na nuvem. repositório, a escolha por essa
ferramenta foi por conta da sua
integração com o Visual Studio
e a facilidade de administrar.
Bolsamiq Mopckups Software proprietário de prototipação de Foi usado para modelar os
tela. Serve para modelar interfaces desktop, protótipos que se encontram no
web e mobile. apêndice B.
64
5.2 HISTÓRICO DE DESENVOLVIMENTO
A maior preocupação durante o desenvolvimento do sistema foi a integração com

as tabelas do banco do Enterprise Architect, o não conhecimento da estrutura dificultou
e criou barreiras que atrasaram um pouco o desenvolvimento. A forma que foi
encontrada para vencer essas dificuldades foi criando diagramas e elementos na
ferramenta do Enterprise Architect e verificando como construía no banco de dados.
Para cada item desenvolvido nessa integração, foram testadas todas as criações de casos
de uso, com o objetivo de garantir que não se criasse nenhum outro problema.
O posicionamento dos elementos foi a maior dificuldade do projeto, houve a
necessidade de vários testes de criação dos elementos de ambas as ferramentas para
entender qual diferença entre as duas, após identificar a diferença precisou-se fazer
algumas conversões de posicionamento para que possa ficar corretos nas duas
ferramentas.
Após vencer a parte inicial, criaram-se os CRUD (Create, Read, Update e Delete)
e o controle de acesso. Apesar de o projeto requerer grande esforço dos autores, o
desenvolvimento de outras funcionalidades foi fácil, desenvolvendo o restante do fluxo
do sistema, possibilitando posteriormente a validação com usuários acima dessas
funcionalidades. A partir disso, gerou-se uma demanda de melhorias que ajudariam o
uso melhor das funcionalidades. Uma imagem do código fonte da ferramenta está
disponível no Apêndice D.
5.3 APRESENTAÇÃO DO SISTEMA
Nesta sessão serão exibidas as telas do sistema com suas funcionalidades e

propostas concluídas. Uma breve comparação da tela do sistema atual poderá ser feita
com os protótipos de tela modelados no Apêndice B.
A Figura 19 a seguir demonstra a introdução da ferramenta, ou seja, onde a tela
inicial do sistema sempre será exibida quando acessar a URL do site. A partir do
65
primeiro acesso, será possível escolher as opções de navegação do site, as opções de
projeto e diagrama só serão exibidas após o usuário realizar o login.
Figura 19 - Tela de introdução da ferramenta
Para usuários que não possuem Login, o sistema permite fazer o cadastro de
novos usuários. O preenchimento de todos os campos é obrigatório, caso o usuário tente
registrar sem o preenchimento completo do formulário, o sistema bloqueia a ação e
exibe as mensagens para orientar o usuário. Quando o cadastro for realizado com
sucesso, o usuário já fica conectado ao sistema, a funcionalidade será representada na
Figura 20 a seguir com a interface do sistema pode ser comparado ao protótipo que se
encontra no Apêndice B – TEL001 – Formulário de Usuário.
66
Figura 20 - Tela para cadastrar usuário
A Figura 21 a seguir deve servir aos usuários que já possuem acesso, bastando
preencher o formulário com o login e senha correta para se conectar ao sistema. A
Figura 21 com a interface do sistema pode ser comparado ao protótipo que se encontra
no Apêndice B – TEL008 - Confirmar Operação.
67
Figura 21 - Tela Fazer Login
O próximo passo quando o usuário se conecta no sistema é selecionar o projeto

que ele deseja visualizar. O sistema apresentara uma lista com todos os projetos
disponíveis para o usuário conectado. A representação dessa funcionalidade está sendo
apresentado na Figura 22 a seguir.
68
Figura 22 - Tela Selecionar Projeto
O cadastro de projetos só está disponível para usuários com perfil de

Administrador, a opção no menu fica escondida quando o usuário não tem esse
privilégio.
O Administrador vai contar com uma lista de todos os projetos cadastrados no
sistema, dessa forma ele pode criar novos, alterar ou excluir.
A Figura 23 a seguir mostra os projetos cadastrados, sendo possível sua
comparação com o protótipo no Apêndice B – TEL005 – Listar Projeto.
69
Figura 23 - Tela Projetos Cadastrados
No formulário de projetos é importante ressaltar o relacionamento com os

usuários que poderão selecionar esse projeto para a manutenção. Essa funcionalidade
será exibida logo após o cadastro do projeto ou na alteração, todos os usuários do
sistema ficam disponíveis para vincular com o projeto.
A Figura 24 a seguir representa a interface de formulário dos projetos e pode ser
comparado ao seu protótipo que se encontra no Apêndice B – TEL004 – Novo Projeto.
70
Figura 24 - Tela Formulário de Projetos
Na Figura 25 a seguir está a lista de diagramas cadastrados no banco de dados

Enterprise Architect cuja conexão foi encolhida anteriormente. As funcionalidades de
novos registros, alterar e excluir estão à disposição do usuário, qualquer uma dessas
ações faz a alteração direta no banco de dados do Enterprise Architect.
A Figura 25 pode ser comparada ao seu protótipo que se encontra no Apêndice
B – TEL006 – Listar Diagrama.
71
Figura 25 - Tela Lista de Diagramas
Para a criação de um novo diagrama o primeiro passo é cadastrá-lo no banco de

dados do Enterprise Architect, para que essa ação seja feita é necessário um nome e a
seleção de um pacote disponível.
A Figura 26 a seguir apresenta a tela de formulário dos diagramas.
72
Figura 26 - Tela Formulário de Diagramas
Na continuação, a tela com o editor de caso de uso. O usuário vai ter a

disposição todos os elementos para a criação do seu caso de uso bastam clicar no
elemento desejado, e em seguida clicar no painel, o elemento é criado. Nenhuma
alteração é feita no banco de dados do Enterprise Architect até que o botão Salvar seja
pressionado.
Importante lembrar que também será possível editar diagramas já criados nos
Enterprise Architect, basta selecionar o Editor na lista de diagramas, e a ferramenta
monta todo o diagrama de caso de uso idêntico ao construído no Enterprise Architect.
A Figura 27 a seguir mostra a tela de modelagem que o sistema propõe,
possibilitando a modelagem dos diagramas de Caso de Uso.
73
Figura 27 - Tela de modelagem do Caso de Uso.
5.4 VALIDAÇÃO OU AVALIAÇÃO DA PROPOSTA
Após a conclusão da ferramenta web, a validação se dividiu em duas etapas,

sendo que a primeira foi realizada pelos próprios autores, objetivando a identificação de
possíveis falhas, mapeando-as e corrigindo em tempo hábil para sua publicação.
74
A segunda etapa de validação foi realizada por 5 potenciais usuários da
ferramenta, os quais estão relacionados com o assunto. Esses usuários foram convidados
a testar e avaliar a ferramenta através de um questionário, o qual foi entregue a eles.
Esse questionário foi elaborado com o objetivo de avaliar características
essenciais para o bom funcionamento da ferramenta, como sua consistência, a
eficiência, satisfação, facilidade e a usabilidade. Ao final foi registrado se os usuários
recorreram ajuda aos autores e quais suas críticas ou sugestões.
O questionário aplicado aos usuários dividiu-se em três etapas. A primeira
relacionada a identificação dos usuários, sendo que foram feitas perguntas como suas
funções atuais, idade, formação e cargo. A segunda etapa é responsável por coletar
afirmações, os quais foram divididas em 4 alternativas (1 – Insatisfeito; 2 – Pouco
satisfeito; 3 – Satisfeito; 4 – Muito Satisfeito) e os convidados só poderiam escolher
uma opção. Esta etapa serve para os autores terem percepção da estruturação da
ferramenta, conforme afirmações feitas pelos convidados. O questionário aplicado
encontra-se no apêndice E. A terceira etapa do questionário realizou-se com perguntas
onde as respostas se caracterizavam em forma descritiva, como as críticas e as
sugestões.
As assertivas do questionário dividiram-se em 5 aspectos. A primeira sessão
relaciona-se com a consistência, conforme tabela 1 a seguir:
Tabela 1 - Consistência da ferramenta

Avaliação 1 2 3 4
Consistência
Qual o grau de satisfação em relação a ferramenta no que diz 20% 80%
respeito a apresentação de erros que não permitem concluir o
restante do processo?
O comportamento da ferramenta sempre é o mesmo 20% 80%
Ao analisar os dados retornados na tabela 1, pode-se entender que os usuários que

avaliaram a ferramenta consideraram a consistência boa, trazendo 80% dos indicadores
como muito satisfeitos.
75
A sessão 2 está relacionada a eficiência, conforme tabela 2 a seguir:
Tabela 2 - Eficiência da ferramenta

Avaliação 1 2 3 4
Eficiência
Qual o grau de satisfação em relação às operações 80% 20%
executadas no sistema?
Qual o grau de satisfação em relação à rapidez na busca das 80% 20%
informações do sistema (quantidade de cliques)
Ao analisar os dados retornados na tabela 2, pode-se entender que os usuários

avaliaram a ferramenta como eficiente.
A sessão 3 está relacionada a satisfação, conforme tabela 3 a seguir:
Tabela 3 – Satisfação com a ferramenta

Avaliação 1 2 3 4
Satisfação
Diante da problemática apresentada, qual a sua satisfação 100%
com a ferramenta?
Você usaria essa ferramenta fora do ambiente corporativo? 80% 20%
Ao analisar os dados retornados na tabela 3, concluiu-se que os usuários

avaliaram como satisfeitos a ferramenta.
A sessão 4 está relacionada a facilidade, conforme tabela 4 a seguir:
Tabela 4 – Facilidade da ferramenta

Avaliação 1 2 3 4
Facilidade
Qual o grau de satisfação em relação a exigência que o 100%
usuário tem e a necessidade de treinamentos para utilizar?
O sistema oferece condições de atender toda a problemática? 80% 20%
Ao analisar os dados referentes à tabela 4, conclui-se que os avaliadores acharam

fácil utilizar a ferramenta.
76
A sessão 5 está relacionada a usabilidade, conforme a tabela 5 a seguir:
Tabela 5 – Usabilidade da Ferramenta

Avaliação 1 2 3 4
Usabilidade
Qual o grau de satisfação em relação à criação de um novo 80% 20%
projeto?
Qual o grau de satisfação em relação à criação de novos 20% 80%
diagramas?
Qual o grau de satisfação em relação ao cadastro de novos 100%
usuários?
Ao analisar os dados referentes a tabela 5, conclui-se que os usuários avaliaram

como muito satisfeitos em relação a usabilidade.
De uma forma geral, a ferramenta proposta foi considerada boa, de grande aplicação
para usuários da área e que se sentiram satisfeitos com a usabilidade oferecida. Não
houve grandes questionamentos a respeito do uso da ferramenta. Ao final do
questionário oferecido aos usuários, foram registradas críticas e quais sugestões eles
teriam para acrescentar para trabalhos futuros, e algumas destacadas foram:
Como crítica, foi descrito que a ferramenta retornou um erro na hora de

cadastrar um novo projeto (mapeado o problema e corrigido);
Como sugestão, foi descrito que é preciso trabalhar mais a parte da
documentação da ferramenta;
Como elogio, usuários descreveram que a ferramenta vem a ajudar as
organizações, especialmente os analistas.
O próximo capítulo aborda as conclusões que os autores tiveram em relação a este

trabalho de conclusão de curso e quais expectativas para trabalhos futuros.
77
6 CONCLUSÕES E TRABALHOS FUTUROS
Neste capítulo serão descritas as conclusões que os autores obtiveram a respeito

do desenvolvimento deste trabalho de conclusão de curso, assim como as dificuldades
encontradas para que esta ferramenta fosse concluída a tempo para atender a sua
proposta. Também são expostas sugestões para trabalhos futuros que envolvam
melhorias ou até mesmo sugestões de novas demandas.
6.1 CONCLUSÕES
Para este trabalho de conclusão de curso, entendeu-se a necessidade de usuários

que utilizam ferramentas desktop para modelagem de software utilizando diagramas
UML, buscando desta forma o desenvolvimento de uma ferramenta web que venha a
facilitar esses usuários a utilizarem esta ferramenta em diversos lugares sendo a única
exigência um computador com acesso a internet.
De início os autores foram em busca de embasamentos teóricos no que diz
respeito à engenharia de software e todos seus fundamentos, principalmente na área de
modelagem de software, UML e as ferramentas que se propõem a fazer as modelagens
de diagramas UML.
A partir disto, foi possível articular a teoria com a prática, partindo para o
desenvolvimento da ferramenta proposta. Embora durante a pesquisa se tenha diversas
tecnologias para que fosse possível a implementação, essa flexibilidade foi absorvida e
partiu-se para a utilização de ferramentas que os autores tivessem mais contato e
domínio.
Implicou-se desta forma que o conjunto escolhido atendeu todas as necessidades
dos autores para o desenvolvimento, reduzindo significativamente o tempo e o custo
para desenvolvimento do protótipo.
Para que o projeto pudesse ser concluído sem maiores prejuízos, a partir de certo
momento foi necessário maior planejamento entre a equipe. As tarefas foram divididas
entre os autores, enquanto um dava prioridade na parte teórica e toda sua condução com
78
a escrita, o outro se empenhava em estudar as partes técnicas do desenvolvimento da
ferramenta.
A validação da ferramenta foi feita, principalmente, por analistas de sistemas,
estudantes e professores da área. Todos eles têm ou já tiveram certo contato com a
modelagem de diagramas UML. De uma forma geral, pode-se observar que a
ferramenta atende as expectativas e aos objetivos propostos neste trabalho de maneira
satisfatória.
6.2 TRABALHOS FUTUROS
Levando em consideração que a ferramenta desenvolvida é um protótipo, listam-

se abaixo sugestões futuras feitas pelos autores e pelos avaliadores da ferramenta:
Desenvolver uma interface para browser mobile ou aplicativos para celulares e

tablets. Desta forma, a ferramenta se tornará mais versátil, tornando-a de uso
mais prático.
A implementação de outros diagramas. Segundo a OMG, na versão 2.4.1

existem 14 diagramas, dos quais apenas um foi desenvolvido na nossa proposta.
Outros diagramas, como de domínio e requisitos agregariam na modelagem
como um todo, auxiliando o usuário com mais informações do projeto.
A criação e manipulação dos cenários na modelagem de caso de uso, a

funcionalidade permite o maior detalhamento do diagrama e auxilia o usuário a
entender melhor as modelagens existentes.
A criação de Logs para cada ação realizada na ferramenta, permitindo um

controle melhor das alterações.
Nos diagramas de caso de uso, implementar a funcionalidade para anexar

arquivos, desta forma a ferramenta deixa incluir protótipos de tela.
79
REFERÊNCIAS BIBLIOGRÁFICAS
BARROS Jr., Rafael. A competição e a ética nas empresas. Disponível em:

<http://www.barrospesquisa.com.br/artigos/competicao_etica_nas_empresas.pdf>.
Acesso em: 29 de março de 2014 às 20h32min.
BEZERRA, Eduardo; Princípios de análise e projetos de sistemas com UML. Rio de
Janeiro: Ed. Campus, 2003.
BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos
com UML 2. São Paulo: Campus 2006.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia de Usuário.

Rio de Janeiro: Ed. Campus. 2000
DIA. Introdução. Disponível em: <http://dia-installer.de/doc/en/index.html> Acesso
em: 06 mai. 2014.
FOWLER, Martin. AUML Essencial: Um breve guia para a linguagem-padrão de
modelagem de objetos. 3. ed. Porto Alegre: Bookman, 2005.
GROFFE, Renato José. Modelagem de sistemas através de UML: uma visão geral.
Disponível em: <http://www.devmedia.com.br/modelagem-de-sistemas-atraves-de-uml-
uma-visao-geral/27913>. Acesso em: 26 abr. 2014.
Institute of Eletrical and Electronics Engineers. What is Software Engineering?
Disponível em: < http://www.computer.org/portal/web/swebok/html/ch1>. Acesso em:
04 mai. 2014.
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software: aprenda
as metodologias e técnicas mais modernas para o desenvolvimento de software. 2.ed.
São Paulo: Novatec, 2007.
LARMAN, Craig. Utilizando UML e padrões: Uma introdução à análise e ao projeto

orientados a objetos. São Paulo: Ed. Bookman. 1999.
MAFFEO, Bruno. Engenharia de Software e especificação de sistemas: Soluções
para quem necessita da informação para agir. Rio de Janeiro: Ed. Campus, 1992.
MARTINS, José Carlos Cordeiro. Gestão de projetos de desenvolvimento de
software. Rio de Janeiro: Ed. Brasport. 20002.
MICROSOFT. Principais recursos do Visio. Disponível em: <
http://office.microsoft.com/pt-br/visio/recursos-populares-do-microsoft-visio-2013-
software-de-diagramas-FX103796044.aspx>. Acesso em: 23 abr. 2014.
MOGGI, Jair. Sinergia como fator de excelência empresarial. Disponível em:
<http://www.adigo.com.br/br/artigos.asp?mode=show&ID=54>. Acesso em: 05 de abril
de 2014 às 14hrs30min.
80
OBJECT MANAGEMENT GROUP. Documents Associated With Unified Modeling
Language (UML), V2.4.1. Disponível em: <
http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF> Acesso em: 22 abr. 2014.
PALACIOS, Paulo Henrique. Porque informatizar seu negócio. [2003]. Disponível

em: <http://www.portaldepostos.com.br/paginas/gest.materia6.html>. Acesso em: 02 de
abril de 2014 às 22h35min.
PETERS, James F.; PEDRYCZ, Witold. Engenharia de Software: Teoria e Prática.
Rio de Janeiro: Campus, 2001.
PRESSMAN, Roger S. Engenharia de Software: Uma abordagem profissional. 7 ed.
São Paulo: Brookman, 2011.
RODRIGUES, Auro de Jesus. Metodologia Científica: Completo e essencial para a
vida universitária. São Paulo: Ed. Avercamp, 2006.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de

Janeiro: Ed. Campus. 1994.
SILVA, Alex de Araújo; GOMIDE, Carlos Francisco; PETRILLO, Fábio. Metodologia
e projeto de software. São Paulo: Ed. Érica. 2003
SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da pesquisa e
elaboração de dissertação. 4 ed. Florianópolis: UFSC, 2005.
SILVA, Elcio. Engenharia de Software (2006). Disponível em:

<http://imasters.com.br/artigo/3691/software/engenharia-de-software/> Acesso em: 02
mai. 2014.
SILVA George; SILVA, Gilbert; GUIMARÃES, Gabriel; MEDEIROS, Rodrigo;
ROSSINI, Tiago. Utilizando ICONIX no desenvolvimento de aplicações Delphi.
Artigo, 2007. Disponível em:
<http://www.redenet.edu.br/publicacoes/arquivos/20080212_080829_INFO-067.pdf>.
Acesso em: 11 Ago. 2014.
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley,
2003.
SOUZA, Thiago Carvalho de. Introdução ao Iconix – Revista SQL Magazine 94.
Disponível em: <http://www.devmedia.com.br/introducao-ao-iconix-revista-sql-
magazine-94/23020.> Acesso em: 12 jun. 2014.
SPARX SYSTEMS. Enterprise Architect Disponível em:
<http://www.sparxsystems.com/> Acesso em 05 mai. 2014.
SWEBOK v3 Guide to the Software Engineering Body of Knowlegment, 2013.
Disponível <http://www.computer.org/portal/web/swebok.< Acesso em: 12 de set de
2014.
TAURION, Cesar. A importância da TI nas estratégias de negócio. [2013].

Disponível em: <http://idgnow.com.br/blog/tecnologia/2013/11/28/a-importancia-da-ti-
nas-estrategias-de-negocio/>. Acesso em: 23 de março de 2014 às 17h25min.
81
VIEIRA, Raphael H. Modelagem de software – A importante tarefa na Modelagem
de Objetos no Desenvolvimento de Sistemas. Disponível em: <
http://www.tiespecialistas.com.br/2014/02/modelagem-de-software-importante-tarefa-
na-modelagem-de-objetos-desenvolvimento-de-sistemas/>. Acesso em: 05 de abril de
2014 às 15hrs50min.
WIKIPEDIA, List of Unified Modeling Language tools. Disponível em:
<http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools>. Acesso em:
15 de Ago de 2014 às 17h19min.
82
APÊNDICES
83
APÊNDICE A – DETALHAMENTO DOS CASOS DE USO
Titulo UC002 - Cadastrar Projeto

Pré- Precisa estar conectado como Administrador.
Condição
Fluxos Listar
1. Usuário clica em Projeto na barra de menu Usuário
2. Sistema exibe uma lista de projetos
Básico: 2a. Criar
Alternativo: 2b. Excluir
Básico: 2c. Alterar
Criar
1. Administrador clica no botão Novo Usuário
2. Sistema exibe formulário de Novo Projeto
3. Administrador preenche todos os campos do formulário Usuário
Exceção: 3a. Erro nas informações do formulário
4. Administrador clica em salvar Usuário
5. Sistema valida as informações do formulário
6. Sistema salva as informações no banco de dados da aplicação
Alterar
1. Administrador clica no botão alterar ao lado do projeto escolhido
2. Sistema exibe formulário de alteração com os dados do projeto
selecionado
3. Administrador altera os dados necessários
4. Administrador clica em salvar
5. Sistema valida dos dados
Exceção: 5a. Erro nas informações do formulário
6. Sistema salva os dados no banco de dados da aplicação
7. Sistema apresenta mensagem de sucesso
Excluir
1. Administrador clica no botão de Excluir na mesma linha do Projeto
escolhido
2. Sistema apresenta mensagem de confirmar
3. Administrador confirma a operação
4. Sistema exclui o registro do banco de dados da aplicação
Erro nas informações do formulário

1. Sistema identifica erros nos dados preenchidos no formulário
2. Sistema exibe mensagem de erro para o Usuário.
84
Caso de Uso: UC002 – Cadastrar Projeto.
Titulo UC001 – Login

Pré-
Condição
Fluxos Login
1. Usuário acessa à aplicação
2. Usuário clica em login
3. Usuário preenche login e senha. Após clica em Salvar.
4. Sistema valida o acesso aos dados de acesso.
Exceção: 4a. Acesso negado
5. Sistema cria sessão do Usuário
6. Sistema retorna para a página anterior
Acesso negado
1. Sistema retorna mensagem de acesso negado
Caso de Uso: UC001 – Login.

Titulo UC004 - Cadastrar Usuário

Condição
Fluxos Listar
1. Administrador clica na opção Usuários na barra de menu Administrador

2. Sistema exibe uma lista com todos os usuários do sistema
Base: 2a. Criar
Base: 2b. Alterar
Criar
1. Administrador clica no botão Novo Administrador
2. Sistema exibe formulário de novo usuário
3. Administrador preenche os campos do formulário Administrador
4. Administrador clica no botão Salvar Administrador
5. Sistema valida dados enviados do formulário
Exceção: 5a. Erro nas informações informadas no formulário
6. Sistema salva informações no banco de dados da aplicação
85
Alterar
1. Administrador clica Alterar na barra de menu Administrador
2. Sistema exibe o formulário de usuário com os dados do registro
selecionado já preenchido
3. Administrador altera as informações
4. Administrador clica no botão salvar
5. Sistema valida os dados enviados do formulário
Exceção: 5a. Erro nas informações informadas no formulário
6. Sistema salva os dados no banco de dados
7. Sistema envia mensagem de sucesso
Excluir
1. Administrador clica no botão excluir ao lado do registro escolhido.
Administrador
2. Sistema exibe mensagem de confirmação Administrador
3. Administrador confirma operação.
4. Sistema exclui registro do banco de dados
Erro nas informações do formulário

1. Sistema identifica erros nos dados preenchidos no formulário
2. Sistema exibe mensagem de erro para o Usuário.
Caso de Uso: UC004 – Cadastrar Usuário.

Titulo UC005 - Relacionar Projeto com Usuário

Condição
Fluxos Listar
1. Administrador no botão Projetos do Usuário
2. Sistema busca no banco de dados da aplicação uma lista com todos os
projetos do usuário
3. Sistema exibe a lista na tela
Alternativo: 3a. Excluir
Alternativo: 3b. Criar
Criar
1. Administrador clica no botão Novo
2. Sistema direciona usuário para o formulário de relacionado de projetos
do usuário
3. Sistema carrega a lista com todos os projetos disponíveis
4. Administrador seleciona um projeto e clica em salvar
5. Sistema valida duplicidade (Pesquisa no banco de dados por outros
registros com o mesmo projeto e usuário)
86
Excluir
1. Administrador clica em excluir ao lado do registro selecionado
2. Sistema exibe mensagem de confirmação
3. Administrador clica em confirmar.
4. Sistema exclui registro do banco de dados
5. Sistema remove registro da fila
Caso de Uso: UC005 – Relacionar Projeto com Usuário

87
APÊNDICE B – PROTÓTIPOS DE TELA
Protótipo de Tela: TEL001 - Formulário de Usuário.

88
Protótipo de Tela: TEL002 - Listar Usuário.
Protótipo de Tela: TEL003 - Adicionar Usuário no Projeto.

89
Protótipo de Tela: TEL004 - Novo Projeto.
Protótipo de Tela: TEL005 - Listar Projeto.

90
Protótipo de Tela: TEL006 - Listar Diagrama.
Protótipo de Tela: TEL007 - Confirmar Operação.

91
Protótipo de Tela: TEL008 - Confirmar Login.
92
APÊNDICE C – CRONOGRAMA
Cronograma
Atividades Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Escolha do Tema e da equipe - 1ª Entrega x
Encontros para orientação x x x x x x x x x x X
Entrega do capítulo 1 - 2ª Entrega x
Entrega do Sumário + Capítulo 2 - 3ª Entrega x
Apresentação do Projeto + Capítulo 3 - 4ª Entrega x
Entrega dos capítulos 1, 2 e 3 para avaliador externo - 5ª Entrega x
Participação Defesa TCC2 x
Participação Defesa TCC2 x
Entrega dos capítulos 1, 2, 3, 4 - 6ª Entrega x
Revisão Bibliográfica x x
Plano de Ensino TCC 2 x
Entrega Cronograma 2 – 1ª Entrega x
Correções Avaliador Externo – 2ª Entrega x
Entrega impressa do capítulo de Modelagem – 3ª Entrega x
Verificação de Desenvolvimento – 4ª Entrega x
Apresentação e entrega impressa do desenvolvimento – 5ª Entrega x
Verificação das normas da ABNT – 6ª Entrega x
Definição da banca 28/10 x
Entrega da monografia 04/11 x
Defesa do TCC 12/11 x
Entrega FINAL da monografia 02/12 x
93
APÊNDICE D – CÓDIGO
94
APÊNDICE E – QUESTIONÁRIO
Qual a sua profissão?

( ) Analista ( ) Coordenador ( ) Projetista ( ) Estudante
Qual a sua Função?
Qual a sua idade?

( ) 18 - 28 ( ) 29 - 40 ( ) 40 - ou mais.
Qual sua formação?
( ) Superior ( )Superior Incompleto ( ) Pós Graduação ( ) Mestrado ( ) Doutorado.
Responda o questionário abaixo, com base nos testes executados no sistema UML Discovery.
1 – Insatisfeito
2 - Pouco Satisfeito
3 – Satisfeito
4 – Muito Satisfeito
Avaliação 1 2 3 4
Consistência
Qual o grau de satisfação em relação a ferramenta no que diz
respeito a apresentação de erros que não permitem concluir o
restante do processo?
O comportamento da ferramenta sempre é o mesmo
Usabilidade
Qual o grau de satisfação em relação à criação de um novo
projeto?
Qual o grau de satisfação em relação à criação de novos
diagramas?
Qual o grau de satisfação em relação ao cadastro de novos
usuários?
Satisfação
Diante da problemática apresentada, qual a sua satisfação com a
ferramenta?
Você usaria essa ferramenta fora do ambiente corporativo?
Facilidade
Qual o grau de satisfação em relação a exigência que o usuário
tem e a necessidade de treinamentos para utilizar?
O sistema oferece condições de atender toda a problemática?
Eficiência
Qual o grau de satisfação em relação às operações executadas no
sistema?
Qual o grau de satisfação em relação à rapidez na busca das
informações do sistema (quantidade de cliques)
Caso você tenha algum comentário, critica, e/ou sugestão sobre este sistema, registre-o neste
espaço.
95

Eduardos Gabriel PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Eduardos Gabriel PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO SUL DE SANTA CATARINA

EDUARDO CLAUMANN NEIS

GABRIEL DIAS JUNCKES

FERRAMENTA WEB PARA MODELAGEM DE DIAGRAMAS UML COM

GABRIEL DIAS JUNCKES

FERRAMENTA WEB PARA MODELAGEM DE DIAGRAMAS UML COM

Trabalho de Conclusão de Curso apresentado

Orientadora: Profª. Vera Rejane Niedersberg Schuhmacher, Msc.

Coorientador: Prof. Jean Carlos Rossa Hauck, Dr.

GABRIEL DIAS JUNCKES

FERRAMENTA WEB PARA MODELAGEM DE DIAGRAMAS UML COM

Este Trabalho de Conclusão de Curso foi julgado

Eduardo Claumann Neis

Agradeço acima de tudo a Deus, por ter me dado saúde, sabedoria e

Gabriel Dias Junckes

A Tecnologia da Informação (TI) se evidencia pelo crescente destaque nas

Palavras chaves: Ferramenta Web, Diagramas de Caso de Uso, Modelagem de

The Information Technology (IT) is evidenced by the increasing prominence in

Keywords: Web Tool, Use Case Diagram, Software Modeling.

Figura 1 - Camadas da Engenharia de Software............................................................. 22

Quadro 1 - Descrição dos atores do sistema. .................................................................. 48

Tabela 1 - Consistência da ferramenta ........................................................................... 75

CASE - Computer-Aided Software Engineering

O mundo atual está tecnologicamente acirrado demais, onde organizações

O contexto do mercado atual exige softwares sofisticados a custos de

O desenvolvimento de um software para cobrir alguma necessidade, em

1.2.1. Objetivo Geral

Desenvolver e avaliar uma ferramenta web para modelagem de diagramas

1.2.2. Objetivos Específicos

investigar a importância da modelagem para o desenvolvimento de

A realização de testes nos softwares remete a real necessidade de se planejar

1.4. ESTRUTURA DA MONOGRAFIA

Este trabalho encontra-se dividido em 6 (seis) capítulos. O primeiro capítulo

Neste capítulo, são abordados diversos assuntos pertinentes à área de engenharia

2.1 ENGENHARIA DE SOFTWARE

A definição para engenharia de software, segundo BAUER (1972, apud

Figura 1 - Camadas da Engenharia de Software

Autor: Pressman (2011, p. 39).

Pode-se, então, entender que o objetivo dos modelos abstratos da engenharia de

A chamada crise do software, “[...], que começou a ser utilizada já na década de

Segundo Naur e Randell:

Para ser eficaz, o desenvolvimento de sistemas de software exige uma

Ainda, assim, a ES é uma disciplina relativamente nova para Sommerville

Segundo Peters e Pedrycz (2001), a ES é uma aproximação de engenharia

2.2 ARQUITETURA E MODELOS DE SOFTWARE

2.2.1 Arquitetura de Software

Segundo Silva, Gomide e Petrillo (2003, p. 107), “arquitetura de software é uma

Para Sommerville (2003), o chamado ciclo de vida do software é um conjunto de

2.2.3 Modelos de ciclo de vida do software

Para Sommerville (2003, p. 36), o conceito de modelagem de processos do

[...] uma representação abstrata de um processo de software. Cada modelo de

A escolha do modelo dependerá da complexidade do sistema que o cliente solicitar, o

O modelo cascata acontece por etapas. Segundo Sommerville (2003), a cada

2.2.3.2 Modelo Espiral

O modelo de ciclo de vida espiral, segundo Peters e Pedrycz (2001), combina as

2.2.3.3 Modelo Incremental

Para Sommerville (2003), no modelo incremental, os clientes identificam quais

2.2.3.4 Modelo Prototipação

De acordo com Peters e Pedrycz (2001), o modelo de prototipação é produzido

2.2.4 Abordagem ICONIX

A abordagem ICONIX permite a utilização de recursos da UML para acrescentar

Figura 2 - Diagramas UML do ICONIX

Fonte: Iconix Process.