Aktivität

[Eigene Ergänzungen/Erfahrungen bearbeiten]

Anforderungsanalyse

A-230 Geschäftsklassenmodell entwickeln

Pro identifiziertem Subsystem wird ein Geschäftsklassenmodell entwickelt. Alle Attribute und Operationen der identifizierten Geschäftsklassen werden beschrieben, soweit sie bekannt sind.

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


Je identifiziertem Subsystem wird ein eigenes UML-Geschäftsklassenmodell entwickelt.
Die strukturellen Zusammenhänge der wichtigsten fachlichen Gegenstände werden in Form eines Geschäftsklassenmodells beschrieben. Aus den Systemanwendungsfällen werden die wichtigsten fachlichen Gegenstände abgeleitet. Eine Liste der identifizierten Geschäftsklassen wird erstellt, ein erstes Geschäftsklassenmodell abgeleitet, soweit dies noch nicht geschehen ist.

Alle im Geschäftsklassenmodell vorkommenden Geschäftsklassennamen sollten als Fachbegriffe im Glossar definiert sein. Im Design-Klassenmodell werden sie ggf. genauer spezifiziert, d.h., es werden die fachlich relevanten Attribute, Assoziationen, Zusicherungen und Operationen (keine primitiven Get-/Set-Operationen) definiert.

In nachfolgenden Iterationen oder wenn aus anderen Gründen bereits ein Geschäftsklassenmodell vorliegt, wird dieses aktualisiert und ggf. restrukturiert, um neue Erkentnisse aus den genannten Beschreibungen, Dokumenten etc. einzuarbeiten.

Es werden nur die fachlich relevanten Klassen, die sog. Geschäftsklassen betrachtet und von diesen ggf. nur eine ausgewählte Menge, d.h. die wichtigsten. Durch Abstraktion gefundene Klassen, Basisklassen, technisch motivierte Klassen, Schnittstellen, Steuerungsklassen u.Ä. werden außer Acht gelassen.

Evtl. vorhandene Referenzmodelle (alte oder aktuelle Datenmodelle u.Ä.) können herangezogen werden, um Hinweise oder Lösungskonzepte zur fachlichen Strukturierung des Anwendungsgebietes zu erhalten.

Bei der Erstellung des Geschäftsklassenmodells sollte der Fokus auf den Assoziationen liegen (inkl. den Spezialformen Aggregation und Kompositionen). Beziehungs- und Rollennamen, Multiplizitäten und Zusicherungen sollten, soweit bekannt, notiert werden. Vererbungsbeziehungen sollten nur soweit notwendig modelliert werden. Eine aktive Suche nach Generalisierungen/Spezialisierungen und der elegantesten Vererbungsstruktur sollte vermieden werden.

Attribute und Operationen werden je Geschäftsklasse identifiziert und beschrieben, Kandidaten sind aus den Systemanwendungsfällen abzuleiten.


Begründung:

Auslöser:

Vorbedingung:

Anforderungsworkshop (Entwurfsphase) wurde durchgeführt. Ein erstes grobes Geschäftsklassenmodell besteht. Ebenso besteht das Subsystemmodell.

Unterlagen:

E-115 Geschäftsklassenmodell
E-6 Systemanwendungsfallbeschreibung [essenziell]

Gegenbedingung:

Ergebnisse:

E-115 Geschäftsklassenmodell
E-58 Subsystem

Besond. Hilfsmittel:

Flip-Chart-Papier, freie Flächen, Digitalkamera, Wiki-Web
UML-Modellierungswerkzeug

Verantwortlicher:

projektintern.SystemanalytikerIn

Beteiligte:

projektintern.FachlicheR ArchitektIn
projektintern.SystemanalytikerIn

Nachfolg. [Beding.]:

A-232 Designklassenmodell und validiertes Subsystemmodell entwickeln
A-251 Geschäftsklassenmodelle konsolidieren [Gemeinsamkeiten bzw. Schnittmengen aller UML-Geschäftsklassenmodelle werden herausgelöst, um Redundanzen zu vermeiden.]

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