Methodik: Objektorientierte Analyse Statisches Modell erstellen

Freitag, 10.12.04 15.15 Uhr Hauptgebäude XIa öffentlicher Vortrag Claus Huitfeld, University of Bergen, Norway Markup Languages for Complex Documents

Checklisten statisches Modell Checklisten für: Klassen Assoziationen Attribute Vererbung

Checkliste Klasse: Identifizierung 1 Checkliste Klasse: Identifizierung 1. Durch Dokumentenanalyse (Formularanalyse) Merkmale: Attribute/ Bestandteile der bestehenden Dokumente werden zusammengefasst auch zur Identifizierung von Assoziationen geeignet

Checkliste Klasse 2. Mittels Beschreibungen aus Beschreibungen der Use Cases oder allgemeinen Anforderungsbeschreibungen werden Klassen identifiziert Klassen sind - oft Substantive - manchmal aus Verben ableitbar - durch Attribute identifizierbar

Checkliste Klasse 3. Mittels Kategorienbildung Personen und deren Rollen (in jeder Rolle anderes Verhalten  Rolle = Klasse) Datenspeicherung in Folge einer Aktion (Kategorie= Informationen über Aktionen; Bsp.: Bestellung/ Banküberweisung)  Aktion = Klasse Ort im Sinne funktionaler Trennung (Anmelde-/ Warte-/Abholbereiche  Ort = Klasse) Organisationen Ereignisse Kataloge Verträge ....

Checkliste Klasse Analytische Schritte: Validieren Klassenname: - fachterminologisches, aussagekräftiges Substantiv im Singular - semantisch klar abgegrenzt von anderen Klassennamen - die Gesamtheit der Attribute der Klasse ausdrückend - keine Rollenbeziehung zwischen Klassen wiederspiegelnd - eindeutig im Paket  Modellverständlichkeit Kurzbeschreibung der Klasse Abstraktionsniveau: - zu hoch = zu wenige Klassen, zu niedrig = zu viele Klassen - Richtwerte: ca. 1 Mitarbeiterjahr  50 - 100 Klassen 10-100 Mitarbeiterjahre  100 - 1000 Klassen

Checkliste Klasse Analytische Schritte: Validieren Objektverwaltung: keine Klassen modellieren, die Mengen von Objekten verwalten  Modellverständlichkeit Fehlerquellen: - Zu wenig komplexe Attribute  zu viele Klassen + Assoziationen - Jedes konkrete Objekt als Klasse modellieren - Klasse modelliert Entwurfs- und Implementierungsdetails

Checkliste Klasse Ergebnisse: Klassendiagramm Kurzbeschreibung der Klassen Konstruktive Schritte: Welche Klassen lassen sich mittels Dokumentanalyse identifizieren? Welche Klassen lassen sich aus der Beschreibung der Anwendungsfälle identifizieren? Sind Klassen aus Kategorien zu modellieren? Analytische Schritte: Liegt ein aussagefähiger KIassenname vor? Ist das gewählte Abstraktionsniveau richtig? Fehlerquellen: Zu kleine Klassen (aus jedem Dokument eine Klasse modellieren) Modellierung von Entwurfs- und Implementierungsdetails

Checkliste Assoziationen Zuerst notwendige (nicht unbedingt alle möglichen) Assoziationen ermitteln durch/ aus: Dokumentenanalyse Beschreibungen 2. Schritt: bestimmen von: Kardinalitäten Komposition Aggregation

Checkliste Assoziationen Dokumentenanalyse/Beschreibung Use Case Dokumente/ Use Cases, die auch bei Klassenidentifizierung genutzt werden Direkte Assoziationen und Assoziationen als assoziative Klassen identifizieren

Checkliste Assoziationen Analytische Schritte: Validieren Kardinalitäten, Aggregation und Komposition bestimmen - Gibt die Beschreibung Aufschluss über Objektmengen? - Wie und wann werden Objekte der Klassen erzeugt? - Können beteiligte Objekte gelöscht werden und mit welcher Konsequenz? - Ist ein Objekt der Klasse X Teil von Y ? whole-part- Beziehung * Multiplizität der Agregatklasse <=1  Komposition * wird das Ganze gelöscht, so werden auch alle Teile gelöscht  Komposition Im Zweifelsfall gilt: einfache Assoziation verwenden! - lassen sich über die Natur des Objekts feste Grenzen ableiten? ( z.B.: ein Schachspiel hat zu jeder Zeit höchstens 32 und mindestens 2 Figuren) 2

Checkliste Assoziationen Analytische Schritte: Validieren mögliche Einschränkungen (constraints) identifizieren 2 3

