5. Klassenstruktur. Klassendiagramme, Strukturelemente. 5. Klassen

Transkript

1 struktur Klassendiagramme, Strukturelemente 1

2 Definition Ein Klassenmodell zeigt die statische Struktur des Systems beschreibt, welche Klassen existieren in welchen Beziehungen diese Klassen zueinander stehen Ein Klassenmodell beschreibt die statische Struktur eines Systems. Es besteht aus Klassen mit Attributen und Operationen, die zueinander auf verschiedene Arten in Beziehung stehen können. Das Klassenmodell wird durch ein oder durch mehrere Klassendiagramme beschrieben, welche diese Klassen und ihre Beziehungen zueinander darstellen. 2

3 Klassendiagramm Ist ein UML Strukturdiagramm zur graphischen Darstellung eines Klassenmodells deren Klassen die benötigten Schnittstellen die Beziehungen untereinander Zusätzlich erhält jede Klasse eine kurze Beschreibung (20-30 Wörter), welche den Sinn (den Aufgabenbereich) der Klasse beschreibt. 3

4 Verwendung Das Klassendiagramm stellt die statische Struktur eines Systems dar wird zum Beispiel zum Darstellen von Geschäftsoder Fachklassen verwendet bildet die Struktur eines Lösungskonzepts ab kann in allen Phasen der Software Entwicklung eingesetzt werden Klassendiagramme können als generelles, konzeptuelles Modell der Applikation verwendet werden. In einer späteren Phase können sie aber auch für die detaillierte Modellierung zum konkreten Erzeugen von Programmcode benutzt werden. Das Grob-Klassendiagramm enthält nur die Klassen (ohne Attribute und Operationen) und die Beziehungen dazwischen. Statt von Geschäfts- oder Fachklassen spricht man oft auch von Domänen Modell (Domain Model / Business Model). 4

5 Klasse Eine Klasse beschreibt die Struktur und das Verhalten der Objekte, welche aus ihr erzeugt werden können. Die Klasse hat einen Namen und besteht aus Attributen und Operationen. Klassen werden durch Rechtecke dargestellt Eine Klasse ist ein Datentyp, d.h. die Beschreibung gleichartiger Objekte. Gleichartig heisst dabei, die Objekte haben die gleichen Attribute und Methoden (Objekte können aber verschiedene Zustände haben). Diese Objekte werden von der entsprechenden Klasse erzeugt (instanziiert). Zusätzlich kann eine Klasse (bzw. ihre Attribute und Operationen) auch Zusicherungen (Bedingungen, Regeln), Merkmale (z.b. private, abstract, ) oder Stereotypen (<<create>>, <<instantiate>>, <<delete>>, ) enthalten. Im obersten Teil stehen zuerst allfällige Klassen-Stereotypen (<<interface>>, <<enum>>, ) und darunter der Klassenname (ev. inklusive dem Paketnamen). Namen von Klassen beginnen normalerweise mit Grossbuchstaben. Die Namen von abstrakten Klassen (z. B. Person ) werden kursiv geschrieben. Im zweiten Teil stehen die Attribute der Klasse mit ihrem Namen, ihrem Typ, der Sichtbarkeit (vgl. Folie 10). Im dritten Teil stehen dann die Operationen der Klasse mit ihrem Namen, ihren Parametern, der Sichtbarkeit. Zusicherungen an Klassen können durch Notizenfelder an die Klasse notiert werden (vgl. Folie 11). 5

6 Verantwortlichkeit Jede Klasse hat eine Aufgabe, einen Zweck oder eine Verantwortlichkeit Bevor eine Klasse modelliert wird ist es sinnvoll, die Verantwortlichkeit der Klasse zu definieren. Eine Klasse sollte möglichst nur für einen(!) fachlichen Zusammenhang verantwortlich sein. Andernfalls entstehen viele Abhängigkeiten und ein instabiles Design. Klassen, für welche der Zweck nicht mit wenigen Worten (20-30) erklärbar ist, sind oft ein Hinweis für einen fehlerhaften Design. 6

7 Objekt Ein Objekt ist ein Exemplar (eine Instanz) einer Klasse also eine im laufenden System konkret vorhandene Einheit wird durch ein Rechteck dargestellt enthält keine Operationen Ein Objekt ist ein konkretes Exemplar einer Klasse (hier ein konkreter Customer mit Namen Peter Muster). Ein Objekt hat immer einen aktuellen Zustand. Dieser besteht aus der Belegung der Attribute durch konkrete Werte. Die Operationen gehören zur Klasse, werden darum im Objekt nicht aufgeführt. 7

