Notes on a Modeling Environment
The following are a set of notes that describe a possible modeling environment.
These notes may be taken as a set of informal requirements. Ideally,
the environment will consist of an integration of in house and external
software to accomplish the following tasks:
Reverse engineer Unified Modeling Language (UML) models from existing
This is standard fare for most UML [UML] modeling packages. Such
examples include the commercial package Rational Rose [Rose], and the open
source projects KUML [KUML] and ArgoUML [ArgoUML]. What drives evaluation
of this feature are the following questions:
The reverse engineering aspects of the environment are highly critical
for application to systems with a large and undocumented code base.
What source languages are supported?
How robust is the parser used for each reverse engineering solution?
What is the fidelity of the model generated?
Generate source code from UML models.
Generation of source code is also known as forward engineering.
The level of granularity in the UML does not allow the generation of fully
functional code. However, interfaces for supported languages may
be generated. Forward engineering gives programmers a framework to
build working applications. Usefulness of a tool relies on the following:
What languages are supported?
Is the code correct over multiple implementations of a language?
Is the code human readable, and conversely how well documented is the code?
What is the fidelity of the code generated with respect to its source model?
Generate documentation from UML models.
The environment needs an easy way to share model information for the
inclusion in design documentation, if not provide a publication facility.
The documentation facility should be able to handle both graphic and text
documentation, with such features as the ability to cut and paste graphics
and generation of text in commonly used formats (such as Microsoft Word
Generate custom products from UML models.
The environment should not only be able to generate code and documents
but other products. These products may include test harness generation,
and generation of interfaces between languages. One specific example
would be generation of interface description files for David Beazley's
SWIG [SWIG], which would allow interfaces between C++ and scripting languages
such as Perl [Perl], Python [Python], and Tcl [Tcl]. This kind of
functionality requires any tools in the environment either provide support
for extensions or exporting data for use in custom tools.
Support synchronization between source code and a UML model.
This is a feature hinted at above, but essentially, if the environment
supports reverse engineering and code generation, it should be capable
of allowing updates to the UML model to be reflected in a code base, and
changes in the code base to be reflected in the UML model. The process,
often called round trip engineering, is not as straightforward as it sounds.
There may be various conflicts between a model and a source base.
For example, what happens if a class is removed from the model, should
the corresponding source code be deleted?
Visualize and graphically edit a UML model.
The environment should have the ability to support the display of UML
diagrams. Furthermore, modifications and/or additions made to a diagram
should impact the UML model. Features such as automatic diagram population,
node placement, and edge routing should be supported.
Validate a UML model for consistency and completeness.
The environment should be able to perform semantic checks on the model
to ensure its consistency and completeness. An example of such validation
would be the determination and presentation of unlabelled associations.
Furthermore, the environment should be able to summarize requirement tracability
into the design via the association of use cases with sequence and collaboration
Read and write UML models using an industry standard interchange format.
The environment may consist of several tools with overlapping functionality.
For example, Rational Rose may be employed for its (more) automated visualization
environment, while the C++ parser from KUML may be used for its robustness
with UNIX based software. When operating under such an environment
the primary issue becomes integration. How will the tools share data?
The Object Modeling Group, an industry standards organization, has standardized
a means of interchanging UML models in XML [XML]. The resulting format
is called the XML Metadata Interface [XMI], and is supported/will be supported
by many of the modeling tools mentioned above. [Rose][KUML][ArgoUML]
As a side note, with an internal focus on integration and customization
in the environment, the open source products potentially offer more benefits.
Once an environment has been established, it should look for further opportunities
to integrate these freely available alternatives.
[KUML] Kuml -
[Python] The Python Language Website
[SWIG] Simplified Wrapper and Interface
[Tcl] Scriptics Developer Site
[UML] UML Resource Page
Application Development: XML Metadata Interface (XMI)
[XML] Extensible Markup Language (XML)
Last modified 8/10/2000, jriehl AT wildideas.org.