E-Book, Deutsch, 567 Seiten
Mehlig / Neumann / Vogel Software-Architektur
1. Auflage 2005
ISBN: 978-3-8274-1534-9
Verlag: Spektrum Akademischer Verlag
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)
E-Book, Deutsch, 567 Seiten
ISBN: 978-3-8274-1534-9
Verlag: Spektrum Akademischer Verlag
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)
Als Architekt arbeiten Sie in einem sehr vielfältigen und dynamischen Umfeld. Neue Technologien drängen auf den Markt, neue Werkzeuge versprechen Effizienz- und Produktivitätssteigerungen und neue Architekturkonzepte, wie Serviceorientierung und modellgetriebene Verfahren sollen Ihnen helfen, mit der inhärenten Komplexität von IT-Systemen umzugehen. All diese Entwicklungen und Neuerungen müssen Sie als Architekt verstehen, einordnen und letztlich beurteilen können, um die Spreu vom Weizen zu trennen und für Ihre konkrete Problemstellung die passende Lösung zu wählen.
Dieses Buch hilft Ihnen dabei, indem es das Thema Software-Architektur umfassend behandelt und mit Hilfe eines architektonischen Ordnungsrahmens strukturiert. Es stellt Sie als Architekten in den Mittelpunkt und bietet Ihnen langfristige Orientierung. Das Buch vermittelt hierzu essenzielles Architektur-Wissen und zeigt Ihnen, wie Sie dieses Wissen konkret und in entsprechenden Projekten einsetzen können.
Zu diesem Zweck enthält das Buch Anwendungsszenarien und Fallstudien aus verschiedenen Industriezweigen und Anwendungsdomänen. Software-Entwickler und Studenten erhalten mit diesem Buch eine wertvolle Hilfestellung, um in das Thema Software-Architektur einzusteigen.
Oliver Vogel ist IT-Architekt und -Trainer für Software-Architektur und -Design bei IBM Business Consulting Services. Er ist in verschiedenen internationalen Projekten tätig und beschäftigt sich mit der Konzeption und Realisierung von komplexen, verteilten Software-Architekturen. Darüber hinaus publiziert er Artikel zu dem genannten Themengebiet und hält Vorträge an Hochschulen und Konferenzen.
Ingo Arnold arbeitet als IT-Architekt für Novartis Pharma AG Schweiz. Schwerpunkte seiner Arbeit sind die Konzeption, Planung, Umsetzung sowie die Weiterentwicklung von Anwendungsdienst-Architekturen im Rahmen internationaler Großprojekte. Arif Chughtai ist selbständiger Berater und Trainer für objektorientierte Software-Entwicklung. Sein spezielles Interesse gilt Konzepten, die zu einer Verbesserung der technischen Software-Qualität führen. Prof. Dr. Edmund Ihler ist seit 2000 Professor für Informatik an der Hochschule der Medien in Stuttgart.
Der Hauptschwerpunkt seiner Arbeit liegt dort im Gebiet objektorientierte Softwaremodellierung und modellgetriebenes Software Engineering. Er ist Leiter des Studiengangs Medieninformatik. Uwe Mehlig ist als IT-Architekt bei der IBM Deutschland GmbH im Bereich Business Consulting Services tätig. Thomas Neumann ist Software-Architekt mit 15 Jahren Erfahrung in der Software-Entwicklung. Markus Völter ist freiberuflicher Berater und Trainer für Softwaretechnologie und Software Engineering. Seine Schwerpunkte liegen auf Softwarearchitektur, Middleware und modellgetriebener Softwareentwicklung. Dr. Uwe Zdun ist Universitätsassistent an der Abteilung für Wirtschaftsinformatik der Wirtschaftsuniversität Wien.
Autoren/Hrsg.
Weitere Infos & Material
1;Vorwort;6
2;Inhaltsverzeichnis;10
3;Verzeichnis der Autoren;16
4;1 Einleitung;18
4.1;1.1 Ausgangslage und Zielsetzung des Buches;19
4.2;1.2 Was ist Software-Architektur?;25
4.3;1.3 Leser-Leitfaden;28
4.3.1;1.3.1 Buchaufbau;28
4.3.2;1.3.2 Zielpublikum;32
4.3.3;1.3.3 Kapitelüberblick;32
4.3.4;1.3.4 Kapitel im Detail;35
5;2 Architektonischer Ordnungsrahmen;40
5.1;2.1 Motivation;41
5.2;2.2 Ordnungsrahmen im Überblick;43
5.3;2.3 Architekturen und Architektur-Disziplinen ( WAS);47
5.4;2.4 Architektur-Perspektiven (WO);48
5.5;2.5 Architektur-Anforderungen (WARUM);49
5.6;2.6 Architektur-Mittel (WOMIT);50
5.7;2.7 Organisationen und Individuen (WER);53
5.8;2.8 Architektur-Vorgehen (WIE);54
6;3 Architekturen und Architektur-Disziplinen (WAS);56
6.1;3.1 Klassische Architektur als Ausgangspunkt;57
6.2;3.2 Von der klassischen Architektur zur Software- Architektur;61
6.3;3.3 Architektur und der Systemgedanke;69
6.4;3.4 Architektur und die Bausteine eines Systems;74
7;4 Architektur-Perspektiven (WO);82
7.1;4.1 Architektur-Ebenen;83
7.1.1;4.1.1 Organisationsebene;88
7.1.2;4.1.2 Systemebene;90
7.1.3;4.1.3 Bausteinebene im Bereich Makro-Architektur;90
7.1.4;4.1.4 Bausteinebene im Bereich Mikro-Architektur;91
7.2;4.2 Architektur-Sichten;92
7.2.1;4.2.1 Zachman-Framework;101
7.2.2;4.2.2 Reference Model for Open Distributed Processing;104
7.2.3;4.2.3 4+1-Sichten-Modell;105
8;5 Architektur-Anforderungen (WARUM);108
8.1;5.1 Allgemeines;109
8.2;5.2 Anforderungen im Überblick;111
8.3;5.3 Anforderungen im Detail;116
8.3.1;5.3.1 Organisationsanforderungen;116
8.3.2;5.3.2 Systemanforderungen;117
8.3.3;5.3.3 Bausteinanforderungen;118
8.3.4;5.3.4 Laufzeitanforderungen;119
8.3.5;5.3.5 Entwicklungszeitanforderungen;120
8.3.6;5.3.6 Organisatorische Rahmenbedingungen;122
8.4;5.4 Anforderungen im Architektur-Kontext;123
9;6 Architektur-Mittel (WOMIT);128
9.1;6.1 Architektur-Prinzipien;129
9.1.1;6.1.1 Prinzip der losen Kopplung;131
9.1.2;6.1.2 Prinzip der hohen Kohäsion;134
9.1.3;6.1.3 Prinzip des Entwurfs für Veränderung;136
9.1.4;6.1.4 Separation-of-Concerns-Prinzip;138
9.1.5;6.1.5 Information-Hiding-Prinzip;141
9.1.6;6.1.6 Abstraktionsprinzipien;144
9.1.7;6.1.7 Modularitätsprinzip;146
9.1.8;6.1.8 Rückverfolgbarkeitsprinzip;150
9.1.9;6.1.9 Selbstdokumentationsprinzip;151
9.1.10;6.1.10 Inkrementalitätsprinzip;151
9.1.11;6.1.11 Weitere Architektur-Prinzipien;153
9.2;6.2 Grundlegende architektonische Konzepte;153
9.2.1;6.2.1 Prozedurale Ansätze;153
9.2.2;6.2.2 Objektorientierung;156
9.2.3;6.2.3 Komponentenorientierung;163
9.2.4;6.2.4 Meta-Architekturen und Reflection;166
9.2.5;6.2.5 Generative Erzeugung von Systembausteinen;168
9.2.6;6.2.6 Modellgetriebene Software-Entwicklung;170
9.2.7;6.2.7 Aspektorientierung;178
9.2.8;6.2.8 Wartung von Software-Architekturen;182
9.3;6.3 Architektur-Stile;186
9.4;6.4 Architektur-Muster;190
9.4.1;6.4.1 Was ist ein Software-Muster?;190
9.4.2;6.4.2 Beispiele für Muster;194
9.4.3;6.4.3 Mustersprachen;199
9.5;6.5 Referenzarchitekturen;203
9.5.1;6.5.1 Definition und Bestandteile;203
9.5.2;6.5.2 Einsatz und Vorteile von Referenzarchitekturen;205
9.5.3;6.5.3 Anforderungen an Referenzarchitekturen;205
9.5.4;6.5.4 Arten von Referenzarchitekturen;206
9.5.5;6.5.5 Beispiel für eine Referenzarchitektur;207
9.6;6.6 Architektur-Dokumentationsmittel;212
9.6.1;6.6.1 Architektur-Metamodelle;213
9.6.2;6.6.2 Unified Modeling Language (UML);214
9.6.3;6.6.3 Architecture Definition Languages (ADL);218
9.6.4;6.6.4 Domain Specific Languages (DSL);223
9.7;6.7 Architektur-Strukturen;225
9.7.1;6.7.1 Zentralisierung gegenüber Dezentralisierung;226
9.7.2;6.7.2 n-Tier-Architektur;228
9.7.3;6.7.3 Rich Client gegenüber Thin Client;230
9.7.4;6.7.4 Middleware-Architekturen;232
9.7.5;6.7.5 Komponentenarchitekturen;235
9.7.6;6.7.6 Serviceorientierte Architekturen;238
9.7.7;6.7.7 Enterprise Service Bus;239
9.7.8;6.7.8 P2P-Systeme;240
9.8;6.8 Aktuelle Technologien in Software- Architekturen;240
9.8.1;6.8.1 Middleware-Systeme;241
9.8.2;6.8.2 Datenbanken und Persistenz von Geschäftsobjekten;246
9.8.3;6.8.3 Datenaustausch und Datentransformation mit XML;250
9.8.4;6.8.4 Dynamische Web-Seiten und Web-Application-Server;253
9.8.5;6.8.5 Komponentenplattformen;254
9.8.6;6.8.6 Web Services;257
10;7 Organisationen und Individuen (WER);260
10.1;7.1 Allgemeines;261
10.2;7.2 Organisationen;264
10.3;7.3 Individuen;270
10.4;7.4 Individuen und Gruppen;272
10.5;7.5 Architektur und Entscheidungen;276
10.6;7.6 Architekt als zentrale Rolle;281
11;8 Architektur-Vorgehen (WIE);286
11.1;8.1 Architektonisches Vorgehen;287
11.1.1;8.1.1 Entwicklungsprozess;287
11.1.2;8.1.2 Architektonische Tätigkeiten;290
11.1.3;8.1.3 Erstellen des Business Case;293
11.1.4;8.1.4 Verstehen der Anforderungen;295
11.1.5;8.1.5 Entwerfen der Architektur;296
11.1.6;8.1.6 Umsetzen der Architektur;301
11.1.7;8.1.7 Kommunizieren der Architektur;304
11.2;8.2 Anwendungsszenario: Product Line Engineering;310
11.2.1;8.2.1 Produktlinien und Software-Systemfamilien;311
11.2.2;8.2.2 Realisierungstechnologien und Zusammenhang zu MDSD;314
11.2.3;8.2.3 Erstellen des Business Case;316
11.2.4;8.2.4 Verstehen der Anforderungen (Domänenanalyse);316
11.2.5;8.2.5 Entwerfen der Architektur (Domänendesign);319
11.2.6;8.2.6 Umsetzen der Architektur (Domänenimplementierung);320
11.2.7;8.2.7 Rollen und Aufgaben;321
11.3;8.3 Anwendungsszenario: Enterprise Application Integration;322
11.3.1;8.3.1 Erstellen des Business Case;323
11.3.2;8.3.2 Verstehen der Anforderungen;326
11.3.3;8.3.3 Entwerfen der Architektur;334
11.3.4;8.3.4 Kommunizieren und Umsetzen der Architektur;344
11.4;8.4 Anwendungsszenario: Anwendungsdienst;345
11.4.1;8.4.1 Erstellen des Business Case für das System;369
11.4.2;8.4.2 Verstehen der Anforderungen;380
11.4.3;8.4.3 Entwerfen der Architektur;390
11.4.4;8.4.4 Kommunizieren und Umsetzen der Architektur;401
12;9 Risikofallmanagementsystem;406
12.1;9.1 Zusammenfassung;407
12.2;9.2 Architektur-Anforderungen (WARUM);408
12.2.1;9.2.1 Business Case;408
12.2.2;9.2.2 Organisationsanforderungen;409
12.2.3;9.2.3 Systemanforderungen;414
12.2.4;9.2.4 Bausteinanforderungen;418
12.3;9.3 Architekturen und Architektur-Disziplinen ( WAS);424
12.3.1;9.3.1 Disziplinen;424
12.3.2;9.3.2 Entscheidungen zur Software-Architektur;426
12.4;9.4 Architektur-Perspektiven (WO);428
12.4.1;9.4.1 Systemebene;428
12.4.2;9.4.2 Bausteinebene;429
12.5;9.5 Architektur-Mittel (WOMIT);433
12.5.1;9.5.1 Architektur-Prinzipien;433
12.5.2;9.5.2 Grundlegende architektonische Konzepte;435
12.5.3;9.5.3 Generative und generische Verfahren;436
12.6;9.6 Organisationen und Individuen (WER);440
12.6.1;9.6.1 Organisation;441
12.6.2;9.6.2 Individuen;443
12.7;9.7 Architektur-Vorgehen (WIE);444
13;10 CRM-Kundendatenrepository;446
13.1;10.1 Zusammenfassung;447
13.2;10.2 Architektur-Anforderungen (WARUM);448
13.3;10.3 Organisationen und Individuen (WER);450
13.4;10.4 Architekturen und Architektur-Disziplinen ( WAS);452
13.5;10.5 Architektur-Perspektiven (WO);452
13.6;10.6 Architektur-Mittel (WOMIT);453
13.7;10.7 Architektur-Vorgehen (WIE);454
13.8;10.8 Ausgangssituation;454
13.9;10.9 Anforderungen;456
13.10;10.10 Architektonische Entscheidungen;465
13.11;10.11 Logische Sicht;469
13.12;10.12 Umsetzung ausgewählter Anforderungen;475
13.13;10.13 Was hat die Architektur genutzt?;485
14;11 Eingebettete Komponenteninfrastrukturen;488
14.1;11.1 Zusammenfassung;489
14.1.1;11.1.1 Architektur-Anforderungen (WARUM);490
14.1.2;11.1.2 Organisation und Individuen (WER);492
14.1.3;11.1.3 Architekturen und Architektur-Disziplinen (WAS);492
14.1.4;11.1.4 Architektur-Perspektiven (WO);493
14.1.5;11.1.5 Architektur-Mittel (WOMIT);493
14.1.6;11.1.6 Architektur-Vorgehen (WIE);494
14.2;11.2 Product Line Engineering;496
14.2.1;11.2.1 Domain Scoping;496
14.2.2;11.2.2 Variabilitätsanalyse und Domänenstrukturierung;497
14.2.3;11.2.3 Kommunikationsparadigmen;498
14.2.4;11.2.4 Container-Services;501
14.2.5;11.2.5 Domänendesign;502
14.2.6;11.2.6 Produktionsprozess;504
14.3;11.3 Modelle;506
14.3.1;11.3.1 Definition von Interfaces;507
14.3.2;11.3.2 Definition von Komponenten und Ports;509
14.3.3;11.3.3 Definition eines Systems;510
14.3.4;11.3.4 Gesamtmodell;514
14.3.5;11.3.5 Generator – Überblick;514
14.4;11.4 Implementierung von Komponenten;515
14.4.1;11.4.1 Abbildung auf Java;516
14.4.2;11.4.2 Parsen und Zusammenführen des Gesamtmodells;517
14.4.3;11.4.3 Pseudodeklarative Metamodellimplementierung;521
14.5;11.5 Codegenerierung;523
14.5.1;11.5.1 Referenzen;523
14.5.2;11.5.2 Umsetzung der Protokollzustandsautomaten;527
14.5.3;11.5.3 Generierung des Build Files;528
14.6;11.6 Fachliche Kaskadierung;529
14.6.1;11.6.1 Modellierungssprache;529
14.6.2;11.6.2 Generierung;531
14.7;11.7 Erfahrungen aus unserem Unternehmen;531
15;Literaturverzeichnis;534
16;Abkürzungsverzeichnis;554
17;Index;558
3 Architekturen und Architektur- Disziplinen (WAS) (S.39)
Dieses Kapitel befasst sich mit der WAS-Dimension des architektonischen Ordnungsrahmens. Es vermittelt ein grundlegendes Verständnis von Architektur, indem es aufzeigt, was im Rahmen dieses Buches unter Architektur und damit verbundenen Architektur-Disziplinen zu verstehen ist.
Darüber hinaus werden wesentliche Systembausteine und ihre Beziehungen zueinander vorgestellt. Da der Charakter von Systemen und das Denken in Systemen für die Arbeit eines Architekten essenziell sind, wird der Systemgedanke im Kontext von Architektur in diesem Kapitel motiviert. Nach dem Lesen dieses Kapitels sind Sie in der Lage, den allgemeinen Charakter von Architektur zu erklären, einzelne Architektur- Disziplinen zu unterscheiden sowie die wichtigsten Bausteine von Systemen zu differenzieren und ihre Beziehungen darzustellen.
3.1 Klassische Architektur als Ausgangspunkt
Dieser Abschnitt betrachtet Architektur aus einem allgemeinen Blickwinkel. Er zeigt auf, was ganz allgemein unter Architektur zu verstehen ist. Auf der Grundlage dieses Verständnisses wird im weiteren Verlauf dieses Kapitels Software-Architektur vorgestellt. Als Ausgangspunkt für diese Betrachtung dient die klassische Architektur von Gebäuden und Bauwerken. Eine mögliche Definition der klassischen Architektur bietet das American Heritage Dictionary:
The art and science of designing and erecting buildings. A style and method of design and construction Orderly arrangement of parts Wenn man diese Definition zugrunde legt, ist Architektur sowohl eine Kunst (englisch: art) als auch eine Wissenschaft (englisch: science), die sich sowohl mit dem Entwerfen (englisch: designing) als auch mit dem Bauen (englisch: erecting) von Bauwerken beschäftigt.
Sie konzentriert sich also nicht nur auf die Planung des Bauwerks, sondern erstreckt sich hinein bis in dessen Realisierung. Ferner ist ein Schlüsselergebnis der Architektur-Tätigkeit das Arrangieren beziehungsweise das Anordnen von Teilen des Bauwerks (englisch: orderly arrangement of parts). Somit trifft Architektur wichtige Aussagen über die Struktur des Bauwerks. Die Definition besagt weiter, dass Architektur-Stile (englisch: styles) und -Methoden (englisch: methods) Bestandteile von Architektur sind.
Diese repräsentieren architektonische Erfahrung, die der Architekt im Rahmen seiner Tätigkeit einsetzt. Architektur ist hiermit nicht nur die Struktur eines Bauwerks, sondern auch die Art und Weise, an etwas heranzugehen.
Der Begriff Architektur ist somit nicht eindeutig belegt. Stattdessen versteht man unter Architektur zum einen die Struktur eines Bauwerks oder eines IT- bzw. Software-Systems und zum anderen die von Menschen ausgeübten Tätigkeiten zum Entwurf der Struktur. Um die eigentliche Tätigkeit beziehungsweise das architektonische Handeln besser von den strukturellen Aspekten von Architektur zu unterscheiden, wird das Handeln im weiteren Verlauf als Architektur-Disziplin verstanden.
Architekturen entstehen ganz generell aufgrund von Anforderungen (z. B. dem Wunsch nach einfachen Behausungen) und unter Verwen- dung von vorhandenen Mitteln (z. B. Baumaterialien und Werkzeugen). Der eigentliche Entwurf basierte in der klassischen Architektur zunächst a uf d em P rinzip v on V ersuch u nd I rrtum ( englisch: trial and error) und erfolgte in aller Regel ad hoc.
Dadurch besaß auch jedes Bauwerk seine individuellen Strukturen. Eine geordnete Anordnung von Teilen durch eine geplante Architektur war meist nicht gegeben. Erst indem die gewonnenen Architektur-Erfahrungen mündlich oder schriftlich weitergegeben wurden, entwickelten sich Architektur-Stile.
