Software Engineering: Strukturelle Modellierung

Transkript

1 Copyright, Page 1 of 13 Software Engineering: Strukturelle Modellierung 1.0 Motivation und Voraussetzungen Zum Verständnis sind Kenntnisse aus dem Bereich der objektorientierten Programmierung unerlässlich. In diesem Dokument stellen wir grundlegende Elemente der strukturellen Modellierung vor. Wir erklären den grundlegenden Begriff Objekt und erläutern, was man unter Zustand, Verhalten und Identität eines Objekts sowie unter einer Verbindung zwischen Objekten versteht. Von den Objekten gehen wir zum abstrakteren Konzept der Klasse über und behandeln dann das Klassenmodell. Das Klassenmodell bildet den unverzichtbaren Kern jeder objektorientierten Softwareentwicklung, da es mit seiner Durchgängigkeit durch alle Entwicklungsaktivitäten einen festen Bezugsrahmen für die gesamte Softwareentwicklung schafft. Diese Zusammenfassung basiert auf dem Skript von Herrn Prof. Dr. H.W. Six, Lehrgebiet Software Engineering, der FernUniversität in Hagen. 2.0 Vom Konkreten zum Abstrakten Bei imperativen Programmiersprachen versteht man ein Programm als lineare Folge von Befehlen, die der Rechner in einer definierten Reihenfolge abarbeitet. Noch in den 80er Jahren des 20. Jahrhunderts war es üblich Go To Statements zu verwenden heutzutage würde man dies zu recht als Spaghetti-Code abtun. Erste Ansätze der besseren Strukturierung des Quellcodes finden sich 1968 als Dijkstra forderte absolute Sprunganweisungen einzuschränken und anstatt dessen DO... WHILE-Anweisungen o.ä. zu verwenden. Programme in kleinere Teilaufgaben zu zerlegen, Funktionalität zu kapseln und damit wiederverwendbar zu machen, ist die Intention der prozeduralen Programmierung. Ferner werden durch Prozeduren auch Schnittstellen bereitgestellt, welche die Aufgabe haben den notwendigen Input und den hinreichenden Output einer Prozedur zu regeln. Das Programmier-Paradigma der modularen Programmierung führte den Strukturierungswillen weiter und baute diesen aus. Im Gegensatz zu prozeduralen Programmen können modulares Programm in einzelne (voneinander unabhängige) Komponenten (Moduln) zerlegt werden. Dies ist nur deshalb möglich, da neben dem funktionalen Aspekt auch die notwendigen Datenstrukturen entsprechend modelliert und programmiert werden. Jede Komponente, jedes Modul, hat eine klar abgegrenzte, präzise definierte (Teil- )Aufgabe innerhalb des Programms zu erfüllen. Daten und Operationen, welche zur Lösung eines Teilproblems notwendig sind, werden zu einer logischen Einheit, dem Modul, vereinigt. Die modulare Programmierung kann als Vorstufe der objektorientierten Programmierung angesehen werden. So ist es auch nicht verwunderlich, dass die Grundsätze der Verkapselung und des Geheimnisprinzips bereits in modularen Sprachen umgesetzt wurden und diese unverändert in objektorientierte Paradigma übernommen wurden.

