Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!

Lehrplan „Grundlagen der Software- 

Architektur“ 

iSQI Certified Professional for Software Architecture 

Foundation Level 

Version 1.0 

Stand: 10.01.2003 

© ASQF e. V.

Lehrplan „Grundlagen der Software-Architektur“ 

Historie des Lehrplans 

Version Stand Bemerkung 

0.9 05.01.2003 Letzter Entwurf für Freigabe 

1.0 10.01.2003 Erste freigegebene Version 

Verzeichnis der verwendeten Abkürzungen 

Abkürzung 

SEI 

RUP 

XP 

V-Modell 

UML 

OMG 

OCL 

Begriff 

Software-Engineering Institute der Carnegie-Mellon-Universität 

Rational Unified Process 

Extreme Programming 

Vorgehensmodell des Bundes 

Unified Modelling Language der OMG 

Object Management Group 

Object Constraint Language der OMG 

Copyright und Nutzungsrechte 

Das Werk ist urheberrechtlich geschützt. Jede Verwertung außerhalb des Urheberrechtsgesetzes 

ist ohne Zustimmung des iSQI unzulässig und strafbar. 

v1.0 Seite 2 von 46 

© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung


Anmerkung: Die Zeitangaben beziehen sich auf den Theorieanteil des jeweiligen Themas und sollen 

einen groben Anhaltspunkt für die Gewichtung der einzelnen Themen auf Basis einer viertägigen 

Schulung geben. Der Übungsanteil ist nicht enthalten. 

Lehrplan Thema Beschreibung Zeit (min.) 

Einleitung 30 

Vorstellung des iSQI-Certified-Programms bzgl. dessen Inhalte, Motivation und Zielsetzung. 

Vorstellung des iSQI Certified Professional for Software Architecture im Besonderen. 

Überblick, Aufbau, Ablauf und Zielsetzung der Schulung. 

Die Software-Architektur 90 

In diesem Kapitel werden der Begriff „Software-Architektur“ definiert, die Beschäftigung 

mit Software-Architektur motiviert und Wechselwirkungen der Software-Architektur mit 

anderen Disziplinen, Phasen und Tätigkeiten im Kontext von Unternehmen und Projekten 

aufgezeigt. 

Definition Was ist Software-Architektur? 12 

Eine allgemeingültige Definition des Begriffs Software-Architektur existiert nicht; allerdings gibt es 

auch keinen Mangel an verschiedenen Definitionen. Beispielsweise listet das Software-Engineering 

Institute der Carnegie-Mellon-Universität auf seiner Webseite über fünfzig unterschiedliche Definitionen 

auf, hebt allerdings einige davon als „classic definitions“ hervor. 

Der Grund für die Vielzahl an Definitionen ist laut SEI, dass die Software-Architektur zwar tiefe Wurzeln 

im Software Engineering hat, allerdings selbst eine noch sehr junge Disziplin ist. 

Eine klassische Definition ist die von Booch, Rumbaugh and Jacobson, 1999. Diese Definition hebt 

zum einen die wesentliche Tätigkeit des Professional for Software Architecture hervor, wichtige Entscheidungen 

zu treffen. Weiterhin werden für die Software-Architektur wesentliche Eigenschaften 

aufgelistet: Organisation, Struktur, Verhalten, Komposition, Stil. 

In der Arbeit von Standardisierungsgremien wie der IEEE wird der Begriff Software-Architektur ebenfalls 

berücksichtigt. Die IEEE Architecture Working Group hat bereits im September 2000 den IEEE- 

Standard 1471 verabschiedet, der den Titel „IEEE Recommended Practice for Architectural Description 

of Software-Intensive Systems“ trägt. 




Motivation 

Wozu wird eine Software-Architektur benötigt? 

10 

Die Frage „Wozu wird eine Software-Architektur benötigt?“ ist zunächst falsch gestellt: Natürlich hat 

jedes nicht triviale Softwaresystem zumindest implizit eine Software-Architektur, selbst wenn sich 

niemand ausdrücklich darum kümmert. Allerdings: Wenn alle anstehenden Entscheidungen über die 

wesentlichen Elemente einer Software-Architektur unbewusst von verschiedenen Entwicklern eines 

Teams ohne definierten Prozess getroffen werden, so hat dies unmittelbare, negative Konsequenzen 

für den Projekterfolg: 

• Ergebnisse der Analysephase führen nicht zu bewußten Entscheidungen für spätere Phasen 

und gehen verloren. 

• Struktur und Verhalten der Software ergeben sich bestenfalls aus technologischen Einzelentscheidungen, 

schlimmstenfalls zufällig. 

• Vorhandenes Wissen aus vorherigen Projekten ist an die einzelnen Entwickler gebunden und 

geht daher leicht verloren oder wird nicht wiederverwendet. 

• Flexibilität und Erweiterbarkeit sind nur eingeschränkt möglich oder gehen auf Kosten der Konsistenz 

des Softwaredesigns. 

• Dokumentation ist lästige Pflicht ohne direkten Bezug zum Softwaresystem. 

• Verständlichkeit und Gesamtübersicht leiden, vor allem für externe Projektbeteiligte wie Management, 

Betreiber, Kunden. 

Diese Probleme führen schließlich zu längeren Projektbearbeitungszeiten und manchmal sogar zum 

Scheitern von Software-Projekten. 




Einordnung 

Software-Architektur als Bindeglied zwischen 

fachlicher Struktur und Implementierung 

12 

Software-Architektur schlägt die Brücke zwischen vielfältigen Anforderungen aus der Fachdomäne 

und der technischen Realisierung eines Systems. Aus einer Anforderungsdefinition kann eine Software-Architektur 

abgeleitet bzw. erarbeitet werden. Hierbei werden die Struktur des Softwaresystems 

festgelegt und erste technologische Entscheidungen getroffen. 

Dabei ist es wichtig, Informationen zu filtern und wegzulassen, um nicht benötigte Details auszusondern 

und die Konzentration auf eine geeignete Abstraktionsebene zu heben. 

Software-Architektur und Design lassen sich nicht klar voneinander abgrenzen. Der Entwurf von 

Softwaresystemen kann auf verschiedenen Abstraktionsebenen stattfinden. Architektur = Gestaltung 

im Großen. 

Die Software-Architektur wird heute vorwiegend mittels graphischer Modelle formuliert. Den Sprung 

von graphischen Modellen zur Implementierung können oftmals Codegeneratoren leisten. Den Softwaretest 

unterstützt die Software-Architektur ebenfalls durch Bereitstellung geeigneter Schnittstellen 

innerhalb der Software-Architektur und Abstimmung des Testrahmens mit dem Testteam. 

Die Software-Architektur als Disziplin steht im Zentrum aller Aktivitäten eines Projekts. 




Stellenwert 

Stellenwert einer Software-Architektur für 

Unternehmen und Projekte 

11 

Eine dedizierte Software-Architektur bringt sowohl dem Unternehmen als auch den dort durchgeführten 

Projekten eine Reihe von Vorteilen. Diese lassen sich in technische und organisatorische Vorteile 

gliedern. 

Organisatorische Vorteile: 

• Software-Architektur schafft den Übergang von der Analyse zur Realisierung und ermöglicht die 

Erfüllung von Systemanforderungen 

• Software-Architektur ermöglicht die Kommunikation des High-Level-Designs und vermittelt den 

Gesamtzusammenhang („roter Faden“) 

• Software-Architektur erlaubt die Aufteilung der weiteren Arbeit in geschlossene Arbeitsblöcke 

• Software-Architektur dokumentiert Systeme und macht sie für alle Projektbeteiligten verständlich 

Technische Vorteile: 

• Software-Architektur ermöglicht es, die Komplexität von Systemen zu beherrschen 

• Software-Architektur stellt einen Rahmen für Wiederverwendung dar (Verwendung von bereits 

existierenden und zugekauften Komponenten) 

• Software-Architektur ist die Basis für Flexibilität und Erweiterbarkeit 

• Software-Architektur reduziert Kosten für Wartung und Weiterentwicklung 

Um diese Vorteile zu erzielen, sollte die Software-Architektur einen hohen Stellenwert in Entwicklungsabteilungen 

des Unternehmens einnehmen. Dazu gehört es, ausgewiesene Professionals for 

Software Architecture mit der Aufgabe zu betrauen, wesentliche Entscheidungen zur Erarbeitung einer 

Software-Architektur verantwortlich zu treffen. 




Wechselwirkungen 

Rolle und Umfeld der Software- 

Architektur 

15 

Software-Architektur bündelt unternehmensweites Know-how 

Der Nutzen, den ein Unternehmen aus der konsequenten Durchführung der Disziplin Software- 

Architektur ziehen kann, muss sich nicht nur auf Einzelprojekte beschränken. Gerade die Vorteile 

durch Wiederverwendung von Komponenten, Strukturen und Organisationsformen sowie die Standardisierung 

von grundlegenden Architektur- und Designmustern wirken sich projektübergreifend 

und im besten Fall unternehmensweit aus. 

Eine Software-Architektur sollte so flexibel sein, dass sie für viele, ähnliche Projekte eines Unternehmens 

anwendbar ist. Die Software-Architektur bündelt das projektübergreifende, unternehmensweite 

Know-how in Form von explizit aufgezeichneten Modellen oder Dokumenten. 

Dabei muss die Durchgängigkeit von Konzepten über den gesamten Entwicklungsprozess durch die 

Software-Architektur getragen werden. 

Externe Einflüsse auf die Software-Architektur 

Die Software-Architektur für ein Projekt unterliegt vielfältigen Einflüssen: 

• Beteiligte Menschen beeinflussen die Software-Architektur durch ihre Fähigkeiten und ihr Knowhow 

• Das Unternehmen sowie Organisations- und Abteilungsstruktur beeinflussen die Software- 

Architektur in ihren Grundsätzen und Werten 

• Die Software-Architektur muss die Maximierung des Kundennutzens berücksichtigen 

