See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/328470591

Analysis of Open-Source CASE Tools for Supporting Software Modeling Process

with UML

Conference Paper · October 2018

DOI: 10.1145/3275245.3275251

CITATIONS READS
4 381

3 authors, including:

Sávio Freire
Federal Institute of Ceará
47 PUBLICATIONS   163 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Sávio Freire on 09 May 2019.

The user has requested enhancement of the downloaded file.

 Analysis of Open-Source CASE Tools for Supporting Software
Modeling Process with UML
Emmanuel Sávio Silva Freire Gabriel Cavalcante Oliveira
Teaching Department Teaching Department
Federal Institute of Ceará (IFCE) Federal Institute of Ceará (IFCE)
Morada Nova, Ceará, Brazil Morada Nova, Ceará, Brazil
savio.freire@ifce.edu.br gabrielcavalcante1209@gmail.com
ABSTRACT
Good modeling practices or guidelines guide the construction of
UML diagrams allowing higher quality software. When these
guidelines are mapping in a CASE tool, they can support the
creation of models following the UML syntax. Thus, this article
aimed to verify the guidelines addressed by the open-source CASE
tools that allow the creation of the five most used UML diagrams by
software engineers. Therefore, thirteen tools were analyzed:
ArgoUML, StarUML, UMLet, DiaUML, BOUML, Violet, UML
Designer, Modelio, NClass, Plantuml, Umbrello, Open
ModelSphere, and Papyrus. As results, it was found that StarUML
and UML Designer attended the highest number of good practices.
Although all diagrams were considered by these tools, Use Case and
Sequence UML diagrams were the ones that had the most good
practices numbers attended.
CCS CONCEPTS
• Software and its engineering → Unified Modeling Language
(UML) • Software and its engineering → Software maintenance
tools
KEYWORDS
Good modeling practices, open-source CASE tools, UML
ACM Reference format:
Emmanuel Sávio Silva Freire, Gabriel Cavalcante Oliveira, and Maria
Eurizene de Sousa Gomes. 2018. Analysis of Open-Source CASE Tools
for Supporting Software Modeling Process with UML. In 17th Brazilian
Symposium on Software Quality (SBQS), October 17–19, 2018, Curitiba,
Brazil. ACM, New York, NY, USA, 10 pages.
https://doi.org/10.1145/3275245.3275251
1 Introdução
O Processo de Desenvolvimento de Software (PDS) é formado
por um conjunto de atividades com o intuito de produzir software
© 2018 Association for Computing Machinery. ACM acknowledges that this
contribution was authored or co-authored by an employee, contractor or affiliate of
a national government. As such, the Government retains a nonexclusive, royalty-
free right to publish or reproduce this article, or to allow others to do so, for
Government purposes only.
SBQS, October 17–19, 2018, Curitiba, Brazil
© 2018 Association for Computing Machinery.
ACM ISBN 978-1-4503-6565-9/18/10…$15.00
https://doi.org/10.1145/3275245.3275251
Maria Eurizene de Sousa Gomes
Teaching Department
Federal Institute of Ceará (IFCE)
Morada Nova, Ceará, Brazil
euryzennesousagomes@gmail.com
[1]. Dentre essas atividades, destaca-se a modelagem de sistemas.
Por meio dela, é possível representar as diferentes perspectivas do
sistema via modelos. Neste sentido, a Unified Modeling Language
(UML) [2] tem sido utilizada como linguagem padrão e possui um
conjunto de quatorze diagramas na sua versão 2.5.1. Entretanto,
os diagramas de casos de uso, de classe, de atividade, de
sequência e de estado são os mais utilizados pelos engenheiros de
software para representar um sistema [1].
Para auxiliar essa atividade, as ferramentas de suporte à
Engenharia de Software (do inglês, Computer-Aided Software
Engineering (CASE)) têm proporcionado um conjunto de
funcionalidades para automatizar a confecção dos diagramas
UML. Essas ferramentas podem ser proprietárias ou open-source.
Assim, as ferramentas open-source possuem o código disponível
para eventuais melhorias ou inclusão de novas funcionalidades.
Vários autores [3] [5] [6] [7] [8] [9] [10] têm analisado as
ferramentas CASE em diferentes aspectos, a saber:
funcionalidades, usabilidade, qualidade de modelos gerados e
boas práticas de modelagem. Mais especificamente, o trabalho de
Cunha, Costa e Parreira Junior [10] analisaram e compararam um
conjunto de ferramentas CASE em relação ao subconjunto de
diretrizes de modelagem definidas por Ambler [11]. Além disso,
esses autores realizaram um estudo experimental utilizando as
ferramentas que melhor e pior atenderam às diretrizes utilizadas.
O objetivo foi verificar se a ferramenta influenciava a qualidade
dos modelos gerados. Entretanto, foram utilizadas apenas
ferramentas proprietárias na análise realizada por esses autores.
Neste sentido, o presente artigo teve como objetivo analisar
um conjunto de ferramentas open-source em relação às diretrizes
de modelagem presentes na Literatura. Mais especificamente,
foram utilizadas as diretrizes de Ambler [11] e Bezerra [12] para
verificar e comparar as ferramentas ArgoUML, StarUML, UMLet,
DiaUML, BOUML, Violet, UML Designer, Modelio, NClass,
Plantuml, Umbrello, Open ModelSphere e Papyrus.
Vale ressaltar que foi utilizado o mesmo processo de análise e
comparação retratado por [10]. Entretanto, foram incluídas novas
diretrizes de Ambler [11] e incluídas as de Bezerra [12],
totalizando 40 diretrizes. Assim, cada ferramenta foi analisada em
relação ao conjunto dessas diretrizes considerando os cinco
diagramas mais utilizados da UML (de casos de uso, de classe, de
atividade, de sequência e de estado).
Esse estudo se justifica pelo fato da utilização das ferramentas
open-source tanto no mundo acadêmico quanto na indústria.
SBQS, October 17-19, 2018, Curitiba, Brazil
Logo, a identificação das boas práticas de modelagem seguidas
por cada ferramenta torna-se um importante critério para auxiliar
no processo de escolha de ferramentas para modelagem de
sistemas. Além disso, por se tratar de ferramentas de código livre,
pode-se evoluir as ferramentas melhor avaliadas com o intuito de
aumentar a quantidade de diretrizes atendidas, e,
consequentemente, maximizar a possibilidade de confecção de
modelos cada vez mais corretos. Em outras palavras, modelos que
seguem as especificações da UML.
Este artigo está organizado como segue. A seção 2 apresenta
os conceitos relacionados com a modelagem de sistemas, as
ferramentas CASE e a diretrizes para a modelagem de software. A
discussão acerca dos trabalhos relacionados é apresentada na
seção 3. A seção 4 detalha a análise das ferramentas open-source.
Finalmente, as considerações finais são apresentadas na seção 5.
2 Fundamentação Teórica
Esta seção apresenta os conceitos relacionados à modelagem de
sistemas, às ferramentas CASE e às diretrizes para modelagem de
software utilizando os diagramas da UML.
2.1 Modelagem de Sistemas
Um Processo de Desenvolvimento de Software (PDS) é um
conjunto de atividades que produz um produto de software [1].
Além disso, esse processo é composto pelas seguintes atividades
básicas: especificação, desenvolvimento, validação e evolução [1].
Mais especificamente, a atividade de desenvolvimento é formada
pelos estágios de projeto e implementação.
O estágio de projeto está relacionado com a modelagem de
sistemas, que se caracteriza pela utilização de modelos para
representar uma visão ou perspectiva diferente do sistema a ser
desenvolvido [1]. Segundo Bezerra [12], a modelagem auxilia a
gerenciar a complexidade intrínseca ao desenvolvimento de
sistemas de software, facilita a comunicação entre as pessoas
envolvidas, reduz os custos de desenvolvimento e suporta a
previsão do comportamento futuro do sistema.
Neste contexto, a Unified Modeling Language (UML) [2] tem
sido a linguagem padrão para a modelagem de sistemas. Na sua
versão atual (2.5.1), a UML possui sete diagramas estruturais
(classe, pacote, componente, perfil, estrutura composta, objeto e
implantação) e sete diagramas comportamentais (casos de uso,
atividade, estados e interação (sequência, comunicação, visão
geral de interação, temporização)). Por meio deles, é possível
modelar as diferentes visões complementares de um sistema.
Dentre os diagramas que compõem a UML, os diagramas de
casos de uso, de classe, de estado, de sequência e de atividade são
os mais utilizados pelos engenheiros de software para representar
um sistema [1]. A seguir, cada um desses diagramas é definido [2]:
• Diagrama de casos de uso: Apresenta a interação entre os
atores do sistema e suas funcionalidades (casos de uso);
• Diagrama de classes: Descreve a estrutura de classes que
compõem o sistema;
E. S. S. Freire et al.
• Diagrama de estado: Apresenta os diversos estados que um
objeto pode assumir durante o seu ciclo de vida;
• Diagrama de sequência: Descreve a interação entre os
objetos e atores por meio da sequência de mensagens
trocadas;
• Diagrama de atividade: Apresenta o fluxo de controle de
uma atividade para outra.
Vale ressaltar que os diagramas supracitados apresentam a
estrutura do sistema por meio do diagrama de classes e as
interações entre as entidades internas e externas por meio dos
outros diagramas. Com isso, tem-se diferentes perspectivas
complementares do sistema que irão auxiliar na fase de
desenvolvimento de sistemas.
2.2 Ferramentas CASE
O termo Computer-Aided Software Engineering (CASE) se refere
às ferramentas que auxiliam o PDS por meio da automatização
das suas atividades [1]. Essas ferramentas possuem um conjunto
de funcionalidades relacionado às atividades ou ao estágio do
processo. Além disso, essas ferramentas podem ser integradas
formando um CASE workbench, possibilitando o apoio aos
diversos estágios que compõem uma atividade do PDS.
Segundo Bezerra [12], as principais funcionalidades
disponibilizadas pelas ferramentas CASE são:
• A criação e manutenção da consistência de diagramas UML;
• A exportação do diagrama no formato XMI (XML Metadata
Interchange), possibilitando a interoperabilidade entre
diferentes ferramentas CASE;
• Manutenção da consistência entre os modelos gerados;
• Engenharia Round-Trip, que permite a interação entre a
ferramenta CASE e o código-fonte. Assim, é possível gerar
código a partir dos modelos e vice-versa;
• Rastreamento de requisitos, que possibilita localizar os
artefatos gerados relacionados a um requisito de software.
Adicionalmente, essas ferramentas podem possibilitar que o
designer utilize um conjunto de símbolos equivalentes aos
definidos na UML para a criação visual dos seus diagramas.
Entretanto, outras ferramentas, como PlantUML e UMLet,
utilizam notação textual para a definição dos diagramas UML.
Vale ressaltar que essas ferramentas podem ser proprietárias ou
open-source [3]. Uma ferramenta proprietária não permite o
acesso gratuito ao código, diferentemente das ferramentas open-
source. Conforme Garcia et al. [4], as ferramentas open-source
apresentam as seguintes vantagens: (i) são gratuitas para ser
utilizadas, (ii) são flexíveis, (iii) proporcionam vantagens
econômicas, (iv) permitem a liberdade de executar o programa e
analisar o seu funcionamento, (v) podem ser aprimoradas e
customizadas, (vi) permitem o acesso ao código-fonte, e (vii)
possuem pouca vulnerabilidade à invasão de vírus.
Dentre as ferramentas open-source para a modelagem de
sistemas, pode-se citar: ArgoUML, StarUML, UMLet, DiaUML,
BOUML, Violet, UML Designer, Modelio, NClass, Plantuml,
Umbrello, Open ModelSphere e Papyrus. As ferramentas
Analysis of Open-Source CASE Tools for Supporting Software
Modeling Process with UML
Enterprise Architect, Gliffy, Vision e Rational Rose são exemplos
de CASE proprietárias.
2.3 Diretrizes para a Modelagem de Software
As diretrizes de modelagem de software auxiliam na boa
formação dos modelos utilizando a UML [11]. Assim, as
ferramentas CASE que apoiam a fase de modelagem deveriam
considerar essas diretrizes para interferir positivamente na
qualidade dos diagramas confeccionados [10].
Neste sentido, Ambler [11] definiu um conjunto de 308
diretrizes divididas em: (i) propósito geral, que podem ser
aplicadas para a maioria dos diagramas UML, e (ii) um
subconjunto para cada um dos treze diagramas da versão 2.0 da
linguagem. Como exemplo dessas diretrizes, pode-se citar: para o
diagrama de classes, “deve-se sempre indicar a multiplicidade
entre as classes”.
Além disso, Bezerra [12] também cita boas práticas de
construção de diagrama UML à medida que explica sobre os
diagramas da versão 2.5. Para o diagrama de casos de uso, o autor
define os relacionamentos possíveis entre as entidades que
compõem esse diagrama (veja a Tabela 1). Além disso, outras
diretrizes são definidas para os demais diagramas da UML.
Tabela 1: Relacionamentos possíveis no diagrama de casos de
uso [12]
Caso de Uso e Ator e Ator Caso de Uso
Caso de Uso e Ator
Comunicação X ferramenta ArgoUML.
Extensão X A pesquisa realizada por Costa, Werneck e Campos [7]
Inclusão X utilizou a norma brasileira NBR 13596 para avaliar as ferramentas
Generalização X X
Vale ressaltar que a verificação das diretrizes pode ser feita
por meio de uma funcionalidade explícita na ferramenta e/ou por
meio de prevenção de erros. Por um lado, a primeira abordagem
possibilita que o usuário possa executar a verificação de modelos
a qualquer momento. Por outro lado, a segunda abordagem não
permite que o erro de modelagem aconteça. Por exemplo, segundo
a Tabela 1, um usuário não deveria conseguir vincular um ator a
outro ator por meio do relacionamento de inclusão em uma
ferramenta que utilizasse a segunda abordagem.
3 Trabalhos Relacionados
Esta seção apresenta a análise dos trabalhos relacionados com a
presente pesquisa. Para tanto, os trabalhos de Foresti e de Bortoli
[5], Oliveira, Souza e Figueiredo [6], Costa, Werneck e Campos
[7], Silva, Alturas e Carneiro [3], Chupac, Mudron e Kana [8],
Khaled [9] e Cunha, Costa e Parreira Junior [10] foram
considerados por abordar a análise de ferramentas CASE para
apoio às atividades da Engenharia de Software.
Foresti e de Bortoli [5] propuseram 57 diretrizes para analisar
ferramentas de apoio à UML. Essas diretrizes foram divididas em
SBQS, October 17-19, 2018, Curitiba, Brazil
oito categorias, a saber: (i) baseados na norma ISO/IEC 9126
(NBR 13596), (ii) baseados em características de hardware e
software, (iii) baseados no repositório de dados, (iv) baseados na
documentação, (v) baseados no uso da ferramenta com relação ao
computador utilizado, (vi) baseados na UML, (vii) baseado no
fornecedor, e (viii) baseados nas necessidades identificadas com a
utilização das ferramentas. Com o intuito de validar as diretrizes,
as autoras elaboraram um estudo de caso contendo os diagramas
de casos de uso, de classes, de sequência, de estado e de
atividades. Para tanto, foram consideradas as seguintes
ferramentas: Rational Rose C++ Demo, PowerDesigner 9.0,
Together ControlCenter 6.1, AllFusion Component Modeler 4.1,
Enterprise Architect 3.51, Poseidon for UML Community Edition
1.6 e ArgoUML 0.14. Como resultados, foram apresentadas a
comparação entre as ferramentas e a validação das diretrizes
propostas.
O trabalho de Oliveira, Souza e Figueiredo [6] analisou as
ferramentas ArgoUML e Gliffy que possibilitam a modelagem
UML via desktop e online, respectivamente. Para tanto, foi
elaborado um experimento para analisar essas ferramentas em
relação à usabilidade do ponto de vista dos alunos de graduação e
pós-graduação da disciplina de Engenharia de Software
Experimental da Universidade Federal de Minas Gerais (UFMG).
Assim, foram considerados o tempo gasto para elaborar os
diagramas, a quantidade de erros cometidos, o número de
diagramas incompletos e a quantidade de vezes que os
pesquisadores foram consultados pelos participantes do
experimento. Como conclusões, a ferramenta Gliffy apresentou
maior facilidade de uso, logo, possui melhor usabilidade que a
gratuitas Dia, ArgoUML, Umbrello e Jude. Assim, os critérios
utilizados seguiram as características da referida norma, a saber:
(i) funcionalidade, (ii) confiabilidade, (iii) usabilidade, (iv)
eficiência, (v) manutenibilidade, e (vi) portabilidade. Como
resultados, os autores encontraram que a ferramenta Jude
apresentou melhor pontuação em relação à comparação com as
outras ferramentas participantes da pesquisa.
Os autores Silva, Alturas e Carneiro [3] analisaram as
ferramentas open-source ArgoUML e DiaUML e a ferramenta
proprietária Visio em relação aos aspectos de usabilidade. Para
tanto, os alunos do curso de pós-graduação em Informática
Aplicada à Organizações foram os sujeitos da pesquisa e
preencheram o questionário proposto pelos autores após a
utilização de um modelo elaborado para o estudo. Os resultados
obtidos demonstraram que a ferramenta Visio apresentou
melhores resultados, pois os sujeitos da pesquisa tiveram maior
facilidade de aprendizado e maior produtividade.
Chupac, Mudron e Kana [8] analisaram quatorze ferramentas
que suportam a modelagem dos diagramas UML e verificaram se
elas possuíam possibilidade de simulação de modelos, quais as
versões da UML suportadas, quais os formatos para a exportação do
projeto e dos diagramas, dentre outros critérios. A ferramentas
SBQS, October 17-19, 2018, Curitiba, Brazil
analisadas foram: Visual Paradigm 8.3 (Enterprise Edition),
MagicDraw 17.0.1 (Enterprise Edition), StarUML 5.0, UModel
2012 (Enterprise Edition), CaseComplete 2012, EnterpriseArchitect
9.2 (Corporate Edition), SketchUML, Bridgepoint 3.4.6,
PowerDesigner 16.1, Artisan Studio 7.3, Objecteering 6.1
(Enterprise Edition), Rational Software Architect 8.0, Blueprint
Software Modeler (Community Edition), e Innovator 11 for
software architects. Considerando a pontuação atribuída a cada
ferramenta, foi concluído que as ferramentas Enterprise Architect e
Visual Paradigm contemplavam a maioria dos critérios utilizados.
Dentre eles, pode-se citar o suporte (i) ao MDA (Model-driven
Architecture), (ii) à exportação de documentos, (iii) à engenharia
reversa e (iv) à geração de código-fonte.
A pesquisa de Khaled [9] comparou as ferramentas Rational
Rose, ArgoUML, MagicDraw e Enterprise Architect considerando
os seguintes critérios: (i) geração de documentação HTML, (ii)
suporte a todos os diagramas previstos nas versões 1.5 e 2.0 da
UML, (iii) engenharia reversa, ou seja, transformação de modelos
em código e vice-versa, (iv) integração com ferramentas de
modelagem de dados, (v) exportação do diagrama para outros
formatos, e (vi) robustez, ou seja, prevenir que os usuários percam
seu trabalho devido a um erro na ferramenta. Como resultados, os
autores indicaram os pontos fortes de cada ferramenta. Por exemplo,
a Rational Rose fornece suporte a todos os diagramas da UML.
Os autores Cunha, Costa e Parreira Junior [10] realizaram uma
comparação entre as ferramentas Rational Software, MagicDraw,
UModel, Visual Paradigma e Enterprise Architect em relação às
boas práticas de modelagem de software. Os critérios de
comparação utilizados foram as diretrizes definidas por Ambler
[11]. Dessa análise, as ferramentas Rational Software e
MagicDraw contemplaram a maior e a menor quantidade de
diretrizes, respectivamente. Assim, os autores realizaram um
estudo experimental considerando essas duas ferramentas e tendo
como participantes, dez alunos do curso de Ciências da
Computação da Universidade Federal de Goiás (UFG). Com isso,
foi atestado que a ferramenta pode interferir na qualidade dos
diagramas confeccionados, pois os alunos que utilizaram a
ferramenta Rational Software obtiveram melhores resultados.
Em comparação com o presente trabalho, todos os trabalhos
dessa seção analisaram ferramentas de apoio à modelagem de
software. Dentre eles, a pesquisa de [5] e [7] utilizaram a norma
ISO/IEC 9126 (NBR 13596), para avaliar ferramentas, mas a
qualidade dos diagramas UML não foi o foco dessas pesquisas.
Além disso, os trabalhos de Oliveira, Souza e Figueiredo [6] e
Silva, Alturas e Carneiro [3] consideraram ferramentas open-
source na sua análise, porém foram analisados somente aspectos
de usabilidade. Os trabalhos de [8] e [9] não contemplaram
nenhuma diretriz relacionada com a qualidade de modelos UML,
pois consideraram apenas as funcionalidades que cada ferramenta
analisada disponibilizava. Entretanto, o trabalho de Cunha, Costa
e Parreira Junior [10] se aproximam mais do presente trabalho
pois consideram diretrizes para analisar a qualidade dos modelos
UML, porém o foco desses autores [10] foram ferramentas
proprietárias, diferenciando-se do escopo do presente trabalho que
utiliza ferramentas open-source. Vale ressaltar que as diretrizes
E. S. S. Freire et al.
utilizadas pelo presente trabalho também são as propostas por [11]
em conjunto com as propostas por Bezerra [12].
4 Análise das Ferramentas Open-Source
Nesta seção, são detalhadas as diretrizes escolhidas para a análise
das ferramentas CASE open-source e a visão geral delas em
relação as suas funcionalidades. Adicionalmente, o resultado da
análise dessas ferramentas é apresentado juntamente com as
ameaças à validade desse estudo.
4.1 Escolha das Diretrizes e das Ferramentas
Inicialmente, foram escolhidas as diretrizes para a análise das
ferramentas considerando as utilizadas por Cunha, Costa e
Parreira Junior [10]. Vale ressaltar que esses autores selecionaram
e utilizaram um subconjunto das diretrizes propostas por Ambler
[11]. Portanto, foram analisadas todas as diretrizes de [11] com o
intuito de verificar quais as novas diretrizes poderiam ser
utilizadas no presente trabalho que não foram utilizadas por [10].
Consequentemente, algumas diretrizes foram incluídas e outras
removidas. Essa análise foi realizada em conjunto pelos três
autores e o intuito foi identificar as diretrizes passíveis de
verificação automática (independentes do designer).
Um ponto importante a ser discutido é que as diretrizes de
Ambler [11] definem boas práticas relacionadas em sua maioria
ao estilo de modelagem utilizando UML. Por exemplo, a
superclasse deve ficar acima das subclasses no diagrama de
classes. Assim, aspectos relacionados às normas de modelagem
UML não são completamente contempladas. Por outro lado, as
diretrizes de modelagem evidenciadas por Bezerra [12] se tornam
complementares a de [11], pois retratam regras de relacionamento
entre os elementos dos diagramas e as informações mínimas para
representá-los.
Neste sentido, o presente trabalho utilizou um subconjunto das
diretrizes de Ambler [11] e de Bezerra [12]. Essas diretrizes foram
escolhidas em conjunto pelos autores do presente trabalho e as
divergências encontradas durante o processo de escolha foram
discutidas considerando o ponto de vista dos autores dessa
pesquisa e as divergências conceituais existentes nas diretrizes de
[11] e [12]. Um exemplo dessas divergências conceituais estava
relacionado com a interação entre atores no diagrama de casos de
uso. Ambler [11] afirmava que um ator não deveria interagir com
outro ator, logo, não poderia haver nenhum relacionamento entre
atores. Essa diretriz foi desconsiderada, pois os atores podem se
relacionar por meio da herança, ou seja, um ator filho herda o
comportamento do ator pai. Essa possibilidade da UML foi
mapeada por [12].
A Tabela 2 apresenta as 40 diretrizes utilizadas pelo presente
trabalho para a avaliação e a comparação das ferramentas open-
source. Por meio dela, é possível identificar as diretrizes por diagrama
e por autor. Além disso, um identificador para cada diretriz também
foi incluído. Vale salientar que foram utilizadas 22 diretrizes de
Ambler e 18 de Bezerra.
As diretrizes contemplam os cinco diagramas mais utilizados
da UML conforme [1], a saber: diagrama de casos de uso, de
Analysis of Open-Source CASE Tools for Supporting Software
Modeling Process with UML
classes, de estado, de sequência e de atividades. Adicionalmente,
as diretrizes de [11] estão relacionadas à versão 2.0 enquanto as
de [12] contemplam a versão 2.5. Essa diferença de versões
também foi considerada na escolha das diretrizes. Logo, o
presente trabalho considerou a versão mais atual da UML (2.5).
Tabela 2: Diretrizes utilizadas na avaliação
Autor # Diretriz
1 Associar cada ator com pelo menos um caso
[11] de uso.
2 Usar «System» para indicar um ator sistema.
3 Não permitir que atores sejam relacionados
Diagrama de Casos de Uso
por «include».
4 Não permitir que atores sejam relacionados
por «extends».
5 Não associar ator com caso de uso via
generalização.
6 Permitir que casos de uso sejam
[12]
relacionados via «include».
7 Permitir que casos de uso sejam
relacionados via «extends».
8 Permitir que casos de uso sejam
relacionados via generalização.
9 Permitir que atores sejam relacionados via
generalização.
10 Não colocar nome de associação com o
mesmo nome de alguma classe.
11 Iniciar nome de operações com verbo no
infinitivo.
[11]
Diagrama de Classes
12 Indicar a visibilidade dos métodos da classe.
13 Criar classes que contenha um box para
nome, um para atributos e outros métodos.
14 Sempre indicar a multiplicidade da relação.
15 Permitir associações reflexivas entre objetos
da mesma classe.
16 Em uma composição, não permitir que os
[12] objetos parte pertençam a mais de um todo.
17 Em uma agregação, permitir que um mesmo
objeto pertença como componente de vários
outros objetos.
18 Evitar nomear ator com o mesmo nome de
uma classe.
19 Evitar destruição de objetos.
20 Sempre indicar valor de retorno ao lado das
Diagrama de Sequência
mensagens.
[11] 21 Evitar usar boxes de ativação durante a
execução do diagrama.
22 Evitar criar objetos durante a execução do
diagrama.
23 Evitar descrever o tipo dos parâmetros de
entrada.
24 Permitir mensagens reflexivas.
25 Garantir que o operador "alt" possua pelo
[12] menos dois operandos.
26 Garantir que o operador "opt" possua apenas
um operando.
SBQS, October 17-19, 2018, Curitiba, Brazil
27 Sempre indicar um ponto inicial.
28 Sempre indicar um ponto final.
Diagrama de Atividades
29 Garantir que um "fork" tenha somente uma
[11] entrada.
30 Garantir que um "join" tenha somente uma
saída.
31 Evitar usar mais do que 5 “Swim Lanes”.
32 Garantir que cada caminho de um ponto de
decisão tenha uma guarda.
[12]
33 Garantir que uma atividade esteja relacionada
a outro elemento do diagrama.
34 Criar um estado inicial.
35 Indicar a ação de entrada.
Diagrama de Estados
[11] 36 Colocar nomes de transição no passado.
37 Nunca coloque uma guarda em uma
transição inicial.
38 Permitir transição reflexiva.
39 Garantir que cada caminho de um ponto de
[12] decisão tenha uma guarda.
40 Garantir que cada estado esteja relacionado a
outro elemento do diagrama.
Após a escolha das diretrizes, foram apontadas as ferramentas
open-source utilizadas no presente trabalho. Para tanto, foram
pesquisados em sites e blogs sobre as ferramentas mais utilizadas
da UML e nos artigos apresentados e discutidos na Seção 3. Um
dos sites consultados foi o da PAT RESEARCH 1 que continha
uma lista das ferramentas CASE open-source e proprietárias para
a modelagem utilizando a UML. Neste site, as ferramentas
estavam ordenadas considerando a nota de avaliação do editor do
site (editor rating) e a dos leitores do site (aggregated user
rating). Assim, foram consideradas as seguintes ferramentas:
ArgoUML, StarUML, UMLet, DiaUML, BOUML, Violet, UML
Designer, Modelio, NClass, Plantuml, Umbrello, Open Model
Sphere e Papyrus. A Tabela 3 apresenta as versões e os links de
download de cada ferramenta.
4.2 Visão Geral das Ferramentas
As ferramentas CASE citadas na subseção 4.1 foram analisadas
seguindo os procedimentos definidos por [10]. Essa análise foi
realizada pelos três autores do trabalho. Cada autor analisou todas
as ferramentas de forma separada e, finalmente, os resultados
divergentes foram discutidos e resolvidos. Dois autores eram
alunos do curso técnico em Informática e o outro é professor e
mestre em Computação com ênfase em Engenharia de Software.
Os dois alunos tinham cursado a disciplina de Engenharia de
Software e tinham estudado sobre os diagramas abordados na
pesquisa.
Além disso, foi elaborado um caso de teste para cada uma das
diretrizes apresentadas na Tabela 2. Cada caso de teste contradizia
uma dessas diretrizes. Por exemplo, a diretriz #3 indica que “Não
permitir que atores sejam relacionados por «include»”. Assim, o
1
https://www.predictiveanalyticstoday.com/open-source-free-unified-modeling-language-
uml-tools/
SBQS, October 17-19, 2018, Curitiba, Brazil E. S. S. Freire et al.