2 Copyright, Page 2 of 13 Eine Moduldefinition ist zweigeteilt und besteht aus einer Schnittstelle und einer Implementation. Die Zweiteilung der Moduldefinition in Schnittstelle und Implementierung hat vor allem den Sinn, den für den Benutzer des Moduls relevanten Teil von dem privaten Teil des Moduls zu trennen. Anschaulich handelt es sich bei der Modulschnittstelle um eine Beschreibung des Leistungsumfangs, während die Modulimplementation die zugehörige Realisierung mit sämtlichen Details enthält. Um den Modul korrekt zu benutzen, d.h. die exportierten Operationen korrekt aufzurufen, braucht der Benutzer deren Implementierung nicht zu kennen. Mehr noch, er darf sie nicht kennen, da er sein Wissen höchstens ausnutzen könnte und dadurch das benutzende Programm abhängig von der Modulrealisierung würde. Die Unabhängigkeit des Moduls von seinen Benutzern erhöht aber nicht nur die Sicherheit, d.h. die Programmkorrektheit, sondern auch die Änderbarkeit. Änderungen, die sich auf den Implementationsteil beschränken und nicht die Schnittstelle betreffen, haben keine Auswirkungen auf die benutzenden Programmteile. Wir werden auf diese Aspekte noch näher eingehen. Das zugrundeliegende Prinzip, die Realisierung vor dem Benutzer zu verbergen, nennt man das Geheimnisprinzip. Der Bezug zum Objekt bzw. zur Klasse fehlt in modularen Sprachen; davon abgesehen ist das Konzept der Vererbung bzw. Generalisierung in modularen Sprachen nur ansatzweise oder gar nicht zu erkennen. Ein Objekt ist ein matrielles oder sichtbares Ding, das bestimmte Eigenschaften (z.b. Aussehen und Verhalten) besitzt und mit dem man etwas tun kann so oder so ähnlich würde wohl ein Nicht-Informatiker ein Objekt definieren. Objekte mit denen wir es in der objektorientierten Softwarentwicklung zu tun haben, sind allerdings keine wirklich existierenden Objekte der Realwelt, sondern Abstraktionen dieser Objekte oder aber auch Abstraktionen einer fiktiven, gedachten Welt, die nur in unserer Vorstellung existiert. So kann beispielsweise Mitarbeiter Mustermann als ein abstrahiertes Objekt interpretieren. Dagegen ist eine Partie Schach mehr eine Idee als ein tatsächlich existierendes Ding im Sinne der Objektorientierung ist auch dies ein Objekt. Der zweite Schritt ist die Abstraktion von Objekten gleicher Art hin zu Klassen. Dabei werden insbesondere auch kollektive Eigenschaften der Objekte (sofern für die Problemlösung nötig) in der Klasse sichtbar. Man abstrahiert also strukturell gleichartige Objekte und nennt sodann dieses Klasse. Eine Klasse kann man auch als Schablone für die Objekte verstehen. Eingenschaften von Objekten können Attribute als auch Operationen sein. Ein Attribut (von lat: attribuere = zuteilen, zuordnen) wird gemeinhin als die Zuordnung eines Merkmals zu einem konkreten Objekt verstanden. Ein Attribut charakterisiert also ein Objekt. Attribute einer Klasse muss man also als Variable verstehten, die bestimmte Ausprägungen annehmen kann. Das abstrahierte Verhalten einer gleichartigen Menge von Objekten nennen wir Operation. In der Idee Klasse bezeichnet man die abstrahierten Operationen der Objekte als Methoden, dabei wird eine Methode einer Klasse von den Operationen der einzelnen zugehörigen Objekte bestimmt. Bei der objektorientierten Programmierung kehrt man diese Beobachtungsweise um. Man programmiert Klassen mit Methoden und Attributen und erzeugt mit Hilfe dieser Schablone seine Objekte.

3 Copyright, Page 3 of UML Grundlagen Die Unified Modeling Language (kurz UML) ist eine standardisierte Sprache für die objektorientierte Modellierung von Software und anderen Systemen. Die UML definiert grafische Notationen für diese Begriffe und für Modelle von statischen Strukturen und von dynamischen Abläufen, die man mit diesen Begriffen formulieren kann. So wird ein Objekt stets als Rechteck mit unterstrichenem Objektnamen visualisiert. Dagegen wird eien Klasse als Rechteck mit nicht unterstrichenem Objektnamen veranschaulicht. Nun ist es nicht immer ganz einfach, unter den Realweltphänomenen diejenigen zu erkennen, die sinnvollerweise als Objekte zu modellieren sind. Eine Gefahr besteht z. B. darin, eine funktionale Abstraktion fälschlicherweise als Objekt aufzufassen. So sollte etwa ein Kauf als funktionale Abstraktion modelliert werden, wenn die Kauftätigkeit gemeint ist, und nur dann als Objekt, wenn man den Kaufvertrag an sich oder die gekaufte Ware meint. Typische Beispiele von Nicht-Objekten sind z. B. Alter, Schönheit und Farbe oder Gefühle wie Liebe und Hass. Erstere sind Attribute, letztere spiegeln allenfalls Verbindungen zwischen Objekten wider. Als Fazit halten wir fest, dass wir eine Richtschnur benötigen, um Objekte eindeutig von Nicht-Objekten wie z. B. funktionalen Abstraktionen oder Attributen und Verbindungen abzugrenzen. Wie bereits weiter oben angedeutet kann eine Klasse durch Attribute, Methoden und dessen Verbindungen zu anderen Objekten. charakterisiert werden. Wir können zwei Arten von Attributen unterscheiden. Einfache Attribute, sind Eigenschaften des Objektes, welche selbst kein Objekt darstellen. Nicht-einfache Attribute, sind selbst wieder Objekte und haben somit evtl. selbst Attribute und Methoden. Die Attribute des Objektes und der Klasse entsprechen sich. Attributwerte können statisch als Konstante und dynamisch als Variable bzw. Objekt sein. Der Zustand eines Objektes ergibt sich aus der konkreten Wertebelegung seiner Attribute. Attributwerte von Objekten können dynamisch geändert werden und damit eine Zustandsänderung verursachen. Im Gegensatz dazu macht es (i. A.) für Klassen keinen Sinn einen Zustand zu definieren; letztlich ist es aber Definitionssache, denn Sonderfälle wie abstrakte Klassen sind hierbei dann ausgenommen. Ferner gibt es so genannte Klassenvariablen (auch Klassenattribute genannt), welche denselben Wert für alle Objekte einer Klasse verkörpern. Ein beliebiges Exemplar einer Klasse operiert mit Hilfe einer Methode auf dessen Menge an vorgegebenen (Input-)Daten und den zugehörigen Attributwerten des Exemplars.

