1 DigInf 05/06 Weitere Tätigkeiten des Entwurfs Zielsetzung: Weitere Anpassung an die beabsichtigte Programmiersprache. Anmerkungen: Der Übergang Entwurf-Implementierung.

Präsentation zum Thema: "1 DigInf 05/06 Weitere Tätigkeiten des Entwurfs Zielsetzung: Weitere Anpassung an die beabsichtigte Programmiersprache. Anmerkungen: Der Übergang Entwurf-Implementierung."—  Präsentation transkript:

1 1 DigInf 05/06 Weitere Tätigkeiten des Entwurfs Zielsetzung: Weitere Anpassung an die beabsichtigte Programmiersprache. Anmerkungen: Der Übergang Entwurf-Implementierung ist unschärfer als der Übergang Analyse-Entwurf. Die Generierung von Coderahmen durch Werkzeuge verschiebt Aspekte der Implementierung in den Entwurf. Eine mögliche (aber untaugliche) Abgrenzung: In der Implementierung wird ausschließlich die im Entwurf bestimmte Architektur umgesetzt. Aber: Wie werden Bibliotheken der Programmiersprache eingebracht, wie erfolgt Wiederverwendung von Programmcode?

2 2 DigInf 05/06 Forderungen an Entwicklungsvorgehen Analyse: Identifikation geeigneter Einheiten im Anwendungsbereich änderungsfreundliche Beschreibung dieser Einheiten übersichtliches Strukturieren der spezifizierten Einheiten Entwurf: Erhalten der Einheiten aus der Analyse Erhalten der Strukturen aus der Analyse Berücksichtigung entwurfstechnischer Aspekte Programmierung: Erhalten der Einheiten aus Analyse und Design Erhalten der Strukturen aus Analyse und Design Berücksichtigung programmiertechnischer Aspekte

3 3 DigInf 05/06 Modelle der Softwareentwicklung Während der Entwicklung entstehen mindestens 4 Modelle: „Realitäts“-Modell:Annahme über den IST-Zustand! Analyse-Modell: WAS soll das Produkt leisten? Design-Modell: WIE soll das Produkt arbeiten? Programm-Modell: Operationale Umsetzung des WIE! Übergänge zwischen den Modellen sind nicht einfach: keine „Brücken“ für kontinuierlichen Übergang statt dessen „Gräben“, die übersprungen werden müssen keine einheitliche Sichtweise keine einheitliche Notation

4 4 DigInf 05/06 Zusammenfassung Objektorientierte Analyse und objektorientierter Entwurf haben unterschiedliche Schwerpunkte. Die Analyse darf nicht nur die Vorwegnahme von Entwurfsentscheidungen verwässert werden. In Analyse, Entwurf, Implementierung werden die gleichen Strukturierungsmerkmale verwendet, sodass im Entwurf das Ergebnis der Analyse und in der Implementierung das Ergebnis des Entwurfs natürlich verfeinert werden kann.

5 5 DigInf 05/06 Zusammenfassung Objektorientierte Modellierungssprachen ermöglichen Vorteile, sie garantieren sie nicht. Deshalb: objektorientierte Modellierung muss durch geeignete Methoden und Richtlinien ergänzt werden.

6 6 DigInf 05/06 Objektorientierte Modellierung

7 7 DigInf 05/06 Wenn man sich um Software Engineering kümmert, hat man meistens mehrere Objekte, meistens sogar viele. Weihnachtsbäckerei

8 8 DigInf 05/06 Beispiel Weihnachtsbäckerei: Bereitstellen der Funktionalität einer Plätzchenbäckerei Durchspielen ihrer Dynamik Arbeitsteiliges System mit Spezialisten für Teigverarbeitung, Rühren und Kneten, Backen und drei Sorten Plätzchen.

9 9 DigInf 05/06 „Spezialisten“ in der Bäckerei Zucker Mehl Teig Rührgerät Backofen Tannenbaum- plätzchen Stern- plätzchen Herz- plätzchen

10 10 DigInf 05/06 „Spezialist“ in der Bäckerei Spezialist für Teig Aufgabe: Zusammenstellen der nötigen Zutaten. Die Zusammenstellung ist vertraulich und darf nicht herausgegeben werden. Anstoßen der notwendigen Bearbeitung.

11 11 DigInf 05/06 „Spezialist“ in der Bäckerei Rührgerät Aufgabe: Übergebenen Teig kneten, Synchronisation der Knethaken, Überwachung der Motortemperatur und Motorsteuerung

