Software-Engineering

Ruth Breu leitet das Institut für Informatik an der Universität Innsbruck. Sie ist Vice Chairperson des German Chapter of the ACM, Obfrau des Vereins der Interessengemeinschaft Informationssicherheit IG:IS, Mitglied der Jury des Tiroler Innovationspreises und Mitglied im wiss. Beirat von ARC Seibersdorf Information Technologies.

Thomas Matzner ist selbständiger Berater mit dem Tätigkeitsfeld der Konzeption von Informationssystemen sowie Vorsitzender des German Chapter der Association for Computer Machinery.

1;Vorwort;6
2;Inhalt;8
3;1 Einleitung;12
4;2 Anwendungslandschaft: Nachverfolgung der Implementierung von IT- Modellen;16
4.1;2.1 Einführung;17
4.2;2.2 Zweck und Zielgruppe von Architekturmanagement;17
4.3;2.3 Rahmenbedingungen für Metamodell und Notation;20
4.4;2.4 Ebenen eines Anwendungslandschaftsmodells;22
4.5;2.5 Details zur Metamodellierung;28
4.6;2.6 Werkzeugunterstützung;33
4.7;2.7 Einordnung in kommende Ansätze zur Metamodellierung;34
4.8;2.8 Erfahrungen;36
4.9;2.9 Zusammenfassung;37
4.10;2.10 Danksagung;37
4.11;2.11 Literatur;37
5;3 Von der Idee zum Projekt Möglichkeiten und Grenzen der Model Driven Architecture;40
5.1;3.1 Anspruch und Grundgedanken der MDA;41
5.2;3.2 Wie MDA funktioniert;44
5.3;3.3 MDA im Projekteinsatz;49
5.4;3.4 Bewertung;54
5.5;3.5 Kriterien für den Einsatz der MDA;57
5.6;3.6 MDA ein Wiedergänger?;59
5.7;3.7 Fazit;60
5.8;3.8 Literatur;61
6;4 Geschäftsprozessmodellierung im Kontext objektorientierter Entwurfstechniken;62
6.1;4.1 Einleitung;63
6.2;4.2 Aspekte der Geschäftsprozessmodellierung;64
6.3;4.3 Geschäftsprozesse im Kontext;67
6.4;4.4 Abläufe und Interaktionen;70
6.5;4.5 Informationsverarbeitung im Prozesskontext;80
6.6;4.6 Vom Geschäftsprozess zur Anforderung;85
6.7;4.7 Zusammenfassung;96
6.8;4.8 Literatur;97
7;5 Komponentenmodellierung mit den Mitteln der UML 1. x und UML 2.0;100
7.1;5.1 Komponentenbegriff;101
7.2;5.2 Technisches vs. fachliches Komponentenmodell;103
7.3;5.3 Anforderungen an Konzepte für die Komponentenmodellierung;106
7.4;5.4 Komponentenmodellierung in der UML 1.x;107
7.5;5.5 Komponentenmodellierung in der UML 2.0;112
7.6;5.6 Kriterien für gute Komponentenmodelle;116
7.7;5.7 Zusammenfassung;118
7.8;5.8 Literatur;119
8;6 Architektur im Großen kann UML helfen?;120
8.1;6.1 Einleitung;121
8.2;6.2 Beispiele für die Vielfalt;123
8.3;6.3 Modellierung im Großen und UML;125
8.4;6.4 Zusammenfassung und Ergänzungen;130
8.5;6.5 Literatur;133
9;7 OCL in der Praxis;134
9.1;7.1 Einleitung;134
9.2;7.2 Einführendes Beispiel;135
9.3;7.3 Verwendung bei der Codierung;139
9.4;7.4 Verwendung im Rahmen des Testens;141
9.5;7.5 Verwendung im Rahmen der Dokumentationserstellung;142
9.6;7.6 Toolsupport;142
9.7;7.7 Weitergehende Anwendungen der OCL;147
9.8;7.8 Zusammenfassung;149
9.9;7.9 Literatur;149
10;8 Systematischer Entwurf zugriffssicherer Systeme;152
10.1;8.1 Einleitung;152
10.2;8.2 Der objektorientierte Kernprozess;155
10.3;8.3 Der Sicherheitsprozess PROSECO;160
10.4;8.4 Schrittweise Entwicklung von Rechtemodellen;169
10.5;8.5 Zusammenfassung und Ausblick;180
10.6;8.6 Literatur;180
11;9 Unternehmensweite Modellintegration;182
11.1;9.1 Einleitung;182
11.2;9.2 Architekturlandschaft;184
11.3;9.3 Modellintegration;195
11.4;9.4 Tool-Unterstützung;202
11.5;9.5 Vorgehensmodell;203
11.6;9.6 Lessons Learned;205
11.7;9.7 Zusammenfassung;206
11.8;9.8 Literatur;206
12;10 Ein praktischer Leitfaden für eine iterative Softwareentwicklung;208
12.1;10.1 Motivation Risiken und Vermeidungsstrategien;209
12.2;10.2 Sequentielle und iterative Entwicklung im Vergleich;213
12.3;10.3 Iterative Entwicklung im Projekt;215
12.4;10.4 Zusammenfassung und Abgrenzung;225
12.5;10.5 Referenzen;226
13;11 Qualitätsförderung in iterativen Prozessen;228
13.1;11.1 Einleitung;228
13.2;11.2 Test Driven Development;230
13.3;11.3 Versionskontrolle;232
13.4;11.4 Der Build-Prozess;233
13.5;11.5 Continuous Integration;235
13.6;11.6 Iterativ und agil entwickelte Software;236
13.7;11.7 Technische Bewertung von Qualität;238
13.8;11.8 Zusammenfassung;245
13.9;11.9 Literatur;245
14;12 Ein gesamtheitliches Verfahren für das Software Process Improvement;248
14.1;12.1 Das SPI-Verfahren im Überblick;249
14.2;12.2 Das konkrete Verfahren für SPI;252
14.3;12.3 Fazit für das Verfahren für SPI;269
14.4;12.4 Literaturverzeichnis;270
15;13 Schätzverfahren im Kontext objektorientierter Prozesse;272
15.1;13.1 Einleitung;272
15.2;1

