universidade do sul de santa catarina josÉ fernando …
TRANSCRIPT
UNIVERSIDADE DO SUL DE SANTA CATARINA
JOSÉ FERNANDO MEYER
JOÃO PAULO DOS SANTOS
FERRAMENTA DE INTEGRAÇÃO DE PROCESSOS PARA APOIO AO
GERENCIAMENTO DE CICLO DE VIDA DE APLICAÇÕES
PALHOÇA
2014
JOÃO PAULO DOS SANTOS
JOSÉ FERNANDO MEYER
FERRAMENTA DE INTEGRAÇÃO DE PROCESSOS PARA APOIO AO
GERENCIAMENTO DE CICLO DE VIDA DE APLICAÇÕES
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.
Orientador: Prof. Jean Carlo Rosa Hauck.
PALHOÇA
2014
JOÃO PAULO DOS SANTOS
JOSÉ FERNANDO MEYER
FERRAMENTA DE INTEGRAÇÃO DE PROCESSOS PARA APOIO AO
GERENCIAMENTO DE CICLO DE VIDA DE APLICAÇÕES
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.
Dedico esse trabalho aos meus pais que
sempre me apoiaram, aos amigos e ao nosso
orientador Jean que foi prestativo e nos ajudou
em todos os momentos.
João Paulo dos Santos
Dedico, com muito carinho, essa monografia à
minha família e a todos meus amigos que me
apoiaram e me acompanharam na minha vida
acadêmica.
José Fernando Meyer
AGRADECIMENTOS
João Paulo dos Santos agradece
Essa monografia foi elaborada, acima de tudo, com muita dedicação e força de
vontade minha e do meu amigo José; porém, muitas pessoas participaram direta ou
indiretamente dela. Nesse espaço, quero agradecer a todos que ajudaram a concluí-la.
Primeiramente, agradeço aos meus pais que sempre me apoiaram em toda a minha
caminhada e que nesse momento foram fundamentais como ponto de equilíbrio e força.
Meus agradecimentos sinceros ao amigo e parceiro dessa jornada, José, que me
acompanhou em diversos trabalhos acadêmicos e na presente monografia.
Ao nosso Orientador Prof. Jean Hauck pelo incentivo, simpatia e presteza no
auxílio às atividades e discussões sobre o andamento desse projeto. Com certeza, seu apoio
foi imprescindível e jamais esqueceremos.
A Profª Maria Inês pela tarefa de multiplicar seus conhecimentos ministrando a
disciplina que nos conduziu a essa obra.
E, por fim, o meu muito obrigado aos membros da banca por terem aceito nosso
convite, agregando seus conhecimentos.
José Fernando Meyer agradece
A toda minha família pelo apoio dado nessa empreitada, principalmente, a meu
pai e minha mãe que sempre me incentivaram e estiveram ao meu lado nos momentos
difíceis.
À meu colega e amigo João Paulo por ser tão paciente no desenvolvimento do
trabalho e por estar sempre motivado ao longo dessa jornada.
Ao Profº Orientador Jean Hauck, pelos ensinamentos, estímulo, apoio e dedicação
nessa trajetória.
Enfim, agradeço a todos que direta ou indiretamente participaram do
desenvolvimento da presente monografia.
“A maior invenção do mundo não é a minha tecnologia! É a morte! pois através dela, o velho
sempre dará lugar para o novo!” (Steve Jobs).
RESUMO
Este trabalho tem como objetivo integrar informações entre as ferramentas EA e o
Eclipse através de um plug-in. Esta integração vem como proposta de solução para problemas
diariamente enfrentados por desenvolvedores em seu ambiente de trabalho, onde os mesmos
necessitam gerenciar uma série de informações relativas ao projeto, porém fazendo uso de
distintas ferramentas e com distintos processos, tornado improdutivo seu rendimento diário.
Para alcançar o objetivo proposto, foram realizados ao longo desses 2 semestres
de estudo: embasamentos teóricos, análise da modelagem de dados da ferramenta EA, análise
da biblioteca do plug-in utilizado pela ferramenta Eclipse e pôr fim a criação da integração
entre a ferramenta EA e o Eclipse. Os resultados obtidos indicam e contribuem com a
melhoria do acesso as informações entre analista e programadores e um aumento de
produtividade com o uso do plug-in.
Palavras-chave: Plug-in, Integração, EA, Eclipse.
ABSTRACT
This work aims to integrate information between EA and Eclipse tools via a plug-in. This
integration comes as a proposed solution to daily problems faced by developers in their work
environment, where they need to manage a lot of information regarding the project, but
making use of different tools and different processes, unproductive become your daily
income.
To achieve the proposed objectives were achieved during these two semesters of study:
theoretical bases, analysis of the data modeling tool from EA, analysis of the plugin library
used by Eclipse tool and end the creation of integration between EA tool and Eclipse. The
results obtained indicate and contribute to improving access to information between analyst
and programmers and increased productivity using the plug-in.
Keywords: Plug-in, Integration, EA, Eclipse.
LISTA DE ILUSTRAÇÕES
Figura 1- O Ciclo de vida clássico............................................................................................22
Figura 2 - Prototipação..............................................................................................................23
Figura 3 – Modelo Espiral........................................................................................................24
Figura 4 – Processos da qualidade compreendidos pela trilogia Juan .....................................27
Figura 5 – Evolução das ferramentas de apoio ao desenvolvimento de software.....................34
Figura 6 - Integração de processos em uma workbench..........................................................37
Figura 7 – Etapas metodológicas..............................................................................................41
Figura 8 – Proposta Solução.....................................................................................................43
Figura 9 – Diagrama de atores..................................................................................................46
Figura 10 - Diagrama de casos de uso Analista........................................................................48
Figura 11 – Diagrama de Casos de Uso do Programador.........................................................49
Figura 12 – Cadastrar Tarefas...................................................................................................50
Figura 13 – Diagrama de Requisitos Funcionais......................................................................52
Figura 14 – Diagrama dos Requisitos Não Funcionais.............................................................54
Figura 15 – Diagrama de Domínio...........................................................................................55
Figura 16 – Diagrama de Robustez - Analista..........................................................................57
Figura 17 – Diagrama de Robustez - Programador...................................................................58
Figura 18 – Cadastrar Casos de uso..........................................................................................59
Figura 19 – Cadastrar tarefa......................................................................................................60
Figura 20 – Acompanhamento das tarefas................................................................................61
Figura 21 – Cadastrar Programador..........................................................................................62
Figura 22 – Cadastrar Bugs.......................................................................................................63
Figura 23 – Visualiza informações sobre Bugs........................................................................64
Figura 24 – Visualiza informações das tarefas.........................................................................65
Figura 25 – Alterar Status da tarefa..........................................................................................66
Figura 26 – Acompanhar bugs de tarefas..................................................................................67
Figura 27 – Alterar Status do Bug............................................................................................68
Figura 28 – Diagrama de Classe...............................................................................................69
Figura 29 – Tela de Autenticação.............................................................................................77
Figura 30 – Cadastros de Caso de Uso.....................................................................................78
Figura 31 – Cadastro de tarefas.................................................................................................79
Figura 32 – Cadastro de bugs....................................................................................................79
Figura 33 – Lista de bugs..........................................................................................................80
Figura 34 – Lista de tarefas.......................................................................................................81
Figura 35 – Atualizar tarefa por caso de uso............................................................................81
Figura 36 – Teste de associação de recurso para tarefa cadastrada no EA...............................83
Figura 37 – Teste de associação de recurso para tarefa cadastrada no plug-in.........................83
Figura 38 – Teste de atualizar cadastro de tarefa no plug-in....................................................84
Figura 39 – Teste de atualizar cadastro de tarefa no EA..........................................................85
Figura 40 – Teste de cadastro de tarefas no plug-in.................................................................85
Figura 41 – Teste de cadastro de tarefas no EA........................................................................86
Figura 42 – Teste de associação de tarefa a programador no plug-in.......................................87
Figura 43 – Teste de associação de tarefa a programador no EA.............................................87
Figura 44 – Teste de cadastro de bug no plug-in......................................................................88
Figura 45 – Teste de cadastro de bug no EA............................................................................89
Figura 46 – Teste de associação de cadastro de bug.................................................................90
Figura 47 – Teste de atualizar bug no plug-in..........................................................................90
Figura 48 – Teste de atualizar bug no EA.................................................................................91
LISTA DE ABREVIATURAS E SIGLAS
ALM – Gerenciamento de ciclo de vida CASE – Engenharia de software auxiliada por computador EA – Enterprise Artchitect PDE – Ambiente de Desenvolvimento Plug-in CMMI – Integração de modelo de maturidade de capacidade TI – Tecnologia da informação GUI – Interface gráfica do utilizador IEEE – Instituto de Engenheiros Elétricos e Eletrônicos IDE – Ambiente Integrado de Desenvolvimento UML – Linguagem Unificada de Modelagem SGBD – Sistema de Gerenciamento de Banco de Dados ORM – Mapeamento Objeto Relacional HTTP – Protocolo de Transferência de Hipertexto
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................................. 15 1.1 PROBLEMÁTICA ....................................................................................................................... 16 1.2 OBJETIVOS ................................................................................................................................. 17 1.2.1 Objetivo geral ............................................................................................................................ 17 1.2.2 Objetivos específicos ................................................................................................................. 17 1.3 JUSTIFICATIVA ......................................................................................................................... 18 1.4 ESTRUTURA DA MONOGRAFIA ............................................................................................ 18
2 REVISÃO BIBLIOGRÁFICA ..................................................................................................... 20 2.1 A ENGENHARIA DE SOFTWARE ............................................................................................ 20 2.1.1 Ciclo de vida de software .......................................................................................................... 21 2.1.2 Tipos de ciclo de vida ............................................................................................................. 22 2.1.3 Rastreabilidade entre elementos de software ............................................................................ 25 2.1.4 Qualidade de software ............................................................................................................... 25 2.2 FERRAMENTAS DE SUPORTE A ENGENHARIA DE SOFTWARE .................................... 28 2.2.1 Integração de ferramentas ......................................................................................................... 30 2.2.2 Ferramentas CASE .................................................................................................................... 33 2.2.3 Ambientes de desenvolvimento integrados ............................................................................... 36
3 MÉTODO ....................................................................................................................................... 39 3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ....................................................................... 39 3.2 ETAPAS METODOLÓGICAS .................................................................................................... 40 3.3 DELIMITAÇÕES ......................................................................................................................... 42 3.4 PROPOSTA DE SOLUÇÃO ........................................................................................................ 42
4 MODELAGEM DA PROPOSTA DE SOLUÇÃO ..................................................................... 44 4.1 TECNICAS UTILIZADAS ......................................................................................................... 44 4.1.1 Unified modeling language (UML) ........................................................................................... 44 4.1.2 Iconix ......................................................................................................................................... 45 4.2 DIAGRAMAS .............................................................................................................................. 46 4.2.1 Atores ......................................................................................................................................... 46 4.2.2 Casos de uso ............................................................................................................................... 47 4.2.2 Diagrama de requisitos ................................................................................................................. 51 4.2.3 Requisitos funcionais .................................................................................................................... 51 4.2.5 Requisitos não funcionais .......................................................................................................... 52 4.2.6 Modelo de Domínio .................................................................................................................. 54 4.2.7 Diagrama de Robustez .............................................................................................................. 56 4.2.6 Diagrama de Sequência ............................................................................................................. 58 4.2.7 Diagrama de Classe ................................................................................................................... 69 4.3 RESUMO DO CAPÍTULO .......................................................................................................... 70 5 DESENVOLVIMENTO ............................................................................................................. 71 5.1 TECNOLOGIA E FERRAMENTAS UTILIZADAS .................................................................. 71 5.1.1 Enterprise Architect .................................................................................................................. 72 5.1.2 Eclipse ...................................................................................................................................... 72 5.1.3 MySQL ..................................................................................................................................... 73 5.1.3 Hibernate ................................................................................................................................... 73 5.1.4 JBoss ......................................................................................................................................... 74 5.1.5 JAX-RS ..................................................................................................................................... 74 5.2 PROBLEMAS E SOLUÇÕES ..................................................................................................... 75 5.3 DESCRIÇÃO DO PLUG-IN ........................................................................................................ 76
5.4 VALIDAÇÃO ............................................................................................................................... 82 5.4.1 Roteiro de teste ......................................................................................................................... 82 5.4.1.1 Teste de associação de recurso para tarefa cadastrada .......................................................... 82 5.4.1.2 Teste de atualização de tarefas .............................................................................................. 84 5.4.1.3 Teste de cadastro de tarefa .................................................................................................... 85 5.4.1.4 Teste de associação de tarefa a programador ........................................................................ 86 5.4.1.5 Teste de cadastro de bug ....................................................................................................... 88 5.4.1.6 Teste de associação de bug .................................................................................................... 89 5.4.1.7 Teste de atualizar bug ............................................................................................................ 90
6 CONCLUSÕES E TRABALHOS FUTUROS ............................................................................ 92 6.1 CONCLUSÕES ............................................................................................................................ 92 6.2 TRABALHOS FUTUROS ........................................................................................................... 93
REFERÊNCIAS .................................................................................................................................. 95
APÊNDICES ........................................................................................................................................ 97
APÊNDICE A – CRONOGRAMA .................................................................................................... 98
15
1 INTRODUÇÃO
O grande crescimento do mercado nos últimos anos tem trazido consigo a
necessidade de inovações tecnológicas que buscam a inteligência que o negócio necessita para
continuar e aumentar cada vez mais sua expansão. Com isso as empresas de Tecnologia da
Informação estão assinando contratos de desenvolvimento de grandes projetos que envolvem
inúmeras complexidades as quais podem ser citadas os prazos, a qualidade de
desenvolvimento e o controle dos custos que este projeto irá consumir em seu escopo global.
Com grandes projetos vem à necessidade de ferramentas que suportem os
requisitos de desenvolvimento do mesmo. Assim tem-se uma crescente demanda de
ferramentas CASE que apoiam os projetos como um todo, desde o planejamento e coleta de
requisitos e modelagem, até o desenvolvimento. Estas variam entre as mais tradicionais como
compiladores e depuradores, e ferramentas de construção de GUI’s e geradores de consultas
de base de dados.
Segundo Watson (2000), ferramentas de engenharia de software em ambientes de
desenvolvimento, estão se tornando cada vez mais importantes facilitadores para softwares
que vem crescendo em níveis de complexidade como jamais se imaginava a alguns
dezembros atrás.
Com o mercado moderno crescendo em larga escala, a necessidade de produtos
para o mercado de TI que não forneçam apenas soluções isoladas e sim ferramentas que
promovam a integração de processos, tem sido uma tendência muito forte nas empresas.
Integração de dados e serviços para a TI atual é uma necessidade quando se pensa
em qualidade de desenvolvimento e centralização de dados. Poder acessar recursos de
soluções distintas em uma única ferramenta, que promova um maior controle do ciclo de vida
do projeto, e que, além disso, possa rastrear de maneira clara e objetiva os requisitos de
negócio das aplicações, é um desejo de muitas empresas de desenvolvimento de software,
porém pode-se dizer que as ferramentas CASE e ALM disponíveis no mercado, ainda
possuem alguma carência de interoperabilidade de processos, devido muitas vezes ao tipo de
suporte, ou dependências de fabricante, por exemplo, ou até mesmo a tecnologias aplicadas.
Segundo IAN THOMAS (2000), o objetivo da integração de dados é para
assegurar que toda a informação no ambiente é gerenciada de forma centralizada,
independentemente da forma como as partes distintas são operadas e modificadas.
16
Automatizar processos com a integração de ferramentas pode trazer consigo
muitos benefícios para projetos de software, se bem aplicados, estes modelos garantem vários
dos requisitos de maturidade de projetos, inclusive atendendo a pontos chave de certificações
como o CMMI, que em determinado grau, exige que a empresa tenha processos mapeados de
forma que as ferramentas estejam integradas ao ponto de tornar o desenvolvimento totalmente
rastreado pelos processos de modelagem dos requisitos, assim podemos garantir qualidade de
desenvolvimento e uma manutenção do mesmo muito mais eficaz, pois ao longo do ciclo de
vida do projeto, todos os processos poderão fornecer informações históricas que podem
garantir a consistência do projeto.
1.1 PROBLEMÁTICA
Atualmente se torna cada vez mais complexo o gerenciamento de grandes
aplicações desde seu planejamento e modelagem, até o desenvolvimento de fato. Para isso
têm-se como um grande aliado, as vertentes de mercado que vem focando em desenvolver
soluções ALM (Gerenciamento de ciclo de vida), as quais vêm trazendo grandes benefícios
para o acompanhamento por completo dos projetos desenvolvidos, soluções estas que vão
desde as mais simples, até as que envolvem planejamentos de alto risco tanto para clientes
como para empresas.
Porém mesmo com inúmeras soluções no mercado, ainda existe uma carência de
ferramentas que unam todas as informações reunidas em sistemas de modelagem de processos
ao longo das etapas do projeto, com as ferramentas de desenvolvimento utilizadas pelas
empresas. Essa integração poderia gerar inúmeros ganhos para a empresa, visto que através do
ambiente de produção o desenvolvedor poderia observar como um todo o ambiente que
engloba o desenvolvimento de suas tarefas, podendo analisar de forma detalhada os requisitos
levantados para cada tarefa do projeto.
Muito dos problemas na falta de qualidade de desenvolvimento se dá pela falta de
um detalhamento completo dos requisitos, e na falta de rastreabilidade entre as diferentes
tarefas desenvolvidas, sendo assim o desenvolvedor acaba trabalhando em curtos prazos de
entrega e com um acesso restrito a informações de requisitos técnicos e de negócio do projeto,
isto acarreta sem a menor dúvida em um grande falta de produtividade e em muitos casos
17
desmotiva o desenvolvedor que não consegue desenvolver seu trabalho de forma clara e
direta. O acesso aos requisitos deve ser detalhado e deve estar disponível da maneira mais
fácil e clara para que ganhos de prazo e qualidade sejam vistos na produção, sendo assim a
integração entre ferramentas de desenvolvimento se torna cada vez mais um ponto de
destaque para resolver estes problemas, centralizando assim da melhor maneira possível
informações relevantes para a qualidade do produto final.
1.2 OBJETIVOS
Serão apresentados a seguir os objetivos gerais e específicos desta monografia.
1.2.1 Objetivo geral
Desenvolver um protótipo de plug-in para a ferramenta eclipse para integração
com a solução de modelagem Enterprise Architect.
1.2.2 Objetivos específicos
Os objetivos específicos estão descritos a seguir:
Criar um protótipo de plug-in para o eclipse
Conectar o plug-in desenvolvido com a ferramenta de modelagem de
processos Enterprise Architect
Gerenciar a modelagem do EA com o intuito de manter rastreabilidade
entre o processo de modelagem e desenvolvimento
18
1.3 JUSTIFICATIVA
A preocupação com a qualidade do software desenvolvido é uma realidade
constante na vida dos desenvolvedores de software, principalmente os responsáveis pela
entrega final do projeto, estes devem manter a qualidade que os clientes desejam e manter o
registro de todas as alterações solicitadas. Após a instalação em produção é importante saber
em qual versão o software se encontra, quais alterações ele sofreu, garantir que erros
corrigidos não voltem a aparecer, que versões antigas não tomem o lugar de versões novas ou
simplesmente não encontrar o código fonte de um sistema em produção. As tarefas, atividades
e processos são necessários para que tenhamos uma gerência de qualidade de software
implantada, e os autores desse trabalho pretendem apresentar um plug-in, com intuito de
utilizá-lo para integrar as informações do EA com o Eclipse.
O presente trabalho possui uma relevância tanto do ponto de vista pessoal para
seus autores, uma vez que lhes agrega conhecimento a respeito de um tema que é do interesse
de ambos, quanto para a empresa em que trabalham, pois irá aumentar a produtividade,
qualidade dos projetos e melhorar a integração das ferramentas para que os utilizadores
possam usufruir das vantagens de se utilizar de boas práticas.
1.4 ESTRUTURA DA MONOGRAFIA
O trabalho é apresentado sistematicamente na seguinte estrutura:
Capítulo 1 – Apresenta uma introdução do assunto com uma problemática, os
objetivos e a justificativa.
Capítulo 2 – Contém uma revisão bibliográfica que possui o foco principal na área
de engenharia de software e integração de ferramentas.
Capítulo 3 – Neste é descrito o método utilizado, as etapas e delimitações.
Capítulo 4 - Esse capítulo tem como função apresentar as informações sobre a
modelagem do protótipo do plug-in desenvolvido.
19
Capítulo 5 - Desenvolvimento da aplicação e modelagem do plug-in de integração
com os processos de modelagem da ferramenta Enterprise Architect
E por fim o capítulo 6 que possui as conclusões da monografia e ideias para
trabalhos futuros.
20
2 REVISÃO BIBLIOGRÁFICA
Este capítulo dedica-se a apresentar a fundamentação teórica a respeito dos temas que
cercam a Engenharia de Software, dentre eles serão abordados: ciclo de vida de software,
rastreabilidade, qualidade de software, ferramentas e integração.
2.1 A ENGENHARIA DE SOFTWARE
São apresentados alguns conceitos sobre engenharia de software:
Engenharia de software significa usar princípios da engenharia nas fases de
desenvolvimento de software, para melhorar a qualidade e reduzir os custos do software
produzido (Jones, 1990).
Engenharia de software é um tipo de engenharia que se aplica a princípios da
ciência da computação e matemática para alcançar soluções com melhor custo-benefício para
o problema do software (SEI, 1990)
O termo ficou conhecido a partir da década de 60 e segundo Koscianski e Soares
(2007) uma das primeiras vezes que se utilizou o tema “Engenharia de Software”, foi em uma
conferência realizada em 1968, na Alemanha, por uma entidade que a princípio não possuía
relação com a área e que se chamava Comitê de Ciência da NATO (North Atlantic Treaty
Organisation – Organização do Tratado do Atlântico Norte).
Segundo Pressman (1995, p.31):
A engenharia de software é um rebento da engenharia de sistemas e de hardware. Ela abrange um conjunto de três elementos fundamentais – métodos, ferramentas e procedimentos – que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade produtivamente.
A fim de associar o termo Engenharia ao conceito de desenvolvimento das
aplicações, o IEEE (Institute of Electrical and Electronics Engineers – Instituto de
Engenheiros Elétricos e Eletrônicos), que é a maior associação profissional do mundo
dedicada a avanços tecnológicos, no ano de 1990 destacou que a Engenharia de Software
21
possuía uma abordagem sistemática, disciplinada e quantificada ao desenvolvimento,
operação e manutenção de software.
Esta engenharia é dividida em camadas, que possuem como foco principal a
qualidade final do produto. O meio para se chegar até este objetivo é o constante
aperfeiçoamento do processo de desenvolvimento, que consiste na criação de documentos,
artefatos e marcos que são capazes de representar o contexto do software, levando em
consideração recursos, ferramentas, prazos, restrições, e outros aspectos que envolvem o
desenvolvimento de um produto de software (PRESSMAN, 2002).
2.1.1 Ciclo de vida de software
Rezende (2005, p. 41) diz que normalmente um software tem um ciclo de vida de
no máximo cinco anos, pois um software nunca está por acabado, sempre têm manutenções,
correções e melhorias. Ele define algumas fases como sendo parte essencial do ciclo de vida
do software:
-concepção: quando a ideia do software surge, ou seja, as suas necessidades;
-construção: quando são feitas as especificações, documentações e a programação;
Implantação: onde o software é finalmente testado, corrigido e disponibilizado
para o cliente;
-maturidade e a utilização plena: quando o software tem suas melhorias, muda de
aparência para uma interface mais amigável, agrega características e funcionalidades;
-declínio: quando um software se torna difícil de ser continuado, adaptado ou
restaurado. Quando um software chega a ser obsoleto;
- manutenção: a última tentativa de sobrevivência do software, com adaptações,
ajustes e mudanças. Rezende (2005, p. 41) também define que neste estado do software é
possível que o ciclo de vida fique em espirou ou looping, retardando a morte e o declínio
total;
-morte: quando um software é finalmente abandonado pelos desenvolvedores e
passa a se tornar um software ‘finalizado’ e fechado.
Existem sistemas que fogem a essas regras, que nunca morrem, por estar sempre a nível
operacional, como folhas de pagamento, contabilidade, contas a pagar, pois esses sistemas
22
estão baseados em outros sistemas que foram formados e formatados há muito tempo e não
devem mudar tão facilmente.
2.1.2 Tipos de ciclo de vida
Pressman (2011, p. 58) define que os modelos de processo foram propostos para
trazer ordem ao caos existente na área de desenvolvimento de software. Não existe uma forma
única e padrão para a resolução dos problemas de se desenvolver um software, o que existe
são vários modelos, estudos e métodos que abrangem todas as fases de desenvolvimento, que
juntos e bem utilizados vão fazer a engenharia de software.
Existe o clico de vida clássica, a prototipação e o modelo espiral.
Figura 1- O Ciclo de vida clássico
Fonte: Engenharia de Software 7° Edição, PRESSMAN,2011.
O ciclo de vida clássico traz um modelo cascata (ilustrado na figura 1), onde o
ciclo de vida está em um modelo sequencial, um paradigma clássico em que uma fase de
desenvolvimento vem após a anterior ser concluída. As fases são: Análise de engenharia de
sistemas, análise, projeto, codificação, testes e manutenção.
Figura 2 - Prototipação
23
Fonte: Engenharia de Software 7° Edição, PRESSMAN, 2011.
A prototipação é um modelo utilizado quando existe apenas uma ideia primária
sobre o que o software deve fazer. Assim o analista ou o desenvolvedor não tem ideia de
como serão as funcionalidades, trazendo assim três possíveis soluções:
a)Um protótipo escrito em papel, com uma ideia mais elaborada como respostas as
ideias inicias;
b)Um protótipo em formato digital, apresentando pequenas funcionalidades possíveis
e um subconjunto de propriedades;
c)Um programa já existente que pode ter parte ou total das funções básicas esperadas,
mas como outras características que serão adaptadas pelo novo desenvolvedor para
anteder o cliente.
A prototipação apresenta um ciclo de desenvolvimento no qual o analista coleta a e
refina os requisitos, elabora um projeto rápido e constrói um protótipo. Em seguida
o cliente avalia o protótipo, e novamente o protótipo é refinado podendo voltar
24
para projeção do software ou continuar na engenharia. Quando o software sai do
modo protótipo, ele recebe o numero das versões.
Figura 3 – Modelo Espiral
Fonte: Engenharia de Software 7° Edição, PRESSMAN, 2011.
O modelo espiral uniu o ciclo de vida clássico com a prototipação, trazendo um
novo paradigma de analise. Ele possui cinco importantes atividades descritas na Figura 3:
Comunicação, planejamento, modelagem, construção e emprego. Ou seja, nesse
caso o cliente avalia o software somente após o mesmo ter passado pela engenharia, e os
testes preliminares são realizados pelos desenvolvedores. Este é um paradigma usado em
grandes sistemas, onde a experiência do grupo de desenvolvimento é grande e a avaliação do
cliente não resulta em grandes alterações do software.
2.1.3 Rastreabilidade entre elementos de software
Segundo o guia de implementação MPS.BR a rastreabilidade é definida como o grau
em que o relacionamento pode ser estabelecido entre dois ou mais produtos de
25
desenvolvimento de software, especialmente produtos que tenham uma relação de predecessor
sucessor ou de mestre subordinado com o outro; por exemplo, o grau em que os requisitos e
projeto (design) de um determinado componente de software combinam (IEEE, 1990).
Quando os requisitos são bem gerenciados, a rastreabilidade pode ser estabelecida,
desde um requisito fonte, passando por todos os níveis de decomposição do produto até seus
requisitos de mais baixo nível e destes até o seu requisito fonte. Tal rastreabilidade auxilia a
determinar se todos os requisitos fonte foram completamente tratados e se todos os requisitos
de mais baixo nível podem ser rastreados para uma fonte válida (SEI, 2010).
Existem duas formas de acontecer a rastreabilidade bidirecional, da forma horizontal
ou vertical. A horizontal estabelece dependência entre os requisitos de trabalho de um mesmo
nível. Já a rastreabilidade vertical estabelece uma rastreabilidade desde um requisito fonte,
passando pelos seus requisitos de mais baixo nível, até o nível de decomposição mais baixo
do produto.
A rastreabilidade é essencial para realização de análise de impacto de mudanças de
requisitos, pois ela identifica o impacto nas mudanças dos requisitos do projeto e o
responsável pela gerência do projeto é capaz de fazer a alterações necessárias no projeto para
minimizar os riscos.
2.1.4 Qualidade de software
Os conceitos de Qualidade têm evoluído por mais de cinquenta anos, criando um
sentido mais amplo, dependente do ambiente onde é analisado. Tais conceitos continuam com
sua validade e são utilizados mundialmente como direcionadores de projetos de Qualidade nas
organizações (DANIELEWICZ, 2006). Alguns dos principais conceitos de qualidade são:
"Qualidade é a totalidade das propriedades e características de um produto ou
serviço que lhe conferem habilidade para satisfazer necessidades explícitas do cliente"
(Norma ISO 8402 - Vocabulário da Qualidade).
"Qualidade é adequação ao uso" (JURAN, 1992).
Segundo Juran (1992), a gerência da qualidade é realizada através de três
processos, que constituem a chamada “Trilogia Juran”:
- Planejamento da Qualidade: consiste na atividade de desenvolver
26
produtos e processos exigidos para satisfazer as necessidades dos
clientes. Compreende uma série de passos, que resumidamente são:
estabelecer metas de qualidade; identificar os clientes; determinar as
necessidades dos clientes; desenvolver características do produto que
atendam às necessidades dos clientes; desenvolver processos que sejam
capazes de produzir aquelas características do produto; estabelecer
controles de processos e transferir os planos resultantes para forças
operacionais.
- Controle da Qualidade: consiste nos passos de avaliar o desempenho
real de qualidade; comparar o desempenho real com as metas da
qualidade; agir a respeito da diferença.
- Melhoramento da Qualidade: é o meio de elevar o desempenho da
qualidade a níveis sem precedentes. Consiste nos passos: constituir
uma infra-estrutura suficiente para garantir o melhoramento anual da
qualidade; identificar as necessidades específicas de melhoras;
estabelecer, para cada projeto, uma equipe com responsabilidades bem
definidas para levá-lo a uma conclusão de sucesso; prover recursos,
motivação e treinamentos de que as equipes necessitam para
diagnosticar causas, estimular os estabelecimento de remédios e
estabelecer controles para manter os ganhos.
A figura 4 mostra as atividades desenvolvidas durante as etapas de cada um dos três processos
para alcance da qualidade do produto através da trilogia Juan.
Figura 4 - Processos da qualidade compreendidos pela trilogia Juan
27
Figura 4 – Fonte: Trilogia Juan(1992)
Um Produto de Software é definido pela norma ISO/IEC 9126-1(ISO9126-1,
1997) como "uma entidade disponível para liberação a um usuário". Também segundo essa
norma, Qualidade de Software é definida como "a totalidade das características de um produto
que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas". Tais
necessidades explícitas são expressas na definição de requisitos elaborados pelo produtor e as
necessidades implícitas são aquelas que podem não estar expressas nos documentos do
produtor, mas que são necessárias ao usuário (GLADCHEFF, 2001).
Segundo Jimenez (1999), produtos de software são largamente utilizados pela
comunidade nos mais diversos setores, que envolvem desde aplicações simples até sistemas
críticos e complexos, tais como sistemas de segurança militar, sistemas de controle aéreo e
sistemas de controle financeiro. Com isso, a qualidade de um produto de software é uma
questão fundamental, pois estes produtos têm um impacto significativo sobre a sociedade.
Baseados nos autores citados pode-se compreender que a garantia da qualidade do
produto de software é relevante durante o seu processo de produção, principalmente em se
28
tratando de domínios de aplicação críticos para a sociedade como: sistemas financeiros, de
saúde e de controle de trânsito (aéreo ou terrestre, dentre outros).
É possível perceber ainda que o controle da qualidade do software ao longo do
processo de produção minimiza os custos, os riscos e favorece a manutenção contínua do
produto.
2.2 FERRAMENTAS DE SUPORTE A ENGENHARIA DE SOFTWARE
Nos últimos anos a tecnologia tem trazido consigo cada vez mais um salto no
nível de complexidade no desenvolvimento de aplicações. Projetos que envolvem um alto
grau de risco e que devem ser pontualmente planejados e otimizados para um resultado final
satisfatório. Com isso entram em cena barreiras como prazo, qualidade e alta produtividade da
equipe, sem a necessidade de grandes investimentos em mão de obra, tarefas que se tornam
um grande desafio para a engenharia de software envolvida no projeto.
Segundo Mian (2001):
Cada vez mais engenheiros de software têm sido cobrados para realmente fazerem engenharia do produto de software: planejar, acompanhar, executar e controlar. Cresce, então, a necessidade de ferramentas para apoiar estas tarefas. Após se ter verificado que ferramentas isoladas podem oferecer apenas soluções parciais, o que se deseja é utilizar ferramentas de apoio ao longo de todo o processo de desenvolvimento de software. Neste contexto, é crescente a demanda por Ambientes de Desenvolvimento de Software (ADSs), que buscam combinar técnicas, métodos e ferramentas para apoiar o Engenheiro de Software na construção de produtos de software, abrangendo todas as atividades inerentes ao processo, tais como planejamento, gerência, desenvolvimento e controle da qualidade (MIAN, 2001, p. 2).
Complexidades como estas levaram os engenheiros de software a pensar em
alternativas viáveis para resoluções de problemas que impactavam diretamente o andamento
do projeto. Assim o computador começa a ser utilizado como ferramenta para automação dos
processos de engenharia de software, tendo em vista que seus recursos não eram aproveitados
anteriormente em benefício dos requisitos exigidos pelos processos de planejamento e
gerenciamento do projeto.
29
Segundo Pressman (1995, p.31):
Em muitos casos, as únicas ferramentas disponíveis ao engenheiro de software eram os compiladores e editores de texto. Estas ferramentas encaminham somente codificação, uma atividade que deve responsabilizar-se por não mais do que 20% do processo de engenharia de software global.
É justo declarar que a engenharia de software auxiliada por computador tem o
potencial de se tornar o mais importante avanço tecnológico da história do desenvolvimento
de software (PRESSMAN, 1995).
As ferramentas de Engenharia de Software de forma geral disponibilizam ao
usuário funcionalidades que facilitam a execução de processos referentes às atividades
exercidas no planejamento e gerenciamento do projeto pelos envolvidos. Dentre estas
ferramentas, algumas se concentram na disponibilização de funcionalidades relevantes para a
fase de concepção (por exemplo, elaboração de diagramas), enquanto outras estão
particularmente direcionadas para a fase de implementação (por exemplo, geração de código e
apoio a realização de testes) (SILVA, 2001).
O autor Roger Pressman (1995) destaca que a engenharia de software auxiliada
por computador pode ser simples ao ser usada, por exemplo, com uma ferramenta única que
suporte uma atividade em específico do processo de engenharia de software, ou pode ser
complexa a ponto de envolver inúmeros outros elementos tecnológicos que vão desde bancos
de dados até padronizações que atendam as mais específicas regras de negócio.
De fato a necessidade de automatização dos processos de engenharia de software
se tornou uma realidade fortíssima no mercado, dificilmente uma empresa atenderá requisitos
complexos exigidos pelos clientes, sem uma boa ferramenta que integre os artifícios
envolvidos ao longo da construção do projeto. Com tudo esta é uma tarefa complexa, que
parte desde a escolha de uma ferramenta que se adeque as necessidades e realidades da
empresa, até a integração desta ferramenta a estrutura do projeto, o que muitas vezes é uma
tarefa árdua e que traz custos para empresa e ainda leva algum tempo para serem implantadas.
30
2.2.1 Integração de ferramentas
Para Ian Thomas (1992), o significado de ‘Integração’ não é tão preciso quanto
deveria ser. Ele acredita que integração não é a propriedade de uma ferramenta simples, mais
sim de suas relações com outros elementos no ambiente, principalmente outras ferramentas,
uma plataforma, ou um processo, sendo que o ponto central se destaca nas na relação entre
ferramentas e nas propriedades desta relação.
Segundo Pressman (1995, p.31):
Ambientes CASE integrados (I-CASE) combinam uma variedade de diferentes ferramentas de diferentes itens de informação de uma forma que possibilita o fechamento da comunicação entre as ferramentas, entre as pessoas e ao longo do processo de engenharia de software.
As ferramentas e ambientes de desenvolvimento têm existido para trazer ao
desenvolvedor facilidades tecnológicas que promovam grande produtividade e facilidade de
desenvolvimento, ferramentas estas que vão desde editores de texto a compiladores.
Os primeiros ambientes eram pouco mais do que pequenas coleções de
ferramentas autônomas, que poderiam ser usados de uma forma vagamente coordenada, para
ajudar na realização de metas da engenharia de software (WATSON, 2000).
A partir do amadurecimento da engenharia de software e do crescimento dos
níveis de complexidade dos projetos, passou a observa-se que as ferramentas de auxilio no
desenvolvimento poderiam trabalhar de forma conjunta para prover maiores benefícios ao
projeto. Porém, tendo em vista as inúmeras mudanças que seriam inseridas nos processos,
muitos ainda se perguntavam, porque integrar ferramentas, e qual benefício isso traria?
As ferramentas são integradas para que as informações de engenharia de software
tornem-se disponíveis para cada ferramenta que delas precisa, um uso integrado em que um
acesso comum e completo as informações é fornecido a todas as ferramentas (PRESSMAN,
1995).
Para Pressman (1995), são inúmeros os benefícios de ferramentas CASE
integradas, dentre os quais podem ser citados:
31
Transferência harmoniosa de informações (modelos, programas,
documentos, dados) de uma ferramenta para outra e de uma etapa da
engenharia de software para a seguinte;
Uma redução do esforço exigido para realizar atividades, tais como
gerenciamento de configuração de software, garantia de qualidade e produção
de documentação;
Um aumento no controle do projeto, que é obtido por meio de um melhor
planejamento monitoração e comunicação;
Coordenação melhorada entre os membros de uma equipe que esteja
trabalhando num grande projeto de software;
Whatson (2000) destaca ainda o ganho efetivo no suporte a rastreabilidade entre
processos do projeto, visto que estas ferramentas facilitam o desenvolvimento e análise de
artefatos envolvidos entre as diferentes plataformas do projeto, trazendo assim ganhos na
gerência de requisitos, onde a interligação entre os processos promove um maior controle para
o engenheiro de software.
Pressmann (1993) afirma que para definir integração no contexto do processo de
engenharia de software, é preciso estabelecer um conjunto de requisitos para o ambiente
integrado de ferramentas, os quais serão descritos abaixo:
Oferecer um mecanismo para compartilhar as informações de engenharia de
software entre todas as ferramentas contidas no ambiente.
Permitir que uma mudança efetuada em um item de informação seja
rastreada até outros itens de informação relacionados.
Oferecer controle de versão e gerenciamento de configuração global para
todas as informações de engenharia de software.
Permitir acesso direto, não sequencial, a qualquer ferramenta contida no
ambiente.
Possibilitar que os usuários de cada ferramenta experimentem uma visão e
uma percepção consistentes em nível de interface ser humano/computador.
Coletar tanto métricas administrativas como técnicas que possam ser usadas
para melhorar o processo e o produto.
32
De acordo com Wasserman (1990), são utilizados cinco tipos de abordagens para
a integração entre ferramentas, sendo elas integrações de plataforma, de apresentação, de
dados, controle e processos. Cada uma dessas abordagens pode ser descrita da seguinte forma:
Integração de plataforma: Diz respeito à integração de serviços em comum
utilizados por ferramentas;
Integração de apresentação: Esta abordagem trata da integração da
ferramenta com o usuário, buscando assim níveis que usabilidade que
proporcionem um bom aproveitamento da ferramenta;
Integração de dados: Esta camada está preocupada com o intercâmbio de
dados entre as diferentes ferramentas dentro do processo, sendo esse um dos
principais pontos para disponibilização da informação em múltiplas
plataformas, que é o que se espera com a integração de ambientes;
Integração de controle: Está preocupada com a interoperabilidade entre as
ferramentas, ou seja, ela fornece uma camada que controla o nível de interação
entre as ferramentas, e analisa como estas estão se comportando no ambiente
automatizado;
Integração de processos: Está preocupado com o papel das ferramentas
dentro de um processo de software inteiro;
Quando se deseja implantar um ambiente de desenvolvimento integrado, deve-se
pensar em algumas premissas, dentre elas uma questão chave que é a capacidade de
determinar o nível adequado de integração e, em seguida, identificar um conjunto de
ferramentas que atendam ao nível exigido. Esta é uma questão dificultada pela falta de acordo
entre os fabricantes de ferramentas, que não consideram mecanismos adequados, com níveis
de integração e padrões que forneçam suporte a automatização de ambientes (WASSERMAN,
1990).
Wasserman ainda afirma que a integração deve ser alcançada através da adoção de
normas a padrões pelos fabricantes de ferramentas, e que todas as ferramentas devem ser
construídas utilizando uma abordagem em camadas, o que facilita uma posterior integração
em um ambiente que já possui uma alta complexidade.
33
2.2.2 Ferramentas CASE
Segundo Silva (2001, p.397):
Definimos CASE como um conjunto de técnicas e ferramentas informáticas que auxiliam o engenheiro de software no desenvolvimento de aplicações, com o objetivo de diminuir o respectivo esforço e complexidade, de melhorar o controle do projeto, de aplicar sistematicamente um processo uniformizado e de automatizar algumas atividades, nomeadamente a verificação da consistência e qualidade do produto final e a geração de artefatos. Uma ferramenta CASE não é mais do que um produto informático destinado a suportar uma ou mais atividades de engenharia de software, relacionadas com uma (ou mais) metodologia(s) de desenvolvimento.
Para Sommerville (2003), a tecnologia CASE proporciona apoio ao processo de
software pela automação de algumas atividades de processo e pelo fornecimento de
informações sobre o software que está sendo desenvolvido.
Um dos principais objetivos que há muito tempo se procura atingir com estas
ferramentas é a implementação de um ambiente integrado que permita a aplicação de uma
abordagem desde a concepção até a implementação para o desenvolvimento de sistemas de
informação (SILVA, 2001).
De acordo com Silva (2001) as ferramentas CASE surgiram efetivamente no
mercado no início da década de 80, onde passaram a ter uma crescente importância no
processo de desenvolvimento, motivada por fatores decisivos que tornaram cada vez maior a
necessidade deste tipo de ferramentas, fatores tais como:
Mudança da ênfase das atividades de programação para atividades de
análise e desenho de software.
Utilização de computadores pessoais e de interfaces de trabalho gráficas.
O aparecimento de diversas técnicas de modelagem de sistemas, que
implicavam o desenho de diagramas gráficos (tais como os fluxogramas
ou diagramas de fluxos de dados), em que a representação destas notações
em papel, ou em ambientes orientados ao caráter, se tornava impraticável à
medida que a respectiva complexidade aumentava.
O aumento da complexidade e do tamanho do software, associado às
maiores capacidades do hardware.
34
A década de 80 foi uma época muito importante para o avanço das ferramentas
CASE, onde foram lançadas no mercado ferramentas de análise de modelagem, ferramentas
de geração automática de código e ferramentas de apoio à gestão de projetos, com suporte a
elaboração de estimativas e testes. Abaixo uma imagem que demonstra a evolução das
ferramentas CASE.
Figura 5 – Evolução das ferramentas de apoio ao desenvolvimento de software.
Fonte: UML Metodologias e ferramentas CASE, SILVA, 2001.
Segundo Pressman (1995) as ferramentas CASE podem ser classificadas por
função, por seus papéis como instrumentos para os gerentes e para o pessoal técnico, pelo uso
que elas têm nas várias etapas do processo de engenharia de software, pela arquitetura de
ambiente (hardware e software) que as suporta ou até mesmo pela origem ou custo delas.
Pressman sugere uma classificação de algumas ferramentas CASE de acordo com sua função,
as quais serão descritas abaixo com o intuito de exemplificar os tipos de ferramentas
existentes:
Ferramentas de gerenciamento de projetos: Utilizando este tipo de
ferramenta o gerente de projetos pode gerar úteis estimativas de esforço, custo
e duração de um projeto de software, definir uma estrutura de divisão de
trabalho, planejar uma programação viável de projeto e acompanhar projetos
em base contínua.
Ferramentas de planejamento de projeto: Ferramentas desta categoria
concentram-se em duas áreas fundamentais: Estimativa de custos, que são
responsáveis por computar o esforço estimado, a duração do projeto e o
número recomendado de pessoas envolvidas, e programação de projetos que
35
permite o a definição e representação de interdependências de todas as tarefas
do projeto.
Ferramentas de rastreamento de requisitos: Responsáveis por oferecer uma
abordagem sistemática ao isolamento dos requisitos que se inicia com a
especificação do cliente.
Ferramentas de apoio: Tem o objetivo de complementar o processo de
engenharia de software, tais como ferramentas de documentação, de rede, de
garantia de qualidade, de gerenciamento de banco de dados e de
gerenciamento de configuração.
Ferramentas de programação: Abrange compiladores, editores e
depuradores que se encontram a disposição para apoiar a maioria das
linguagens de programação convencionais.
Ferramentas de integração e teste: Ferramentas responsáveis por gerenciar
os testes de um projeto, utilizando casos de teste por meio de ferramentas que
proporcionam a aquisição de dados que serão utilizados para os testes e por
análise de código fonte, sem executar os casos de teste.
Dentre outras inúmeras ferramentas que auxiliam o engenheiro de software nas várias etapas
do ciclo de vida de um projeto de alta complexidade.
Para Silva (2001) a adoção de ferramentas CASE pode trazer inúmeros benefícios
desde sua concepção, já que para sua implantação são necessária uma série de regras e
princípios que por si só já são um considerável ganho para o processo empresarial, até outras
melhorias que serão citadas abaixo:
Uniformização do processo de desenvolvimento, das atividades realizadas e
dos artefatos produzidos.
Reutilização de vários artefatos ao longo do mesmo projeto e entre projetos,
promovendo o consequente aumento da produtividade.
Automatização de atividades, com particular destaque ao nível de geração
de código e de documentação.
Diminuição do tempo de desenvolvimento decorrente da reutilização de
artefatos existentes e até mesmo de outros projetos.
Integração de artefatos produzidos em diferentes fases do ciclo de vida do
desenvolvimento de software.
36
Qualidade do produto final, pois a abordagem utilizando ferramentas já
existentes no mercado impõe uma série de regras e padronizações que
automaticamente refletem em um projeto mais estruturado.
Apesar das inúmeras vantagens obtidas, Silva destaca que também existem
aspectos negativos nesse tipo de abordagem, onde alguns fatores foram determinantes para o
fracasso na adoção deste tipo de ferramenta, fatores como o elevado tempo de aprendizagem,
por vezes necessárias para o maior aproveitamento das funcionalidades disponibilizadas por
estas ferramentas, o que é incompatível com a realidade das empresas que exigem sempre a
apresentação de resultados no menor tempo possível. Outros problemas como a
impossibilidade de em uma abordagem mais estratégica, mapear os processos de negócio em
requisitos de informação, e o mito das ferramentas geradoras automáticas de código que não
atingiram ainda resultados satisfatórios, complementam os pontos a se considerar ao pensar
na implantação de ferramentas CASE para o apoio do projeto.
O crescente aumento no desenvolvimento de artifícios computacionais que
apoiem o engenheiro de software em suas tarefas de gerenciamento do projeto é um ponto
muito importante para a potencialidade de cada etapa do ciclo de vida de um projeto, onde
padronizações são adquiridas e regras estabelecem maior estabilidade no desenvolvimento
como um todo, atendendo assim com maior exatidão os prazos e com alto nível de qualidade
no produto final.
2.2.3 Ambientes de desenvolvimento integrados
Existem inúmeras ferramentas de desenvolvimento integrado (IDE), também
conhecidas como workbenches, disponíveis no mercado, ambas possuindo características que
as tornam únicas em alguns aspectos, sempre voltadas para um único propósito geral, elevar
os níveis de produtividade no desenvolvimento de sistemas. No entanto, tendo aumentando
consideravelmente a complexidade dos projetos, espera-se uma gama de funcionalidades cada
vez maior destas ferramentas, e em muitos casos faz-se necessária a integração das diferentes
ferramentas envolvidas nos processos do projeto, tais como a visualização e gerenciamento de
37
informações de uma ferramenta de modelagem de processos através de um ambiente de
desenvolvimento.
Segundo Sommerville (2003) a união destas ferramentas forma uma workbench
CASE, que de acordo com sua definição, se trata de um conjunto de ferramentas que são
utilizadas em determinada fase do processo de software, como a fase de projeto,
implementação ou teste. A vantagem de agrupar ferramentas CASE em uma workbench é que
as mesmas podem trabalhar em conjunto, para oferecer um apoio mais abrangente. Serviços
comuns podem ser implementados e solicitados por todas as outras ferramentas. As
ferramentas de workbench pode ser integradas por meio de arquivos compartilhados, de um
repositório compartilhado ou de estruturas de dados compartilhadas (Sommerville, 2003).
Sommerville (2003) exemplifica a integração de diferentes processos utilizados
por uma ferramenta de modelagem de processos nos estágios de análise e projeto do processo
de software, através de uma imagem que demonstra todas as funcionalidades inclusas em uma
workbench de modelagem, que geralmente estão integradas a repositórios compartilhados,
cuja estrutura é de propriedade do fornecedor do software.
Figura 6 - Integração de processos em uma workbench
.
Fonte: Engenharia de software, SOMMERVILLE, 2003.
38
De acordo com Pressman (1995) este repositório é o conjunto de mecanismos e
estruturas de dados que realizam a integração dados-ferramentas e dados-dados. Um
repositório realiza ou precipita as seguintes funções:
Integridade de dados: Inclui funções que validam a entrada de dados no
repositório e garante a consistência entre objetos relacionados, além de
executar automaticamente mudanças em cascata entre os objetos
relacionados entre si.
Compartilhamento de informações: Oferece um mecanismo de
compartilhamento de informações entre múltiplas ferramentas, além de
gerenciar e controlar o acesso a dados.
Integração dados-ferramentas: Estabelece um modelo de dados que pode ser
disponível a todas as ferramentas do ambiente integrado, controla o acesso
aos dados e realiza funções de gerenciamento de configuração apropriadas.
Integração dados-dados: Estabelece o sistema de gerenciamento de banco
de dados que relaciona objetos de dados de forma que outras funções
possam ser realizadas.
Imposição metodológica: Define uma modelagem E.R implícita para dados
armazenados no repositório, onde no mínimo os relacionamentos e objetos
modelados definem um conjunto de regras que deve ser respeitado para
construir um conteúdo do repositório.
Padronização de documentos: Leva diretamente uma abordagem padrão
para a criação de documentos de engenharia de software ao criar
definições para os objetos do repositório.
É importante entender os níveis de complexidade gerados nesse tipo de
abordagem, por isso deve-se observar as reais necessidades do projeto, e a realidade da
empresa e do ambiente de desenvolvimento, pois a informação acessada de forma
descentralizada podem trazer tanto benefícios como prejuízos em caso de mal uso dessas
ferramentas.
39
3 MÉTODO
O presente capítulo aborda os métodos de pesquisa, cujo objetivo é apresentar o
tipo de pesquisa adotado, as etapas e as delimitações da pesquisa.
De acordo com Oliveira (1997, p.45), a metodologia estuda os meios ou métodos
de investigação do pensamento concreto e do pensamento verdadeiro, e procura estabelecer a
diferença entre o que é verdadeiro e o que não é, entre o que é real e o que é ficção.
Entende-se que a metodologia significa vários procedimentos que são utilizados
na produção de conhecimento. Representa a utilização do método através de técnicas que
asseguram a legitimidade do conhecimento adquirido.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
A classificação dos tipos de pesquisas adotadas em determinado trabalho
cientifico variam de acordo com o enfoque dado. De acordo com Silva (2003), alguns dos
tipos de pesquisa existentes para que o pesquisador possa, com base em seus objetivos, definir
a pesquisa que pretende realizar e a que mais se adapta a sua necessidade para atingir seus
objetivos, são as pesquisas: bibliográfica, documental, experimental ou de laboratório, ex-
post-facto, levantamento de campo, estudo de caso, ação, participante, exploratória, descritiva
e explicativa.
Essa monografia se classifica como sendo uma pesquisa aplicada, quanto a sua
abordagem como pesquisa qualitativa, tendo como objetivos uma pesquisa exploratória e de
acordo como procedimentos técnicos classifica-se como pesquisa bibliográfica e estudo de
caso.
Segundo Silva e Menezes (2001, p. 20) “pesquisa aplicada objetiva gerar
conhecimento para aplicação prática dirigida à solução de problemas específicos”.
40
No que diz respeito a sua forma de abordagem, a pesquisa se classifica como
qualitativa que segundo Gil (2002), as pesquisas qualitativas respondem a questões muito
particulares.
Quanto aos objetivos, à pesquisa se clássica como sendo da natureza exploratória,
pois busca conceitos e fundamentos que justifiquem o estudo, prevendo uma melhor
desenvoltura do tema e dos objetivos propostos, fazendo o uso teórico de referências que
abordam o assunto, através de análise de livros e artigos científicos, que possam enriquecer o
conteúdo. Segundo Menezes e Silva (2005), visa proporcionar maior familiaridade com o
problema, tendo como objetivo torná-lo explícito ou construir hipóteses. Esta pesquisa
envolve levantamento bibliográfico e análise de exemplos que auxiliem a compreensão do
problema.
Relacionado a procedimentos técnicos esta monografia apresenta duas
características: a pesquisa bibliográfica e o estudo de caso. Menezes e Silva (2005), afirmam
que uma pesquisa bibliográfica é aquela que foi elaborada a partir de um material previamente
publicado, sendo exemplos deste: livros, artigos e publicações disponibilizadas na internet.
Para Yin (2011) o estudo de caso significa uma pesquisa empírica e compreende um método
abrangente, como a lógica de planejamento, da coleta e da análise de dados.
3.2 ETAPAS METODOLÓGICAS
A seguir apresentamos as etapas metodológicas seguidas pelo trabalho.
Primeiramente é seguida a etapa de revisão bibliográfica, que representa
embasamentos teóricos de autores credenciados no meio acadêmico, a respeito da engenharia
de software em geral, e sobre seu relacionamento com a proposta de se criar a utilizar
ferramentas computacionais que auxiliam nas atividades de engenharia de software no
projeto, e gerem informações que sirvam de análise para posteriores projetos.
Após o embasamento teórico, será efetuada uma análise da modelagem de dados
da ferramenta Enterprise Architect, pois a modelagem do mesmo será utilizada pela
ferramenta de integração para listar e alterar informações relativas ao processo proposto.
Após o estudo da modelagem de dados será feita a análise da biblioteca do plug-
in, utilizado pela ferramenta Eclipse com o propósito de criar uma perspectiva de visualização
41
em forma de lista de tarefas, sendo que ferramentas externas como o Enterprise Architect,
podem ter suas tarefas listadas por dentro do Eclipse com o auxílio desta biblioteca.
Assim então será criada a interação entre as ferramentas Eclipse e Enterprise
Architect, onde algumas telas serão desenvolvidas para listar os detalhes e ciclo de vida das
tarefas criadas no software para modelagem de processos de engenharia de software. Tendo
acesso a base de dados gerada pelo EA, podemos conectar sem problemas as duas
ferramentas, produzindo e alterando de forma automatizada, as informações relevantes ao
projeto.
Tendo em vista o trabalho realizado, serão extraídas conclusões que poderão
trazer considerações sobre os esforços realizados e conhecimentos extraídos através do
desenvolvimento do projeto.
A seguir segue um diagrama com as etapas metodológicas para o projeto.
Figura 7 – Etapas metodológicas
Fonte: Elaborada pelos autores.
42
3.3 DELIMITAÇÕES
Este trabalho apresenta delimitações, que são apresentadas a seguir.
Por se tratar de uma integração de ferramentas, não existirá total liberdade
e maleabilidade dos recursos utilizados por ambas as ferramentas;
É necessária a configuração específica e disponibilidade de ambas as
ferramentas para que o serviço não se torne instável;
Como se está em um ambiente integrado, qualquer alteração equivocada
na modelagem de dados Enterprise Architect, pode resultar em
inconsistências de dados e até erros em sua apresentação pelo Eclipse;
3.4 PROPOSTA DE SOLUÇÃO
Serão utilizadas duas ferramentas para proposta de solução desenhada, para
modelagem de processos e gerenciamento do ciclo de vida destes processos será utilizada a
solução Enterprise Architect, e como ferramenta de desenvolvimento que apresentará a
interface de integração com as modelagens de negócio do projeto, e que concentrará toda a
ideia de integração de um ambiente CASE, será utilizada a solução Eclipse, que fornecerá
códigos de implementação para interface de interação com o usuário em forma de listagem de
tarefas.
O objetivo deste projeto é, a partir de um ambiente real de produção, que envolve
a coleta de requisitos, levantamento de casos de uso e modelagem dos processos com o EA,
onde com o sistema tendo um repositório de dados que concentrará todas as informações
relativas a estes processos que acompanham todo o ciclo de vida de cada caso de uso, seja
possível a conexão entre as duas ferramentas conectadas ao repositório central de informações
43
do EA, sendo assim alterações de status de tarefas, acompanhamento de requisitos de
desenvolvimento, dentre outros artifícios, podem ser utilizados pela ferramenta Eclipse, onde
alterações serão realizadas e replicadas para ambas.
A seguir uma figura demonstra como será desenhado este processo:
Figura 8 – Proposta Solução
Fonte: Elaborada pelos autores.
Todos os mapeamentos de dados do EA estarão disponíveis via repositório de
dados, onde será desenvolvido um código que trará um formato de apresentação e edição dos
dados relativos às tarefas cadastradas pela ferramenta de modelagem de processos, assim com
acesso aos dados, será possível através do plug-in, gerenciar os dados cadastrados e mantidos
pelo Enterprise Architect.
44
4 MODELAGEM DA PROPOSTA DE SOLUÇÃO
Será apresentada neste capítulo a proposta de modelagem da solução, onde através
dos principais diagramas serão especificados os requisitos os quais este trabalho se propõe a
atender.
4.1 TECNICAS UTILIZADAS
Para a elaboração da modelagem criada neste trabalho foi utilizada a linguagem
de notação UML, que de acordo com Rezende (2005, p. 201), se trata de uma notação ou uma
padronização unificada de modelagem de software e o ICONIX que segundo Guimarães et
al., (2007) pode ser definido como um processo de desenvolvimento de software cuja
metodologia utilizada é simples e prática, tendo um componente de análise e representação de
problemas sólido e eficaz.
4.1.1 Unified modeling language (UML)
A UML (Unified Modeling Language), segundo Rezende (1999, p. 201), é “uma
notação ou uma padronização unificada de modelagem (diagramação e desenvolvimento) de
software”. O mesmo autor ainda acrescenta que se trata de uma linguagem para modelagem
não sendo, portanto, uma metodologia de desenvolvimento.
Bell (2003) afirma que os diagramas UML mais utilizados são: diagrama de casos
de uso, diagrama de classe, diagrama de sequência, diagrama de estados, diagrama de
atividade, diagrama de componentes e diagrama de implantação.
Diagrama de caso de uso - Para Rumbaugh et al. (2000, p.217), esse diagrama é
responsável por “captar o comportamento pretendido do sistema que está sendo
45
desenvolvido, sem ser necessário especificar como esse comportamento é
implementado”.
Diagrama de classe - São usados para exibir as classes e interfaces de um sistema, bem
como suas relações. (RUMBAUGH et al. , 2000).
Diagrama de sequência - De acordo com Eriksson e Penker (2000), eles são usados
para explorar e visualizar a sequência de objetos em interações uns com os outros.
Diagrama de estado - A ideia é de estudar certos tipos de lógicas que envolvem
transições possíveis entre diferentes estados. (FURLAN, 1998)
Diagrama de atividade – Nesse caso serão apresentados os fluxos das atividades de
controle do sistema. (RUMBAUGH et al., 2000)
Diagrama de componentes – Analisam e gerenciam dependências entre componentes
ou entre interfaces de componentes. Podem ser arquivos de código-fonte, bibliotecas
ou programas executáveis. (ERIKSSON; PENKER, 2000)
Diagrama de implantação – Furlan (1998) explica que esse diagrama tem como
propósito mostrar a organização de hardware e a ligação do software aos dispositivos
físicos.
4.1.2 Iconix
Segundo Guimarães et al., (2007) o ICONIX pode ser definido como um processo
de desenvolvimento de software cuja metodologia utilizada é simples e prática, tendo um
componente de análise e representação de problemas sólido e eficaz.
Para Rosenberg (tradução nossa, 2005, p. 58) dentro do ICONIX tudo tem um
propósito primordial. O mesmo autor ainda explica alguns elementos que compõem o
ICONIX:
Diagrama de Robustez: Explica as exigências de comportamento, relacionando-as ao
modelo de objeto;
Diagrama de Sequência: Atribui funções para as classes, mostrando seu
comportamento;
Modelo de domínio: Descreve os objetos do mundo real e os relacionamentos;
Modelo de casos de uso: Define os requisitos de comportamento.
46
4.2 DIAGRAMAS
A seguir serão apresentados os diagramas elaborados para representar a
modelagem de proposta de solução a qual se propõe o trabalho.
4.2.1 Atores
A modelagem apresentará dois atores, ambos usuários, conforme demonstra a
figura 9.
Figura 9 – Diagrama de atores
Fonte: Elaborado pelos autores
47
Os atores utilizados no plug-in são os seguintes:
Usuário: Ator que acessa o repositório de informações compartilhadas.
Analista de Sistemas: É um usuário com permissão de cadastro de casos de
uso, tarefas, cadastro de usuários e o mesmo delega tarefas a
programadores.
Programador: Usuário que visualiza tarefas vinculadas a casos de uso o qual
tem permissão, podendo atualizar suas informações de acompanhamento e
alterar o status das mesmas.
4.2.2 Casos de uso
Foram considerados os seguintes casos de uso para o Analista de sistemas:
US-001 - Cadastrar Casos de Uso
US-002 - Cadastrar Tarefas
US-003 - Acompanhar andamento das tarefas
US-004 - Cadastrar Programadores
US-005 - Associar tarefas a programadores
US-006 - Cadastrar Bugs para tarefas
US-007 - Associar bugs a programadores
US-008 - Visualizar informações sobre correção dos bugs
A modelagem dos casos de uso é apresentada pela figura 10.
48
Figura 10 - Diagrama de casos de uso Analista
Fonte: Elaborado pelos autores do sistema
Para o programador foram elaborados os seguintes casos de uso.
US-009 - Visualizar listagem de tarefas por caso de uso
US-010 - Visualizar requisitos e informações de tarefas
US-011 - Inserir informações de acompanhamento
US-012 - Alterar Status de tarefas
49
US-013 - Acompanhar bugs de tarefas
US-014 - Alterar status de bugs
A modelagem para os casos de uso do programador é descrita pela figura 11.
Figura 11 – Diagrama de Casos de Uso do Programador
Fonte: Elaborado pelos autores Abaixo, a figura 12 ilustra como exemplo, o fluxo principal para o caso de uso cadastrar tarefas:
50
Figura 12 – Cadastrar Tarefas
Fonte: Elaborado pelos autores
51
4.2.3 Diagrama de requisitos
A seguir serão apresentados os requisitos funcionais e não funcionais utilizados na
elaboração da modelagem.
4.2.4 Requisitos funcionais
Abaixo são apresentados os requisitos funcionais especificados.
RF001 - Deve ser possível que o programador visualize a listagem dos casos
de uso e tarefas associadas a seu usuário
RF002 - Deve ser possível que o programador altere o status de uma tarefa
RF003 - Deve ser possível que o programador atualize os dados periódicos
das tarefas, inserindo dados de acompanhamento da mesma.
RF004 - O plug-in deve disponibilizar a listagem de bugs relacionados ao
programador
RF005 – Ao programador deve ser dada a possibilidade de visualização dos
detalhes e requisitos de cada tarefa associada a seu usuário
RF006 - Deve ser possível que o analista visualize a listagem de todos os
casos de uso e tarefas as quais o mesmo cadastrou via EA
RF007 - O plug-in deve disponibilizar ao Analista uma visualização dos
detalhes de cada tarefa para que o mesmo acompanhe o ciclo de cada
atividade
RF008 - Os Analistas devem possuir permissão de visualização somente dos
casos de uso e tarefas que o mesmo cadastrou ou é associado
RF009 - Deve ser possível o cadastro de Casos de uso
RF010 - O plug-in deve disponibilizar o cadastro de tarefas
52
RF011 – Garantir que somente as tarefas associadas ao programador sejam
listadas em sua interface
RF012 - Deve ser possível associar tarefas a usuários
RF013 - Somente analistas terão permissão para cadastro de casos de uso e
tarefas
A modelagem para os requisitos funcionais é representada pela figura 13.
Figura 13 – Diagrama de Requisitos Funcionais
Fonte: Elaborado pelos autores
4.2.5 Requisitos não funcionais
Abaixo são apresentados os requisitos não funcionais especificados.
RNF001 - A modelagem de dados do Enterprise Architect deve ser
disponibilizada em uma base de dados MySQL para que o acesso externo
seja possível.
53
RNF002 - A partir do banco de dados MySQL deve ser criado um
repositório central que reunirá a informações que serão conectadas entre o
EA e a ferramenta desenvolvida.
RNF003 - A integração deve ser implementada através de um plug-in
desenvolvido para a ide eclipse
RNF004 - O plug-in deve possui controle de acesso às tarefas.
RNF005 - Em caso de problema de conexão com o repositório deve ser
efetuado rollback das informações para que não exista inconsistência entre
as ferramentas
RNF006 - Existindo problema de conexão o usuário deve ser informado do
problema através de mensagem
RNF007 - O plug-in deve ser compatível com Eclipse Kepler e Enterprise
Architect 11.
RNF008 - Os dados alterados em uma das ferramentas devem ser replicados
automaticamente para a outra, proporcionando a consistência necessária.
A modelagem para os requisitos não funcionais é representada pela figura 14.
54
Figura 14 – Diagrama dos Requisitos Não Funcionais
Fonte: Elaborado pelos autores
4.2.6 Modelo de Domínio
A figura 15 ilustra o diagrama de domínio do sistema.
55
Figura 15 – Diagrama de Domínio
Fonte – Elaborado pelos autores
O modelo de domínio traz os objetos de domínio mapeados a partir da base de
dados compartilhada e modelada para o Enterprise Architect. Abaixo serão explicados cada
objeto do modelo:
TObject - Se trata do objeto principal do domínio, esse elemento representa
as tarefas e os casos de uso utilizados pela ferramenta.
TConnector - Através deste elemento fazemos a conexão entre dois objetos
do domínio, por exemplo interligar uma tarefa a um caso de uso
específico.
TObjectProblems - Aqui estão contidos os bugs relacionados a um objeto,
sendo assim problemas encontrados em uma tarefa e cadastrados no plug-
in serão encontrados nesta tabela.
56
TResource - São os usuários cadastrados via Enterprise Architect e que
podem ser associados a tarefas e bugs. Para o EA usuários são
considerados como recursos do projeto.
TObjectResource - Se trata da associação entre um objeto (TObject) e um
recurso. Ao criar essa ligação informações como horas trabalhadas e
porcentagem de uma tarefa iniciada poderão ser inseridas no modelo.
TProjectRole - São os tipos de perfis que podem ser associados ao usuário
no EA.
Usuario – Se trata de um usuário (recurso) que possui dados de autenticação
para acesso ao plug-in de integração.
4.2.7 Diagrama de Robustez
As figuras 16 e 17 apresentam o Diagrama de Robustez do plug-in.
57
Figura 16 – Diagrama de Robustez - Analista
Fonte: Elaborado pelos autores
58
Figura 17 – Diagrama de Robustez - Programador
Fonte: Elaborado pelos autores
4.2.8 Diagrama de Sequência
A figura 18 apresenta o diagrama de sequência da ação de cadastrar casos de uso
na aplicação.
59
Figura 18 – Cadastrar Casos de uso
Fonte – Elaborado pelos autores
A figura 19 apresenta o diagrama de sequência da ação de cadastrar tarefa na
aplicação.
60
Figura 19 – Cadastrar tarefa
Fonte – Elaborado pelos autores
A figura 20 apresenta o diagrama de sequência é o acompanhamento das tarefas
na aplicação.
61
Figura 20 – Acompanhamento das tarefas
Fonte – Elaborado pelos autores
A figura 21 apresenta o diagrama de sequência da ação de cadastrar programador
na aplicação.
62
Figura 21 – Cadastrar Programador
Fonte – Elaborado pelos autores
A figura 22 apresenta o diagrama de sequência da ação de cadastrar Bugs na
aplicação.
63
Figura 22 – Cadastrar Bugs
Fonte – Elaborado pelos autores
64
A figura 23 apresenta o diagrama de sequência da ação de visualizar informações
sobre os Bugs na aplicação.
Figura 23 – Visualiza informações sobre Bugs
Fonte – Elaborado pelos autores
65
A figura 24 apresenta o diagrama de sequência da ação de visualizar informações
sobre as tarefas na aplicação.
Figura 24 – Visualiza informações das tarefas
Fonte – Elaborado pelos autores
66
A figura 25 apresenta o diagrama de sequência da ação de alterar status da tarefa
na aplicação.
Figura 25 – Alterar Status da tarefa
Fonte – Elaborado pelos autores
A figura 26 apresenta o diagrama de sequência do acompanhamento de bugs de
tarefa.
67
Figura 26 – Acompanhar bugs de tarefas
Fonte – Elaborado pelos autores
A figura 27 apresenta o diagrama de sequência da ação de alterar status do bug na
aplicação.
68
Figura 27 – Alterar Status do Bug
Fonte – Elaborado pelos autores
69
4.2.9 Diagrama de Classe
A figura 28 mostra o diagrama de classe do sistema exemplificando as classes envolvidas nos processos de listagem e cadastro de tarefas e na listagem de bugs. Figura 28 – Diagrama de Classe
Fonte – Elaborado pelos autores
4.3 RESUMO DO CAPÍTULO
Nesse capítulo foram apresentados, os principais conceitos sobre a UML,
ICONIX e seus diagramas mais comuns.
70
Além desses temas, também foi exposta uma explicação sobre o protótipo
utilizado no estudo de caso e sua modelagem utilizando a UML.
O capítulo seguinte aborda os detalhes das ferramentas utilizadas, sobre o
desenvolvimento da solução proposta e validação.
71
5 DESENVOLVIMENTO
Nesse capítulo são apresentados os detalhes sobre o desenvolvimento do plug-in,
contendo uma descrição sobre o sistema envolvido no estudo de caso.
Nas seções que seguem é descrito o ferramental utilizado, bem como a explicação
de seu funcionamento. Posteriormente, serão mostrados os problemas e soluções no
desenvolvimento da ferramenta.
Após o levantamento das características anteriores, serão apresentadas
características do protótipo desenvolvido para atender aos requisitos levantados para a
proposta de solução.
Por fim, será apresentada a avaliação dos resultados obtidos.
5.1 TECNOLOGIA E FERRAMENTAS UTILIZADAS
Para o desenvolvimento do protótipo proposto para atender aos requisitos da
proposta de solução, uma série de ferramentas e tecnologias foram utilizadas. Visto que este
se tratava de um projeto de integração, sabia-se que a necessidade de tecnologias e conceitos
distintos, seriam necessários para o funcionamento completo da ferramenta.
Abaixo serão apresentadas estas tecnologias, seguidas de um breve trecho
explicativo sobre cada uma delas e como foram aplicadas neste projeto para gerar o resultado
final esperado.
Nas subseções que seguem, estarão descritas as ferramentas utilizadas no Plug-in.
72
5.1.1 Enterprise Architect
De acordo com o Sparx System (2014), a ferramenta Enterprise Architect (EA)
possui os recursos da linguagem UML para criação de modelos na arquitetura de sistemas.
O EA disponibiliza, dentre seus diversos recursos, a modelagem para o ciclo de
vida de softwares e Engenharia de Sistemas, além de gerar relatórios e documentos detalhados
dos projetos.
Esta ferramenta se trata do objeto principal de exploração o qual é focado este
projeto, isso por se tratar de uma ferramenta que tendo seus recursos bem explorados, pode
gerar uma série de benefícios no gerenciamento de projetos. A ideia explorada aqui é
gerenciar todo o ciclo de vida de um projeto e seus objetos por meio do Enterprise Architect,
onde os recursos referentes ao modelo de projeto, contidos na ferramenta, serão
compartilhados por uma base de dados que disponibilizará externamente estes dados para que
outros recursos possam consumi-los.
5.1.2 Eclipse
Para Aniszczyk e Gallardo (2012), Eclipse é uma plataforma de desenvolvimento
de software livre extensível, baseada em Java. Por si só, é simplesmente uma estrutura e um
conjunto de serviços para desenvolvimento de aplicativos de componentes de plug-in.
Felizmente, o Eclipse vem com um conjunto padrão de plug-ins, incluindo as amplamente
conhecidas Ferramentas de Desenvolvimento Java (JDT).
O Eclipse também inclui o Plug-in Development Environment (PDE), que é de
interesse principalmente daqueles que desejam estender o Eclipse, visto que ele permite
desenvolver ferramentas que se integram perfeitamente ao ambiente do Eclipse. Como tudo
no Eclipse é plug-in, todos os desenvolvedores de ferramentas têm um campo de ação
nivelado para oferecer extensões ao Eclipse e fornecer um IDE unificado e consistente aos
usuários. (ANISZCZYC e GALLARDO, 2012).
Dada esta possibilidade de extensão da ferramenta, chegamos ao objetivo deste
projeto, que é implementar na versão “Kepler”, através da linguagem Java e do ambiente
73
integrado PDE, um plug-in de integração para administrar os elementos do Enterprise
Architect de forma simples e ágil para o programador a partir de sua própria ferramenta diária
de trabalho que é o eclipse.
5.1.3 MySQL
De acordo com Milani (2006, p.22), MySQL é um servidor e gerenciador de
banco de dados (SGBD) relacional, de licença dupla (sendo uma delas de software livre),
projetado inicialmente para trabalhar com aplicações de pequeno e médio portes, mas hoje
atendendo a aplicações de grande porte e com mais vantagens do que seus concorrentes.
Possui todas as características que um banco de dados de grande porte precisa, sendo
reconhecido por algumas entidades como o banco de dados open source com maior
capacidade para concorrer com programas similares de código fechado, tais como SQL Server
(da Microsoft) e Oracle.
O MySQL foi utilizado neste projeto como o banco de dados alimentado pelos
dados que serão compartilhados a partir da ferramenta Enterprise Architect. Esta base de
dados será acessada tanto pela ferramenta de modelagem quanto pelo plug-in que também se
conectará a este repositório de dados compartilhado.
5.1.4 Hibernate
O trabalho com o software objeto relacional e banco de dados relacionais podem
ser incômodos e desgastantes atualmente num meio empresarial. Hibernate é um
Objeto/Relacional de Mapeamento de ferramentas nos meio Java. O termo Objeto/Relacional
de Mapeamento (ORM) refere-se à técnica de mapeamento de dados, representada desde o
objeto modelo aos dados relacionais modelo com um esquema baseado na SQL.
O Hibernate não cuida apenas do mapeamento desde às classes de Java até as
mesas de banco de dados (e de tipos de dados Java até tipos de dados da SQL), mas também
74
proporciona a consulta de dados e facilidades de recuperação que pode significativamente
reduzir o tempo de desenvolvimento. Do contrário, consumido com o manual de dados
executados em SQL e JDBC (RED HAT, 2004).
O Hibernate será responsável por fornecer os objetos Java espelhados nas tabelas
do modelo relacional criado para o Enterprise Architect, além de ser responsável pelas
funcionalidades de consulta e persistência nas tabelas deste modelo.
5.1.5 JBoss
Segundo Magnani (2013), JBoss Application Server 7 ou apenas JBoss é um
servidor de aplicação de código aberto que é 100% compatível com a especificação Java EE
desenvolvido pela Red Hat.
O JBoss será responsável por integrar as duas ferramentas de fato, onde
realizando conexões HTTP, o plug-in se conectará ao servidor de aplicação e obterá um dos
serviços disponíveis implementados para fornecer os dados requisitados vindos da base de
dados compartilhada. Além disso, o servidor de aplicação é responsável por itens de
segurança que vão desde a conexão com o mesmo até a garantia de consistência das
transações de dados efetuadas pelas ferramentas.
5.1.6 JAX-RS
Para entender o que é JAX-RS primeiro é necessário entender o conceito de Web
Services. Segundo Menéndez (2002), há uma definição bastante simples para um Web
Services: É uma aplicação que aceita solicitações de outros sistemas através da Internet. Web
Services são interfaces acessíveis de rede, para as funcionalidades da aplicação, que utilizam
em sua construção tecnologias padrões da Internet.
75
Através dessas afirmações, observa-se que Web Services são serviços que visam
facilitar o processamento distribuído em sistemas heterogêneos.
Tendo entendido este conceito, podemos afirmar que JAX-RS se trata de uma
especificação que faz parte do Java Enterprise Edition 6, que define a implementação de web
services em Java.
Em conjunto com o JBoss o JAX-RS foi utilizado para desenvolver o web
servisse que funciona como a interface de conexão entre o plug-in e o modelo de dados. Com
a disponibilização do serviço, podem ser criadas conexões HTTP que retornaram arquivos
XML convertidos em objetos Java que contém os dados que serão consumidos pela interface
da ferramenta via eclipse.
5.2 PROBLEMAS E SOLUÇÕES
No decorrer do projeto, surgiram alguns problemas no desenvolvimento da
proposta de solução, problemas estes que limitaram algumas escolhas feitas pelos autores, e
forçaram a pesquisa de meios que solucionassem estes obstáculos para o atendimento dos
requisitos levantados. Estes problemas serão listados a seguir, juntamente com a solução
encontrada para sanar cada um destes problemas.
Problema 1 - Desenvolver interface para interação do usuário com a
ferramenta eclipse.
Solução - Implementar a solução utilizando o ambiente PDE oferecido pelo
eclipse para a construção de plug-ins otimizados para a plataforma.
Problema 2 - Compartilhar recursos modelados no Enterprise Architect
para acesso externo pela ferramenta de integração.
Solução - Compartilhar os dados do EA com uma base de dados MySql com
reflexão em tempo real das mudanças realizadas na modelagem.
76
Problema 3 - Centralizar as regras de negócio e acesso a base de dados do
EA em um ambiente com suporte a conexões HTTP.
Solução - Uso do Container J2EE JBoss para compartilhamento destes recursos e
implementações das regras do lado servidor do plug-in.
Problema 4 - Realizar a conexão entre o plug-in, que não é uma
ferramenta web, com o container JBoss para acesso aos dados.
Solução - Implementar classes de serviço através de Web services, que utilizando
conexões HTTP se conectam ao JBoss e solicitam serviços suportados pela implementação
realizada.
Problema 5 - Manter segurança ao acesso de informações entre os
usuários, para que o mesmo não visualize informações que não tenha
acesso.
Solução - Criar cortes de dados por usuário autenticado na ferramenta, essa
autenticação irá refletir os usuários cadastrados no EA e seus papéis, com isso o acesso será
restringido somente a dados que tenham sido previamente associados a um usuário da
plataforma.
5.3 DESCRIÇÃO DO PLUG-IN
O plug-in desenvolvido para a ferramenta eclipse foi criado na forma de um
protótipo que trás consigo as funcionalidades demonstradas nos casos de uso modelados para
a proposta de solução apresentada no projeto.
Alguns destes casos de uso e suas telas e funcionalidades implementadas no
protótipo serão demonstrados a seguir:
Autenticação – O usuário abre o Eclipse, clica no ícone do plug-in e insere
seus dados para autenticar-se no sistema.
77
A imagem 29 mostra a tela desse funcionamento.
Figura 29 – Tela de Autenticação
Fonte: Elaborado pelos autores
Cadastro de Caso de Uso – O Analista faz o cadastro de caso de uso a partir do menu conforme mostra na imagem 30
78
Figura 30 – Cadastros de Caso de Uso
Fonte: Elaborado pelos autores
Cadastro de Tarefas – O Analista faz o cadastro de tarefas a partir de um caso de uso conforme mostra na imagem 31
79
Figura 31 – Cadastro de tarefas
Fonte: Elaborado pelos autores
Cadastro de bugs – O Analista faz o cadastro de bugs a partir do menu conforme mostra na imagem 32
Figura 32 – Cadastro de bugs
Fonte: Elaborado pelos autores
80
Lista de bugs – O analista e programador conseguem visualizar a lista de
bugs cadastrados a partir do menu conforme mostra a imagem 33.
Figura 33 – Lista de bugs
Fonte: Elaborado pelos autores
Lista de tarefas – O analista e programador conseguem visualizar a lista de tarefas cadastrados a partir do menu conforme mostra a imagem 34.
81
Figura 34 – Lista de tarefas
Fonte: Elaborado pelos autores
Atualizar tarefa – O programador atualiza a tarefa a partir de um caso de uso conforme mostra na imagem 35.
Figura 35 – Atualizar tarefa por caso de uso
Fonte: Elaborado pelos autores
82
Por fim, foi possível verificar que a integração entre as ferramentas conseguiu
interagir de forma prática e rápida, facilitando o acompanhamento de projetos para analista e
programadores.
5.4 VALIDAÇÃO
Como validação para as funcionalidades desenvolvidas no plug-in, foi utilizada a
abordagem de testes baseados em casos de teste exploratórios, onde através de um roteiro de
testes utilizando caminhos alternativos, os autores fizeram uso da ferramenta acessando todos
os recursos que ela oferece a fim de encontrar possíveis problemas de implementação ou de
regras de negócio.
O roteiro de testes demonstrou essencial para o processo de validação da
ferramenta, pois através deles foi possível validar a usabilidade do plug-in e a taxa de
disponibilidade de conexão com o repositório de dados compartilhado.
5.4.1 Roteiro de teste
Para execução do teste manual elaborou-se um roteiro contendo alguns casos de
teste onde o resultado de cada um destes servirá como validação da implementação
das funcionalidades desenvolvidas. Abaixo serão descritos os testes passo a passo,
seguidos de uma figura com o resultado final do teste executado.
5.4.1.1 Teste associação de recurso para tarefa cadastrada
O teste de associação de um recurso para uma tarefa cadastrada consiste na criação
de uma tarefa pelo EA, seguida da associação da mesma a um caso de uso. Posteriormente é
criada a associação de um recurso a esta tarefa através da aba “Project Management”, onde o
recurso “Paulo” cadastrado previamente será utilizado, como mostra a figura 36.
83
Figura 36 – Teste de associação de recurso para tarefa cadastrada no EA
No plug-in entrar com o usuário “Paulo”, e acessar a opção “Listagem de tarefas”,
clicar no caso de uso associado a tarefa e na grid abrir os detalhes clicando duas vezes na
tarefa para mostrar que a mesma foi cadastrada no EA como mostra a imagem 37.
Figura 37 – Teste de associação de recurso de tarefa pelo plug-in
84
5.4.1.2 Teste de atualização de tarefas
O teste para atualização de tarefa, se dá pelo programador, no caso “Paulo”,
selecionar a opção do menu “Atualizar tarefas” clicar no caso de uso associado a tarefa,
depois clicar duas vezes na tarefa listada na grid e preencher os campos da tela conforme na
figura 38.
Figura 38 – Teste de atualizar cadastro de tarefa no plug-in
Em seguida abrir o EA e confirmar se os dados cadastrados no plug-in foram
atualizados conforme inseridos no plug-in como mostra a imagem 39.
85
Figura 39 – Teste de atualizar cadastro de tarefa no EA
5.4.1.3 Teste de cadastro de tarefa no plug-in
O teste de cadastro de tarefa no plug-in consiste em entrar com o perfil analista, no
caso “Fernando”, clicar em cadastrar tarefa, selecionar um caso de uso, na tela de cadastro
preencher os campos e clicar em salvar conforme mostra a imagem 40.
Figura 40 – Teste de cadastro de tarefas no plug-in
86
No EA clicar com o botão direito na pasta “Gerencia de projeto” ir até “Content” e
clicar em “Reload current Package”, a nova tarefa é mostrada na pasta, clicar duas vezes nela
mostra que é a mesma tarefa cadastrada como mostra a imagem 41.
Figura 41 – Teste de cadastro de tarefas no EA
5.1.4.4 Teste de Associação de tarefa a programador
O teste de Associação de tarefa a programador consiste em entrar com o perfil
analista no plug-in no caso “Fernando”, clicar na opção “Associar tarefa a programador”,
selecionar um caso de uso, dar um duplo clique numa tarefa cadastrada, preencher os campos
e clicar em salvar como mostra a imagem 42.
87
Figura 42 – Teste de associação de tarefa a programador no plug-in
No EA clicar na tarefa e mostrar na aba “Project Management” que o recurso foi
associado a “Paulo” como mostra a figura 43.
Figura 43 – Teste de associação de tarefa a programador no EA
88
5.4.1.5 Teste de cadastro de bug
O teste de cadastro de bug consiste em entrar no plug-in com o perfil analista no caso
“Fernando”, clicar na opção do menu “Cadastrar bug”, selecionar um caso de uso, abrir uma
tarefa associada, preencher os campos na tela e clicar em salvar como mostra a figura 44.
Figura 44 – Teste de cadastro de bug no plug-in
No EA selecionar a tarefa no qual foi feito o cadastro de bug, selecionar a aba
“Maintenance” e verificar se as informações cadastradas no bug estão ali conforme mostra a
imagem 45.
89
Figura 45 – Teste de cadastro de bug no EA
5.4.1.6 Teste de associação de bug
O teste de associação de bug consiste em entrar no plug-in com o perfil analista no
caso “Fernando, clicar na opção do menu “Associar bug a um programador”, selecionar uma
tarefa associada um caso de uso, selecionar o programador que deseja fazer a associação e
clicar em salvar como mostra a imagem 46.
90
Figura 46 – Teste de associação de cadastro de bug
5.4.1.7 Teste de atualizar bug
O teste de cadastro de bug consiste em entrar como programador no plug-in no caso
“Paulo” clicar na opção do menu “Atualizar bug”, selecionar a tarefa que tem o bug
cadastrado e atualizar as informações do bug como mostra a imagem 47.
Figura 47 – Teste de atualizar bug no plug-in
91
No EA selecionar a tarefa que foi feito as atualizações do bug, clicar na janela
“Maintenance” e verificar se as informações foram atualizadas conforme a imagem 48.
Figura 48 – Teste de atualizar bug no EA
As validações foram realizadas em várias etapas do desenvolvimento entre os
desenvolvedores do projeto, o que ocasionou na descoberta e correção de problemas que
minimizados reduzem o risco de erros desconhecidos e bugs inesperados no momento do uso
em ambiente real. Sendo assim a utilização dos testes exploratórios se mostrou uma
abordagem simples de validação mas que trouxe ganhos consideráveis para requisitos de
garantia de qualidade do produto final.
92
6 CONCLUSÕES E TRABALHOS FUTUROS
Para atender o estudo, foi necessário criar e aplicar os testes manuais e
automatizados, utilizando como base um protótipo de um sistema web. Com base nisso, foram
levantadas as conclusões da presente monografia, bem como sugestões de trabalho futuros.
6.1 CONCLUSÕES
Projetos de integração entre ferramentas vêm se tornando cada vez mais uma
realidade tanto para usuários finais comuns, quanto para o mundo corporativo. Integrar
ferramentas pode trazer ganhos significativos para os processos nas empresas, onde a
tendência se mostra voltada a diminuir as burocracias envolvidas no uso de várias ferramentas
distintas, e aumentar a produtividade e a motivação dos envolvidos nestes processos.
Com a proposta de construção do plug-in o qual este trabalho se propõe, os
autores puderam reforçar estes conceitos e visualizar na prática como dados fornecidos de
maneira simples e integrada, pode trazer agilidade nos processos de desenvolvimento dos
personagens envolvidos.
Trazendo para o ambiente de desenvolvimento integrado utilizado diariamente por
programadores e analistas as informações de requisitos e controle de toda a manutenção do
ciclo de vida das tarefas, notou-se que todos os detalhes para a construção de uma tarefa
podem estar disponíveis de maneira rápida e detalhada com o uso do plug-in, isso sem sair da
ferramenta atual, o que em inúmeras conversas com programadores, é um grande ganho para
a qualidade do desenvolvimento e para a satisfação do usuário envolvido, isso porque em sua
grande maioria, as empresas acabam utilizando diversas ferramentas que apoiam o controle e
manutenção das tarefas, tais como sistemas que controlam os bugs, outro para modelagem e
levantamento de requisitos e ainda um terceiro para apontamento de horas gastas e custos
relacionados a atividades e tarefas. A solução proposta pelos autores mostrou a ideia de
conectar estes distintos elementos, que estão contidos como módulos da solução Enterprise
Architect, a uma ferramenta em formato de plug-in para o Eclipse, onde o acesso centralizado
93
aos recursos compartilhados mostrou a aplicação dos conceitos de integração propostos neste
trabalho.
Propor melhorias que tragam aos desenvolvedores e analistas, em um ambiente de
trabalho tão amplo e complexo, a possibilidade de agilizar e descomplicar os processos
diários no andamento de um projeto, direcionando o foco a elementos que garantam requisitos
de qualidade e controle, e essa foi à lição aprendida e aplicada no desenvolvimento deste
trabalho, fornecendo uma ideia e um protótipo de uma ferramenta que aplica estas ideias.
6.2 TRABALHOS FUTUROS
Ao decorrer deste projeto, tendo analisado as ferramentas que faziam parte da
estrutura apresentada para solução do mesmo, uma série de potencialidades foram
identificadas para exploração a fim de trazer um maior número de funcionalidades para o
plug-in desenvolvido. O Enterprise Architect é uma ferramenta com inúmeros recursos, que
se explorados em larga escala, pode trazer grandes benefícios para o ciclo de vida de projetos
atuais e futuros, isso por tratar de uma ferramenta que se preocupa com vários aspectos
relevantes para a manutenção de todas as fases do planejamento.
Tendo estas características em mente podemos apontar que a ferramenta
desenvolvida engloba apenas uma pequena parte do processo, que seria o gerenciamento do
ciclo de tarefas relacionadas às fases do projeto, sendo assim destacamos como trabalhos
futuros alguns itens que podem trazer uma maior riqueza para o plug-in.
Trazer uma opção com mais detalhamentos para o apontamento de horas dos
programadores seria um item importante, isso porque dessa maneira poderia
ser pensada a ideia de descartar softwares terceiras responsáveis por este tipo
de atividade, e como este trabalho se presta a trazer a integração e comodidade
para o programador centralizar suas atividades em uma única ferramenta isso
traria um ganho significativo.
Investir na ideia de relatórios que traga ao usuário, independente do perfil, um
detalhamento em números das atividades desenvolvidas e dos custos
direcionados a estas atividades. Uma série de relatórios poderia trazer uma
94
riqueza de informação altamente significativa para o plug-in se tornar
realmente uma ferramenta aplicável.
Criar itens que auxiliem na rastreabilidade entre tarefas e implementação, onde
o usuário poderá vincular as classes desenvolvidas para a solução da tarefa
com o item da modelagem que representa a mesma. Investir em
rastreabilidade traz muitos ganhos a curto e longo prazo, onde a resolução de
problemas e auditoria de mudanças se torna muito mais ágeis e eficientes.
Trazer para a ferramenta conceitos de usabilidade que tornem sua manipulação
no dia a dia muito mais atrativo para o usuário. Por se tratar de um protótipo,
não foram criados componentes reflitam as melhores práticas de usabilidade.
Se tratando de uma ferramenta de integração, e de um público específico, este
item é de extrema importância, já que sendo uma ferramenta complexa no uso,
o plug-in acabará se tornando um empecilho a mais no processo e não um
benefício.
Estes são os itens considerados como importantes para que nosso projeto ganhe
aspectos de uma ferramenta aplicável em ambiente real, onde assim poderá cumprir seu papel
de fornecer itens que proporcionem uma troca mais ágil de informações entre os responsáveis
por seu uso além de descomplicar algumas etapas do processo de gerenciamento do projeto.
95
REFERÊNCIAS
A. I. Wasserman. Tool Integration in Software Engineering Environments. In Proc. Int. Workshop on Environments, Berlin, 137 – 149, 1990. BELL, Donald. UML basics: An introduction to the Unified Modeling Language. 2003. Disponível em: <http://www.ibm.com/developerworks/rational/library/769.html>. Acesso em: 20 março 2014. DANIELEWICZ, Marcio. Procedimentos para rastreabilidade das não conformidades no processo produtivo. Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico. Programa de Pós-Graduação em Engenharia de Produção. Florianópolis, 2006. ERIKSSON, Hans-Erik; PENKER, Magnus. Business Modeling with UML. Estados Unidos: Wiley & Sons, 2000. 459p. FURLAN, José David. Modelagem de objetos através da UML. São Paulo: Makron Books,1998 GLADCHEFF, A.P.; ZUFFI, E.M.; SILVA, D.M. Um Instrumento para Avaliação da Qualidade de Softwares Educacionais de Matemática para o Ensino Fundamental. In: VII WORKSHOP DE INFORMÁTICA NA ESCOLA, Fortaleza, CE, Brasil, julho/agosto, 2001. Anais. GUIA MPS.BR Acesso em 26 ABRIL. 2013 GUIMARÃES, Gabriel; MEDEIROS, Rodrigo; ROSSINI, Tiago; SILVA, George; SILVA, Gilbert. Utilizando ICONIX no desenvolvimento de aplicações delphi. In: CONGRESSO DE PESQUISA E INOVAÇÃO DA REDE NORTE NORDESTE DE EDUCAÇÃO TECNOLÓGICA, 2., 2007, João Pessoa. Anais eletrônicos... Disponível em: <http://www.redenet.edu.br/publicacoes/publicacoes.php?tipo=1&area2=Inform%E1tica#>. Acesso em: 20 março 2014. IAN , THOMAS, Definitions of tool integration for environments , 2000. Disponível em: <http://www.ics.uci.edu/~taylor/ics228/thomas.pdf>. Acesso em: 31 MAR. 2013. JONES, Gregory W. Software Engineering. New York: Jhon Wiley & Sons 1990. JURAN, Joseph. M. 1904. A qualidade desde o projeto: novos passos para o planejamento da qualidade em produtos e serviços / J. M. Juan; tradução Nivaldo Montingelli Jr. São Paulo: Pioneira Thomson, 1992. PRESSMAN, Roger S. Engenharia de Sofware. Editora MAKRON Books 1 Edição. Ano: 1995
96
PRESSMAN, Roger S. Engenharia de Software 7° Edição. Editora ABDR Books 1 Edição. Ano: 2011 REZENDE, Denis Alcides. Engenharia de Sofware e Sistemas de informação. Editora BRADSPORT, 3 edição. Ano: 2005. REZENDE, Denis A. Engenharia de Software e Sistemas de Informação. Rio de Janeiro: Brasport, 1999. ROSENBERG, Doug; STEPHENS, Matt; COPE, Mark Collins-. Agile Development with ICONIX Process: People, Process, and Pragmatism. New York: Apress , 2005.
RUMBAUGH, James; BOOCH, Grady; JACOBSON, Ivar. UML: Guia do usuário. Rio de Janeiro: Campus, 2000 SEI, Software Engineering Institute. SEI Report on Undergraduate Software Engineering Educadion (CMU/SEI-90-TR-003), 1990. SILVA, Alberto Manuel Rodrigues da; VIDEIRA, Carlos Alberto Escaleira. Linguagem de Modelação UML, Metodologias e Ferramentas CASE na Concepção e Desenvolvimento de Software. Porto: Centro Atlântico, 2001. 552 p. SOMMERVILLE, Ian. Engenharia de software. São Paulo. 6. ed. Pearson Education Companion, 2003. MENÉNDEZ, Andrés Ignácio Martínez. Uma ferramenta de apoio ao desenvolvimento de Web Services. Dissertação de Mestrado, Universidade Federal de Campina Grande, curso de Pós-Graduação em Informática, 2002. 97 p. Watson , Thomas J. Software Engineering Tools and Environments: A Roadmap. 2000. Disponível em: <http://dl.acm.org/citation.cfm?id=336569>. Acesso em: 31 MAR. 2013. Milani, Andre. MySQL: Guia do Programador. São Paulo. 1. ed. Editora Novatec, 2006. Aniszczyk, Chris; Gallardo, David. Introdução à Plataforma Eclipse. 2012. Disponível em: < http://www.ibm.com/developerworks/br/library/os-eclipse-platform/>. Acesso em: 20 MAI. 2014. Red Hat. HIBERNATE - Persistência Relacional para Java Idiomático. 2004. Disponível em: <https://docs.jboss.org/hibernate/orm/3.5/reference/pt-BR/html/preface.html>. Acesso em: 25 MAI. 2014. Magnani Jr, Mauricio. Administrando JBoss Application Server 7. 2013. Disponível em: < https://community.jboss.org/wiki/AdministrandoJBossApplicationServer7-Parte1 >. Acesso em: 26 MAI. 2014.
97
APÊNDICES
98
APÊNDICE A – Cronograma
Atividade Mar/ 2013
Abril/201
3
Maio/201
3
Jun/2013
Mar/2014
Abril/201
4
Maio/201
4
Jun/2014
Julho/ 2014
Capítulo 2- Correções
X X X X
Capítulo 3- Correções
X
X
Capítulo 4-
Desenvolvimento
X X X X
Capítulo 5 -
Desenvolvimento
X X
Desenvolvimento de views plug-in eclipse
X X X X X
Desenvolvimento da
integração
X X X X X
Validação e testes da implementação
X
Resumo
X X
Revisão da monografia
X
Entrega
X X
Defesa
X