12 12 DigInf 05/06 „Spezialist“ in der Bäckerei Backofen Aufgabe: Übergebenen Teig backen, Überwachung und Steuerung der Backtemperatur

13 13 DigInf 05/06 „Spezialist“ in der Bäckerei Spezialist für Schokoladenplätzchen Aufgabe: Richtige Form bestimmen, Richtigen Bräunungsgrad festlegen Und Glasur auftragen

14 14 DigInf 05/06 Erkenntnisse Prinzipien bei der Gestaltung der Spezialisten: Kapselung Jeder Spezialist hat eine Grenze - kein „Hinüberlangen“ zu anderen. Lokalität Daten und Handlungsanweisungen des Spezialisten sind zusammengefasst. konzeptionelle Vollständigkeit Jeder Spezialist kann seine Aufgaben erledigen. Geheimhaltung von „Interna“ Jeder Spezialist verbirgt seine Daten und genauen Handlungen. wohldefinierte „extern sichtbare Leistung“ Jeder Spezialist stellt Ergebnisse von Dienstleistungen bereit.

15 15 DigInf 05/06 Erkenntnisse Prinzipien bei der Gestaltung des Systems: Autonomie Jeder Spezialist entscheidet autonom über Handlungen und Antwort. Kommunikation über wohldefinierte Nachrichten Spezialisten senden einander ausschließlich Nachrichten. „Teamwork“ Systemleistung entsteht als gemeinsames Ergebnis.

16 16 DigInf 05/06 Objekte in der Bäckerei Zucker Mehl Teig Rührgerät Backofen Tannenbaum- plätzchen Stern- plätzchen Herz- plätzchen

17 17 DigInf 05/06 Objekte in der Bäckerei - Ähnlichkeiten Zucker Mehl Teig Rührgerät Backofen Tannenbaum- plätzchen Stern- plätzchen Herz- plätzchen Ähnlichkeit

18 18 DigInf 05/06 Objekte in der Bäckerei - Enthaltensein Enthaltensein Zucker Mehl Teig Rührgerät Backofen Tannenbaum- plätzchen Stern- plätzchen Herz- plätzchen

19 19 DigInf 05/06 Objektorientierte Modellierung Zielsetzungen der Modellierung: gleichartige Beziehungen auch gleichartig beschreiben: Nachrichtenaustausch Ähnlichkeit Enthaltensein Objekte mit ähnlichen Eigenschaften gemeinsam beschreiben: verschiedene Objekte sind gleichartig, d.h. besitzen gleiche Methoden und Attribute zwei Objekte unterscheiden sich, aber ein Objekt besitzt insbesondere alle Methoden und Attribute des anderen Beziehungen zwischen gleichartigen Objekten gemeinsam beschreiben

20 20 DigInf 05/06 Klasse Gleichartige Objekte besitzen gleiche Attribute und gleiche Methoden. Beispiel: Sternplätzchen und Tannenbaumplätzchen besitzen die gleichen Attribute: Form, Glasur, Bräunungsgrad besitzen die gleichen Methoden: ausstechen, glasieren, backen

21 21 DigInf 05/06 Klasse Es bietet sich an, die Attribute und Methoden aller Plätzchen nur genau einmal zu beschreiben: Klasse Plätzchen: zugehöriges Objekt besteht aus: Form Glasur Bräunungsgrad … ausstechen glasieren backen...

22 22 DigInf 05/06 Objekt Ein Objekt...ist eine handlungsfähige Einheit, bestehend aus von außen nicht erkennbarem Zustand, von außen nicht sichtbaren Funktionen und von außen sichtbaren Funktionen (Methoden), die das extern sichtbare Objektverhalten bestimmen. Ein Attribut...ist ein „Behälter“ für einen Wert, der den internen Objektzustand mitbestimmt. Eine Methode...ist eine von außen sichtbare Funktion eines Objekts. Die Menge aller Methoden bildet die Schnittstelle eines Objekts.

23 23 DigInf 05/06 Definition: Klassen und Objekte Eine Klasse...ist eine Definition, die eine Menge gleichartiger Objekte beschreibt. Sie umfasst die gemeinsamen Attribute und Methoden der Objekte. Ein Objekt...ist ein Exemplar (eine Instanz) einer Klasse. Es wird „bei Bedarf“ aus der Klasse abgeleitet.  Eine Klasse ist eine Schablone für das Erzeugen einer beliebigen Anzahl gleichartiger Objekte.

