Kapitel 5. Analyse

Inhaltsverzeichnis

5.1. Der Analyseprozess
5.1.1. Klasse-, Verantwortlichkeits- und Zusammenarbeits-Karten (CRC)
5.1.2. Konzeptdiagramm (Noch zu beschreiben)
5.1.3. System-Sequenzdiagramm (Noch zu beschreiben)
5.1.4. System-Zustandsdiagramm (Noch zu beschreiben)
5.1.5. Anwendungsfalldiagramm realisieren (Noch zu beschreiben)
5.1.6. Dokumente (Noch zu beschreiben)
5.2. Klassendiagramme (Noch zu beschreiben)
5.2.1. Das Klassendiagramm (Noch zu beschreiben)
5.2.2. Erweiterte Klassendiagramme (Noch zu beschreiben)
5.3. Klassendiagramme in ArgoUML erzeugen
5.3.1. Klassen
5.3.2. Assoziationen (Noch zu beschreiben)
5.3.3. Klassenattribute und Operationen (Noch zu beschreiben)
5.3.4. Erweiterte Klasseneigenschaften (Noch zu beschreiben)
5.4. Sequenzdiagramme (Noch zu beschreiben)
5.4.1. Das Sequenzdiagramm (Noch zu beschreiben)
5.4.2. Aktionen identifizieren (Noch zu beschreiben)
5.4.3. Erweiterte Sequenzdiagramme (Noch zu beschreiben)
5.5. Sequenzdiagramme in ArgoUML erzeugen
5.5.1. Sequenzdiagramme
5.5.2. Aktionen (Noch zu beschreiben)
5.5.3. Erweiterte Sequenzdiagramme (Noch zu beschreiben)
5.6. Zustandsdiagramme (Noch zu beschreiben)
5.6.1. Das Zustandsdiagramm (Noch zu beschreiben)
5.6.2. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
5.7. Zustandsdiagramme in ArgoUML erstellen
5.7.1. Zustandsdiagramme (Noch zu beschreiben)
5.7.2. Zustände (Noch zu beschreiben)
5.7.3. Transitionen (Noch zu beschreiben)
5.7.4. Aktionen (Noch zu beschreiben)
5.7.5. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
5.8. Anwendungsfälle realisieren (Noch zu beschreiben)
5.9. Realisierungs-Anwendungsfälle in ArgoUML erstellen (Noch zu beschreiben)
5.10. Fallstudie (Noch zu beschreiben)
5.10.1. CRC Karten
5.10.2. Klassendiagramme konzipieren (Noch zu beschreiben)
5.10.3. System-Sequenzdiagramme (Noch zu beschreiben)
5.10.4. System-Zustandsdiagramme (Noch zu beschreiben)
5.10.5. Die Realisierung von Anwendungsfällen (Noch zu beschreiben)

Die Analyse ist der Prozess, die „Kunden“-Anforderungen zu nehmen und in die Sprache und Perspektive der künftigen Lösung umzuwandeln.

Wir sollten zu diesem Zeitpunkt nicht versuchen die detaillierte Lösung auszuarbeiten. Dies passiert in der Design -Phase (siehe Kapitel 6, Design ).

Wie die Grenze zwischen den Anforderungs- und der Analyse-Phase ist die Grenze zwischen Analyse und Design inhärent unscharf. Der Schlüssel dazu ist, dass die Analyse die Lösung nicht weiter als notwendig definieren sollte, um die Anforderungen in der Sprache der Lösung zu spezifizieren. Die Modellelemente in der Analyse repräsentieren generell eine höhere Abstraktionsebene.

Noch einmal, die rekursive, und iterative Natur unserer Prozesse bedeutet, dass wir in der Zukunft noch häufig auf die Analysephase zurückkommen werden.

5.1. Der Analyseprozess

Es gibt drei gedankliche Ausrichtungen darüber, wie man sich der Analyse annähern sollte. Die Ontologen definieren die Daten (aktuell die Metadaten) zuerst und plagen sich später mit den Prozessen. Der wahre Ontologe würde es vorziehen, überhaupt nicht an Prozesse denken zu müssen. Der Phänomenalist kehrt dies um und stellt die Prozesse über die Daten. Der Paradigmatiker betrachtet die Prozesse und Daten gleichwertig wichtig und adressiert beide von Beginn an.

