6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information systems modeling: from object-oriented conceptual modeling to automated programming 1
Problem Space Conceptual Model Solution Space Execution Model Object Model Dynamic Model Functional Model OASIS Specification 2/10 OO-Methode In der klassischen Softwareentwicklung wird der Entwurf eines Modells im Problemraum mit unterschiedlichsten Methoden und Hilfsmitteln bzw. Diagrammen erstellt. Dieser Entwurf wird dann im Lösungsraum implementiert. Leider gibt es keine Verbindung zw. den Modellen im Problem- und Lösungsraum. So passiert es immer wieder das die Modelle verschieden sind. Die Folge ist das sich Entwurf und Implementierung unterscheiden, was z.b. die Erweiterung des Modells bzw. der Lösung erschwert. Eine andere Herangehensweise ist OO-Methode. Hierbei werden die Modelle im Problem- und Lösungsraum über eine formale Spezifikation miteinander verbunden. OASIS ist so eine formale Spezifikation. Im Problemraum wird ein konzeptionelles Modell, bestehend aus einem Objektmodell, einem dynamischen Modell und einem funktionalen Modell erstellt. Dieses Modell wird in einem OASIS Schema abgebildet aus dem 1 zu 1 ein Ausführungsmodell erstellt wird. Damit sind sind die Modelle im Problemund Lösungsraum identisch. Dies hat den Vorteil das große Teile (bis zu 95%) des Programmcodes automatisch generiert werden können und nur noch ein geringer Teil per Hand geschrieben werden muss. Voraussetzung ist dabei ein exakt definiertes konzeptionelles Modell. Der Vortrag beschreibt die Modelle sowie die Vorgehensweise der Transformation vom konzeptionellen Entwurf zum Ausführungsmodell. 2
- Objekt Modell (1/3) Darstellung von Klassen mit folgenden Merkmalen Attribute Services Constaints Beziehungen (Vererbung, Aggregation) Basierend auf UML Klassendiagramm 3/10 Im Objekt Modell werden die Komponenten des zu modellierenden Informationssystems definiert. Sie bilden die Basis für das spätere Ausführungsmodell, da sie den Zustand des Systems darstellen. Über Services kann der Nutzer auf die Objekte zugreifen. Im Objekt Modell werden Klassen definiert von denen Objekte instanzieiert werden. Die Klassen haben folgende Merkmale. Attibute: Services: zu Constraints: Eigenschaften (statisch, variabel, abgeleitet) der Klasse Methoden der Klasse, Argumente des Service Dienen dem Ändern des Objektzustandes Man unterscheidet in private und shared Services. Private Services können nur innerhalb einer Klasse genutzt werden. Shared Services sind in mehren Klassen definiert und dienen synchronen Kommunikation der entsprechenden Klassen untereinander. Bedingungen für Attribute die eingehalten werden müssen, um ein Objekt der Klasse erzeugen zu können. Beziehungen: zw. Klassen bzw. Objekten Aggregation (Assoziation und Komposition) Vererbung (Generalisierung und Spezialisierung) Zur Darstellung des Klassen werden UML Klassendiagramme verwendet. 3
- Dynamisches Modell (2/3) Dient zur Darstellung von Prozesses Beschreibung von Objekt-Lebenszyklen Zustands Übergangs Diagramme Transitionen entsprechen gültigen Zustandswechsel eines Objektes Transitionen werden durch Services ausgelöst Beschreibung von Beziehungen zw. Objekten Interaktionsdiagramme Arten von Interaktionen Trigger Transaktionen 4/10 Das Dynamische Modell dient zur Darstellung von Prozessen. Dabei werden einerseits Objekt- Lebenszyklen, andererseits Interaktionen zw. Objekten beschrieben. Für den Objektlebenszyklus werden Zustandsübergangsdiagramme verwendet. Hiermit werden gültige Zustandsübergänge definiert, die durch Services ausgelöst werden. Ein Service wird nur bedient wenn die Attribute des Objektes definierten Bedingungen entsprechen. Daher werden beim Aufruf eines Services die entsprechenden Bedingungen geprüft. Hierbei wird unterschieden in Preconditions Attribute müssen dieser Bedingung entsprechen, damit ein Service ausgelöst wird. Control Conditions dienen der Unterscheidung von alternativen Services Interaktionen zw. Objekten werden über Interaktionsdiagramme dargestellt. Man unterscheidet hierbei zwei Arten von Interaktionen. Trigger sind Objekt Services die aufgerufen werden, wenn eine bestimmte Bedingung eines Objektattributes erfüllt ist. Transaktionen beinhalten Services mehrerer Objekte Es gibt für jede Klasse ein Zustandsübergangsdiagramm, für das ganze System aber nur ein Interaktionsdiagramm. 4
- Funktionales Modell (3/3) Kategorisierung von Attribute von Objekten Kategorien von Attributen Push-Pop State-Independent Discrete-Domain Definition wie Services Attribute verändern Überprüfung der Operation und Ergebnisse 5/10 Im funktionalem Modell werden Methoden definiert wie Services den Zustand bzw. die Attribute von Objekten verändern. Dazu werden die Attribute kategorisiert. Kategorien von Attributen Push-Pop Wert wird erhöht bzw. vermindert State-Independent Wert ist abhängig vom zuletzt aufgetretenen Service Discrete-Domain Wert hat bestimmten Typ (Integer, Char,...) Durch das funktionale Modell wird auch die Überprüfung der Operation und Ergebnisse festgelegt. D.h. es wird über Methoden geprüft ob der eingetretene Zustand gültig ist. 5
(1/2) OASIS ist die formale Spezifikation des konzeptuellen Modells und des Ausfügrungsmodells Aus dem konzeptuellen Modell läßt sich die OASIS Schemadefinition ableiten Für jede Klasse wird so ein konzeptuelles Schema in OASIS abgebildet 6/10 OASIS ist die formale Spezifikation des konzeptuellen Modells und des Ausführungsmodells. Aus dem konzeptuellen Modell läßt sich die OASIS Schemadefinition ableiten. D.h. für jede Definition im konzeptuellen Modell gibt es auch eine Definition im OASIS Schema. Für jede Klasse wird so ein konzeptuelles Schema in OASIS abgebildet. Dabei werden in den Klassen die Attribute und Services eines Objektes aus dem Objektmodell, aber auch die Prozessdefinitionen des dynamischen Modells und die Methoden des funktionalen Modells definiert. Aus dem OASIS Schema läßt sich das Ausführungsmodell erzeugen. Dazu wird ein Ausführungsschema benutzt, wie es auf Folie 8 beschrieben ist. 6
(2/2) Prozessdefinition von in Beziehung stehenden Objekten Objekte bieten Services und Attribute Services verändern Attribute und damit Objektzustand in einem definierten Verfahren Zustandsänderungen müssen gültig sein 7/10 Services werden direkt oder über Trigger / Transaktionen aufgerufen Die OASIS Spezifikation ist eine Prozessdefinition von in Beziehung stehenden Objekten. Diese Beziehungen werden im dynamischen Modell über Zustandsübergangsdiagramme und Interaktionsdiagramme definiert. Damit aus einem OASIS Schema ein Ausführungsmodell erstellt werden kann, müssen folgende Kriterien erfüllt sein. Objekte bieten Services und Attribute, welche im Objektmodell über Klassendiagramme definiert werden. Services verändern Attribute und damit Objektzustand in einem definierten Verfahren aus dem funktionalen Modell. Dabei ist definiert welcher Service welche Attribute in welcher Art und Weise modifiziert. Die Zustandsänderungen der Objekte müssen gültig sein, d.h. dem Zustandsübergangsdirgramm entsprechen. Services können direkt vom Nutzer des Informationssystem aufgerufen werden. Durch Änderungen der Objektzustände bzw. Attribute werden Bedingungen erfüllt die Trigger oder Transaktionen auslösen und somit weiter Services aufrufen 7
(1/2) Aufruf Service Gültige Transition Bedingung für Serviceausführung erfüllt ja nein Exception Änderung Objektzustand / Attribute Gültiger Objektzustand nein Exception ja ja Trigger 8/10 Ende Serviceaufruf Aus dem OASIS Schema wird ein Ausführungsmodell erzeugt. Dabei wird folgendes Ausführungsschema benutzt. Der Nutzer authentifiziert sich am Informationssystem. Er erhählt eine Überblick über die vorhandenen Objekte und die angebotenen Services. Durch Nutzer des Informationssystems oder durch Trigger werden Services eines Objektes mit den notwendigen Argumente aufgerufen. Im ersten Schritt wird geprüft ob für den aktuellen Objektzustand eine gültige Transition existiert und ob Bedingung zur Ausführung des Services erfüllt sind. Ist mindestens eine der Voraussetzungen nicht erfüllt wird eine Exception ausgelöst und der Service nicht ausgeführt. Sind die Bedingungen erfüllt werden die Attribute des Objekts geändert. Es wird in einen neuen Zustand überführt. Der neue Objektzustand wird auf seine Gültigkeit geprüft. Ist der Zustand nicht gültig wird eine Exception ausgelöst und der alte Objektzustand wieder hergestellt. In einem gültigen Objektzustand werden Attributbedingungen überprüft ob sie Trigger auslösen. Ist dies der Fall wird über den Trigger der entsprechende Service aufgerufen. 8
(2/2) User Interface Access Control System View Service Activation Logic Repository Mediator Domain Class Database Mediator Domain Logic Services... Domain Class Persistence Repository Database 9/10 Das Excution Modell wird in eine Dreischichten Architektur eingeteilt. Das User Interface stellt für die Nutzer des Informationssystems den Zugang zu den Objekten und Services dar. Über die Access Control Komponente kann sich der Nutzer am System anmelden. Die System View listet Objekte und Services. Durch die Service Activation Komponente werden Services von Objekten aufgerufen. Die Application Logic ist unterteilt in Problem Domain Objects und Services Objects. Problem Domian Object stellen die OASIS Spezifikation dar. Sie enthalten Klassen und die damit Verbundene Prozessdefinition des OASIS Modells. Über Problem Domain Objects findet die Transformation der OASIS Spezifikation in eine Programmiersprachen Implementierung statt. Service Objects stellen Verbindungen zu Repositories her in denen Objekte und OASIS Spezifikationen sowie Systeminformationen gespeichert werden. Die Mediatoren nehmen die Transformation der Objekte und Systeminformationen in die entsprechenden Datenformate der jeweiligen Repositories vor Unter Persistence versteht man die Repositories zur Speicherung von Objekten und Systeminformationen. In der Datenbank werden Objekte der Applikation Logic im jeweiligen Zustand gespeichert. Im Repository lagern OASIS Spezifikationen und Systeminformationen, die hauptsächlich das UserInterface betreffen. 9
OASIS ist ein Objektorientiertes Modellierendes Entwicklungssystem mit dem nur noch wenig Code per Hand geschrieben werden muß. Wichtig ist eine exakte Modellierung der Prozesse. Der Anwendungsbereich ist zur Zeit noch auf Informationssysteme beschränkt. 10/10 OASIS ist ein Objektorientiertes Modellierendes Entwicklungssystem mit dem nur noch wenig Code per Hand geschrieben werden muß. Wichtig ist eine exakte Modellierung der Prozesse, da nur so die gewünschten Ergebnisse im Ausführungsmodell eintreten. Der Anwendungsbereich ist zur Zeit noch auf Informationssysteme oder Geschäftsanwendungen beschränkt. Die Nutzung von OASIS oder einer anderen OO-Methode zur Entwicklung hardwarenaher Programme wie Treiber oder 3D Anwendungen ist nicht möglich, weil hier der Bedarf mehr auf Performance als auf exakte eine Modellierung fokusiert ist. 10