Checkliste Assoziationen Analytische Schritte: Validieren Rollennamen erhöhen die Verständlichkeit (Welche Rolle spielt die Klasse?) Assoziationsnamen: Läßt sich mit den beteiligten Klassen und dem gewählten Assoziationsnamen ein Satz bilden? Gibt es mehrere unterschiedliche Assoziationen zwischen zwei Klassen? * unterschiedliche Bedeutungen einer Assoziation * unterschiedliche Kardinalitäten

Checkliste Assoziationen Analytische Schritte: Validieren Nach abgeleitete Assoziationen überprüfen Eintragung empfiehlt sich - bei existierenden Systemen, um vorhandene Redundanzen zu dokumentieren - evtl. um bessere Übersichtlichkeit zu gewährleisten

Checkliste Assoziationen Ergebnis: Klassendiagramm um Assoziationen erweitert Konstruktive Schritte: Welche Assoziationen lassen sich mittels Dokumentanalyse oder Beschreibungen ableiten? Analytische Schritte: Ist eine Benennung oder Rollenangabe notwendig oder sinnvoll? Existieren zwischen zwei Klassen mehrere Assoziationen? Sind abgeleitete Assoziationen notwendig? Soll eine assoziative Klasse oder eine eigenständige Klasse modelliert werden? Fehlerquelle: Verwechseln von Assoziation mit Vererbung.

Checkliste Attribute Ziel: Vervollständigen der Klassenspezifikation Konstruktive Schritte: - Ableiten aus Dokumentenanalyse oder Beschreibungen der Anforderungen/ Anwendungsfälle - In Beschreibungen oft Substantive Wird das identifizierte Attribute wirklich benötigt (wird es im Laufe seines Lebens einen Wert annehmen)? Welche Daten werden zur Ausführung aller Use Cases benötigt?

Checkliste Attribute Analytische Schritte: Validieren Attributname: kurzes, eindeutiges verständliches Substantiv (Welche Daten repräsentiert das Attribut?) Lassen sich Attribute zu Datenstrukturen zusammenfassen? Gehört ein Attribut zu einer Klasse oder zu einer Assoziation? Muß das Attribut auch dann zu jedem Objekt der Klasse gehören, wenn die betreffende Klasse isoliert von allen anderen Klassen betrachtet wird?  ja= Attribut gehört zur Klasse

Checkliste Attribute Validieren Auf Klassenattribute prüfen - Wert gilt für alle Objekte der Klasse --> Bsp.: fixe Stundenlöhne für alle Personen der Kategorie XY, - Informationen über die Gesamtheit der Objekte  z.B.: Anzahl der Objekte einer Klasse abgeleitete Attribute werden dann in die Klasse eingetragen, wenn z.B. - Ihre Werte für den Benutzer an der Benutzungsoberfläche sichtbar sein sollen Beginn, Ende, /Dauer - die Lesbarkeit verbessert werden soll

Checkliste Attribute Ergebnisse: Klassendiagramm um Attributnamen und -spezifikation erweitert Konstruktive Schritte: Welche Attribute lassen sich mittels Dokumentanalyse oder anhand der Beschreibung von Anforderungen oder Anwendungsfällen identifizieren? Wird das jeweilige Attribut wirklich benötigt? Analytische Schritte: Ist der Attributname geeignet? Einfache Attribute oder Datenstrukturen? Wurde das richtige Abstraktionsniveau gewählt? Gehört das Attribut zu einer Klasse oder einer Assoziation? Liegen Klassenattribute vor? Abgeleitete Attribute verwenden?

Checkliste Vererbung Ziel: Zusammenhänge und Unterschiede von Klassen deutlich machen Konstruktive Schritte Ermitteln über bottom-up Vergleiche Gibt es genügend Gemeinsamkeiten zwischen Klassen, die zur Bildung einer gemeinamen Oberklasse berechtigen? Über top-down Inspektion - Kann jedes Objekt der Klasse für jedes Attribut einen Wert annehmen? - (Später:) Kann jede Operation auf jedes Obekt der Klasse angewandt werden? Analytische Schritte Benötigt jede Unterklasse alle geerbten Attribute, Operationen und Assoziationen? Ist die Vererbungshirarchie flach genug?

Checkliste Vererbung

Checkliste Vererbung Ergebnis: Klassendiagramm um Vererbungsstrukturen erweitert Konstruktive Schritte: Ergibt sich durch Generalisierung eine Vererbung ? Ergibt sich durch Spezialisierung eine Vererbung? Analytische Schritte: Liegt eine »gute« Vererbungsstruktur vor? Verbesserung des Modells? 3-5 Hierarchiestufen? „Ist-ein“ – Frage stellen