4 Copyright, Page 4 of 13 Oft bezeichnet man eine Methode auch also Operation. Das Verhalten eines Objekts gibt für jeden Zustand an, welche Operationen (nach aktuellem Zustand und gegebenen Eingabedaten) ausgeführt werden dürfen und welches Resultat, d.h. welche Zustände und welche Rückgabewerte, sich nach Ausführung der Operationen ergeben. Ausgehend von einem Anfangszustand (auch Initialzustand genannt) ist der aktuelle Zustand eines Objektes durch die Folge von Operationen definiert, die das Objekt bis dahin ausgeführt hat. Grundsätzlich ist es nicht sinnvoll ein Verhalten für Klassen zu definieren. Eine Klasse beschreibt eine Menge von Objekten mit denselben (Anfangs-)Attributen und identischem Verhalten nach Erzeugung. Man kann sich also eine Klasse als eine Art abstrakten Objekttyp vorstellen. Weiterhin beschreibt eine Klasse eine Menge von Objekten mit gemeinsamen Eigenschaften, also identischen Attributen. Die von einer Klasse beschriebenen Objekte werden als Erzeugnisse dieser Klasse bezeichnet. Die Sichtbarkeit eines Attributs oder einer Operation gibt an, ob fremde Klassen auf das Attribut oder die Operation zugreifen dürfen oder nicht. Dabei kennzeichnet das Schlüsselwort public Elemente auf die von außen zugegriffen werden dürfen und private Elemente die geschützt sind gegen Zugriffe anderer Klassen. Im Klassendiagramm kann die Sichtbarkeit auch durch die Zeichen + bzw. kenntlichgemacht werden. 4.0 Verbindungen zwischen Objekten/Klassen Sinnvolle Modelle beschreiben Objektgeflächte, in denen jedes Objekt seine Operationen anderen Objekten zur Verfügung stellt oder sich der Operationen anderer Objekte bedient. In diesem Kontext heißt der Bereitstellende Dienstleister (supplier) und der in Anspruch nehmende Dienstnutzer (client). Voraussetzung für die Nutzung einer Operation eines Objektes durch ein anderes Objekt ist, dass der Dienstnutzer den Dienstleister kennt. Tritt ein Objekt in einer Verbindung stets als Dienstnutzer und das andere stets als Dienstleister auf, bezeichnet man die Verbindung als unidirektional. Allerdings sind auch unidirektionale Verbindungen mit wechselnder Aufgabenverteilung möglich. Verbindungsname: Rolle: Die Darstellung von Verbindungen in UML-Diagrammen erfolgt durch eine durchgezogene Verbindungskante zwischen den Objekten. Die Angabe eines (unterstrichenen) Namens für die Verbindung ist optional. Unidirektionale und bidirektionale Kanten werden als Pfeile mit offener Spitze dargestellt dies kann man auch sehr schön an obiger Skizze erkennen: Der Getränkeautomat stellt eine Dienstleistung zur Verfügung, um diese nutzen zu können müssen Dienstleister und Dienstnutzer in Verbindung treten. D.h. der Kunde muss den Getränkeautomaten kennen, also wissen wo dieser zu finden ist. Dem Automaten

