In diesem Artikel wird ein Vergleich zwischen der Methodik der modellgetriebenen Softwareentwicklung der OMG und der SOM Methodik durchgeführt.

 

PIM und PSM

Model Driven Architecure (MDA) ist eine Spezifikation zur modellgetriebenen Softwareentwicklung ähnlich dem semantischen Objektmodell. Grundsätzlich wird dabei versucht, den Programmcode mit Hilfe von Modelltransformationen zu  erzeugen. Die dazu verwendete Sichten-Architektur (Viewpoit) setzt voraus, zwischen plattformunabhängigen Modellen (PIM) und plattformabhängigen Modellen (PSM) zu unterscheiden. Transformationsmethoden unterschiedlichen Automatisierungsgrads setzen anschließend ein PIM mittels eines oder mehrerer Transformationsschritte in ein PSM um.

Grundlagen für die Realisierung schaffen

Ausgangslage zur Softwareentwicklung bildet das s.g. Computation Independet Model (CIM), welches innerhalb der MDA  beschreibt, in welcher Domäne bzw. welchem  Umfeld das Softwaresystem genutzt werden soll. Da es sich um ein rein beschreibendes Modell handelt, wird darauf verzichtet strukturelle oder technische Sachverhalte mit anzugeben. Eine ähnliche Ebene bzw. ein äquivalentes Modell existiert in der SOM Methodik – heißt in diesem Zusammenhang dann aber Unternehmensplan und beschreibt die Außensicht eines betrieblichen Systems. Allerdings wird bei SOM in jeder Ebene zwischen struktur- und verhaltensorientierten Aspekten unterschieden, weswegen sich der U-Plan aus einem Zielsystem und einem Objektsystem zusammensetzt. Das im SOM immer zwei verschiedenen Sichten vorhanden sind, unterscheidet sich vom MDA Ansatz. Beide Methoden nutzen letztendlich aber als ersten Schritt auf dem Weg zur Softwareerstellung eine informelle Darstellung des Sachverhaltes.

CIM im semantischen Objektmodell

In der MDA Methodik leitet sich aus dem CIM das nun plattformunabhängige Modell (PIM) ab. Hierin wird, ohne jeglichen Bezug auf Technologien oder Funktionalitäten zu nehmen beschrieben, was das System operativ oder prozessual zu leisten hat. Auch in der SOM Methodik gibt es eine solche Modellanalyse. Im Gegensatz zu MDA wird nun auf die Beschreibung der Innensicht (inbs. Aufgabenebene) des Objekt- und Zielsystems Wert gelegt. Der geforderte Detaillierungsgrad bestimmt, wie viele Verfeinerungen des Geschäftsprozessmodells notwendig sind, um die Leistungsbeziehungen und Lenkungsprozesse aufzudecken. Dazu wird mit Hilfe des Interaktionsschemas (IAS) ein Interaktionsmodell für strukturelle Aspekte und mit Hilfe des Vorgangs-Ereignis-Schema (VES) alle verhaltensorientierte Aspekte modelliert.

aus CIM wird PIM

Um anschließend ein PIM in ein plattformabhängiges Modell (PSM) zu transformieren, bedient man ich in der MDA Methodik verschiedener Mapping, Marking und Transformationsmethoden. Mapping beinhaltet, wie bei einer Modelltransformation Anforderungen/Spezifikationen der gewünschten Zielplattform berücksichtigt und bei der Codeerstellung umgesetzt werden. Marking bedeutet, diejenigen Objekte des PIM zu kennzeichnen die transformiert werden sollen. Transformation vereint letztendlich Mapping und Marking um das PSM zu erstellen und kann für verschieden Modelltypen eingesetzt werden.  Innerhalb des SOM erfolgt auf dieser nun dritten Ebene ebenfalls eine detaillierte Spezifikation (hier für ein AWS). Hierbei geht es im Wesentlichen darum, die Automatisierbarkeit und den Automatisierungsgrad von Aufgaben und Transaktionen festzulegen, welche aus dem VES und IAS abgeleitet wurden. Anstelle der Aufgabe wie in der vorherigen Ebene rückt nun der Aufgabenträger in den Vordergrund. So gesehen reduzieren sich die betrachteten Objekte (Aufgabe und Transaktion) die spezifiziert werden sollen ausschließlich auf solche, die auch automatisiert sind. Es erfolgt kein explizites Kennzeichnen von Objekten wie im MDA.

SOM ist nicht programmgesteuert

Darüber hinaus verwendet SOM im Gegensatz zu MDA, nur formale bzw. semiformale Modellierungssprachen, weswegen die Transformation von einer zur nächst tieferen Modellebene nicht programmgesteuert durchgeführt werden kann. Aus diesem Grund nutzt SOM keine Mapping und Marking Methoden bei der Modelltransformation (2te zur 3ten Ebene), dafür aber ähnliche Konstrukts innerhalb einer Modellebene. Dies ist z.B. der Fall wenn in der zweiten Ebene Zerlegungsregeln für Objekte und Transaktionen bereitgestellt werden, die wiederum dabei helfen ein Geschäftsprozessmodell mehrstufig zu zerlegen.