24 24 DigInf 05/06 Klasse Vorteile der Definition mit Klassen: abstrakte Typisierung = Reduktion der betrachteten Aspekte strukturierte Beschreibung aller Objekte Gleichförmigkeit aller Objekte einer Art reduzierter Beschreibungsaufwand, keine Redundanz Vermeidung von Fehlern Änderungen werden unterstützt, da Beschreibung aller Objekte einer Art an einem Ort vorliegt, alle anschließend erzeugten Objekte betroffen sind, eine beliebige Anzahl von Objekten möglich ist.

25 25 DigInf 05/06 Objekte in der Bäckerei :Zucker :Mehl :Teig :Rührgerät :Backofen :Tannenbaum- plätzchen :Herz- plätzchen :Stern- plätzchen

26 26 DigInf 05/06 Klassen der Bäckerei Teig Rührgerät Backofen Plätzchen Zucker Mehl

27 27 DigInf 05/06 Vererbung Eine Klasse beschreibt gleichartige Objekte. Ähnliche, aber nicht gleichartige Objekte erfordern eine andere Klasse. Beispiel: Verschiedene Formen von Plätzchen sind einander nur ähnlich: Zimtsterne Zimt im Teig, nur Sternform Schokoladenplätzchen Schokolade im Teig Vanillekipferl Vanille im Teig, Nicht ausgestochen, sondern gerollt

28 28 DigInf 05/06 Vererbung Es ergeben sich drei Klassen: ZimtsternSchokoplätzchenVanillekipferl FormForm Form GlasurGlasurGlasur BräunungsgradBräunungsgradBräunungsgrad ZimtgehaltSchokogehaltVanillegehalt......... ausstechenausstechen ausrollen glasierenglasieren glasieren.........

29 29 DigInf 05/06 Vererbung Alle drei Klassen besitzen gleiche Attribute: Form, Glasur, Bräunungsgrad,... gleiche Methoden: glasieren,... Objekte aller drei Klassen werden als „Plätzchen“ angesprochen, da das Konzept „Plätzchen“ im Sprachgebrauch durch die gemeinsamen Eigenschaften repräsentiert wird: Ein Plätzchen ist „etwas“, auf das gebacken und glasiert werden kann und das man anschließend aufessen kann. Plätzchen ist somit der abstrakte Oberbegriff für die Klassen Zimtstern, Schokoplätzchen und Vanillekipferl!

30 30 DigInf 05/06 Vererbung Ableitung einer Klasse aus einer anderen Klasse derart, dass die abgeleitete Klasse alle Attribute und Methoden übernimmt. Oberklasse, Superklasse Klasse, von der abgeleitet wird. Unterklasse, Subklasse Klasse, die abgeleitet ist.

31 31 DigInf 05/06 Vererbung Beispiel für Vererbung: Klasse Plätzchen: Form, Glasur, Bräunungsgrad,..., glasieren,... Klasse Zimtstern erbt von Plätzchen zzgl. Zimtgehalt, ausstechen Klasse Schokoplätzchen erbt von Plätzchen zzgl. Schokogehalt, ausstechen Klasse Vanillekipferl erbt von Plätzchen zzgl. Vanillegehalt, ausrollen alle Attribute und Methoden von Plätzchen

32 32 DigInf 05/06 Plätzchen Vererbung Notation für Vererbung: VanillekipferlSchokoplätzchenZimtstern Oberklasse Unterklasse Vererbung

33 33 DigInf 05/06 Klassenhierarchie der Bäckerei Teig Rührgerät Backofen Zutaten ZuckerMehl Plätzchen VanillekipferlSchokoplätzchenZimtstern

34 34 DigInf 05/06 Assoziationen Überlegungen: Vererbung ist eine Beziehung zwischen Klassen. Nachrichtenaustausch ist eine Beziehung zwischen Objekten (vgl. Experiment). Da Objekt eine Instanz einer Klasse ist, muss eine Beziehung zwischen Objekten als Beziehung zwischen Klassen vorgegeben worden sein. Assoziation = Beziehung zwischen Klassen, die Nachrichtenaustausch zwischen deren Objekten erlaubt.

35 35 DigInf 05/06 Assoziationen der Bäckerei TeigRührgerät Backofen Zutaten ZuckerMehl Plätzchen VanillekipferlSchokoplätzchenZimtstern Assoziation