5 Copyright, Page 5 of 13 ist es völlig gleichgültig wen der bedient die Tätigkeit ist stets diegleiche und unabhängig vom Dienstnutzer. Ein Objekt kann bezüglich seiner Verbindungen unterschiedliche Rollen spielen. Unter einer Rolle (siehe Skizze oben) verstehen wir eine Teilmenge der von ihm angebotenen Operationen. Eine Rolle definiert also das Verhalten des Objekts gegenüber den verbundenen Objekten. Wie wir bereits wissen können Objekte Verbindungen eingehen; Verbindungen von Instanzen einer Klasse zu Instanzen derselben Klasse oder anderer Klassen werden im Klassenmodell durch Assoziationsbeziehungen kurz: Assoziationenzwischen den entsprechenden Klassen ausgedrückt. Im Falle von Verbindungen zwischen Instanzen ein und derselben Klasse spricht man von reflexiven Assoziationen. Eine Assoziation wird in der Sprache der UML durch eine durchgezogene Linie zwischen den assoziierten Klassen gezeichnet. Ein Assoziationsende besitzt oft eine Multiplizität, die eine untere und obere Grenze für die Anzahl der jeweils verbundenen Instanzen angibt. Die gebräuchlichsten sind (genau eine verbundene Instanz, Abkürzung: 1) 0...* (beliebig viele verbundene Instanzen, Abkürzung: *) 0 1 (keine oder eine verbundene Instanz) 1 * (unbegrenzt viele verbundene Instanzen, aber mind. eine) Untere Grenze Obere Grenze Einseitige bzw. zweiseitige Beziehungen solcher Art werden Navigierbarkeit genannt und können auch durch Pfeile mit entsprechenden Spitzen dargestellt werden. Ungerichtete Kanten werden als unspezifiziert angesehen. D.h. insbesondere, dass eine Assoziation ohne Pfeilspitzen durchaus bidirektional sein kann. Wie für Naturwissenschaftler üblich, wird der so wichtige Begriff der Assoziation in einzelne Arten von Assoziationen zerlegt. Eine Aggregation ist eine spezielle Assoziation, die eine Hierarchie auf den verbundenen Instanzen definiert. Anschaulich gesprochen besteht also ein Teil-Ganzes-Verhältnis zwischen den verbundenen Instanzen (Objekten). Dabei hat die Ganzes-Instanz eine Verantwortung für die Teil-Instanzen. So erfordert das Zerstören des Ganzen ein Konzept, wie mit seinen Teilen zu verfahren ist. Da ein Objekt gleichzeitig auch Teil anderer Objekte sein kann, muss dem Zerstören besondere Aufmerksamkeit gewidmet werden.

6 Copyright, Page 6 of 13 In Klassendiagrammen wird eine Aggregation durch eine nicht ausgefüllte Raute am Ganzes-Ende der Assoziationslinie gekennzeichnet. Es besteht zwischen Einzelposten und Produkt sowie zwischen Kunde und Bestellung eine Assoziation. Die Aggregation, namentlich Bestellposten, besteht offensichtlich zwischen Bestellung und Einzelposten. Die Ganzes-Klasse Bestellung ist durch die Raute an ihrem Ende der Aggregation gekennzeichnet. Instanzen der Klasse Einzelposten haben Kenntnis von der zugehörigen Produktinstanz, jedoch nicht umgekehrt. Zu einem Einzelposten kann somit z.b. der Verkaufspreis des gewünschten Produktes ermittelt werden. Hierbei können beliebig viele Einzelposten, doch mind. 1 aufgegeben werden. Neben der Aggregation kennt die UML die Komposition. Die Komposition ist eine spezielle Aggregation, es werden also zusätzliche Forderungen an die Aggregation gestellt: Teilobjekte einer Komposition dürfen nur von Objekten der Ganzes-Klasse entfernt oder ausgetauscht werden, d.h. allein die Teilobjekte haben keine Daseinsberechtigung ohne Ihre zugeordnete Ganze-Klasse. dürfen nicht Teil anderer Kompositionen sein; konkreter: ein identisches Objekt (Instanz einer Klasse) darf nicht zwei oder mehr Kompositionen zugeordnet sein, dagegen kann ein gleiches Objekt sehr wohl mehreren Kompositionen zugeordnet werden. werden beim Zerstören des Ganzes-Objektes automatisch (kaskadierend) mit zerstört. Betrachten wir die Klasse Polygon. Jedes Erzeugnis besitzt ein Teilobjekt der Klasse Graphikattribut, in dem seine Visualisierungsattribute wie z.b. Farbe und Beschriftung gespeichert werden. Ist jede Instanz der Klasse Graphikattribut eindeutig einer Polygonin-