caso de teste referente a essa diretriz especificava que dois ou • C3: Verificação da consistência entre os modelos
mais atores estavam associados pelo relacionamento «include». gerados,
Em seguida, os casos de testes foram confrontados com as • C4: Engenharia Round-Trip, e
ferramentas supracitadas com o intuito de identificar quais as • C5: Rastreamento de requisitos.
diretrizes contempladas. Além disso, buscou-se também Vale ressaltar que para o critério C1, foram consideradas as
identificar se as ferramentas evitavam a modelagem incorreta dos seguintes opções: (i) visual, relacionada com o uso de elementos
diagramas e/ou alertavam aos usuários sobre os erros de gráficos, e (ii) textual, relacionada com a utilização de linguagem
modelagem. textual para definir os elementos do diagrama e seus
relacionamentos. Além disso, para o critério C4, as opções
possíveis eram: (i) direta (D), que possibilita a geração de código-
Tabela 3: Versão das ferramentas open-source analisadas
fonte a partir de diagramas, e (ii) reversa (R), que corresponde a
geração de diagramas a partir de um código-fonte.
Ferramentas Versão Link de Acesso
ArgoUML 0.34 http://argouml.tigris.org//
StarUML 5.0.2.157 http://staruml.sourceforge.net/ Tabela 4: Características das ferramentas
0 v1/download.php
UMLet 14.2 http://www.umlet.com/ Ferramentas C1 C2 C3 C4 C5
Dia 0.97.2 http://dia-http://dia- ArgoUML Visual Sim Sim D/R Não
installer.de/index.html StarUML Visual Sim Sim D/R Não
BOUML 7.6 https://www.bouml.fr/downloa Visual/
UMLet Não Não D Não
d.html Textual
Violet 2.1.0 https://sourceforge.net/projects Dia Visual Não Não D Não
/violet/files/latest/download?so BOUML Visual Sim Não D/R Não
urce=files Violet Visual Não Não Não Não
UML Designer 8.1 http://www.umldesigner.org/d UML Designer Visual Não Sim Não Não
ownload/ Modelio Visual Sim Sim Não Não
Modelio 3.7.1 https://www.modelio.org/dow NClass Visual Não Não D Não
nloads/download- Plantuml Textual Não Não Não Não
modelio.html Umbrello Visual Não Não D/R Não
NClass 2.04 http://nclass.sourceforge.net/d Open ModelSphere Visual Sim Sim D Não
ownloads.html Papyrus Visual Não Sim D/R Não
Plantuml 1.2018.8 http://plantuml.com/download
Umbrello 2.25 https://umbrello.kde.org/ Assim, é possível perceber que nenhuma das ferramentas
Open 3.2.2 http://www.modelsphere.com/ analisadas possibilitam o rastreamento de requisitos. Em outras
ModelSphere org/download.html palavras, as ferramentas não dão suporte à vinculação e à
Papyrus 4.0.0 https://www.eclipse.org/papyr identificação dos relacionamentos de dependência entre os
us/download.html#accordion requisitos e os artefatos de modelagem. Além disso, apenas as
ferramentas UMLet e Plantuml possibilitam a confecção de
É importante ressaltar que não foi utilizado o mesmo contexto diagramas via linguagem natural. É importante salientar que os
para a verificação de cada diretriz, pois a análise estava diagramas de sequência e de atividades são confeccionados em
relacionada à sintaxe e à organização do diagrama e não aos linguagem textual na ferramenta UMLet, enquanto as demais são
aspectos de negócio de um contexto específico. Por isso, cada modelados em linguagem visual. Entretanto, em Plantuml,
caso de teste retratou uma diretriz. Por exemplo, a diretriz #1 nenhum diagrama é confeccionado utilizando elementos gráficos
afirmava que “Associar cada ator com um ou mais casos de uso”. diretamente na ferramenta.
Logo, foi modelado um ator que não estava associado a um caso Em relação à exportação dos diagramas no formato XMI,
de uso, independente desse ator ser um Aluno ou um Cliente. O apenas cinco ferramentas apresentaram essa funcionalidade,
importante era verificar se a ferramenta conseguia detectar a permitindo a interoperabilidade entre ferramentas. Essa mesma
ausência do relacionamento como um erro de modelagem. quantidade de ferramentas possibilita a transformação de
A Tabela 4 apresenta uma síntese das principais características diagramas em código e vice-versa. Sobre a consistência de
e funcionalidades de cada uma das ferramentas analisadas. Foram modelos, apenas seis ferramentas permitem a checagem das regras
utilizados os critérios definidos por Bezerra [12] explicados na de modelagem por meio da funcionalidade de verificação explícita
subseção 2.2. Além disso, foram utilizados os seguintes de modelos. Vale ressaltar que para o presente estudo, essa
identificadores para cada um desses critérios: funcionalidade é decisiva para verificar se as diretrizes
• C1: Criação de diagramas UML, apresentadas na Tabela 2 são contempladas em cada ferramenta.
• C2: Exportação do diagrama no formato XMI, Além disso, torna-se complementar à abordagem de prevenção de
Analysis of Open-Source CASE Tools for Supporting Software
SBQS, October 17-19, 2018, Curitiba, Brazil
Modeling Process with UML

