Qualitätsaspekte des Software Designs am Beispiel Traffic Tower

Größe: px

Ab Seite anzeigen:

Download "Qualitätsaspekte des Software Designs am Beispiel Traffic Tower"

Carin Acker
vor 8 Jahren
Abrufe

1 Qualitätsaspekte des Software Designs am Beispiel Traffic Tower Matthias Wagner, Anita Herrmann Deutsches Zentrum für Luft- und Raumfahrt e.v. (DLR) Simulations- und Softwaretechnik Workshop in Braunschweig, 10. Nov 2004 DLR, Simulations- und Softwaretechnik 1

de> Deutsches Zentrum für Luft- und Raumfahrt e.v.

2 Traffic Tower Aufgaben Traffic Tower ist eine verteilte Test- und Simulationsumgebung des IVF BA für 4 die Forschung auf dem Gebiet des Verkehrsmanagements, 4 die kommerzielle Analyse und den Test von kundenspezifischen Verkehrs- und Verkehrsrechnersystemen, 4 das kommerzielle Training von Operatoren für kundenspezifische Verkehrsrechnersysteme. DLR, Simulations- und Softwaretechnik 2

Test von kundenspezifischen Verkehrs- und Verkehrsrechnersystemen, 4 das kommerzielle Training

3 Traffic Tower Projektmerkmale 4 Die Anforderungen sind zu Beginn der Entwicklung nicht vollständig bekannt. Laufende Überarbeitung des Designs im inkrementellen iterativen Entwicklungsprozess. 4 Anpassbar an vielfältige und veränderliche Forschungs- und Kundenanforderungen. Designänderungen der Software sind auch später wahrscheinlich. DLR, Simulations- und Softwaretechnik 3

Laufende Überarbeitung des Designs im inkrementellen iterativen Entwicklungsprozess.

4 Traffic Tower Architektur Sensoren Closed Loop TrafficTower Simulation SUMO Simulationsrechner Kommunikationsrechner Verkehrsrechner Verkehrsrechner- Software Kommunikation Kommunikation Verkehrsrechner- Software Datenbank Datenbankrechner Konfig. Closed Loop Steuerrechner (Regie) abgesetzte Anwenderrechner der Operatoren DLR, Simulations- und Softwaretechnik 4 GUI GUI

Kommunikation Kommunikation Verkehrsrechner- Software Datenbank Datenbankrechner Konfig.

5 Anforderungen an die Traffic Tower Software 4 Flexible Interfaces für die Einbindung unterschiedlichster Verkehrsrechnersysteme 4 Flexible Einbindung der kundenspezifischen GUI dieser Verkehrsrechner 4 Hoher Grad von Interoperabilität als Voraussetzung für die Integration kundenspezifischer Software 4 Flexible Interprozesskommunikation vieler paralleler Prozesse DLR, Simulations- und Softwaretechnik 5

Verkehrsrechner 4 Hoher Grad von Interoperabilität als Voraussetzung für die Integration

6 Anforderungen an das Software-Design 4 Offen für Änderungen 4 Flexibel Austauschbarkeit von Modulen 4 Testbar mit angemessenem Aufwand Software Tests sind nicht nur während der Software- Entwicklung, sondern auch während des Routinebetriebs notwendig. Strategie: Minimierung dieses Testaufwands! DLR, Simulations- und Softwaretechnik 6

nicht nur während der Software- Entwicklung, sondern auch während des

