Software Engineering (eBook)

Inhaltsverzeichnis 6
Vorwort 10
Dank 12
1 Gegenstandsbestimmung – Einführung und Überblick 14
1.1 Was ist Software? 14
1.2 Was ist Software Engineering? 16
1.3 Inhalt und Aufbau des Buches 18
Teil I Prozessorientierte Sicht – Organisation von Software-Projekten 22
2 Prozessmodelle 24
2.1 Das klassische sequenzielle Phasenmodell 24
2.2 Das V-Modell 31
2.3 Das Prototyping-orientierte Prozessmodell 39
2.3.1 Begriffe und Abgrenzung 39
2.3.2 Prozessmodell 42
2.4 Das Spiralmodell 45
2.4.1 Das Spiralmodell von Boehm 45
2.4.2 Das Spiralmodell von Pomberger und Pree 48
2.5 Der Unified Process 52
2.6 Ein objektorientiertes Phasenmodell 55
2.7 Leichtgewichtige (agile) Prozessmodelle 58
3 Software-Qualitätsmanagement 64
3.1 Was ist Softwarequalität? 64
3.2 Wo und wie entstehen Softwarequalität bzw. Qualitätsmängel 68
3.3 Grundzüge des Software- Qualitätsmanagements 70
3.3.1 Hauptaufgaben des Qualitätsmanagements 71
3.3.2 Objekte und Sichten des Qualitätsmanagements 71
3.3.3 Prinzipien des Qualitätsmanagements 73
3.3.4 Konstruktive und analytische Qualitätsmaßnahmen 74
Teil II Konstruktions- und Architektur-orientierte Sicht 78
4 Elementare Konzepte und Konstrukte 80
4.1 Der Algorithmenbegriff 80
4.2 Datenobjekte, Datentypen und elementare Aktionen 81
4.3 Schnittstellen und Aktivierung von Algorithmen 83
4.4 Systematischer Entwurf von Algorithmen 85
4.5 Grundlegende Konzepte der objektorientierten Programmierung 89
4.5.1 Klassen, Objekte (= Instanzen von Klassen), Instanzvariablen, Methoden 90
4.5.2 Vererbung, Polymorphismus, statischer Variablentyp, dynamischer Variablentyp und dynamische Bindung 92
5 Konstruktion anpassbarer Software 98
5.1 Konfigurationsparameter als Basis für anpassbare Software 98
5.1.1 Parametereinstellungen über globale, statische Variable 98
5.1.2 Callback-Style of Programming – Funktionen und Prozeduren als Parameter 100
5.2 Konzepte und Konstruktionsprinzipien für anpassbare, objektorientierte Produktfamilien 102
5.2.1 Das Konzept der abstrakten Kopplung 104
5.2.2 Das Konzept der Template- und Hook-Methoden 110
5.2.3 Das Hook-Method-Konstruktionsprinzip 113
5.2.4 Das Hook-Object-Konstruktionsprinzip 116
5.2.5 Das Composite-Konstruktionsprinzip 122
5.2.6 Das Decorator-Konstruktionsprinzip 129
5.2.7 Zusammenfassung der Merkmale der Konstruktionsprinzipien 138
5.3 Konstruktionsprinzipien und Entwurfsmuster 138
6 Modularisierung und Software-Architekturen 144
6.1 Software-Module 145
6.2 Erwünschte Eigenschaften von Modulen 147
6.2.1 Stabile und verständliche Modulschnittstellen durch Information Hiding 148
6.2.2 Balance zwischen Kopplung und Kohäsion 150
6.3 Ausprägungen von Modulen 153
6.3.1 Modul als Abstrakte Datenstruktur (ADS) 153
6.3.2 Modul als Abstrakter Datentyp (ADT) 154
6.3.3 Module und Komponentenstandards 158
6.4 Beispiele für ausgewogene Modularisierungen 160
6.4.1 Kohäsionsverbesserung durch Aufteilung von Modulen 160
6.4.2 Module für die Simulation diskreter Ereignisse 162
6.5 Beschreibung von Software-Architekturen 169
6.5.1 Datenzentrierung 170
6.5.2 Datenflussorientierung 171
6.5.3 Call& Return
6.5.4 Virtuelle Maschine 173
6.5.5 Unabhängige Komponenten 174
6.5.6 Vor- und Nachteile der Architekturmuster 175
6.6 Analyse von Software-Architekturen 175
6.6.1 Die Software-Architektur-Analyse-Methode (SAAM) 175
6.6.2 Beispiel einer Anwendung der SAAM 180
6.6.3 Was ist bei einer Anwendung der SAAM zu beachten? Was sind die Vorteile und Risiken? 185
6.7 Mehrdimensionale Modularisierung durch Aspektorientierte Programmierung (AOP) 186
6.7.1 Das Problem einer einzigen, statischen Modularisierung 187
6.7.2 Grundlegende Sprachkonzepte und -konstrukte von AOP 189
6.8 Zusammenfassung wichtiger Modularisierungsprinzipien 193
Teil III Ausgewählte Gebiete und Fallbeispiele 194
7 Transformationsorientierte Software1 196
7.1 Grundlegende Konzepte 196
7.1.1 Kontextfreie Grammatiken 197
7.1.2 Konstruktion eines Sprachanalysators (Scanner und Parser) 199
7.1.3 Attributierte Grammatiken 205
7.2 Fallbeispiel: Transformation strukturierter Texte 209
7.2.1 Entwurf einer attributierten Grammatik mit Coco/R 212
7.3 Zusammenfassung 228
8 Web-Service-basierte Software1 230
8.1 Was sind Web-Services 230
8.2 Vergleich mit anderen Technologien 232
8.2.1 CORBA 233
8.2.2 Java RMI 235
8.2.3 .NET Remoting Framework 235
8.3 Entwicklungsprozess für Web-Service-basierte Software 236
8.4 Grundlegende Konzepte und Standards 237
8.4.1 SOAP 237
8.4.2 Web-Service Description Language (WSDL) 239
8.5 Fallbeispiel: Elektronisches Telefonbuch 242
8.5.1 Ausgangssituation im Fallbeispiel 242
8.5.2 Beteiligte Komponenten 243
8.5.3 Schnittstelle des Web-Services 243
8.5.4 Implementierung des Web-Services mit Microsoft Visual Studio 244
8.5.5 Implementierung der Anwendungssoftware 245
8.5.6 Interaktionen zwischen Anwendungssoftware und Web-Service 247
8.6 Zusammenfassung 249
9 Eingebettete Echtzeitsoftware 250
9.1 Grundlegende Konzepte und Voraussetzungen 250
9.1.1 Charakteristika von Echtzeitsoftware 251
9.1.2 Logische versus tatsächliche Ausführungszeiten von Echtzeitsoftware 252
9.2 Fallbeispiel: Echtzeitsoftware eines autonom fliegenden Helikopters 254
9.2.1 Das OLGA-System 256
9.2.2 Die TDL-Spezifikation des Zeit- und Kommunikationsverhaltens 257
9.2.3 Die Übersetzung der TDL-Spezifikation in ein ausführbares Programm 260
9.2.4 Simulation eines TDL-basierten Regelungssystems 261
9.3 Zusammenfassung 263
Literaturverzeichnis 264
Stichwortverzeichnis 268

