UML-Analysemodell erstellen

• grober Entwurf fürs Design, enthält keine Operationen
• Identifizieren von Objekten, Klassen, Attributen und Beziehungen
• Dient Verständigung Kunde-Firma (Businessobjekte identifizieren)
• keine fertige Lösung (weitere Diagramme nötig, Ausprägung kann sich dabei ändern)
• Nebenziel: Doppelten Code vermeiden, viel Wiederverwendbarkeit ermöglichen

Unterscheidung Analyse- und Designmodell

• Statisch (Analysemodell)
  • beschreibt Struktur eines Systems (Klassendiagramme )
  • Nur Objekte, welche der Kunde wahrnimmt; aus Anwendersicht modellieren
  • ggf. ergänzendes Objektdiagramm für Kunde erstellen (verständlicher)
  • nur rudimentäre Domain-/Analyseklassen, Attribute, Operationen und ihre Beziehungen
  • Statisches Analysemodell zeigt Klassen und deren Beziehungen. Besteht aus einem oder mehreren Klassendiagrammen.
• Dynamisch (Designmodell)
  • Stellt Technologie der Implementierung dar (Wie können Anforderungen geleistet werden?)
  • Modell um weitere Informationen ergänzt
  • Die Abläufe erklären

Ablauf

An Ende von jedem Schritt steht Diagramm, welches erweitert wird.

1. Klassen analysieren

1. Kandidaten finden (Use Case analysieren nach Substantiven)
   1. Personen/Rollen
   2. Organisationen
   3. Gegenstände
   4. Verträge/Vereinbarungen

Tipp: Glossar erstellen

2. Aussortieren
   1. unrelevante Klassen (Beispiel: Person statt Kunde und Lieferant)
   2. Operationen
   3. Attribute
3. fehlende Attributzuordnungen
   1. ggf. neue Klassen mit diesen Attributen

Fragestellung: Was ist Superklasse, was Subklasse? Manchmal auch tauschbar

abstrakte Klassen

Bildet Basis für Unterklassen, enthält zentrale Gemeinsamkeiten

immer Startpunkt für Klassenhierarchie

kursive Schreibweise/Schlüsselwort abstract

• keine Objekte
• Unvollständig
• min. eine abstr. Operation

Interface

• Legt durch Signaturen Verhalten von (mehreren) Klassen fest
• kann nicht instanziiert werden
• hat keine Implementierung
• Kennzeichnung: <<interface>>
• Klasse: implements

Besonderheiten Domainklassen

Domainklasse = rudimentäre Klasse zur Verdeutlichung

• muss mindestens in einem Anwendungsfall vorkommen
• braucht min. ein Attribut
• keine Umsetzungsdetails darstellen

2. Assoziationen (Beziehungen) festlegen

Usecase/Aktivitätsdiagramm als Vorlage nutzen. Die Modelle ggf. erweitern.

• konzeptionelle Verbindungen
  • arbeitet für…, Kunde von…
• Besitz
  • hat, Teil von…
• Zusammenarbeit von Objekten

Assoziationen haben im Modell keine Richtungen.

doppelte Assoziationen vermeiden (wenn über Umwege vorhanden)

Aggregation

Klassen sind ein Teil voneinander (Implementierung z. B. als Subklassen)

Können unabh. voneinander existieren

Komposition

Die Bestandteile hängen zusammen und sind aufeinander angewiesen.

Generalisierung

Oberbegriff für etwas (Onlinekredit ist eine Ausprägung eines Kredites).

Vorgehen um UML-Beziehungen festzulegen

1. Kandidaten notieren (Use Case)
   1. Verben
      1. Vorsicht: oft Aktivität statt Beziehung
   2. Substantive im Genitv (z. B. Kreditkarte des Kunden)
   3. Possesivpronomen (seine…)
2. ungeeignetets streichen
   1. erschließbare Assoziationen vermeiden
3. fehlende, relevante Beziehungen hinzufügen
4. Multiplizitäten und ggf. Rollennamen hinzufügen
   1. Schritt kann auch nachträglich gemacht werden

3. Attribute definieren

• Nur sinnvolle Attribute nutzen (Abstraktion).
• Keine Objektattribute (ist dann Assoziation), kann bei Implementation trotzdem anders gemacht werden.
• Attributen auch Datenypen zuordnen.

Bezeichnung Sichtbarkeiten Attribute

Public: für alle anderen Klassen sichtbar, d.h. öffentlich (in der UML: + )
Private: außerhalb der Klasse nicht sichtbar, auch nicht für Unterklassen (in der UML:
Protected: nur für alle Unterklassen sichtbar (in der UML: # )
Package: nur für Klassen im gleichen Paket (“Ordnet’) sichtbar (in der UML: -)

4. Vererbung

• Hauptsächlich Generalisierungen einführen (gemeinsame Merkmale, Ist-Ein-Beziehung)
• Nur wenn logisch sinnvoll, gemeinsame Merkmale und Spezialisierung.
• Überschreibung denkbar
• Wertebereich von Attributen darf eingeschränkt, aber nicht erweitert werden.

5. Feedback einholen

• Was fehlt?
• Was ist unnötig?
• Ist etwas unlogisch?