• Andere Projekte im Unternehmen bestimmen wesentliche Teile der Software-Architektur 

• Bestehende Systeme oder Frameworks sollten in der Software-Architektur berücksichtigt werden 

(Vereinheitlichung, Wiederverwendung, Standardisierung) 

• Organisatorische Bedingungen wie Zeit, Budget oder zu erzielende Qualität geben den Rahmen 

für die Software-Architektur vor 

• Produkte und Technologien, die bereits im Team bekannt sind, beeinflussen ebenfalls die Entscheidungen 

für die Software-Architektur. 

Starke zeigt die unterschiedlichen Ebenen der Wechselwirkungen von externen Einflüssen und 

Software-Architektur anhand von einigen praktischen Beispielen auf. 

Bereits 1968 hat Melvin Conway sein Gesetz formuliert, welches besagt, dass die Struktur in einer 

Software-Architektur und die Struktur der Organisation oftmals kongruent sind. Dabei können Kräfte 

in beide Richtungen wirken. 




Anforderungen und Software-Architektur 

Die Schnittstellen zwischen der Anforderungsanalyse 

und der Software- 

Architektur 

20 

Software-Architektur hat eine zentrale Rolle in Softwareprojekten. Die Software-Architektur hat dabei 

Schnittstellen zu anderen Aktivitäten innerhalb einer Organisation, die wichtigsten sind: 

• Anforderungsanalyse 

• Design und Implementierung 

• Projektplanung 

• Test und Qualitätssicherung 

• Hardware-Architektur 

Die Software-Architektur dient dabei den Beteiligten als zentrale Referenz bzw. als Leitbild. 

Im Besonderen soll hier die Schnittstelle zur Anforderungsanalyse näher behandelt werden. 

• auf Basis funktionaler Anforderungen Architektur erstellen 

• nicht-funktionale Anforderungen berücksichtigen 

• Durchstich 

• Architektur auf wesentliche Anforderungen testen 

• Kreativer Schritt, Erfahrung 

Die Analysephase muss sicherstellen, dass das richtige System entwickelt wird. Die Entwurfsphase 

stellt hingegen sicher, dass das System richtig entwickelt wird. 

Die Schnittstelle von der Anforderungsanalyse zur Software-Architektur ist keine Einbahnstraße: Ü- 

ber die Aspekte der technischen Machbarkeit und der Kosten hat die Software-Architektur ihrerseits 

Einflüsse auf die Anforderungen, die letztendlich im Pflichtenheft verbindlich festgelegt werden. 

Der Professional for Software Architecture prüft, präzisiert und klärt einerseits die Anforderungen; 

andererseits muss er die Rückwirkungen überblicken und gegebenenfalls den Analysten notwendige 

Änderungen rückmelden. Er arbeitet also stets mit einem unvollständigen Satz von Anforderungen, 

der nicht unbedingt konsistent sein muss. Somit sitzt der Professional for Software Architecture an 

der Schnittstelle beider Aktivitäten. 

Die Anforderungen aus der Anforderungsanalyse werden zum einen in fachliche und technische Anforderungen 

unterschieden, zum anderen in funktionale und nicht-funktionale Anforderungen. 

Fachliche Anforderungen beschreiben Funktion und Verhalten bezogen auf die Fachdomäne, technische 

Anforderungen beziehen sich auf die technische Umsetzung. 

Im Volere Requirements Specification Template der Atlantic Systems Guild werden funktionale Anforderungen 

ausführlich definiert. 

Der Professional for Software Architecture muss bei der Erarbeitung einer Lösung für einen gegebenen 

Satz von Anforderungen damit rechnen, dass es zwischen einzelnen Anforderungen Konflikte 

gibt oder gar eine Teilmenge der Anforderungen in sich widersprüchlich ist. Somit besteht bei der 

Anforderungsanalyse und bei Erstellung der Software-Architektur ein hoher Bedarf, Entscheidungen 

zu treffen. 




Aktuelle Forschung Architekturtransformation 10 

In einer jungen Disziplin wie der Software-Architektur gibt es eine Vielzahl von Forschungsaktivitäten, 

von denen eine herausgegriffen werden soll: die Architekturtransformation. 

Architekturtransformation wird von Prof. Jan Bosch (Univ. Groningen, NL) als eine der Methoden 

propagiert, die zur Etablierung von Produktpipelines für Softwareprodukte notwendig ist. 




Der Professional for Software Architecture 50 

Dieses Kapitel beschreibt die Rolle des Professional for Software Architecture. Es klärt, 

was einen Professional for Software Architecture ausmacht und welche Qualifikationen 

er besitzen sollte. 

Begriffsklärung 

Was ist ein Professional for Software Architecture 

? 

5 

Der Professional for Software Architecture nimmt eine zentrale Rolle in einem Softwareprojekt ein. 

Mit seiner Leistung steht und fällt das Ergebnis des gesamten Projekts. Seine Fähigkeit, auch zukünftige 

Veränderungen einzuplanen und zu ermöglichen, beeinflusst den Wert und die Dauerhaftigkeit 

des Ergebnisses maßgeblich. 




Fähigkeiten 

Welche Qualifikationen muss ein Professional 

for Software Architecture besitzen? 

10 

Der typische Werdegang zum Professional for Software Architecture ist der vom Entwickler zum erfahrenen 

Entwickler hin zu einem Teammitglied, das zentralen und wesentlichen Einfluss auf Projektverlauf 

und -ergebnis hat. 

Professionals for Software Architecture werden deshalb nicht geboren, sondern eignen sich ihre Fähigkeiten 

durch Projektarbeit an. Natürlich profitieren sie auch von den Erfahrungen anderer. Eigene 

Erfahrungen sind für diese Aufgabe jedoch immer vorzuziehen. 

Die Fähigkeiten, die ein Professional for Software Architecture besitzen muss, sind in verschiedenen 

Bereichen anzusiedeln: 

Er muss kommunikative Fähigkeiten (Soft Skills) besitzen, wie 

• Abstraktionsfähigkeit 

• Entscheidungsfähigkeit 

• Durchsetzungsvermögen 

• Teamfähigkeit 

• Kommunikations- und Überzeugungsfähigkeit 

da er mit (nahezu) allen anderen beteiligten Projektrollen kommunizieren, seine Lösungen vorstellen 

und vertreten muss. 

Hinzu kommen intensive technische Erfahrungen wie 

• Kenntnisse über gängige technische Lösungen für die Hauptarchitekturprobleme GUI, Persistence, 

Networking, Verteilung, Security, 

um das zu erstellende System verständlich, zukunftssicher und leicht erweiterbar bzw. wartbar gestalten 

zu können. 

Der Professional for Software Architecture sollte deshalb eine starke Persönlichkeit sein; er ist typischerweise 

ein Generalist: Sein Wissen wird gleichermaßen durch Soft Skills und technische Erfahrungen 

geprägt. 

Oft fällt er auf Basis unvollständigen Wissens auch suboptimale Entscheidungen. Eine iterative Entwicklung 

ist heutzutage erforderlich, um Lücken zu füllen oder neues Wissen einfließen zu lassen. 




Kommunikation und Kooperation 

Wie arbeitet der Professional for Software 

Architecture im Projektteam? 

Welche Aufgaben nimmt er wahr? 

15 

Aufgrund seiner zentralen Rolle ist der Professional for Software Architecture Ansprechpartner für 

viele andere Projektmitglieder: 

• Fachabteilungen (für technische und fachliche Anforderungen) 

• Projektmanagement (zur Einflussnahme auf Projektplanung, -ablauf und -controlling) 

• Entwickler (zum Verständnisaufbau (Überblick des Systems) und für Entwicklungsvorgaben) 

• Testteam (zur Abstimmung der Testrahmenbedingungen) 

Von der Fachabteilung bekommt er den Input, was zu tun ist. In Abstimmung mit dem Projektmanagement 

legt er fest, wann und unter welchen Rahmenbedingungen es getan werden kann. Mit den 

Entwicklern erfolgt schließlich die Vorgabe und Abstimmung, wie das System umgesetzt werden soll. 

Seine typischen Aufgaben sind: 

• Entgegennahme und inhaltliche Abstimmung der fachlichen und technischen Anforderungen mit 

der Fachabteilung (Artefakte sind Pflichtenhefte, Anforderungen jeglicher Art) 

• Vorgabe und Abstimmung der Architektur, entsprechender Richtlinien und Muster sowie des 

Vorgehens mit dem Entwicklungsteam (Modelle sowie Beispiele für Architektur und Vorgehen, 

Architektur- und Entwicklungsmuster, repräsentativer Beispielcode) 

• Abstimmung der Architektur auf Testbarkeit, Test der Architektur und Testbarkeit der Entwicklungsergebnisse 

mit dem Testteam (Testszenarien und -pläne) 

• Abstimmung von Entwicklungszyklen und -ergebnissen mit der Projektleitung (Projektpläne und 

Termine) 

• (typischerweise iterativer) Entwurf, Integration und Test der Architektur 




Handwerkszeug 

Was benötigt der Professional for Software 

Architecture für seine Aufgabe? 

10 

Die Grundlagen für seine Arbeit sind Modelle, Heuristiken, Muster aus anderen Projekten, Codeschnipsel 

und weiteres, die einerseits bestehende Erfahrungen dokumentieren und zum anderen die 

konkreten Anforderungen des aktuellen Projekts aufzeigen. 

Vergleichbar mit einem Puzzle setzt der Professional for Software Architecture Einzelteile zusammen, 

zerlegt Bestehendes, löst Widersprüche auf und fügt all dieses zu einem neuen Großen und 

Ganzen zusammen. 

An geeigneter Stelle wird in den folgenden Kapiteln detailliert auf dieses Thema eingegangen. 




Besonderheiten 

Wie arbeitet der Professional for Software 

Architecture im Team? 

Gibt es in jedem Projekt diese Rolle? 

