# Klassen Diagramme https://www.hanser-elibrary.com/doi/epdf/10.3139/9783446431973 - Klassen werden als Boxen dargestellt mit - Name - Attribute - Methoden ### Aufbau Klassen-Diagramm #### 1. Bereich: Name der Klasse - beginnt mit Großbuchstaben - ist ein Nomen - sollte die Klasse beschreiben #### 2. Bereich: Attribute der Klasse Es gibt zwei Arten die Attribute darzustellen - Inline, dabei muss angegeben werden: - [Sichtbarkeit](UMLKlassenDiagramme.md#sichtbarkeit-von-attributen-methoden) - Name - Typ (primitiv / komplex) - Durch [Assoziation](UMLKlassenDiagramme.md#association) - bspw.: entries  #### 3. Bereich: Methoden der Klasse - Haben 4 Elemente: - [Sichtbarkeit](UMLKlassenDiagramme.md#sichtbarkeit-von-attributen-methoden) - Name - ggf Parameter - Rückgabewert - Bspw.: ```+ addEntry(int number, string description): void``` ### Sichtbarkeit von Attributen / Methoden - **Public (+)** - Jedes Objekt anderer Klassen kann zugreifen - **Protected (#)** - Jedes Objekt der Klasse und der Unterklassen kann darauf zugreifen - **Package (~)** - Jedes Objekt, deren Klasse im selben Package ist, kann darauf zugreifen - **Private (-)** - Nur das Objekt selbst kann darauf zugreifen ### Beispiel Klassen Diagramme: - 3 Klassen (Student, Course, LectureHall) - Student kann keine bis n Lectures beitreten - Courses können in keine bis einer LectureHall stattfinden - Student hat einen first name, last name, date of birth... - etc.  ### Erstellung eines Klassen-Diagramms 1. Identifizierung der Klassen -  2. Identifizierung der Attribute -  3. Identifizierung von Generalisierungen -  4. Identifizierung von Assoziationen und Aggregationen -  _Entstandenes UML-Diagramm ist nicht einzig korrektes!_ ## Objekt Diagramme ### Beispiel Objekt Diagramme: - 4 Instanzen / Objekte vom Typ Student (Helen, Mike, Paul) - Helen ist im Kurs oom und iprog - Der Kurs db ist in der LectureHall lh2 -  ## Relationship Overview Klassen arbeiten zusammen über verschiedene Arten von Relationships - Relationships werden als Linie zwischen den Boxen dargestellt mit - Name - Leserichtung - Multiplizität - Sind als Intervall dargestellt _[Min..Max]_ - Falls es kein Limit gibt: * - Falls Min = Max: nur eins hinschreiben - Bsp.: - ```[0..1]```: Attribut hat 0 - 1 Wert - ```[5]```: Attribut hat genau 5 Werte - ```[*]```: Attribut hat 0 bis unendlich Werte - ```[3..*]```: Attribut hat 3 bis unendlich Werte ### Association Wenn ein Objekt einer Klasse mit Objekten einer anderen Klasse arbeitet  - schwächstes Relationship - Kommunikationspartner können auf Attribute und Methoden des Anderen zugreifen - Bsp.: -  #### Navigatability - **x**: Darauf ist nicht zugreifbar - **>**: Darauf kann zugegriffen werden - nix: undefined ### Aggregation Wenn eine Klasse eine Referenz zu Objekten einer anderen Klasse besitzt und teilt  - Objekte existieren auch unabhängig - Es können auch [mehrere Objekte](UMLKlassenDiagramme.md#relationship-overview) in einer Aggregation verbunden werden ### Composition Wenn eine Klasse Objekte einer anderen Klasse enthält  - Nur maximal eine Instanz - Objekt kann nicht allein existieren ### Generalization (Inheritance) Wenn eine Klasse ein Typ einer anderen Klasse ist  ## Erstellung von Klassen ### Appropriate Level of detail Detail der Zeichnung sollte abhängig vom [SDLC](IntroductionOOAD.md#software-development-lifecycle-sdlc) sein. 1. keine Details (erste Analyse für die ersten Diskussionen des Domänen-Konzepts) -  2. mehr Details (während späterer Analysen) -  3. sehr detaillierte Beschreibung (detaillierte Analyse oder während Implementierung) -  ## N-Ary Association - Relationship zwischen mehr als zwei Klassen - Wird durch hohle Raute in der Mitte der Klassen dargestellt - bspw.:  ### Implementierung in Code von N-Ary Association - nicht existent in Standard-Programmiersprachen #### Using Two Binary Associations  #### Using additional Class  ## Association Class ### Introduction Association Class Erlaubt [N-Ary Associations](UMLKlassenDiagramme.md#n-ary-association) ### Possible Implementations of Association Classes   ## Abstract Class  - nur im Kontext von Generalisierungsbeziehungen sinnvoll ## Interface 