Wenn es dazu kommt, Purist zu sein, dann hat der Ontologe die Oberhand. Es ist möglich, eine Datenbank zu definieren und zu erzeugen, in die Daten eingegeben und geholt werden kann, ohne Rücksicht darauf, was mit ihnen getan wird oder nicht. Auf der anderen Seite ist es nicht besonders nützlich einen Prozess zu implementieren ohne irgendwelche Datenstrukturen zu haben auf denen der Prozess arbeitet.

5.1.1. Klasse-, Verantwortlichkeits- und Zusammenarbeits-Karten (CRC)

Die CRC-Methode (CRC = Class, Responsibility, Collaborators) favorisiert die Vorliebe der Phänomenologen für die Analyse. Es ist äquivalent mit den Anwendungsfällen zu beginnen, die Aspekte der Prozesse (Operationen) in Klassendiagrammen und Szenarien darzustellen aus denen Sequenzdiagramme initiiert werden können.

CRC-Karten und die entsprechende Methode sind detailliert in Anhang G, Die CRC-Karten Methode beschrieben. Sie werden in der Designphase erneut verwendet und weiter diskutiert in Kapitel 6, Design .

Die Stärke der CRC-Karten während der Analyse.

  • Gemeinsames Projektvokabular -

  • Breites Bereichswissen -

  • Führt Paradigmenwechsel durch -

  • Live-Prototyping -

  • Indentifiziert Lücken in den Anforderungen -

In dieser Phase sollte die Gruppe aus zwei oder drei Fachexperten bestehen. Einer als Vermittler der objektorientierten Technologie und der Rest der Gruppe sollte aus Personen bestehen, die für das das Ausrollen des Systems verantwortlich sind.

Wenn man das erste Mal in die Analysephase eintritt, tritt ein spezieller Fall der CRC-Sitzung auf, weil es keine Klassen oder Szenarien gibt, die man in der CRC-Sitzung für die Definition auswählen könnte. Zu diesem Zeitpunkt tritt ein spezieller Sitzungstyp, Brainstorming genannt, auf. Während dieser Phase identifizieren Sie den grundlegenden Satz von Klassen des Problembereiches, indem Sie die Problembeschreibung oder das Anforderungsdokument oder was immer Sie auch über das gewünschte Ergebnis wissen als Startpunkt verwenden. Die Hauptwörter, die Sie finden, sind gute Ansätze für einen ersten Satz von Klassen in dem System. Während der Brainstorming-Sitzung sollten die Ideen wenig bis gar nicht diskutiert werden. Schreiben Sie diese auf und filtern Sie die Ergebnisse nach dem Brainstorming. Zu diesem Zeitpunkt ist die Unterscheidung zwischen Klasse und Objekt unscharf.

Nachdem ein vernünftiger Satz von Klassen durch die Gruppe definiert wurde, können die Verantwortlichkeiten hinzugefügt werden. Fügen Sie Verantwortlichkeiten hinzu, die aus den Anforderungen oder den Namen der Klassen deutlich hervorgehen. Sie müssen nicht alle finden müssen (oder in jedem Fall alle). Die Szenarien werden dies deutlicher machen. Der Vorteil, einige bereits am Anfang zu finden ist, dass es hilft, einen Anfangspunkt zu finden.

Wählen Sie die ersten Szenarios aus dem Anforderungsdokument aus, indem Sie dessen Verben auf die gleiche Weise prüfen, wie wir vorher die Hauptwörter durchgingen. Dann führen Sie diesen Prozess so oft als notwendig durch, um die begonnene Analysephase zu vervollständigen.

Wann ist genug Analyse durchgeführt worden und wann kann das Design beginnen? Wenn alle unterschiedlichen Verantwortlichkeiten zugeordnet wurden und das System stabil geworden ist. Nachdem das gesamte normale Verhalten abgedeckt wurde, ist es notwendig aussergewöhnliches Verhalten zu simulieren. Wenn Sie feststellen, dass die Verantwortlichkeiten alle an der richtigen Stelle sind, um die neuen Szenarien zu unterstützen und nur noch wenige Änderungen an den Karten vorzunehmen sind, dann ist das ein Anzeichen dafür, dass Sie mit dem Design beginnen können.

5.1.2. Konzeptdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.1.3. System-Sequenzdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.1.4. System-Zustandsdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

5.1.5. Anwendungsfalldiagramm realisieren (Noch zu beschreiben)

Noch zu beschreiben...

5.1.6. Dokumente (Noch zu beschreiben)

Anwendungsfall- und Ergänzende Anforderungs-Spezifikationen sind in die Sprache der Lösung umzuwandeln. Noch zu beschreiben...