10 

Stehen diese Fähigkeiten nicht in einer einzelnen Person zur Verfügung oder kann eine einzelne 

Person in einem großen Projekt diese Aufgabe nicht alleine wahrnehmen, so kann der „Professional 

for Software Architecture “ auch durch ein Team gebildet werden. 

Die Größe des Teams ist dabei auch bei großen Projekten zu beschränken, um die Anzahl möglicher 

Meinungen zu begrenzen und Koordinationsaufwände zu minimieren. Die Anzahl der Mitglieder 

orientiert sich an der Größe des Projekts und den verschiedenen Themengebieten. 

Handelt es sich umgekehrt um ein sehr kleines Projekt, so kann die Rolle des Professionals for 

Software Architecture auch mit einer anderen, z. B. der des Projektleiters zusammenfallen. 

Zu beachten ist, dass gerade in agilen oder XP-Projekten ein neues/anderes Rollenverständnis 

herrscht. Hierarchien werden vereinfacht oder sind nicht vorhanden. Auch hier können Rollen zusammenfallen. 




Vorgehen 50 

In diesem Kapitel werden die wichtigsten Schritte und deren Ergebnisse bei der Erstellung 

einer Software-Architektur behandelt. Dabei wird von einem konkreten Prozessmodell 

abstrahiert. 

Einordnung 

Prozesse und die Einordnung von Architektur, 

Allgemeines Vorgehen 

10 

Architektur als zentrales Thema im Entwicklungsprozess. 

Softwareentwicklungsprozesse beschreiben eine Reihe von Disziplinen bei der Softwareentwicklung. 

Sie legen dabei Rollen (Verantwortlichkeiten), Dokumente (Arbeitsergebnisse) und Aktivitäten fest. 

Jeder Prozess setzt hier andere Schwerpunkte. Das Thema Architektur spielt aber bei allen Prozessen 

eine zentrale Rolle. Es wird lediglich unterschiedlich dargestellt. Während im RUP eine explizite 

Rolle des „Architekten“ vergeben ist, der für bestimmte Teilaktivitäten verantwortlich ist, verteilen 

sich die Architekturaktivitäten bei XP auf verschiedene andere Rollen. 

Die Softwarearchitektur bildet immer das Grundskelett für alle anderen Prozessaktivitäten. Sie stellt 

die Struktur für die weitere Detaillierung zur Verfügung. Die Prozesse unterscheiden sich dabei allerdings 

stark bezüglich der geforderten Formalität und der Rollen und Dokumente. 

Die Architektur eines Systems spiegelt zu einem großen Anteil die nicht-funktionalen Anforderungen 

(Qualitätseigenschaften) wieder und gibt zum anderen Aufschluss über potentielle Risiken. Diese Informationen 

sind wiederum essentiell für das Projektmanagement. 




Zentrale Rolle der Software-Architektur 

im Entwicklungsprozess 

Vorgehen bei der Software-Architektur 25 

Angelehnt an die verschiedenen existierenden Softwareentwicklungsprozesse wird ein allgemeingültiger 

Vorgehensrahmen mit dessen Schritten und Artefakten definiert. 

Iterative, inkrementelle Prozesse sind heute Standard. Diese unterscheiden zeitlich aufeinanderfolgende 

Phasen und dazu querschnittlich angeordnete Aktivitäten. Diese Phasen bilden dabei wesentliche 

Meilensteine für das Projekt. Die Aktivitäten ziehen sich in unterschiedlicher Intensität durch alle 

Phasen. 

Der Professional for Software Architecture ist an allen Phasen beteiligt. Seine Aktivitäten laufen in 

der Analyse- und Design-Aktivität ab und wirken sich auf alle anderen Aktivitäten aus. 

Wichtige Schritte im Rahmen der Architekturerstellung und Überarbeitung sind: 

• Machbarkeitsstudie & Risikoanalyse 

• Priorisierung der Anforderungen 

• Konkretisierung der Risikoanalyse 

• Iterationsplanung 

• Architekturkonzept 

• Koordination der Entwicklung 




Schnittstellen und Wechselwirkungen 

mit anderen 

Rollen 

Welche Schnittstellen gibt es zu anderen 

Rollen? Was ist Gegenstand dieser 

Schnittstellen? 

15 

Der Professional for Software Architecture hat eine Reihe von Schnittstellen zu anderen Rollen in 

der Softwareentwicklung. 

Professional for Software Architecture – Fachabteilung (Analyst) 

Zwischen dem Professional for Software Architecture und der Fachabteilung findet im Wesentlichen 

eine Wechselwirkung bezüglich der Anforderungen statt. Die Fachabteilung liefert die Anforderungen 

für die der Professional for Software Architecture ein Gesamtkonzept entwerfen soll. Der Professional 

for Software Architecture evaluiert diese Anforderungen auf ihre technische Machbarkeit (speziell 

auch auf widersprüchliche Anforderungen). Daraus können Konkretisierungen bzw. Änderungsanforderungen 

an die Fachabteilung resultieren. Außerdem findet ein Informationstransfer bezüglich 

der Risiken von der Fachabteilung zum Professional for Software Architecture statt. 

Professional for Software Architecture – Entwickler 

Der Professional for Software Architecture stellt den Entwicklern eine Gesamtarchitektur als Grundlage 

für das Feindesign zur Verfügung und sichert das Zusammenspiel zwischen den verschiedenen 

Komponenten. In diesem Zusammenhang gibt er den Entwicklern Architekturkonzepte, Technologien 

und Tools sowie Implementierungsrichtlinien vor. Die Entwickler auf der anderen Seite geben den 

Umsetzungsstatus und eventuell notwendige oder gewünschte Änderungen an den Professional for 

Software Architecture weiter. Dieser muss dann darüber entscheiden ob diese Anfragen umgesetzt 

werden können und ob es sich dabei um Probleme handelt, die kritisch für die erfolgreiche Umsetzung 

des Gesamtsystems sind. 

Professional for Software Architecture – Tester 

Der Professional for Software Architecture unterstützt das Testteam beim Aufbau des Testframeworks. 

Außerdem kann er bei einer großen Anzahl von Testfällen bei der Priorisierung bzw. Auswahl 

wichtiger Testfälle behilflich sein. Das Testteam liefert dem Professional for Software Architecture 

Informationen bezüglich der Stabilität der Architektur und des Erfüllungsgrades der Qualitätsanforderungen. 

Professional for Software Architecture – Projektleitung 

Der Projektleiter liefert dem Professional for Software Architecture die Projektziele und organisatorischen 

Randbedingungen. Der Professional for Software Architecture muss daraus eine Basisarchitektur 

ableiten und potentielle Risiken identifizieren. Im weitern Verlauf erstellt er dann mit Hilfe der 

Anforderungen der Fachabteilung eine Grobarchitektur und einen Iterationsplan. Zu den wesentlichen 

Aufgaben des Professional for Software Architecture gehört es, den Projektleiter stetig über 

den aktuellen Stand der technischen Risiken und Lösungsmöglichkeiten, sowie den Projektstatus 

der Iterationsplanung zu informieren. 




Notation und Modellierung 120 

Dieses Kapitel zeigt auf, wie Architektur beschrieben und dargestellt wird. Der Schwerpunkt 

liegt auf der gezielten Verwendung der graphischen Modellierungssprache UML 

für unterschiedliche Sichten auf die Architektur. 

Motivation 

Notation zur Kommunikation, Dokumentation 

und Codegenerierung 

10 

Um Interpretationsmöglichkeiten zu vermeiden wird eine Notationsform benötigt, die über eine höhere 

Abstraktionsebene verfügt als reiner Quellcode und zudem standardisiert ist. 

Zwei Kernprobleme der Softwareentwicklung sind die Kommunikation im Team sowie die Erstellung 

von Dokumentation. Eine standardisierte Modellierung trägt zur Lösung beider Probleme bei. 

Existieren in einem Projekt nicht die richtigen Kommunikationsstrukturen, gerät dies ab einer bestimmten 

Komplexität ins Stocken und das Team wird ineffektiv. Eine ausführliche Softwarearchitektur, 

die in einer standardisierten Form notiert ist, leistet einen wesentlichen Beitrag zur Behebung 

dieses Kommunikationsproblems. Entscheidend ist, dass dadurch jedem Beteiligten sofort die wesentlichen 

Strukturen, Mechanismen, Einschränkungen, Schnittstellen und Verantwortlichkeiten von 

Elementen der Software klar verständlich werden und ihm somit die Bedeutung und Auswirkung der 

von ihm entwickelten Teile der Software verständlich werden. Insbesondere wird es dem Entwickler 

ermöglicht, in einem hohen Maße selbständig und unabhängig zu arbeiten, da ihm die notwendigen 

Informationen für seine Arbeit vorliegen. 

Gerade bei komplexer Software ist die Erstellung einer aussagekräftigen, qualitativ hochwertigen 

Dokumentation sehr aufwendig. Hinzu kommt, dass es sehr schwierig ist, die Dokumentation aktuell 

zu halten. Gerade für den Investitionsschutz und die Wartung spielt eine gute Dokumentation jedoch 

eine wichtige Rolle. Eine standardisierte Modellierung hilft hierbei, da sie teilweise Codegenerierung 

ermöglicht: „The model ist the code“. Da aus den Modellen auch die Dokumentation generiert werden 

kann, ist deren Erstellung mit deutlich weniger Aufwand verbunden. Zudem bleibt ist sie immer 

auf dem aktuellen Stand. 




UML 

UML als standardisierte Notationsform für 

Software 

10 

Als standardisierte Notationsform für Software hat sich UML etabliert. UML ist eine allgemeingültige 

Modellierungssprache, die für alle wesentlichen Objekt- und Komponentenmethoden in beliebigen 

Branchen und Domänen angewendet werden kann. Die Standardisierung der UML wird durch die 

Object Management Group (OMG, www.omg.org) vorangetrieben. 

