This used to be located at http://argouml-enki.tigris.org.
The argouml-enki project provides integration between ArgoUML and the
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
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
support in ArgoUML. This requires more study in order to
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
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
Support for UML2 and related OMG standards. This is definitely
important, but it depends on adding corresponding support at the Enki
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
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.