8 Abstrakte Klasse Eine abstrakte Klasse wird wie eine normale Klasse dargestellt, ausser dass der Klassenname kursiv gesetzt wird. Abstrakte Klassen können selber bereits Operationen und Attribute enthalten, welche dann an die abgeleiteten Klassen vererbt werden. Aus abstrakten Klassen können keine Objekte erzeugt werden. Alle Objekte sind Instanzen von den konkreten (daraus abgeleiteten) Klassen. Statt des kursiven Klassennamens kann der Klassennamen auch mit {abstract} ergänzt werden (vgl. Oestereich Kap 2.2.3). Oft enthalten abstrakte Klassen leere Operationsdefinitionen, welche dann in den abgeleiteten Klassen realisiert werden müssen. 8

9 Parametrisierbare Klasse Eine parametrisierbare Klasse ist eine Art Schablone/Template, mit welcher echte (nichtgenerische) Klassen erzeugt werden können Durch die Angabe der konkreten Parameterwerte (Binding) entstehen dann die daraus hergeleiteten Klassen In Java ist dieses Konstrukt unter dem Begriff Generics bekannt. Beispiele von parametrieserbaren Klassen sind Arrays, Listen, Maps, Hashtables, Trees, Sets, Queues, Das Konstrukt der Parametrisierbaren Klassen darf nicht mit der Vererbung (Ableitung) verwechselt werden! 9

10 Attribut Jedes Attribut hat einen Namen einen Typ (int, String, Account, ) eine Sichtbarkeitsangabe +public, #protected, -private, ~package ev. Zusicherungen z.b. eingeschränkter Wertebereich Klassenattribute gehören allen Objekten dieser Klasse gemeinsam Attribut-Namen beginnen eher mit Kleinbuchstaben. In C# oder Java werden Klassenattribute als static Attribute bezeichnet. public static float interestrate; Abgeleitete oder berechnete Attribute werden im Objekt nicht physisch realisiert, sondern bei Bedarf automatisch berechnet. Sie werden durch einen Schrägstrich /abgelattribut bezeichnet. Das Konstrukt der abgeleiteten Attribute ist eigentlich überflüssig, da diese sowieso durch eine Operation implementiert werden müssen. 10

11 Operation Jede Operation hat einen Namen eine Signatur Argumente und Rückgabewert eine Sichtbarkeitsangabe +public, #protected, -private, ~package Operationen können mehrfach definiert (überladen) sein. Statische Operationen sind globale Prozeduren und damit unabhängig von einem Objekt. Operationen sind Dienstleistungen die von einem Objekt ausgeführt werden können. Sie werden auch Methoden, Services, Prozeduren, Funktionen oder Nachrichten genannt. Die Argumente (Operations-Parameter) können fehlen. Die Argumente können mit den Schlüsselwörtern in, out, und inout gekennzeichnet werden, abhängig davon, ob die Argumente nur gelesen, nur zurückgegeben oder gelesen und zurückgegeben werden. Der Rückgabewert (Resultat, Ergebnis) kann ebenfalls fehlen (void-funktion). Der Name der Operation beginnt mit einem Kleinbuchstaben, ebenso die Namen der Argumente. Operationen können (in abstrakten Klassen oder Interfaces) als {abstract} bezeichnet werden, um anzugeben, dass diese Operation hier nicht implementiert wird. #printreport() : void {abstract} protected abstract void printreport(); Statische Operationen werden als solche deklariert +gettopbalance() : float public static float gettopbalance() Operationen können mehrfach definiert sein (überladen). Sie unterscheiden sich dann in mindestens einem Eingabe-Argument. public boolean checklimit(){ } public float checklimit( float amount ){ } Für Operationen können Zusicherungen (Bedingungen) definiert werden (z.b. amount > 0) 11

12 Interface Ein Interface (Schnittstelle) definiert das (oder einen Teil des) extern sichtbare Verhalten einer Klasse oder Komponente deklariert die nötigen Operationen wird mit dem Schlüsselwort «interface» gekennzeichnet Ein Interface (eine Schnittstelle) ist eine Sammlung von Operations- (und ev. Attribut-) Definitionen, die eine kohärente Verhaltensweise definiert. Die im Interface deklarierten Operationen sind abstrakt. Ein Interface wird durch eine Klasse oder eine Komponente realisiert. Dazu muss die realisierende Klasse (Komponente) alle Operationen des Interfaces implementieren. Die realisierende Klasse kann weitere Operationen und Attribute enthalten. Jede Klasse oder Komponente kann ein oder mehrere Schnittstellen implementieren. Jedes Interface kann durch eine oder mehrere Klassen oder Komponenten realisiert werden. Ein Interface definiert eine Art Vertrag, welche von allen realisierenden Klassen/Komponenten erfüllt werden muss. 12