Die OMG ist eine nicht auf Profit ausgerichtete Organisation. Sie hat Ihren Hauptsitz in der Nähe von 

Boston in den USA. Bei den Mitgliedern der OMG handelt es sich um Unternehmen und Organisationen 

aus aller Welt. OMG-Standards werden durch einen definierten Prozess vorangetrieben und 

durch einen Abstimmungsprozess der Mitglieder verabschiedet. 

1997 wurde die UML in der ersten Version 1.1 auf Basis einer breiten Unterstützung der Industrie 

verabschiedet. In 2001 wurde die Version 1.4 verabschiedet. 2003 wurde die UML in der Version 2.0 

freigegeben. Diese Version enthält wesentliche Erweiterungen, die auf der Basis der praktischen 

Anwendungserfahrungen der letzten Jahre eingeflossen sind. Neben dem allgemeinen UML- 

Standard gibt es noch standardisierte Profile, welche die UML für den Einsatz in bestimmten Domänen, 

wie z. B. Enterprise- oder Real-Time-Software spezialisiert. 

Die UML definiert eine Menge von Elementen mit deren Bedeutung und graphischer Notation. Es 

handelt sich dabei sowohl um statische, wie auch dynamische Elemente. Dazu zählen z. B. Klassen, 

Komponenten, Pakete, Aktionen, Interaktionen, Zustandsautomaten, Use Cases etc. Neben diesen 

Elementen definiert die UML auch eine Menge von Diagrammen. Die Diagramme ermöglichen es, 

verschiedene Aspekte eines Softwaresystems darzustellen. Dazu zählen statische Diagrammtypen 

wie Klassendiagramme, Komponentendiagramme, Verteilungsdiagramme aber auch dynamische 

Diagrammtypen, wie Sequenzdiagramme, Aktivitätsdiagramme oder Zustandsdiagramme. 

Die wesentlichen Diagrammtypen der UML zur Beschreibung der Softwarestruktur sind: 

• Klassendiagramme 

• Komponentendiagramme 

• Verteilungsdiagramme 

• Komponentenverteilungsdiagramme 

• Interne Strukturdiagramme 

• Paketdiagramme 

Die wesentlichen Diagrammtypen der UML zur Beschreibung des Verhaltens von Software sind: 

• Aktivitätsdiagramme 

• Sequenzdiagramme 

• Kommunikationsdiagramme 

• Protokollzustandsautomatendiagramme 

• Zustandsautomatendiagramme 

• Anwendungsfalldiagramme (Use-Case Diagramme) 




Sichten 

Welche Sichten auf eine Software- 

Architektur müssen modelliert werden? 

5 

Ziel der UML ist es, durch die unterschiedlichen Diagrammtypen verschieden Sichten auf ein Softwaresystem 

zu ermöglichen. Jede Diagrammart der UML kann dabei für unterschiedliche Sichten 

auf unterschiedlichen Abstraktionsebenen eingesetzt werden. 

Um ein komplexes Softwaresystem verstehen zu können ist es wichtig, dass bestimmte Sichten auf 

die Architektur explizit modelliert werden. 

Folgende Sichten haben sich als wesentlich herausgestellt: 

• Anforderungen 

• Abbildung der Anforderungen auf das Design 

• Systemkontext 

• Systemdesign 

○ Statische Sicht: Komponenten, Klassen, Struktur, Schnittstellen 

○ Dynamische Sicht: Verhalten, Mechanismen, Objekte, Threads 

• Implementierung (Paketorganisation, Artefakte) 

• Infrastruktur und Verteilung 

• Informationsfluss und Daten 

Im Rest dieses Kapitels wird auf obige Sichten jeweils näher eingegangen. 




Anforderungen 

Bedeutung und Darstellung der Anforderungen 

15 

Auf die Anforderungssicht wird im Rahmen des Certified Professional for Software Architecture nur 

aus Gründen der Vollständigkeit eingegangen. 

Die Anforderungen werden in Form von Use Cases und natürlicher Sprache dargestellt. Anforderungen 

unterteilen sich in die drei Hauptkategorien Use Cases, ergänzende funktionale Anforderungen 

und nicht-funktionale Anforderungen. 

Die Use Cases erfassen dabei den wesentlichen Teil der funktionalen Anforderungen. Ein Use Case 

beschreibt dabei eine typische Art und Weise, wie das System von außen benutzt wird und umfasst 

somit eine Menge funktionaler Anforderungen. Für jeden Use Case existieren ein oder mehrer Szenarien. 

Die detaillierte Beschreibung der Use Case Szenarien und der ihm zugeordneten funktionalen 

Anforderungen erfolgt in natürlicher Sprache und kann durch Sequenz- oder Aktivitätsdiagramme 

unterstützt werden. Der Zusammenhang zwischen Aktoren und Use Cases wird in Use-Case- 

Diagrammen dargestellt. Besitzt das System auf Ebene der Use Cases ein zustandsbasiertes Verhalten, 

so kann dies über Zustandsautomaten dargestellt werden. Ein explizites Kontextdiagramm 

zeigt allein das System und die Aktoren, mit denen es in Verbindung steht. 

Ergänzende funktionale Anforderungen sind solche, die nicht einen spezifischen Use Case zugeordnet 

sind. Diese werden ebenso wie nicht-funktionale Anforderungen ausschließlich in natürlicher 

Sprache erfasst. 




Systemkontext 

Bedeutung und Darstellung des Systemkontexts 

5 

In dieser Sicht wird dargestellt, wie das System als Blackbox in seine Umgebung eingebettet ist. Neben 

dem System und allen externen Elementen werden auch die Kommunikationsbeziehungen und 

Schnittstellen zwischen diesen dargestellt. Für diese Sicht bietet sich das Komponentendiagramm 

an, welches die Kooperation zwischen den Komponenten hervorhebt. 




Systemdesign 

Bedeutung und Darstellung des Systemdesigns 

mit dynamischen und statischen 

Aspekten 

45 

Im Rahmen dieser Sicht wird alles dargestellt, was für das Verständnis des internen Aufbaus und der 

internen Funktionsweise des Systems wichtig ist (die sog. „Whitebox-Sicht“ auf das System). Dazu 

gehören strukturelle und dynamische Aspekte auf unterschiedlichen Hierarchieebenen des Systems. 

Statische Sichten 

Auf den oberen Hierarchieebenen wird ein System meistens aus Komponenten aufgebaut. Erst auf 

den unteren Ebenen zerfällt die interne Struktur der Komponenten in miteinander kooperierende Objekte 

verschiedener Klassen. Die Architektur von Komponenten einer bestimmten Hierarchieebene 

wird in Komponentendiagrammen dargestellt, die strukturellen Beziehungen zwischen Klassen werden 

in Klassendiagrammen notiert. Der interne Aufbau einer Komponente oder Klasse wird in einem 

internen Strukturdiagramm verdeutlicht. Wichtig ist es, die Schnittstellen detailliert zu beschreiben. 

Auch können Einschränkungen für Beziehungen zwischen Elementen oder für ganze Elemente existieren. 

Um Einschränkungen auszudrücken bietet sich die OCL an. 

Dynamische Sichten 

Auch bei der Dynamik gibt es verschiedene Hierarchieebenen. Kernpunkt des Verhaltens eines Systems 

ist, wie es bestimmte Use Case Szenarien abarbeitet. Es kann auf sehr grober Ebene gezeigt 

werden, wie die Komponenten miteinander kommunizieren, oder andererseits die detaillierte Funktionsweise 

eines Algorithmus modelliert werden. Zur Beschreibung von dynamischen Aspekten bietet 

die UML mehrere Diagrammarten, die jeweils für bestimmte Aspekte der Modellierung besonders 

geeignet sind. 

Der allgemeine Ablauf von Aktivitäten im Großen und Kleinen, wird mit Aktivitätsdiagrammen modelliert. 

Zustandsbasiertes Verhalten von Klassen oder Komponenten wird mit Zustandsdiagrammen 

notiert. Diese ermöglichen Simulation und die Generierung ausführbarer Codes. Eine spezielle Form 

sind Protokoll-Zustandsdiagramme. Zu den Interaktionsdiagrammen zählen Sequenzdiagramme, 

Kommunikationsdiagramme, Interaktionsübersichtsdiagramme und Timingdiagramme. Sequenzdiagramme 

bilden die zeitliche Abfolge des Nachrichtenaustausches zwischen Instanzen ab. Sie können 

auch sehr gut zur Darstellung von Interprozess- oder Intertask-Kommunikation genutzt werden. 

Kommunikationsdiagramme stellen ebenfalls den Nachrichtenaustausch zwischen Instanzen dar. 

Sie fokussieren auf die strukturellen Zusammenhänge zwischen den Instanzen. Interaktionsübersichtsdiagramme 

fassen mehrere Sequenzdiagramme in Form eines Kontrollflusses zusammen. 

Damit können komplexe Abläufe übersichtlich dargestellt werden. Timing-Diagramme sind eine Form 

von Interaktionsdiagrammen, um das Auftreten von Nachrichten im Zusammenhang mit den Zustand 

einer Instanz und der genauen Zeit darzustellen. 

Kooperationen 

Typischerweise arbeiten mehrere Entitäten des Systems zusammen, um ein bestimmtes Verhalten 

zu realisieren. Um eine solche Kooperation zu beschreiben, muss die Struktur zwischen den beteiligten 

Entitäten sowie die Kommunikationsmuster beschrieben werden. Dazu verwendet man interne 

Strukturdiagramme und Interaktionsdiagramme. Die Diagramme werden dann in einer „Collaboration“ 

zusammengefasst. Collaborations werden auch für die allgemeine Beschreibung von Design 

Patterns verwendet. 




Implementierung 

Bedeutung und Darstellung der Implementierungsaspekte 

10 

Die Implementierungssicht beschreibt die Gruppierung der Designelemente wie Klassen und Komponenten 