"In dem Buch Software-Engineering kommen erfahrene Praktiker zu Wort, die den oft fehlenden Erfahrungsaustausch über die Projektarbeit mit Beschreibungen aus der Praxis ersetzen." Mechatronik, 5-6/2005

3 Von der Idee zum Projekt – Möglichkeiten und Grenzen der Model Driven Architecture (S. 29-30)

Juri Urbainczyk, iteratec GmbH

Heutige Softwareprojekte sind trotz allen Fortschritts mit einer Vielzahl von Problemen konfrontiert. Die technische Komplexität der heutigen Infrastruktur führt zu hohem Entwicklungsaufwand und trotzdem zu fehleranfälligen und wenig änderbaren Systemen. Das in einer Anwendung implementierte fachliche Wissen ist häufig kaum dokumentiert und muss bei einer technisch getriebenen oder anderweitigen Migration neu aufgenommen werden. An diesen Problemen nun setzt die Model Driven Architecture (MDA) an. Mit der Idee der Programmierung mit Modellen verspricht MDA eine höhere Produktivität und einfache Softwareentwicklung. Der vorliegende Beitrag beschäftigt sich gerade im Licht der historischen Erfahrungen mit CASE intensiv und kritisch mit der neuen Methode. Der Beitrag gibt zuerst einen Überblick über die theoretischen Grundlagen und bewertet dann den Ansatz im Hinblick auf den heutigen Stand der Technik. Die Vorteile und Nachteile der MDA werden diskutiert und notwendige konzeptionelle Vorarbeiten für den Einsatz in einem Entwicklungsprojekt benannt. Zum Abschluss werden Kriterien angegeben, mit denen die Perspektive eines Einsatzes der MDA in konkreten Projekten bewertet werden kann.

Über den Autor

Juri Urbainczyk, geboren 1967, studierte Physik an der Universität Münster. Seit 1993 arbeitet er in der Softwareindustrie, zunächst in Projekten für die Telekommunikations- und Finanzbranche, dann als Technical Consultant für einen internationalen Hersteller von Entwicklungswerkzeugen. Seit 1998 ist er bei iteratec GmbH als Software-Berater und Bereichsleiter in Frankfurt und München tätig. Seine Interessen liegen im Bereich Projektmanagement, Softwareprozessen und -Architekturen.

3.1 Anspruch und Grundgedanken der MDA

In den letzten Jahren hat die Softwaretechnik große Fortschritte erlebt: mit der UML hat sich ein einheitlicher Modellierungsstandard durchgesetzt. Durch die Etablierung von Objektorientierung, Komponententechnologie und Applikationsservern wurden immer größere und komplexere Systeme möglich.

Aber die heutigen Softwareprojekte sind trotz des Fortschritts mit einer Vielzahl von Problemen konfrontiert. Nach wie vor muss sehr viel Quelltext von Hand erstellt werden. Zusätzlich verlangt die technische Komplexität der heutigen Anwendungen von Entwicklern ein enormes Wissen an infrastrukturellen Details, die nur wenig zur tatsächlichen Funktionalität beitragen. Viele ständig wiederkehrende Aktivitäten werden manuell durchgeführt. Dies führt nicht nur zu hohen Aufwänden für Softwareprojekte sondern auch zu fehleranfälligen und schlecht änderbaren Systemen.

Die MDA ist angetreten, viele dieser heute existierenden Probleme zu lösen. Drei Hauptversprechen gehen von diesem durch die OMG [OMG 01] propagierten Ansatz aus:

1. Die Produktivität der Softwareentwicklung kann gesteigert werden, d h ein Projektziel kann schneller oder durch Einsatz von weniger Ressourcen erreicht werden.

2. Durch Trennung von Technik und Fachlichkeit wird eine stärkere Wiederverwendung fachlicher Beschreibungen und somit ein besserer Investitionsschutz möglich.

3. Durch die Verlagerung und Kapselung von infrastrukturellen Details wird die Komplexität heutiger Software wieder beherrschbar.

Zu diesem Zweck stellt die MDA Modelle in den Vordergrund der Entwicklung [Hub 02]. MDA ist somit Softwareentwicklung mit Modellen. Modelle dienen als Repräsentation eines bestimmten Teils der Funktionali