13 Angebotenes/Benötigtes Interface Ein angebotenes Interface wird durch eine Klasse oder Komponente realisiert und mit einem Kreis gezeichnet. Ein benötigtes Interface ist für die Klasse oder Komponente erforderlich, um seine Funktion korrekt wahrzunehmen. Die Klasse TemperaturSensor implementiert das Interface Sensor (also die darin verlangten Operationen). Die Klasse AirCondition braucht einen Sensor, um richtig funktionieren können und benutzt dazu die angebotenen Dienste der Klasse TemperaturSensor. Falls die Klasse TemperaturSensor weitere Dienste anbietet, werden diese von AirCondition nicht benutzt. 13

14 5.1 Beziehungen Beziehungselemente in Struktur-Diagrammen Vgl. Oestereich Kap 2.3 Seiten

15 Definition Eine Beziehung ist eine gegenseitige Verbindung (Link). Die drei wichtigsten Beziehungsarten in der objektorientierten Modellierung sind Generalisierung (Vererbung) Assoziation (Aggregation, Komposition) Abhängigkeit («use», «call», «derive», ) Vererbung: Die Klasse PrivateAccount erbt von der Klasse Account class PrivateAccount extends Account{... } Assoziation: Der Customer hat eine Adresse: class Customer{ Address address;... } Abhängigkeit: Der BankOfficer führt eine Geldeinzahlung über aus. Er benutzt dazu einen Account. bankofficer.deposittransaction(account, 500); 15

16 Verwendung Nachdem im Klassendiagramm die verschiedenen Typen (Klassen) definiert sind, ist der nächste Schritt die Beschreibung der Beziehungen dieser Klassen untereinander. In allen Strukturdiagrammen stehen gewisse Klassen (Classifier) in Beziehung zueinander. Die verschiedenen Beziehungselemente helfen dabei, die verschiedenen Arten von Beziehungen zu unterscheiden. Classifier sind zum Beispiel Klassen, Interfaces, Packages oder Komponenten. 16

17 Generalisierung Die Generalisierung gliedert Eigenschaften in einer hierarchischen Ordnung allgemeinere Basisklasse spezialisierte abgeleitete Klasse vererbt die Eigenschaften der Basisklasse an die abgeleitete Klasse Generalisierung (Vererbung, Spezialisierung) ist ein Abstraktionsprinzip zur hierarchischen Strukturierung der Semantik eines Modells. Die abgeleiteten Klassen (Unterklassen) erben alle Eigenschaften (Attribute, Operationen) der Basisklasse (Oberklasse). Diese werden aber im Diagramm in der abgeleiteten Klasse nicht wiederholt. Die abgeleiteten Klassen können die Operationen der Basisklasse überschreiben oder erweitern (spezialisieren), aber nicht eliminieren oder unterdrücken. In UML ist auch die Mehrfachvererbung vorgesehen. Diese wird allerdings in einigen modernen Sprachen nicht unterstützt und schafft viele Probleme. Generalisierung gibt es auch unter Interfaces (Schnittstellen), wenn ein Interface eine Spezialisierung eines anderen Interfaces ist (z.b. das Java List Interface ist abgeleitet vom Collection Interface und dieses wiederum vom Iterable Interface). 17