in Pakete sowie deren Implementierung durch Artefakte. Die Aufteilung der Elemente in 

Pakete erfolgt dabei zum einen auf Basis der Abhängigkeiten zwischen den Elementen und zum anderen 

aus Sicht von organisatorischen Aspekten. Zur Darstellung der Gruppierung von Elementen in 

Pakete sowie deren Abhängigkeiten werden UML Paketdiagramme verwendet. Artefakte werden mit 

einer Abhängigkeit zu den Designelementen versehen, welche sie repräsentieren 

Die Festlegungen dieser Sicht bestimmt auch, in welchen Einheiten die Bestandteile des Systems in 

einem Konfigurationsmanagementwerkzeug abgelegt werden. 




Infrastruktur und Verteilung 

Bedeutung und Darstellung der Systeminfrastruktur 

und der Verteilung der Artefakte 

auf die Infrastruktur 

10 

Bei verteilten Systemen ist die explizite Darstellung der Infrastruktur von Bedeutung. Aufbauend auf 

der Infrastrukturdarstellung wird notiert, wie die Artefakte des Systems auf die Bestandteile der Infrastruktur 

verteilt werden. Zudem können die Abhängigkeiten zwischen den Artefakten eingezeichnet 

werden. Infrastruktur und Verteilung werden mit Verteilungsdiagrammen abgebildet. Die Infrastruktur 

besteht aus Knoten, die über Kommunikationspfade verbunden sind. Ausführungsumgebungen sind 

spezielle Knoten, die eine Umgebung bereitstellen, um einen bestimmten Typ von Komponenten 

auszuführen. 

Komponentenverteilungsdiagramme sind eine erweiterte Form von Verteilungsdiagrammen. Diese 

beinhalten zusätzlich Spezifikationen, welche die Ausführungsparameter der Komponentenartefakte 

angeben. 




Informationsfluss und Daten 

Bedeutung und Darstellung von Informationsflüssen 

und Daten 

10 

In stark datengetriebenen Systemen sind Datenstrukturen sowie Informationsflüsse explizit zu beschreiben. 

In der Systemkontextsicht können dabei die Informationsflüsse zwischen dem System 

und seiner Umgebung eingezeichnet werden. In den Diagrammen der Designsicht können systeminterne 

Informationsflüsse abgebildet werden. Die UML bietet für Informationen und Informationsflüsse 

ein explizites Konstrukt an. Die Datenstrukturen werden in Form von UML-Datentypen beschrieben. 

Der Zusammenhang zwischen Informationen und Daten kann über Repräsentationsbeziehungen 

hergestellt werden. 




Architekturkonzepte 260 

Die Themen einer Architekturdefinition sind vielfältig. Sie reichen von der Auswahl des 

Architekturstils über die Betrachtung der einzelnen Merkmale einer Architektur bis hin 

zur Einbettung der Architektur in die Rahmenbedingungen eines Projekts, Unternehmens 

oder Teams. Dieses Kapitel behandelt die skizzierten Themen im Detail und gibt 

Hilfen bei der Entscheidungsfindung zum Erstellen von Software-Architektur. 

Motivation 

Rahmenbedingungen und Entscheidungsfindung 

15 

Die zu entwerfende Architektur ist im Kontext ihrer Rahmenbedingungen zu betrachten: Welche Erfahrungen 

liegen im Unternehmen, dem Team oder einem vergleichbaren Projekt vor? Können/sollen 

die dort erarbeiteten Ergebnisse konzeptuell oder auf Basis fertiger Softwarekomponenten 

wiederverwendet werden? Wird die Architektur für ein oder mehrere Projekte entworfen? 

Wie ein roter Faden zieht sich eine Rahmenbedingung durch den gesamten Entwurf einer Architektur: 

Das Treffen von Entscheidungen. Im Rahmen einer Architekturspezifikation steht der Professional 

for Software Architecture wiederholt vor der Frage, welche Anforderungen vorrangig vor anderen 

zu behandeln sind und wie Widersprüche zwischen mehreren Anforderungen aufgelöst werden. Das 

Vermögen solche Entscheidungen vorzubereiten, forcieren und treffen zu können, zählt zu einer der 

wesentlichen Fähigkeiten eines Professional for Software Architecture. 




Auswahl an Stilen 

Was ist bei der Erstellung einer Architektur 

zu beachten? 

Wie kann vorgegangen werden? 

45 

Fachliche und technische Rahmenbedingungen sowie das politische und organisatorische Projektumfeld 

prägen den Architekturstil. 

Welche Art von Anwendung soll entworfen werden? Ein hostbasiertes System, eine Client-Server- 

Anwendung, ein Embedded-System, eine plattformübergreifende Anwendung? 

Welche Rolle spielt die Wiederverwendung des Ergebnisses? Können vorhandene Ergebnisse wiederverwendet 

werden? 

Die Summe der Antworten auf diese Fragen führt dazu, 

• eine Teamaufteilung zu finden 

• die Anwendungen in Schichten (Layering) zu entwerfen 

• bestehende Komponenten/Systeme zwecks Wiederverwendung zu kapseln 

• das System auf mehrere logische/physische Plattformen, z. B. als Client/Server-Systeme zu verteilen 

• eine Fat-, Thin- oder Ultra-Thin-Client-Architektur zu wählen 

• die Entwicklungsergebnisse von Hand zu erstellen oder teilweise bzw. vollständig zu generieren 

Eine Grundlage dieser Entscheidungen bilden bereits erprobte Designmuster und Architekturstile. 

Deren Beschreibung folgt einer klaren Definition. Schichtenbildung auf Basis von Themengebieten 

ermöglicht auch bei großen Systemen, Komplexität zu beherrschen. Sowohl innerhalb der Themen 

als auch an deren Schnittstellen untereinander werden Designmuster und Architekturstile eingesetzt. 

Als Komponente wird typischerweise eine in sich schlüssige entweder allein ablauffähige oder durch 

andere Softwareeinheiten verwendbare Softwareeinheit bezeichnet. Komponentenbildung ermöglicht 

im Idealfall das „Zusammenstecken“ von Anwendungen, wobei Einzelteile bedarfsgerecht ausgetauscht 

werden können. 

Kapselung ermöglicht das Verstecken von Details und macht ebenfalls Komplexität beherrschbar. 

Die Prinzipien der Objektorientierung fördern dieses Vorgehen. 

Aufgrund verschiedener Anforderungen ist es erforderlich, Systeme zu verteilen. Dies kann im einfachsten 

Falle nur logisch erfolgen und dient wiederum der Komplexitätsbeherrschung. Typischerweise 

wird eine Verteilung auch physisch vollzogen. Logische und physische Verteilung müssen 

nicht identisch sein. 

Fat-Client bezeichnet eine Architektur, in der der Rechner des Anwenders die Hauptlast trägt. Beim 

Thin-Client sind diese Aufgaben auf einen oder mehrere leistungsstarke Server verteilt. Ultra-Thin- 

Clients geben auch noch einen Teil der Präsentationslogik an den Server ab. 

Mittels Generierungstechniken ist es möglich, viele sich wiederholende oder systematische Implementierungen 

automatisch zu erstellen. Konzepte wie Model Driven Architecture führen derzeit zu 

einem konsolidierten Vorgehen in diesem Bereich. 




Themenbereiche 

Welche Themen muss/soll eine Software- 

Architektur adressieren? 

75 

Nach Festlegung der Rahmenentscheidungen für die Architektur, folgt die Detailbetrachtung der Einzelthemen. 

Achtung: Auch wenn diese Aussage ein „Wasserfall-Vorgehen“ assoziiert, so ist das 

Vorgehen iterativ. Abstraktionsniveaus werden regelmäßig während der Architekturerstellung gewechselt, 

gröbere Themenbereiche verfeinert, Details abstrahiert, Teillösungen realisiert. 

Aktuelle Anwendungssysteme müssen eine Vielzahl der folgenden Themenbereiche berücksichtigen. 

Es ist immer die Entscheidung zu treffen, „Kann bzw. will ich diese Funktionalität einkaufen o- 

der ist diese selbständig zu entwerfen?“. Auch bei gekauften Funktionalitäten sind Architektur- 

Entscheidungen zu treffen. 

Die häufigsten zu adressierenden Themen sind: 

• Benutzeroberfläche 

• Datenhaltung 

• Infrastruktur, Verteilung/Netzwerk 

• Zugriffssicherheit/Security 

• Transaktionen 

• Rahmenbedingungen durch Betriebssystem, Hardware, Implementierungssprache (Impedance 

Mismatch) 

• Workflow 

• Fehlerbehandlung 

• Berücksichtigung vorhandener Lösungen und Bibliotheken 

In allen Bereichen haben sich eine Vielzahl von Lösungsmustern (Patterns) etabliert und bewährt. 

Neben diesen Themen sind allgemeine Festlegungen zu treffen wie: 

• In welcher Form erhält ein Entwickler Vorgaben? Papier oder Generator? 

• Sollen regelmäßige Reviews stattfinden, die sicherstellen, dass Architekturvorgaben eingehalten 

wurden? 

• Wie fließen neue Ideen ein? Wann? Wie oft? 

Die Testbarkeit der Architektur ist frühzeitig zu berücksichtigen. Im Idealfall kann der Test automatisiert 

werden. Abstimmung mit dem Testteam ist notwendig. 

Welche Entscheidung in dem jeweiligen Bereich getroffen wird, hängt insbesondere mit dem Zusammenspiel 

der anderen Bereiche zusammen. 




Klassifizierung und Typisierung 

Dimensionen und Typen 65 

Dimensionen von Softwaresystemen 

Softwaresysteme lassen sich entlang verschiedener, orthogonaler Dimensionen klassifizieren. Dazu 

gehören einerseits die logischen Dimensionen Funktionalität und Kontrolle und andererseits die physischen 

Dimensionen Verteilung und Mobilität. Eine derartige Klassifizierung des Systems hat natürlich 