7 Copyright, Page 7 of 13 stanz zugeordnet, liegt eine Komposition vor; die Graphikattribut-Instanz darf nicht ausgetauscht werden und muss beim Zerstören des Polygonobjekts sinnvoller Weise automatisch mitzerstört werden. Häufig muss eine Assoziation mit Attributen ausgestattet werden, z.b. mit dem Datum, wann eine Verbindung zwischen zwei Objekten eingegangen wurde. Dieser Sachverhalt kann mit einer eigenen Assoziationsklasse modelliert werden, die es erlaubt, eine Assoziation nicht nur mit eigenen Attributen, sondern auch mit eigenen Operationen und anderen Elementen zu versehen. Wichtig ist die Eindeutigkeit, d.h. dass jede Assoziationsklasse genau eine Assoziation repräsentiert, die lediglich um einige Merkmale erweitert wurde. Im Klassendiagramm wird eine Assoziationsklasse durch eine gestrichelte Linie mit der entsprechenden Assoziationslinie verbunden. Obiges UML-Diagramm visualisiert ein typisches Beispiel. Offensichtlich besteht eine Verbindung zwischen einer Person und einer Firma ein Beschäftigungsverhältnis. Die Multiplizitäten sind klar, denn diese Beschäftigung ist üblicherweise eine 1:1-Beziehung. Natürlich kann eine Firma mehrere Beschäftigungen aufweisen. Eine übersichtlichere Modellierung ist die folgende. Wird einem Mitarbeiter gekündigt, so verweilt der Datensatz dennoch in der Datenbank, jedoch besteht keine Beschäftigung mehr. Dies ist auch der Grund, warum eine Person nicht mehrere Male bei einer Firma beschäftigt sein kann. Hier müsste man anstatt dessen mehrere Assoziationen verwenden. Unter den Attributen einer Klasse können solche vorkommen, die aus anderen Modellierungen berechnet werden können. So kann z.b. bei einer Klasse Zeitintervall mit den Attributen anfang, ende und dauer das Attribut dauer aus den beiden originären Attributen anfang und ende berechnet werden (genauer: aus den jeweiligen Attributwerten). Wir bezeichnen Attribute wie z.b. dauer als abgeleitete Attribute. Analog gibt es abgeleitete Assoziationen. So ist z.b. bei der Modellierung einer Familie mit den Klassen Elternperson und Kindperson die Assoziation Geschwister ableitbar aus der Assoziation Kind. Sind nämlich zwei (Kind-)Personen mit denselben (Eltern-) Personen verbunden, kann man auf die Existenz der Geschwisterverbindung schließen. Abgeleitete Modellelemente erkennt man in der UML daran, dass ihrem Namen ein / vorangestellt wird. Zugriffe auf Attribute (auch auf öffentlich sichtbare) sollten zur Wahrung des Geheimnisprinzips stets über entsprechende Operationen erfolgen. Das Gleiche gilt auch für das

8 Copyright, Page 8 of 13 Erstellen und Lösen von Verbindungen zwischen Objekten. Dies hat zur Folge, dass bereits bei der Klassenmodellierung für alle Klassen und Assoziationen derartige Operationen vorgegeben werden müssen. Zur Vereinfachung führt man Standardoperationen für den Zugriff auf Attribute und Asoziationen ein, die oft nicht explizit in den Diagrammen angegeben werden. Die im Folgenden angegebenen Standardoperationen sind in allen Aktivitäten der Softwareentwicklung verwendbar. Für ein Attribut att vom Typ T heißen die Standardoperationen zum Lesen und Schreiben: gibatt():t liefert den Wert des Attributs att; setzeatt(in wert: T) setzt den Wert des Attributs att auf den übergebenen Wert wert. verbindeass(in einb : B) verbindet die ausführende A-Instanz mit der übergebenen B-Instanz einb; gibass(): B gibt die mit der ausführenden A-Instanz verbundene B-Instanz bzw. (bei einer mehrwertigen Assoziation) die Menge aller verbundenen B-Instanzen zurück; loeseass(in einb : B) hebt die Verbindung zwischen der ausführenden A-Instanz und der übergebenen B-Instanz einb wieder auf. 5.0 Fortgeschrittene Konzepte: Klassen und Beziehungen Das Konzept der Klasse arbeitet Gemeinsamkeiten von Objekten heraus. Wir werden nun noch einen Schritt weiter gehen und klassenübergreifende Gemeinsamkeiten betrachten. In der Biologie werden gemeinsame Eigenschaften von Lebewesen über Hierachiestufen wie z.b. Rasse, Art, Gattung, Familie und Ordnung ausgedrückt. Diese Systematisierung schreitet von spezielleren Eigenschaften bestimmter Lebewesen zu allgemeineren Eigenschaften. Die objektorientierte Modellierung bietet die Möglichkeit, Gemeinsamkeiten wie z.b. Attribute oder Operationen unterschiedlicher spezieller Klassen in einer allgemeineren Klasse zusammenzufassen. Auf diese Weise gewinnt das Modell an Aussagekraft und es wird Redundanz vermieden. Wir nennen solche Beziehungen zwischen spezielleren und allgemeineren Klassen Generalisierungen. Generalisierung bedeutet, dass alles, was für eine Instanz der allgemeineren Klasse gilt, auch für eine Instanz der spezielleren Klasse zutrifft. Wir nennen die allgemeinere Klasse Oberklasse und die speziellere Klasse Unterklasse. Die Unterklasse erbt (d.h. hat zur Verfügung) alle Attribute und Methoden sowie alle Assoziationen der Oberklasse. Häufig wird anstelle des Begriffs Generalisierung auch Spezialisierung verwendendet.