18 Verwendung der Generalisierung Subtyp-Vererbung Teilmengen Beziehung Vererbung zur Erweiterung JRadioButton hat zusätzliche Attribute und Operationen Vererbung zur Unterstützung allgemeiner Fähigkeiten Abstrakte Klasse für die gemeinsame Basis-Schnittstelle Vererbung von Standardimplementierungen Wiederverwendung von Standard-Code Subtyp-Vererbung: Bei dieser ist die abgeleitete Klasse ein Subtyp der Basisklasse im Sinne eines abstrakten Datentyps: der Wertebereich der abgeleiteten Klasse ist eine Teilmenge des Wertebereichs der Basisklasse (mit ev. zusätzlichen Operationen). Vererbung zur Erweiterung: Die abgeleitete Klasse wird mit zusätzlicher Funktionalität oder zusätzlichen Attribute gegenüber der Basisklasse ergänzt. Dies kann auch durch Überschreiben von Methoden geschehen, um beispielsweise Funktionalität zu ergänzen, die in der Basisklasse nicht relevant ist. Vererbung zur Unterstützung allgemeiner Fähigkeiten: Bei dieser Variante geht es darum, gewisse Basisfunktionalität zu etablieren. Eine Basisfunktionalität wie Serialisierbarkeit oder Vergleichbarkeit wird dabei durch eine abstrakte Klasse (oder Schnittstelle) deklariert typische Beispiele sind Serializable oder Comparable. Vererbung von Standardimplementierungen: Allgemeine für mehrere Typen verwendbare Funktionalität (z.b. clone(), equals(), tostring(), ) wird dabei in einer zentralen Klasse implementiert. Diese Variante dient dazu, allgemeine Programmteile wieder verwenden zu können. 18

19 Assoziation Eine Assoziation beschreibt eine Beziehung oder Verbindung zwischen zwei (verschiedenen) Klassen, ermöglicht, dass zwei Objekte miteinander kommunizieren können, kann mit einem Namen versehen werden, welche die Beziehung beschreibt Wird nicht als Attribut aufgelistet Assoziationen sind nötig, damit zwei Objekte miteinander kommunizieren können sie müssen voneinander wissen, bzw. sich kennen. Die konkrete Ausprägung davon wird Objekt-Link oder Objekt- Verbindung genannt. Assoziationen sind normalerweise Verbindungen zwischen zwei Objekten von verschiedenen Klassen, eine Assoziation kann aber auch Objekte vom gleichen Typ verbinden (rekursive Assoziation). Assoziationen werden dadurch realisiert, dass die beteiligten Klassen entsprechende Referenz-Attribute enthalten: class Customer{ class PrivateAccount { private Name name; private Customer customer; private Address address; private float balance; private PrivateAccount account; } } 19

20 Multiplizität Assoziationen können mit einer Multiplizität versehen werden. Diese gibt an mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert werden kann. Ausserdem kann ein Rollenname und dessen Sichtbarkeit angegeben werden Bsp: Jede Person hat genau eine Adresse, jede Adresse gehört zu genau einer Person. Implementiert bedeutet dies zum Beispiel class Person { private Address address;. } class Address{ private Person person;. } 20

21 Multiplizitäten 1 genau eine 3 genau drei 0..1 null oder eine 0..3 von null bis drei 0..* beliebig viele (auch null) * beliebig viele (auch null) Default Wert, wenn Angabe fehlt 1..* eine oder mehrere Jeder Kunde hat ein oder mehrere Privat-Konti. Die konkrete Implementation (Liste, Array, ) bleibt offen. Die Realisierung von * Multiplizitäten erfolgt über eine Collection (List, Array, Map, ) class Customer{ private Name name; private Address address; private List<PrivateAccount> accounts;... } 21

22 Assoziations-Beziehung Die Beziehung zwischen Student und Kurs (die Einschreibung) soll ein weiteres Attribut (Einschreibe-Datum) enthalten. Dies wird mit Hilfe einer Assoziationsklasse ausgedrückt. Sie wird für die Implementation normalerweise durch eine normale Klasse ersetzt. Die Assoziationsklasse heisst gleich wie die Assoziationsbeziehung (hier Registration). Die Meinung hierbei ist, dass es eindeutige Registration-Objekte gibt, welche die Information enthalten, welcher Student in welchem Kurs eingeschrieben ist. Die Implementation mit einer (normalen) Registration Klasse jedoch führt dazu, dass sich der Student mehrmals im gleichen Kurs registrieren kann. Es fehlt dann nämlich die Einschränkung, dass jede Kombination (Student/Course) als Registration Objekt maximal einmal vorkommen darf. 22

23 Assoziations-Beziehung Als Datenbank-Schema würde die Einschränkung so aussehen: Durch die Eindeutigkeit der Fremdschlüssel- Beziehung wird erzwungen, dass alle Registration-Einträge unterschiedlich sind. Die Assoziationsbeziehung lässt sich nicht ohne Informations- Verlust in ein Klassendiagramm ohne Assoziationsklasse umschreiben. Der Informations-Verlust muss durch eine Notiz (oder durch ein Constraint) im Klassendiagramm behoben werden. 23

