Modellierung statischer Strukturen

6 Modellierung statischer Strukturen 6.1 Ubersicht Klassen- und Objektdiagramme zeigen die statische Struktur eines Systems. Dazu gehoren die beteiligten Klassen, ggf. Objekte, die Beziehungen zwischen ihnen, Attribute und Operationen. Je nach Gro:f&e des Systems wird dieses weiter in Pakete zerlegt. In der Analyse liegt das Interesse auf der Darstellung der Strukturen im Anwendungsbereich und der Erfassung der Anforderungen an das System. Spiiter verschiebt sich der Interessenschwerpunkt auf IT-spezifische Objekte. Die Darstellungsform bleibt wiihrend des ganzen Entwicklungsprozesses erhalten. Sie wird aber urn DV-spezifische Elemente ergiinzt und nach Bedarf angepasst. Die Darstellung beginnt aus mehreren Grunden mit den statischen Strukturen: • Statische Strukturen sind im Zeitablauf im Wesentlichen stabil und daher einfacher zu identifizieren als veriinderliche, dynamische Strukturen. • Diagramm-Arten, wie Sequenzdiagramme oder Zustandsdiagramme bauen auf den statischen Modellelementen auf oder beziehen sich auf diese. • Dem Leser, der Entity-Relationship-Modelle kennt, fiillt der Einstieg hier wahrscheinlich am leichtesten. Da die Darstellung der Diagramme einen erheblichen Umfang einnimmt, sei auf Folgendes besonders hingewiesen: Das Analysieren von Problem en und der Entwurf von Software besteht nicht im Zeichnen von Diagrammen. Diagramme halten Erkenntnisse nur in priiziser und iibersichtlicher Form fest. 6.2 Lernziele • • • • • • Die Begriffe Klasse, Assoziation und Aggregation kennen. Basisnotation fur Objekte, Klassen und Beziehungen kennen. Syntax und Semantik des Klassenmodells kennen. Klassen und Objekte sicher identifizieren konnen. Einfache Klassenmodelle entwickeln konnen. Multiplizitiiten verstehen. B. Kahlbrandt, Software-Engineering mit der Unified Modeling Language © Springer-Verlag Berlin Heidelberg 2001 6.3 Klassen und Objekte 125 «8tereotyp» Klassenname AtribuName:Typ~ (Eigenschaften) AtlributName[Multiplizitat] AtlributName:Typ InitialWert (+i-#JAtlrbuName:Typ~ InitialWert ~li§enArbut:TI1W OperationsName OperationsName:ROckgabe Typ OperationsName(Parameter: Typ) :ROckgabe Typ [+i-i#jOperationsName{Parameter: Typ) :ROckgabe Typ ~liI§eoQW![tn(Pr:Tg'R;kb T~g Abb. 6.1. Schema eines Klassensymbols • Unterschied zwischen Assoziation und Aggregation kennen . • Verallgemeinerung und Spezialisierung kennen. 6.3 Klassen und Objekte Klassen und Objekte sind die Dreh- und Angelpunkte jeder objektorientierten Methode. Definition 6.3.1 (Klassensymbol) Das Klassensymbol ist ein Rechteck mit dreiAbschnitten: 1. Einem Abschnitt mit dem Namen der Klassen in fetter Schrift, ggf. durch weitere Informationen ergiinzt. 2. Einem Abschnitt, der die Attribute in normaler Schrifttype zeigt. 3. Einem Abschnitt, der Operationen in normaler Schrifttype zeigt. Weitere optionale Abschnitte konnen als Ergiinzung hinzukommen, etwa urn die Verantwortung der Klasse wie bei Klassenkarten zu beschreiben ..... Die Angabe des Namens der Klasse kann durch folgende Elemente ergiinzt werden: 1. Stereotyp: Ein Beispiel hierfiir ist «actor» (Akteur). 2. Eigenschaften oder Bedingungen: Ein Beispiel hierfiir ist {abstrakt} oder {Autor = Bernd Kahlbrandt}. Die Elemente eines vollstiindig ausgefulltes Klassensymbols zeigt Abb. 6.1. An die Stelle des Rechtecks kann das Symbol fur den Stereotyp der Klasse treten. Die Angabe des Namens der Klasse ist obligatorisch. Die Darstellung der Abschnitte fur Attribute oder Operationen kann unterbleiben. Die Darstellung sagt in einem solchen Fall nichts uber das Vorhandensein der fehlenden Elemente aus. Wird ein leerer Abschnitt dargestellt, so heigt dies, dass es keine entsprechenden Elemente (Attribute bzw. Operationen) in der Klasse gibt. 126 6 Modellierung statischer Strukturen Abb. 6.2. Narnensteil des Klassensyrnbols Definition 6.3.2 (Abstrakte und konkrete Klassen) Eine abstrakte Klasse ist eine, die keine direkten Objekte haben kann, z. B. weil die Implementierung von Operationen an Unterklassen delegiert wurde. Eine abstrakte Klasse wird durch die Eigenschaft {abstrakt} oder einen kursiv gesetzten Klassennamen gekennzeichnet. SoIl bei einer Klasse betont werden, dass sie nicht abstrakt ist, so nennt man sie konkrete Klasse . .... Beispiel 6.3.3 (Namensteil des Klassensymbols) Abbildung 6.2 zeigt Klassen aus den vorangehenden Beispielen 2.3.6, 2.3.14 und 2.7.2 mit moglichen Eigenschaften und Stereotypen, die gegeniiber Abb. 2.10 auf S. 36 hinzukommen. 1. Wirbeltier und Vogel: Abstrakte Klassen, gekennzeichnet durch kursive Klassennamen und die Eigenschaft {abstrakt}. Diese Hierarchie unterstellt, dass jedes Objekt einer konkreten Klasse am Ende der Hierarchie angehort. 2. Seidenschwanz: Eine konkrete Klasse. 3. Kunde: Eine Klasse mit dem Stereotyp «Actor», der in Def. 2.4.1 auf S. 28 eingefiihrt wurde. 4. Auto, PKW, LKW: Konkrete Klassen ohne Stereotypen. In dieser Hierarchie kann es also Objekte der Klasse Auto geben, die weder PKW noch LKW sind. 5. Person, Benutzer und Bibliothekar: Die Klasse Person ist abstrakt. Das heii5t, in dem betrachteten Kontext eines Bibliothekssystems gibt es keine Person, die weder Benutzer noch Bibliothekar ist. Benutzer und Bibliothekar sind konkrete Klassen mit dem Stereotyp «Akteur», die Objekte dieser Kassen konnen also in Interaktionen mit dem System kommuniziereno Bei der Klasse Benutzer ist noch der Autor N.N. (Nomen Nominator oder Norbert Nolte ... ) notiert. Da es hier urn den Namensteil geht, sind die Teile mit Attributen und Operationen nicht dargestellt ..... Definition 6.3.4 (Objektsymbol) Entsprechend des in Def. 5.4.1 auf S. 107 angegebenen Schemas ist das Objektsymbol ein Rechteck, das mit dem unterstrichenen String 6.3 Klassen und Objekte Guia des pejxes de Galicia:Buch 127 I Manuel Rodriguez Solorzano I Titel = "Guia des peixes de Galicia" Verlag = "Editorial Galaxia' Adresse= "Vi go" ISBN = "84-7154-433-4" Jahr ="1983" Sergio Devesa Reouejro Lidia Soutullo Garrido !ineSch[jb~<lamp·. Mejo ISQmbj:8ulQ x=O y=O w=800 h=800 I W!!,rt!!§Qblaope I Kennzeichen=" HH-OR 1134" Hersteller = "Mercedes" Typ = '230 TE" Fartle = "WeiS" Leistung = 100 Spannung = 230 Arlikelnr = "HLX 64655" Hersteller =Elch Per Mbalter gyrQb gie (>a!ill\i§'6UQh For!:! PrefeQt:Per§Qn Name= "Prefect" Vorname= "Ford" Geburtsort= "Beteigeuze" Geburtsdaturn= Gewicht= GroSe= Titel = "Per Anhalter durch die Galaxis" Verlag = 'Roger & Bernhard" Adresse = 'Munchen" ISBN = "3-8077-0171-0" Note = "Ein Kultbuch der BOer Jahre" Abb. 6.3. Einige Objektsymbole ObjektName:KlassenName beschriftet ist. Wenn der Zustand des Objekts von Bedeutung ist, so kann er in eckigen Klammern angegeben werden: ObjektName:KlassenName[ZustandsName]. 1m zweiten Abschnitt des Objektsymbol konnen die Attribute in der Form: AttributName : Typ = AttributWert angegeben werden. An die Stelle des Rechtecks kann das Symbol fur den Stereotyp der Klasse treten. Der Name wird dann unter das Symbol geschrieben. ~ Hier nun einige Beispiele fur diese Symbole. Beispiel 6.3.5 (Beispiele fur Objekte) Einige Objekte aus Beispiel 2.3.6 auf S. 22 sind mit unterschiedlichen Bezeichnungen aus Objektname und Klassenname in Abb. 6.3 gezeigt. Gegenuber der entsprechenden Darstellung in Abb. 2.1 auf S. 22 sind einige Elemente hinzugekommen. Die Bucher sind mit Objekt- und Klassenname, getrennt durch einen Doppelpunkt beschriftet. Bei den drei Autoren des Fischbuchs "Gufa dos peixes de Galicia" ist kein Klassenname angegeben. So wird man verfahren, wenn noch nicht entschieden ist, zu welcher Klasse diese Objekte gehoren sollen. In Frage kiimen z. B. Autor oder Person. Das Objekt "Ford Prefect" ist jetzt zusiitzlich mit dem Klassennamen versehen, ebenso das Auto und die Schreibtischlampe. "Warteschlange" und "Fenster" sind anonyme Objekte, d.h. nur mit ,,:Klassenname" beschriftet. ~ 128 6 Modellierung statischer Strukturen Definition 6.3.6 (Sichtbarkeit) Die Sichtbarkeit von Elementen (Attributen oder Operationen) einer Klasse wird durch folgende Symbole dargestelIt: + Offentlich (public): Das Element ist fur Objekte aller anderen Klassen zuganglich. # Geschiitzt (protected): Das Element ist fiir Objekte dieser und aller von ihr spezialisierten Klassen zuganglich. - Privat (private): Das Element ist nur fUr Objekte dieser Klasse zuganglich. Statt der Symbole konnen auch die Schliisselworte public, protected oder private verwendet werden. Dies ist insbesondere iiblich, wenn die Sichtbarkeit fUr eine ganze Liste von Elementen angegeben wird. Weitere, imp lementierungsabhangigen Sichtbarkeiten sind moglich .... Bemerkung 6.3.7 (Sichtbarkeit) Die hier getroffene Klassifikation der Sichtbarkeit von Elementen (Attributen oder Operationen) einer Klasse entspricht der Klassifikation in C++. Fiir die Einzelheiten der Sichtbarkeit in C++ sei auf die Literatur verWlesen, insbesondere [Str91], [Mey92] und [Mey96] .... Fiir die Darstellung gilt analog zu Attributen und Operationen: 1st keine Sichtbarkeit angegeben, so wird iiber die Sichtbarkeit nichts ausgesagt. Bemerkung 6.3.8 (privat) Dass ein Element einer Klasse privat ist, heifSt nicht, dass nur das jeweilige Objekt dieses Attribut sehen und verandern kann, sondern aIle Objekte der jeweiligen Klasse. Betrachten wir zwei Objekte einer Klasse Person, Pascal und Marcel, in C++ oder Java. Beide mogen eine Reihe von CDs haben. Diese seien als "privat" deklariert, da sie diese als Eigentum ansehen, an das der jeweils andere nicht herankommen solI. Trotzdem konnen die beiden gegenseitig an die CDs gelangen. Die Sichtbarkeit besagt nur etwas iiber den Zugang von Objekten anderer Klassen. Diese konnen auf die privaten Elemente einer anderen Klasse nicht zugreifen. Innerhalb der Klasse Person kann man aber sehr wohl eine "Diebstahls-Operation" ,,NimmVon" schreiben, die als Parameter eine Person und eine CD bekommt. Innerhalb dieser Funktion sind dann Zugriffe auf beliebige Attribute des als Parameter ubergebenen Personen-Objekts moglich. Innerhalb des schiitzendes "Mantels" der Klasse Person sind also Zugriffe moglich, die Objekten anderer Klassen verwehrt werden .... Definition 6.3.9 (Attribut-Spezifikation) Die vollstandige Spezifikation eines Attributs ist: Sichtbarkeit Name[Multiplizitat] :Typ=Default Wert {Eigenschaften } Die Multiplizitat gibt dabei an, wie oft das Attribut auftritt. 1st keine Mutliplizitat angegeben, so ist sie eins. Klassenattribute, d.h Attribute, die einmal 6.3 Klassen und Objekte 129 in der Klasse und nicht mit unterschiedlichen Wertauspragungen in jedem Objekt existieren, werden entsprechend der Konvention aus Def. 5.4.1 auf S. 107 durch Unterstreichen gekennzeichnet: Sicht barkeit EinKlassenAttribut[M ultiplizitat1:Typ=Default Wert Dabei sind "Typ" und "Default Wert" sprachabhangige Spezifikationen zur Implementierung des Attributs. Weitere Eigenschaften des Attributs ki::innen in geschweiften Klammern hinter einem Attribut oder vor einer Liste von Attributen notiert werden. In letzterem Fall gelten sie bis zur nachsten Eigenschaftsangabe. <Oil Beispiel 6.3.10 (Attribut-Spezifikation) Die Ausdrucke ,,kundenNummer:int", ,,name:string" und "plz:string="20000"" sind Beispiele fUr Attribut-Darstellungen. <Oil Bemerkung 6.3.11 (Angaben zu Attributen) Fur die Spezifikation von Attributen gelten folgenden Regeln: • Mindestens der Name des Attributs wird spezifiziert. • Die Sichtbarkeit von Attributen ist in der Regel privat. • In der Analyse ist von der sprachabhangigen Spezifikation von Typ und Initialwert sparsam Gebrauch zu machen. Festlegungen fUr die Implementierung sollten hier vermieden werden. Da die Spezifikation des Typs sprachabhangig ist, kann sie im Laufe der Entwicklung in die der Implementierungssprache uberfuhrt werden. <Oil Definition 6.3.12 (Operations-Spezifikation) Die vollstandige Spezifikation einer Operation ist: Sichtbarkeit OpName(Art Parameterl:Typl=default, ... ):RiickgabeTyp. Art ist dabei in, out oder inout. Der default ist in. Wie auch Klassenattribute, werden Klassenoperationen durch Unterstreichen gekennzeichnet. Weitere Eigenschaften der Operation konnen in geschweiften Klammern hinter einer Operation oder vor einer Liste von Operationen notiert werden. In letzterem Fall gelten sie bis zur nachsten Eigenschaftsangabe. <Oil Beispiel 6.3.13 (Operationen) Fur Person en , die mit einer Firma zu tun haben, mag es die Operationen "einstellen", "befordern" und "entlassen" geben. Diese werden als EingabeParameter (in) u. a. ein Datum haben, zu dem die Operation wirksam wird. <Oil Bemerkung 6.3.14 (Angaben zu Operationen) Der Ruckgabe-Typ einer Operation und die Typen der Parameter werden in einer grof6en Zahl der Faile ein implementierungsabhangiger Typ wie int, string, void etc. oder eine Klasse des Modells sein. Nicht berucksichtigt 130 6 Modellierung statischer Strukturen sind dabei Unterschiede wie Wert-Semantik oder ReJerenz-Semantik. Hierbei handelt es sich urn Optimierungen in der Implementierung. Da die TypAusdrucke sprachspezifisch formuliert werden k6nnen, kann dies hier aber dargestellt werden, wenn eine solche Entscheidung getroffen wurde. Ahnlich wie bei Attributen gilt: • Mindestens der Name der Operation wird notiert . • Die Sichtbarkeit kann unterdruckt werden, wenn sie keine entscheidende Bedeutung hat. Eine generelle Empfehlung wie bei Attributen gibt es nicht (s. aber Bern. 6.3.15). Auch wenn die Spezifikation hier selten gezeigt wird, mussen Operationen in jedem Fall prazise beschrieben werden. Es ist aber ublich und sinnvoll, dass technische Details entsprechend dem Entwicklungsfortschritt prazisiert werden ..... Bemerkung 6.3.15 (Sichtbarkeit von Operationen) In vielen Fallen wird es genugen, Attribute als privat zu deklarieren und Operationen als 6ffentlich. Weitere Abstufungen werden meistens erst im Design oder in der Implementierung ben6tigt. Andererseits hat es sich vielfach bewahrt, die Sichtbarkeit restriktiv zu handhaben und dies erst bei entsprechendem Bedarf zu lockern ..... Bemerkung 6.3.16 (Definitionsbereich von Operationen) Die Objekte der betreffenden Klasse sind genaugenommen eine Projektion des Definitionsbereiches einer Operation. Eine Operation kann beliebige weitere Parameter haben. Urn den Unterschied hervorzuheben, werden die Objekte auch vor den Operationsnamen geschrieben und die anderen Parameter wie Variable bei mathematischen Funktionen oder Programmen geschrieben . .... Definition 6.3.17 (Signatur) Die Signatur einer Operation besteht aus: 1. dem Namen der Operation, 2. den Klassen bzw. den Typen und der Reihenfolge der Parameter, 3. dem Typ bzw. der Klasse des Ruckgabewertes der Operation. Sprachabhangige Eigenschaften, wie const in Signatur geh6ren ..... C++, k6nnen ebenfalls zur Beispiel 6.3.18 (Operationen) Einige Beispiele fur die Spezifikation der Signaturen von Operationen sind fur die Klasse Singleton aus Abschn. 12.9.2 auf S. 284: 1. Singleton: • #SingletonO. Ein geschutzter Konstruktor. Dies verhindert, dass an- dere Klassen direkt Singleton-Objekte erzeugen k6nnen. 6.3 Klassen und Objekte 131 SIngleton -uniauelnstance·Siogllloo" -data ±lnstanceO'Si!J!l!moo" j return uniquelnstance J +Operation() +GetData() #Singleton() Abb. 6.4. Spezifikation von Operationen • +createObject () : Singleton t. Eine offentliche Operation, die eine Referenz auf das einzige Objekt dieser Klasse liefert. Siehe auch Abb. 6.4 auf S. 131. Zur Spezifikation von Operationen kann die OCL eingesetzt werden. Hat eine Klasse "Person" ein Attribut "geburtsDatum" und eine Operation "alter 0", so wird diese folgende Spezifikation haben: context Person: :alter() post: result = aktuelles Datum - Geburtsdatum Eine Operation kann iiber Vor- und Nachbedingungen spezifiziert werden. Eine Vorbedingung enthalt Informationen iiber den Zustand des Systems, der beim Start der Operation bestehen muss. Eine Nachbedingung beschreibt den Zustand des Systems nach Abschluss der Operation. Vor- und Nachbedingungen sind hervorragend geeignet, Operationen formal zu spezifizieren; in den meisten Fallen reicht es aber aus, die Bedingungen in priiziser Sprache zu formulieren. Eine Moglichkeit Vor- und Nachbedingungen zu spezifizieren, ist es zwei Objektdiagramme anzugeben, eines vor und eines nach der Operation. Dies kann z. B. fiir komplizierte Datenstrukturen sinnvoll sein. Das Design einer Operation kann in einem oder mehreren Sequenzdiagrammen dargestellt werden (s. Kap. 7) oder auch einem Aktivitiitsdiagramm. Der tatsiichliche Code kann in Form einer Notiz an der Operation im Klassendiagramm dargestellt werden (s. Abb. 6.4). Eine vollstandige Spezifikation konnte aussehen wie in Abb. 6.3. Bemerkung 6.3.19 (Signatur, Polymorphismus und Uberladen) Eine Operation wird nicht durch ihren Namen, sondern erst durch ihre ganze Signatur festgelegt. Es kann also sehr wohl mehrere Operationen in einer Klasse mit dem gleichen Namen geben, die sich durch unterschiedliche Parameter-Listen unterscheiden. Da in Programmiersprachen der Riickgabewert meist nicht mit zum Uberladen von Operationen (s. Abschn. 2.8) verwandt werden kann, wird beim Uberladen nur der Name und die ParameterListe herangezogen. Hiervon wird in der Programmierung ausgiebig Gebrauch gemacht. ~ Der Giiltigkeitsbereich eines Klassennamens ist das Paket, zu der die Klasse gehort (s. Def. 5.5.5 auf S. 110). Gleiche Namen sollten allerdings nur verwandt werden, wenn die Semantik wirklich identisch ist. Namen sollten in 132 6 Modellierung statischer Strukturen Operation: Verantwortung: Sort (Elemente: Array von T) Anordnung der Elemente im Array in aufsteigender Sortierfolge Elemente, ein Array von Objekten der Klasse T Eingaben: Elemente Ruckgabe: Veriinderte Objekte: Keine AIle Objekte aus Elemente sind von der Klasse T. Vorbedingungen: T besitzt einen Vergleichsoperator, der fur den Vergleich zwei Objekte auf "groi&er oder gleich" wahr oder falsch liefert. Nachbedingungen: Elemente enthiilt die Objekte in aufsteigender Reihenfolge. Das Array enthiilt die gleiche Anzahl von Objekten wie vor der Operation. Zwei Objekte, die bzgl. des Vergleichoperators gleich sind, behalten relativ zueinander die Position. Abb. 6.5. Spezifikation einer Operation jedem Fall aber so gewahlt werden, dass sie Elemente (hier Klassen) klar und unmissverstandlich bezeichnen. Klassen konnen in anderen Paketen als in dem, welches die Klasse direkt umfasst, benutzt werden, wenn dies iiber die Sichtbarkeit der Klassen und die Zugriffsrechte anderer Pakete entsprechend spezifiziert ist. Auf der Ebene von Paketen zeigen die import- und die access-Beziehung, dass ein Paket ein anders benutzt. Diese Beziehungen werden durch einen gestrichelten Pfeil, das Abhangigkeitssymbol, mit dem Stereotyp «import» bzw. Stereotyp «access» bzw. dargestellt. Ein Element eines Pakets kann importiert werden, wenn es in dem deklarierenden Paket exportiert wird. Hierfiir gibt es keine besondere Notation, sondern dies wird durch eine Sicht, die die offentlich zuganglichen Elemente zeigt, dargestellt. Der Unterschied zwischen «import» und «access» besteht darin, dass bei «import», die Namen der Elemente dem importierenden Paket direkt hinzugefugt werden, wahrend sie bei «access» voll qualifiziert werden mussen. Der qualifizierte Name einer Klasse wird in der Form PaketName: : KlassenName angegeben, wobei PaketName der Name des umfassenden Pakets der Klasse ist. In vielen Fallen wird man sich auf die Angabe des Klassennamens beschranken, urn ein Diagramm ubersichtlich zu gestalten. Dies ist in verschiedenen Situationen besonders sinnvoll: • Wenn es auf die Darstellung der Beziehungen zwischen den Klassen ankommt . • Wenn die Attribute oder Operationen einer Klasse noch nicht hinreichend sicher feststehen. Bei Einsatz eines CASE- Tools sind die ausgeblendeten Informationen stets zuganglich und sollten bei Bedarf eingeblendet werden konnen. 6.3 Klassen und Objekte 133 Bemerkung 6.3.20 (Namensschreibweisen) Ein "Problem" tritt auf, wenn Klassen- oder Attributnamen Umlaute enthalten. So werden sich diese in keiner Programmiersprache umsetzen lassen. Diese Schwierigkeit tritt in allen Sprachen mit (aus amerikanischer Sicht) ,,funny characters" auf. Vorschlage zur Lasung dieses Konflikts sind: • Von Anfang an auf Englisch modellieren. Dies ist in multinationalen Projekten die Regel. Es stellt den Anwender und Entwickler aber oft vor Probleme, wenn kein ,,native speaker" aus dem Anwendungsbereich zur Hand ist, urn mit geeigneten Fachbegriffen auszuhelfen. Was hei~t z. B. "Ohrenanlegemaschine" auf Englisch? • Schreiben der nicht-ASCII Zeichen mit ihren Ersatzzeichen, wie "ae" fUr "ii" etc. Dies fuhrt beim Anwender und Auftraggeber leicht zur skeptischen Frage: ,,Kann Ihr System keine Umlaute?" Ich sehe die Lasung darin, in der jeweils adiiquaten Sprache des Anwendungsbereichs zu formulieren und Alias-Namen fur die anderen Bereiche zu vergeben. So kannen neben dem Klassen- oder Attributnamen aus dem Anwendungsbereich bei Bedarf ein DV-spezifischer Name zur Verwendung bei der Code-Generierung oder Programmierung vergeben werden. Zum Teil kannten diese sogar automatisch generiert werden . • Bemerkung 6.3.21 (Klassen-Dokumentation) Zur Dokumentation einer Klasse gehart aul/,er den Informationen, die im Klassensymbol enthalten sein kannen, unbedingt noch Folgendes: • Eine kurze Beschreibung der Verantwortlichkeiten der Klasse. • Eine Angabe, wer fur den Entwurf oder die Implementierung verantwortlich ist. • Eine Anderungshistorie mit kurzer Beschreibung, was, warum, wann, wer geandert hat. Eine VersionsfUhrung ist von Anfang an sinnvoll, urn eine Basis fur ein systematisches Konfigurationsmanagement zu haben. Die verfugbare Werkzeugunterstutzung in diesem Bereich ist allerdings noch verbesserungsfiihig . • Bemerkung 6.3.22 (Benennung von Elementen) Fur die Benennung der bisher in diesem Kapitel eingefUhrten Modellelemente Klasse, Attribut und Operation haben sich verschiedene Konventionen eingeburgert, die auch in der UML sinnvoll sind. Es gibt hier aber Unterschiede zwischen Deutsch und Englisch. Sowohl im Deutschen als auch im Amerikanischen sind folgende Konventionen verbreitet: • Klassennamen beginnen mit Gro~buchstaen. • Die Namen von Attributen und Operationen beginnen mit einem Kleinbuchstaben. 134 6 Modellierung statischer Strukturen Katja-Persoo verhejratet mit Bernd-person OOPB'firma ~_o __~I._ __~_SCfti9 __~ ___ fl_m_a__~ Abb. 6.6. Beispiele fill Objektbeziehung und Assoziation • An Wortgrenzen werden Grol&buchstaben werwendet, wie in EierLegendeWollMilchSau oder TheKandyKoloredTangerineFlakeStreamlineBaby. (Diese Konvention stammt aus Smalltalk und ist auch in C++ und Java gehriiuchlich. ) Vorschliige fUr detaillierte Empfehlungen fUr C++ findet man u. a. in [BaI96) oder fUr Java in der Java Spezifikation [GJSBOO). 1m Zweifelsfall wiihle man in Analysemodellen Namen, die vom Anwender akzeptiert werden. ~ 6.4 Assoziationen und Objektbeziehungen Die wenigsten Objekte existieren fiir sich alleine. Sie waren fUr eine Anwendung dann auch ziemlich uninteressant. Sie stehen auf unterschiedlichste Weise mit anderen in Beziehung. Bereits in Def. 2.5.2 auf S. 31 wurden Objektbeziehungen und ihre Bezeichnungen eingefUhrt. Eine Objektbeziehung wird durch eine Linie dargestellt, die zwei Objekte verbindet. Handelt es sich urn mehr als zwei Objekte, so wird wie bei Assoziationen eine Raute benutzt. Die Leserichtung kann wie bei Assoziationen durch ein kleines schwarzes Dreieck angegeben werden, das in Leserichtung zeigt: ,~". Beispiel 6.4.1 (Beispiele fiir Objektbeziehungen) Abbildung 6.6 enthiilt zwei Ohjektbeziehungen: 1. verheiratet mit: Zwei Personen, Katja und Bernd, konnen verheiratet sein. In diesem Fall besteht eine Objektbeziehung, die man als ,,ist verheiratet mit" bezeichnen kann. Eine Leserichtung ist nicht angegeben, da diese Beziehung symmetrisch ist, also in heiden Richtungen gleich gelesen werden kann. 2. arbeitet fUr: Eine Person Wolf kann in einer Firma OODB beschiiftigt sein. In diesem Fall besteht zwischen den beiden Objekten eine Objektbeziehung, die man in der Richtung von Wolf zu OODB als "arbeitet fUr" und in der anderen als "beschiiftigt" lesen kann. Dies wird durch die Leserichtung angegeben. Die Objekte spielen also je nach der Richtung, in der die Objektbeziehung betrachtet wird, unterschiedliche Rollen. 6.4 Assoziationen und Objektbeziehungen Lebensmittel bezeichnung bundeslebensmittelschlussel zebsCode leitsatznummer evs 135 Komponente {abstract} getlleratorO nextO currentO:component Abb. 6.7. Darstellung von Attributen und Operationen Die Bedeutung von Rollen wird spater in diesem Abschnitt erlautert. Der unterste Teil in Abb. 6.6 zeigt die zur daruber dargestellten Objektbeziehung gehorende Assoziation ..... Bemerkung 6.4.2 Die Darstellung von Objekten und Objektbeziehungen wird fur statische Zwecke selten benotigt. Sie ist dort manchmal nutzlich, urn komplexe oder zunachst kompliziert erscheinende Zusammenhange zu durchdringen. Interessant wird sie bei der Modellierung von Kollaborationen, siehe Kap. 7 ..... Wenn Attribute und Operationen dargestellt werden, so werden im Minimum die Namen angegeben, wie in Abb. 6.7 an einfachen Beispielen gezeigt. Dies illustriert auch die Verwendung einiger der in Abschn. 5.5 erwahnten Eigenschaften. Definition 6.4.3 (Assoziationssymbol) Eine Assoziation ist eine Beziehung zwischen Objekten einer oder mehrerer Klassen, die eine Klasse von Objektbeziehungen zwischen diesen Objekten beschreibt. Eine Assoziation zwischen zwei Klassen heil&t binar, zwischen drei Klassen ternar und zwischen n Klassen n-ar. Eine bin are Assoziationen wird durch eine Linie dargestellt, die die beiden beteiligten Klassensymbole verbindet. Mehrstellige (n-are, speziell ternare) Assoziationen werden durch eine Raute dargestellt, die mit den beteiligten Klassensymbolen durch Linien verbunden sind. Der Name der Assoziation wird an das Symbol geschrieben. Wie bei Objektbeziehungen wird die Leserichtung bei Bedarf durch ein kleines schwarzes Dreieck ,~" das in die Leserichtung zeigt, gekennzeichnet . .... In Abb. 6.8 ist die Beziehung zwischen "arbeitet fur" von Person zu Firma zu lesen. Bemerkung 6.4.4 (Benennung von Assoziationen) Manche Assoziationen sind bereits durch die beteiligten Klassen und den Kontext, in dem diese stehen, klar bezeichnet. In einem solchen Fall konnte man auf die Angabe eines Namens verzichten. Ein Beispiel hierfiir bilden einfache Aggregationen. Davon ist abzuraten. Die Faustregel ist, Assoziationen oder deren Enden zu benennen. Urn die Ubersichtlichkeit zu erhohen, kann ein CASE-Tool allerdings die Option bieten, diese in der Anzeige zu unterdrucken ..... 136 6 Modellierung statischer Strukturen 1.: ~ arbeitet fUr 0,1 Arbeitgeber '-----_ _----' '----------;,----------' Arbeitnehmer berichtet an ... ~ 1 Directory Person enthalt 0':1 L __ FI_le_---' 1 0.: ~besitz 0.: _A_u_to_---' LI Abb. 6.8. Biniire Assoziationen Bei weitem am hiiufigsten sind biniire Assoziationen, von denen einige in Abb. 6.8 dargestellt sind und in Beispiel 6.4.8 diskutiert werden. Definition 6.4.5 (Rolle) Eine Klasse kann in einer Assoziation eine bestimmte Rolle spielen. Der Name dieser Rolle wird an das Assoziationsende bei dieser Klasse geschrieben .... Einige Beispiele von Rollen sind in Abb. 6.8 dargestellt und in Beispiel 6.4.8 diskutiert. Die Raute an einer Aggregation ist ein Symbol fiir eine Rolle: Die Klasse, an der die Raute steht, spielt die Rolle des "Ganzen" in der Aggregation. Objektbeziehungen konnen auch zwischen Objekten einer Klasse bestehen, es gibt also rekursive Assoziationen. Bemerkung 6.4.6 (Rollennamen bei rekursiven Assoziationen) Bei rekursiven Assoziationen sind Rollen obligatorisch, vgl. Abb. 6.8. Ohne diese Angaben konnte man die Navigation von einem Mitarbeiter zum anderen entlang der Assoziation ,,fiihrt" bzw. "berichtet an" nicht spezifizieren . ... Definition 6.4.7 (Kardinalitat und Multiplizitat) Die Kardinalitiit einer Rolle gibt an, wieviele Objekte der Klasse in dieser Rolle mit den anderen in Beziehung stehen. Die Multiplizitiit einer Rolle bezeichnet die Bereiche der moglichen Kardinalitiiten. Diese werden als Zahlen (0, 1, 3, ... ), als Bereiche (2 .. 4) oder bei Bedarf als eine Kombination von beidem angegeben. 1st die Anzahl Objekte nicht spezifiziert, so wird dies durch einen * dargestellt. Es bedeutet also: keine Angabe: Genau ein. Viele (auch Null zuliissig). * oder 0 .. *: n .. m: n bis m. Auch eine Liste derartiger Angaben ist moglich .... 6.4 Assoziationen und Objektbeziehungen 137 Teilnahme Abb. 6.9. Temiire Assoziation Beispiel 6.4.8 (Binare Assoziationen) Da noch sehr viele weitere Beispiele vorkommen werden, hier nur eine Illustration der Notation an ganz einfachen Beispielen, die in Abb. 6.8 dargestellt sind. Die Assoziation "arbeitet fUr" wird von Person zu Firma gelesen. In der anderen Richtung wurde man sie als "beschiiftigt" lesen. In dieser Assoziation spielen Personen die Rolle des Mitarbeiters und Firmen die des Arbeitgebers. Personen konnen in keiner oder einer Firma arbeiten. Dieses Modell unterstellt, dass keine Person mehrere Arbeitsverhiiltnisse eingehen kann. Ob dies so ist, hiingt davon ab, was modelliert wird. Die Multiplizitiiten unterstellen, dass eine Firma mindestens einen Mitarbeiter hat (1 .. *) und dass eine Person fur maximal eine Firma arbeitet. Zwischen Personen gibt es die rekursive Beziehung ,fuhrt", in der maximal ein Chef mehrere Mitarbeiter hat. Jede Person kann einen oder keinen Chef haben. Letzteres ist bei nicht Berufstiitigen oder bei dem Eigentumer einer Firma der Fall. In der anderen Richtung ist diese Assoziation als "berichtet an" zu lesen. In der Assoziation "arbeitet fUr" kann auf die Angabe der Rollennamen verzichtet werden. Ein Directory in einem Dateisystem (UNIX oder MS-DOS) kann keine oder mehrere Dateien enthalten. Eine Person kann kein oder viele Autos besitzen, es konnen aber auch mehrere Person en gemeinsam ein Auto besitzen. Aufgrund der Objektidentitiit kommt ein und dasselbe Objekt hochstens einmal am Ende der Objektbeziehung vor, die von einem Objekt ausgehen. Es kann also nicht sein, dass eine Person ein Auto zu einem gegebenen Zeitpunkt mehrmals besitzt. Multiplizitiiten sind keine nichtssagende "Dekoration" sondern wesentlich fur das Modell. Das Modell in Beispiel 2.5.3 auf S. 32 modelliert z. B. eine Situation, in der ein Auto genau einen Besitzer hat ...... Beispiel 6.4.9 (Ternare Assoziationen) Abbildung 6.9 zeigt ein Beispiel einer terniiren Assoziation: Mehrere Studierende nehmen pro Semester an Lehrveranstaltungen teil. Semester sei dabei das Semester, in dem die Veranstaltung angeboten wird, also z. B. das SS 2001. Studierende konnen mehrfach an einer Lehrveranstaltung teilnehmen . ..... Bemerkung 6.4.10 (Ternare und binare Assoziationen) Jede terniire Assoziation kann durch eine Klasse und drei biniire Assoziationen dargestellt werden. Seien niimlich A, B und C Klassen und X eine terniire Beziehung zwischen diesen dreien. Nach Def. 2.5.1 auf S. 31 ist X ei- 138 6 Modellierung statischer Strukturen Abb. 6.10. Umformung einer temiiren Assoziation ne (spezielle) Klasse, namlich die der Objektbeziehungen zwischen Objekten aus A, B und C. Man kann also ein Klassensymbol fur X verwenden. Urn den Beziehungsaspekt darzustellen, benotigt man dann noch die drei binaren Assoziationen AX, BX und CX. Graphisch ist dies in Abb. 6.10 dargestellt. <OIl Das allgemeine Geheimnisprinzip aus Def. 4.5.19 ist fUr Klassen ganz einfach zu formulieren. Definition 6.4.11 (Geheimnisprinzip) Die internen Eigenschaften einer Klasse sind nach auEen nicht sichtbar, nur die Signaturen von offentlichen Operationen sind nach auEen bekannt. <OIl Es ist nicht in allen objektorientierten Umgebungen so, dass dieses Geheimnisprinzip immer erfUllt ist. Es ist aber in jedem Fall anzustreben. Das Geheimnisprinzip ist ein akzeptiertes Grundprinzip jedes guten Modells. Es hat nicht nur den Aspekt der Sicherheit, sondern auch den der Ubersichtlichkeit: Es solI jeweils nur das sichtbar sein, was tatsachlich zur Nutzung notwendig ist. Bemerkung 6.4.12 (Klasse oder Attrihut) Es ist nicht immer von vorn herein klar, ob es sich bei einem Objekt urn eine Klasse oder ein Attribut handelt. Zu diesem Zeitpunkt konnen hierzu noch keine wesentlichen Hinweise gegeben werden. Dazu ist es notwendig, zunachst einige weitere Begriffe einzufUhren. Damit wird es dann in Kap. 12 moglich, Kriterien hierfUr zu nennen. In vielen Fallen wird es sich dabei urn Design-Entscheidungen handeln. Zum Beispiel ist in der Sprache Smalltalk entschieden worden, dass alle Elemente Objekte sind. So sind auch die elementaren Datentypen in Smalltalk Klassen. In C++ sind diese zwar im Wesentlichen gleichberechtigt mit Klassen, aber man kann z. B. int nicht weiter spezialisieren. <OIl Definition 6.4.13 (Assoziationsklasse) Eine Assoziationsklasse ist eine Assoziation, die auch die Eigenschaften einer Klasse hat. Eine Assoziationsklasse wird durch eine gestrichelte Linie mit der Assoziation verbunden. Das Symbol fUr eine Assoziationsklasse besteht aus 6.4 Assoziationen und Objektbeziehungen 139 «Bedingung» (s.select(Ergebnis.bestanden=true),>size()) <= 1 Abb. 6.11. Ternare Assoziationsklasse dem Klassensymbol, dem Assoziationssymbol und der verbindenden, gestrichelten Linie ..... Assoziationsklassen konnen in Verbindung mit jeder Art von Assoziation vorkommen. Beispiel 6.4.14 (Assoziationsklasse) Abbildung 6.11 ist eine Erweiterung der Abb. 6.9 aus Beispiel 6.4.9. Zujedem Tripel gehort nun ein Ergebnis. Der Name der Assoziationsklasse ist jetzt "Ergebnis" und im Klassensymbol, nicht am Assoziationssymbol notiert. Mit statischen Symbolen kann nicht abgebildet werden, dass es nur ein positives ("bestanden") Ergebnis pro Student und Lehrveranstaltung geben kann. Dies kann aber tiber eine in OCL geschriebene Bedingung formuliert werden, die in der Notiz dargestellt wird ..... Wann verwendet man nun welches Modellierungskonstrukt? Hier ein weiteres Beispiel zur Erliiuterung. Beispiel 6.4.15 (Assoziationen) Ein Unternehmen liisst seine Dienstleistungen dem Zug der Zeit folgend von unabhiingigen Tochtergesellschaften (Business Units) erbringen. Die Zentrale fungiert nur noch als steuernde Holding, die u.a. die gemeinsamen IT-Systeme anbietet. Dort sollen nun die Beziehungen zwischen (Tochter-) Gesellschaft, Kunde und Dienstleitung korrekt abgebildet werden. Die erste Variante zeigt der 1. Teil von Abb. 6.12. Die zweite Variante ist nur eine andere Darstellung der ersten: Der Name der Assoziationsklasse steht jetzt im KlassensymboL Hier sind Kunde und Gesellschaft als Klassen modelliert (die Attribute und Operationen werden nicht gezeigt) und Dienstleistung ist als Attribut der Assoziationsklasse "bezieht" modelliert. Deshalb ist der Namensteil des Klassensymbols in der ersten Variante leer. Diese Variante modelliert die Situation, dass ein Kunde von einer Gesellschaft eine Dienstleistung abnimmt. Es 140 6 Modellierung statischer Strukturen Kunde I* bezieht * I Gesellschaft I Gesellschaft Dienstleistung Kunde I* * bezieht Dienstleistung Kunde Gesellschaft Abb. 6.12. Varianten von Assoziationen r __e_rte_ilt_---"-i* Auftrag '-----_---'Auftraggeber t-*'-----_um_fa_ss_t- - t Dienstleistung Gegen- L -_ _ _ _--' stand erhiil! Auftragnehmer Abb. 6.13. Eine weitere Variante unterstellt ferner, dass eine Dienstleistung nicht unabhiingig von der Assoziation zwischen Kunde und Gesellschaft existiert_ Dies mag der Fall sein, wenn individuelle Dienstleistungen angeboten werden, die auf einen Kunden gezielt ausgerichtet sind. Hiiufiger wird es sich aber urn Dienstleistungen handeln, die wiederholt angeboten werden_ Eine weitere Schwiiche dieses Modells besteht darin, dass ein Kunde von einer Gesellschaft maximal eine Dienstleistung abnehmen kann: Zu jedem Paar aus Kunde und Gesellschaft gibt es eine Objektbeziehung. Es erscheint darum sinnvoll, dies als eine terniire Assoziation zu modellieren, wie es im unteren Teil von Abb. 6.12 gezeigt wird. Das lost das Problem der Existenz von "Dienstleistungsobjekten" tiber die Abnahme vom Kunden hinweg, da diese jetzt eine eigenstiindige Klasse sind. Ein Kunde kann nun auch mehrere Dienstleistungen von einer Gesellschaft erhalten. Gemiig Bern. 6.4.10 kann manjede terniire Beziehung durch eine Klasse und drei biniire Beziehungen ersetzen. Dies ist hier in Abb. 6.13 geschehen. Es bietet sich hier eine Klasse Auftrag an. Das dort beschriebene schematische Vorgehen entspricht hier also auch der typischen Sicht im Anwendungsbereich. 1m Anschluss an diese Diskussion konnte man noch viele weitere fiihren: Was ist, wenn ein Auftrag sich an mehrere Tochtergesellschaften richten kann? Kann ein Auftrag nur tiber eine oder tiber mehrere Dienstleistungen 6.4 Assoziationen und Objektbeziehungen 141 abgeschlossen werden? Hier kommt man auf ein Gebiet, wo nach grundlicher Recherche die Erfahrung und das Wissen des System-Entwicklers einfl~ mussen: Es lohnt sich nicht, uber diese Details ohne konkreten Hintergrund lange zu diskutieren. Sicher ist nur: Wenn sie nicht pleite geht, wird sich die Firma Markterfordernissen anpassen, selbst wenn diese heute als vollig abwegig abgetan werden. Entscheidend ist nicht, dass in diesem statischen Modell genau das aktuelle Verfahren dokumentiert wird. Wichtig ist, dass die Verhiiltnisse im Problemraum erfasst werden und das aktuelle Verfahren durch das Modell unterstutzt wird. Es ist Aufgabe des Entwicklers, dies so zu tun, dass Erweiterungen schmerzlos moglich sind ..... Urn Pfade in Klassendiagrammen zu beschreiben, kann die OCF benutzt werden. Ein Punkt "." zeigt die Verwendung eines Attributwertes oder die Verfolgung einer Assoziation: In Abb. 6.25 z. B. "Person.firma". Je nach Multiplizitiit der Assoziation bezeichnet dies einen skalaren Wert oder eine Menge von Werten. Zur Erinnerung: "." ist die Kurzform der "collect" Operation. Fur die Navigation zu den Assoziationsenden wird die in Def. 5.7.20 eingefUhrte Konvention verwendet: Klassenname mit kleinem Anfangsbuchstaben als Rollenname. Bemerkung 6.4.16 (Multiplizitatsschreibweise) Uber die Schreibweise von Multiplizitiiten gibt es viele verschiedene Ansichten, von denen einige hier referiert werden sollen. 1. contra *: Fur C++ Programmierer ist * ein Multiplikationssymbol, leitet eine pointer Deklaration ein oder bezeichnet den Indirektionsoperator. Deshalb ist Kritik gegen seine Verwendung als Multiplizitiitssymbol vorgebracht worden. Booch argumentierte gegen diese Kritik, dass * einen Unterschied zu einer variablen Kardinalitiit mit Namen ,,n" zum Ausdruck bringt und aus mathematischer Sicht ublich sei. Ich kenne dieses Zeichen aus der Mathematik als Bezeichnung fUr den Faltungsoperator, als Symbol urn einen Dualraum oder eine konjugierte Abbildung zu kennzeichnen, nicht aber im Zusammenhang mit Kardinalitiiten. 2. pro *: Das Symbol ,,*" ist ein ubliches Zeichen, urn andere zu ,,maskieren". Buchstaben wie ,,n" konnen nun als Variable genutzt werden, die an anderer Stelle im Modell definiert und durch Bedingungen eingeschriinkt werden. 3. Rollenzuordnung: Andere Autoren wie Coad (z. B. [CY94]) und Scheer (z. B. [Sch90l) notieren die Multiplizitiiten genau anders herum. Als Argument hierfur wird Folgendes vorgetragen: Eine Multiplizitiit stellt eine Restriktion oder Bedingung an die Assoziation dar. 1m Beispiel in Abb. 6.13 gehoren zu einem Kunden 1 bis n Auftriige. Dies wird nun interpretiert als Bedingung an einen Auftrag: Er gehort zu genau einem Kunden. Aus der anderen Sicht hat ein Kunde 1 bis n Auftriige. Dies ist eine Aussage uber den Kunden. Also sollten die Multiplizitiiten auch an die in diesem Sinne dadurch niiher spezifizierten Klassen geschrieben werden. 142 6 Modellierrnig statischer Strukturen Ich neige aufgrund meiner Ausbildung zu der UML Notation fUr die Multiplizitaten, die in diesem Buch verwendet wird. Coad und Carmichael haben in einem Beitrag fUr den Coad Letter 1996 darauf aufmerksam gemacht, dass es nicht nur um die Multiplizitaten, sondern auch urn die Abhiingigkeiten geht: Welche Klasse hat die Verantwortung fUr die Assoziation, welche pflegt sie? Dieser Aspekt wird im Zusammenhang mit dem Design in Abschn. 13.14.1 besprochen. Es ist zwischen den Multiplizitaten und den Verantwortungen zu unterscheiden. Die Multiplizitat spezifiziert eine Bedingung: Eine Kardinalitat 1 besagt, dass es an diesem Ende der Assoziation stets genau ein Objekt gibt. Damit ist aber noch nicht entschieden, wo die Verantwortung dafiir liegt, dies auch sicherzustellen. Diese Frage wird im Kap. 13 behandelt. ~ 6.5 Aggregation und Komposition Definition 6.5.1 (Aggregationssymbol) Eine Aggregation ist nach Def. 2.5.5 auf S. 33 eine Spezialform einer binaren Assoziation, in der die Objekte der einen Klasse ein Ganzes und die dazu in Beziehung stehenden Objekte der anderen Klasse dessen Teile bilden. Eine Aggregation wird durch eine Raute am Ende der Assoziation bei der Klasse, deren Objekte als "Ganzes" fungieren, dargestellt. ~ Beispiel 6.5.2 (Stiicklisten) Ein typisches Beispiel fUr Aggregationen sind Stiicklisten-Strukturen, wie z. B. in Abb. 1.6 gezeigt. Eine gute Moglichkeit diese darzustellen, ist das sogenannte Composite pattern, das nach der EinfUhrung der Generalisierung und Spezialisierung skizziert wird. ~ Beispiel 6.5.3 (Assoziation und Aggregation) Ein Menii kann sich aus mehreren Gangen zusammensetzen, z. B. Vorspeise, Hauptgericht, Nachspeise. Zu jedem Gang gehoren verschiedene Lebensmittel, die entweder direkt diesen Gang ausmachen, wie z. B. ein Stiick Obst als Nachspeise. Es kann sich aber auch um ein Gericht handeln, zu dem es dann Zubereitungshinweise gibt, die hier als Rezept bezeichnet seien. Ein Rezept besteht aus verschiedenen Lebensmitteln (den Zutaten) und Hinweisen, wie diese zu verarbeiten sind. Letztere bezeichnen wir als Zubereitung. Abbildung 6.14 zeigt ein exemplarisches Objektdiagramm, Abb. 6.15 das Klassendiagramm. Die Beziehung "besteht aus" zwischen "Menii" und "Gang" wird als Aggregation modelliert. In diesem Modell ist ein Menii etwas, was man bestellen kann. Das Zubereiten eines Meniis umfasst das Zubereiten aller Gange. Das Servieren eines Meniis besteht aus dem Servieren der einzelnen Gange. Ein Gang besteht nicht wiederum aus Meniis. Wenn ein Gang aus mehreren Teilen besteht, so gehoren diese ganz selbstverstandlich auch zum Menii, 6.5 Aggregation und Komposition I Min21rQ!l:E~§] I I I Mittag:Mahizeit I I I Qbst:PQ§itiQn 143 I Q§J IS~cle: i I Kiwi:Lebe!ll!mittel I~ I~ I,soagni·l.b~m!1 Sgaghetti I VO[!\lQe:P~in I ~-§] I I 10IiVenbl:!.e!l!!n!![!]ittel I 11 5kg I TQmalll:Le!l!lnsmi!l!!1 I Ize~n I !:rzmU1l;~I.&nsie I I I I KnQblaygh:Lebensmi!!e1 I I Abb. 6.14. Menii - Objektdiagramm besteht aus Rezept beschreibt 1." ~ Gang ___e,m_~· _____t_...~ ~Mm Menge Abb. 6.15. Menii - Klassendiagramm die Beziehung ist also auch transitiv. Die Assoziation "beschreibt" zwischen Rezept und Gang ist keine Aggregation. Die Assoziation "enthiilt" zwischen "Gang" und "Lebensmittel" konnte auf den ersten Blick auch als Aggregation modelliert werden. Hier wurde aus folgenden Grunden dagegen entschieden: Ein Lebensmittel kann in mehreren Giingen vorkommen. Eine Multiplizitiit * bei der Raute einer Aggregation ist moglich, aber selten sinnvoll. Das Modell sagt aus, dass in einem Gang eine gewisse Menge eines Lebensmittels enthalten ist. Es muss also nicht das ganze Objekt sein, wenn es sich bei dem Objekt um so etwas wie einen Salatkopf, eine Lammkeule etc. handelt .... Bemerkung 6.5.4 (Assoziation vs Aggregation) 1st man im Zweifel, ob es sich um eine Assoziation oder speziell eine Aggregation handelt, so soUte man konsequent die Eigenschaften abprufen (s. Abb. 6.16): • Neigt man dazu, die Assoziation mit Bezeichnungen wie: ,,ist Teil von" zu benennen? • Werden Operationen auf dem Ganzen typischerweise auch (automatisch) auf das Ganze angewandt? • Gibt es Eigenschaften, die sich vom Ganzen auf die Teile ubertragen? 144 6 Moclellierung statischer Strukturen B B ist Teil von A Antisymmetrie Obertragung von Operationen Abb. 6.16. Eigenschaften cler Aggregation • 1st die Assoziation transitiv? • 1st die Assoziation antisymmetrisch, d.h. kann man die Rollen nicht sinnvoll vertauschen? Werden alle diese Fragen mit "ja" beantwortet, so wird man die Beziehung als Aggregation modellieren, sonst als Assoziation. In der Analyse macht es zunachst nur einen geringfiigigen Unterschied, ob man eine Beziehung als Assoziation oder als Aggregation modelliert. In der Diskussion der Bedeutung (Semantik) der Aggregation in spateren Kapiteln und in Design und Implementierung wird sich zeigen, dass dies sehr wohl eine Entscheidung ist, die bewusst getroffen werden muss. Dies gilt insbesondere, wenn es sich urn eine Komposition handelt. 1st dies nicht der Fall, so kann man in Zweifelsfallen bedenkenlos als Assoziation modellieren. <l1li Definition 6.5.5 (Komposition, Kompositionssymbol) Die Komposition (composition) ist eine Form der Aggregation, bei der die Existenz der Teile von der des Ganzen abhangt. Die Multiplizitat der Komals eins sein. Die Komposition kann nach dem positionsrolle kann nicht gro~e Erzeugen nicht mehr verandert werden. Teile mit Multiplizitat > 1 konnen hinzugeftigt werden; sie existieren dann genau so lange wie das Ganze. Wird das Ganze zerstort, so werden auch alle Teile zerstort. Innerhalb einer Komposition konnen zusatzliche Assoziationen definiert werden, die au~erhlb der Kompositionssymbol Komposition keine sinnvolle Interpretation haben. Das ist ein ein Aggregationssymbol mit ausgefiillter (schwarzer) Raute. <l1li Komposition kann statt tiber bin are Assoziationssymbole auch tiber die Schachtelung der Symbole der beteiligten Elemente in dem Klassensymbol des Ganzen dargestellt werden. Die Rolle eines so geschachtelten Elements wird durch die Notation Rollenname:Klassenname 6.5 Aggregation und Komposition 145 Klasse Attribut Operation "I Abb. 6.17. Komposition: Klasse und Elemente 0 .. 1 Value '-_r--1template argument nested 0 .. 1 extension points members Members +isTypeScope:Boolean +visibility:Visibility +direction:(provide, require} J-__S_i=..gna_I_S_ _-t "ignals +direction:{receive,send} 0." Abb. 6.18. Einige Kompositionen angegeben. Komposition kann auf alle ,,klassenartigen" Modellelemente wie Klassen, Typen, Knoten, Prozesse ... angewandt werden. Ein Objekt kann in einer gewissen Anzahl in einem zusammengesetzten Objekt vorkommen (M ultiplizitat am Aggregationsende beim Teil). Abbildung 6.17 zeigt beide Darstellung an einem kleinen Ausschnitt aus dem Metamodell der UML. Klassen bestehen aus Attributen und Operationen. Anzahl wird als ganze Zahl in kleiner Schrifttype in der oberen rechten Ecke des Klassensymbols notiert etwa 3, 5, 7 .. 13, 19 .. *. Dies zeigt, wieviele Instanzen cler Klasse zu einem Zeitpunkt innerhalb einer Komposition existieren konnen. Das Symbol * bedeutet, dass es keine obere Grenze gibt; alleine bedeutet es keines oder beliebig viele. Der default ist "viele". Es gibt eine natiirliche KompositionsKlasse, die das ganze Modell umfasst, das System also der Welt gegeniiber reprasentiert. Ein weiteres Beispielliefert Abb. 6.18 aus dem Metamodell der UML. Bemerkung 6.5.6 (Komposition: by value oder by reference) In einer Programmiersprache, die Wert-Semantik und ReJerenz-Semantik kennt, wird eine Komposition meist iiber Werte realisiert, wahrend Aggregationen und Assoziationen iiber pointer realisiert werden. Insofern gibt die Entscheidung, wie eine Situation modelliert wird, bereits einen Implementierungshinweis. Andererseits ist es Aufgabe einer Implementierung, die Regeln des Anwendungsbereiches korrekt und effizient abzubilden. Eine entscheidende Voraussetzung dafiir ist die korrekte Modellierung der Verhaltnisse im An- 146 6 Modellierung statischer Strukturen wendungsbereich. Die hier priisentierten Darstellungsmoglichkeiten ermoglichen eine priizise Formulierung auch subtiler Unterschiede. ~ 6.6 Generalisierung und Spezialisierung Abstraktion ist ein wesentliches Merkmal jedes Modellierungsprozesses. Urn aus einem allgemeinen durch Abstraktion gewonnenen Modell wieder konkrete Aussagen zu gewinnen, muss spezialisiert werden. Abstraktionen konnen im Problemraum direkt vorkommen oder bei der Modellierung herausgearbeitet werden. Definition 6.6.1 (Generalisierungssymbol) Eine Klasse A ist eine Oberklasse oder Verallgemeinerung einer Klasse B, wenn jedes Objekt aus Bauch ein Objekt in A ist. B hei:Et dann auch Unterklasse oder abgeleitete Klasse von A. Das Generalisierungssymbol oder GenSpecsymbol ist eine durchgezogene Linie mit einem leeren Dreieck als Pfeilspitze an der allgemeineren Klasse. Au:Eer auf Klassen kann Generalisierung und Spezialisierung auch auf Pakete und Anwendungsfiille angewandt werden. ~ Eine Unterklasse hat also aIle Attribute und aIle Operationen ihrer Oberklasse(n). Bemerkung 6.6.2 (Verallgemeinerung und Vererbung) Man sagt hiiufig, dass eine Oberklasse ihre Eigenschaften an die spezialisierteren Unterklassen "vererbt". Diesen Aspekt der Vererbung wird aber erst beim Design und bei der Behandlung der Implementierung in den Vordergrund treten. In der Analyse geht es nicht in erster Linie urn Wiederverwendung mittels Vererbung, sondern urn das Identifizieren gemeinsamer Eigenschaften. 1m Metamodell der UML ist ein Klasse GeneralizableElement definiert, die Oberklasse aller UML-Elemente ist, die diesem Mechanismus unterliegen. ~ Beispiel 6.6.3 (GenSpecsymbol) So kann es sein, dass in einem Unternehmen von "Geschiiftspartnern" gesprochen wird, wenn von ,,Kunden" oder "Lieferanten" die Rede ist. Abbildung 6.19 zeigt diese Beziehung einmal mit zwei Verallgemeinerungspfeilen und einmal als Baumdarstellung. Die Beziehung wird durch eine durchgezogene Linie mit einer nicht ausgefiillten, dreieckigen Pfeilspitze an der Oberklasse dargestellt. ~ Beispiel 6.6.4 (Das Composite pattern) Aggregationen, wie sie z. B. in Stiicklisten Anwendungen vorkommen, gehen in manchen Fiillen tiber viele Ebenen. Solche Strukturen konnen oft hervorragend durch das sogenannte "Composite pattern" dargestellt werden (s. 6.6 Generalisierung und Spezialisierung 147 Abb. 6.19. Generalisierung/Spezialisierung Conv»nent Operation() Add(Component) Remove(Compooent) Getlterator():herator<Component> lretumo; I I I Leal IOperationO I J 0 I ComposIte I OperationO Add(Component) Remove(Component) GeHterator():herato«Component> iter = GetlteratorO for(ite;~=O+) ( ~er.CuntO·>paio; ) return Iterator iiber aile Components Abb. 6.20. Das Composite pattern [GHJV94] und Abschn. 12.9). Das allgemeine Schema zeigt Abb. 6.20. Ein Beispiel einer solchen Struktur wurde bereits in Beispiel 1.5.1 vorgestellt. Nun wird die in Abb. 1.5 auf S. 12 dargestellte Struktur auf dieses pattern abgebildet. Das Ergebnis zeigt Abb. 6.21. Ohne weitere Vorkehrungen gehen dabei allerdings einige der Restriktionen verloren ..... Die vorstehenden Beispiele zeigen die Art von GenSpec-Beziehung, die am einfachsten zu verstehen ist. Die Klasse "Geschiiftspartner" enthiilt alle Attribute und Operationen, die sowohl Kunden als auch Lieferanten haben. Kunden und Lieferanten haben aber auch Unterschiede, die verschiedene Klassen rechtfertigen. So wird man Kunden wegen der Uberschreitung eines Zahlungsziels mahnen, Lieferanten wegen Uberschreiten eines Zahlungstermins. Unterstellt ist hier eine "oder"-Spezialisierung: Ein Geschiiftspartner ist entweder ein Kunde oder ein Lieferant, die geht so aus der Notation aber nicht hervor. Dies kann aber durch eine Bedingung {disjoint} (disjunkt) spezifiziert werden. Spezialisierungen konnen sich auch iiberlappen. So kann ein Geschiiftspartner sowohl ein Kunde als auch ein Lieferant sein. Kaffeefirmen verkaufen inzwischen nicht nur (auch noch?) Kaffee, sondern auch noch viele 148 6 Modellierung statischer Strukturen /Component I Controller r-I CPU rI Grafikkarte f-I Platte rI Floppy r-I CD-ROM f-- I I I I I I I NetzteU LiiIter Display Speicher Register Logic Bus I I fI ff- . contains I Composite I j I I Malnboard I I PC I I / ALU / L Gehiuse I Abb. 6.21. Ein Beispiel fur das Composite pattern andere Waren. Ein Lieferant solcher Artikel konnte auch den Kaffee fur seine Firma bei eben dieser Kaffeefirma kaufen und damit gleichzeitig Kunde sein. Eine solche Situation kann durch die Bedingung {overlapping} (uberlappend) am GenSpecsymbol zum Ausdruck gebracht werden. In den meisten Programmiersprachen wird dies allerdings nicht unterstutzt. Die moglichen Bedingungen an Spezialisierungen fasst die folgende Definition zusammen. Definition 6.6.5 (Bedingungen an Spezialisierungen) In der UML sind die folgenden Bedingungen an GenSpec-Beziehungen vordefiniert: 1. overlapping (uberlappend): Ein Objekt der Oberklasse kann Objekt meh- rerer Spezialisierungen sein. 2. disjoint (disjunkt): Ein Objekt der Oberklasse kann Objekt hochstens einer Spezialisierung sein. Wird nichts spezifiziert, so sind die Spezialisierungen disjunkt. 3. complete (vollstandig): Alle Spezialisierungen sind spezifiziert, unabhangig davon, ob sie in diesem Diagramm gezeigt werden oder nicht. 4. incomplete (unvollstandig): Es ist bereits bekannt, dass es weitere Spezialisierungen gibt, diese sind aber noch nicht spezifiziert oder hier nicht dargestell t. Neben der bisher behandelten "oder"-Spezialisierung kann es aber auch vorkommen, dass eine Klasse gleichzeitig in verschiedene Richtungen spezialisiert wird. Diese Situation tritt in verschiedenen ,,verkleidungen" auf und wird deshalb im folgenden Beispiel ausfiihrlich diskutiert. Beispiel 6.6.6 ("und"-Spezialisierung) Fortbewegungsmittel konnen (u. a.) nach Antriebsart und Einsatzgelande unterschieden werden. Eine Moglichkeit hierzu zeigt Abb. 6.22. Nach Einsatz- 6.6 Generalisierung und Spezialisierung 149 Einsatzgeiande Luftfortbewegungsmittel Segelschiff Abb. 6.22. "und"-Spezialisierung von Fortbewegungsmitteln f----I>I Fortbewegungsmittel Abb. 6.23. Rekonstruktion konkreter Klassen gelande kann man z. B. Land-, Luft- und Wasserfortbewegungsmittel unterscheiden. Mogliche Antriebsarten sind Benzin- oder Dieselmotor, Windkraft oder Turbine. Nach welchem Kriterium die Spezialisierung erfolgt, wird durch den Diskriminator (s. Def. 6.6.7) am GenSpecsymbol dargestellt. Hier ist die Situation ganz anders als bei der "oder"-Spezialisierung. Zwar gilt auch hier: Jedes Schiff ist ein Fortbewegungsmittel etc. Aber jede Unterklasse enthalt nur einen Teil der Attribute und Operationen, die ein konkretes Fortbewegungsmittel benotigt. Jede Unterklasse reprasentiert einen obligatorischen Aspekt eines Fortbewegungsmittels. Eine konkrete Klasse muss aus mehreren dieser Aspekte rekonstruiert werden. Dies ist fiir einige Falle in Abb. 6.23 geschehen. Die Klasse Fortbewegungsmittel ist von diesen Blattklassen des Spezialisierungsbaumes auf zwei Wegen zu erreichen. Die Konvention in der UML ist, dass die Attribute und Operationen von Fortbewegungsmittel in diesen Blattklassen nur einmal vorkommen. Dies entspricht dem C++ Begriff der virtuellen Vererbung. Nicht spezifiziert ist, wie Konflikte aufge- 150 6 Modellierung statischer Strukturen lost werden, wenn Operationen auf den beiden Wegen zu einer Blattklasse iiberschrieben werden. Der aus meiner Sicht bessere Weg, eine solche Situation zu modellieren, ist in Abb. 6.23 dargestellt. Die verschiedenen "und"Spezialisierungen aus Abb. 6.22 sind nun auf der gleichen Hierarchie-Ebene wie Fortbewegungsmittel modelliert. Es wird von vorneherein klargestellt, dass alle diese Klassen abstrakt sind. Das hiitte man allerdings auch schon in Abb. 6.22 tun konnen. Wesentlich erscheint mir, dass keine wiederholte Spezialisierung mehr auftreten kann und dass die entkoppelten, orthogonalen Oberklassen flexibel zur ,,Beimischung" geeigneter Eigenschaften verwandt werden konnen. So kann ein Segelschiff mit einem Dieselmotor als Hilfsmotor durch zusiitzliche Spezialisierung von "Dieselgetrieben" ohne Probleme konstruiert werden ..... Manchmal ist es sinnvoll den impliziten Aufziihlungstyp, der hinter verschieden en Spezialisierungen steckt, im Diagramm anzugeben; ein solches Attribut ist ein Diskriminator und wurde bereits in Abb. 6.22 benutzt: "Einsatzgeliinde" und ,,Antriebsart". Definition 6.6.7 (Diskriminator) Ein Diskriminator (discriminator) ist der Name einer Zerlegung einer Oberklasse in Unterklassen. Die Spezifikation eines Diskriminators erfolgt durch einen String, der an das GenSpecsymbol oder durch eine gestrichelte Linie iiber die entsprechenden GenSpecsymbole geschrieben wird ..... Eine gemeinsame Vorgiingerklasse wird nur einmal geerbt, auch wenn sie in verschiedenen Pfaden auftritt (im C++ Sprachgebrauch eine virtuelle Basisklasse). Verschiedene sprachabhiingige Optionen, wie wiederholte Vererbung oder virtuelle Vererbung, public, protected oder private in C++ konnen als Textanmerkungen an der Vererbungslinie angebracht werden. Fiir iiberlappende Vererbung gibt es kein spezielles Symbol, da sie bei Mehrfachvererbung implizit vorliegt und ansonsten ohne Bedeutung ist. Mehrfachspezialisierung kann auch so auftreten, dass eine Unterklasse zwei Oberklassen ohne gemeinsame Vorgiinger hat, wie in Beispiel 6.6.6 gezeigt wird. Die dort benutzte Form des ,,mixins" (vgl. [Bo094a]), auch Aspekt genannt (z. B. in [KGZ93]), ist ein hiiufig niitzlicher Einsatz von Mehrfachspezialisierung. Ein hiiufig praktizierter Stil strebt an alle nicht-Blattklassen als abstrakte Klassen zu modellieren. Gibt es doch eine konkrete Klasse auf einer anderen Ebene, so kann dies leicht behoben werden, indem eine neue Unterklasse im Sinne von ,,keine der anderen Unterklassen" eingefiigt wird, die ehemals konkrete Klasse wird dann als abstrakte definiert. Die bisher beschriebenen Symbole, zusammen mit den Notizen fiir verschiedene Programmiersprachen, reichen aus, urn Klassenspezifikationen in den meisten Sprachen zu generieren. Manchmal mochte man aber auch die Werte, die Objekte oder Objektbeziehungen annehmen konnen, einschriinken. Eine Bedingung ist eine Restriktion an Werte, die durch einen beliebigen Ausdruck an einer Klasse oder Assoziation formuliert werden kann. 6.7 Abhiingigkeiten und weitere Beziehungen Gaschiftspartner (abstract) I 151 Singleton (Autor; GoF) ·Singleton instance Composite #SingletonO; +ereateObjectO:Singleton getiteratorO:lterator(abstract} ... Mitglied Vereln L ___Y-;.....V"io~rstZ;· Person (Subset) ;end,~(ri) -A'rbei.tnhmT~ Chef 0,1 (Person.ArtJeitgeber; Person. Chef.ArtJeitgeber) MrtartJeiter ... beschaftigt Abb. 6.24. Klassenattribute und Bedingungen Eine Bedingung kann als Text in geschweiften Klammern neben die Objekte oder in einer Notiz fiir die betroffenen Elemente geschrieben werden. Fiir binare Bedingungen kann eine gestrichelte Linie zwischen den betroffenen Elementen gezogen werden, die mit der Bedingung in geschweiften Klammern beschriftet wird. Navigations-Ausdriicke sind gut geeignet, urn Bedingungen auszudriicken (s. Abb. 6.24). Notizen konnen auch fiir beliebige Kommentare in Diagrammen benutzt werden oder urn den Implementierungs-Code fUr Operationen zu zeigen. 6.7 Abhangigkeiten und weitere Beziehungen Definition 6.7.1 (Abhangigkeit) Eine Abhiingigkeit (dependency) ist eine Beziehung zwischen Modellelementen, die sich direkt auf die Elemente bezieht und im Unterschied zu Assoziationen keine Objekte benotigt, urn eine Bedeutung zu haben. Sie zeigt eine Situation, in der eine Anderung des Ziel-Elements eine Anderung der Quelle erforderlich machen kann. Abhangigkeiten werden durch einen gestrichelten Pfeil dargestellt. Der Pfeil kann mit einem Stereotyp wie z. B. «friend» oder einem Namen beschriftet werden. ~ Abbildung 5.2 zeigt die «import»-Beziehung zwischen Paketen. Der Pfeil zeigt bei Abhangigkeiten immer in der Richtung, in der man die Bezeichnung liest, hier also in Richtung von ,,importiert". 1m Allgemeinen sind Redundanzen in Klassenmodellen zu vermeiden; manchmal ist es aber niitzlich, redundante Werte oder Assoziationen zu zeigen, die aus anderen rekonstruiert werden konnen. 152 6 Modellierung statischer Strukturen beschiiftigt Person geburtsdatum:Date lalter {alter = aktueliesDatum-geburtsdatum} !beschiiftigt {Person. firma = Person.abteilung.firma} I I offset I {offset= (Maschine.offset-Baugrupp).offset) +(Baugruppe.offset-Bauteil.offset)} Abb. 6.25. Abgeleitete Elemente Definition 6.7.2 (Abgeleitetes Element) Ein abgeleitetes Element ist ein Modellelement, das zu jedem Zeitpunkt aus anderen rekonstruiert werden kann. Ein abgeleitetes Element wird durch den Prefix "/,, vor dem Namen gekennzeichnet. In einer Bedingung wird beschrieben, wie das Element hergeleitet wird. Die Elemente, aus denen das Element rekonstruiert werden kann, konnen durch Abhiingigkeiten dargestellt werden, die mit dem Stereotyp «derived» (abgeleitet) beschriftet sind. Die wichtigsten Elemente, die in dieser Art vorkommen, sind Attribute, Assoziationen und Klassen ..... Beispiel 6.7.3 (Abgeleitete Elemente) Abbildung 6.25 zeigt Beispiele fUr abgeleitete Klasse, Attribut und Assoziation. Die Assoziation ,,/beschiiftigt" im oberen Teil ist redundant, sie kann aus der Assoziation "beschiiftigt" zwischen "Person" und ,,Abteilung" rekonstruiert werden. 1m unteren Teil sind die Klasse ,,jOffset" und die Assoziation ,,/NetOffset" abgeleitet: Sie lassen sich jederzeit aus den relativen Offsets innerhalb der iibergeordneten Klassen rekonstruieren. Ein Beispiel fUr ein abgeleitetes Attribut kam bereits friiher vor: Das Alter einer Person kann jederzeit aus dem Geburtsdatum und dem aktuellen Datum ermittelt werden . .... Eine Verfeinerungs-Beziehung zwischen zwei Elementen A und B zeigt, dass B durch A genauer oder vollstiindiger spezifiziert wird. Dies ist eine spezielle Abhiingigkeit. Beispiele fUr Verfeinerungen sind: • Eine Klasse, die einen Typ realisiert. • Eine Klasse im Design, die eine Klasse aus der Analyse genauer spezifiziert. • Die genauere Spezifikation von Import-Beziehungen zwischen Paketen durch Zusammenarbeitsdiagramme der beteiligten Klassen. 6.7 Abhangigkeiten und weitere Beziehungen 153 • Ein Konstrukt, wie z. B. ein Entwurfsmuster oder ein Typ und seine Implementierung . • Die Implementierung eines allgemeines Konstruktes durch eine im Kontext besonders effiziente Implementierung. Verfeinerungen werden durch ein Abhangigkeitssymbol mit dem Stereotyp «Verfeinerung» oder «refinement» dargestellt. Bemerkung 6.7.4 (Konfigurationsmanagement) Abhiingigkeiten konnen auch zur Darstellung von Konfigurationen verwendet werden. Der Stereotyp «become» stellt z. B. eine zeitliche Entwicklung dar. So kann die Entwicklung von Versionen oder ein Status wie Entwicklung, Integration oder Produktion dargestellt werden .... Die Organisation grol&er Klassendiagramme erfolgt durch Pakete. 1m hier betrachteten Kontext statischer Strukturen gehoren zu einem Paket Klassen und Beziehungen (Assoziationen, Aggregationen, GenSpec-Beziehungen, Abhiingikeiten). Pakete organisieren aber nicht nur die Sicht, in der sie zuerst erscheinen (hier das Klassendiagramm), sondern das ganze Modell. Auch Zustandsdiagramm und nach entsprechender Realisierung der Code einer Klasse gehoren also zu dem Paket, in dem sich die Klasse befindet. Bemerkung 6.7.5 (Paket und Assoziation) Die Zusammenfassung von Klassen zu einem Paket stellt keine neuen Assoziationen zwischen den beteiligten Klassen her. ... Pakete konnen geschachtelt werden. Jede Klasse hat aber ein Paket, zu dem sie direkt gehort. Urn eine Klasse in einem anderen Paket anzusprechen, wird ein Pfadname "Paketname::Klassenname" benutzt. Der Name einer Klasse ist pro Paket eindeutig. Ein Paket definiert einen GUltigkeitsbereich, in C++ Terminologie einen Namensraum (namespace). Wie Pakete gebildet werden, hat keinerlei syntaktische Bedeutung. Sinn volle Pakete haben aber im Modell eine Bedeutung. Sie bilden Teile des Anwendungsbereiches oder der Architektur des Systems abo Die in Kap. 4 entwickelten Kriterien Kopplung und Zusammenhalt miissen bei der Bildung von Paketen beachtet werden. Bemerkung 6.7.6 (Konfigurationsmanagement) Pakete sind oft gut geeignete Einheiten fur ein Konfigurationsmanagements. Durch die enge Kopplung zwischen den Klassen eines Pakets wird man diese oft nur gemeinsam iindern .... Pakete werden oft dazu benutzt die Grobstruktur eines Systems darzustellen. Jedes Paket kann dann in einem Klassendiagramm detailliert dargestellt werden. Eine erste Strukturierung dieser Art kann bereits bei der Analyse von Anwendungsfiillen erfolgen. Klassen, die Anwendungsfiille aus einem Paket 154 6 Modellierung statischer Strukturen Abb. 6.26. Pakete (Baumdarstellung) von Anwendungsfiillen unterstutzen, werden dann im Klassenmodell ebenfalls diesem Paket zugeordnet. Diese Struktur kann sich aber im Laufe der Entwicklung noch mehr oder weniger stark veriindern. Abhiingigkeiten zwischen Paketen werden wie alle Abhiingigkeiten durch gestrichelte Pfeile dargestellt; dabei zeigt der Pfeil vom nutzenden Paket auf das genutzte, siehe Abb. 5.2. Ein Paketdiagramm ist ein Klassendiagramm, das nur Pakete zeigt. Die Anzeige der Klassen unterbleibt in diesem Fall. Die Zerlegung eines Paketes in kleinere Pakete kann in zwei Wei sen dargestellt werden: Abbildung 5.2 auf S. 111 zeigt die Schachtelung von Paketen, Abb. 6.26 verwendet eine Baumdarstellung. Da Pakete nicht notwendig Instanzen haben, wird dazu keine Aggregation verwendet, sondern an die Stelle der Raute tritt das Zeichen EEl. Die Art eines Pakets wird durch seinen Stereotyp (z. B. facade, framework, system) spezifiziert. Ein Paketsymbol, in dem die Bestandteile detailliert als Klassendiagramm etc. dargestellt werden, ist eine Form der Darstellung der Teilsystems (s. Abb. 9.5 auf S. 207). 6.8 Weitere Notationen fUr Klassen In Kap. 2 wurden bereits Akteure von anderen Klassen unterschieden und mit dem Stereotyp «Akteur» gekennzeichnet. In diesem Abschnitt werden einige weitere Modellierungsmoglichkeiten vorgestellt. Definition 6.8.1 (Template-Klasse) Eine Template-Klasse oder kurz Template ist eine durch Typen oder Klassen parametrisierte Klasse. Fur jede als Parameter eingesetzte Typenkombination liefert ein Template eine Klasse. Das Symbol fur eine Template-Klasse ist ein Klassensymbol, das auf der rechten oberen Ecke ein gestricheltes Rechteck mit den Template-Parametern enthiilt, wie in Abb. 6.27 gezeigt. .... 6.8 Weitere Notationen fur Klassen 155 ,---- T I \TSet I TSet<Kunde> I TSet<lnI> Abb. 6.27. Template- oder parametrisierte Klasse Die Container-Klasse TSet in Abb. 6.27 ist ein typisches Beispiel fUr eine Template-Klasse. Aufgrund der immer unterstellten Objektidentitat konnen fUr jede Klasse oder elementaren Datentyp spezielle Container aus TSet<T> erzeugt werden, wie dies im Beispiel fUr int und Kunde dargestellt ist. Die gestrichelten Pfeile deuten die Abhangigkeit an: TSet<Kunde> und TSet<int> sind aus TSet<T> erzeugt worden. Man kann dies als Instanziierung oder Verfeinerung lesen. Definition 6.8.2 (utility) Ein utility (Versorger) ist eine Zusammenfassung globaler Variabler und Funktionen zu einer Klasse. Die Attribute und Operationen eines utilities sind Klassenattribute bzw. Klassenoperationen. Ein utility wird durch den Stereotyp «utility» gekennzeichnet. ~ Beispiel 6.8.3 (utility) Eine Klasse in C++, die nur statische data member und member functions hat, ist ein utility. Ein typisches Beispiel ist die Klasse "Task" aus [Str94a]: class Task { public: static void schedule(int); // ... private: static Task* chain; // ... } Auf diese Weise wird vermieden, den globalen Namensraum unnotig zu fUllen. Namenskonflikte werden vermieden. Au~erdm kann der Zugriff auf die Variablen durch geeignete Operationen sicher kontrolliert werden. ~ Der durch utilities beschriebene Stil ist auch in Smalltalk ublich und verbreitet. Definition 6.8.4 (Classifier) 1m Metamodell der UML ist Classifier die Generalisierung von Klasse, Typ, Schnittstelle, K omponente, und Teilsystem. ~ 156 6 Modellierung statischer Strukturen Der Begriff "Classifier" wird in der Dokumentation der UML oft benutzt, urn Aussagen iiber aIle diese Arten von Modellelementen zu formulieren. In diesem Buch wird er fast nur im Abschn. B verwandt. 6.9 Weitere N otationen fur Assoziationen In verschiedenen Situationen benotigt man weitere Notationen, urn bestimmte Eigenschaften von Assoziationen zum Ausdruck zu bringen. In Def. 6.4.7 wurden die Kardinalitaten und Multiplizitaten von Rollen in einer Assoziation eingefiihrt. 1st die Kardinalitat gro~e als 1, so konnen die Objektbeziehungen eine Ordnung haben. Definition 6.9.1 (Geordnete Assoziation) Eine Rolle einer Assoziation heilSt geordnet, wenn die Objekte an diesem Ende der Assoziation eine spezifizierte Reihenfolge haben. Dies wird durch die Bedingung {ordered} (oder auch deutsch {geordnet}) gekennzeichnet. Eine Assoziation mit einer geordneten Rolle heifbt geordnete Assoziation . • Objekte erscheinen in der Praxis haufig sortiert. Das heifbt nicht, dass es dann zwingend eine geordnete Assoziation gibt. Die {ordered} Eigenschaft bezieht sich auf eine Eigenschaft der Menge der Objekte am jeweiligen Ende der Assoziation, die im Anwendungsbereich identifiziert wurde. Beispiel 6.9.2 (Geordnete Assoziation) Die Assoziation zwischen einem Hauptfenster einer MDI Anwendung unter MS-Windows und dessen child windows ist geordnet: Die Fenster konnen sich iiberlappen, und so wird festgehalten, welches oben ist. Selbst wenn die child windows dann angeordnet werden, bleibt diese Reihenfolge und das aktive Fenster i.d.R. erhalten und wird weiter benotigt (z. B. wenn sie wieder iiberlappend dargestellt werden, oder wenn mit Funktionstasten von einem in das nachste gewechselt werden solI). Wenn festgelegt wird, dass die Auftrage eines Kunden nach Eingang abgearbeitet werden sollen, so kann dies Anlass zu einer geordneten Assoziation zwischen Kunde und Auftrag geben .• Definition 6.9.3 (Qualifizierte Assoziation) Seien X und Y Klassen, A eine binare Assoziation zwischen X und Y. Eine qualiJizierte Assoziation ist ein Attribut oder eine Attributkombination einer binaren Assoziation A, durch die die Menge der Objekte aus Y, die mit einem Objekt aus X durch A verbunden sind, partitioniert wird. Haufig wird durch einen Qualifier zu jedem x aus X und jedem Wert des Qualifiers hochstens ein Objekt aus Y identifiziert. In diesem Fall ist der Qualifier also eindeutig innerhalb des Kontextes, der durch ein Objekt aus X definiert wird. Eine Assoziation mit Qualifier wird qualiJizierte Assoziation genannt .• 6.9 Weitere Notationen fur Assoziationen 157 Variante 1 ~reday ~-'I, . contains . ____ F_ne____ ~ Variante 2 I. contains 0, 1 1'---____F1_Ie______ ......J Abb. 6.28. Qualifizierte Assoziation: Dateisystem Variante 1 beschaftigt Firma Person '------------' '-~ I m~arbeitu Variante 2 Firma mitarbeitemummer bescMftigt I Person I Abb. 6.29. Qualifizierte Assoziation Firma - Mitarbeiter Dieses Konzept liisst sich auch auf n-are Assoziationen verallgemeinern, es ist dort aber meist von geringem Nutzen. Das Konzept der qualifizierten Assoziation sei an einigen Beispielen eriautert: Beispiel 6.9.4 (Beispiele fiir Qualifier) In einem UNIX -System kann es eine Datei unter verschiedenen Namen in verschiedenen Verzeichnissen geben (links). Welcher dieser Namen ist nun der Name der Datei? Die Beziehung zwischen Verzeichnis (Klasse Directory) und Datei (Klasse File) wiirde man in einem erst en Entwurf vielleicht wie in Abb.6.28, Variante 1, modellieren. Durch Einfiihren eines Qualifiers ,,filename" erhalt man eine *:0,1 Assoziation in Variante 2. Der Qualifier ,,filename" ist eindeutig innerhalb eines Verzeichnisses. Innerhalb eines Verzeichnisses wird durch "filename" eine Datei eindeutig identifiziert. Verzeichnisiibergreifend ist dies falsch. Eine ganz analoge Rolle spielt eine Mitarbeiternummer in dem Diagramm in Abb. 6.29. Eine Person kann in mehreren Firmen beschaftigt sein. Eine Mitarbeiternummer ist daher weder ein Attribut von Firma noch von Mitarbeiter, sondern ein Attribut der Assoziation "beschiiftigt", wie in Variante 1 dargestellt. Variante 2 zeigt die Modellierung mit einem Qua- 158 6 Modellierung statischer Strukturen lifier ,,mitarbeiternummer". Zu jeder Firma und ,,mitarbeiternummer" gibt es maximal eine Person. ~ Ein Qualifier schrankt die Anzahl Objekte am gegeniiberliegenden Ende einer binaren Assoziation ein: Fiir jedes Objekt und jeden Qualifier-Wert gibt es die spezifizierte Anzahl Objekte der "gegeniiberliegenden" Klasse. Besonders niitzlich sind Qualifier, die diese Anzahl auf eins reduzieren. In dieser Situation werden Qualifier am haufigsten eingesetzt (vgl. [Rum96]). Fiir die Navigation iiber eine qualifizierte Assoziation wird OeL verwendet: Ein Ausdruck in eckigen Klammern zeigt die Auswahl von Werten aus einer Menge context directory def: let aFile = directory.files[filename]. Multiplizitaten sind bei ternaren (oder n-aren, n>2) Assoziationen nicht von der gleichen Aussagekraft und Ubersichtlichkeit wie bei binaren. Bei ternaren Assoziationen haben sich Schliisselkandidaten bewahrt. Definition 6.9.5 (Schliisselkandidat) Ein Schliisselkandidat (candidate key) ist eine minimale Kombination von Rollen in einer n-aren Assoziation, die eine Objektbeziehung eindeutig identifiziert. ~ Bemerkung 6.9.6 (Schliisselkandidaten und RDBMS) Der Begriff Schliisselkandidat aus Def. 6.9.5 ist eine natiirliche Ubertragung des entsprechenden Begriffes fUr relationale Datenbanken: Dort ist ein Schliisselkandidat eine minimale identifizierende Attributkombination. Eine n-are Assoziation wird in einer relationalen Datenbank als Tabelle abgebildet. Fiir diesen Fall sind die Begriffe identisch. Analoge Uberlegungen gelten fiir die Abbildung von Klassen auf Tabellen (vgl. auch Kap. 16). ~ Beispiel 6.9.7 (Schliisselkandidat) In der ternaren Assoziation ,,nimmt teil" aus Beispiel 6.4.9 gibt es (bis auf die Reihenfolge) nur den Schliisselkandidaten (Student, Lehrveranstaltung, Semester). In der Abb. 6.30 wird folgende Situation modelliert: Ein Jockey reitet in einem Rennen ein Pferd. Er kann in einem Rennen maximal ein Pferd reiten, allerdings mit diesem oder anderen Pferden an mehreren Rennen teilnehmen. Die Rollen hier mit Multiplizitaten zu versehen ist schwierig: Liest man "Lauf' als ,,An einem Rennen nehmen viele Pferde teil, ein Pferd kann in vielen Rennen starten", so gibt es zu jeder Kombination von Pferd und Rennen einen Jockey. Interpretiert man Lauf als: ,,An einem Rennen nehmen viele Jockeys teil", so gibt es zu jedem Jockey genau ein Pferd. Sinnvoller ist hier die Angabe von Schliisselkandidaten: (Rennen, Pferd) und (Rennen, Jockey) bestimmen jeweils eindeutig eine Objektbeziehung, denn es gibt zu den Schliisselkandidaten-Wert en jeweils genau einen Jockey bzw. Pferd. (Jockey, Pferd) ist kein Schliisselkandidat, da diese Kombination aus Jockey und Pferd an mehreren Rennen teilnehmen kann [Rum96]. ~ 6.9 Weitere Notationen fUr Assoziationen 159 Lau! Pferd SchlOsselkandidaten: (Rennen, Plerd), (Rennen, Jockey) Kein SchIOsselkandidat: (Plerd, Jockey) Abb. 6.30. Schliisselkandidaten communicate 6, serves Abb. 6.31. Benutzungsrichtung So wie Assoziationen bisher eingefiihrt wurden, sind sie in beiden Richtungen benutzbar. Nun gibt es aber auch Einbahnstragen: Assoziationen, die nur in einer Richtung benutzt werden konnen. Es kann auch sein, dass in einem System eine Assoziation nur in einer Richtung benutzt wird und deshalb auch nur in dieser implementiert wird. Definition 6.9.8 (Benutzungsrichtung) 1st nichts anderes angegeben, so kann eine biniire Assoziation kann in beiden Richtungen benutzt werden. 1st sie nur in einer Richtung benutzbar, so wird diese durch eine Pfeilspitze in Benutzungsrichtung am Ende des Assoziationssymbols gekennzeichnet ..... Beispiel 6.9.9 (Benutzungsrichtung) In Client-Server-Strukturen besteht typischerweise eine Beziehung zwischen Client und Server, die vom Client zum Server benutzt werden kann. Die Riickgabe eines Ergebnisses vom Server zum Client ist keine Benutzung einer Assoziation. Dieses Szenario zeigt der linke Teil von Abb. 6.31. In Peer-to-Peer Beziehungen wird die Assoziation zwischen zwei Knoten typischerweise in beiden Richtungen genutzt. Dementsprechend ist in Abb. 6.31 die Assoziation ,,serves" mit einem Pfeil in Richtung Server gezeichnet, die Assoziation 160 6 Modellierung statischer Strukturen Klasse 1 «use» «use» Klasse 2 I Klasse 1 ~ Klasse 3 xyz «use» Klasse 3 I Klasse 2 «use» Abb. 6.32. Schnittstellensymbole "communicate" ohne, da letztere in beiden Richtungen benutzbar sein solI. Da die "communicate" Assoziation zwischen Knoten rekursiv ist, sind die ROllennamen, hier ,,sender" und ,,reciever" obligatorisch ..... 6.10 Schnittstellen Definition 6.10.1 (Schnittstelle, Schnittstellensymbol) Eine Schnittstelle (interface) ist eine Spezifikation des nach auf&en sichtbaren Verhaltens einer Klasse, Komponente oder anderen Klassifizierung (einschlief&lich von Teilsystemen). Eine Schnittstelle spezifiziert fur eine Klasse die Signaturen von Operationen. Eine Schnittstelle wird durch ein Klassensymbol ohne Attributabschnitt und dem Stereotyp «interface»oder durch einen kleinen Kreis dargestellt, der mit dem Namen der Schnittstelle beschriftet ist, wie in Abb. 6.32 gezeigt wird. Eine Schnittstelle hat keine Attribute und keine Zustiinde. Eine Schnittstelle kann Ziel einer grichteten Assoziation sein, aber keinen Assoziationen folgen ..... Beispiel 6.10.2 (Schnittstelle) Abbildung 6.32 zeigt diese Notation. Das gestrichelte Genspecsymbol zwischen Interface und Klasse und die durchgezogene Linie zwischen Interface und Klasse sind iiquivialente Darstellungen. Die Abhiingigkeit ist eine benutzt-Beziehung und deshalb durch den Stereotyp «use» gekennzeichnet. Ein Beispiel fUr Schnittstellen sind die Interfaces aus Java: interface Component { public operation(); II } class Composite implements Component 6.10 Schnittstellen 161 { public operation(); / / ... } Ein anderes Beispiele fur eine Schnittstelle liefert eine DLL, die bestimmte Funktionen exportiert. ~ Definition 6.10.3 (Realisierung, Realisierungssymbol) Wenn eine Klasse eine Schnittstelle realisiert, so wird dies in Abhiingigkeit von der Darstellung der Schnittstelle visualisiert. Wird der Kreis als Kurzschreibweise fur eine Schnittstelle verwendet, so wird der Kreis durch eine durchgezogene Linie mit der realisierenden Klasse verbunden. Wird das Klassensymbol fUr die Darstellung der Schnittstelle verwendet, so wird die Schnittstelle durch ein gestricheltes GenSpecsymbol mit der realisierenden Klasse verbunden. Realisierung bedeutet, dass die Klasse mindestens die Operationen der Schnittstelle implementiert. ~ Klassen, die eine Schnittstelle benutzen werden, mit dem Schnittstellensymbol durch einen gestrichelten Pfeil mit dem Schlusselwort «use» verbunden. Bemerkung 6.10.4 (Klasse, Typ und Schnittstelle) Bereits im Vorwort wurde auf eine vielfiiltig verwobene Begriffswelt hingewiesen. Es erscheint daher sinnvoll einige der eingefUhrten Begriffe zu vergleichen. Was ist der Unterschied zwischen Klasse, Typ, Schnittstelle und abstrakter Klasse? Mit den hier getroffenen Definitionen ist das (hoffentlich) einfach. Ein Typ ist eine Klasse, die nur spezifiziert, welche Attribute und Operationen sie hat. Ein Typ hat also ein spezifiziertes Verhalten, enthiilt aber keine Informationen daruber (weder offentlich noch privat), wie dieses Verhalten realisiert wird. Eine abstrakte Klasse leistet das Gleiche. Sie kann daruberhinaus aber auch spezifizieren, wie das Verhalten realisiert werden solI. Von der Art der Spezialisierung hiingt die Wirkung einer solchen Spezifikation abo Sie kann obligatorisch sein, dann mussen spezialisierte Klassen diese Spezifikation oder Implementierung ubernehmen. Dies ist der Fall, wenn in Java eine Operation als final deklariert ist. In C++ konnen Operationen in spezialisierten Klassen uberschrieben werden, wenn sie als virtual deklariert sind. Sie kann aber auch einen default zur VerfUgung stellen, den Spezialisierungen verwenden oder veriindern konnen. Eine Schnittstelle spezifiziert einen Ausschnitt des Verhaltens einer Klasse oder eines Pakets. Dieses kann von einer oder mehreren Klassen unterstutzt werden. Wie das Verhalten realisiert wird, ist der Schnittstelle nicht zu entnehmen. Einer abstrakten Klasse kann dies zwar nicht ein Benutzer, wohl aber der Entwickler entnehmen. Die unterschiedlichen Begriffe haben also auch unterschiedliche Zielgruppen. So wird man hiiufig von einer Klasse nur eine Schnittstelle, niimlich die offentlichen Operationen, fur aBe Benutzer publizieren, wiihrend die Internas den Entwicklern der Klasse vorbehalten bleiben. ~ 162 6 Modellierung statischer Strukturen Fur die Abgrenzung von Paketen sind zunachst einmal die Verhaltnisse im Anwendungsbereich ausschlaggebend. Diese konnen dem Entwickler aber nicht immer hinreichende Anhaltspunkte fUr eine Zerlegung des Systems, insbesondere des Klassenmodells, in Pakete geben. Dann sind die Regeln fUr Modularisierung, insbesondere Kopplung und Zusammenhalt nutzlich. Deshalb hier eine Ubersicht, die bei der Identifikation von Kopplung und Zusammenhalt helfen solI: 1. Zusammenhalt: Indizien fUr Zusammenhalt von Klassen, die (potenziell) ein Paket bilden, sind: • Aggregationen zwischen den Klassen, insbesondere Kompositionen. • Assoziationen. • Gemeinsames Auftreten mit direkter Nachrichtenverbindung in Kollaborationsdiagrammen. 2. Kopplung: Indizien fUr eine Kopplung zwischen (potenziellen) Paketen sind: • Assoziationen oder Aggregationen, die uber Paket-Grenzen gehen. • Importbeziehungen und deren ,,Breite". 6.11 Historische Anmerkungen Fur Klassen gibt es in der Literatur eine Reihe von Symbolen. Popular waren und sind z. B. die Wolken von Booch. Die Wolken hatte Grady Booch ursprunglich aus der Dokumentation von Intels objektorientierter Architektur iAPX432 ubernommen [Boo94a]. Das Symbol sollte andeuten, dass die Grenzen einer Abstraktion oder eines Konzepts nicht notwendig eben sind oder nur einfache Ecken haben. Man konnte zur Motivation auch an fraktale Gebilde denken. Das Klassensymbol in der hier benutzten Form stammt aus der OMT Methode von James Rumbaugh et al. (s. [RBP+91]) und steht in der Tradition sowohl der Entity-Relationship-Modellierung als auch der bewahrten Diagrammtechniken, die fur statische Objekte eckige Symbole und fUr dynamische Objekte runde oder abgerundete Symbole vorsehen [M092]. Beispiele fUr dieses Prinzip sind auch die Kreise fUr Prozesse in der strukturierten Analyse und die Symbole fUr Zustande und Anwendungsfalle in diesem Buch. Das Sechseck als Symbol fUr ein Objekt, das in UML 0.8 vorgesehen war, kann als strukturierte Wolke angesehen werden [BR96]. Die in der UML benutzte Form des Klassensymbols eignet sich auch gut fur die Zeichnung auf Tafel oder Papier. Die Bezeichnung "utility" geht meines Wissens auf [Boo94a] zuruck. Die Praxis, freie Unterprogramme (free subprograms) nach den Klassen zu gruppieren, aus den en sie aufgebaut sind, stammt wohl aus C++ und ist eine Standardanwendung der in Kap. 4 dargestellten Prinzipien. Der Verzicht auf eine Formalisierung des ,,semantischen Hintergrundes" folgt dem Stil der Booch Notation, in der fUr jedes Element eine derartige, nicht 6.11 Historische Anmerkungen 163 weiter formalisierte Spezifikation vorgesehen ist. Die Spezifikation von Operationen lehnt sich an die Ada Syntax an. Fiir die Darstellung von GenSpecBeziehungen wurden verschiedenste Symbole benutzt: Pfeile in verschiedenen Formen, die mal auf die Spezialisierung [Mey92], mal auf die Generalisierung zeigen, z. B. [Bo094a}; ein Dreieck, dessen Spitze auf die Generalisierung zeigt und etwa in der Mitte einer Linie zwischen Spezialisierung und Generalisierung angebracht ist (OMT, z. B. [RBP+91J); ein Halbkreis in der Mitte einer solchen Linie, dessen ,,schnittfHiche" zur Spezialisierung gerichtet ist. Eine Umrahmung der Spezialisierungen, die durch eine Linie mit der Generalisierung verbunden sind [M095},[Fow96}. In der erweiterten Entity-Relationship Notation wurde dies durch einen Bogen bei der Generalisierung ausgedriickt. Die UML iibernimmt eine Form, die sich nach meinem Eindruck im Wesentlichen bereits durchgesetzt hatte. Das Symbol fUr Schnittstelle stammt aus der Microsoft Dokumentation zu DCOM. Booch unterscheidet zusiitzlich eine Sichtbarkeit ,)mplementierung". Offentliche Sichtbarkeit wird dort nicht weiter markiert. Geschiitzt, privat und Implementierung wird durch ein, zwei bzw. drei senkrechte Striche markiert. Klassenattribute und -operationen werden in OMT durch den Priifix $ gekennzeichnet. Diese Notation ist eine Weiterentwicklung der Notationen der genannten Autoren, wie der folgende Text anekdotisch zeigt (zumindest fiir Booch und OMT). Nach den vorstehenden Erliiuterungen sollte er fUr Leser mit etwas Englisch Kenntnissen verstiindlich sein. 1 Both Sides Now by Jim Rumbaugh with apologies to Joni Mitchell Blobs with writing in their hair And small adornments in the air And has-relations everywhere I've looked at clouds that way. But now I've purged them from my Sun Eliminated everyone So many things I would have done To drive the clouds away. I've looked at clouds from both sides now Both in and out, and still somehow It's clouds' delusions I appall I really can't stand clouds at all. Balls for multiplicity Black and white for clarity And data flows arranged in trees 1 Fowler berichtet in [FSM97j, die Party von Rational auf der OOPSLA 1995 sei trotz des Gesangs von Jim Rumbaugh sehr lustig gewesen. 164 6 Moclellierung statischer Strukturen Were part of OMT. But now I've had to let them go We'll do it differently, you know 'Cause Grady said, they've got to go We can't use OMT. I've seen 0 MT from both sides now Both good and bad, and still somehow It's my notation I recall I really like OMT best of all. Talks in June to write it down And document just what we've found And bring it here to Austin town To give it all away. But now our fans are acting strange Hey, Jim and Grady, you've both changed. Well, something's lost, but something's gained In building unity. We've seen 00 from both sides now Both his and mine, and still somehow It's OO's strengths we'll still pursue We've tried to bring the best to you. 6.12 Fragen zur Klassenmodellierung (UML) 1. Erliiutern Sie Gemeinsamkeiten/Unterschiede von Assoziation und Aggregation! 2. Wann modelliert man eine Beziehung als Aggregation, wann als Assoziation? 3. Wie kann man virtuelle Methoden aus C in einem Klassenmodell ausdriicken? 4. Wie macht man deutlich, dass es sich bei einer Klasse urn eine abstrakte (Basis- )Klasse handelt, von der es keine Instanzen geben solI bzw. darf? 5. Nach welch en Kriterien kann man sich richten, wenn man sich entscheiden muss, ob man eine Klasse bilden oder diese in mehrere aufsplitten solI oder nicht? (Kopplung contra Zusammenhalt) 6. Wie entscheidet man, ob Attribute in eine Klasse gehoren oder Bestandteil einer Oberklasse sind? 7. In wieweit lasst die Anzahl cler Attribute eines Objektes darauf schlieBen, dass dieses Objekt evtl. gesplittet werden sollte? 8. Was ist der Definitionsbereich einer Operation? 9. Was versteht man unter einer Rolle? 6.12 Fragen zur Klassenmodellierung (UML) 165 10. Was sind bei Assoziationen Rollennamen? Was genau unterscheidet die Rolle von einer Benennung einer Assoziation? 11. Was ist ein Diskriminator? 12. Wann soIl ten ternare Assoziationen verwendet werden? Was sagen sie aus und wie sollten sie spezifiziert werden? 13. Nennen und diskutieren Sie einige Kriterien, nach denen Klassen in einem Analysemodell sinnvoll zu Paketen zusammengefasst werden konnen! 14. Welche Klassen sind Kandidaten fUr Singletons? Wann sollten sie vermieden werden, bzw. sind sie iiberfliissig? 15. Welche Methoden gibt es, urn eine Kopplung zwischen bzw. Zusammenhalt innerhalb von Objekten zu erkennen und zu analysieren? 16. Was ist ein Qualifier? Wann benutzt man diese? 17. Welche Beziehungen gibt es zwischen Schnittstelle und Klasse bzw. Schnittstelle und Paket? 18. Was gibt die Benutzungsrichtung einer Assoziation an? 19. Wie sind Assoziationen zu verstehen, wenn keine Benutzungsrichtung angegeben ist? 20. Beschreiben Sie die Unterschiede und Gemeinsamkeiten von Zusammensetzungs-Strukturen (Aggregation, Is a-) und VerallgemeinerungsBeziehungen (Is a-, GenjSpec) in einem komplexen System! 21. Was ist der Unterschied zwischen Aggregation und Zusammensetzung (Komposition) ? 22. Vergleichen Sie das Objektmodell aus OMT mit dem Entity-RelationshipModell! 23. Wie soUte man die Kardinalitaten in einem Objektmodell notieren? Was spricht fUr und was gegen die verschiedenen Moglichkeiten? 24. Was versteht man unter Abhangigkeit? 25. Wie unterscheidet man Assoziation und Abhangigkeit? 26. Wozu setzt man Utility-Klassen ein? 27. Gibt es sinnvolle Assoziationen, in denen ein Assoziationsende die Kardinalitat 0 hat? 28. Hat man eine gerichtete Assoziation von einer Klasse A zu einer Klasse B, kann man dann zu einem Objekt aus B das oder die zugehorigen Objekte der Klasse A finden? 29. Es gibt keine (?) Programmiersprache, in der sich Aggregation abbilden lasst. 1st es also interessant in der Analyse zwischen Assoziation, Aggregation und Komposition zu unterscheiden? 30. Klassische Verfahren der Wiederverwendung erlauben nur das Wiederverwenden von Elementen, die genau auf die andere Aufgabenstellung passen. Objektorientierung tritt mit dem Anspruch auf, dies auch zu ermoglichen, wenn die Elemente nur "ungefahr" passen. Wie ist das moglich und welche Vor- und Nachteile sehen Sie darin?