Aktuelles

Forum

Meta

Tutorial: UML2-Validierung

Das folgende Tutorial beschreibt die Erstellung eines zusätzlichen Plugins in Eclipse. Dieses wird an den TOPCASED UML2 Editor gekoppelt, so dass die erstellten UML-Modelle Regeln genügen müssen, die der Entwickler selbst definiert hat. Die Validierungsregeln werden in Java implementiert. Prinzipiell ist es möglich auch andere Validierungssprachen, wie Check oder OCL zu unterstützen.

Für dieses Tutorial werden folgende Vorkenntnisse benötigt:

Der UML2 Editor aus dem TOPCASED Projekt (http://www.topcased.org) unterstützt alle Validierungsregeln, welche in der Infra- bzw. Superstructure der UML-Spezifikation aufgeführt sind. Dennoch lassen diese Regeln viele Modellierungsfehler zu, die zu einem inkonsistenten Modell führen. Da TOPCASED ein Open Source Projekt ist und auf der Eclipse Plattform basiert, kann der Editor durch ein selbst erstelltes Validierungsplugin erweitert werden. Die Erstellung eines solchen Plugins ist das Hauptthema dieses Textes.

Site map

Die Eclipse-Plugin-Architektur basiert auf dem OSGi-Standard. Die Plugins werden über so genannte Extension Points an andere Plugins gekoppelt. Selbst definieren sie wiederum Schnittstellen, die als Extension Points für weitere Anwendungen dienen können.

Der TOPCASED UML2 Editor baut auf der Eclipse UML2 Implementierung auf und verwendet auch deren Validierungsregeln. Für erweiterte Validierungsmöglichkeiten bietet TOPCASED den Extension Point org.topcased.validation.core.validators an. Der Extension Point erwartet eine Klasse, welche die Schnittstelle org.topcased.validation.core.IValidator implementiert. Diese Schnittstelle definiert nur eine recht generische Validierungsmethode, die in nachfolgendem Listing skizziert ist.

public class PlayerValidator implements IValidator {
    public boolean validate(EObject eObject, DiagnosticChain diagnostics, final IProgressMonitor monitor)
    {
        return true;
    }
}

Die Methodensignatur schreibt drei Übergabeparameter vor. Der Erste gibt das Modellobjekt an, welches geprüft werden soll. Der Datentyp EObject rührt von Ecore, der eMOF-Implementation von Eclipse. Ecore ist das Metamodel der Eclipse UML2 Implementierung. Ein Beispiel für solch ein EObject wäre Class aus der UML. Der nachfolgende Parameter ist eine DiagnosticChain, zu deutsch Diagnosekette. Diese Datenstruktur enthält eine Übersicht, über die Fehler, die während einer Validierung auftreten. Neue Fehler oder besser Diagnosen (Diagnostics) werden angehängt. In der Implementierung der Methode wird das EObject geprüft. Bei einem Fehlschlag, wird die Fehlermeldung an die Diagnosekette gehängt. Der letzte Parameter ist der Fortschrittsmonitor, ein gängiges Konzept in Eclipse (Buch: Eclipse Plugin Development). Das Plugin dieses Beispiels erweitert die bereits vorhandene UML2-Validierung von Eclipse. Dazu wird das zu prüfende Objekt und die Diagnosekette an eine UMLValidierungsklasse weitergleitet (siehe Listing).

public boolean validate(EObject eObject, DiagnosticChain diagnostics, final IProgressMonitor monitor)
    {
       int count = 0;
        for (Iterator i = eObject.eAllContents(); i.hasNext(); i.next())
        {
            ++count;
        }
        monitor.beginTask("UML Validation", count);
        Diagnostician diagnostician = new Diagnostician()
        {
            public boolean validate(EClass eClass, EObject eObj, DiagnosticChain diag, Map context)
            {
                monitor.worked(1);
                boolean result = PlayerUMLValidator.INSTANCE.validate(eClass, eObj, diag, context);
                if (result || diag != null)
                {
                    result &= doValidateContents(eObj, diag, context);
                }
                return result;
            }
        };
        monitor.setTaskName("Validation of " + EcoreUtil.getURI(eObject));
        Diagnostic result = diagnostician.validate(eObject);
        diagnostics.merge(result);
        return true;
    }

Die UMLValidierungsklasse erweitert die bereits vorhandene Eclipse-UML-Validierung (org.eclipse.uml2.uml.util.UMLValidator) und beinhaltet zusätzliche Prüfungen, welche die eigenen Validierungsmethoden enthalten. Nachstehend ist eine der Validierungsmethoden dargestellt.

public boolean validateState_miracleState(State state,
         DiagnosticChain diagnostics, Map context)
{
      boolean result = true;
      if (state.getIncomings() == null || state.getIncomings().size() <= 0) {
         Object [] states = {state};
           Diagnostic miracleState = new BasicDiagnostic(Diagnostic.ERROR, "State "+state.getLabel(), 1,
                 "Miracle states (apart from initial states) are not allowed.", states);
           diagnostics.add(miracleState);
           result = false;
      }
      return result;
}

Diese Methode prüft, ob es sich bei dem zu prüfenden Zustand um einen so genannten Miracle-State handelt – einen Zustand, der zwar eingehende, aber keine ausgehenden Transitionen besitzt.