erros. A Figura 1 apresenta o item de menu de cada ferramenta 4.3 Análise das Ferramentas considerando as
para a verificação de modelos. Diretrizes de Modelagem
Considerando as diretrizes apresentadas na Tabela 2, foi realizada
ArgoUML StarUML
a análise das ferramentas CASE descritas na subseção 4.2. A
Tabela 5 mostra o resultado da análise realizada. Assim, é
possível identificar quais as diretrizes que são contempladas por
cada ferramenta.

[...]
Tabela 5: Resultado da Análise das Ferramentas Open-Source

Ferramentas Diretrizes Contempladas Total

UML Designer Modelio ArgoUML #3, #4, #5, #6, #7, #8, #9, #12, 14
#13, #15, #17, #21, #24, #37
StarUML #2, #3, #4, #6, #7, #8, #9, #12, 21
#13, #15, #17, #18, #19, #20,
#22, #23, #24, #25, #29, #30,
#38
[...] UMLet #3, #4, #6, #7, #8, #9, #13, 11
[...]
#15, #17, #24, #38
Dia #6, #7, #8, #9, #12, #13, #15, 10
#17, #24, #38
BOUML #3, #4, #5, #6, #7, #8, #9, #12, 15
#13, #15, #17, #24, #29, #30,
#38
Violet #6, #7, #8, #9, #13, #15, #17, 11
Open ModelSphere #19, #22, #24, #38
UML Designer #2, #3, #4, #5, #6, #7, #8, #9, 21
#12, #13, #14, #15, #17, #18,
#19, #20, #22, #24, #29, #30,
#38
Modelio #3, #4, #5, #6, #7, #8, #9, #12, 15
#13, #14, #15, #17, #24, #26,
#38
NClass #12, #13, #15, #17 4
Plantuml #6, #7, #8, #9, #13, #15, #17, 13
#18, #19, #21, #24, #29, #38
Umbrello #3, #4, #5, #8, #9, #12, #13, 17
#15, #17, #18, #20, #22, #23,
#24, #25, #26, #38
Open ModelSphere #1, #3, #4, #5, #12, #13, #14, 15
#17, #19, #22, #23, #29, #30,
Papyrus #33, #40
Papyrus #3, #4, #5, #6, #7, #8, #9, #12, 16
#13, #14, #15, #17, #24, #25,
#26, #38