7 Abhängigkeit Design und Testaufwand: Beispiele 4 Zahl der Interfaceparameter einer Komponente 3 Parameter erfordern 6 Testfälle (3!) 5 Parameter erfordern 120 Testfälle (5!) 4 Designkomplexität Zahl notwendiger Testfälle nach McCabe 11 Testfälle 3 Testfälle DLR, Simulations- und Softwaretechnik 8

) 5 Parameter erfordern 120 Testfälle (5!

8 Minimierung des Testaufwandes durch Anwendung objektorientierter Designregeln Minimierung des Umfanges möglicher Ablaufpfade durch 4 Flache Vererbungshierarchien, Vermeidung von Mehrfachvererbung aus unterschiedlichen Basisklassen 4 Beschränkung der Zustandsvielfalt der Objekte entsprechend den tatsächlichen Anforderungen in der Software 4 Sorgfältige, beschränkte Anwendung des Polymorphismus DLR, Simulations- und Softwaretechnik 11

unterschiedlichen Basisklassen 4 Beschränkung der Zustandsvielfalt der Objekte entsprechend den

9 Designstrategie für die Traffic Tower Software 4 Klare entkoppelte Schichtenarchitektur 4 Flache Vererbungshierarchien für flexibles Software Design 4 Funktionale Vererbung minimieren 4 Abhängigkeiten zwischen Klassen und Packages minimieren 4 Standardisierte Interprozesskommunikation 4 Einsatz von Design Patterns, z. B. zur Prozessverwaltung und Schnittstellenentkopplung DLR, Simulations- und Softwaretechnik 12

zwischen Klassen und Packages minimieren 4 Standardisierte Interprozesskommunikation 4 Einsatz von

10 Traffic Tower Schichtenarchitektur (Interprozesskommunikation) 4 Benutzte Design Patterns: Broker (mit Bridge, Proxy) Server-Proxy Daten-Kompatibilität Koordination der Übertragung Technische Umsetzung Verkehrsdaten Client-Proxy Server- Applikation Client- Applikation Broker Handshaking Broker Bridge Socket-Nachrichten (XML) Bridge Socket-Channel DLR, Simulations- und Softwaretechnik 13

Umsetzung Verkehrsdaten Client-Proxy Server- Applikation Client- Applikation Broker Handshaking

11 Design Pattern Beispiel: Broker (Interprozess-Kommunikation im Traffic Tower) Client-Side Broker Proxy packdata unpackdata sendrequest return Broker mainloop updaterepository registerservice findclient findserver Server-Side Proxy packdata unpackdata callservice sendresponse Client callserver starttask usebrokerapi Bridge packdata unpackdata forwardmessage transmitmessage Server initialize entermainloop runserver usebrokerapi DLR, Simulations- und Softwaretechnik 14

Proxy packdata unpackdata callservice sendresponse Client callserver starttask usebrokerapi Bridge packdata

12 Weitere einzusetzende Design Patterns 4 Model View Controller (MVC) Trennung zwischen Daten (Modell), Visualisierung und Kommandierung 4 Factory Method Flexibles Erzeugen von Unterklassen, z. B. Daten-Telegramme 4 Memento Schnittstelle zum Zugriff von außen auf klasseninterne Funktionalität ohne Verletzung der Kapselung (Aufzeichnen, Wiedergabe von Abläufen) 4 Observer Benachrichtigung anderer Objekte bei Änderung des Zustands eines Objekts (z. B. Protokollierung) 4 Adapter, Facade, DLR, Simulations- und Softwaretechnik 15

Daten-Telegramme 4 Memento Schnittstelle zum Zugriff von außen auf klasseninterne Funktionalität ohne Verletzung der Kapselung

13 Fazit: Was wird dadurch ermöglicht? 4 Einfacher Austausch von Basisfunktionalitäten 4 Voraussetzung für effektives Plug-In von kundenspezifischen Systemen Komplette Rechner Software-Module 4 Minimierter Einfluss bei Änderungen der Anforderungen 4 Minimierter Aufwand zum Testen im Routinebetrieb DLR, Simulations- und Softwaretechnik 16

Plug-In von kundenspezifischen Systemen Komplette Rechner Software-Module 4

14 Vielen Dank für Ihre Aufmerksamkeit! Noch Fragen? DLR, Simulations- und Softwaretechnik 17

Ähnliche Dokumente

Design Pattern - Strukturmuster. CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi

Design Pattern - Strukturmuster CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi Agenda Einleitung Strukturmuster Fassade Model View Controller Vergleich 2 Einleitung Strukturmuster