Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!
Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!
Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<br />
<strong>Architektur“</strong><br />
iSQI Certified Professional for <strong>Software</strong> Architecture<br />
Foundation Level<br />
Version 1.0<br />
Stand: 10.01.2003<br />
© ASQF e. V.
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Historie des <strong>Lehrplan</strong>s<br />
Version Stand Bemerkung<br />
0.9 05.01.2003 Letzter Entwurf für Freigabe<br />
1.0 10.01.2003 Erste freigegebene Version<br />
Verzeichnis <strong>der</strong> verwendeten Abkürzungen<br />
Abkürzung<br />
SEI<br />
RUP<br />
XP<br />
V-Modell<br />
UML<br />
OMG<br />
OCL<br />
Begriff<br />
<strong>Software</strong>-Engineering Institute <strong>der</strong> Carnegie-Mellon-Universität<br />
Rational Unified Process<br />
Extreme Programming<br />
Vorgehensmodell des Bundes<br />
Unified Modelling Language <strong>der</strong> OMG<br />
Object Management Group<br />
Object Constraint Language <strong>der</strong> OMG<br />
Copyright und Nutzungsrechte<br />
Das Werk ist urheberrechtlich geschützt. Jede Verwertung außerhalb des Urheberrechtsgesetzes<br />
ist ohne Zustimmung des iSQI unzulässig und strafbar.<br />
v1.0 Seite 2 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Anmerkung: Die Zeitangaben beziehen sich auf den Theorieanteil des jeweiligen Themas und sollen<br />
einen groben Anhaltspunkt für die Gewichtung <strong>der</strong> einzelnen Themen auf Basis einer viertägigen<br />
Schulung geben. Der Übungsanteil ist nicht enthalten.<br />
<strong>Lehrplan</strong> Thema Beschreibung Zeit (min.)<br />
Einleitung 30<br />
Vorstellung des iSQI-Certified-Programms bzgl. dessen Inhalte, Motivation und Zielsetzung.<br />
Vorstellung des iSQI Certified Professional for <strong>Software</strong> Architecture im Beson<strong>der</strong>en.<br />
Überblick, Aufbau, Ablauf und Zielsetzung <strong>der</strong> Schulung.<br />
Die <strong>Software</strong>-Architektur 90<br />
In diesem Kapitel werden <strong>der</strong> Begriff „<strong>Software</strong>-<strong>Architektur“</strong> definiert, die Beschäftigung<br />
mit <strong>Software</strong>-Architektur motiviert und Wechselwirkungen <strong>der</strong> <strong>Software</strong>-Architektur mit<br />
an<strong>der</strong>en Disziplinen, Phasen und Tätigkeiten im Kontext von Unternehmen und Projekten<br />
aufgezeigt.<br />
Definition Was ist <strong>Software</strong>-Architektur? 12<br />
Eine allgemeingültige Definition des Begriffs <strong>Software</strong>-Architektur existiert nicht; allerdings gibt es<br />
auch keinen Mangel an verschiedenen Definitionen. Beispielsweise listet das <strong>Software</strong>-Engineering<br />
Institute <strong>der</strong> Carnegie-Mellon-Universität auf seiner Webseite über fünfzig unterschiedliche Definitionen<br />
auf, hebt allerdings einige davon als „classic definitions“ hervor.<br />
Der Grund für die Vielzahl an Definitionen ist laut SEI, dass die <strong>Software</strong>-Architektur zwar tiefe Wurzeln<br />
im <strong>Software</strong> Engineering hat, allerdings selbst eine noch sehr junge Disziplin ist.<br />
Eine klassische Definition ist die von Booch, Rumbaugh and Jacobson, 1999. Diese Definition hebt<br />
zum einen die wesentliche Tätigkeit des Professional for <strong>Software</strong> Architecture hervor, wichtige Entscheidungen<br />
zu treffen. Weiterhin werden für die <strong>Software</strong>-Architektur wesentliche Eigenschaften<br />
aufgelistet: Organisation, Struktur, Verhalten, Komposition, Stil.<br />
In <strong>der</strong> Ar<strong>bei</strong>t von Standardisierungsgremien wie <strong>der</strong> IEEE wird <strong>der</strong> Begriff <strong>Software</strong>-Architektur ebenfalls<br />
berücksichtigt. Die IEEE Architecture Working Group hat bereits im September 2000 den IEEE-<br />
Standard 1471 verabschiedet, <strong>der</strong> den Titel „IEEE Recommended Practice for Architectural Description<br />
of <strong>Software</strong>-Intensive Systems“ trägt.<br />
v1.0 Seite 3 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Motivation<br />
Wozu wird eine <strong>Software</strong>-Architektur benötigt?<br />
10<br />
Die Frage „Wozu wird eine <strong>Software</strong>-Architektur benötigt?“ ist zunächst falsch gestellt: Natürlich hat<br />
jedes nicht triviale <strong>Software</strong>system zumindest implizit eine <strong>Software</strong>-Architektur, selbst wenn sich<br />
niemand ausdrücklich darum kümmert. Allerdings: Wenn alle anstehenden Entscheidungen über die<br />
wesentlichen Elemente einer <strong>Software</strong>-Architektur unbewusst von verschiedenen Entwicklern eines<br />
Teams ohne definierten Prozess getroffen werden, so hat dies unmittelbare, negative Konsequenzen<br />
für den Projekterfolg:<br />
• Ergebnisse <strong>der</strong> Analysephase führen nicht zu bewußten Entscheidungen für spätere Phasen<br />
und gehen verloren.<br />
• Struktur und Verhalten <strong>der</strong> <strong>Software</strong> ergeben sich bestenfalls aus technologischen Einzelentscheidungen,<br />
schlimmstenfalls zufällig.<br />
• Vorhandenes Wissen aus vorherigen Projekten ist an die einzelnen Entwickler gebunden und<br />
geht daher leicht verloren o<strong>der</strong> wird nicht wie<strong>der</strong>verwendet.<br />
• Flexibilität und Erweiterbarkeit sind nur eingeschränkt möglich o<strong>der</strong> gehen auf Kosten <strong>der</strong> Konsistenz<br />
des <strong>Software</strong>designs.<br />
• Dokumentation ist lästige Pflicht ohne direkten Bezug zum <strong>Software</strong>system.<br />
• Verständlichkeit und Gesamtübersicht leiden, vor allem für externe Projektbeteiligte wie Management,<br />
Betreiber, Kunden.<br />
Diese Probleme führen schließlich zu längeren Projektbear<strong>bei</strong>tungszeiten und manchmal sogar zum<br />
Scheitern von <strong>Software</strong>-Projekten.<br />
v1.0 Seite 4 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Einordnung<br />
<strong>Software</strong>-Architektur als Bindeglied zwischen<br />
fachlicher Struktur und Implementierung<br />
12<br />
<strong>Software</strong>-Architektur schlägt die Brücke zwischen vielfältigen Anfor<strong>der</strong>ungen aus <strong>der</strong> Fachdomäne<br />
und <strong>der</strong> technischen Realisierung eines Systems. Aus einer Anfor<strong>der</strong>ungsdefinition kann eine <strong>Software</strong>-Architektur<br />
abgeleitet bzw. erar<strong>bei</strong>tet werden. Hier<strong>bei</strong> werden die Struktur des <strong>Software</strong>systems<br />
festgelegt und erste technologische Entscheidungen getroffen.<br />
Da<strong>bei</strong> ist es wichtig, Informationen zu filtern und wegzulassen, um nicht benötigte Details auszuson<strong>der</strong>n<br />
und die Konzentration auf eine geeignete Abstraktionsebene zu heben.<br />
<strong>Software</strong>-Architektur und Design lassen sich nicht klar voneinan<strong>der</strong> abgrenzen. Der Entwurf von<br />
<strong>Software</strong>systemen kann auf verschiedenen Abstraktionsebenen stattfinden. Architektur = Gestaltung<br />
im Großen.<br />
Die <strong>Software</strong>-Architektur wird heute vorwiegend mittels graphischer Modelle formuliert. Den Sprung<br />
von graphischen Modellen zur Implementierung können oftmals Codegeneratoren leisten. Den <strong>Software</strong>test<br />
unterstützt die <strong>Software</strong>-Architektur ebenfalls durch Bereitstellung geeigneter Schnittstellen<br />
innerhalb <strong>der</strong> <strong>Software</strong>-Architektur und Abstimmung des Testrahmens mit dem Testteam.<br />
Die <strong>Software</strong>-Architektur als Disziplin steht im Zentrum aller Aktivitäten eines Projekts.<br />
v1.0 Seite 5 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Stellenwert<br />
Stellenwert einer <strong>Software</strong>-Architektur für<br />
Unternehmen und Projekte<br />
11<br />
Eine dedizierte <strong>Software</strong>-Architektur bringt sowohl dem Unternehmen als auch den dort durchgeführten<br />
Projekten eine Reihe von Vorteilen. Diese lassen sich in technische und organisatorische Vorteile<br />
glie<strong>der</strong>n.<br />
Organisatorische Vorteile:<br />
• <strong>Software</strong>-Architektur schafft den Übergang von <strong>der</strong> Analyse zur Realisierung und ermöglicht die<br />
Erfüllung von Systemanfor<strong>der</strong>ungen<br />
• <strong>Software</strong>-Architektur ermöglicht die Kommunikation des High-Level-Designs und vermittelt den<br />
Gesamtzusammenhang („roter Faden“)<br />
• <strong>Software</strong>-Architektur erlaubt die Aufteilung <strong>der</strong> weiteren Ar<strong>bei</strong>t in geschlossene Ar<strong>bei</strong>tsblöcke<br />
• <strong>Software</strong>-Architektur dokumentiert Systeme und macht sie für alle Projektbeteiligten verständlich<br />
Technische Vorteile:<br />
• <strong>Software</strong>-Architektur ermöglicht es, die Komplexität von Systemen zu beherrschen<br />
• <strong>Software</strong>-Architektur stellt einen Rahmen für Wie<strong>der</strong>verwendung dar (Verwendung von bereits<br />
existierenden und zugekauften Komponenten)<br />
• <strong>Software</strong>-Architektur ist die Basis für Flexibilität und Erweiterbarkeit<br />
• <strong>Software</strong>-Architektur reduziert Kosten für Wartung und Weiterentwicklung<br />
Um diese Vorteile zu erzielen, sollte die <strong>Software</strong>-Architektur einen hohen Stellenwert in Entwicklungsabteilungen<br />
des Unternehmens einnehmen. Dazu gehört es, ausgewiesene Professionals for<br />
<strong>Software</strong> Architecture mit <strong>der</strong> Aufgabe zu betrauen, wesentliche Entscheidungen zur Erar<strong>bei</strong>tung einer<br />
<strong>Software</strong>-Architektur verantwortlich zu treffen.<br />
v1.0 Seite 6 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Wechselwirkungen<br />
Rolle und Umfeld <strong>der</strong> <strong>Software</strong>-<br />
Architektur<br />
15<br />
<strong>Software</strong>-Architektur bündelt unternehmensweites Know-how<br />
Der Nutzen, den ein Unternehmen aus <strong>der</strong> konsequenten Durchführung <strong>der</strong> Disziplin <strong>Software</strong>-<br />
Architektur ziehen kann, muss sich nicht nur auf Einzelprojekte beschränken. Gerade die Vorteile<br />
durch Wie<strong>der</strong>verwendung von Komponenten, Strukturen und Organisationsformen sowie die Standardisierung<br />
von grundlegenden Architektur- und Designmustern wirken sich projektübergreifend<br />
und im besten Fall unternehmensweit aus.<br />
Eine <strong>Software</strong>-Architektur sollte so flexibel sein, dass sie für viele, ähnliche Projekte eines Unternehmens<br />
anwendbar ist. Die <strong>Software</strong>-Architektur bündelt das projektübergreifende, unternehmensweite<br />
Know-how in Form von explizit aufgezeichneten Modellen o<strong>der</strong> Dokumenten.<br />
Da<strong>bei</strong> muss die Durchgängigkeit von Konzepten über den gesamten Entwicklungsprozess durch die<br />
<strong>Software</strong>-Architektur getragen werden.<br />
Externe Einflüsse auf die <strong>Software</strong>-Architektur<br />
Die <strong>Software</strong>-Architektur für ein Projekt unterliegt vielfältigen Einflüssen:<br />
• Beteiligte Menschen beeinflussen die <strong>Software</strong>-Architektur durch ihre Fähigkeiten und ihr Knowhow<br />
• Das Unternehmen sowie Organisations- und Abteilungsstruktur beeinflussen die <strong>Software</strong>-<br />
Architektur in ihren Grundsätzen und Werten<br />
• Die <strong>Software</strong>-Architektur muss die Maximierung des Kundennutzens berücksichtigen<br />
• An<strong>der</strong>e Projekte im Unternehmen bestimmen wesentliche Teile <strong>der</strong> <strong>Software</strong>-Architektur<br />
• Bestehende Systeme o<strong>der</strong> Frameworks sollten in <strong>der</strong> <strong>Software</strong>-Architektur berücksichtigt werden<br />
(Vereinheitlichung, Wie<strong>der</strong>verwendung, Standardisierung)<br />
• Organisatorische Bedingungen wie Zeit, Budget o<strong>der</strong> zu erzielende Qualität geben den Rahmen<br />
für die <strong>Software</strong>-Architektur vor<br />
• Produkte und Technologien, die bereits im Team bekannt sind, beeinflussen ebenfalls die Entscheidungen<br />
für die <strong>Software</strong>-Architektur.<br />
Starke zeigt die unterschiedlichen Ebenen <strong>der</strong> Wechselwirkungen von externen Einflüssen und<br />
<strong>Software</strong>-Architektur anhand von einigen praktischen Beispielen auf.<br />
Bereits 1968 hat Melvin Conway sein Gesetz formuliert, welches besagt, dass die Struktur in einer<br />
<strong>Software</strong>-Architektur und die Struktur <strong>der</strong> Organisation oftmals kongruent sind. Da<strong>bei</strong> können Kräfte<br />
in <strong>bei</strong>de Richtungen wirken.<br />
v1.0 Seite 7 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Anfor<strong>der</strong>ungen und <strong>Software</strong>-Architektur<br />
Die Schnittstellen zwischen <strong>der</strong> Anfor<strong>der</strong>ungsanalyse<br />
und <strong>der</strong> <strong>Software</strong>-<br />
Architektur<br />
20<br />
<strong>Software</strong>-Architektur hat eine zentrale Rolle in <strong>Software</strong>projekten. Die <strong>Software</strong>-Architektur hat da<strong>bei</strong><br />
Schnittstellen zu an<strong>der</strong>en Aktivitäten innerhalb einer Organisation, die wichtigsten sind:<br />
• Anfor<strong>der</strong>ungsanalyse<br />
• Design und Implementierung<br />
• Projektplanung<br />
• Test und Qualitätssicherung<br />
• Hardware-Architektur<br />
Die <strong>Software</strong>-Architektur dient da<strong>bei</strong> den Beteiligten als zentrale Referenz bzw. als Leitbild.<br />
Im Beson<strong>der</strong>en soll hier die Schnittstelle zur Anfor<strong>der</strong>ungsanalyse näher behandelt werden.<br />
• auf Basis funktionaler Anfor<strong>der</strong>ungen Architektur erstellen<br />
• nicht-funktionale Anfor<strong>der</strong>ungen berücksichtigen<br />
• Durchstich<br />
• Architektur auf wesentliche Anfor<strong>der</strong>ungen testen<br />
• Kreativer Schritt, Erfahrung<br />
Die Analysephase muss sicherstellen, dass das richtige System entwickelt wird. Die Entwurfsphase<br />
stellt hingegen sicher, dass das System richtig entwickelt wird.<br />
Die Schnittstelle von <strong>der</strong> Anfor<strong>der</strong>ungsanalyse zur <strong>Software</strong>-Architektur ist keine Einbahnstraße: Ü-<br />
ber die Aspekte <strong>der</strong> technischen Machbarkeit und <strong>der</strong> Kosten hat die <strong>Software</strong>-Architektur ihrerseits<br />
Einflüsse auf die Anfor<strong>der</strong>ungen, die letztendlich im Pflichtenheft verbindlich festgelegt werden.<br />
Der Professional for <strong>Software</strong> Architecture prüft, präzisiert und klärt einerseits die Anfor<strong>der</strong>ungen;<br />
an<strong>der</strong>erseits muss er die Rückwirkungen überblicken und gegebenenfalls den Analysten notwendige<br />
Än<strong>der</strong>ungen rückmelden. Er ar<strong>bei</strong>tet also stets mit einem unvollständigen Satz von Anfor<strong>der</strong>ungen,<br />
<strong>der</strong> nicht unbedingt konsistent sein muss. Somit sitzt <strong>der</strong> Professional for <strong>Software</strong> Architecture an<br />
<strong>der</strong> Schnittstelle <strong>bei</strong><strong>der</strong> Aktivitäten.<br />
Die Anfor<strong>der</strong>ungen aus <strong>der</strong> Anfor<strong>der</strong>ungsanalyse werden zum einen in fachliche und technische Anfor<strong>der</strong>ungen<br />
unterschieden, zum an<strong>der</strong>en in funktionale und nicht-funktionale Anfor<strong>der</strong>ungen.<br />
Fachliche Anfor<strong>der</strong>ungen beschreiben Funktion und Verhalten bezogen auf die Fachdomäne, technische<br />
Anfor<strong>der</strong>ungen beziehen sich auf die technische Umsetzung.<br />
Im Volere Requirements Specification Template <strong>der</strong> Atlantic Systems Guild werden funktionale Anfor<strong>der</strong>ungen<br />
ausführlich definiert.<br />
Der Professional for <strong>Software</strong> Architecture muss <strong>bei</strong> <strong>der</strong> Erar<strong>bei</strong>tung einer Lösung für einen gegebenen<br />
Satz von Anfor<strong>der</strong>ungen damit rechnen, dass es zwischen einzelnen Anfor<strong>der</strong>ungen Konflikte<br />
gibt o<strong>der</strong> gar eine Teilmenge <strong>der</strong> Anfor<strong>der</strong>ungen in sich wi<strong>der</strong>sprüchlich ist. Somit besteht <strong>bei</strong> <strong>der</strong><br />
Anfor<strong>der</strong>ungsanalyse und <strong>bei</strong> Erstellung <strong>der</strong> <strong>Software</strong>-Architektur ein hoher Bedarf, Entscheidungen<br />
zu treffen.<br />
v1.0 Seite 8 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Aktuelle Forschung Architekturtransformation 10<br />
In einer jungen Disziplin wie <strong>der</strong> <strong>Software</strong>-Architektur gibt es eine Vielzahl von Forschungsaktivitäten,<br />
von denen eine herausgegriffen werden soll: die Architekturtransformation.<br />
Architekturtransformation wird von Prof. Jan Bosch (Univ. Groningen, NL) als eine <strong>der</strong> Methoden<br />
propagiert, die zur Etablierung von Produktpipelines für <strong>Software</strong>produkte notwendig ist.<br />
v1.0 Seite 9 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Der Professional for <strong>Software</strong> Architecture 50<br />
Dieses Kapitel beschreibt die Rolle des Professional for <strong>Software</strong> Architecture. Es klärt,<br />
was einen Professional for <strong>Software</strong> Architecture ausmacht und welche Qualifikationen<br />
er besitzen sollte.<br />
Begriffsklärung<br />
Was ist ein Professional for <strong>Software</strong> Architecture<br />
?<br />
5<br />
Der Professional for <strong>Software</strong> Architecture nimmt eine zentrale Rolle in einem <strong>Software</strong>projekt ein.<br />
Mit seiner Leistung steht und fällt das Ergebnis des gesamten Projekts. Seine Fähigkeit, auch zukünftige<br />
Verän<strong>der</strong>ungen einzuplanen und zu ermöglichen, beeinflusst den Wert und die Dauerhaftigkeit<br />
des Ergebnisses maßgeblich.<br />
v1.0 Seite 10 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Fähigkeiten<br />
Welche Qualifikationen muss ein Professional<br />
for <strong>Software</strong> Architecture besitzen?<br />
10<br />
Der typische Werdegang zum Professional for <strong>Software</strong> Architecture ist <strong>der</strong> vom Entwickler zum erfahrenen<br />
Entwickler hin zu einem Teammitglied, das zentralen und wesentlichen Einfluss auf Projektverlauf<br />
und -ergebnis hat.<br />
Professionals for <strong>Software</strong> Architecture werden deshalb nicht geboren, son<strong>der</strong>n eignen sich ihre Fähigkeiten<br />
durch Projektar<strong>bei</strong>t an. Natürlich profitieren sie auch von den Erfahrungen an<strong>der</strong>er. Eigene<br />
Erfahrungen sind für diese Aufgabe jedoch immer vorzuziehen.<br />
Die Fähigkeiten, die ein Professional for <strong>Software</strong> Architecture besitzen muss, sind in verschiedenen<br />
Bereichen anzusiedeln:<br />
Er muss kommunikative Fähigkeiten (Soft Skills) besitzen, wie<br />
• Abstraktionsfähigkeit<br />
• Entscheidungsfähigkeit<br />
• Durchsetzungsvermögen<br />
• Teamfähigkeit<br />
• Kommunikations- und Überzeugungsfähigkeit<br />
da er mit (nahezu) allen an<strong>der</strong>en beteiligten Projektrollen kommunizieren, seine Lösungen vorstellen<br />
und vertreten muss.<br />
Hinzu kommen intensive technische Erfahrungen wie<br />
• Kenntnisse über gängige technische Lösungen für die Hauptarchitekturprobleme GUI, Persistence,<br />
Networking, Verteilung, Security,<br />
um das zu erstellende System verständlich, zukunftssicher und leicht erweiterbar bzw. wartbar gestalten<br />
zu können.<br />
Der Professional for <strong>Software</strong> Architecture sollte deshalb eine starke Persönlichkeit sein; er ist typischerweise<br />
ein Generalist: Sein Wissen wird gleichermaßen durch Soft Skills und technische Erfahrungen<br />
geprägt.<br />
Oft fällt er auf Basis unvollständigen Wissens auch suboptimale Entscheidungen. Eine iterative Entwicklung<br />
ist heutzutage erfor<strong>der</strong>lich, um Lücken zu füllen o<strong>der</strong> neues Wissen einfließen zu lassen.<br />
v1.0 Seite 11 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Kommunikation und Kooperation<br />
Wie ar<strong>bei</strong>tet <strong>der</strong> Professional for <strong>Software</strong><br />
Architecture im Projektteam?<br />
Welche Aufgaben nimmt er wahr?<br />
15<br />
Aufgrund seiner zentralen Rolle ist <strong>der</strong> Professional for <strong>Software</strong> Architecture Ansprechpartner für<br />
viele an<strong>der</strong>e Projektmitglie<strong>der</strong>:<br />
• Fachabteilungen (für technische und fachliche Anfor<strong>der</strong>ungen)<br />
• Projektmanagement (zur Einflussnahme auf Projektplanung, -ablauf und -controlling)<br />
• Entwickler (zum Verständnisaufbau (Überblick des Systems) und für Entwicklungsvorgaben)<br />
• Testteam (zur Abstimmung <strong>der</strong> Testrahmenbedingungen)<br />
Von <strong>der</strong> Fachabteilung bekommt er den Input, was zu tun ist. In Abstimmung mit dem Projektmanagement<br />
legt er fest, wann und unter welchen Rahmenbedingungen es getan werden kann. Mit den<br />
Entwicklern erfolgt schließlich die Vorgabe und Abstimmung, wie das System umgesetzt werden soll.<br />
Seine typischen Aufgaben sind:<br />
• Entgegennahme und inhaltliche Abstimmung <strong>der</strong> fachlichen und technischen Anfor<strong>der</strong>ungen mit<br />
<strong>der</strong> Fachabteilung (Artefakte sind Pflichtenhefte, Anfor<strong>der</strong>ungen jeglicher Art)<br />
• Vorgabe und Abstimmung <strong>der</strong> Architektur, entsprechen<strong>der</strong> Richtlinien und Muster sowie des<br />
Vorgehens mit dem Entwicklungsteam (Modelle sowie Beispiele für Architektur und Vorgehen,<br />
Architektur- und Entwicklungsmuster, repräsentativer Beispielcode)<br />
• Abstimmung <strong>der</strong> Architektur auf Testbarkeit, Test <strong>der</strong> Architektur und Testbarkeit <strong>der</strong> Entwicklungsergebnisse<br />
mit dem Testteam (Testszenarien und -pläne)<br />
• Abstimmung von Entwicklungszyklen und -ergebnissen mit <strong>der</strong> Projektleitung (Projektpläne und<br />
Termine)<br />
• (typischerweise iterativer) Entwurf, Integration und Test <strong>der</strong> Architektur<br />
v1.0 Seite 12 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Handwerkszeug<br />
Was benötigt <strong>der</strong> Professional for <strong>Software</strong><br />
Architecture für seine Aufgabe?<br />
10<br />
Die Grundlagen für seine Ar<strong>bei</strong>t sind Modelle, Heuristiken, Muster aus an<strong>der</strong>en Projekten, Codeschnipsel<br />
und weiteres, die einerseits bestehende Erfahrungen dokumentieren und zum an<strong>der</strong>en die<br />
konkreten Anfor<strong>der</strong>ungen des aktuellen Projekts aufzeigen.<br />
Vergleichbar mit einem Puzzle setzt <strong>der</strong> Professional for <strong>Software</strong> Architecture Einzelteile zusammen,<br />
zerlegt Bestehendes, löst Wi<strong>der</strong>sprüche auf und fügt all dieses zu einem neuen Großen und<br />
Ganzen zusammen.<br />
An geeigneter Stelle wird in den folgenden Kapiteln detailliert auf dieses Thema eingegangen.<br />
v1.0 Seite 13 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Beson<strong>der</strong>heiten<br />
Wie ar<strong>bei</strong>tet <strong>der</strong> Professional for <strong>Software</strong><br />
Architecture im Team?<br />
Gibt es in jedem Projekt diese Rolle?<br />
10<br />
Stehen diese Fähigkeiten nicht in einer einzelnen Person zur Verfügung o<strong>der</strong> kann eine einzelne<br />
Person in einem großen Projekt diese Aufgabe nicht alleine wahrnehmen, so kann <strong>der</strong> „Professional<br />
for <strong>Software</strong> Architecture “ auch durch ein Team gebildet werden.<br />
Die Größe des Teams ist da<strong>bei</strong> auch <strong>bei</strong> großen Projekten zu beschränken, um die Anzahl möglicher<br />
Meinungen zu begrenzen und Koordinationsaufwände zu minimieren. Die Anzahl <strong>der</strong> Mitglie<strong>der</strong><br />
orientiert sich an <strong>der</strong> Größe des Projekts und den verschiedenen Themengebieten.<br />
Handelt es sich umgekehrt um ein sehr kleines Projekt, so kann die Rolle des Professionals for<br />
<strong>Software</strong> Architecture auch mit einer an<strong>der</strong>en, z. B. <strong>der</strong> des Projektleiters zusammenfallen.<br />
Zu beachten ist, dass gerade in agilen o<strong>der</strong> XP-Projekten ein neues/an<strong>der</strong>es Rollenverständnis<br />
herrscht. Hierarchien werden vereinfacht o<strong>der</strong> sind nicht vorhanden. Auch hier können Rollen zusammenfallen.<br />
v1.0 Seite 14 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Vorgehen 50<br />
In diesem Kapitel werden die wichtigsten Schritte und <strong>der</strong>en Ergebnisse <strong>bei</strong> <strong>der</strong> Erstellung<br />
einer <strong>Software</strong>-Architektur behandelt. Da<strong>bei</strong> wird von einem konkreten Prozessmodell<br />
abstrahiert.<br />
Einordnung<br />
Prozesse und die Einordnung von Architektur,<br />
Allgemeines Vorgehen<br />
10<br />
Architektur als zentrales Thema im Entwicklungsprozess.<br />
<strong>Software</strong>entwicklungsprozesse beschreiben eine Reihe von Disziplinen <strong>bei</strong> <strong>der</strong> <strong>Software</strong>entwicklung.<br />
Sie legen da<strong>bei</strong> Rollen (Verantwortlichkeiten), Dokumente (Ar<strong>bei</strong>tsergebnisse) und Aktivitäten fest.<br />
Je<strong>der</strong> Prozess setzt hier an<strong>der</strong>e Schwerpunkte. Das Thema Architektur spielt aber <strong>bei</strong> allen Prozessen<br />
eine zentrale Rolle. Es wird lediglich unterschiedlich dargestellt. Während im RUP eine explizite<br />
Rolle des „Architekten“ vergeben ist, <strong>der</strong> für bestimmte Teilaktivitäten verantwortlich ist, verteilen<br />
sich die Architekturaktivitäten <strong>bei</strong> XP auf verschiedene an<strong>der</strong>e Rollen.<br />
Die <strong>Software</strong>architektur bildet immer das Grundskelett für alle an<strong>der</strong>en Prozessaktivitäten. Sie stellt<br />
die Struktur für die weitere Detaillierung zur Verfügung. Die Prozesse unterscheiden sich da<strong>bei</strong> allerdings<br />
stark bezüglich <strong>der</strong> gefor<strong>der</strong>ten Formalität und <strong>der</strong> Rollen und Dokumente.<br />
Die Architektur eines Systems spiegelt zu einem großen Anteil die nicht-funktionalen Anfor<strong>der</strong>ungen<br />
(Qualitätseigenschaften) wie<strong>der</strong> und gibt zum an<strong>der</strong>en Aufschluss über potentielle Risiken. Diese Informationen<br />
sind wie<strong>der</strong>um essentiell für das Projektmanagement.<br />
v1.0 Seite 15 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Zentrale Rolle <strong>der</strong> <strong>Software</strong>-Architektur<br />
im Entwicklungsprozess<br />
Vorgehen <strong>bei</strong> <strong>der</strong> <strong>Software</strong>-Architektur 25<br />
Angelehnt an die verschiedenen existierenden <strong>Software</strong>entwicklungsprozesse wird ein allgemeingültiger<br />
Vorgehensrahmen mit dessen Schritten und Artefakten definiert.<br />
Iterative, inkrementelle Prozesse sind heute Standard. Diese unterscheiden zeitlich aufeinan<strong>der</strong>folgende<br />
Phasen und dazu querschnittlich angeordnete Aktivitäten. Diese Phasen bilden da<strong>bei</strong> wesentliche<br />
Meilensteine für das Projekt. Die Aktivitäten ziehen sich in unterschiedlicher Intensität durch alle<br />
Phasen.<br />
Der Professional for <strong>Software</strong> Architecture ist an allen Phasen beteiligt. Seine Aktivitäten laufen in<br />
<strong>der</strong> Analyse- und Design-Aktivität ab und wirken sich auf alle an<strong>der</strong>en Aktivitäten aus.<br />
Wichtige Schritte im Rahmen <strong>der</strong> Architekturerstellung und Überar<strong>bei</strong>tung sind:<br />
• Machbarkeitsstudie & Risikoanalyse<br />
• Priorisierung <strong>der</strong> Anfor<strong>der</strong>ungen<br />
• Konkretisierung <strong>der</strong> Risikoanalyse<br />
• Iterationsplanung<br />
• Architekturkonzept<br />
• Koordination <strong>der</strong> Entwicklung<br />
v1.0 Seite 16 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Schnittstellen und Wechselwirkungen<br />
mit an<strong>der</strong>en<br />
Rollen<br />
Welche Schnittstellen gibt es zu an<strong>der</strong>en<br />
Rollen? Was ist Gegenstand dieser<br />
Schnittstellen?<br />
15<br />
Der Professional for <strong>Software</strong> Architecture hat eine Reihe von Schnittstellen zu an<strong>der</strong>en Rollen in<br />
<strong>der</strong> <strong>Software</strong>entwicklung.<br />
Professional for <strong>Software</strong> Architecture – Fachabteilung (Analyst)<br />
Zwischen dem Professional for <strong>Software</strong> Architecture und <strong>der</strong> Fachabteilung findet im Wesentlichen<br />
eine Wechselwirkung bezüglich <strong>der</strong> Anfor<strong>der</strong>ungen statt. Die Fachabteilung liefert die Anfor<strong>der</strong>ungen<br />
für die <strong>der</strong> Professional for <strong>Software</strong> Architecture ein Gesamtkonzept entwerfen soll. Der Professional<br />
for <strong>Software</strong> Architecture evaluiert diese Anfor<strong>der</strong>ungen auf ihre technische Machbarkeit (speziell<br />
auch auf wi<strong>der</strong>sprüchliche Anfor<strong>der</strong>ungen). Daraus können Konkretisierungen bzw. Än<strong>der</strong>ungsanfor<strong>der</strong>ungen<br />
an die Fachabteilung resultieren. Außerdem findet ein Informationstransfer bezüglich<br />
<strong>der</strong> Risiken von <strong>der</strong> Fachabteilung zum Professional for <strong>Software</strong> Architecture statt.<br />
Professional for <strong>Software</strong> Architecture – Entwickler<br />
Der Professional for <strong>Software</strong> Architecture stellt den Entwicklern eine Gesamtarchitektur als Grundlage<br />
für das Feindesign zur Verfügung und sichert das Zusammenspiel zwischen den verschiedenen<br />
Komponenten. In diesem Zusammenhang gibt er den Entwicklern Architekturkonzepte, Technologien<br />
und Tools sowie Implementierungsrichtlinien vor. Die Entwickler auf <strong>der</strong> an<strong>der</strong>en Seite geben den<br />
Umsetzungsstatus und eventuell notwendige o<strong>der</strong> gewünschte Än<strong>der</strong>ungen an den Professional for<br />
<strong>Software</strong> Architecture weiter. Dieser muss dann darüber entscheiden ob diese Anfragen umgesetzt<br />
werden können und ob es sich da<strong>bei</strong> um Probleme handelt, die kritisch für die erfolgreiche Umsetzung<br />
des Gesamtsystems sind.<br />
Professional for <strong>Software</strong> Architecture – Tester<br />
Der Professional for <strong>Software</strong> Architecture unterstützt das Testteam <strong>bei</strong>m Aufbau des Testframeworks.<br />
Außerdem kann er <strong>bei</strong> einer großen Anzahl von Testfällen <strong>bei</strong> <strong>der</strong> Priorisierung bzw. Auswahl<br />
wichtiger Testfälle behilflich sein. Das Testteam liefert dem Professional for <strong>Software</strong> Architecture<br />
Informationen bezüglich <strong>der</strong> Stabilität <strong>der</strong> Architektur und des Erfüllungsgrades <strong>der</strong> Qualitätsanfor<strong>der</strong>ungen.<br />
Professional for <strong>Software</strong> Architecture – Projektleitung<br />
Der Projektleiter liefert dem Professional for <strong>Software</strong> Architecture die Projektziele und organisatorischen<br />
Randbedingungen. Der Professional for <strong>Software</strong> Architecture muss daraus eine Basisarchitektur<br />
ableiten und potentielle Risiken identifizieren. Im weitern Verlauf erstellt er dann mit Hilfe <strong>der</strong><br />
Anfor<strong>der</strong>ungen <strong>der</strong> Fachabteilung eine Grobarchitektur und einen Iterationsplan. Zu den wesentlichen<br />
Aufgaben des Professional for <strong>Software</strong> Architecture gehört es, den Projektleiter stetig über<br />
den aktuellen Stand <strong>der</strong> technischen Risiken und Lösungsmöglichkeiten, sowie den Projektstatus<br />
<strong>der</strong> Iterationsplanung zu informieren.<br />
v1.0 Seite 17 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Notation und Modellierung 120<br />
Dieses Kapitel zeigt auf, wie Architektur beschrieben und dargestellt wird. Der Schwerpunkt<br />
liegt auf <strong>der</strong> gezielten Verwendung <strong>der</strong> graphischen Modellierungssprache UML<br />
für unterschiedliche Sichten auf die Architektur.<br />
Motivation<br />
Notation zur Kommunikation, Dokumentation<br />
und Codegenerierung<br />
10<br />
Um Interpretationsmöglichkeiten zu vermeiden wird eine Notationsform benötigt, die über eine höhere<br />
Abstraktionsebene verfügt als reiner Quellcode und zudem standardisiert ist.<br />
Zwei Kernprobleme <strong>der</strong> <strong>Software</strong>entwicklung sind die Kommunikation im Team sowie die Erstellung<br />
von Dokumentation. Eine standardisierte Modellierung trägt zur Lösung <strong>bei</strong><strong>der</strong> Probleme <strong>bei</strong>.<br />
Existieren in einem Projekt nicht die richtigen Kommunikationsstrukturen, gerät dies ab einer bestimmten<br />
Komplexität ins Stocken und das Team wird ineffektiv. Eine ausführliche <strong>Software</strong>architektur,<br />
die in einer standardisierten Form notiert ist, leistet einen wesentlichen Beitrag zur Behebung<br />
dieses Kommunikationsproblems. Entscheidend ist, dass dadurch jedem Beteiligten sofort die wesentlichen<br />
Strukturen, Mechanismen, Einschränkungen, Schnittstellen und Verantwortlichkeiten von<br />
Elementen <strong>der</strong> <strong>Software</strong> klar verständlich werden und ihm somit die Bedeutung und Auswirkung <strong>der</strong><br />
von ihm entwickelten Teile <strong>der</strong> <strong>Software</strong> verständlich werden. Insbeson<strong>der</strong>e wird es dem Entwickler<br />
ermöglicht, in einem hohen Maße selbständig und unabhängig zu ar<strong>bei</strong>ten, da ihm die notwendigen<br />
Informationen für seine Ar<strong>bei</strong>t vorliegen.<br />
Gerade <strong>bei</strong> komplexer <strong>Software</strong> ist die Erstellung einer aussagekräftigen, qualitativ hochwertigen<br />
Dokumentation sehr aufwendig. Hinzu kommt, dass es sehr schwierig ist, die Dokumentation aktuell<br />
zu halten. Gerade für den Investitionsschutz und die Wartung spielt eine gute Dokumentation jedoch<br />
eine wichtige Rolle. Eine standardisierte Modellierung hilft hier<strong>bei</strong>, da sie teilweise Codegenerierung<br />
ermöglicht: „The model ist the code“. Da aus den Modellen auch die Dokumentation generiert werden<br />
kann, ist <strong>der</strong>en Erstellung mit deutlich weniger Aufwand verbunden. Zudem bleibt ist sie immer<br />
auf dem aktuellen Stand.<br />
v1.0 Seite 18 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
UML<br />
UML als standardisierte Notationsform für<br />
<strong>Software</strong><br />
10<br />
Als standardisierte Notationsform für <strong>Software</strong> hat sich UML etabliert. UML ist eine allgemeingültige<br />
Modellierungssprache, die für alle wesentlichen Objekt- und Komponentenmethoden in beliebigen<br />
Branchen und Domänen angewendet werden kann. Die Standardisierung <strong>der</strong> UML wird durch die<br />
Object Management Group (OMG, www.omg.org) vorangetrieben.<br />
Die OMG ist eine nicht auf Profit ausgerichtete Organisation. Sie hat Ihren Hauptsitz in <strong>der</strong> Nähe von<br />
Boston in den USA. Bei den Mitglie<strong>der</strong>n <strong>der</strong> OMG handelt es sich um Unternehmen und Organisationen<br />
aus aller Welt. OMG-Standards werden durch einen definierten Prozess vorangetrieben und<br />
durch einen Abstimmungsprozess <strong>der</strong> Mitglie<strong>der</strong> verabschiedet.<br />
1997 wurde die UML in <strong>der</strong> ersten Version 1.1 auf Basis einer breiten Unterstützung <strong>der</strong> Industrie<br />
verabschiedet. In 2001 wurde die Version 1.4 verabschiedet. 2003 wurde die UML in <strong>der</strong> Version 2.0<br />
freigegeben. Diese Version enthält wesentliche Erweiterungen, die auf <strong>der</strong> Basis <strong>der</strong> praktischen<br />
Anwendungserfahrungen <strong>der</strong> letzten Jahre eingeflossen sind. Neben dem allgemeinen UML-<br />
Standard gibt es noch standardisierte Profile, welche die UML für den Einsatz in bestimmten Domänen,<br />
wie z. B. Enterprise- o<strong>der</strong> Real-Time-<strong>Software</strong> spezialisiert.<br />
Die UML definiert eine Menge von Elementen mit <strong>der</strong>en Bedeutung und graphischer Notation. Es<br />
handelt sich da<strong>bei</strong> sowohl um statische, wie auch dynamische Elemente. Dazu zählen z. B. Klassen,<br />
Komponenten, Pakete, Aktionen, Interaktionen, Zustandsautomaten, Use Cases etc. Neben diesen<br />
Elementen definiert die UML auch eine Menge von Diagrammen. Die Diagramme ermöglichen es,<br />
verschiedene Aspekte eines <strong>Software</strong>systems darzustellen. Dazu zählen statische Diagrammtypen<br />
wie Klassendiagramme, Komponentendiagramme, Verteilungsdiagramme aber auch dynamische<br />
Diagrammtypen, wie Sequenzdiagramme, Aktivitätsdiagramme o<strong>der</strong> Zustandsdiagramme.<br />
Die wesentlichen Diagrammtypen <strong>der</strong> UML zur Beschreibung <strong>der</strong> <strong>Software</strong>struktur sind:<br />
• Klassendiagramme<br />
• Komponentendiagramme<br />
• Verteilungsdiagramme<br />
• Komponentenverteilungsdiagramme<br />
• Interne Strukturdiagramme<br />
• Paketdiagramme<br />
Die wesentlichen Diagrammtypen <strong>der</strong> UML zur Beschreibung des Verhaltens von <strong>Software</strong> sind:<br />
• Aktivitätsdiagramme<br />
• Sequenzdiagramme<br />
• Kommunikationsdiagramme<br />
• Protokollzustandsautomatendiagramme<br />
• Zustandsautomatendiagramme<br />
• Anwendungsfalldiagramme (Use-Case Diagramme)<br />
v1.0 Seite 19 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Sichten<br />
Welche Sichten auf eine <strong>Software</strong>-<br />
Architektur müssen modelliert werden?<br />
5<br />
Ziel <strong>der</strong> UML ist es, durch die unterschiedlichen Diagrammtypen verschieden Sichten auf ein <strong>Software</strong>system<br />
zu ermöglichen. Jede Diagrammart <strong>der</strong> UML kann da<strong>bei</strong> für unterschiedliche Sichten<br />
auf unterschiedlichen Abstraktionsebenen eingesetzt werden.<br />
Um ein komplexes <strong>Software</strong>system verstehen zu können ist es wichtig, dass bestimmte Sichten auf<br />
die Architektur explizit modelliert werden.<br />
Folgende Sichten haben sich als wesentlich herausgestellt:<br />
• Anfor<strong>der</strong>ungen<br />
• Abbildung <strong>der</strong> Anfor<strong>der</strong>ungen auf das Design<br />
• Systemkontext<br />
• Systemdesign<br />
○ Statische Sicht: Komponenten, Klassen, Struktur, Schnittstellen<br />
○ Dynamische Sicht: Verhalten, Mechanismen, Objekte, Threads<br />
• Implementierung (Paketorganisation, Artefakte)<br />
• Infrastruktur und Verteilung<br />
• Informationsfluss und Daten<br />
Im Rest dieses Kapitels wird auf obige Sichten jeweils näher eingegangen.<br />
v1.0 Seite 20 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Anfor<strong>der</strong>ungen<br />
Bedeutung und Darstellung <strong>der</strong> Anfor<strong>der</strong>ungen<br />
15<br />
Auf die Anfor<strong>der</strong>ungssicht wird im Rahmen des Certified Professional for <strong>Software</strong> Architecture nur<br />
aus Gründen <strong>der</strong> Vollständigkeit eingegangen.<br />
Die Anfor<strong>der</strong>ungen werden in Form von Use Cases und natürlicher Sprache dargestellt. Anfor<strong>der</strong>ungen<br />
unterteilen sich in die drei Hauptkategorien Use Cases, ergänzende funktionale Anfor<strong>der</strong>ungen<br />
und nicht-funktionale Anfor<strong>der</strong>ungen.<br />
Die Use Cases erfassen da<strong>bei</strong> den wesentlichen Teil <strong>der</strong> funktionalen Anfor<strong>der</strong>ungen. Ein Use Case<br />
beschreibt da<strong>bei</strong> eine typische Art und Weise, wie das System von außen benutzt wird und umfasst<br />
somit eine Menge funktionaler Anfor<strong>der</strong>ungen. Für jeden Use Case existieren ein o<strong>der</strong> mehrer Szenarien.<br />
Die detaillierte Beschreibung <strong>der</strong> Use Case Szenarien und <strong>der</strong> ihm zugeordneten funktionalen<br />
Anfor<strong>der</strong>ungen erfolgt in natürlicher Sprache und kann durch Sequenz- o<strong>der</strong> Aktivitätsdiagramme<br />
unterstützt werden. Der Zusammenhang zwischen Aktoren und Use Cases wird in Use-Case-<br />
Diagrammen dargestellt. Besitzt das System auf Ebene <strong>der</strong> Use Cases ein zustandsbasiertes Verhalten,<br />
so kann dies über Zustandsautomaten dargestellt werden. Ein explizites Kontextdiagramm<br />
zeigt allein das System und die Aktoren, mit denen es in Verbindung steht.<br />
Ergänzende funktionale Anfor<strong>der</strong>ungen sind solche, die nicht einen spezifischen Use Case zugeordnet<br />
sind. Diese werden ebenso wie nicht-funktionale Anfor<strong>der</strong>ungen ausschließlich in natürlicher<br />
Sprache erfasst.<br />
v1.0 Seite 21 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Systemkontext<br />
Bedeutung und Darstellung des Systemkontexts<br />
5<br />
In dieser Sicht wird dargestellt, wie das System als Blackbox in seine Umgebung eingebettet ist. Neben<br />
dem System und allen externen Elementen werden auch die Kommunikationsbeziehungen und<br />
Schnittstellen zwischen diesen dargestellt. Für diese Sicht bietet sich das Komponentendiagramm<br />
an, welches die Kooperation zwischen den Komponenten hervorhebt.<br />
v1.0 Seite 22 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Systemdesign<br />
Bedeutung und Darstellung des Systemdesigns<br />
mit dynamischen und statischen<br />
Aspekten<br />
45<br />
Im Rahmen dieser Sicht wird alles dargestellt, was für das Verständnis des internen Aufbaus und <strong>der</strong><br />
internen Funktionsweise des Systems wichtig ist (die sog. „Whitebox-Sicht“ auf das System). Dazu<br />
gehören strukturelle und dynamische Aspekte auf unterschiedlichen Hierarchieebenen des Systems.<br />
Statische Sichten<br />
Auf den oberen Hierarchieebenen wird ein System meistens aus Komponenten aufgebaut. Erst auf<br />
den unteren Ebenen zerfällt die interne Struktur <strong>der</strong> Komponenten in miteinan<strong>der</strong> kooperierende Objekte<br />
verschiedener Klassen. Die Architektur von Komponenten einer bestimmten Hierarchieebene<br />
wird in Komponentendiagrammen dargestellt, die strukturellen Beziehungen zwischen Klassen werden<br />
in Klassendiagrammen notiert. Der interne Aufbau einer Komponente o<strong>der</strong> Klasse wird in einem<br />
internen Strukturdiagramm verdeutlicht. Wichtig ist es, die Schnittstellen detailliert zu beschreiben.<br />
Auch können Einschränkungen für Beziehungen zwischen Elementen o<strong>der</strong> für ganze Elemente existieren.<br />
Um Einschränkungen auszudrücken bietet sich die OCL an.<br />
Dynamische Sichten<br />
Auch <strong>bei</strong> <strong>der</strong> Dynamik gibt es verschiedene Hierarchieebenen. Kernpunkt des Verhaltens eines Systems<br />
ist, wie es bestimmte Use Case Szenarien abar<strong>bei</strong>tet. Es kann auf sehr grober Ebene gezeigt<br />
werden, wie die Komponenten miteinan<strong>der</strong> kommunizieren, o<strong>der</strong> an<strong>der</strong>erseits die detaillierte Funktionsweise<br />
eines Algorithmus modelliert werden. Zur Beschreibung von dynamischen Aspekten bietet<br />
die UML mehrere Diagrammarten, die jeweils für bestimmte Aspekte <strong>der</strong> Modellierung beson<strong>der</strong>s<br />
geeignet sind.<br />
Der allgemeine Ablauf von Aktivitäten im Großen und Kleinen, wird mit Aktivitätsdiagrammen modelliert.<br />
Zustandsbasiertes Verhalten von Klassen o<strong>der</strong> Komponenten wird mit Zustandsdiagrammen<br />
notiert. Diese ermöglichen Simulation und die Generierung ausführbarer Codes. Eine spezielle Form<br />
sind Protokoll-Zustandsdiagramme. Zu den Interaktionsdiagrammen zählen Sequenzdiagramme,<br />
Kommunikationsdiagramme, Interaktionsübersichtsdiagramme und Timingdiagramme. Sequenzdiagramme<br />
bilden die zeitliche Abfolge des Nachrichtenaustausches zwischen Instanzen ab. Sie können<br />
auch sehr gut zur Darstellung von Interprozess- o<strong>der</strong> Intertask-Kommunikation genutzt werden.<br />
Kommunikationsdiagramme stellen ebenfalls den Nachrichtenaustausch zwischen Instanzen dar.<br />
Sie fokussieren auf die strukturellen Zusammenhänge zwischen den Instanzen. Interaktionsübersichtsdiagramme<br />
fassen mehrere Sequenzdiagramme in Form eines Kontrollflusses zusammen.<br />
Damit können komplexe Abläufe übersichtlich dargestellt werden. Timing-Diagramme sind eine Form<br />
von Interaktionsdiagrammen, um das Auftreten von Nachrichten im Zusammenhang mit den Zustand<br />
einer Instanz und <strong>der</strong> genauen Zeit darzustellen.<br />
Kooperationen<br />
Typischerweise ar<strong>bei</strong>ten mehrere Entitäten des Systems zusammen, um ein bestimmtes Verhalten<br />
zu realisieren. Um eine solche Kooperation zu beschreiben, muss die Struktur zwischen den beteiligten<br />
Entitäten sowie die Kommunikationsmuster beschrieben werden. Dazu verwendet man interne<br />
Strukturdiagramme und Interaktionsdiagramme. Die Diagramme werden dann in einer „Collaboration“<br />
zusammengefasst. Collaborations werden auch für die allgemeine Beschreibung von Design<br />
Patterns verwendet.<br />
v1.0 Seite 23 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Implementierung<br />
Bedeutung und Darstellung <strong>der</strong> Implementierungsaspekte<br />
10<br />
Die Implementierungssicht beschreibt die Gruppierung <strong>der</strong> Designelemente wie Klassen und Komponenten<br />
in Pakete sowie <strong>der</strong>en Implementierung durch Artefakte. Die Aufteilung <strong>der</strong> Elemente in<br />
Pakete erfolgt da<strong>bei</strong> zum einen auf Basis <strong>der</strong> Abhängigkeiten zwischen den Elementen und zum an<strong>der</strong>en<br />
aus Sicht von organisatorischen Aspekten. Zur Darstellung <strong>der</strong> Gruppierung von Elementen in<br />
Pakete sowie <strong>der</strong>en Abhängigkeiten werden UML Paketdiagramme verwendet. Artefakte werden mit<br />
einer Abhängigkeit zu den Designelementen versehen, welche sie repräsentieren<br />
Die Festlegungen dieser Sicht bestimmt auch, in welchen Einheiten die Bestandteile des Systems in<br />
einem Konfigurationsmanagementwerkzeug abgelegt werden.<br />
v1.0 Seite 24 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Infrastruktur und Verteilung<br />
Bedeutung und Darstellung <strong>der</strong> Systeminfrastruktur<br />
und <strong>der</strong> Verteilung <strong>der</strong> Artefakte<br />
auf die Infrastruktur<br />
10<br />
Bei verteilten Systemen ist die explizite Darstellung <strong>der</strong> Infrastruktur von Bedeutung. Aufbauend auf<br />
<strong>der</strong> Infrastrukturdarstellung wird notiert, wie die Artefakte des Systems auf die Bestandteile <strong>der</strong> Infrastruktur<br />
verteilt werden. Zudem können die Abhängigkeiten zwischen den Artefakten eingezeichnet<br />
werden. Infrastruktur und Verteilung werden mit Verteilungsdiagrammen abgebildet. Die Infrastruktur<br />
besteht aus Knoten, die über Kommunikationspfade verbunden sind. Ausführungsumgebungen sind<br />
spezielle Knoten, die eine Umgebung bereitstellen, um einen bestimmten Typ von Komponenten<br />
auszuführen.<br />
Komponentenverteilungsdiagramme sind eine erweiterte Form von Verteilungsdiagrammen. Diese<br />
<strong>bei</strong>nhalten zusätzlich Spezifikationen, welche die Ausführungsparameter <strong>der</strong> Komponentenartefakte<br />
angeben.<br />
v1.0 Seite 25 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Informationsfluss und Daten<br />
Bedeutung und Darstellung von Informationsflüssen<br />
und Daten<br />
10<br />
In stark datengetriebenen Systemen sind Datenstrukturen sowie Informationsflüsse explizit zu beschreiben.<br />
In <strong>der</strong> Systemkontextsicht können da<strong>bei</strong> die Informationsflüsse zwischen dem System<br />
und seiner Umgebung eingezeichnet werden. In den Diagrammen <strong>der</strong> Designsicht können systeminterne<br />
Informationsflüsse abgebildet werden. Die UML bietet für Informationen und Informationsflüsse<br />
ein explizites Konstrukt an. Die Datenstrukturen werden in Form von UML-Datentypen beschrieben.<br />
Der Zusammenhang zwischen Informationen und Daten kann über Repräsentationsbeziehungen<br />
hergestellt werden.<br />
v1.0 Seite 26 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Architekturkonzepte 260<br />
Die Themen einer Architekturdefinition sind vielfältig. Sie reichen von <strong>der</strong> Auswahl des<br />
Architekturstils über die Betrachtung <strong>der</strong> einzelnen Merkmale einer Architektur bis hin<br />
zur Einbettung <strong>der</strong> Architektur in die Rahmenbedingungen eines Projekts, Unternehmens<br />
o<strong>der</strong> Teams. Dieses Kapitel behandelt die skizzierten Themen im Detail und gibt<br />
Hilfen <strong>bei</strong> <strong>der</strong> Entscheidungsfindung zum Erstellen von <strong>Software</strong>-Architektur.<br />
Motivation<br />
Rahmenbedingungen und Entscheidungsfindung<br />
15<br />
Die zu entwerfende Architektur ist im Kontext ihrer Rahmenbedingungen zu betrachten: Welche Erfahrungen<br />
liegen im Unternehmen, dem Team o<strong>der</strong> einem vergleichbaren Projekt vor? Können/sollen<br />
die dort erar<strong>bei</strong>teten Ergebnisse konzeptuell o<strong>der</strong> auf Basis fertiger <strong>Software</strong>komponenten<br />
wie<strong>der</strong>verwendet werden? Wird die Architektur für ein o<strong>der</strong> mehrere Projekte entworfen?<br />
Wie ein roter Faden zieht sich eine Rahmenbedingung durch den gesamten Entwurf einer Architektur:<br />
Das Treffen von Entscheidungen. Im Rahmen einer Architekturspezifikation steht <strong>der</strong> Professional<br />
for <strong>Software</strong> Architecture wie<strong>der</strong>holt vor <strong>der</strong> Frage, welche Anfor<strong>der</strong>ungen vorrangig vor an<strong>der</strong>en<br />
zu behandeln sind und wie Wi<strong>der</strong>sprüche zwischen mehreren Anfor<strong>der</strong>ungen aufgelöst werden. Das<br />
Vermögen solche Entscheidungen vorzubereiten, forcieren und treffen zu können, zählt zu einer <strong>der</strong><br />
wesentlichen Fähigkeiten eines Professional for <strong>Software</strong> Architecture.<br />
v1.0 Seite 27 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Auswahl an Stilen<br />
Was ist <strong>bei</strong> <strong>der</strong> Erstellung einer Architektur<br />
zu beachten?<br />
Wie kann vorgegangen werden?<br />
45<br />
Fachliche und technische Rahmenbedingungen sowie das politische und organisatorische Projektumfeld<br />
prägen den Architekturstil.<br />
Welche Art von Anwendung soll entworfen werden? Ein hostbasiertes System, eine Client-Server-<br />
Anwendung, ein Embedded-System, eine plattformübergreifende Anwendung?<br />
Welche Rolle spielt die Wie<strong>der</strong>verwendung des Ergebnisses? Können vorhandene Ergebnisse wie<strong>der</strong>verwendet<br />
werden?<br />
Die Summe <strong>der</strong> Antworten auf diese Fragen führt dazu,<br />
• eine Teamaufteilung zu finden<br />
• die Anwendungen in Schichten (Layering) zu entwerfen<br />
• bestehende Komponenten/Systeme zwecks Wie<strong>der</strong>verwendung zu kapseln<br />
• das System auf mehrere logische/physische Plattformen, z. B. als Client/Server-Systeme zu verteilen<br />
• eine Fat-, Thin- o<strong>der</strong> Ultra-Thin-Client-Architektur zu wählen<br />
• die Entwicklungsergebnisse von Hand zu erstellen o<strong>der</strong> teilweise bzw. vollständig zu generieren<br />
Eine Grundlage dieser Entscheidungen bilden bereits erprobte Designmuster und Architekturstile.<br />
Deren Beschreibung folgt einer klaren Definition. Schichtenbildung auf Basis von Themengebieten<br />
ermöglicht auch <strong>bei</strong> großen Systemen, Komplexität zu beherrschen. Sowohl innerhalb <strong>der</strong> Themen<br />
als auch an <strong>der</strong>en Schnittstellen untereinan<strong>der</strong> werden Designmuster und Architekturstile eingesetzt.<br />
Als Komponente wird typischerweise eine in sich schlüssige entwe<strong>der</strong> allein ablauffähige o<strong>der</strong> durch<br />
an<strong>der</strong>e <strong>Software</strong>einheiten verwendbare <strong>Software</strong>einheit bezeichnet. Komponentenbildung ermöglicht<br />
im Idealfall das „Zusammenstecken“ von Anwendungen, wo<strong>bei</strong> Einzelteile bedarfsgerecht ausgetauscht<br />
werden können.<br />
Kapselung ermöglicht das Verstecken von Details und macht ebenfalls Komplexität beherrschbar.<br />
Die Prinzipien <strong>der</strong> Objektorientierung för<strong>der</strong>n dieses Vorgehen.<br />
Aufgrund verschiedener Anfor<strong>der</strong>ungen ist es erfor<strong>der</strong>lich, Systeme zu verteilen. Dies kann im einfachsten<br />
Falle nur logisch erfolgen und dient wie<strong>der</strong>um <strong>der</strong> Komplexitätsbeherrschung. Typischerweise<br />
wird eine Verteilung auch physisch vollzogen. Logische und physische Verteilung müssen<br />
nicht identisch sein.<br />
Fat-Client bezeichnet eine Architektur, in <strong>der</strong> <strong>der</strong> Rechner des Anwen<strong>der</strong>s die Hauptlast trägt. Beim<br />
Thin-Client sind diese Aufgaben auf einen o<strong>der</strong> mehrere leistungsstarke Server verteilt. Ultra-Thin-<br />
Clients geben auch noch einen Teil <strong>der</strong> Präsentationslogik an den Server ab.<br />
Mittels Generierungstechniken ist es möglich, viele sich wie<strong>der</strong>holende o<strong>der</strong> systematische Implementierungen<br />
automatisch zu erstellen. Konzepte wie Model Driven Architecture führen <strong>der</strong>zeit zu<br />
einem konsolidierten Vorgehen in diesem Bereich.<br />
v1.0 Seite 28 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Themenbereiche<br />
Welche Themen muss/soll eine <strong>Software</strong>-<br />
Architektur adressieren?<br />
75<br />
Nach Festlegung <strong>der</strong> Rahmenentscheidungen für die Architektur, folgt die Detailbetrachtung <strong>der</strong> Einzelthemen.<br />
Achtung: Auch wenn diese Aussage ein „Wasserfall-Vorgehen“ assoziiert, so ist das<br />
Vorgehen iterativ. Abstraktionsniveaus werden regelmäßig während <strong>der</strong> Architekturerstellung gewechselt,<br />
gröbere Themenbereiche verfeinert, Details abstrahiert, Teillösungen realisiert.<br />
Aktuelle Anwendungssysteme müssen eine Vielzahl <strong>der</strong> folgenden Themenbereiche berücksichtigen.<br />
Es ist immer die Entscheidung zu treffen, „Kann bzw. will ich diese Funktionalität einkaufen o-<br />
<strong>der</strong> ist diese selbständig zu entwerfen?“. Auch <strong>bei</strong> gekauften Funktionalitäten sind Architektur-<br />
Entscheidungen zu treffen.<br />
Die häufigsten zu adressierenden Themen sind:<br />
• Benutzeroberfläche<br />
• Datenhaltung<br />
• Infrastruktur, Verteilung/Netzwerk<br />
• Zugriffssicherheit/Security<br />
• Transaktionen<br />
• Rahmenbedingungen durch Betriebssystem, Hardware, Implementierungssprache (Impedance<br />
Mismatch)<br />
• Workflow<br />
• Fehlerbehandlung<br />
• Berücksichtigung vorhandener Lösungen und Bibliotheken<br />
In allen Bereichen haben sich eine Vielzahl von Lösungsmustern (Patterns) etabliert und bewährt.<br />
Neben diesen Themen sind allgemeine Festlegungen zu treffen wie:<br />
• In welcher Form erhält ein Entwickler Vorgaben? Papier o<strong>der</strong> Generator?<br />
• Sollen regelmäßige Reviews stattfinden, die sicherstellen, dass Architekturvorgaben eingehalten<br />
wurden?<br />
• Wie fließen neue Ideen ein? Wann? Wie oft?<br />
Die Testbarkeit <strong>der</strong> Architektur ist frühzeitig zu berücksichtigen. Im Idealfall kann <strong>der</strong> Test automatisiert<br />
werden. Abstimmung mit dem Testteam ist notwendig.<br />
Welche Entscheidung in dem jeweiligen Bereich getroffen wird, hängt insbeson<strong>der</strong>e mit dem Zusammenspiel<br />
<strong>der</strong> an<strong>der</strong>en Bereiche zusammen.<br />
v1.0 Seite 29 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Klassifizierung und Typisierung<br />
Dimensionen und Typen 65<br />
Dimensionen von <strong>Software</strong>systemen<br />
<strong>Software</strong>systeme lassen sich entlang verschiedener, orthogonaler Dimensionen klassifizieren. Dazu<br />
gehören einerseits die logischen Dimensionen Funktionalität und Kontrolle und an<strong>der</strong>erseits die physischen<br />
Dimensionen Verteilung und Mobilität. Eine <strong>der</strong>artige Klassifizierung des Systems hat natürlich<br />
direkten Einfluß auf die <strong>Software</strong>-Architektur.<br />
Die logischen Dimensionen Funktionalität und Kontrolle sind orthogonal zueinan<strong>der</strong>, d. h. zur Beherrschung<br />
<strong>der</strong> Komplexität ist es naheliegend, <strong>bei</strong>de im Rahmen <strong>der</strong> <strong>Software</strong>-Architektur explizit<br />
zu trennen. Unter Kontrolle werden alle Systemeigenschaften verstanden, die nicht direkt aus fachlichen<br />
Anfor<strong>der</strong>ungen resultieren. In objektorientierten Programmiersprachen läßt sich die Kontrolldimension<br />
über Exceptions abbilden. In UML 2.0 gibt es das allgemeinere Konzept <strong>der</strong> getypten Ports.<br />
Verteilung und Mobilität sind weitere orthogonale Dimensionen. Mobilität bezeichnet die dynamische,<br />
physische Verlagerung von Komponenten zur Laufzeit. Eine Methode zur Implementierung <strong>der</strong> Mobilität<br />
ist die Persistenz.<br />
Die beschriebenen Dimensionen können sowohl auf die gesamte <strong>Software</strong>-Architektur als auch auf<br />
einzelne Subsysteme bezogen werden. Da<strong>bei</strong> kann die Klassifizierung entlang <strong>der</strong> Dimensionen auf<br />
verschiedenen Hierarchie- o<strong>der</strong> Abstraktionsebenen verschieden ausfallen.<br />
Die Dimensionen sowie dazu querschnittliche Probleme wie Konfigurierbarkeit und Dynamik haben<br />
entsprechende Auswirkungen auf die <strong>Software</strong>-Architektur.<br />
Typen von <strong>Software</strong>systemen<br />
<strong>Software</strong>systeme lassen sich zudem nach folgenden grundsätzlichen Typen klassifizieren:<br />
• Bei datenorientierten Systemen steht die Bear<strong>bei</strong>tung von größeren und/o<strong>der</strong> komplex strukturierten<br />
Datenmengen im Zentrum.<br />
• Bei ereignisorientierten Systemen steht die Reaktion des Systems auf Ereignisse und/o<strong>der</strong> die<br />
Kommunikation von Systemteilen über Ereignisse im Mittelpunkt.<br />
Die obigen Aspekte treten häufig gemischt bzw. gleichzeitig auf. Die <strong>Software</strong>-Architektur muss die<br />
vorkommenden Typen geeignet unterstützen. Der Typ des Systems hat auch Einfluss auf die Auswahl<br />
<strong>der</strong> Technologen und Werkzeuge.<br />
v1.0 Seite 30 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Bewertung<br />
Wie wäge ich meine Architekturentscheidungen<br />
ab?<br />
60<br />
Eine Architektur zu definieren ist, das Finden des „besseren Übels“. Ähnlich wie <strong>bei</strong> <strong>der</strong> Erstellung<br />
eines fachlichen Modells gibt es Wi<strong>der</strong>sprüche zwischen Anfor<strong>der</strong>ungen. Wo sich in diesem Falle<br />
Anwen<strong>der</strong> (Stakehol<strong>der</strong>) noch relativ einfach einigen können, da sie sich in ihrer Domäne befinden<br />
und damit eine Entscheidung gut abwägen können, ist diese Kompromissfindung im Rahmen <strong>der</strong><br />
Architekturerstellung sehr viel schwieriger. Die Lösung einer Anfor<strong>der</strong>ung kann <strong>der</strong> an<strong>der</strong>en zunächst<br />
wi<strong>der</strong>sprechen. Ein geeigneter Kompromiss ist zu finden.<br />
Hier werden die noch offenen Fragen „Wie wäge ich meine Architekturentscheidungen ab? Welche<br />
Kriterien gibt es? Wie viel Zeit sollte ich wann verwenden? Wann ist eine Architektur gut, wann richtig?“<br />
geklärt.<br />
Die Priorisierung von Anfor<strong>der</strong>ungen hilft das Wichtige vom weniger Wichtigen zu trennen. Nicht das<br />
Thema, das für den Professional for <strong>Software</strong> Architecture spannend ist, ist das wichtigste, son<strong>der</strong>n<br />
das, das dem Anwen<strong>der</strong> am meisten <strong>bei</strong> seiner Lösung hilft und wofür er zu zahlen bereit ist.<br />
Die meisten Entscheidungen können nicht auf dem Papier getroffen werden. Das Vorgehen des<br />
„Durchstichs“ (Proof of concept) hat sich bewährt. Die entscheidende Frage, „was muss gehen, damit<br />
die Architektur funktioniert?“ wird geklärt. Mit (verhältnismäßig) wenig Aufwand wird eine hohe<br />
Sicherheit für die weitere Ar<strong>bei</strong>t erzielt.<br />
Der Professional for <strong>Software</strong> Architecture for<strong>der</strong>t die Stakehol<strong>der</strong> auf, die Vielzahl von Anfor<strong>der</strong>ungen<br />
zu priorisieren. Am Ende einer Iteration steht ein lauffähiges System o<strong>der</strong> zumindest ein Durchstich<br />
mit diesen Funktionen.<br />
Beim Abwägen mehrerer Lösungen klärt <strong>der</strong> Professional for <strong>Software</strong> Architecture die Fragen:<br />
• Kann damit die Anfor<strong>der</strong>ung erfüllt werden?<br />
• In welchem Maße?<br />
• Zeichnet sich eine Lösung beson<strong>der</strong>s aus?<br />
• Wie zukunftssicher ist die Lösung?<br />
• Welche Folgen hat die Lösung?<br />
• Sind für die Stakehol<strong>der</strong> die Folgen nützlich/unwichtig/unakzeptabel?<br />
v1.0 Seite 31 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Prozesse 70<br />
In diesem Kapitel wird die Rolle von <strong>Software</strong>-Architektur in unterschiedlichen <strong>Software</strong>entwicklungsprozessen<br />
genauer betrachtet.<br />
Überblick<br />
Prozesse und die Einordnung von Architektur;<br />
Spezielle Prozesse: RUP, V-Modell,<br />
XP<br />
5<br />
In <strong>der</strong> <strong>Software</strong>entwicklung gibt es keinen allgemeingültigen Prozess, <strong>der</strong> in allen Bereichen Anwendung<br />
findet. Vielmehr gibt es eine Menge unterschiedlicher Prozesse, die von verschiedenen Gruppierungen<br />
entworfen sind. Zu den Gruppierungen gehören öffentliche Einrichtungen, Unternehmen,<br />
aber auch unabhängige Strömungen in <strong>der</strong> <strong>Software</strong>gemeinde, die von einzelnen Personen getrieben<br />
werden. Die Prozesse verfolgen teilweise völlig unterschiedliche Ideologien.<br />
Bekannte Prozesse sind das V-Modell, <strong>der</strong> RUP sowie agile Prozesse mit XP als bekanntesten Vertreter.<br />
In allen Prozessen spielt die <strong>Software</strong>-Architektur eine Rolle, die je nach Prozess jedoch deutlich unterschiedlich<br />
ausfallen kann.<br />
v1.0 Seite 32 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Rational Unified Process Architektur im RUP 20<br />
Ziel des RUP ist es, ein sehr mächtiges Prozess-Framework zur Verfügung zu stellen, das nach Bedarf<br />
angepasst werden kann. Der RUP beschreibt eine Vielzahl von Rollen, Aktivitäten und Dokumente,<br />
die für die verschiedenen Bereiche des Entwicklungsprozesses sinnvoll sind. Zudem werden<br />
„Best Practices“ für den Einsatz dieser Elemente beschrieben. <strong>Software</strong>-Architektur und damit <strong>der</strong><br />
Professional for <strong>Software</strong> Architecture nimmt eine zentrale Rolle innerhalb des RUP ein.<br />
Profil eines Professional for <strong>Software</strong> Architecture n:<br />
“The ideal architect should be a person of letters, a mathematician, familiar with historical<br />
studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine,<br />
learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.”<br />
— Vitruvius, circa 25 BC<br />
Der RUP definiert konkrete Eigenschaften und Aufgaben eines Professional for <strong>Software</strong> Architecture.<br />
Er legt fest in welchen Disziplinen <strong>der</strong> <strong>Software</strong>entwicklung <strong>der</strong> Professional for <strong>Software</strong> Architecture<br />
beteiligt ist und für welche Aktivitäten und Artefakte er verantwortlich ist.<br />
Ein Professional for <strong>Software</strong> Architecture ist die treibende Kraft <strong>bei</strong> <strong>der</strong> Systemerstellung. Die wesentliche<br />
Aufgabe des Professional for <strong>Software</strong> Architecture ist es, eine Folge von suboptimalen<br />
Entscheidungen <strong>bei</strong> unvollständigem Wissen zu treffen. Architekturverantwortung ist eine Vollzeitbeschäftigung.<br />
Deshalb sollte es eine Person geben, die die Rolle des Professional for <strong>Software</strong> Architecture<br />
ausfüllt.<br />
v1.0 Seite 33 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
V-Modell Architektur im V-Modell 15<br />
Das V-Modell ist neben dem militärischen auch für den gesamten Bereich <strong>der</strong> Bundesverwaltung<br />
verbindlich und wird von vielen Industriefirmen als Hausstandard für <strong>Software</strong>entwicklung verwendet.<br />
Das V-Modell regelt die <strong>Software</strong>bear<strong>bei</strong>tung im Bereich <strong>der</strong> Bundeswehr durch die einheitliche und<br />
verbindliche Vorgabe von Aktivitäten und Produkten(Ergebnissen), die <strong>bei</strong> <strong>der</strong> <strong>Software</strong>erstellung<br />
und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und<br />
technisches Projektmanagement (PM) anfallen.<br />
<strong>Software</strong>-Architektur ist auch im V-Modell ein zentrales Element. Es gibt aber keinen ausgesprochenen<br />
Professional for <strong>Software</strong> Architecture. Die Rolle ist auf an<strong>der</strong>e Rollen verteilt, welche noch zusätzliche<br />
Aufgaben erfüllen. Rollen im V-Modell, die sich mit <strong>Software</strong>-Architektur befassen, sind <strong>der</strong><br />
Systemdesigner sowie <strong>der</strong> <strong>Software</strong>entwickler.<br />
Es existiert ein Architekturdokument für das Gesamtsystem und eine <strong>Software</strong>-Architektur pro <strong>Software</strong>einheit.<br />
Das V-Modell behandelt Systeme und somit neben <strong>Software</strong> auch Hardware.<br />
v1.0 Seite 34 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Agile Prozesse – XP Architektur in XP 15<br />
Ziel von agilen Prozessen ist die Fokussierung auf die wesentlichen, notwendigen Aktivitäten für ein<br />
konkretes Projekt. Da<strong>bei</strong> sollen übermäßig formale Aktivitäten vermieden werden. Agil bedeutet hier,<br />
dass ein Prozess stets an das konkrete Projektumfeld und an die aktuellen Gegebenheiten angepasst<br />
wird. eXtreme Programming (XP) ist <strong>der</strong> bekannteste Vertreter agiler Prozesse.<br />
XP basiert im Wesentlichen auf dem Gedanken die <strong>Software</strong> so einfach wie möglich zu halten und<br />
auf damit flexible auf weitere bzw. neue Anfor<strong>der</strong>ungen zu reagieren. Da<strong>bei</strong> wird auf herkömmliche<br />
Aktivitäten wie Analyse und Design nicht verzichtet, jedoch werden sie auf ein Minimum reduziert.<br />
Architektur wird <strong>bei</strong> XP nicht explizit hervorgehoben, ist aber auch hier von zentraler Bedeutung. XP<br />
basiert auf einem iterativen Ansatz. Bei <strong>der</strong> ersten Iteration werden eine Reihe von einfachen „basic<br />
stories“ umgesetzt und die dafür notwendigen Elemente formen die Architektur (auch wenn sie nicht<br />
explizit als solche bezeichnet wird). In den weiteren Iterationen werden weitere „stories“ dazu genommen<br />
und damit die Architektur überar<strong>bei</strong>tet. Ziel für die Umsetzung neuer „stories“ ist stets: „the<br />
simplest solution that will work“ (Kent Beck).<br />
v1.0 Seite 35 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Gegenüberstellung<br />
<strong>Software</strong>-Architektur in <strong>Software</strong>prozessen<br />
– Vergleich und Gegenüberstellung<br />
15<br />
Das Architekturthema hat in allen betrachteten Prozessen eine wichtige Rolle. Die Prozesse können<br />
anhand einiger Kriterien, die für das Thema <strong>der</strong> <strong>Software</strong>-Architektur relevant sind, gegenübergestellt<br />
werden. Die gewählten Kriterien sind:<br />
• Machbarkeitsstudie & Risikoanalyse<br />
• Priorisierung <strong>der</strong> Anfor<strong>der</strong>ungen & Iterationsplanung<br />
• Grobkonzept <strong>der</strong> Architektur<br />
• Unterstützung Testrahmen & Testplanung<br />
• Konkretisierung <strong>der</strong> Iterationsplanung<br />
• Än<strong>der</strong>ungsmanagement<br />
• Statusbericht für die Projektleitung erstellen<br />
• Rollen/Artefakte<br />
• Zielgruppe<br />
RUP und V-Modell gelten allgemein eher als schwergewichtige Prozesse. Beide können aber „tailored“<br />
werden, um den Ansprüchen an schlankere Entwicklungsprozesse gerecht zu werden. Die Fokussierung<br />
auf einen iterativen Prozesse und die explizite Rolle eines Professional for <strong>Software</strong> Architecture<br />
lassen den RUP im Vergleich zum V-Modell als geeigneter für aktuelle, komplexe <strong>Software</strong>entwicklungen<br />
erscheinen. XP ist im Gegensatz ein leichtgewichtiger Prozess, <strong>der</strong> wie <strong>der</strong> RUP<br />
auf einem iterativen Ansatz beruht. Architektur wird nicht explizit durch eine bestimmte Rolle in den<br />
Mittelpunkt gestellt durch eine bestimmte Rolle definiert, son<strong>der</strong>n ist Aufgabe verschiedener Rollen<br />
im XP-Prozess. Trotzdem spielt eine gute Architektur (wenn auch an<strong>der</strong>s bezeichnet) eine wichtige<br />
Rolle. Um XP einzusetzen sind einige Voraussetzungen (kleine Teams, Vertrauen, Kommunikationsfähigkeit)<br />
unabdingbar. Wenn diese Voraussetzungen erfüllt sind, dann kann ein weniger formaler<br />
Prozess sehr effizient sein.<br />
v1.0 Seite 36 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Technologien und Werkzeuge 200<br />
In diesem Kapitel werden existierende Technologien und Werkzeuge klassifiziert und<br />
an Beispielen demonstriert. Darüber hinaus werden dem Professional for <strong>Software</strong><br />
Architecture Anhaltspunkte zur Auswahl von geeigneten Technologien und Werkzeuge<br />
an die Hand gegeben.<br />
Technologien Übersicht existieren<strong>der</strong> Technologien 15<br />
Ein wesentlicher technischer Aspekt <strong>der</strong> Entwicklung und gleichzeitig Handwerkszeug <strong>der</strong> Entwickler<br />
sind die einzusetzenden Technologien und Werkzeuge. Der Professional for <strong>Software</strong> Architecture<br />
muss während <strong>der</strong> Erar<strong>bei</strong>tung <strong>der</strong> <strong>Software</strong>-Architektur Entscheidungen treffen, um geeignete<br />
Technologien bzw. Werkzeuge auszuwählen und ungeeignete auszuschließen.<br />
Mit welchen Technologien können <strong>Software</strong>-Architekturen heute gestaltet werden?<br />
• Betriebssysteme<br />
• Programmiersprachen<br />
• Codegenerierung<br />
• Third-party <strong>Software</strong> (Frameworks, Bibliotheken und Komponenten)<br />
• Komponentenmodelle (CORBA, COM, DCOM, J2EE)<br />
• Application Server<br />
v1.0 Seite 37 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Betriebssysteme Aufgaben, Klassifizierung und Beispiel 15<br />
Die zentrale Aufgabe eines Betriebssystems ist die Verwaltung und Steuerung eines Computers und<br />
seiner Ressourcen. Daraus leiten sich die Bereiche Datenverwaltung, Ein-/Ausgabesteuerung, Ablaufsteuerung<br />
und Gewährleistung von Sicherheit und Zugriffsschutz ab.<br />
Betriebssysteme lassen sich entlang folgen<strong>der</strong> Dimensionen klassifizieren:<br />
• Anzahl <strong>der</strong> Prozessoren<br />
• Anzahl <strong>der</strong> Nutzer<br />
• Verteilung<br />
• Art <strong>der</strong> Zielhardware<br />
• Unterstützung spezieller Anfor<strong>der</strong>ungen<br />
Als Entscheidungsgrundlage für den Professional for <strong>Software</strong> Architecture ist es speziell interessant,<br />
dass die Wahl des Betriebssystems gleichzeitig die Auswahl <strong>der</strong> darüber hinaus verwendbaren<br />
Technologien und Werkzeuge einschränkt. Lediglich mit portablen Sprachen, Tools o<strong>der</strong> Technologien<br />
läßt sich diese Einschränkung teilweise aufheben.<br />
v1.0 Seite 38 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Programmiersprachen<br />
Prozedurale, objektorientierte und weitere<br />
Programmiersprachen<br />
20<br />
Bei keiner Technologie werden wohl so erbitterte Auseinan<strong>der</strong>setzungen und „Glaubenskriege“ geführt<br />
wie <strong>bei</strong> den Programmiersprachen, die zur Umsetzung einer Entwicklungsaufgabe ausgewählt<br />
werden. Da<strong>bei</strong> gibt es sowohl Faktoren, die zu einem solchen Streit <strong>bei</strong>tragen, aber auch immer<br />
mehr Faktoren, welche die Bedeutsamkeit von Einzelentscheidungen relativieren.<br />
Die Auswahl einer Programmiersprache sollte somit möglichst pragmatisch und technologieorientiert<br />
erfolgen. Ein guter Anhaltspunkt ist <strong>der</strong> Best-practice-Ansatz: Mit welcher Programmiersprache wurde<br />
in vergleichbaren Projekten gear<strong>bei</strong>tet? Für welche Programmiersprachen sind im Unternehmen<br />
bereits Erfahrungen vorhanden? Was wünscht <strong>der</strong> Kunde?<br />
Die wesentlichen Klassen von Programmiersprachen sind prozedurale Programmiersprachen, objektorientierte<br />
Programmiersprachen, Datenbank-Sprachen und Markup-Sprachen. Zudem gibt es<br />
noch weitere Klassen, wie funktionale, logische, Spezifikations- o<strong>der</strong> deklarative Sprachen. Diese<br />
werden in eng begrenzten, beson<strong>der</strong>en Anwendungsnichen eingesetzt. Jede Klasse von Sprachen<br />
hat ihre typischen Eigenschaften.<br />
Die Auswahl <strong>der</strong> Programmiersprache beeinflußt nicht zwingend den methodischen Ansatz für den<br />
Entwurf <strong>der</strong> <strong>Software</strong>. So kann z. B. <strong>bei</strong>m Einsatz von C die <strong>Software</strong> trotzdem objektorientiert mit<br />
UML entworfen werden.<br />
v1.0 Seite 39 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Codegenerierung Automatische Codegenerierung 20<br />
Generierung ermöglicht die automatische Wie<strong>der</strong>holung einer Entwicklungsleistung. Die positiven<br />
Folgen sind eine beträchtliche Aufwandsreduzierung, eine gleichbleibende Qualität und eine leichte<br />
Erweiterbarkeit bzw. Wartbarkeit. Demgegenüber steht <strong>der</strong> zusätzliche Aufwand, einen geeigneten<br />
Generator zu entwerfen, wozu eine nicht unerhebliche Abstraktionsfähigkeit des Professional for<br />
<strong>Software</strong> Architecture Voraussetzung ist. Gute Generatoren können bis zu 100% des Zielcodes erzeugen.<br />
Die verbleibenden Codeteile werden vom Entwickler manuell ergänzt.<br />
Abhängig vom eingesetzten Generator ist die Grundlage <strong>der</strong> Generierung eine strukturierte Information,<br />
die anhand <strong>der</strong> Regeln des Generators interpretiert wird und zur gewünschten Transformation<br />
führt. Die heute am weitesten verbreitete „strukturierte Information“ ist ein UML-Modell. Da hier das<br />
Modell führt, wird auch häufig von einem modellbasierten Vorgehen o<strong>der</strong> auch vom Visual Modeling<br />
gesprochen.<br />
Wichtige Eigenschaften eines Codegenerators sind dessen Fähigkeiten zu Round-Trip und Reverse<br />
Engineering.<br />
Model Driven Architecture (MDA) ist ein neuer Standard <strong>der</strong> OMG, <strong>der</strong> das modellbasierte Entwikkeln<br />
vorantreiben soll.<br />
v1.0 Seite 40 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Third-Party-<strong>Software</strong><br />
Frameworks, Bibliotheken und Komponenten<br />
30<br />
Für rein prozedurale Sprachen haben sich in <strong>der</strong> Vergangenheit <strong>Software</strong>-Bibliotheken als Technologie<br />
bewährt, um die Wie<strong>der</strong>verwendung von <strong>Software</strong>produkten Dritter in eigenen Projekten zu<br />
ermöglichen. Das Konzept <strong>der</strong> Bibliotheken wird zudem in großen <strong>Software</strong>projekten als Strukturierungsmittel<br />
und als Mittel zur unternehmensweiten Wie<strong>der</strong>verwendung eingesetzt.<br />
In den Bereichen <strong>der</strong> objektorientierten und komponentenbasierten Programmierung kann dieses<br />
Prinzip in wesentlich mächtigerer und vielfältiger Form angewandt werden. Grundsätzlich lassen sich<br />
hier drei Arten <strong>der</strong> Wie<strong>der</strong>verwendung unterscheiden: Komponentenbibliotheken, Klassenbibliotheken<br />
und Frameworks.<br />
Komponentenbibliotheken enthalten Sammlungen von <strong>Software</strong>-Komponenten zur direkten Verwendung<br />
in eigenen Projekten. Komponenten sind Standard-<strong>Software</strong>-Bausteine, die jeweils für sich abgeschlossen<br />
sind und genau definierte externe Schnittstellen haben. Für den Einsatz <strong>der</strong> Komponenten<br />
muss es eine übergeordnete Schnittstellenspezifikation geben. Diese wird unter dem Begriff<br />
„Standard-Plattform“ geführt.<br />
Klassenbibliotheken enthalten eine o<strong>der</strong> mehrere Hierarchien von objektorientierten Klassen und<br />
sind daher an eine bestimmte Programmiersprache gebunden. Die Klassen können in eigenen Projekten<br />
direkt verwendet werden o<strong>der</strong> als Basis für weitere Ableitung dienen.<br />
Frameworks ermöglichen die Wie<strong>der</strong>verwendung für spezifische Anwendungsfel<strong>der</strong>. Die Stärke von<br />
Frameworks ist, dass nicht nur <strong>Software</strong> auf <strong>der</strong> Ebene <strong>der</strong> Implementierung wie<strong>der</strong>verwendet werden<br />
kann, son<strong>der</strong>n auch auf <strong>der</strong> Ebene von Design und <strong>Software</strong>-Architektur (design reuse).<br />
Frameworks gehorchen dem Hollywood-Prinzip: Don’t call us, we call you!<br />
Hausinterne Frameworks und Bibliotheken<br />
Gerade in großen Unternehmen, aber auch in mittleren Entwicklungsabteilungen muss in die Technologieauswahl<br />
auch die bereits existierende <strong>Software</strong> einbezogen werden. Als Mechanismen zur<br />
Wie<strong>der</strong>verwendung bieten sich hier ebenfalls obige Methoden an: Frameworks, Klassenbibliotheken<br />
und Komponenten sind mächtige Mechanismen zur Steigerung von Produktivität und Qualität innerhalb<br />
von Entwicklungsabteilungen und Unternehmen. Natürlich entsteht durch das Aufsetzen dieser<br />
Mechanismen zunächst zusätzlicher Aufwand, <strong>der</strong> erst durch mehrfache Verwendung in späteren<br />
Projekten wie<strong>der</strong> kompensiert wird.<br />
v1.0 Seite 41 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Übergreifende Technologien<br />
Verteilte Komponenten, Standardplattformen,<br />
Application Server, …<br />
25<br />
Seit Anfang <strong>der</strong> neunziger Jahre und bis heute entwickeln sich übergreifende Technologien, welche<br />
die obigen Technologien umfassend kombinieren und dadurch neue Ansätze zur Lösung von <strong>Software</strong>aufgaben<br />
schaffen. Der Professional for <strong>Software</strong> Architecture muss sich mit diesen übergreifenden<br />
Technologien auseinan<strong>der</strong>setzen, da diese teilweise fertige Architekturen für bestimmte Problemklassen<br />
bereitstellen.<br />
Verteilte Komponenten<br />
War COM noch ein rein lokales Komponentenmodell, das die Wie<strong>der</strong>verwendung von <strong>Software</strong>produkten<br />
auf Basis einer binären Standardplattform ermöglichen sollte, ist mit <strong>der</strong> Weiterentwicklung<br />
DCOM <strong>der</strong> Schritt zum verteilten System vollzogen worden. Die Anwendung von COM/DCOM ist im<br />
Wesentlichen auf Windows-Plattformen beschränkt. Eine Alternative zum verteilten Komponentenmodell<br />
DCOM ist die plattformunabhängige CORBA-Architektur.<br />
Mit <strong>der</strong> Etablierung des Internets in <strong>der</strong> zweiten Hälfte <strong>der</strong> neunziger Jahre konnte sich das Kommunikationsprotokoll<br />
HTTP zwischen Browser und Webserver so etablieren, dass es als eine viel allgemeinere<br />
Kommunikationsplattform als <strong>bei</strong> COM und CORBA verwendet werden kann. Eingebettet<br />
in HTTP haben sich bis heute eine Vielzahl von Protokollen und Schnittstellenspezifikationen entwikkelt,<br />
die zur Kommunikation zwischen verteilten Komponenten benutzt werden.<br />
Standard-Plattformen<br />
Durch die technische Möglichkeit und fachliche Notwendigkeit, im Rahmen des Internets bzw. Intranets<br />
Applikationslogik auf Browser und Webserver zu verteilen, müssen geeignete Technologien<br />
vielfältigen Aufgaben lösen. Im Wesentlichen sind zwei Technologie-Plattformen für diese Aufgaben<br />
verfügbar:<br />
J2EE (Java 2 Enterprise Edition). Hier<strong>bei</strong> handelt es sich um eine Sammlung von Spezifikationen,<br />
auf <strong>der</strong>en Grundlage <strong>Software</strong>produkte entwickelt werden können. Der Schwerpunkt liegt da<strong>bei</strong><br />
auf Internetapplikationen. J2EE-kompatible Application Server bilden das Rückgrat <strong>der</strong> Technologie.<br />
Komponenten kommunizieren über eine Vielzahl von Protokollen und Schnittstellenspezifikationen,<br />
z. B. HTML, XML, TCP/IP, HTTP, SSL, RMI etc. Speziell ist zu betonen, dass J2EE<br />
eine zwar von Sun Microsystems vorgeschlagene, aber dennoch herstellerunabhängige Spezifikation<br />
darstellt.<br />
Microsoft .NET. Dies ist eine Plattform für die Entwicklung und Ausführung von verteilten Anwendungen.<br />
Wie <strong>bei</strong> J2EE liegt <strong>der</strong> Schwerpunkt auf Internetapplikationen. Im Zentrum von .NET<br />
steht das .NET Framework. Dieses wird unterstützt bzw. ergänzt vom Betriebssystem (zunächst<br />
nur die Windows-Varianten für Desktop, Server, mobile Plattformen), vom .NET Enterprise Server,<br />
von den .NET Building Block Services und schließlich von Visual Studio .NET, einer integrierten<br />
Entwicklungsumgebung. Alle erwähnten Bestandteile werden zunächst in Form von<br />
Microsoft-Produkten angeboten.<br />
v1.0 Seite 42 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Technologie-Auswahl<br />
Wie finde ich die richtige Technologie für<br />
mein Projekt bzw. Unternehmen?<br />
25<br />
Die wichtigste Aufgabe des Professional for <strong>Software</strong> Architecture ist es, in Zusammenar<strong>bei</strong>t mit<br />
dem Analyse-Team einen konsistenten Satz von Anfor<strong>der</strong>ungen herauszuar<strong>bei</strong>ten und daraus<br />
schließlich eine tragfähige <strong>Software</strong>-Architektur abzuleiten. Die zu erstellende <strong>Software</strong>-Architektur<br />
besteht zwar zu einem großen Teil auf Konzepten und Modellen, muss jedoch immer auf einer Auswahl<br />
von existierenden Technologien basieren. Diese Auswahl muss <strong>der</strong> Professional for <strong>Software</strong><br />
Architecture aufgrund seiner Erfahrung treffen. Dazu gehört sowohl die Vertrautheit mit grundlegenden<br />
Technologien als auch die Fähigkeit, sich neue Technologien zu erschließen.<br />
Faktoren, welche die Auswahlentscheidung beeinflussen sind technische Anfor<strong>der</strong>ungen, Produktund<br />
Systemfaktoren sowie organisatorische und politische Faktoren. Die übliche Konzentration auf<br />
technische Faktoren reicht <strong>bei</strong> weitem nicht aus.<br />
Als Anhaltspunkt empfiehlt es sich, vor <strong>der</strong> Festlegung auf bestimmte Technologien die folgenden<br />
Fragen zu beantworten und die Antworten samt daraus resultierenden Entscheidungen in Form eines<br />
Dokuments festzuhalten.<br />
1. Welche Technologien sind dem Entwicklerteam bereits bekannt bzw. haben sich im praktischen<br />
Einsatz in <strong>der</strong> Vergangenheit bewährt?<br />
2. Welche Technologien werden <strong>bei</strong> ähnlichen Projekten von an<strong>der</strong>en Unternehmen bzw. für an<strong>der</strong>e<br />
Kunden üblicherweise eingesetzt?<br />
3. Gibt es Wi<strong>der</strong>sprüche zwischen bestimmten Technologien und den Anfor<strong>der</strong>ungen?<br />
4. Welche Technologien können neu eingeführt werden, um die Tragfähigkeit <strong>der</strong> <strong>Software</strong>-<br />
Architektur für das aktuelle Projekt, aber auch für zukünftige Projekte zu verbessern?<br />
Die Maxime: „Generalisieren statt wie<strong>der</strong>holen“ spielt auch <strong>bei</strong> <strong>der</strong> Technologieauswahl eine entscheidende<br />
Rolle. Die Aufgabe <strong>der</strong> Identifikation von Synergieeffekten zwischen Projekten kann <strong>der</strong><br />
Professional for <strong>Software</strong> Architecture von seinem übergeordneten Standpunkt aus am besten erfüllen.<br />
v1.0 Seite 43 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Werkzeuge<br />
Entwicklungsumgebungen, Frameworks,<br />
Codegeneratoren, etc.<br />
40<br />
Der Einsatz geeigneter Werkzeuge ist eng mit <strong>der</strong> Auswahl von Technologien verknüpft. Kategorien<br />
von Entwicklungswerkzeugen sind:<br />
• Entwicklungsumgebungen<br />
• CASE-Tools und Codegeneratoren<br />
• Frameworks<br />
• Application Server<br />
• Statische und dynamische Analysetools<br />
• Simulatoren/Emulatoren<br />
• Versionsverwaltung/Konfigurationsmanagement<br />
• Testwerkzeuge<br />
• Installationstools<br />
• Sonstiges (Datei/Verzeichnisvergleich, Automatisierung über Skriptsprachen, etc.)<br />
Entwicklungsumgebungen (IDE) sind Tools, welche typische Tätigkeiten <strong>der</strong> <strong>Software</strong>-Entwicklung<br />
wie Design, Implementierung sowie Fehlersuche und -behebung unterstützen.<br />
CASE-Tools (Computer Aided <strong>Software</strong> Engineering) ermöglichen die graphische Modellierung von<br />
<strong>Software</strong>-Systemen. Ein Codegenerator kann nachgeschaltet werden.<br />
Frameworks wurden bereits im entsprechenden Abschnitt unter „Technologien“ ausführlich beschrieben.<br />
Da diese entwe<strong>der</strong> durch Werkzeuge unterstützt werden bzw. selbst als Entwicklungswerkzeuge<br />
bezeichnet werden können, wird das Thema hier nochmals aufgegriffen.<br />
Application Server kommen im Rahmen <strong>der</strong> Standard-Plattformen J2EE und .NET zum Einsatz. Für<br />
.NET bietet Microsoft den .NET Enterprise Server an. Für J2EE gibt es mehrere Produkte, <strong>der</strong>en<br />
Funktionalität durch die J2EE-Spezifikation definiert ist.<br />
Testen ist ein prinzipiell unvollständiger Weg, um Fehler in <strong>Software</strong> auszuschließen. Wirksamer ist<br />
die formale Analyse des Sourcecodes (statische Analyse) o<strong>der</strong> die Analyse während des Programmlaufs<br />
(dynamische Analyse). Es gibt eine Vielzahl von Analysetools, die sich hinsichtlich ihres Anwendungsgebiets<br />
(statisch/dynamisch) und hinsichtlich <strong>der</strong> nötigen Ausbildung des Anwen<strong>der</strong>s unterscheiden.<br />
Simulatoren ermöglichen die Ausführung von <strong>Software</strong> auf <strong>der</strong> Entwicklungsplattform, im Gegensatz<br />
zur späteren Ausführung <strong>der</strong> <strong>Software</strong> auf <strong>der</strong> Zielplattform. Emulatoren gehen einen Schritt weiter<br />
und ermöglichen die Ausführung <strong>der</strong> <strong>Software</strong> unter Einhaltung sämtlicher relevanter Randbedingungen.<br />
<strong>Software</strong>-Konfigurationsmanagement ist die Disziplin <strong>der</strong> Verfolgung und Steuerung <strong>der</strong> Evolution<br />
von <strong>Software</strong>. Eine wichtige Aufgabe des CM ist die Versionsverwaltung. Weiterhin wird von CM-<br />
Tools die Än<strong>der</strong>ungsverfolgung, Komposition von Applikationen, Dokumentenverwaltung und nicht<br />
zuletzt Prozessunterstützung erwartet. Zusätzliche Bereiche sind <strong>Software</strong>-Metrik-Tools und Bug-<br />
Tracking-Systeme.<br />
Installationstools erlauben die Erstellung von Installationsversionen von <strong>Software</strong>-Releases. Neben<br />
einfachen Archivierungs- und Kompressionsfunktionen werden z. B. die dialogbasierte Interaktion<br />
mit dem Benutzer o<strong>der</strong> die Aufbereitung von Releases für Internet-Download unterstützt.<br />
v1.0 Seite 44 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Werkzeug-Auswahl<br />
Wie finde ich die richtigen Werkzeuge für<br />
mein Projekt bzw. Unternehmen?<br />
10<br />
Zur Auswahl geeigneter Werkzeuge gelten zunächst die Überlegungen, die weiter oben für die Auswahl<br />
von Technologien aufgestellt wurden. Die Ansatzpunkte zur Auswahl von Werkzeugen finden<br />
sich in Randbedingungen durch das Umfeld, Best-Practice-Erfahrungen sowie in <strong>der</strong> Informationsbeschaffung<br />
bzgl. Leistungsfähigkeit, Ausgereiftheit, Anbieter, Kosten, etc.<br />
Gerade für den Punkt Informationsbeschaffung empfiehlt es sich für den Professional for <strong>Software</strong><br />
Architecture durch kontinuierliches Sichten von Fachliteratur auf einem zwar abstrakten, doch stets<br />
überblickhaften Wissensstand zu bleiben.<br />
v1.0 Seite 45 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Abschluss und Ausblick 30<br />
Zusammenfassung und Diskussion <strong>der</strong> Schulung.<br />
Besprechung <strong>der</strong> Prüfung zum Certified Professional for <strong>Software</strong> Architecture.<br />
Bin ich jetzt Professional for <strong>Software</strong> Architecture? Wie gehe ich aufbauend auf den<br />
Certified Professional for <strong>Software</strong> Architecture vor?<br />
Ausblick: Wie geht es weiter? Was kommt nach dem Foundation Level?<br />
v1.0 Seite 46 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung