Eclipse-based UML Validation of Enterprise Architect Models

Two weeks ago, there was yet another newsletter from Sparx Systems in my inbox telling me more about the latest fancy new features they added to the Enterprise Architect (EA). Project management, look of diagrams, wireframe designing for Windows Phone, even a new user interface was recently added to the ‘UML’ modeling tool. But what about stability and bugs of its core feature - authoring UML models?

If it's broken...

EA still does not take model consistency and correctness very seriously. Model validation only exists to some extent (try running the project integrity check on your model…), one famous example that is not validated are broken references. EA allows entering arbitrary text instead of enforcing existing types which often results in models that appear to be valid but which might be syntactically broken.

Several of our customers use the EA for modeling their software architecture and design with the intention of generating code from structural model information. This requires syntactically correct and consistent models. Because the EA provides only limited model validation (and also code generation) facilities, we decided to use Eclipse and its tools for model validation, code generation, model transformations, etc.

...fix it (feat. YAKINDU EA-Bridge)!

Back in 2011, we started implementing the YAKINDU EA-Bridge which provides easy access to EA models inside Eclipse by loading them as Eclipse UML models and, as a by-product, it reports syntactical model errors. If the model is valid, all Eclipse-based modeling tools can be used to process EA models, e.g. for model validation, code generation (Xtend, Acceleo, ATL, amongst others), or automated test execution in continuous integration builds.

Syntactical model validation is either performed by the YAKINDU EA-Bridge or via built-in Eclipse UML. If the EA model is broken and cannot be loaded consistently (e.g. a type reference is set but invalid), the YAKINDU EA-Bridge reports load errors as ‘EA Model Problems’. Moreover, Eclipse allows to provide quick fixes and for some errors, the YAKINDU EA-Bridge already provides such quick fixes. Redirecting or unsetting an invalid type reference is an example for such a quick fix, as shown below. This way, the user has a chance to systematically fix invalid EA models.

The EA model loaded with the Eclipse UML editor via the YAKINDU EA-Bridge: resource markers indicate errors and warnings.

Quick fixes guide the user to resolve common model errors

What else can YAKINDU EA-Bridge help you with?

Besides syntactical model validation, it is often reasonable for certain use cases like code generation to restrict the scope of modeling concepts to a specific subset of the UML, e.g. to use only Java or C data types, depending on the target language for code generation. Furthermore, projects often define modeling and coding guidelines, e.g. abstract class names should always be prefixed with ‘Abstract’. The YAKINDU EA-Bridge can also be used to easily define such custom validation rules as illustrated in the code snippet. Java annotations are used to easily define custom validation rules and associated quick fixes.

/**
 * This rule reports all abstract classes whose names do not start with 'Abstract'.
 *
 * Furthermore, this validation rule refers to two quick fixes (by ID) that are 
 * defined below which can be used in the UI to automatically fix violations of 
 * this validation rule.
 */
@EAValidation(severity = Severity.warning, quickfix = { "rename", "toggleAbstract" })
public String validateAbstractClass(Element element) {
    if (isAbstractClassWithoutPrefix(element, ABSTRACT_CLASS_PREFIX)) {
        return String.format("Abstract class '%s' should start with '%s'. Double click "
            + "this in Problems view to navigate to the model element, right-click for "
            + "possible quick fixes.",
            ((Class) element).getName(), ABSTRACT_CLASS_PREFIX);
    }
    return null; // no violation
}

/**
 * This is a quick fix for the validation rule {@link #validateAbstractClass(Element)}.
 * It should repair the model such that the validation rule is not violated any more.
 * The return value indicates whether the model was changed.
 * 
 * Parameter id is used by {@link EAValidation} to refer to possible quick fixes.
 * Parameter label is used in the UI.
 */
@Quickfix(id = "rename", label = "Add 'Abstract' prefix to class name")
public boolean fixRenameAbstractClass(Element element) {
    if (isAbstractClassWithoutPrefix(element, ABSTRACT_CLASS_PREFIX)) {
        ((Class) element).setName(ABSTRACT_CLASS_PREFIX + ((Class) element).getName());
        return true; // if the model was changed, 'true' must be returned
    }
    return false; // if the model was not changed, 'false' must be returned
}

Code for a custom validation rule that reports warnings for abstract classes without prefix ‘Abstract’; an additional quick fix can be used to add that prefix automatically.

The YAKINDU EA-Bridge is available as a Trial Download which also contains the example discussed here.