Aktivität

[Eigene Ergänzungen/Erfahrungen bearbeiten]

Systemerstellung.Subsysteme

A-232 Designklassenmodell und validiertes Subsystemmodell entwickeln

Pro Subsystem je ein Designklassenmodell entwickeln sowie ein validiertes Subsystemmodell entwerfen

Aktivität sollte durchgeführt werden in Entwurf-/Architekturphase (Startphase) (Iterative Aktivität)
Aktivität muss durchgeführt werden in Konstruktionsphase (Hauptphase) (Iterative Aktivität)


Basis ist ein erstes grobes Subsystemmodell (Anforderungsworkshop durchführen (Vorbereitungsphase)), soweit vorhanden, bzw. ein Geschäftsklassenmodell sowie die identifizierten Systemanwendungsfälle. Sofern ein erstes Subsystemmodell besteht, wird dieses weiterentwickelt.

Pro Subsystem wird ein validiertes vollständiges Subsystemmodell inklusive der benötigten und bereitgestellten Schnittstellen erstellt.
Die in dem Geschäftsklassenmodell enthalten Geschäftsklassen werden durch Detaillierung und Restrukturierung in weitere Klassen untergliedert. Beispielsweise ist die Klasse "Kunde" noch sehr allgemein, wahrscheinlich gibt es verschiedene Arten von Kunden. Außerdem haben diese Anschriften, Rufnummern, Bankverbindungen etc., die durch eigene Klassen repräsentiert werden könnten. Auch können Gemeinsamkeiten bei den Geschäftsklassen existieren, zum Beispiel für die Klassen "Kunde" und "Kundenmitarbeiter" bestünde diese Möglichkeit.

Fasse fachlich zusammenhängende Geschäftsklassen des Geschäftsklassenmodells zu Subsystemen zusammen, indem Annahmen darüber getroffenen werden, wie groß die Abhängigkeiten und die fachliche Zusammengehörigkeit der Geschäftsklassen sind. So entsteht beispielsweise für die Geschäftsklassen "Kunde" und "Kundenmitarbeiter" das Subsystem "Kunde". So wird mit allen Geschäftsklassen fortgefahren, bis alle fachlichen Subsysteme identifiziert wurden.

Die benötigten und bereitgestellten Schnittstellen je Subsystem werden im Modell explizit spezifiziert und gekennzeichnet. Ebenso müssen die Abhängigkeiten zwischen den Subsystemen dargestellt und auf zyklische Abhängigkeiten überprüft werden (siehe auch Meilensteinerreichung überprüfen9 und Subsystemabhängigkeiten identifizieren und ggf. restrukturieren).

Je ein Designklassenmodell pro identifiziertem Subsystem (basierend auf dem UML-Subsystemmodell) entwickeln sowie alle Attribute, Operationen, globale Services und Enumerationen (Schlüsseltabellen) identifizieren und beschreiben
Entwickle ausgehend vom Geschäftsklassenmodell (Problembeschreibung) für jedes Subsystem ein spezifisches Design-Klassenmodell (Lösungskonzept). Innerhalb eines Subsystems können die Beziehungen zwischen den fachlichen Geschäftsklassen prinzipiell erhalten bleiben, werden aber ggf. detailliert und weiterentwickelt. Für jedes Subsystem ergibt sich so ein spezifisches Designklassenmodell, das unabhängig von den Designklassenmodellen anderer Subsysteme ist.

Aus den Systemanwendungsfällen und anderen Unterlagen sind systematisch alle Kandidaten für Attribute und Operationen je Designklasse zu extrahieren.


Begründung:

Auslöser:

Vorbedingung:

Ein erstes UML-Subsystemmodell liegt bereits aus einer vorherigen Aktivität Anforderungsworkshop durchführen (Vorbereitungsphase) vor.

Unterlagen:

E-115 Geschäftsklassenmodell
E-58 Subsystem
E-9 Katalog externer Schnittstellen
E-2 Systemanwendungsfallübersicht

Gegenbedingung:

Ergebnisse:

E-50 Design-Klassenmodell
E-58 Subsystem
E-53 Paketmodell

Besond. Hilfsmittel:


UML-Modellierungswerkzeug

Verantwortlicher:

projektintern.DesignerIn

Beteiligte:

projektintern.SystemanalytikerIn
projektintern.AnwendungsentwicklerIn
projektintern.FachlicheR ArchitektIn

Nachfolg. [Beding.]:

A-285 Designklassenmodell restrukturieren [Konsolidierung der Design-Klassenmodelle aller Subsysteme]

OEP - Object Engineering Process, v3.0, 06.11.2006 11:04:45, Copyright © 2006 by oose Innovative Informatik eG