direkten Einfluß auf die Software-Architektur. 

Die logischen Dimensionen Funktionalität und Kontrolle sind orthogonal zueinander, d. h. zur Beherrschung 

der Komplexität ist es naheliegend, beide im Rahmen der Software-Architektur explizit 

zu trennen. Unter Kontrolle werden alle Systemeigenschaften verstanden, die nicht direkt aus fachlichen 

Anforderungen resultieren. In objektorientierten Programmiersprachen läßt sich die Kontrolldimension 

über Exceptions abbilden. In UML 2.0 gibt es das allgemeinere Konzept der getypten Ports. 

Verteilung und Mobilität sind weitere orthogonale Dimensionen. Mobilität bezeichnet die dynamische, 

physische Verlagerung von Komponenten zur Laufzeit. Eine Methode zur Implementierung der Mobilität 

ist die Persistenz. 

Die beschriebenen Dimensionen können sowohl auf die gesamte Software-Architektur als auch auf 

einzelne Subsysteme bezogen werden. Dabei kann die Klassifizierung entlang der Dimensionen auf 

verschiedenen Hierarchie- oder Abstraktionsebenen verschieden ausfallen. 

Die Dimensionen sowie dazu querschnittliche Probleme wie Konfigurierbarkeit und Dynamik haben 

entsprechende Auswirkungen auf die Software-Architektur. 

Typen von Softwaresystemen 

Softwaresysteme lassen sich zudem nach folgenden grundsätzlichen Typen klassifizieren: 

• Bei datenorientierten Systemen steht die Bearbeitung von größeren und/oder komplex strukturierten 

Datenmengen im Zentrum. 

• Bei ereignisorientierten Systemen steht die Reaktion des Systems auf Ereignisse und/oder die 

Kommunikation von Systemteilen über Ereignisse im Mittelpunkt. 

Die obigen Aspekte treten häufig gemischt bzw. gleichzeitig auf. Die Software-Architektur muss die 

vorkommenden Typen geeignet unterstützen. Der Typ des Systems hat auch Einfluss auf die Auswahl 

der Technologen und Werkzeuge. 




Bewertung 

Wie wäge ich meine Architekturentscheidungen 

ab? 

60 

Eine Architektur zu definieren ist, das Finden des „besseren Übels“. Ähnlich wie bei der Erstellung 

eines fachlichen Modells gibt es Widersprüche zwischen Anforderungen. Wo sich in diesem Falle 

Anwender (Stakeholder) noch relativ einfach einigen können, da sie sich in ihrer Domäne befinden 

und damit eine Entscheidung gut abwägen können, ist diese Kompromissfindung im Rahmen der 

Architekturerstellung sehr viel schwieriger. Die Lösung einer Anforderung kann der anderen zunächst 

widersprechen. Ein geeigneter Kompromiss ist zu finden. 

Hier werden die noch offenen Fragen „Wie wäge ich meine Architekturentscheidungen ab? Welche 

Kriterien gibt es? Wie viel Zeit sollte ich wann verwenden? Wann ist eine Architektur gut, wann richtig?“ 

geklärt. 

Die Priorisierung von Anforderungen hilft das Wichtige vom weniger Wichtigen zu trennen. Nicht das 

Thema, das für den Professional for Software Architecture spannend ist, ist das wichtigste, sondern 

das, das dem Anwender am meisten bei seiner Lösung hilft und wofür er zu zahlen bereit ist. 

Die meisten Entscheidungen können nicht auf dem Papier getroffen werden. Das Vorgehen des 

„Durchstichs“ (Proof of concept) hat sich bewährt. Die entscheidende Frage, „was muss gehen, damit 

die Architektur funktioniert?“ wird geklärt. Mit (verhältnismäßig) wenig Aufwand wird eine hohe 

Sicherheit für die weitere Arbeit erzielt. 

Der Professional for Software Architecture fordert die Stakeholder auf, die Vielzahl von Anforderungen 

zu priorisieren. Am Ende einer Iteration steht ein lauffähiges System oder zumindest ein Durchstich 

mit diesen Funktionen. 

Beim Abwägen mehrerer Lösungen klärt der Professional for Software Architecture die Fragen: 

• Kann damit die Anforderung erfüllt werden? 

• In welchem Maße? 

• Zeichnet sich eine Lösung besonders aus? 

• Wie zukunftssicher ist die Lösung? 

• Welche Folgen hat die Lösung? 

• Sind für die Stakeholder die Folgen nützlich/unwichtig/unakzeptabel? 




Prozesse 70 

In diesem Kapitel wird die Rolle von Software-Architektur in unterschiedlichen Softwareentwicklungsprozessen 

genauer betrachtet. 

Überblick 

Prozesse und die Einordnung von Architektur; 

Spezielle Prozesse: RUP, V-Modell, 

XP 

5 

In der Softwareentwicklung gibt es keinen allgemeingültigen Prozess, der in allen Bereichen Anwendung 

findet. Vielmehr gibt es eine Menge unterschiedlicher Prozesse, die von verschiedenen Gruppierungen 

entworfen sind. Zu den Gruppierungen gehören öffentliche Einrichtungen, Unternehmen, 

aber auch unabhängige Strömungen in der Softwaregemeinde, die von einzelnen Personen getrieben 

werden. Die Prozesse verfolgen teilweise völlig unterschiedliche Ideologien. 

Bekannte Prozesse sind das V-Modell, der RUP sowie agile Prozesse mit XP als bekanntesten Vertreter. 

In allen Prozessen spielt die Software-Architektur eine Rolle, die je nach Prozess jedoch deutlich unterschiedlich 

ausfallen kann. 




Rational Unified Process Architektur im RUP 20 

Ziel des RUP ist es, ein sehr mächtiges Prozess-Framework zur Verfügung zu stellen, das nach Bedarf 

angepasst werden kann. Der RUP beschreibt eine Vielzahl von Rollen, Aktivitäten und Dokumente, 

die für die verschiedenen Bereiche des Entwicklungsprozesses sinnvoll sind. Zudem werden 

„Best Practices“ für den Einsatz dieser Elemente beschrieben. Software-Architektur und damit der 

Professional for Software Architecture nimmt eine zentrale Rolle innerhalb des RUP ein. 

Profil eines Professional for Software Architecture n: 

“The ideal architect should be a person of letters, a mathematician, familiar with historical 

studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, 

learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.” 

— Vitruvius, circa 25 BC 

Der RUP definiert konkrete Eigenschaften und Aufgaben eines Professional for Software Architecture. 

Er legt fest in welchen Disziplinen der Softwareentwicklung der Professional for Software Architecture 

beteiligt ist und für welche Aktivitäten und Artefakte er verantwortlich ist. 

Ein Professional for Software Architecture ist die treibende Kraft bei der Systemerstellung. Die wesentliche 

Aufgabe des Professional for Software Architecture ist es, eine Folge von suboptimalen 

Entscheidungen bei unvollständigem Wissen zu treffen. Architekturverantwortung ist eine Vollzeitbeschäftigung. 

Deshalb sollte es eine Person geben, die die Rolle des Professional for Software Architecture 

ausfüllt. 




V-Modell Architektur im V-Modell 15 

Das V-Modell ist neben dem militärischen auch für den gesamten Bereich der Bundesverwaltung 

verbindlich und wird von vielen Industriefirmen als Hausstandard für Softwareentwicklung verwendet. 

Das V-Modell regelt die Softwarebearbeitung im Bereich der Bundeswehr durch die einheitliche und 

verbindliche Vorgabe von Aktivitäten und Produkten(Ergebnissen), die bei der Softwareerstellung 

und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und 

technisches Projektmanagement (PM) anfallen. 

Software-Architektur ist auch im V-Modell ein zentrales Element. Es gibt aber keinen ausgesprochenen 

Professional for Software Architecture. Die Rolle ist auf andere Rollen verteilt, welche noch zusätzliche 

Aufgaben erfüllen. Rollen im V-Modell, die sich mit Software-Architektur befassen, sind der 

Systemdesigner sowie der Softwareentwickler. 

Es existiert ein Architekturdokument für das Gesamtsystem und eine Software-Architektur pro Softwareeinheit. 

Das V-Modell behandelt Systeme und somit neben Software auch Hardware. 




Agile Prozesse – XP Architektur in XP 15 

Ziel von agilen Prozessen ist die Fokussierung auf die wesentlichen, notwendigen Aktivitäten für ein 

konkretes Projekt. Dabei sollen übermäßig formale Aktivitäten vermieden werden. Agil bedeutet hier, 

dass ein Prozess stets an das konkrete Projektumfeld und an die aktuellen Gegebenheiten angepasst 

wird. eXtreme Programming (XP) ist der bekannteste Vertreter agiler Prozesse. 

XP basiert im Wesentlichen auf dem Gedanken die Software so einfach wie möglich zu halten und 

auf damit flexible auf weitere bzw. neue Anforderungen zu reagieren. Dabei wird auf herkömmliche 

Aktivitäten wie Analyse und Design nicht verzichtet, jedoch werden sie auf ein Minimum reduziert. 

Architektur wird bei XP nicht explizit hervorgehoben, ist aber auch hier von zentraler Bedeutung. XP 

basiert auf einem iterativen Ansatz. Bei der ersten Iteration werden eine Reihe von einfachen „basic 

stories“ umgesetzt und die dafür notwendigen Elemente formen die Architektur (auch wenn sie nicht 

explizit als solche bezeichnet wird). In den weiteren Iterationen werden weitere „stories“ dazu genommen 

und damit die Architektur überarbeitet. Ziel für die Umsetzung neuer „stories“ ist stets: „the 

simplest solution that will work“ (Kent Beck). 




Gegenüberstellung 

Software-Architektur in Softwareprozessen 

– Vergleich und Gegenüberstellung 

15 

Das Architekturthema hat in allen betrachteten Prozessen eine wichtige Rolle. Die Prozesse können 

