Notes on a Modeling Environment
Jonathan Riehl
March, 2000
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:
  1. Reverse engineer Unified Modeling Language (UML) models from existing source code.

    2. 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:
    1. What source languages are supported?
    2. How robust is the parser used for each reverse engineering solution?
    3. What is the fidelity of the model generated?
    The reverse engineering aspects of the environment are highly critical for application to systems with a large and undocumented code base.
  2. Generate source code from UML models.

    3. 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:
    1. What languages are supported?
    2. Is the code correct over multiple implementations of a language?
    3. Is the code human readable, and conversely how well documented is the code?
    4. What is the fidelity of the code generated with respect to its source model?
  3. Generate documentation from UML models.

    4. 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 and/or HTML.)
  4. Generate custom products from UML models.

    5. 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.
  5. Support synchronization between source code and a UML model.

    6. 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?
  6. Visualize and graphically edit a UML model.

    7. 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.
  7. Validate a UML model for consistency and completeness.

    8. 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 diagrams.
  8. Read and write UML models using an industry standard interchange format.

    9. 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.

References:

[ArgoUML] argouml.tigris.org
[KUML] Kuml - Homepage
[Perl] www.perl.com
[Python] The Python Language Website
[Rose] Rational Rose...
[SWIG] Simplified Wrapper and Interface Generator
[Tcl] Scriptics Developer Site
[UML] UML Resource Page
[XMI] IBM Application Development: XML Metadata Interface (XMI)
[XML] Extensible Markup Language (XML)

Last modified 8/10/2000, jriehl AT wildideas.org.