24 Gerichtete Assoziation Eine gerichtete Assoziation ist eine Beziehung, die nur in eine Richtung navigierbar ist. Sie wird durch eine offen Pfeilspitze, welche die zugelassene Navigationsrichtung angibt, dargestellt. Der Customer kennt also seine Accounts, der Account kennt aber nicht seinen Besitzer. Es können also nicht ohne weiteres Aufrufe von Methoden vom Customer aus der Klasse PrivateAccount gemacht werden. 24

25 Gerichtete Assoziation Falls der Navigationsausschluss fehlt, ist nicht bestimmt, ob der Account seinen Besitzer kennt oder nicht. Bidirektionale Assoziationen sind genau genommen zwei inverse Assoziationen. Assoziationen sind also nicht dasselbe wir relationale Beziehungen in ER Diagrammen, und dürfen damit nicht verwechselt werden. 25

26 Aggregation Eine Aggregation ist eine Assoziation, deren beteiligte Klassen in einer Ganzes-Teile-Hierarchie stehen beschreibt wie sich etwas Ganzes aus seinen Teilen (logisch) zusammensetzt besteht aus einem Aggregat und den Einzelteilen ist normalerweise eine 1 zu n Beziehung Ein Teil kann zu mehreren Aggregaten gehören (Employee kann mehreren Departments angehören). Ausserdem kann das Aggregat selber wieder Teil eines Ganzen (zum Beispiel einer Firma) sein. Aggregationen und Assoziationen sind oft schwer zu unterscheiden. Der resultierende Programmcode ist der gleiche. Falls man sich nicht sicher ist, wählt man darum im Zweifelsfall eine Assoziation. 26

27 Komposition Eine Komposition ist eine Aggregation, bei welcher die Teile vom Ganzen existenzabhängig sind beschreibt, wie sich das Ganze aus den Einzelteilen zusammensetzt ist eine 0..1 zu n Bedingung erfüllt ansonsten die gleichen Bedingungen wie die Assoziation Die Lebenszeit der Teile ist abhängig von der Lebenszeit des Ganzen: Wenn die Firma (Company) aufgelöst wird, werden auch die einzelnen Filialen (BranchOffice) geschlossen. Die Kardinalität beim Aggregat ist immer 0 oder 1, d.h. jedes Teil kann nur einem Aggregat zugehören. Ein anderes typisches Beispiel einer Komposition ist eine Rechnung (oder Bestellung) mit ihren einzelnen Positionen. Sobald die Rechnung gelöscht wird, werden auch die einzelnen Positionen sinnlos. Die Rechnung übernimmt bestimmte Aufgaben für das Ganze, wie zum Beispiel das Berechnen der Gesamt-Summe oder der Anzahl Positionen. 27

28 Abhängigkeit Eine Abhängigkeit ist eine Beziehung von einem oder mehreren Quellelementen zu einem oder mehreren Zielelementen Typische Arten der Abhängigkeit sind call, create, derive, realize, permit, use, abhängig unabhängig Die Abhängigkeit ist dadurch gegeben, dass das das Zielelement (unabhängiges Element) für die Spezifikation oder die Implementation des Quellelements (abhängiges Element) erforderlich ist. Beispiele von Abhängigkeiten sind: «call» Eine Operation des unabhängigen Elements wird vom abhängigen Element aufgerufen. «create» Das unabhängige Element wird vom abhängigen Element erzeugt. «derive» Das abhängige Element ist vom unabhängigen Element abgeleitet. «permit»das abhängige Element hat die Erlaubnis, private Eigenschaften des unabhängigen Elementes zu verwenden. «realize» Das abhängige Element implementiert das unabhängige Element. «use» Das abhängige Element benutzt das unabhängige Element (zum Beispiel als Parameter in einem Operationsaufruf). Abhängigkeiten gibt es zwischen Paketen (ein Paket benutzt Klassen von einem anderen Paket), zwischen verschiedenen Klassen oder zwischen Operationen und Klassen (die Klasse wird als Operationsparameter benutzt). 28

29 Finden der Klassen Beispiel: Banken Applikation Die Idee der Objekt Orientierten Synthese stammt aus dem OOAD Skript von André-Claude Godet. 29

