Navigation


WHAT is FUJABA?
From http://www.uni-paderborn.de/cs/fujaba/: Fujaba is an Open Source UML CASE tool project started at the software engineering group of Paderborn University in 1997. In 2002 Fujaba has been redesigned and became the Fujaba Tool Suite with a plug-in architecture allowing developers to add functionality easily while retaining full control over their contributions.

I found Fujaba’s main strength it’s Java code generation from a visual programming language based on UML statecharts and object diagrams. This language is called Story Driven Modeling (SDM) and has been used extensively in the embedded systems area.

WHY FUJABA?
Thanks to the Segravis research network, I had the opportunity to follow a one-week crash course from the core Fujaba developers in Paderborn. At the end of the week, Niels Van Eetvelde and I had already implemented our prototype.
WHY REFACTORING?
As a member of LORE, I was working on automating refactoring OO sources using OCL bad code smell specifications and refactoring pre- and postconditions (see paper).

My long-term goal however is to develop primitive refactorings for MDA code generators. Such code generators take a stereotyped UML diagram as input and generate deployable software. The code generation is configurable by the software developer by exposing the "cartridges" defining the code generation. Today’s MDA code generators (such as AndroMDA, OptimalJ or ArcStyler) suffer from complex cartridges with duplicate logic across cartridges for similar target technologies (e.g. among WebLogic and JBoss EJB cartridges). A solution is to use a chain of model transformations to break the code generation process into several steps. In this situation, cartridges can share parts of refinements. The WebLogic and JBoss EJB cartridges would share the refinement from <<ejb>> to <<bean>>, <<localhome>>, <<remotehome>>, <<homeintf>>, <<remoteintf>>, <<valueobject>>, and <<standarddeploymentdescriptor>> ... but would not share the refinement to <<wl_dd_extensions>> and <<jboss_dd_extensions>>. First, I am investigating how such model transformations can be implemented in a model driven way (i.e. generate the transformation code from visualizable transformation models as well). This will enable a domain specific syntax for model transformations (enhancing readability), hide low-level (duplicate) code and create the opportunity to add code generators for different repositories (e.g. MDR and EMF)! The next steps will be investigating how to

  • manipulate the model refinements to migrate the generated applications to new platforms
  • reengineer existing code templates with duplicate logic and high complexity to stepwisely refined cartridges
Anyway, you can see that mastering "model transformations" is essential for my research. As I’ve discussed in a recent e-mail thread, refactorings are model transformations as well. That’s why we were interested in using Fujaba as a model transformation tool and start with the implementation of a familiar refactoring: "pull up method".
SOFTWARE PROTOTYPE
Fujaba Users Tutorial
  • Step 1: Reverse engineer your Java sources to UML class diagrams. (Fujaba screenshot)
  • Step 2: Arrange your class diagram, possibly using the auto-layout plugin from the University of Tampere, Finland.
  • Step 3: Look for design problems, e.g. duplicate functionality in sibling classes.
  • Step 4: Execute the refactoring by rightclicking on the problematic diagram element and following the "refactor" menu item. (Fujaba screenshot)
Fujaba Developers Tutorial
  • Step 1: Create a project containing the metamodel on which you want to define your model transformations. In our Fujaba experiment, we used Fujaba’s internal UML metamodel (Fujaba screenshot)
  • Step 2: Design your transformation classes in a UML class diagram In our Fujaba experiment, we implemented the pull up method refactoring (again, just a case study of model transformation). The structural design for our refactorings consists of a superclass "Refactoring" with a method "checkPrecondition" and another "execute"" (Fujaba screenshot). Subclass "PullUpMethod" implements these methods. We'll zoom on the implementation of this example.
  • Step 3: Write the actual transformation specification. "checkPrecondition" is a model query, "execute" is a model transformation. If you look at the SDM for "execute", you see a concrete example of a model driven transformation (Fujaba screenshot)
PUBLICATION
We published a paper of this case study on the Fujaba Days 2003 conference. You can download Implementing Refactorings as Graph Rewrite Rules on a Platform Independent Metamodel from the papers section of this website. My mindmap for preparing the presentation of the paper is also online.
CURRENT STATUS (last updated on may 7, 2004)

The next step will be to iteratively make SDM more specific to the domain of model transformations. Next to adding syntactic shortcuts for metamodel navigation, we will define constructs to specify transformations between two different metamodels (note that refactorings are model transformations within the same metamodel!). This is needed for specifying MDA refinements (PIM to (intermediates to)* PSM).

CLOSING REMARK
I'd like to add a note on our migration from Fujaba to AndroMDA: if Fujaba would be reengineered to use the MDR as it’s repository (this has been done to Poseidon in the past and is being done to Argo at the moment), all our extensions to SDM could be used inside of Fujaba again. This would be a very interesting project, but it goes beyond the scope of my research.
SITE ADMIN
Validator
Valid HTML 4.01!
Hit Counter

Top of this page...