9 Copyright, Page 9 of 13 Gemäß Definition ist damit jedes Erzeugnis der Unterklasse auch ein Erzeugnis der Oberklasse. Daraus folgt direkt, dass jedes Vorkommen eines Erzeugnisses der Oberklasse (sei es in der Spezifikation, im Quelltext oder im ausgeführten Programm), durch ein Erzeugnis der Unterklasse ersetzt werden kann, ohne das sich die Semantik ändert. Diese Eigenschaft nennt man auch Substituierbarkeitsprinzip. Wir betrachten Privatkunden und Firmenkunden und fassen die gemeinsamen Merkmale wie z.b. Name und Adresse in einer neuen gemeinsamen Oberklasse Kunde zusammen. Somit ist jedes Erzeugnis der Klasse Privat- oder Firmenkunde natürlich auch eine Instanz der Klasse Kunde. Es gilt also das Substituierbarkeitsprinzip. Das Konzept der Generalisierung erscheint einleuchtend und einfach, doch die korrekte Anwendung erfordert einige Übung. Falsch eingesetzte Generalisierung ist nicht nur irreführend, sondern kann auch zu aufwendigen Änderungen und unangenehmen Fehlern führen. Um Substituierbarkeit zu ermöglichen, unterstützen objektorientierte Programmiersprachen wie Java die Konzepte Polymorphismus und dynamisches Binden. Jede Operation einer Klasse besitzt eine Vor- und eine Nachbedingung, welche zum einen die zulässigen Eingaben und zum anderen den gewünschten Zustand nach der Operation spezifizieren. Diese Bedingungen ordnen der aktuellen Objektkonstellation (Programmzustand) ein boolsches Ergebnis (True oder False) zu. Die Objekte einer Klasse besitzen häufig Eigenschaften, die vor und nach jeder Ausführung einer öffentlichen Operation gelten müssen. Um die Bedingung, die diese Eigenschaften sicherstellt, nicht in jeder Vor- und Nachbedingung angegeben werden müssen, formulieren wir diese als Klasseninvariante. Wir betrachten eine Klasse A mit Unterklasse B und bezeichnen mit op A bzw. op B die in A definierte bzw. in B überschriebene Operation op(). Die (Spezifikation der) Operation op B aus B heißt konform zur (Spezifikation der) in der Klasse A definierten Operation op A, wenn die folgenden drei Konformitätsbedingungen gelten: 1. op B und op A haben die gleiche Signatur 2. Vorbedingungen(op A ) Vorbedingungen(op B ) 3. Nachbedingungen(op B ) Nachbedingungen(op A ) Damit Instanzen der Unterklasse die Instanzen der Oberklasse auch semantiktreu vertreten können, ist es erforderlich, dass die Spezifikation der Unterklasse zur Spezifikation der Oberklasse konform ist. INV A bzw. INV B bezeichnen im Weiteren die Invarianten der Klasse A bzw. B. Sind alle von A geerbten Operationen in B konform zu den entsprechenden Operationen in A und gilt darüber hinaus INV B INV A, so heißt die (Spezifikation der) Unterklasse B konform zur (Spezifikation der) Oberklasse A.

10 Copyright, Page 10 of 13 Die Definition der Konformität präzisiert das Prinzip der Substituierbarkeit: Ist die Klasse B konform zur Klasse A, dann können Instanzen der Klasse A durch Instanzen der Klasse B ersetzt werden. Damit lässt sich jetzt die Definition der Generalisierung präzisieren: Eine Ober-Unter-Klassenbeziehung bezeichnen wir als Generalisierung, wenn die Unterklasse konform zur Oberklasse ist. Für die Spezifikation von in der Unterklasse zusätzlich definierten Operationen besteht keine Einschränkung. Ist der Unterklasse zu ihrer Oberklasse nicht konform, sprechen wir anstelle von Generalisierung von Vererbung. Die Sichtbarkeiten von Attributen und Operationen werden in der UML durch Voranstellen der Schlüsselworte public bzw. private gekennzeichnet. Die öffentlichen Attribute und Operationen stehen ihrem Dienstnutzer zur Verfügung, die privaten nicht. Letztere werden nur für die Realisierung benötigt, die gemäß dem Geheimnisprinzip nach außen verborgen bleiben müssen. Wie bereits angesprochen sollte man auch auf öffentliche Attribute nur über entsprechende Standardoperationen (seter- und geter-methoden) zugreifen. Im Kontext der Generalisierung bietet die UML (und einige Programmiersprachen) noch eine weitere Sichtbarkeit an. Die Generalisierung koppelt die verbundenen Klassen relativ eng (vgl. Substituierbarkeitsprinzip). Häufig muss die Unterklasse sogar einige Realisierungsdetails ihrer Oberklasse kennen, z.b. wenn sie die Implementierung einer Oberklassenoperation geeignet anpassen muss (Aufruf der super-methode in Java). Um Implementierungsdetails, die nur in Unterklassen bekannt sein sollen, allen anderen Klassen gegenüber zu verbergen, können Attribute und Operationen als geschützt (protected) deklariert werden. Geschützte Attribute und Operationen sind nur in der definierten Klasse selbst und in ihren Unterklassen sichtbar. In der UML wird bei geschützten Attributen und Operationen das Schlüsselwort protected oder das Zeichen # vorangestellt. Analog zu den verschiedenen Sichtbarkeiten werden verschiedene Schnittstellen einer Klasse unterschieden. Die öffentliche Schnittstelle einer Klasse umfasst die Beschreibung ihrer öffentlichen Attribute und Operationen. Sie stellt damit den von außen sichtbaren Teil der Klasse dar, also genau diejenigen Features, die von den Dienstnutzern in Anspruch genommen werden können. Private bzw. geschützte Features werden in der privaten bzw. geschützten Schnittstelle beschrieben. Die privaten Features einer Klasse dienen ihrer internen Realisierung, die geschützten Features ermöglichen es, Realisierungsdetails in Unterklassen geeignet zu modifizieren. Entsprechend versteht man unter dem Begriff Implementierung einer Klasse die Realisierung ihrer öffentlichen Schnittstelle. Allerdings setzen die öffentlichen Schnittstellen auf den privaten Operationen derselben Klasse auf, da diese die öffentliche Schnittstelle