Com isso, é possível notar que as ferramentas StarUML e

Figura 1: Verificação da consistência de modelos
Em relação aos diagramas, a ferramenta NClass dá suporte
apenas à modelagem do diagrama de classes, enquanto as demais
possibilitam a confecção dos cinco diagramas abordados nesse
estudo.
UML Designer conseguiram atender ao maior número de
diretrizes. Por outro lado, a ferramenta Dia suporta apenas 10 das
diretrizes consideradas na análise. É importante ressaltar que a
ferramenta NClass obteve uma quantidade menor que Dia, porém
NClass dá suporte a apenas o diagrama de classes da UML.
Além disso, a Figura 2 apresenta as diretrizes que foram e não
foram atendidas por ferramenta. Com isso, é possível perceber
que as diretrizes #10, #11, #16, #27, #28, #31, #32, #34, #35, #36
e #39 não são atendidas por nenhuma das ferramentas analisadas.
SBQS, October 17-19, 2018, Curitiba, Brazil
A maioria dessas diretrizes auxilia na organização do diagrama,
aumentando o entendimento do engenheiro de Software. Por outro
lado, a diretrizes #16, #32 e #39 estão relacionadas à sintaxe da
UML, ou seja, impactam diretamente na qualidade da modelagem.
Figura 2: Diretrizes atendidas por ferramenta
As ferramentas também foram analisadas considerando os
cinco diagramas da UML. A Figura 3 apresenta o resultado para o
E. S. S. Freire et al.
diagrama de casos de uso. Pode-se notar que a ferramenta UML
Designer cumpre com oito das nove diretrizes consideradas para
esse diagrama, representando quase 90% de conformidade. Além
disso, as ferramentas ArgoUML, StarUML, BOUML, Modelio e
Papyrus seguem sete diretrizes.
Figura 3: Diretrizes do diagrama de casos de uso
Para o diagrama de classes (veja a Figura 4), pode-se perceber
que as ferramentas UML Designer, Modelio e Papyrus seguem
cinco das oito diretrizes. Esse resultado corresponde a quase 63%
de conformidade.
Figura 4: Diretrizes do diagrama de classes
A Figura 5 mostra que as ferramentas StarUML e Umbrello
seguem sete das nove diretrizes para o diagrama de sequência,
alcançando quase 78% de conformidade.
Em relação ao diagrama de atividades, pode-se notar que
apenas as ferramentas Open ModelSphere, StarUML, BOUML,
Plantuml e UML Designer dão suporte parcial às diretrizes
consideradas nesse estudo. A Figura 6 mostra que a ferramenta
Open ModelSphere possui o melhor resultado. Ela cumpre três das
sete diretrizes, correspondendo a quase 43% de conformidade.
Em relação ao diagrama de estado, com exceção da NClass,
todas as ferramentas atendem a apenas uma das sete diretrizes
utilizadas para analisar esse diagrama. Esse resultado corresponde
a 14% de conformidade.
Analysis of Open-Source CASE Tools for Supporting Software
Modeling Process with UML
Figura 5: Diretrizes do diagrama de sequência
Figura 6: Diretrizes do diagrama de atividade
4.4 Ameaças à Validade
As ameaças à validade são influências que podem limitar a
interpretação ou a conclusão dos dados coletados por um
experimento [13]. As ameaças identificadas no presente trabalho
foram analisadas conforme a taxonomia definida por [13]:
validade de construção, validade interna e validade externa.
Em relação à minimização da ameaça à validade de
construção, além das diretrizes propostas por [11], também foram
consideradas as boas práticas definidas por [12]. Com isso,
aumentou-se a quantidade de diretrizes utilizadas para a análise e
a comparação das ferramentas CASE. Vale ressaltar que
divergências entre as diretrizes foram discutidas pelos autores do
presente trabalho com o intuito de removê-las e manter a
coerências entre as mesmas. Além disso, o processo de escolha de
ferramentas considerou as ferramentas citadas nos trabalhos
relacionados (veja a Seção 3), além de consultar sites e blogs que
abordavam ferramentas CASE para modelagem de sistemas
utilizando a UML.
Para a ameaça à validade interna, a análise das ferramentas foi
realizada pelos autores paralelo e separadamente. Assim, as
divergências encontradas foram discutidas e resolvidas. Além
disso, as dúvidas referentes às funcionalidades suportadas por
cada ferramenta foram analisadas nos manuais de utilização e nos
SBQS, October 17-19, 2018, Curitiba, Brazil
exemplos contidos nos links apresentados na Tabela 3.
Consequentemente, conseguiu-se mitigar a possibilidade dessa
ameaça.
Adicionalmente, os resultados encontrados neste estudo
podem ser utilizados tanto na comunidade científica quanto na
indústria, pois o processo de escolha das ferramentas não
considerou se as mesmas eram utilizadas em apenas uma das
comunidades supracitadas. Com isso, tentou-se inibir às ameaças
de validade externa.
5 Considerações Finais
O presente artigo utilizou as diretrizes de Ambler [11] e Bezerra
[12] com o intuito de analisar e comparar as ferramentas CASE
open-source em relação às boas práticas de modelagem de
software utilizando UML. Ao implementar essas diretrizes como
regras de validação nas ferramentas, proporciona-se uma maneira
de criar modelos mais corretos. Por meio do estudo experimental
de [10], foi possível constatar essa relação entre a interferência da
ferramenta na qualidade dos diagramas confeccionados.
A maioria das diretrizes de Ambler [11] foca no estilo de
modelagem e no posicionamento dos elementos, facilitando o
entendimento dos diagramas. As de Bezerra [12] abordam a
estrutura dos elementos da UML e os possíveis relacionamentos
entre eles. Assim, as diretrizes escolhidas permitem evitar que
erros relacionados à sintaxe da UML ocorram e possibilitam uma
melhor organização do diagrama. Vale salientar que a pesquisa
não buscou pela existência de outras diretrizes. Essa busca poderia
ser uma sugestão de trabalhos futuros, pois poderia refinar o
conjunto de diretrizes utilizado.
Como resultado principal, as ferramentas StarUML e UML
Designer conseguiram atender ao maior número das 40 diretrizes
utilizadas nesse estudo. Houve um empate entre StarUML e UML
Designer, porém o critério de desempate sugerido pode ser o
maior número de características apresentadas na Tabela 4 sendo
que, StarUML, diferentemente de UML Designer, dá suporte a
exportação de diagramas no formato XMI e a engenharia Round-
Trip tanto direta quanto reversa. Além disso, os diagramas de
casos de uso e de sequência foram os que obtiveram o maior
número de diretrizes atendidas pelas treze ferramentas analisadas.
Por meio da pesquisa, foi possível verificar que (i) Dia e
UMLet não apresentavam áreas de trabalho específicas por
diagrama; (ii) a falta da verificação automática de modelo, na
maioria das ferramentas, torna a modelagem mais suscetível a
erros; (iii) a ferramenta NClass, mesmo possibilitando apenas a
modelagem de diagramas de classe, apresentou um desempenho
igual ou inferior às demais ferramentas para o referido diagrama;
(iv) a sintaxe de modelagem textual da UMLet e Pantuml é de
fácil compreensão e exemplos são encontrados no site delas; (v) o
processo de instalação da Open ModelSphere precisa ser
atualizado (ocorreram problemas para a instalação, mas foram
superados); e (vi) algumas ferramentas não são tão intuitivas (foi
necessário procurar por informações no site delas para entender o
funcionamento).
 SBQS, October 17-19, 2018, Curitiba, Brazil E. S. S. Freire et al.

