Objektdiagramm Komponentendiagramm Paketdiagramm. 6. Weitere Strukturdiagramme

Transkript

1 6. Weitere Strukturdiagramme Objektdiagramm Komponentendiagramm Paketdiagramm 1

2 6.1 Objekte Ausprägungsspezifikation von Klassen und Assoziationen 2

3 Definition Das Objektdiagramm zeigt eine bestimmte Sicht auf die Struktur des modellierten Systems. Die Darstellung umfasst dabei typischerweise Ausprägungsspezifikationen von Klassen und Assoziationen. Das Objektdiagramm ist eine Art Schnappschuss. Es zeigt den Zustand, also die Belegung der Attribute eines Objektes zu einem bestimmten Zeitpunkt. 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

4 Verwendung Das Objektdiagramm wird nicht so oft verwendet. Es eignet sich dazu, beispielhaft ein zur Laufzeit existierendes Objektnetz mit sein Attributwerten zu visualisieren. Es kann zum Beispiel dazu benutzt werden, das Klassendiagramm und dessen Beziehungen zu verifizieren. Objektdiagramme werden nur verwendet, wenn komplexe Klassendiagramme anhand von konkreten Beispielen verdeutlicht oder überprüft werden sollen. 4

5 Objekt: Notation Ein Objekt ist eine konkrete Realisierung (Instanz) einer Klasse. Im Objektdiagramm wird der momentane Zustand des Objekts (hunger = true) dargestellt. Objekte haben keine Operationen. 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

6 Beispiel: Bank 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

7 Beispiel: Firma 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

8 6.2 Komponenten Komponenten-Diagramm 8

9 Definition Eine Komponente ist ein modulares (in sich abgeschlossenes) Teil eines Systems. ist so strukturiert, dass sie in ihrer Umgebung einfach durch eine andere, äquivalente Komponente ersetzt werden könnte. kann als eine spezielle Klasse mit Attributen, Operationen, Beziehungen, gesehen werden. lebt/läuft oft in einer Umgebung (z.b. einem Container). 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

10 Verwendung Komponentendiagramme werden gebraucht für die Spezifikation der Software-Architektur zur Aufteilung des Systems in Subsysteme (zum Beispiel Persistenz-, Business- und GUI-Schicht) die Modellierung von komponentenbasierten Softwaresystemen die Aufteilung der Aufgaben des Systems in verschiedene Teil-Bereiche und ihre Schnittstellen (Interfaces) Kann aus logischen oder physikalischen Komponenten bestehen. 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

11 Notationselemente Eine Komponente hat einen Namen, den Stereotyp «component» sowie optional ein Symbol Ports definieren die Kommunikations-Punkte der Komponente. 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

12 Notationselemente Der Delegations- Konnektor zeigt an, welches Subsystem letztlich für die Schnittstelle verantwortlich ist. 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. 12

13 Alternative Schreibweise Alternativ lässt sich das vorherige Komponentendiagramm auch so darstellen. Es fehlt hier das Subsystem. 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. 13

14 Port Ein Port definiert einen Kommunikationspunkt, durch den eine Komponente mit seiner Umgebung kommunizieren kann. Die Kommunikation wird von der Komponente selber (als Methode) oder durch einem inneren Teil (eigene Klasse) implementiert. Die Sichtbarkeit eines Ports ist public. Ports haben häufig keinen Namen (anonym). Die Suchmaschine realisiert das ProductSearch Interface und bietet dieses über den searchport gegen aussen an. 14

15 Port Ports können einfach oder komplex sein. Komplexe Ports können gleichzeitig die benötigten und angebotenen Schnittstelle anzeigen. searchport benötigt zum korrekten Funktionieren eine Inventory-Schnittstelle und bietet anderseits die Schnittstelle SearchBooks und SearchVideo Die Beziehung verschiedener Komponenten kann entweder als Linie zwischen den Ports oder über die Schnittstelle gezeichnet werden. 15

16 Komponente:Black-Box-Sicht Die Black-Box-Sicht einer Komponente zeigt die Schnittstellen, die die Komponente gegen aussen anbietet bzw. die sie von anderen Komponenten beziehen kann/muss. EventListener «component» JTextArea Scrollable ImageObserver 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). 16

17 Komponente: White-Box-Sicht In der White-Box-Sicht werden die inneren Bestandteile (Klassen, Komponenten, Subsysteme) einer Komponente aufgezeichnet. «component» JTextArea «component» View «subsystem» Model TransferHandler 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. 17

18 Artefakt Ein Artefakt ist eine physisches Bestandteil eines Software-Systems, welches beim Software- Entwicklungsprozess benutzt oder erzeugt wird. Artefakt Stereotyp «artefact» TextAreaSystem.jar Name des Artefakts 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. 18

19 6.3 Pakete Paket Diagramm 19

20 Verwendung Ein komplexes Gesamtsystem sollte möglichst früh in Pakete (Subsysteme) unterteilt werden Reduktion der Komplexität Gruppen von Use Cases (Funktionsgruppen) Klassen, die fachlich zusammengehören (Produkte-Gruppe, Personen-Typen, usw.) Klassen, die stark interagieren oder zur gleichen Schicht (Layer) gehören, Klassen, welche ähnliche Funktionalität haben (Controller, DB-Zugriff, usw.) können in Paketen zusammengefasst werden. Auch die Pakete sollten einfache, beschreibende Namen haben, welche den Sinn des Pakets klar machen. 20

21 Definition Ein Paket fasst Klassen, Interfaces, Komponenten, zusammen bildet einen Namespace kann Unterpakete enthalten kann andere Pakete importieren (benutzen) kann benutzt werden, um eine hierarchische Struktur zu bilden 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. 21

22 Paket Diagramm Es werden nur die wichtigsten Klassen im Inneren eines Pakets notiert und davon oft bloss deren Namen 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 { }... 22

23 Notationselemente 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, 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. Die import-beziehung macht das Referenzieren von Elementen eines Pakets über unqualifizierte Namen möglich, so als wenn das importierende Paket diese Elemente selbst enthalten würde. Die Paketgruppe kann auch als Paket mit Unterpaketen gezeichnet werden. 23

24 import access Auf die public Klassen von importierten Paketen kann direkt (ohne Angabe des Namespaces) zugegriffen werden. Java und C# unterstützen keinen transitiven public Import, sondern bloss die access-beziehung. Auflösen der import Beziehung 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 {... } 24

25 6.4 Spezielle Paketdiagramme Modell-Diagramm Verteilungsdiagramm 25

26 Modell-Diagramm Zeigt die logische Struktur (Architektur) eines Systems. Die logischen Modell- Elemente werden durch ein Dreieck markiert. 26

27 Verteilungsdiagramm Das Verteilungs (oder Deployment)-Diagramm zeigt die physikalische Umsetzung der verschiedenen Komponenten (welche Komponente wird durch welches Artefakt implementiert). 27

28 Verteilungsdiagramm Verteilungsdiagramme spezifizieren auch 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. 28