11 Copyright, Page 11 of 13 mit ihren verkapselten Funktionalitäten realisieren. Die Implementierung einer Operation wird dabei in der UML als Methode bezeichnet. Die Realisierungsinterna der Implementierung bleiben Dienstnutzern verborgen. Um Modellierungselmente wie z.b. Klassen oder Assoziationen besonders aussagekräftig an die jeweilige Situation anpassen zu können, bietet die UML das Erweiterungskonzept Stereotyp an. Für jeden Stereotyp gilt ein Satz spezieller, textuell spezifizierter Charakteristika und/oder Zusicherungen. Jeder Stereotyp wird durch einen Benutzer identifiziert. Zusätzlich kann auch ein graphisches Symbol vereinbart werden. In UML-Diagrammen können stereotypisierte Klassen auf drei verschiedene Arten dargestellt werden: 1. Der Bezeichner des Stereotyps wird textuell, eingefasst in guillemets (), über dem Namen der Klasse angegeben oder 2. das graphische Symbol des Stereotyps erscheint oben rechts im Klassenrahmen oder 3. es ist nur das graphische Symbol des Stereotyps mit darunterliegendem Klassennamen aufgeführt. Bisher haben wir drei Arten von Beziehungen kennengelernt: o Verbindungen bei Objekten, o Assoziationen (inklusive Aggregationen und Kompositionen) bei Klassen und o Generalisierungsbeziehungen. Neben diesen gibt es in der UML noch eine weitere Beziehungsart: die Abhängigkeit (dependency). Mit dieser (schwächeren) Beziehungsart kann man ausdrücken, dass Modellelemente irgendwie von anderen Modellelementen abhängen. Eine Abhängigkeit ist eine gerichtete Beziehung, welche die hinsichtlich eines bestimmten Sachverhalts abhängigen Elemente ( Klienten, clients) mit den unabhängigen Elementen ( Anbieter, supplier) verknüpft. Eine Abhängigkeit kann also auch mehr als zwei Modellelemente umfassen und sagt ohne weitere Angaben nur aus, dass die abhängigen Elemente Kenntnis von den abhängigen Elementen haben und Änderungen eines Anbieters Konsequenzen für Klienten nach sich ziehen können. In der UML sind einige Stereotype vordefiniert, welche die jeweils verknüpfbaren Modellelemente und die Bedeutung der Abhängigkeiten präzisieren. Abhängigkeiten werden in UML-Diagrammen als in Richtung von den abhängigen zu den unabhängigen Elementen verlaufende Pfeile mit gestrichelter Linie und offener Spitze dargestellt. Die Art der Darstellung kann jedoch je nach Stereotyp der Abhängigkeit variieren. Hier verwendet die Klasse A bspw. die Klasse B, d.h. die Klasse A ist von der Klasse B abhängig. Die UML unterscheidet drei arten von Klassen.