anhand einiger Kriterien, die für das Thema der Software-Architektur relevant sind, gegenübergestellt 

werden. Die gewählten Kriterien sind: 

• Machbarkeitsstudie & Risikoanalyse 

• Priorisierung der Anforderungen & Iterationsplanung 

• Grobkonzept der Architektur 

• Unterstützung Testrahmen & Testplanung 

• Konkretisierung der Iterationsplanung 

• Änderungsmanagement 

• Statusbericht für die Projektleitung erstellen 

• Rollen/Artefakte 

• Zielgruppe 

RUP und V-Modell gelten allgemein eher als schwergewichtige Prozesse. Beide können aber „tailored“ 

werden, um den Ansprüchen an schlankere Entwicklungsprozesse gerecht zu werden. Die Fokussierung 

auf einen iterativen Prozesse und die explizite Rolle eines Professional for Software Architecture 

lassen den RUP im Vergleich zum V-Modell als geeigneter für aktuelle, komplexe Softwareentwicklungen 

erscheinen. XP ist im Gegensatz ein leichtgewichtiger Prozess, der wie der RUP 

auf einem iterativen Ansatz beruht. Architektur wird nicht explizit durch eine bestimmte Rolle in den 

Mittelpunkt gestellt durch eine bestimmte Rolle definiert, sondern ist Aufgabe verschiedener Rollen 

im XP-Prozess. Trotzdem spielt eine gute Architektur (wenn auch anders bezeichnet) eine wichtige 

Rolle. Um XP einzusetzen sind einige Voraussetzungen (kleine Teams, Vertrauen, Kommunikationsfähigkeit) 

unabdingbar. Wenn diese Voraussetzungen erfüllt sind, dann kann ein weniger formaler 

Prozess sehr effizient sein. 




Technologien und Werkzeuge 200 

In diesem Kapitel werden existierende Technologien und Werkzeuge klassifiziert und 

an Beispielen demonstriert. Darüber hinaus werden dem Professional for Software 

Architecture Anhaltspunkte zur Auswahl von geeigneten Technologien und Werkzeuge 

an die Hand gegeben. 

Technologien Übersicht existierender Technologien 15 

Ein wesentlicher technischer Aspekt der Entwicklung und gleichzeitig Handwerkszeug der Entwickler 

sind die einzusetzenden Technologien und Werkzeuge. Der Professional for Software Architecture 

muss während der Erarbeitung der Software-Architektur Entscheidungen treffen, um geeignete 

Technologien bzw. Werkzeuge auszuwählen und ungeeignete auszuschließen. 

Mit welchen Technologien können Software-Architekturen heute gestaltet werden? 

• Betriebssysteme 

• Programmiersprachen 

• Codegenerierung 

• Third-party Software (Frameworks, Bibliotheken und Komponenten) 

• Komponentenmodelle (CORBA, COM, DCOM, J2EE) 

• Application Server 




Betriebssysteme Aufgaben, Klassifizierung und Beispiel 15 

Die zentrale Aufgabe eines Betriebssystems ist die Verwaltung und Steuerung eines Computers und 

seiner Ressourcen. Daraus leiten sich die Bereiche Datenverwaltung, Ein-/Ausgabesteuerung, Ablaufsteuerung 

und Gewährleistung von Sicherheit und Zugriffsschutz ab. 

Betriebssysteme lassen sich entlang folgender Dimensionen klassifizieren: 

• Anzahl der Prozessoren 

• Anzahl der Nutzer 

• Verteilung 

• Art der Zielhardware 

• Unterstützung spezieller Anforderungen 

Als Entscheidungsgrundlage für den Professional for Software Architecture ist es speziell interessant, 

dass die Wahl des Betriebssystems gleichzeitig die Auswahl der darüber hinaus verwendbaren 

Technologien und Werkzeuge einschränkt. Lediglich mit portablen Sprachen, Tools oder Technologien 

läßt sich diese Einschränkung teilweise aufheben. 




Programmiersprachen 

Prozedurale, objektorientierte und weitere 

Programmiersprachen 

20 

Bei keiner Technologie werden wohl so erbitterte Auseinandersetzungen und „Glaubenskriege“ geführt 

wie bei den Programmiersprachen, die zur Umsetzung einer Entwicklungsaufgabe ausgewählt 

werden. Dabei gibt es sowohl Faktoren, die zu einem solchen Streit beitragen, aber auch immer 

mehr Faktoren, welche die Bedeutsamkeit von Einzelentscheidungen relativieren. 

Die Auswahl einer Programmiersprache sollte somit möglichst pragmatisch und technologieorientiert 

erfolgen. Ein guter Anhaltspunkt ist der Best-practice-Ansatz: Mit welcher Programmiersprache wurde 

in vergleichbaren Projekten gearbeitet? Für welche Programmiersprachen sind im Unternehmen 

bereits Erfahrungen vorhanden? Was wünscht der Kunde? 

Die wesentlichen Klassen von Programmiersprachen sind prozedurale Programmiersprachen, objektorientierte 

Programmiersprachen, Datenbank-Sprachen und Markup-Sprachen. Zudem gibt es 

noch weitere Klassen, wie funktionale, logische, Spezifikations- oder deklarative Sprachen. Diese 

werden in eng begrenzten, besonderen Anwendungsnichen eingesetzt. Jede Klasse von Sprachen 

hat ihre typischen Eigenschaften. 

Die Auswahl der Programmiersprache beeinflußt nicht zwingend den methodischen Ansatz für den 

Entwurf der Software. So kann z. B. beim Einsatz von C die Software trotzdem objektorientiert mit 

UML entworfen werden. 




Codegenerierung Automatische Codegenerierung 20 

Generierung ermöglicht die automatische Wiederholung einer Entwicklungsleistung. Die positiven 

Folgen sind eine beträchtliche Aufwandsreduzierung, eine gleichbleibende Qualität und eine leichte 

Erweiterbarkeit bzw. Wartbarkeit. Demgegenüber steht der zusätzliche Aufwand, einen geeigneten 

Generator zu entwerfen, wozu eine nicht unerhebliche Abstraktionsfähigkeit des Professional for 

Software Architecture Voraussetzung ist. Gute Generatoren können bis zu 100% des Zielcodes erzeugen. 

Die verbleibenden Codeteile werden vom Entwickler manuell ergänzt. 

Abhängig vom eingesetzten Generator ist die Grundlage der Generierung eine strukturierte Information, 

die anhand der Regeln des Generators interpretiert wird und zur gewünschten Transformation 

führt. Die heute am weitesten verbreitete „strukturierte Information“ ist ein UML-Modell. Da hier das 

Modell führt, wird auch häufig von einem modellbasierten Vorgehen oder auch vom Visual Modeling 

gesprochen. 

Wichtige Eigenschaften eines Codegenerators sind dessen Fähigkeiten zu Round-Trip und Reverse 

Engineering. 

Model Driven Architecture (MDA) ist ein neuer Standard der OMG, der das modellbasierte Entwikkeln 

vorantreiben soll. 




Third-Party-Software 

Frameworks, Bibliotheken und Komponenten 

30 

Für rein prozedurale Sprachen haben sich in der Vergangenheit Software-Bibliotheken als Technologie 

bewährt, um die Wiederverwendung von Softwareprodukten Dritter in eigenen Projekten zu 

ermöglichen. Das Konzept der Bibliotheken wird zudem in großen Softwareprojekten als Strukturierungsmittel 

und als Mittel zur unternehmensweiten Wiederverwendung eingesetzt. 

In den Bereichen der objektorientierten und komponentenbasierten Programmierung kann dieses 

Prinzip in wesentlich mächtigerer und vielfältiger Form angewandt werden. Grundsätzlich lassen sich 

hier drei Arten der Wiederverwendung unterscheiden: Komponentenbibliotheken, Klassenbibliotheken 

und Frameworks. 

Komponentenbibliotheken enthalten Sammlungen von Software-Komponenten zur direkten Verwendung 

in eigenen Projekten. Komponenten sind Standard-Software-Bausteine, die jeweils für sich abgeschlossen 

sind und genau definierte externe Schnittstellen haben. Für den Einsatz der Komponenten 

muss es eine übergeordnete Schnittstellenspezifikation geben. Diese wird unter dem Begriff 

„Standard-Plattform“ geführt. 

Klassenbibliotheken enthalten eine oder mehrere Hierarchien von objektorientierten Klassen und 

sind daher an eine bestimmte Programmiersprache gebunden. Die Klassen können in eigenen Projekten 

direkt verwendet werden oder als Basis für weitere Ableitung dienen. 

Frameworks ermöglichen die Wiederverwendung für spezifische Anwendungsfelder. Die Stärke von 

Frameworks ist, dass nicht nur Software auf der Ebene der Implementierung wiederverwendet werden 

kann, sondern auch auf der Ebene von Design und Software-Architektur (design reuse). 

Frameworks gehorchen dem Hollywood-Prinzip: Don’t call us, we call you! 

Hausinterne Frameworks und Bibliotheken 

Gerade in großen Unternehmen, aber auch in mittleren Entwicklungsabteilungen muss in die Technologieauswahl 

auch die bereits existierende Software einbezogen werden. Als Mechanismen zur 

Wiederverwendung bieten sich hier ebenfalls obige Methoden an: Frameworks, Klassenbibliotheken 

und Komponenten sind mächtige Mechanismen zur Steigerung von Produktivität und Qualität innerhalb 

von Entwicklungsabteilungen und Unternehmen. Natürlich entsteht durch das Aufsetzen dieser 

Mechanismen zunächst zusätzlicher Aufwand, der erst durch mehrfache Verwendung in späteren 

Projekten wieder kompensiert wird. 




Übergreifende Technologien 

Verteilte Komponenten, Standardplattformen, 

Application Server, … 

25 

Seit Anfang der neunziger Jahre und bis heute entwickeln sich übergreifende Technologien, welche 