36 36 DigInf 05/06

37 37 DigInf 05/06 Unified Modeling Language Unified Modeling Language – eine lingua franca Welche Aufgaben hat die UML? Sie dient der Modellierung, Dokumentation, Spezifizierung und Visualisierung von komplexen Softwaresystemen (unabhängig vom Fachgebiet, in dem es eingesetzt werden soll). Wer ist für die Entwicklung der UML verantwortlich? Die UML ist ein von der OMG (Object Management Group) gepflegter Standard. Die OMG ist ein Konsortium, bestehend aus über 800 Mitgliedsunternehmen, das herstellerneutrale Industriestandards erstellt (gegründet 1989).

38 38 DigInf 05/06 S.Shlaer, S. Mellor OOA und OOD, 1991 P. Coad, E. Yourdon, 1991 OOD, 1991 G. Booch OMT, 1991 J. Rumbaugh Unified Method G. Booch / J. Rumbaugh, 1995 Unified Modeling Language (UML) G. Booch / J. Rumbaugh / L. Jacobson 1996 OOSE, 1992 I. Jacobson State Charts (erw. / hierarchische Zustandsübergangs- diagramme) D. Harel CRC-Karten (Class-Responsibilities- Collaborations) R. Wirfs-Brock 1990 Integrationen auf dem Weg zur UML Integrationen ohne Niederschlag in der UML Unified Modeling Language

39 39 DigInf 05/06 UML: Verwendung von Diagrammen 1) Klassendiagramme (inkl. CRC Cards) 2) Anwendungsfall- diagramm 6) Aktivitäten- diagramm 3a) Sequenzdiagramme 3b) Kollaborationsdiagramme 5) Komponenten- diagramme falls das Anwendungsgebiet workflow-geprägt ist OOA OOD 4) Zustandsübergangs- diagramm

40 40 DigInf 05/06 Geschichte der UML OMG UML 2.0 unveröffentlicht OMG UML 1.5 2003 OMG UML 1.4 2001 OMG UML 1.3 1999 OMG UML 1.2 1998 UML Partners UML 1.1 1997 UML Partners UML 1.0 1997 Bo., Ru., Ja. UML 0.9 1996 Booch, Rumbaugh Unified Method 0.8 1995Jacobson OOSE 1995 Rumbaugh et al. OMT 1991Booch OOD 1992 Quelle: Jeckle et al.: UML 2 - glasklar Einsatzerfahrung der Sprachschöpfer Integration der Object Constraint Language XML Metadata Interchange Erfahrungen der Anwender OMG übernimmt Copyright

41 41 DigInf 05/06 Zentrale Paradigmen der UML I 1. Unterscheidung Modell / Diagramm Ein UML-Modell wird repräsentiert durch ein Gruppe von Diagrammen. Ein Diagramm entspricht einer bestimmten Sicht auf das Modell. Ein Diagramm wird deshalb häufig nur einen Teil der im Modell enthaltenen Information darstellen. Andererseits kann ein Modellelement mehrfach, also in unterschiedlichen Diagrammen vorkommen. In einem Diagramm kommt keine Information vor, die nicht im Modell vorhanden ist.

42 42 DigInf 05/06 Zentrale Paradigmen der UML II 2. Trennung von Begriffswelt und Notation Es gibt eine festgelegte Menge an Begriffen, mit denen im Modell enthaltene Information beschrieben werden kann. Es gibt festgelegte Regeln zur Konstruktion des Modells auf der Grundlage der Begriffe. Die Notation wird der Begriffswelt zugeordnet und dient der physischen Repräsentation des Modells in Form von Diagrammen. Trennung von Inhalt und Form Es kann die jeweils passende Notation ausgewählt werden. Basis für die Erweiterung oder Einschränkung der Sprache 3. Objektorientierung Die UML baut konsequent auf der objektorientierten Begriffswelt auf.

43 43 DigInf 05/06 Anforderungen an die UML 2.0 I Anforderungen, die aus der Kritik an der UML 1.x extrahiert wurden die UML soll präziser werden Neuformulierung des Metamodells möglichst weitgehende Verwendung der OCL es soll eine verbesserte Ausführbarkeit gewährleistet werden Erweiterung der Zustandsautomaten stärkere Beziehung zwischen statischen und dynamischen Diagrammen Integration erprobter Ansätze (z.B. Petri-Netze) es soll mehr Übersichtlichkeit geben Verringerung der graphischen Modellkonstrukte und Basiskonzepte bessere Unterstützung der komponentenbasierten Entwicklung (z.B. J2EE) Quelle: Jeckle et al.: UML 2 - glasklar

