Übersicht Inhaltsverzeichnis Vorwort 1 Einführung 2 Klassendiagramme 3 Object Constraint Language 3.1 Übersicht über OCL/P 3.2 Die OCL-Logik 3.3 Container-Datenstrukturen 3.4 Funktionen in OCL 3.5 Ausdrucksmächtigkeit der OCL 3.6 Zusammenfassung 4 Objektdiagramme 5 Statecharts 6 Sequenzdiagramme A Sprachdarstellung durch Syntaxklassendiagramme B Java C Die Syntax der UML/P D Anwendungsbeispiel: Internet-basiertes Auktionssystem Literatur |
3 Object Constraint LanguageDie Object Constraint Language (OCL) ist eine eigenschaftsorientierte Modellierungssprache, die eingesetzt wird, um Invarianten sowie Vor- und Nachbedingungen von Methoden zu modellieren. Die in diesem Buch vorgestellte Version OCL/P ist eine an Java angepasste und erweiterte Variante des OCL-Standards. Nach einer Übersicht über die OCL werden die in der OCL eingesetzte Logik, die Konzepte zur Modellierung von Container-Datenstrukturen und von Funktionen in der OCL behandelt. Betrachtungen zur Ausdrucksmächtigkeit der OCL schließen das Kapitel ab. 3.1 Übersicht über OCL/P 3.1.1 Der Kontext einer Bedingung 3.1.2 Das let-Konstrukt 3.1.3 Fallunterscheidungen 3.1.4 Grunddatentypen 3.2 Die OCL-Logik 3.2.1 Die boolesche Konjunktion 3.2.2 Zweiwertige Semantik und Lifting 3.2.3 Kontrollstrukturen und Vergleiche 3.3 Container-Datenstrukturen 3.3.1 Darstellung von Mengen und Listen 3.3.2 Mengen- und Listenkomprehension 3.3.3 Mengenoperationen 3.3.4 Listenoperationen 3.3.5 Container-Operationen 3.3.6 Flachdrücken von Containern 3.3.7 Typisierung von Containern 3.3.8 Mengen- und listenwertige Navigation 3.3.9 Qualifizierte Assoziation 3.3.10 Quantoren 3.3.11 Spezialoperatoren 3.4 Funktionen in OCL 3.4.1 Queries 3.4.2 OCL≫-Methoden 3.4.3 Methodenspezifikation 3.4.4 Bibliothek von Queries 3.5 Ausdrucksmächtigkeit der OCL 3.5.1 Transitive Hülle 3.5.2 Die Natur einer Invariante 3.6 Zusammenfassung Graphische Notationen sind besonders gut geeignet, um dem Leser einen schnellen Einstieg in eine Übersicht des modellierten Systems zu geben. Um die Übersichtlichkeit zu gewährleisten, ist es jedoch notwendig, von Details zu abstrahieren. Deshalb können beispielsweise Klassendiagramme viele strukturelle und verhaltenstechnische Zusammenhänge nicht darstellen. Generell sind graphische Notationen aufgrund ihrer zweidimensionalen Natur nur bedingt geeignet, allgemeine Bedingungen an ein System darzustellen. Rein visuelle Programmiersprachen wie etwa VISTA [Sch98a], die dies versuchen, zeigen deshalb zwar eine interessante Richtung auf, konnten aber keine Verbreitung finden. Daher ist zu erwarten, dass die Programmiersprachen in der näheren Zukunft weiterhin textbasiert sind oder eine enge Verzahnung aus graphischen und textuellen Elementen beinhalten. Speziell für Bedingungen ist eine textuelle Notation sinnvoll, die konzeptuell an der bekannten Mathematik angelehnt ist. Für bestimmte, häufig auftretende Arten von Eigenschaften lassen sich natürlich graphische Abkürzungen finden. Die UML bietet zum Beispiel Kardinalitäten für Assoziationen als Kurzformen für Bedingungen an. Auch das Typsystem einer Sprache wie Java kann als einschränkende Bedingung über Eigenschaften eines Systems verstanden werden. In [GHK99] werden visuelle Konzepte für weitere Arten von Bedingungen eingeführt. Die textuelle Modellierung von Bedingungen an das System erlaubt die Modellierung von Systemeigenschaften, die mit einer graphischen Notation nicht oder oft nur umständlich beschrieben werden können. Die Kompaktheit einer textuellen Notation gegenüber einer graphischen Beschreibungstechnik führt dazu, dass diese im Allgemeinen als schlechter verständlich empfunden wird. Eine gute Modellierung besteht deshalb aus verständlichen sowie kompakten und damit knapp formulierten Bedingungen. Außerdem ist es wichtig, die formulierten Bedingungen konstruktiv im Softwareentwicklungsprozess einzusetzen. Deshalb sind Werkzeuge wie ein Parser und ein Prüfer der Typkorrektheit hilfreich. Darüber hinaus ist die Ausführbarkeit und damit die automatisierte Überprüfbarkeit einer Bedingung eine wesentliche Voraussetzung für den Einsatz einer Bedingungssprache zur Definition von Tests. Im UML-Standard steht mit der Object Constraint Language (OCL) eine textuelle Notation zur Verfügung, die für die Definition von Bedingungen (engl.: Constraints) in Form von Invarianten sowie für Vor- und Nachbedingungen von Methoden eingesetzt werden kann. Neben der präzisen Definition ihrer Syntax und einer informellen Bedeutungserklärung in [OMG10b] steht mit [WK98] eine Einführung in die OCL zur Verfügung. Die Historie zur Definition von Programmier- und Spezifikationssprachen zeigt, dass es sehr schwierig ist, bereits im ersten Ansatz eine allgemein zufriedenstellende und hinreichend sauber definierte Sprache zu entwerfen. Die OCL ist in der Form, wie sie im UML-Standard angeboten wird, an keine bekannte Programmiersprache angelehnt. Gerade deswegen besitzt sie ein eher ungewöhnliches syntaktisches Aussehen, das vielen Entwicklern den Zugang zur OCL erschwert. Deshalb wurde in [Rum02b] eine syntaktische Form der OCL vorgeschlagen, die an Java angelehnt ist. Dieses Kapitel enthält eine Erweiterung dieses Vorschlags, die im Folgenden mit OCL/P oder kurz OCL bezeichnet wird. Neben der Anpassung der syntaktischen Form der OCL wurden eine Reihe konzeptueller Verbesserungen, die teilweise bereits in [CKM+02] beschrieben sind und teilweise von funktionalen Programmiersprachen übernommen wurden, in die hier präsentierte Form OCL/P eingearbeitet. Nach einer Einführung in die OCL/P im nächsten Abschnitt werden die technischen Details der OCL in mehreren Abschnitten informell diskutiert. Dabei wird die für die OCL sinnvolle Logik vorgestellt, Container eingeführt und gezeigt, wie Operationen in der OCL modelliert werden. Abschließend wird die Ausdrucksmächtigkeit der OCL untersucht und dabei der Vergleich zu der vollständigen algebraischen Spezifikationssprache Spectrum [BFG+93] gezogen. In Anhang C.3 werden die kontextfreie Syntax der OCL vorgestellt. Die wesentlichen Unterschiede zwischen dem OCL-Standard und der hier vorgestellten OCL/P sowie deren Motivation sind in Anhang C.3.2 zusammengefasst.
|
|||||||||