Fase 1 - Escolha de um editor UML

Relatório da Fase 1.1 do TFC – Desenvolvimento Automático de Sistemas
TRABALHO FINAL DE CURSO
do Curso de
LICENCIATURA EM ENGENHARIA
INFORMÁTICA E DE COMPUTADORES (LEIC)
Ano Lectivo 2004 / 2005
Departamento
de Engenharia
Informática
Relatório da Fase 1.1 do TFC
N.º da Proposta: 12
Título: Desenvolvimento Automático de Sistemas
Professor Orientador:
Alberto Manuel Rodrigues da Silva
Co-Orientador:
Miguel Luz
Aluno:
49673, João Paulo Pedro Mendes de Sousa Saraiva
24-10-2004
1
Introdução
3
2
Metodologias a seguir
4
2.1
4
2.1.1
Fase 1.1 – Escolha de um editor UML a converter
4
2.1.2
Fase 1.2 – Conversão do editor UML escolhido
4
2.1.3
Fase 1.3 – Alteração do editor UML para suporte ao perfil UML/XIS
5
2.2
3
Fase 1 - Escolha de um editor UML
Fase 2 - Integração do editor UML com o gerador de código
Editores candidatos a serem utilizados
5
6
3.1
Business Change Modeller
7
3.2
ArgoUML
8
3.3
Thorn
8
3.4
Eclipse (em conjunto com uma extensão)
9
3.5
MonoUML
10
4
Conclusões
11
5
Referências
12
2
1 Introdução
Com este Trabalho Final de Curso (vulgo TFC), pretende-se a integração de um editor
de modelos UML (possivelmente a desenvolver) com uma ferramenta de geração
automática de código, desenvolvida no âmbito de um projecto anterior de TFC. Este TFC
insere-se num conjunto de projectos cujo desenvolvimento está em curso, no âmbito do
projecto ProjectIT, desenvolvido pelo INESC.
O editor de UML pretendido deverá ser uma aplicação WinForms com a capacidade de
edição gráfica de modelos UML (modelos estes em conformidade com o perfil UML/XIS,
definido no projecto ProjectIT), e a exportação destes modelos para o formato XMI (para
poderem ser fornecidos à supra-dita ferramenta de geração automática de código).
Para este efeito serão usadas tecnologias .NET, que asseguram um razoável grau de
portabilidade entre diferentes máquinas.
O objectivo deste relatório preliminar é fornecer os elementos necessários à escolha de
um editor UML a ser utilizado para este TFC, através dos seus prós e contras.
3
2 Metodologias a seguir
Tendo em conta os objectivos a cumprir (escolha de um editor UML e sua integração
com a ferramenta de geração automática de código), escolheu-se dividir este TFC em 2
fases, a seguir explicadas em maior detalhe.
2.1 Fase 1 - Escolha de um editor UML
Nesta fase, pretende-se obter um editor UML, desenvolvido com base em tecnologias
.NET, que permita a edição gráfica e exportação para XMI dos modelos UML desenvolvidos.
Este editor UML deverá suportar, obviamente, o desenvolvimento de modelos UML em
conformidade com o perfil UML/XIS.
Esta fase pode ainda dividir-se nas seguintes fases:
2.1.1
Fase 1.1 – Escolha de um editor UML a converter
Tendo em conta a escassez de software de código aberto em .NET e o facto de
haver uma quantidade razoável de editores UML de código aberto para Java, uma solução a
considerar é a conversão de um destes editores para .NET.
Os factores importantes a pesar na escolha de um editor nesta fase deverão ser a
facilidade de conversão, a sua dependência de outras bibliotecas de código (deve-se ter em
atenção se estas também serão de fácil conversão ou não), a facilidade de manutenção
(pois as correcções que forem sendo feitas no editor original, em Java, também terão que
ser feitas no novo editor) e, claro, a facilidade de modificação do código para incluir o
suporte ao perfil UML/XIS.
Claro que, caso seja escolhido um editor já desenvolvido em .NET, esta fase não terá
sequer lugar.
2.1.2
Fase 1.2 – Conversão do editor UML escolhido
Consistirá apenas na conversão do código (em Java) do editor UML escolhido na fase
anterior para código .NET. Sempre que possível e o tempo o permita, o código deverá ser
alterado/optimizado para tirar total partido das funcionalidades oferecidas pelas bibliotecas
da plataforma .NET.
4
Como a fase anterior, esta fase só terá lugar se fôr escolhida a conversão de um editor
em Java para .NET.
2.1.3
Fase 1.3 – Alteração do editor UML para suporte ao perfil UML/XIS
Consistirá na alteração do código do editor UML para introduzir suporte ao perfil
UML/XIS. Caso o editor UML suporte o conceito de extensões, a alteração do código fonte
do editor não será necessária, o que é sempre preferível.
2.2 Fase 2 - Integração do editor UML com o gerador de código
Nesta fase, irá proceder-se à integração do editor UML (alterado para o perfil
UML/XIS) com a ferramenta de geração automática de código. Esta fase não será agora
explicada em detalhe; sê-lo-á apenas após a conclusão da Fase 1 (explicada anteriormente)
5
3 Editores candidatos a serem utilizados
Após alguma pesquisa e algumas experiências, chegou-se aos seguintes candidatos:
1. Business Change Modeller
2. ArgoUML
3. Thorn
4. Eclipse (em conjunto com uma extensão desenvolvida para os nossos objectivos)
5. MonoUML
Todos estes candidatos apresentam prós e contras, que serão a seguir expostos.
6
3.1 Business Change Modeller
O resultado de um TFC desenvolvido pelo Eng. José Faria, o Business Change
Modeller (vulgo BCM) é um editor UML (para a plataforma CEO) desenvolvido em .NET.
O propósito original deste editor era providenciar uma maneira fácil de representar a
mudança pela qual os processos de negócio devem passar, ao longo da sua vida. Contudo,
o autor deste editor seguiu a abordagem de fazer um editor o mais geral possível e
acrescentar/restringir as funcionalidades disponíveis através de um mecanismo de
extensões (aliás, a própria representação da mudança, no editor, é conseguida exactamente
através de extensões desenvolvidas para o efeito).
Infelizmente, este editor ficou bastante incompleto, com uma funcionalidade bastante
reduzida (o autor propunha-se a um objectivo muito ambicioso, mas só teve quatro meses
para o desenvolver). Isto levou a que o mecanismo de extensões tenha ficado num estado
relativamente precário (só é suportado um nome de profile, por exemplo), embora esta falha
apresentada não seja de grande nota. Para além disto, o próprio editor apresenta algumas
falhas graves: um exemplo é a utilização do controlo PropertyGrid (utilizado para mostrar
propriedades de outros controlos, entre outros propósitos) para mostrar as propriedades dos
elementos do modelo UML apresentado (ou seja, a mistura de componentes altamente
especializados com objectos de domínio). Caso seja este o editor escolhido, uma das
primeiras coisas a fazer será criar uma WinForm com o objectivo específico de
mostrar/alterar as propriedades dos elementos de domínio.
De seguida, aqui estão os seus prós e contras:

Prós:
o
Está feito em .NET; poupa-se trabalho na conversão do código
o
O desenvolvimento de extensões é relativamente fácil, se se conseguir
superar o facto de as entidades de base não serem nada ricas em
informação

Contras:
o
Falhas na arquitectura
o
Mecanismo de extensões relativamente precário
o As entidades de base em que o editor se apoia são demasiado pobres
para algo como o UML
7
3.2 ArgoUML
Um editor UML, desenvolvido em Java, muito famoso na comunidade de código
aberto, este editor é bastante poderoso e seria um forte candidato à conversão para .NET.
Contudo, este editor apresenta uma forte desvantagem em relação aos outros editores
considerados neste documento, pois depende de um grande número de outras bibliotecas
Java, também disponíveis na Internet. Estas bibliotecas, por sua vez dependem de outras
bibliotecas, e assim por diante... Como facilmente se conclui, iria ser necessário muito tempo
para fazer a conversão destas bibliotecas, para além da conversão do próprio editor.
De seguida, aqui estão os seus prós e contras:


Prós:
o
Muito famoso na comunidade
o
Bastante poderoso
Contras:
o
Implica conversão de Java para .NET
o
Dependência de um grande número de outras bibliotecas Java;
implicaria um esforço adicional de conversão dessas bibliotecas para
.NET também
3.3 Thorn
Outro editor UML em Java, mas não tão famoso como o ArgoUML. Apresenta uma
interface simplista, embora isto seja alterável. A sua dependência de outras bibliotecas Java
é consideravelmente menor que a do ArgoUML, embora esta componente ainda exista em
peso no Thorn. Contudo, o ArgoUML é bastante mais poderoso que o Thorn.
De seguida, aqui estão os seus prós e contras:

Prós:
o

Provavelmente de mais fácil conversão do que o ArgoUML
Contras:
o
Não é tão famoso na comunidade como é o ArgoUML
o
Implica conversão de Java para .NET
8
o Dependência de algumas bibliotecas Java; implicaria um esforço
adicional de conversão dessas bibliotecas para .NET também
3.4 Eclipse (em conjunto com uma extensão)
O Eclipse é uma plataforma de desenvolvimento de software, de código aberto, muito
famosa na comunidade. Apresenta um mecanismo de extensões, e está separado em
camadas funcionais, o que serve para facilitar um bocado a conversão, pois só iríamos
converter o que fosse preciso.
Este editor, embora também não seja de fácil conversão, apresenta uma enorme
vantagem: manutenção grátis. Se esta conversão fosse disponibilizada na comunidade, é
muito provável que esta fosse arcar com grande parte dos “custos” (em termos de esforço)
de manutenção do editor. Assim, o esforço da nossa equipa de desenvolvimento poderia ser
muito mais concentrado na actualização e manutenção da extensão que fosse desenvolvida
para esta versão do Eclipse.
Isto para não falar na fama que viria para o INESC se este fosse responsável pela
conversão do Eclipse para a plataforma .NET...
De seguida, aqui estão os seus prós e contras:

Prós:
o
O Eclipse é bastante acarinhado pela comunidade
o
O mecanismo de extensões é bastante eficaz
o
Se fôr disponibilizado à comunidade, há fortes possibilidades de termos
manutenção grátis e assegurada
o
Não é preciso converter todo o software que é o Eclipse: podemos
apenas converter o que precisamos

Contras:
o
Implica conversão de Java para .NET
o Dependência de algumas bibliotecas Java; implicaria um esforço
adicional de conversão dessas bibliotecas para .NET também
9
3.5 MonoUML
Este editor é um projecto recente, que consiste num editor UML desenvolvido em cima
da plataforma .NET. Seria, portanto, uma óptima oportunidade para aquilo que pretendemos.
Contudo, é um projecto que se encontra ainda demasiado na infância para poder ser usado
por nós em “tempo útil”.
De seguida, aqui estão os seus prós e contras:

Prós:
o
Seria um editor que preencheria todos os nossos requisitos
o
Só seria necessário o desenvolvimento de uma extensão, ou alteração
do código fonte
o

Manutenção seria grátis, em grande parte
Contras:
o
Ainda é muito novo; nem sequer há uma versão executável ainda
(encontra-se em fase de planeamento/codificação inicial)
10
4 Conclusões
Após a apresentação de todos estes produtos, a recomendação inicial vai para a
conversão do Eclipse, por todas as vantagens que lhe foram apontadas.
A recomendação iria para o MonoUML, se não fosse o seu estado actual de
desenvolvimento. Contudo, caso a sua progressão seja rápida, pode ser que ainda consiga
ser utilizável neste trabalho, o que seria preferível.
11
5 Referências
[1] José Alexandre Antunes Faria. Business Change Modeller. Relatório de Trabalho Final
de Curso, Instituto Superior Técnico, 2003.
[2] ArgoUML: http://argouml.tigris.org .
[3] Thorn: http://thorn.sourceforge.net .
[4] Eclipse: http://www.eclipse.org .
[5] UML2 (Extensão para Eclipse): http://www.eclipse.org/uml2 .
[6] MonoUML: http://monouml.sourceforge.net .
12