Vgl. Oestereich Kap 2.4 Seiten 99-110 1
Vgl. Oestereich Kap 2.41 Seiten 99ff 2
Wie das Klassendiagramm ist auch das Objektdiagramm ebenfalls ein Strukturdiagramm. Da die Anzahl der Attribute sehr groß sein kann, werden normalerweise nur diejenigen Attribute aufgelistet, welche für den Zweck, den man verdeutlichen möchte, ausreichen. 3
Objektdiagramme werden nur verwendet, wenn komplexe Klassendiagramme anhand von konkreten Beispielen verdeutlicht oder überprüft werden sollen. 4
Statt Objekt sagt man darum oft auch Instanz. Das Objektdiagramm zeigt nicht, wer dieses Objekt erstellt hat oder wann oder warum ( Aktivitätsdiagramm, Sequenzdiagramm). Vom Objekt werden nicht alle Attribute dargestellt, sondern bloss diejenigen, welche für das Diagramm/den aktuellen Zustand relevant sind. 5
Der Aufbau des Objektdiagramms ist ähnlich wie beim Klassendiagramm, nur dass im obersten Kasten nicht der Klassenname steht, sondern Instanzname : Typ und zwar unterstrichen. Der Instanzname ist optional und kann bei nicht benannten (anonymen) Objekten weggelassen werden. Ausserdem fehlen die Operationen. Diese gehören zu der Klasse, nicht zum Objekt. In Use-Case-, Sequenz- oder Kommunikationsdiagrammen werden Rollen und keine Objekte gezeichnet. 6
Rekursive Assoziationen lösen sich im Objektdiagramm auf. Ausserdem können Objekte in der Hierarchie mehrfach verbunden sein (z.b. der Angestellte Rolf, der zwei Chefs hat). 7
Vgl. Oestereich Kap 2.4.2 Seiten 100ff 8
Man spricht oft auch von Softwarekomponenten. Komponenten sind eine Spezialisierung von Klassen. Sie können deshalb Strukturmerkmale wie Attribute oder Operationen haben, an Generalisierungen teilnehmen und über Assoziationen mit anderen Komponenten in Beziehung gesetzt werden. Im Gegensatz zu einer Klasse ist eine Komponente als Modul abgeschlossen und bietet gegen aussen wohldefinierte Schnittstellen (Interfaces) an. Oft besteht eine Komponente aus mehreren Klassen oder anderen Komponenten. Je nach Blickpunkt gibt es zwei unterschiedliche Sichten auf eine Komponente: eine Black-Box-Sicht, die nur den Rand (Schnittstelle, angebotene Dienste) zeigt, und eine White-Box-Sicht, die auch die innere Struktur der Komponente zeigt. 9
Komponentenbasierte Softwaresysteme sind zum Beispiel Java Beans, ActiveX, DCOM, Corba,... Falls bei einem System die Austauschbarkeit der Klassen sehr wichtig ist, können auch normale Klassen als Komponenten definiert werden. Um das Innere einer Komponente darzustellen, benutzt ein Komponentendiagramm auch Notationselemente, die sonst in Klassen- oder Kompositions-Struktur- Diagrammen verwendet werden, wie zum Beispiel Klassen, Interfaces oder Parts (die Kompositions-Teile eines Objektes). Die Black-Box Sicht einer Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Das Schlüsselwort «component» sowie ein Symbol in der rechten oberen Ecke unterscheiden die Notation einer Komponente von jener einer Klasse. 10
Eine Komponente wird ähnlich wie eine Klasse als Rechteck mit einem Namen gezeichnet. Zusätzlich ist das Schlüsselwort «component» oder ein Komponenten- Symbol eingefügt. Die realisierten und benötigten Schnittstellen der Komponente definieren vollständig das Verhalten einer Komponente. Schnittstellen können entweder direkt mit der Komponente kommunizieren oder über einen Port, d.h. über eine separate Klasse, welche dieses Interface implementiert. 11
Beispiel einer Text-Komponente mit zwei angebotenen und einer benötigten Schnittstelle Das Beispiel hier zeigt die angebotenen Schnittstellen als Lollipops (Scrollable, ImageObserver) und die benötigten als Socket (EventListener). Zu lesen: JTextArea benötigt (<<uses>>) einen EventListener und implementiert (<<is>>) einen Scrollbar sowie einen ImageObserver (zum Einlesen von Bildern). 12
Die White-Box-Sicht zeigt die innere Struktur der Komponente. Die Komponente JTextArea könnte zum Beispiel aus einer View (für das User Interface), einem Model (für das Verwalten der Daten) sowie aus einer Klasse TransferHandler (für das Verarbeiten von Drag und Drop) bestehen. 13
Die Komponente (oder Klasse) KeyEventHandler implementiert in diesem System den EventListener für die Komponente JTextArea. 14
Artefakte modellieren konkrete Bestandteile des Softwaresystems aus der realen Welt wie zum Beispiel Dateien mit Programmcode, Datenbanken, Hier ist konkret ein Java Archiv (jar-file) notiert. Auch ein Artefakt kann Teil eines Komponentendiagramms sein. 15
Verteilungsdiagramme spezifizieren die physische Hardware- und Softwareumgebung und die Verteilung der Komponenten in dieser Umgebung. Verteilungsdiagramme werden vor allem in der Design-Phase erstellt. Damit kann entschieden werden, welche Hardware und Software-Komponenten eventuell beschafft werden müssen, sowie welche Kommunikationswege zwischen den Komponenten nötig sind. Oestereich S.109f 16
Vgl. Oestereich Kap 2.5 Seiten 112-126 17
Auch die Pakete sollten einfache, beschreibende Namen haben, welche den Sinn des Pakets klar machen. 18
Ein Paket fasst eine Menge von Modellelementen (Klassen, Komponenten, Interfaces, ) zu einer Gruppe zusammen und bildet einen Namensraum (Namespace) für sie. Die Elemente innerhalb eines Paketes müssen eindeutige (verschiedene) Namen haben. Pakete können andere Pakete als Unterpakete enthalten. Sie gliedern die Modellelemente hierarchisch in eine Struktur, analog zu einem Dateisystem (Directory). Jede Klasse, Interface, gehört jeweils nur zu einem Paket. Oft wird statt Paket auch der Name Subsystem oder Kategorie verwendet. 19
Falls die Interna des Pakets aufgezeichnet werden, bietet es sich an, den Paketnamen auf den Reiter zu schreiben. Auch die Pakete sollten (kurz) dokumentiert werden (Aufgaben-, Rollen- Kurzbeschreibung, 20-30 Wörter). Falls die Sichtbarkeit der Klasse fehlt, ist die Klasse public. Die access Beziehung entspricht dem Java import, bzw. dem C# usage Befehl. Die import Beziehung entspricht einem public import, dieses wird in Java und C# nicht unterstützt. 20
Paketdiagramme dienen der Übersicht des Systems und enthalten darum nur die wichtigsten Klassen und nur die wichtigsten Details (Attribute, Operationen) davon. Der voll qualifizierende Name der Klasse innerhalb des Pakets wird zusammengesetzt aus dem Paket-Namen und dem Klassennamen. In Java package myns.myapp.ui; In C# namespace myns.myapp.ui { }... 21
Die in Java oder C# importierten Elementnamen sind jeweils nur im importierenden Paket verfügbar, d.h. wenn das restaurantkette, welches restaurantsystem importiert kann nicht auf PdfErzeuger zugreifen. Dies entspricht der UML access Beziehung. Um ein UML import zu simulieren, muss die entsprechenden access Beziehung hinzugefügt werden. Java: package restaurantkette; import restaurantsystem; import werkzeuge; public class Restaurant {... } C# namespace restaurantkette { using restaurantsystem; using werkzeuge; public class Restaurant {... } 22
Eine positive Beschreibung führt zu einem klaren Gruppennamen. Eine negative Kategorisierung ist von der Art: alles, was nicht zu gehört. Dies führt zu keinem geeigneten Paket (-namen). 23