Übung 1 Ziel: Statisches Modell (Klassendiagramm) aus allgemeiner Beschreibung erstellen. Für Paletten ist eine Lagerverwaltung zu organisieren, eine Palette kann in einem offenen Lager (z.B. eine große Lagerhalle) stehen. Für jedes offene Lager sind dessen Bezeichnung, der Standort, das Lagerprofil (z.B. Kühlung vorhanden) zu speichern. Eine Palette kann alternativ auf einem Stellplatz in einem Stellplatzlager gelagert werden. Für jeden Stellplatz, der mehrere Paletten aufnehmen kann, sind festzuhalten: Koordinaten und Angabe, ob frei oder belegt ist. Für das Stellplatzlager sind prinzipiell die gleichen Informationen zu speichern wie für das offene Lager, jedoch bezieht sich das Lagerprofil immer auf einzelne Stellplätze. Paletten sollen auch ohne Zuordnung zu einem Lager erfasst werden.

Lösung

Lösung

Lösung

Lösung

2. Klassen notieren Lager Offenes Lager Stellplatz- Lager Stellplatz „Lagerhalle“ bezeichnet eine Variante eines offenen Lagers; es bleibt daher als Klasse im primären einfachen Analysemodell unberücksichtigt; eine spätere Modellierung als Subklasse von „Offenes Lager“ (Satz: Lagerhaus IST EIN offenes Lager) ist ggf. möglich. Lager Offenes Lager Stellplatz- Lager Stellplatz Palette

3. Attribute hinzufügen Lager bezeichnung standort Offenes Lager Für das Stellplatzlager sind prinzipiell die gleichen Informationen zu speichern wie für das offene Lager, jedoch bezieht sich das Lagerprofil immer auf einzelne Stellplätze. Lager bezeichnung standort Offenes Lager Stellplatz- Lager profil Stellplatz Palette koordinate profil istFrei Anmerkung: „Kühlung“ ist eine Profilart und bezeichnet zunächst nur einen möglichen Wert für „Lagerprofil“.

4. Assoziationen hinzufügen 1. eine Palette kann in einem offenen Lager stehen.. 2. Eine Palette kann alternativ auf einem Stellplatz in einem Stellplatzlager gelagert werden Lager bezeichnung standort Offenes Lager Stellplatz- Lager profil Stellplatz koordinate profil Palette istFrei

5. Vererbungsstrukturen identifizieren Für das Stellplatzlager sind prinzipiell die gleichen Informationen zu speichern wie für das offene Lager Lager bezeichnung standort Offenes Lager Stellplatz- Lager profil Stellplatz koordinate profil Palette istFrei

6. Assoziationen verfeinern/ Attribute verfeinern 1. Für jeden Stellplatz, der mehrere Paletten aufnehmen kann,… 2. Eine Palette kann alternativ auf einem Stellplatz in einem Stellplatzlager gelagert werden Lager bezeichnung standort Offenes Lager Stellplatz- Lager profil 1 0..1 1..* {xor} Stellplatz * koordinate 0..1 profil * Palette /istFrei

Übung 2 Ziel: Klassendiagramm systematisch aus Beschreibung erstellen Erstellt werden soll ein Programm, mit dem Leser und ausleihbare Medien einer Bibliothek verwaltet werden können. Zu einem Leser sollen dessen Name, Vorname, Anschrift und eine Kundennummer gespeichert werden. Verliehen werden Bücher und DVDs. Zu einem Buch werden gespeichert der Name des Autors, der Titel, die ISBN-Nummer, zu einer DVD der Titel und die Spielzeit. Alle Medien enthalten eine eindeutige Mediennummer. Ein Leser kann bis zu 10 Bücher oder DVDs auf einmal ausleihen. Ein Medium ist entweder ausgeliehen oder verfügbar.

Übung 3 Lernziel: Assoziationen vollständig spezifizieren können Modellieren Sie folgende Problemstellungen durch Klassen und Assoziationen: Auf einer Palette sind mehrere Fässer. Paletten werden im Normalfall komplett geliefert und im Normalfall komplett weiterverkauft. Es können jedoch auch einzelne Fässer verkauft werden. Leere Paletten und einzelne Fässer können nicht vorkommen. Jedes Projekt hat genau einen Projektleiter, der für mehrere Projekte verantwortlich sein kann. Die meisten Programmierer arbeiten für mehrere Projekte. Jede Hauptabteilung besteht aus mehreren Abteilungen. Die meisten Abteilungen sind in einer Hauptabteilung eingegliedert, die anderen (z.B. Stabsabteilungen) berichten direkt an die Geschäftsleitung. In einer Abteilung sind mehrere Mitarbeiter tätig. Jeder Mitarbeiter ist genau einer Abteilung zugeordnet. Ein Lexikon besteht aus mehreren Bänden. Jedes Buch kann Teil einer Buchreihe sein.