6 Modularisierung und Software-Architekturen (S. 143-144)

Die Qualität eines Software-Produktes hängt in besonderem Maße von der Güte des Entwurfes ab. Die Hauptaufgabe im Rahmen der Entwurfsphase besteht darin, die Architektur des geplanten Software-Produktes festzulegen. Ausgehend von einer Systemspezifikation wird in der Entwurfsphase die Systemarchitektur mit dem Ziel entworfen, den in der Systemspezifikation festgelegten Funktionsumfang mit möglichst geringem Aufwand verfügbar zu machen und zu gewährleisten, dass die Qualitätsforderungen erfüllt und die Architektur an sich ändernde Anforderungen schnell, sicher und mit möglichst wenig Aufwand angepasst werden kann.

Der Entwurfsprozess umfasst grob skizziert die folgenden Tätigkeiten: problemadäquate Zerlegung des Gesamtsystems in Module (= Komponenten) und Spezifikation der Wechselwirkungen zwischen den Modulen; Festlegung der Anforderungen an die Module, das heißt, Festlegung der Modulschnittstellen; Entwurf der Algorithmen zur Bereitstellung der durch die Modulschnittstellen definierten Funktionalität. Der Modularisierung – mit Bedacht auf die Wiederverwendung bereits vorhandener Komponenten – kommt beim Entwurf und bei der Gestaltung der Systemarchitektur zentrale Bedeutung zu.

