Semantic Steps

steps-up-300x300-2175475In a previous post we explored three layers of a UML tool: application (top), semantic (middle) and technology (bottom).  These three layers influence one another but also enjoy a measure of modular independence from one another.  Changes can be made in one layer without disrupting other layers.

The middle semantic layer houses the metamodel.  Let us explore making modifications to the semantic metamodel without disturbing the modeling application (drawing, organizing, versioning, building, etc.) or changing technology (Eclipse, java, file formats, etc.).

The xtUML (then Shlaer-Mellor) metamodel predates UML.  In recent years, as new functionality has been added to BridgePoint, conformance to UML has informed the metamodeling choices.  But is it possible to modify the xtUML metamodel in place without breaking the tool functionality?  Can UML (fUML and UML2) compliance be augmented in an Incremental, Always Advancing, Never Broken manner?

xtUML MM Function and Parameter

Let us explore an example.  A suboptimal subsection of the xtUML metamodel involves the model of action body parameters.  This metamodel fragment is unnecessarily duplicated for each flavor of action body.  As xtUML  expanded and grew in functionality, such as support for class operations and component messaging, the passed argument model from functions was simply copied into each new subsystem with some renaming of classes and renumbering of associations.  The pattern of handling passed parameters is repeated in the metamodel.  It would be nice to refactor and consolidate these fragments of the metamodel.

xtUML MM Operation and Parameter (notice similarity/duplication)

Let us think more about making this improvement while simultaneously increasing the compliance and commonality with UML.

To accomplish this, the semantic middle layer can be modified to add a segment of the UML metamodel that supports parameter passing.  The modification involves the following steps…

outline of steps:
1.  adding UML segment to overall metamodel
2.  adding population of UML segment to the model editing and loading operations
3a.  replacing execution of xtUML segment for UML portion in Verifier
3b.  replacing translation of xtUML portions with UML bits for model compilers
4.  obsoleting the xtUML segment

As a model is being edited or loaded, populator operations are called.  These routines validate the input model data and create instances of the metamodel elements.  The populator functions link the metamodel instances across the class model associations.

The key is to add functionality and test it while existing support remains in place.  Only when the newly added functionality is as good or better than the existing functionality will removal of the existing segment be considered.

It is reasonable to author or modify concurrent versions of these populators that create and relate the newly added segment of metamodel (e.g. UML support of passed parameters).  At this point both xtUML and UML representations of the functionality exist concurrently.  After tool functionality uses the new metamodel segment and stops using the old metamodel segment, the old can be pruned away.  This approach allows the existing tool to continue operating smoothly while adding, improving and validating updated capability.  The Semantic Layer can indeed be incrementally advanced in-place without breaking.


Related Articles
Dear Modelers, Significant progress has been made on a specifications of textual xtUML and separately…
At xtUML Days 2020 UK, Marc Balcer explained model-driven test case generation with TAME.
BridgePoint is Open Source Software (OSS). It is free. However, OSS is not free like…