30 Vorgehensweise Kandidaten für Fachklassen -> Substantive -> gelb Attribute -> Substantive -> rot Operationen -> Verben -> blau Multiplizitäten -> Mengen-Angaben -> grün Beziehungen -> Örtliche Nachbarschaft (zum Beispiel im gleichen Satz) Um (erste) Klassen, Attribute und Operationen für das Fachklassendiagramm zu finden, kann man das Pflichtenheft systematisch analysieren. Dabei sucht man alle Substantive, Verben und Mengenangaben und streicht diese farbig an. 30

31 Kandidaten für Fachklassen Als erstes streichen wir alle Substantive gelb an. Dies sind erste, provisorische Kandidaten für Fachklassen. 31

32 Kandidaten für Attribute Beim Überprüfen der Substantive versuchen wir zu entscheiden, welche davon eher Attribute statt Fachklassen sind. Als Attribute kommen diejenigen Objekte in Frage, welche einen einfachen Aufbau haben (Datum, Kontonummer, ) oder nur einmal vorhanden sind (Name, Geburtsdatum, Zins, ). Weiter unterstreichen wir diejenigen Substantive, welche eventuell als Klasse/Attribut im System nicht notwendigerweise vorhanden sein müssen. 32

33 Kandidaten für Operationen Als drittes streichen wir aktive Verben blau an. Hilfsverben werden ebenfalls unterstrichen. Diese dienen eventuell später für das Erfassen eines Zustandsdiagramms oder zum Erkennen von Bedingungen. 33

34 Multiplizitäten Die Multiplizitäten können wir aus den Mengenangaben erkennen. Jede Person hat einen Namen, ein Geburtsdatum, eine Adresse, beliebig viele Konten, 34

35 Beziehungen Gewisse (offensichtliche) Beziehungen können wir erkennen, wenn wir die Sätze untersuchen: Kunde Konto Kunde Adresse Kontotyp Zinssätze Weitere Beziehungen sind in den Use Case Diagrammen zu finden worauf/ womit operieren die Akteure? Alle korrekten (und nötigen) Beziehungen zu finden ist allerdings oft schwierig und oft erst am Ende der Design Phase möglich. 35

36 CRC Karten (Class, Responsibilities and Collaborations Cards) können dazu dienen, eine erste Grobskizze der Fachklassen mit deren Attributen und (public) Operationen zu erstellen. Weitere (private) Operationen kommen oft im späteren Verlauf des Designs dazu. Collaborations zeigen erste Beziehungen zu anderen Klassen auf. 36

37 37

38 Fachklassen Diagramm Ein erster Entwurf Aus der Beschreibung werden die nötigen Attribute (Name, Vorname, Geburtsdatum, ) der Klassen ermittelt. Ausserdem die nötigen Operationen (checklimit(), getbalance(), printdata(), ) Statt eines berechneten Attributs /balance ist hier im Account bereits die entsprechende Methode modelliert. Da ein Kunde mehrere Adressen haben kann, wird eine zusätzliche Klasse Address benötigt. 38

39 System Klassen Bank Administration BankAdministration ist eine Singleton Klasse, sie darf im System nur einmal erzeugt werden. Darum benötigt sie eine statische getinstance() Methode, der Konstruktor ist private. Sie ist die zentrale Schnittstelle des Systems und kennt (findet) die Liste der Kunden und Konten. Die BankAdministration Klasse ist für die eindeutige Vergabe der customerid zuständig. Diese wird beim Erzeugen eines neuen Kunden vergeben. getglobalstate und checkaccounting sind Methoden zum Überprüfen ob alle Transaktionen korrekt sind. Diese beiden Klassen gehören nicht mehr zu den Fachklassen. Sie funktionieren als Controller, Manager oder Service-Provider,. Das ist auch daran zu erkennen, dass beide Klassen nur wenige (oder keine) Attribute, aber viele Operationen besitzen. 39

40 Checkliste Statisches OOA Modell Klassen und Assoziationen 40

41 Klassendiagramm In einem ersten Entwurf hat jede Klasse entweder nur einen Namen oder wenige wichtige Attribute mit deren Typen und die wichtigsten Operationen mit deren Sichtbarkeit eine Kurzbeschreibung von 25 oder weniger Wörtern ihre (vermutlichen) Beziehungen (Assoziationen) durch eine Verbindungslinie zu den anderen Klassen eingetragen 41

42 Klassen finden Mögliche Klassen sind Personen und deren Rollen Konkrete Objekte, Dinge, Informationen Informationen über Aktionen (Commands) Orte, Zeitangaben, Organisationen (Firma, Verein, Schule, ) Ereignisse (was, wer, wann, wo, ) Kataloge, Listen, Bestellungen Diese werden aus den Subjekten der Use Cases und Aktivitätsdiagrammen oder aus dem Pflichtenheft extrahiert. 42