die obigen Technologien umfassend kombinieren und dadurch neue Ansätze zur Lösung von Softwareaufgaben 

schaffen. Der Professional for Software Architecture muss sich mit diesen übergreifenden 

Technologien auseinandersetzen, da diese teilweise fertige Architekturen für bestimmte Problemklassen 

bereitstellen. 

Verteilte Komponenten 

War COM noch ein rein lokales Komponentenmodell, das die Wiederverwendung von Softwareprodukten 

auf Basis einer binären Standardplattform ermöglichen sollte, ist mit der Weiterentwicklung 

DCOM der Schritt zum verteilten System vollzogen worden. Die Anwendung von COM/DCOM ist im 

Wesentlichen auf Windows-Plattformen beschränkt. Eine Alternative zum verteilten Komponentenmodell 

DCOM ist die plattformunabhängige CORBA-Architektur. 

Mit der Etablierung des Internets in der zweiten Hälfte der neunziger Jahre konnte sich das Kommunikationsprotokoll 

HTTP zwischen Browser und Webserver so etablieren, dass es als eine viel allgemeinere 

Kommunikationsplattform als bei COM und CORBA verwendet werden kann. Eingebettet 

in HTTP haben sich bis heute eine Vielzahl von Protokollen und Schnittstellenspezifikationen entwikkelt, 

die zur Kommunikation zwischen verteilten Komponenten benutzt werden. 

Standard-Plattformen 

Durch die technische Möglichkeit und fachliche Notwendigkeit, im Rahmen des Internets bzw. Intranets 

Applikationslogik auf Browser und Webserver zu verteilen, müssen geeignete Technologien 

vielfältigen Aufgaben lösen. Im Wesentlichen sind zwei Technologie-Plattformen für diese Aufgaben 

verfügbar: 

J2EE (Java 2 Enterprise Edition). Hierbei handelt es sich um eine Sammlung von Spezifikationen, 

auf deren Grundlage Softwareprodukte entwickelt werden können. Der Schwerpunkt liegt dabei 

auf Internetapplikationen. J2EE-kompatible Application Server bilden das Rückgrat der Technologie. 

Komponenten kommunizieren über eine Vielzahl von Protokollen und Schnittstellenspezifikationen, 

z. B. HTML, XML, TCP/IP, HTTP, SSL, RMI etc. Speziell ist zu betonen, dass J2EE 

eine zwar von Sun Microsystems vorgeschlagene, aber dennoch herstellerunabhängige Spezifikation 

darstellt. 

Microsoft .NET. Dies ist eine Plattform für die Entwicklung und Ausführung von verteilten Anwendungen. 

Wie bei J2EE liegt der Schwerpunkt auf Internetapplikationen. Im Zentrum von .NET 

steht das .NET Framework. Dieses wird unterstützt bzw. ergänzt vom Betriebssystem (zunächst 

nur die Windows-Varianten für Desktop, Server, mobile Plattformen), vom .NET Enterprise Server, 

von den .NET Building Block Services und schließlich von Visual Studio .NET, einer integrierten 

Entwicklungsumgebung. Alle erwähnten Bestandteile werden zunächst in Form von 

Microsoft-Produkten angeboten. 




Technologie-Auswahl 

Wie finde ich die richtige Technologie für 

mein Projekt bzw. Unternehmen? 

25 

Die wichtigste Aufgabe des Professional for Software Architecture ist es, in Zusammenarbeit mit 

dem Analyse-Team einen konsistenten Satz von Anforderungen herauszuarbeiten und daraus 

schließlich eine tragfähige Software-Architektur abzuleiten. Die zu erstellende Software-Architektur 

besteht zwar zu einem großen Teil auf Konzepten und Modellen, muss jedoch immer auf einer Auswahl 

von existierenden Technologien basieren. Diese Auswahl muss der Professional for Software 

Architecture aufgrund seiner Erfahrung treffen. Dazu gehört sowohl die Vertrautheit mit grundlegenden 

Technologien als auch die Fähigkeit, sich neue Technologien zu erschließen. 

Faktoren, welche die Auswahlentscheidung beeinflussen sind technische Anforderungen, Produktund 

Systemfaktoren sowie organisatorische und politische Faktoren. Die übliche Konzentration auf 

technische Faktoren reicht bei weitem nicht aus. 

Als Anhaltspunkt empfiehlt es sich, vor der Festlegung auf bestimmte Technologien die folgenden 

Fragen zu beantworten und die Antworten samt daraus resultierenden Entscheidungen in Form eines 

Dokuments festzuhalten. 

1. Welche Technologien sind dem Entwicklerteam bereits bekannt bzw. haben sich im praktischen 

Einsatz in der Vergangenheit bewährt? 

2. Welche Technologien werden bei ähnlichen Projekten von anderen Unternehmen bzw. für andere 

Kunden üblicherweise eingesetzt? 

3. Gibt es Widersprüche zwischen bestimmten Technologien und den Anforderungen? 

4. Welche Technologien können neu eingeführt werden, um die Tragfähigkeit der Software- 

Architektur für das aktuelle Projekt, aber auch für zukünftige Projekte zu verbessern? 

Die Maxime: „Generalisieren statt wiederholen“ spielt auch bei der Technologieauswahl eine entscheidende 

Rolle. Die Aufgabe der Identifikation von Synergieeffekten zwischen Projekten kann der 

Professional for Software Architecture von seinem übergeordneten Standpunkt aus am besten erfüllen. 




Werkzeuge 

Entwicklungsumgebungen, Frameworks, 

Codegeneratoren, etc. 

40 

Der Einsatz geeigneter Werkzeuge ist eng mit der Auswahl von Technologien verknüpft. Kategorien 

von Entwicklungswerkzeugen sind: 

• Entwicklungsumgebungen 

• CASE-Tools und Codegeneratoren 

• Frameworks 

• Application Server 

• Statische und dynamische Analysetools 

• Simulatoren/Emulatoren 

• Versionsverwaltung/Konfigurationsmanagement 

• Testwerkzeuge 

• Installationstools 

• Sonstiges (Datei/Verzeichnisvergleich, Automatisierung über Skriptsprachen, etc.) 

Entwicklungsumgebungen (IDE) sind Tools, welche typische Tätigkeiten der Software-Entwicklung 

wie Design, Implementierung sowie Fehlersuche und -behebung unterstützen. 

CASE-Tools (Computer Aided Software Engineering) ermöglichen die graphische Modellierung von 

Software-Systemen. Ein Codegenerator kann nachgeschaltet werden. 

Frameworks wurden bereits im entsprechenden Abschnitt unter „Technologien“ ausführlich beschrieben. 

Da diese entweder durch Werkzeuge unterstützt werden bzw. selbst als Entwicklungswerkzeuge 

bezeichnet werden können, wird das Thema hier nochmals aufgegriffen. 

Application Server kommen im Rahmen der Standard-Plattformen J2EE und .NET zum Einsatz. Für 

.NET bietet Microsoft den .NET Enterprise Server an. Für J2EE gibt es mehrere Produkte, deren 

Funktionalität durch die J2EE-Spezifikation definiert ist. 

Testen ist ein prinzipiell unvollständiger Weg, um Fehler in Software auszuschließen. Wirksamer ist 

die formale Analyse des Sourcecodes (statische Analyse) oder die Analyse während des Programmlaufs 

(dynamische Analyse). Es gibt eine Vielzahl von Analysetools, die sich hinsichtlich ihres Anwendungsgebiets 

(statisch/dynamisch) und hinsichtlich der nötigen Ausbildung des Anwenders unterscheiden. 

Simulatoren ermöglichen die Ausführung von Software auf der Entwicklungsplattform, im Gegensatz 

zur späteren Ausführung der Software auf der Zielplattform. Emulatoren gehen einen Schritt weiter 

und ermöglichen die Ausführung der Software unter Einhaltung sämtlicher relevanter Randbedingungen. 

Software-Konfigurationsmanagement ist die Disziplin der Verfolgung und Steuerung der Evolution 

von Software. Eine wichtige Aufgabe des CM ist die Versionsverwaltung. Weiterhin wird von CM- 

Tools die Änderungsverfolgung, Komposition von Applikationen, Dokumentenverwaltung und nicht 

zuletzt Prozessunterstützung erwartet. Zusätzliche Bereiche sind Software-Metrik-Tools und Bug- 

Tracking-Systeme. 

Installationstools erlauben die Erstellung von Installationsversionen von Software-Releases. Neben 

einfachen Archivierungs- und Kompressionsfunktionen werden z. B. die dialogbasierte Interaktion 

mit dem Benutzer oder die Aufbereitung von Releases für Internet-Download unterstützt. 




Werkzeug-Auswahl 

Wie finde ich die richtigen Werkzeuge für 

mein Projekt bzw. Unternehmen? 

10 

Zur Auswahl geeigneter Werkzeuge gelten zunächst die Überlegungen, die weiter oben für die Auswahl 

von Technologien aufgestellt wurden. Die Ansatzpunkte zur Auswahl von Werkzeugen finden 

sich in Randbedingungen durch das Umfeld, Best-Practice-Erfahrungen sowie in der Informationsbeschaffung 

bzgl. Leistungsfähigkeit, Ausgereiftheit, Anbieter, Kosten, etc. 

Gerade für den Punkt Informationsbeschaffung empfiehlt es sich für den Professional for Software 

Architecture durch kontinuierliches Sichten von Fachliteratur auf einem zwar abstrakten, doch stets 

überblickhaften Wissensstand zu bleiben. 




Abschluss und Ausblick 30 

Zusammenfassung und Diskussion der Schulung. 

Besprechung der Prüfung zum Certified Professional for Software Architecture. 

Bin ich jetzt Professional for Software Architecture? Wie gehe ich aufbauend auf den 

Certified Professional for Software Architecture vor? 

Ausblick: Wie geht es weiter? Was kommt nach dem Foundation Level?

Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?