Grosse Systeme im Griff Ein Konzept für V-Modell V konformes Anforderungsmanagement und Systemarchitekturmodellierung mit UML und RE/RM für komplexe Systeme Teil1: Methodisches Vorgehen Vorstellung EADS European Aeronautic Defence and Space Company Bereich: Defence & Civil Systems Firma: Lenkflugkörpersysteme GmbH Aufgabe: Entwicklungsleiter für eine Waffenführungssystem Name: D. Wagner CoCOO Competence Centre ObjectOrientation (www.cocoo.de) Aufgabe: Methodenberater für OO/UML und V-Modell 97 Name: M. Reinhold (reinhold@cocoo.de) Page 2
Rahmenbedingungen Entwicklung eines komplexen Systems System besteht aus n Anwendungssystemen Systementwicklung mehr als nur Anwendungsentwicklung Entwicklung/Integration unterschiedlicher Anwendungssysteme, HW, Betriebssysteme, Netzwerktechnologien Berücksichtigung beim Vorgehen, Teile des System als Unterauftrag zu vergeben Berücksichtigung des Unternehmensstandards zur Erstellung von Systemen (V-Modell) Realtime System Page 3 Lösungsansatz Requirements-Engineering (RE) u. Requirements- Management (RM) Externe Know how Träger komplexes System unternehmensspezifisches V-Modell inkrementelles Vorgehen RM Tool Standardnotation UML UML Tool Abhängigkeiten Page 4
Lösungsbausteine Unternehmensspezifisches V-Modell V (erweitertes V-Modell 97) V Inkrementelles Vorgehen auf Systemebene Standardnotation UML Verbindung mit der Toolumgebung (siehe Teil 2) Einsatz der Rational Suite Erweiterungen der Rational Suite durch Skripts Page 5 Lebenszyklus komplexer Systeme Page 6
Unternehmensspezifisches V-Modell SE 1 System-Anforderungsanalyse SE 2 Systementwurf VM-GBV SE 9 Überleitung in die Nutzung SE 8 System-Integration QS SE 3 (ILS) Analyse d.log. SE 3 (HW) HW-Anforde- SE 3 (SW) SW-Anforde- Anforderungen rungsanalyse rungsanalyse SE 4 (ILS) SE 4 (HW) SE 4 (SW) Logistische HW-Grob- SW-Grob- Analysen entwurf entwurf SE 7 (SW) HW- Integration SW- Integration SE 7 (HW) SE 7 (ILS) Integr. der log. Elemente KM SE 5 (ILS) Feinentwurf der Logistik SE 5 (HW) HW-Feinentwurf SE 5 (SW) SW-Feinentwurf SE 6 (SW) SW-Implementierg. SE 6 (HW) HW-Realisierung SE 6 (ILS) Realisierung der logistischen Elemente PM Page 7 Inkrementelle Vorgehensweise aus SE Sicht Analyse, Entwurf Verifizierung, Ergänzung SE1 + SE2 Realisierung, Integration SE1 SE2 SE3 SE4 SE9 SE8 SE7 SE6 Vorteile: Komplexitätsbewältigung mittels Teile und Herrsche Stufenweise Integration Flexible Reaktionsmöglichkeit auf sich ändernde Anforderungen Lerneffekt durch Feedbackschleifen (SE5) SE5 Inkrement 1 Inkrement 2... Inkrement n Inkrement n beinhaltet die Funktionalität aller vorherigen Inkremente Zeit Page 8
Inkrementelle Vorgehensweise aus QS Sicht QS 2 (Seg) QS 2 (SW-E, HW-E) QS 2 (Komp., Mod.) Prüfungsvorbereitung QS 1, QS 2 (Sys) Prüfungsdurchführung QS 4 (Sys) QS 4 (Seg) QS 4 (SW-E, HW-E) QS 4 (Komp., Mod.) Vorteile: Steigerung der Qualität durch kontinuierlichen Testprozeß Steigerung der Qualität durch wiederholtes Testen Risiken: Know how Defizit aufgrund integr. QS im Entwicklungsteam Inkrementelles Testen ist ein unbekanntes Verfahren in LFK Inkrement 1 Inkrement 2... (=Inkr 1 + neue Funkt.) Inkrement n (=Inkr.n -1 + neue Funkt.) Zeit Page 9 UML Modellierung - Grundidee (1) Kundenanforderungen bestimmen das System Firmenanforderungen bestimmen die Realisierung Hierarchischer Aufbau - Jedes komplexe System zerfällt hierarchisch Jedes komplexe System zerfällt hierarchisch in Teilsysteme Anwender- forderungen <<führt zu>> (Teil-)System )System- beschreibung * (Teil-)Technische Anforderungen <<leitet sich u.a. ab von>> (Teil-)System )System- architektur Page 10
UML Modellierung Grundidee (2) Systemebene Zerlegungsebene 1 Anwender- forderungen System Teilsystem n... Technischen Anforderungen (für Gesamtsystem) Technischen Anforderungen (pro Teilsystem)... <<ist abhängig von>> Page 11 Anforderungsarten Fragestellung Welche Anforderungsarten gibt es? Anforderung funktional (Use Case) beziehen sich auf nicht funktional Leistungs- kenngrößen Sicherheit Umwelt Qualität Logistik... Page 12
UML Modellierung - Hierarchisierung (1) Fragestellung Welche hierarchischen Modelltypen kennt die UML Dekomposition Hierarchischer Modelltyp Detaillierung Bei einer hierarchischen Zerlegung des Systems wird pro Ebene noch ein integratives Element benötigt, welches den dynamischen Zusammenhang erläutert Spezialisierung Page 13 Modellierungslösung Hierarchisierung (2) In konkreten UML-Modellelementen Modellelementen bedeutet dies: Architektur Klassendiagramm, Paketdiagram (Dekomposition) Sequenzdiagramme zur Schnittstellenbeschreibung - Integrativ Technische Anforderungen (pro Dekompositionsebene in Architektur) (hierarchisierbare) Use Cases (Detaillierung) Zustandsdiagramm (Spezialisierung) Sequenzdiagramme und Aktivitätsdiagramme - Integrativ Page 14
Hierarchische Systemarchitektur durch Dekomposition Systemebene System Segmentebene 1 Segment 1 Segment 2 Segment 3 Segment 4 Segmentebene 2 Segment 2.1 Segment 2.2 Beauftragung an Unterauftragnehmer Page 15 Dynamisches Zusammenspiel der Architekturbausteine Segmentebene 1 Segment 1 Segment 2 Segment 3 Integration durch Kommunikation zwischen den Segmenten Page 16
Abhängigkeiten zwischen den Architekturbausteinen Segment 1 Segmentebene 1 Segment 2 Segment 3 Abhängigkeit durch Kommunikationkanäle zwischen den Segmenten Page 17 Hierarchische Anforderungsbeschreibung durch Detaillierung Systemebene <<System>> Use Case abc Segmentebene <<Segmentebene 1>> Use Case S1.1 <<Segmentebene 1>> Use Case S2.1 Segment 1 Segment 2 Rekursives Zerfallen der Use Cases auf jeder Segmentebene Page 18
Zusammenspiel der Use Cases z.b. System Use Case abc Segment 1 Segment 2 Segment 3 Use Case S1.1 Use Case S2.1 Use Case S1.2 Use Case S3.2 Realisierung der System Use Cases durch Segment Use Cases Page 19 Zusammenhang der Use Cases zu Systemzuständen POWEROFF event 1: Use Case arg event 2: Use Case tre IDLE do/use Case bla event 3: Use Case klo Nicht alle Use Cases lassen sich auf diese Art und Weise zuordnen. Z1 event 4: Use Case pok event 5: Use Case tre event 9: Use Case fre Z2 event 6: Use Case arg event 7: Use Case tre... Zuordnung der Use Cases zu den Systemzuständen Page 20
S eg eg ment 1 1 S eg eg ment 2 2 S eg eg ment 3 3 Bediener Use Case S1.1 Use Case C Use Case S1.1 Use Case A Use Case B POWEROFF event 1: Use Case arg event 2: Use Case tre event 3: Use Case klo GPS Empfaenger S eg eg ment 1 1 S eg eg ment 2 2 S eg eg ment 3 3 Use Case S2.1 Use Case S1.2 S eg eg ment 1 1 S eg eg ment 2 2 S eg eg ment 3 3 Use Case S2.1 Use Case S1.2 Use Case S3.2 Use Case S3.2 event 9: Use Case fre II DLE do/use Case bla Z 11 event 4: Use Case pok event 5: Use Case tre Z 22 event 6: Use Case arg event 7: Use Case tre Zusammenfassung Modellelemente Technische Anforderungen Use Cases Zustandsdiagramm Sequenzdiagramme und Aktivitätsdiagramme Architektur Klassendiagramm Sequenzdiagramme Page 21