44 44 DigInf 05/06 Anforderungen an die UML 2.0 II Anforderungen, die aus der Kritik an der UML 1.x extrahiert wurden Spezifikation von Echtzeitarchitekturen soll möglich sein (für technische Systeme) geeignete Notationsmittel müssen hinzugefügt werden klare Definition der zum Teil noch schwachen Semantik bessere Unterstützung von Kapselung und Skalierbarkeit in der Verhaltensmodellierung, insbesondere bei Zustandsautomaten und Interaktionsdiagrammen Behebung der Einschränkungen bei der Aktivitätsmodellierung bessere Unterstützung der hierarchischen Modellierung (Systemzerlegung) Quelle: Jeckle et al.: UML 2 - glasklar

45 45 DigInf 05/06 Diagrammtypen der UML StrukturdiagrammeVerhaltensdiagramme UML-Diagramme Interaktionsdiagramme Interaktionsübersichtsdiagramm Aktivitätsdiagramm Kommunikationsdiagramm Klassendiagramm Sequenzdiagramm Verteilungsdiagramm Kompositionsstrukturdiagramm Timingdiagramm Komponentendiagramm Zustandsautomat Objektdiagramm Paketdiagramm Use-Case-Diagramm Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering

46 46 DigInf 05/06 Diagrammtypen der UML StrukturdiagrammeVerhaltensdiagramme Interaktionsdiagramme Klassendiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Zustandsautomat Paketdiagramm Aktivitätsdiagramm Use-Case-Diagramm Sequenzdiagramm Kommunikationsdiagramm Verteilungsdiagramm UML-Diagramme Unterschiede zwischen UML 1.x und UML 2.0: hoch mittel gering Timingdiagramm Interaktionsübersichtsdiagramm

47 47 DigInf 05/06 Klassendiagramm Diese zentrale Frage beantwortet das Diagramm: Aus welchen Klassen besteht mein System und wie stehen diese untereinander in Beziehung? Diese Stärken hat das Diagramm: a.beschreibt die statische Struktur des Systems b.enthält alle Strukturzusammenhänge und Datentypen c.ist Brücke zu dynamischen Diagrammen Quelle: Jeckle et al.: UML 2 - glasklar

48 48 DigInf 05/06 Notationselemente I eine Klasse wird als Rechteck mit dem Klassennamen dargestellt der Klassenname muss modellweit eindeutig sein es können weiterhin Attribute und Operationen festgelegt werden

49 49 DigInf 05/06 Notationselemente II Attribute...werden im einfachsten Fall nur mit ihrem Namen angegeben. Es können darüber hinaus folgende Angaben gemacht werden: [Sichtbarkeit] [/] name [: Typ] [Multiplizität] [= Vorgabewert] [{Eigenschaftswert}]

