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
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. Realisierungs-Anwendungsf??lle (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, The CRC Card Methodology 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...