Além disso, as ferramentas precisam ser evoluídas para prover
maior suporte às diretrizes utilizadas nesse estudo. Mais
especificamente, os diagramas de atividade e de estado precisam
de uma atenção maior, pois as ferramentas cumprem com um
percentual baixo de conformidade.
Como lições aprendidas desse estudo, pode-se destacar: (i)
[11] Scott W. Ambler. 2003. The Elements of UML Style. São Paulo: Cambridge
University Press, 2003. 146p.
[12] Eduardo Bezerra. 2015. Princípios de Análise e Projetos de Sistemas com
UML. Rio de Janeiro: Elsevier, 3ª ed., 2015. 416p.
[13] D. E. Perry, A. A. Porter e L. G. Votta. 2000. Empirical studies of software
engineering: A roadmap. In Proceedings of the 22nd International Conference
on Software Engineering, pages: 345–355

mesmo com a automatização das diretrizes, o designer precisa

conhecer a semântica e a sintaxe dos elementos da UML; (ii) nem
sempre é possível automatizar todas as diretrizes disponíveis, pois
algumas podem ser dependentes do designer; (iii) os erros
precisam ser identificados pelas ferramentas para auxiliar na
confecção de diagramas mais corretos; e (iv) a identificação de
erros pode auxiliar no aprendizado das diretrizes.
Como trabalhos futuros, sugere-se: (i) realizar um estudo
experimental para verificar a qualidade dos modelos UML
gerados na ferramenta que mais atendeu (StarUML) e a que
menos atendeu (Dia) as diretrizes, seguindo a abordagem de
Cunha, Costa e Parreira Junior [10]; (ii) fazer uma análise com
ferramentas proprietárias utilizando o mesmo conjunto de
diretrizes e comparar os resultados com os obtidos pelo presente
trabalho; e (iii) realizar uma análise de usabilidade entre as
ferramentas proprietárias e open-source, seguindo o experimento
de Oliveira, Souza e Figueiredo [6].