50 50 DigInf 05/06 Notationselemente III [Sichtbarkeit] public (+)Es kann unbeschränkt, insbesondere von außerhalb der Klasse, auf das Attribut zugegriffen werden. private (-)Nur Elemente der Klasse selbst können auf das Attribut zugreifen. protected (#)Das Attribut ist nur in der definierende Klasse und in Spezialisierungen davon sichtbar. package (~)Das Attribut ist für alle Klassen im selben Paket sichtbar. [/] abgeleitetes Attribut: Inhalt kann zur Laufzeit berechnet werden Speicherung nicht nötig

51 51 DigInf 05/06 Notationselemente IV [Name] der Attributname [Typ] der Datentyp des Attributs (Integer, String, Boolean etc.) [Multiplizität] legt die Untergrenze (links von..) und die Obergrenze (rechts von..) für die Anzahl der unter einem Attributnamen ablegbaren Ausprägungen fest 0..1optionales Attribut 1..1zwingendes Attribut 0..*optional beliebig 1..*beliebig, aber mindestens eins n..mmindestens n, aber höchstens m

52 52 DigInf 05/06 Notationselemente V [= Vorgabewert] Dieser Wert wird für das entsprechende Attribut automatisch gesetzt. [{Eigenschaftswert}] Damit können besondere Eigenschaften des Attributs gesetzt werden: {readOnly}Wert darf nicht geändert werden {redefines}überschreibt eine bestehende Attributdefinition {ordered}Inhalte sind sortiert und ohne Duplikate {sequence}Inhalte sind sortiert uvm. Sonderfall statische Attribute (Darstellung durch Unterstreichung) Alle Ausprägungen einer Klasse teilen sich denselben Attributwert. Schreiboperationen in einem Objekt wirken sich auf alle anderen Objekte aus.

53 53 DigInf 05/06 Notationselemente VI Operationen...werden im einfachsten Fall nur mit ihrem Namen angegeben. Es können darüber hinaus folgende Angaben gemacht werden: [Sichtbarkeit] Name (Parameterliste) : Rückgabetyp Die Parameterliste ist definiert als: [Übergaberichtung] Name : Typ [´[´Multiplizität´]´] [= Vorgabewert]

54 54 DigInf 05/06 Notationselemente VII [Sichtbarkeit] wie bei den Attributen [Name] wie bei den Attributen [Rückgabetyp] der Datentyp, der zurückgeliefert wird Parameterliste [Übergaberichtung] in liest den Parameter out überschreibt den Parameter inout liest den Parameter und überschreibt ihn [Name] wie bei den Attributen [Typ] Datentyp des Parameters [Multiplizität] wie bei den Attributen [Vorgabewert] Wert wird beim Fehlen des Parameters gesetzt

55 55 DigInf 05/06 Anwendungsbeispiel Ein Beispiel in Java public class Buch { private static String Besitzer; private String Titel; private int Jahr; public String Ausleiher;... public void ausleihen (String Ausleiher) {...} public void zurueckgeben () {...} public void setBesitzer (String Besitzer) {...}... }

56 56 DigInf 05/06 Notationselemente VIII Schnittstellen werden mit einem Klassensymbol dargestellt sie beschreiben eine Menge von Operationen, Merkmalen und „Verpflichtungen“ Klasse1 implementiert die Schnittstelle Pfeildarstellung Ball-Darstellung Klasse2 benötigt die Schnittstelle Pfeildarstellung Socket-Darstellung Ball-Socket-Darstellung

57 57 DigInf 05/06 Notationselemente IX die Generalisierungsbeziehung drückt aus, dass Klasse2 und Klasse3 Spezialisierungen von Klasse1 sind Klasse2 und Klasse3 erben die Eigenschaften von Klasse1 Klasse1 wird als Superklasse bezeichnet (vererbt) Klasse2 und Klasse3 werden als Sub- oder Unterklasse bezeichnet (erben)

58 58 DigInf 05/06 Notationselemente X eine Assoziation beschreibt die Beziehungen zwischen mehreren Klassen es können Multiplizitätsangaben gemacht werden es kann ein Assoziationsname angegeben werden es können Rollen angegeben werden (sie beschreiben die die konkrete Verwendung einer Klasse näher)

59 59 DigInf 05/06 Anwendungsbeispiel eine Person trinkt mindestens einen Cocktail, ein Cocktail wird von genau einer Person getrunken ein Cocktail enthält beliebig viele Früchte, eine Frucht ist in genau einem Cocktail enthalten die Assoziation Früchtekonsum fügt dem Modell keine neue Aussage hinzu (abgeleitete Assoziation) eine Frucht wird von genau einer Person verzehrt, eine Person konsumiert beliebig viele Früchte

60 60 DigInf 05/06 Notationselemente XI eine navigierbare Assoziation drückt aus, dass die Quelle (Klasse1) das Ziel (Klasse2) kennt eine Aggregation drückt aus, dass das Ziel (Klasse2) Teil der Quelle (Klasse1) ist eine Komposition ist die strengere Form der Aggregation die Quelle (Klasse1) beinhaltet das Ziel (Klasse2) physisch  Klasse2 kann nicht ohne Klasse1 existieren

61 61 DigInf 05/06 Anwendungsbeispiel

62 62 DigInf 05/06 Klassendiagramm Änderungen gegenüber früheren UML-Versionen Unsauberkeiten wurden beseitigt, einige Elemente wurden überarbeitet (z. B. copy- oder become-Stereotypen). Sonst keine wesentlichen Änderungen. Besondere Hinweise Klassen sollten mit einem Hauptwort im Singular benannt werden. In den Namen sollten Sonderzeichen und Umlaute vermieden werden.