Der Blick auf die Modularisierung (= Strukturierung) eines Software-Systems erlaubt uns eine „grobkörnige" Betrachtung des Software-Produktes, aus der wir insbesondere feststellen können, welche Schnittstellen die Module haben und wie die Module untereinander interagieren. Im Mittelpunkt der Gestaltung der Software-Architektur steht daher die Modularisierung beziehungsweise Strukturierung des Software-Systems. Die Qualität der Modularisierung von Software-Systemen, die in der Entwurfsphase des Software-Entwicklungsprozesses festgelegt wird, ist ausschlaggebend für den Verlauf der weiteren Entwicklungsphasen und die Qualität des Endproduktes. Außerdem schafft eine adäquate Modularisierung die technische Voraussetzung für die Schaffung wiederverwendbarer Software-Komponenten.

In diesem Abschnitt führen wir zuerst das Modulkonzept als Grundlage für die Konstruktion von Software-Komponenten ein (Abschnitte 6.1 bis 6.4). Um die Beschreibungsproblematik von Software-Architekturen einigermaßen in den Griff zu bekommen, ist ein Teil dieses Kapitels der Diskussion von Architekturmustern gewidmet. Sie sind ein Mittel zur Beschreibung der Architektur von Software-Systemen (Abschnitt 6.5). Eine der Schwierigkeiten beim Entwurf einer Software-Architektur besteht darin, dass nicht exakt definierbar ist, was eine „gute" Modularisierung ausmacht und wie wir vorzugehen haben, um zu Aussagen zur Güte der Architektur zu gelangen. In Abschnitt 6.6 stellen wir die Software Architektur Analyse Methode (SAAM) vor, die ein pragmatischer Lösungsansatz zur Evaluierung einer Software-Architektur ist.

Die aspektorientierte Programmierung kann als Querschnittsmodularisierungstechnik gesehen werden, die zu einer flexiblen Modularisierung führt. Ihr ist ein eigener Abschnitt (Abschnitt 6.7) gewidmet. Die aspektorientierte Programmierung gehört zu den jüngeren Entwicklungen im Bereich der Modularisierungstechniken und ist ein in den letzten Jahren viel diskutiertes Forschungsgebiet (siehe dazu zum Beispiel die Web- Referenzen zu aspektorientiertem Programmieren und Colyer et al, 2004). Das zeigt, dass die Forschung im Bereich der Modularisierung von Software-Systemen bei weitem noch nicht abgeschlossen ist.

6.1 Software-Module

Module sind, wenn man die Entwicklung von Programmiersprachen und von Strukturierungskonstrukten betrachtet, Ende der 1970er Jahre eingeführt worden, weil die bis dahin benutzten Strukturierungskonstrukte Prozedur und Funktion keine der wachsenden Systemkomplexität angemessene Strukturierung erlaubten. Prozeduren und Funktionen repräsentieren Algorithmen. Das heißt, sie fassen einzelne Anweisungen zu einer Einheit zusammen. Module hingegen fassen mehrere Prozeduren und/oder Funktionen sowie die Daten, auf denen diese operieren, zu einer Einheit zusammen. Man unterscheidet zwischen der Schnittstelle eines Moduls und dessen Implementierung. Die (Programmier-)Schnittstelle führt die Namen und Parameter der Funktionen, Prozeduren und Daten an, die von anderen Modulen verwendet werden können. Wir definieren einen Modul (=Software-Komponente) als ein Stück Software mit einer Programmierschnittstelle.

Das mögliche Zusammenspiel mehrerer Module ist durch ihre Programmierschnittstellen festgelegt. Genau genommen ist zwischen zwei Arten von Schnittstellen zu unterscheiden: Die Programmierschnittstelle ist die Exportschnittstelle, die angibt, welche Operationen und Daten ein Modul anderen Modulen zur Verfügung stellt. Die Importschnittstelle gibt an, was ein Modul von anderen Modulen benutzt. Wenn wir nachfolgend nicht explizit zwischen Export- und Importschnittstelle unterscheiden, meinen wir mit Schnittstelle die Exportschnittstelle.

Reiser und Wirth, 1992, beschreiben das Modulkonzept wie folgt:

It provides mechanisms for:

1. structuring of a program into independent units;

2. the declaration of variables that keep their value for the duration the module is active (that is, in memory) – these variables are called global to the module;

3. export of variables and procedures to be used in other modules. The module therefore provides the facilities for abstractions.