43 Analyse: Klassen Mögliche Fehler: Klassen, die bloss eine Menge von Objekten verwalten Zu viele, zu kleine Klassen Klasse, welche die Benutzeroberfläche modelliert Klasse, die Entwurfs- oder Implementierungsdetails modelliert Klasse, die elementar und keine Architektur- oder Fachklasse ist (Datum, Name, Preis, ) Im Klassendiagramm muss geprüft werden, ob wirklich alle Klassen wichtige und eigenständige Klassen sind. Nicht ins Klassendiagramm gehören - Klassen, welche bloss Container sind (List, Vector, Array, Map, ) ohne zusätzlichen Nutzen - Klassen, welche keine eigene Funktionalität oder Rolle haben (Geburtsdatum, Bestellnummer, ) - Komponenten wie GUI oder Persistenz - Ableitungen von Standard-Interfaces wie Serializable oder Iterator 43

44 Analyse: Klassenname Der Klassenname soll der Fachterminologie entsprechen ein Substantiv im Singular sein so präzise wie möglich gewählt werden dasselbe ausdrücken wie die Gesamtheit der Attribute nicht die Rolle dieser Klasse in einer Beziehung zu einer anderen Klasse beschreiben eindeutig im Paket bzw. im System sein und sich auch semantisch von allen Namen aller anderen Klassen unterscheiden Gut gewählte Klassennamen helfen enorm, das System leichter zu verstehen. Die richtige Wahl der Klassennamen ist darum von grosser Bedeutung und sollte entsprechendes Gewicht bekommen. Der Klassenname sollte darum ein Wort aus dem Problemgebiet sein (z. B. in Cargo Cruise: Buchung statt Bestellung, Kunde oder Reisender statt Person, Reise statt Ausflug, Route oder Teilstrecke statt Tour ) 44

45 Analyse: Attribute Sind alle Attribute wirklich notwendig? Ist die Anzahl der Attribute pro Klasse angemessen? Sind die Typen / Sichtbarkeiten korrekt? Könnten einfache Attribute zu einer Datenstruktur zusammengefasst werden? Müsste eine Gruppe von Attributen in eine eigene Klasse ausgelagert werden? Ist das Attribut ein Klassenattribut (static)? Es ist oft nicht einfach zu entscheiden, ob ein Attribut korrekt gewählt wurde, oder ob es in eine eigene Klasse ausgelagert werden müsste. Eine Klasse beschreibt eine Objektidentität und hat eine den anderen Klassen gleichgewichtige Bedeutung im System. Die Existenz des Objektes ist unabhängig von der Existenz anderer Objekte, der Zugriff ist in der Umgebung des Objektes grundsätzlich in beide Richtungen denkbar. Ein Attribut hat keine Objektidentität, seine Existenz ist abhängig von der Existenz anderer Objekte, der Zugriff geschieht immer über das Objekt. Attribute haben im System eine untergeordnete Bedeutung. 45

46 Analyse: Attribute Unnötige Attribute Es beschreibt den internen Zustand eines Lebenszyklus und ist ausserhalb des Objekts nicht sichtbar. Es beschreibt Entwurfs- oder Implementierungs- Details. Es handelt sich um ein abgeleitetes (berechnetes) Attribut, das nur aus Performance-Gründen eingefügt wurde. Es definiert eine Assoziation. Im Modell sollten nur Attribute aufgelistet werden, die fachlich relevant sind. Attribute, welche bloss für die Implementation gewisser Operationen nötig sind, gehören nicht ins Klassendiagramm. 46

47 Analyse: Attributname Der Attributname soll kurz, eindeutig und im Kontext der Klasse verständlich sein möglichst ein Substantiv sein (kein Verb) den Namen der Klasse nicht wiederholen bei komplexen (strukturierten) Attributen der Gesamtheit der Komponente (Information) entsprechen nur fachspezifische oder allgemein übliche Abkürzungen enthalten Attribute sollten, ähnlich wie Klassen, sprechende und der Fach- Terminologie entsprechende Namen haben. Dies erleichtert das Verständnis für den Zweck dieses Attributes. Es sollten darum auch möglichst keine Abkürzungen verwendet werden. Das Wiederholen des Klassennamens ist unnötig und sollte darum vermieden werden. Namen von strukturierten Attributen sollten das Ganze beschreiben (z.b. adresse -> strasse/nr/plz/ort/land). 47

