Login | Register
My pages Projects Community openCollabNet

Project home

2020-03-13: This site is going to be decommissioned and shut down very soon. Please copy and archive any data you wish to keep ASAP

If you were registered and logged in, you could join this project.

Summary Provide an Enki/Hibernate repository for ArgoUML
Category design
License Eclipse Public License - v 1.0
Owner(s) jsichi, linus

The argouml-enki project provides integration between ArgoUML and the Enki repository implementation for DBMS persistence of UML models via Hibernate.

The project is currently in a very early state and is not yet ready for end users. It may be of interest to developers with backgrounds in DBMS and object/relational mapping technology, particularly those interested in eventually developing ArgoUML capabilities related to

  • support for accessing very large models
  • multi-user online sharing of model instances
  • transactional edits
  • implementation of updated OMG standards for MOF, JMI, UML, and XMI


The primary goal of the project is to add a mode to ArgoUML in which UML 1.4 model instances are manipulated directly in a DBMS repository; this mode will be an alternative to the current default ArgoUML mode in which model instances are fully loaded into memory via XMI import.

  • Must-have scope for concurrency is support for single-writer with multiple readers (assuming an underlying DBMS with multi-version concurrency control capability).
  • Must-have scope for scalability is that only the portions of a model instance which are actually accessed by ArgoUML should be brought into memory by Hibernate (using its standard session-level and second-level cache providers).

Stretch goals goals include:

  • Using DBMS or Hibernate add-on capabilities equivalent to persistent savepoints or point-in-time recovery in order to implement Undo support in ArgoUML. This requires more study in order to determine feasibility.

The following items are initially out of scope, but could be good candidates for follow-on or parallel efforts:

  • Supporting multiple concurrent readers and writers online against the same DBMS repository. This could make sense for some development environments, but requires a lot of high level concurrency control, distributed notification, and merge support. Some of the Configuration Item concepts from traditional disconnected team development approaches may be applicable here too.
  • Using ArgoUML to create models for use as input to Enki/Hibernate. In fact, this already works (Eigenbase developers use ArgoUML as their modeling tool for generating DBMS metadata catalog persistence via Enki), but it's not related to this argouml-enki project, despite the name.
  • Support for UML2 and related OMG standards. This is definitely important, but it depends on adding corresponding support at the Enki level first.
  • Taking advantage of Enki's in-memory repository implementation as an alternative to the one from MDR. The MDR codebase and documentation are no longer actively maintained by anyone, and the Enki codebase may be easier to work with, so this could be a good long-term migration path for ArgoUML's default model implementation.

Project assumptions include:

  • As much of the existing argouml-mdr implementation as possible should be reused via sharing/extension in order to minimize code duplication. This may require small modifications to argouml-mdr in order to facilitate extension; these should be undertaken in such a way that they do not destabilize the default non-Enki implementation in any way.
  • It will be necessary to co-evolve Enki in order to add any support necessary to make the argouml-enki integration successful. Once this is far enough along, specific releases of argouml-enki will be tied to specific releases of Enki, with all dependencies identified and carefully controlled (including second-order dependencies such as Hibernate).
  • Once past the proof-of-concept phase, it will be necessary to modify some core portions of ArgoUML, e.g. to add the concept of a repository-backed project file. Any such modifications should be undertaken via collaboration and review with the full ArgoUML user and developer community in order to avoid negative usability impact for existing in-memory use cases, as well as to obtain positive usability feedback for the new DBMS repository features.

Related resources