Diese Arbeitsabläufe beschreiben typische Szenarien zum Verwenden dieser Integration
der Tools Rational RequisitePro und Rational Software Modeler.
Voraussetzungen und Modellelemente in neuen Produkten zuordnen
- Der Analyst oder Produktmanager definiert mit Hilfe von RequisitePro
die Voraussetzungen für ein neues Softwareprodukt.
- Der Systemarchitekt startet Software Modeler und öffnet das RequisitePro-Projekt
in der Sicht Voraussetzungsexplorer. Der Systemarchitekt
analysiert die Voraussetzungen und entwickelt ein neues UML-Modell, das diese
Voraussetzungen erfüllt.
- Der Softwarearchitekt ordnet RequisitePro-Voraussetzungen
den UML-Modellelementen zu, um anzugeben, welche Voraussetzungen von welchen Modellelementen
erfüllt werden.
Anmerkung: Diese Architektur kann ein Element mit einer einzelnen Voraussetzung
verknüpfen (wie in der Eins-zu-Eins-Zuordnung eines Anwendungsfallelements zu einer
Anwendungsfallvoraussetzung) oder mit Hilfe von Tracefähigkeit zu mehreren
Voraussetzungen (z. B. wenn eine einzige Klasse mehrere Voraussetzungen erfüllt). Umgekehrt können mehrere Elemente zu einer einzigen Voraussetzung führen (z. B.
wenn mehrere Klassen eine einzige Voraussetzung erfüllen). Modellelemente
und Voraussetzungen ohne Zuordnungen oder Tracefähigkeit deuten
möglicherweise auf einen unvollständigen Entwurf hin.
- Sobald die Architektur vollständig ist, erstellen die Programmierer
anhand des UML-Modells ihre Implementierung des Anwendungscodes.
Modellelemente und Voraussetzungen in vorhandenen Produkten zuordnen
- Der Analyst oder Produktmanager erstellt oder modifiziert mit Hilfe
von RequisitePro die
Voraussetzungen für ein vorhandenes Softwareprodukt.
- Der Systemarchitekt startet Software Modeler und öffnet das RequisitePro-Projekt
in der Sicht Voraussetzungsexplorer. Der Systemarchitekt erstellt
neue Modellelemente und Tracefähigkeit, um die neuen Voraussetzungen zu erfüllen.
- Außerdem modifiziert der Architekt das UML-Modell entsprechend den Änderungen
des vorhandenen Entwurfs.
Anmerkung: Diese Änderungen führen zu Änderungen an den zugeordneten
Voraussetzungen und bewirken möglicherweise, dass die Tracefähigkeit mit zugehörigen
Voraussetzungen als 'suspect' (fehlerverdächtig)gekennzeichnet wird.
Diese Tracefähigkeitsbeziehungen können in der Sicht Voraussetzungstrace
und in der Sicht Ergebnisse der Voraussetzungsabfrage oder
in RequisitePro angezeigt
werden und unterstützen das Projektteam beim Analysieren der Auswirkungen
vorgeschlagener Projektänderungen.
- Sobald die Architekturänderungen abgeschlossen sind, erstellen die Programmierer
anhand des UML-Modells den geänderten Anwendungscode.