48 Analyse: Operationen Die Operationen findet man in der Spezifikation und den Szenarien. Falls nötig werden Listen- Operationen (Suche, Auswahl, ) hinzugefügt. Operationen werden in der Vererbungshierarchie so hoch wie möglich eingetragen Die Operation muss einen geeigneten Namen haben, welcher beschreibt, was die Operation tut (Verb) Verwaltungsoperationen (new, delete, get/set, link, unlink, ) werden nicht im Modell eingetragen Falls das Klassendiagramm sehr komplex ist, werden auch Methoden wie update, read, print, nicht ins Klassendiagramm eingetragen. Falls aus dem Namen der Operation nicht eindeutig klar ist, was sie tut, sind ev. Aktivitäten- oder Sequenzdiagramme zur Beschreibung nötig. Für einfache Operationen genügeine textuelle Beschreibung. 48

49 Beziehungen Es besteht eine Abhängigkeit oder Assoziation zwischen A und B, falls A ein physischer oder logischer Teil von B ist A eine Beschreibung für B ist A ein Mitglied von B ist A eine organisatorische Einheit von B ist A ein B benutzt A mit B kommuniziert A ein B besitzt Eine Assoziation zwischen zwei Klassen A und B liegt vor, wenn die beiden in irgend einer Form in direkter Beziehung stehen. Beziehungen findet man in der Spezifikation, den Beschreibungen der Geschäftsprozessen oder (falls bereits ein DB-Modell vorliegt) anhand der Fremdschlüssel. 49

50 Eins zu eins (1:1) Assoziation Klassen verschmelzen? Zwei Klassen sind nötig, falls die Verbindung in eine oder beide Richtungen optional ist sich die Verbindung zwischen beiden Objekten ändern kann es sich um zwei umfangreiche Klassen handelt die beiden Klassen eine unterschiedliche Semantik besitzen. 1:1 Assoziationen sind mögliche Kandidaten für Klassen- Verschmelzungen. Beispiel: Person Name. Jede Person hat einen Namen, jeder Name gehört genau zu einer Person. Da ist es ev. sinnvoll, Name nicht als eigene Klasse zu führen (ausser die Klasse ist sehr umfangreich, hat viele Attribute oder eigene wichtige, funktionale Operationen). 50

51 Analyse: Assoziation Eine Benennung der Beziehung kann sinnvoll oder sogar notwendig sein. Sie ist notwendig, wenn zwischen zwei Klassen mehrere Assoziationen bestehen. Bei reflexiven Assoziationen ist immer ein Rollenname notwendig. Oft ist es sinnvoll, einer Assoziation einen Namen (eine Rolle) zuzuordnen, welche die Beziehung erklärt. Zum Beispiel dann, wenn die Art der Beziehung nicht offensichtlich ist. Das Benennen der Beziehung kann auch dazu beitragen zu erkennen, ob die Assoziation korrekt und nötig ist. Rollennamen für Assoziationen sind besser als ein Attributname oder ein Verb. 51

52 Analyse: Multiplizitäten Aus den Anforderungen an das System ergibt sich, ob ein Schnappschuss (1 bzw Kardinalität) oder die Historie (0..n-Kardinalität) zu modellieren ist. Eine 1, bzw Beziehung liegt vor, wenn nur der aktuelle Zustand dargestellt werden muss. Many-Kardinalitäten sind erforderlich, falls Listen von Objekten zu verwalten sind (mehrere Adressen, Konti, Bestell-Positionen, ) oder falls eine History (vgl. Beispiel) vorliegt. 52

53 Analyse: Kann / Muss Assoziation Die Muss-Beziehung verlangt, dass für jeden neuen Kunden sofort eine Adresse erzeugt werden muss. Der Kunde kann einen Account haben. Falsche Muss-Beziehungen führen zu unnötigen Einschränkungen. Kann-Assoziation Untergrenze 0 Muss-Assoziation Untergrenze 1 Falls eine 1:1 Beziehung besteht, müssen die beiden Objekte auch gleichzeitig wieder gelöscht werden. Im Modell ist sicherzustellen, ob tatsächlich eine Muss-Beziehung besteht oder ob es sich um eine Kann-Beziehung handelt. Andernfalls entstehen unnötige Einschränkungen oder Aufwände. Kompositionen sind üblicherweise Muss-Beziehungen. 53