AGRADECIMENTOS
Os autores agradecem aos revisores do Simpósio Brasileiro de
Qualidade de Software (SBQS) pelos comentários que
engrandeceram o presente artigo.

REFERÊNCIAS
[1] Ian Sommerville. 2011. Engenharia de Software. São Paulo: Pearson Prentice
Hall, 9ª ed., 2011. 544 p.
[2] Object Management Group. 2017. Disponível em:
https://www.omg.org/spec/UML/. Acesso em fev/2018.
[3] I. Silva, B. Alturas e A. Carneiro. 2017. Ferramentas de modelação UML:
avaliação na perspetiva dos utilizadores. In Álvaro Rocha, Bráulio Alturas,
Carlos J. Costa, Luís Paulo Reis e Manuel Pérez Cota (Ed.), 12th Iberian
Conference on Information Systems and Technologies (CISTI). (pp. 2262-
2267). Lisboa: IEEE.
[4] M. N. Garcia, S. M. B. Santos, R. S. Pereira e G. B. Rossi. 2010. Software
livre em relação ao software proprietário: Aspectos favoráveis e desfavoráveis
percebidos por especialistas. In Gestão & Regionalidade 26, 78 (Set. 2010),
106 – 120.
[5] J. Foresti e L. A. de Bortoli. 2004. Ferramentas de apoio a UML: um modelo
para avaliação baseado em requisitos funcionais e não-funcionais.
INFOCOMP 4, 1 (Mar. 2004), 62-69.
[6] J. Oliveira, P. Souza e E. Figueiredo. 2014. Uma avaliação de ferramentas de
modelagem de software. In Anais do I Simpósio Mineiro de Engenharia de
Software (SMES2014), Belo Horizonte, 109-118.
[7] A. N. Costa, V. M. B. Werneck e M. F. Campos. 2008. Avaliação de
ferramentas para desenvolvimento orientado a objetos com UML. Cadernos
do IME: Série Informática 25 (Jul. 2008).
[8] L. Chupac, I. Mudron e K. Kana. 2013. Comparison of UML tools. SGEM
GeoConference on Informatics, Geoinformatics And Remote Sensing
Proceedings 1, (Jun. 2013), 23-28.
[9] Lena Khaled. 2009. A comparison between UML tools. In Second
International Conference on Environmental and Computer Science (ICECS
2009), Dubai, 111-114.
[10] W. S. Cunha, H. Costa e P. A. Parreira Júnior. 2016. Análise de ferramentas
CASE quanto às boas práticas de modelagem de software com UML. In XV
Simpósio Brasileiro de Qualidade de Software (SBQS 2016), Maceió, 51-63.

View publication stats