12 Copyright, Page 12 of 13 a) Reguläre Klassen, deren sämtliche Operationen implementiert sind. b) Abstrakte Klassen, die mindestens eine abstrakte Operation besitzen, d.h. eine Operation, für die keine Implementierung angegeben ist. c) Interfaces, die keine Attribute besitzen, keine ihrer Operationen implementieren und keine Kenntnis von Assoziationen haben dürfen, d.h. sie dürfen höchstens Ziel einseitig navigierbarer Assoziationen sein. Von regulären Klassen können Instanzen erzeugt werden, nicht aber von abstrakten Klassen oder Interfaces. Bei den beiden letzteren wäre sonst zumindest ein Teil des Verhaltens ihrer Instanzen undefiniert. Durch Unterklassenbildung (Vererbung) einer abstrakten Klasse, in der die abstrakten Operationen implementiert werden, erhält man reguläre (Unter-)Klassen, von denen Instanzen gebildet werden können. Ansonsten verhalten sich die abstrakten Klassen wie normale, sie enthalten die gleichen Eigenschaften und können auch selbst von anderen Klassen erben. Abstrakte Klassen sind das Gegenteil von konkreten Klassen. Eine Klasse realisiert ein Interface, indem sie dessen sämtliche Operationen in ihren Schnittstellen anbietet. Zur Modellierung dieses Sachverhalts bietet die UML die «realizes»-abhängigkeite (realize dependency) an. Zu einem Interface kann es durchaus mehrere realisierende Klassen geben, die dann alle als Klienten in der Realisierungsabhängigkeit zum Interface (Anbieter) auftreten. Interfaces werden in UML-Diagrammen als Klassen mit dem Stereotyp «interface» dargestellt oder einfach als ein kleiner, mit dem Namen des Interface unterschriebener Kreis. Abstrakte Klassen und Interfaces dienen primär der Strukturierung von Modellen und Software. Sie extrahieren Gemeinsamkeiten von Klassen und definieren Vorgaben für deren Schnittstellen, wobei in abstrakten Klassen nicht nur die Schnittstellen, sondern auch Teile der Implementierung zur Redundanzvermeidung vordefiniert werden können. Abstrakte Klassen und Interfaces bieten also den Dienstnutzern eine einheitliche Schnittstelle für eine Familie von Realisierungen an. Zusammenfassend halten wir fest: Abstrakte Klassen und Interfaces sind ähnliche Konzepte und werden in vielen Programmiersprachen mit demselben Konstrukten umgesetzt. Beide definieren eine Schnittstelle und verschieben die Realisierung auf einen späteren Zeitpunkt bzw. in Unterklassen. Während eine abstrakte Klasse jedoch Attribute enthalten kann, beliebig in Assoziationsbeziehungen vorkommen darf und die Implementierung von eigenen Operationen zulässt, enthält ein Interface keine Attribute, ist höchstens Ziel von einseitig navigierbaren Assoziationen und erlaubt die Implementierung der spezifizierten Operationen ausschließlich in den realisierenden Klassen. Wie bekannt werden die Attribute und Operationen eines Obejekts durch entsprechende Attributs- und Operationsspezifikationen seiner Klasse definiert. In einigen Fällen möchte man jedoch modellieren, dass ein Attributwert nicht nur im Kontext einer einzelnen Instanz der jeweiligen Klasse, sondern klassenweit, d.h. für alle Erzeugnisse der Klasse, gilt. Um solche Attributwerte manipulieren zu können, muss es auch entsprechende klassenweit ausführbare Operationen geben. Die UML sieht hierfür die Konzepte Klassenattribut und Klassenoperation vor.

13 Copyright, Page 13 of 13 Für ein Klassenattribut existiert jeweils nur ein einziger, für alle Erzeugnisse global sichtbarer Wert. Im Fall einer Klassenoperation wird die Operation nicht im Kontext einer Instanz, sondern im Kontext der Klasse ausgeführt. Klassenattribute und operationen werden in UML-Diagrammen und textuellen Spezifikationen durch Unterstreichungen des Bezeichners gekennzeichnet. Zur Beschreibung komplexer Sachverhalte der Realwelt können sich die bisher vorgestellten Modellierungselemente als nicht ausreichend erweisen. Für derartige Fälle sieht die UML so genannte Zusicherungen (Constraints) vor, die für (Mengen von) Modellierungselmenten formuliert werden können. Eine Zusicherung kann in das Klassendiagramm integriert werden, indem sie (eingeschlossen in geschweifte Klammern) an die Elemente im Klassenmodell geschrieben wird, für welche sie gilt. Zum Abschluss noch einige Bemerkungen zur strukturellen Modellierung. Das objektorientierte Paradigma wird oft zu einseitig interpretiert. Softwareentwickler tendieren gerne dazu, alles in der Welt als Objekt zu begreifen eine naive, viel zu kurz greifende und oft kontraproduktive Betrachtungsweise. Nicht zuletzt wegen der immer wichtiger werdenden unternehmensweiten Integration von Softwareanwendungen gewinnen globale Funktionen, modelliert als Geschäftsprozess, zunehmend an Bedeutung. Derartige Funktionen etwa in den Operationen von (vielen) Klassen zu verstecken, stellt nicht nur eine inadäquate Modellierung dar, sondern erweist sich noch aus einem anderen Grund als besonders nachteilig. Erfahrungsgemäß ändern sich Funktionen häufiger als Daten bzw. Objekte, und die Änderung solcher verstreuter Funktionalität ist besonders aufwändig.