erni essentials SOFTWARE ENGINEERING - erni-consultants.com

software engineering 1
erni essentiaLs
SOFTWARE ENGINEERING

enables & delivers
oLiVer bLindebaCher
architektur@erni.ch
business Unit Leader
bei erni schweiz ag
VORWORT
Die Abhängigkeit der Gesellschaft von IT-
Systemen und deren Prozessunterstützung ist
enorm und steigt stetig an. Dies macht das
Konzipieren und Realisieren von IT-Systemen
zu einem verantwortungsvollen Auftrag.
Dieser Auftrag kann nur erfüllt werden,
wenn Systemarchitekturen einem Prozess
folgend und nach festen Prinzipien konzipiert
werden. Der Schlüssel zum Erfolg in der
Systementwicklung liegt in der interdisziplinären
Zusammenarbeit, in der alle Aspekte
eines Zielsystems berücksichtigt werden und
eine adäquate Lösung konstruiert wird.
Dieses ERNI Essential zeigt auf, wie die
Komplexität in der Konzeption und Realisierung
von IT-Systemen und den übergeordneten
Strategien durch einen Architekturprozess
sowie ausgewählte Prinzipien
und Methoden reduziert und beherrschbar
gemacht wird. Basierend auf unserer
Erfahrung haben wir aus der Vielfalt von
Theorien und Literatur eine systematische,
kompakte und pragmatische Referenz für
Architektur, Design und Implementation
von Software zusammengestellt, die unabhängig
von Technologien und Tools in Projekten
und Organisationen anwendbar ist.
erni – innovation in Process and technology
software engineering 3
1. EINFühRuNG 5
2. ARchITEkTuRbEGRIFF 7
2.1 architektur ist ein Kompromiss 8
2.2 Qualitätsattribute 9
2.3 architektenrolle 10
3. ARchITEkTuRdImENSIONEN 13
3.1 ebenen 14
3.2 standpunkte 16
3.3 aspekte 20
3.4 sichten 24
4. ARchITEkTuRpATTERNS 29
5. ARchITEkTuRENTWuRF 33
5.1 Prozessschritte 34
5.2 architekturdokumentation 36
5.3 Cartoon 38
6. ARchITEkTuRbEWERTuNG 41
7. dESIGNpRINzIpIEN 47
8. dESIGNpATTERNS 53
8.1 Layering 55
8.2 Model-View-Controller 56
8.3 facade 58
9. ImplEmENTATION 61
9.1 refactoring 63
9.2 Unit-tests 64
10. mEThOdEN FüR dIE umSETzuNG 69
11. bEGRIFFE/GlOSSAR 75
12. REFERENzEN 79

1. EINFühRuNG
software engineering 5
Der Entwurf von Softwaresystemen lässt sich grob in die Disziplinen
Requirements Engineering, Architektur, Design, Implementation
und Testen unterteilen. Das ERNI Essential «Software
Engineering» beschäftigt sich dabei mit den drei Disziplinen
Architektur, Design und Implementation. Für die Disziplinen
Requirements Engineering und Testen verweisen wir auf die
ERNI Essentials «Requirements Engineering» und «Testmanagement».
Im Prozess zur Entwicklung einer Software oder eines Systems
bewegt man sich im Laufe eines Projekts von einem abstrakten
Lösungsansatz zu einer konkreten Lösung. Über die Disziplinen
hinweg wird die Lösung durch die einzelnen Teams und Personen
definiert und geformt. Dieses ERNI Essential folgt diesem
Ansatz und zeigt die verschiedenen Schritte des Entwicklungsprozesses
mit ausgewählten Beispielen zu Methoden, Prinzipien
und Vorgehensweisen auf. Dabei wurden diejenigen Beispiele
ausgewählt, die universell nutzbar sind und sich nicht auf eine
bestimmte Technologie oder Domäne beschränken. Das vorliegende
ERNI Essential folgt im inhaltlichen Ablauf den Prozessschritten
von der Konzeption der Architektur über das Design bis
zur Implementation bzw. zum Code. Im letzten Teil fragen wir
uns, was einen guten Code ausmacht und welche Werkzeuge
und Konzepte existieren, um einen solchen zu schreiben und zu
erhalten. Ein Glossar und eine Referenzliste für weiterführende
Literatur komplettieren dieses ERNI Essential.

2. ARchITEkTuRbEGRIFF
software engineering 7
Die Architektur ist die grundlegende Organisation eines Systems,
verkörpert durch seine Komponenten und deren Kommunikation
untereinander wie auch zur Umgebung. Die Architektur
spiegelt die Prinzipien und wichtigsten Designentscheide
wider, nach denen das System entworfen wurde. Der Fokus liegt
dabei auf den für die Lösung signifikanten Elementen und deren
Einbettung in die umliegenden Systeme.
definition
die architektur ist die grundlegende organisation eines systems,
verkörpert durch seine Komponenten und deren Kommunikation
untereinander wie auch zur Umgebung.
Die Architektur einer Software adressiert in erster Linie die Kapselung
der Daten, die Aufteilung in Komponenten und Programme,
deren Zusammenspiel in Form von Prozessen und den Datenzugriff
sowie die Interaktionen mit Drittsystemen. Die Architektur
bildet dabei das Fundament für den Detailentwurf und
stellt die Integration in das übergeordnete Gesamtsystem sicher.
Es gibt nicht die richtige Architektur. Sie muss immer in Bezug
zu den geforderten Qualitätsattributen, den verfügbaren Ressourcen
und dem gegebenen Kostenrahmen gesehen werden.

Jedes System hat eine Architektur, auch wenn diese nicht formal
dokumentiert ist. Ohne entsprechende Dokumentation in Form
geeigneter Modelle lässt sich jedoch nur schwer oder zu spät feststellen,
ob die gewählte Lösung den Qualitätsanforderungen
genügt. Die Dokumentation bildet die Grundlage für die weitere
Entwicklung und fungiert als eines der wichtigsten Kommunikationsmittel
zwischen Auftraggeber, Projektleitung, Kundenvertretern
(dem Geschäft) und Entwicklern. Die Architekturdokumentation
stellt dabei ein gemeinsames Verständnis sicher.
2.1 ARchITEkTuR IST EIN kOmpROmISS
Abb. 1: arChiteKtUr aLs KoMProMiss
Verfügbarer Kostenrahmen
Verfügbarkeit
erweiterbarkeit
?
bedienbarkeit
Performance
sicherheit
Die Architektur ist das Ergebnis eines Kompromisses zwischen
den oft gegenläufigen Qualitätsattributen. Die Kosten geben da-
software engineering 9
bei den möglichen Rahmen vor. So wirkt sich beispielsweise eine
erhöhte Sicherheit negativ auf die Performance aus; die Verbesserung
der Performance wirkt sich andererseits negativ auf die
Erweiterbarkeit durch die Schaffung von Redundanzen aus. Die
richtige und ausgewogene Berücksichtigung der Qualitätsattribute
bildet ein Hauptaugenmerk der Architektur. Der gewählte
Entwurf entscheidet über deren Erfüllungsgrad – heute wie auch
in Zukunft. Bei der abschliessenden Architekturbewertung wird
geprüft, ob die getroffenen Entscheidungen den relevanten Qualitätsanforderungen
noch entsprechen und die gewählte Lösung
als Ganzes damit zweckmässig ist.
2.2 QuAlITäTSATTRIbuTE
Bei Qualitätsattributen handelt es sich um einen Teil der nichtfunktionalen
Anforderungen, die manchmal implizit erwartet
werden und bei deren Absenz der spätere Anwender nicht zufrieden
wäre. Es ist nicht das Fehlen einer bestimmten Funktion,
sondern die nicht korrekte oder nicht effiziente Ausführung, die
ein Ärgernis für den Benutzer darstellt.
wiChtig zU wissen
architektur adressiert die Qualitätsattribute.

wesentLiChe QUaLitätsattribUte
• Performance
• Skalierbarkeit
• Sicherheit
• Bedienbarkeit
• Verfügbarkeit
• Integrierbarkeit
• Änderbarkeit
• Testbarkeit
• Wartbarkeit
Die Kosten, die zur Verfügung stehende Zeit und weitere nichtfunktionale
Anforderungen wie z.B. Technologievorgaben sind
zusätzliche, oft unterschätzte Einflussgrössen bei der Konzeption
der Architektur und dem möglichen Erfüllungsgrad der Qualitätsattribute.
2.3 ARchITEkTENROllE
Der Architekt ist in erster Linie Vermittler zwischen den verschiedenen
Interessengruppen, Verantwortlicher des Lösungskonzepts
und Berater für Businessanalysten, Programmierer und
Projektleiter. Die Rolle des Architekten verlangt eine grosse Portion
Sozial- und Kommunikationskompetenz. Er muss sich in
die Lage der Stakeholder versetzen und ihre Position verstehen
können.
software engineering 11
Der Architekt steht in der direkten Verantwortung, eine optimale
Umsetzung für den Auftraggeber in Bezug auf Funktionalität,
Qualitätsattribute und Kosten zu finden und voranzutreiben.
Nicht die technisch beste Lösung oder der Einsatz der neusten
Technologie steht im Vordergrund, sondern die Erreichung der
Projektziele. Es ist nicht immer eine einfache Aufgabe, das Mögliche
zugunsten des zeitlich Machbaren zu opfern und Kompromisse
auch unter schwierigen Bedingungen herbeizuführen.
Zu einem Architekten entwickelt man sich im Laufe seines Arbeitslebens.
Ein Studiengang IT-Architektur wird bis dato von
Hochschulen leider nicht angeboten. Sogar Zertifizierungen
sind erst in der Entwicklung. Folgende Erfahrungen und Fähigkeiten
sollte ein Architekt besitzen. Es ist zu beachten, dass dies
lediglich eine Auswahl darstellt.
sKiLLs eines arChiteKten
• Informatik- oder Ingenieurstudium
• Weitreichende Erfahrungen als Entwickler
• Ausgeprägte analytische und konzeptionelle Fähigkeiten
• Kenntnisse über die aktuell verfügbaren Technologien sowie
deren Vor- und Nachteile
• Kommunikations- und Sozialkompetenz
• Grundlegende Kenntnisse im Projektmanagement und im
gesamten Entwicklungsprozess
• Proaktive Vorgehensweise und Pragmatismus
• Kompromissbereitschaft, aber auch Durchsetzungsvermögen

3. ARchITEkTuRdImENSIONEN
software engineering 13
In einem Unternehmen findet die IT-Architektur auf verschiedenen
Ebenen statt. Die Architekturebenen gilt es durchgängig
und vollständig zu planen und zu unterhalten. Mit Hilfe von
Sichten und Standpunkten als Architekturdimensionen lassen
sich die Ebenen in sich ganzheitlich und konsistent beschreiben
(Abb. 2). Die Geschäftsebene, jedes System und jede Applikation
müssen adäquat dokumentiert werden, beispielsweise in einem
Architekturdokument, wie in Kapitel 5.2 beschrieben.
Abb. 2: diMensionen Von it-arChiteKtUren
sichten
standpunkte
geschäftsebene
systemebene
applikationsebene

3.1 EbENEN
Architektur findet auf verschiedenen Abstraktionsebenen statt:
Abb. 3: ebenen Von it-arChiteKtUren
ebene
geschäft
technologie system
Konzeptionell ausführung
geschäftsleistung
implementation
wirkt auf verarbeitet
geschäftsobjekt geschäftsprozess geschäftsrolle
unterstützt
geschäftsfunktion
nutzt
abgeleitet
von
stellt bereit
Komponente
abgeleitet
von
Klasse
standpunkt
geschäftsereignis
service
Modul
applikationsservice
infrastrukturservice
subsystem
Knoten
ausgeführt
auf
software engineering 15
Geschäftsebene: Die Geschäftsebene, auch Unternehmensarchitektur
genannt, beschäftigt sich mit der langfristigen Geschäftsstrategie.
Eine Organisation ist gekennzeichnet durch die
ständige Anpassung an äussere Gegebenheiten und die Fähigkeit,
rasch auf Veränderungen zu reagieren. Auf der Unternehmensebene
wird eine bedarfsgerechte Kernprozessunterstützung
durch die IT in einem kalkulierbaren Kostenrahmen angestrebt.
Den Anforderungen und Dynamiken des jeweiligen Geschäftsfeldes
gilt es auf Architekturebene Rechnung zu tragen. Diese
Ebene hat strategischen Charakter.
Systemebene: Die Systemebene beschreibt das in sich konsistente
Zusammenspiel verschiedener Applikationen und Services.
Ein häufig vorkommender Begriff auf der Systemebene ist
Service-orientierte Architektur (SOA). Die SOA ermöglicht es,
Geschäftsprozesse und Workflows aus Services unabhängig von
den darunterliegenden Applikationen zu orchestrieren und so
rasch auf Prozessänderungen zu reagieren.
Applikationsebene: Die Applikationsebene beschäftigt sich mit
der Implementation sowie der Anpassung von Applikationen,
Modulen und Komponenten. Es handelt sich hier um die klassische
Softwarearchitektur.
Untere Ebenen verfeinern die Architekturvorgaben der darüberliegenden
Ebenen. Jede Ebene nutzt mit Hilfe von Schnittstellen
die Daten, Services und Komponenten der darunterliegenden
Schicht, um daraus höherwertige Dienste zu bauen und anzubieten.
Anpassungen auf einer unteren Ebene sollten keine Anpas-

sungen auf der darüberliegenden Ebene notwendig machen.
Dies wird durch einen Top-down-Ansatz und die konsequente
Verwendung von prozessunabhängigen Interfaces erreicht.
Wrapperklassen und übergreifende Definitionen müssen vermieden
werden.
wiChtig zU wissen
architektur findet auf verschiedenen ebenen statt.
Jede ebene muss geplant und gelenkt werden.
Alle diese Ebenen müssen konzipiert werden. Sichten und Standpunkte
sind Methoden, um diese zu beschreiben und zu konkretisieren.
Jeder Standpunkt und jede Sicht trägt zur Konkretisierung
der jeweiligen Architektur bei.
3.2 STANdpuNkTE
Die Sicht auf eine Architektur ist abhängig vom Betrachtungsstandpunkt
(Abb. 4). Die Stakeholder einer Architektur vertreten
naturgemäss verschiedene Standpunkte in Abhängigkeit ihrer
Rolle. Die Betrachtung einer Architektur aus drei Standpunkten
hat sich in der Praxis bewährt:
software engineering 17
Abb. 4: standPUnKte zUr betraChtUng Von it-arChiteKtUren
Konzeptioneller
standpunkt
Was
sind die bestandteile des
systems? (Design Time)
ausführungsstandpunkt
Wie
ist der ablauf des systems?
(Run Time)
implementationsstandpunkt
Wo
wird das system ausgeführt?
(Deploy Time)
Konzeptioneller Standpunkt: Er beschreibt das System aus der
logischen, funktionalen Perspektive. Im Zentrum steht die Aufteilung
in Funktionsblöcke, deren Schnittstellen und Verbindungen.
Der konzeptionelle Standpunkt fokussiert sich darauf, die
Architektur in Begriffen der Domäne zu verstehen und auszudrücken
sowie darzulegen, wie die Anforderungen erfüllt werden.
Dies umfasst das logische Datenmodell und die Benutzerfürung.

TAb. 1: foKUs des KonzePtioneLLen standPUnKtes
bzgL. der drei arChiteKtUrebenen
Architekturebene Fokus
geschäftsebene welche domänenspezifischen geschäftstreiber
und Leistungen der organisation definieren das
geschäftsobjektmodell?
systemebene was für services, abgeleitet von den geschäftsobjekten,
müssen durch das system bereitgestellt
werden, und wie sind diese untereinander
verbunden?
applikationsebene aufzählen der Komponenten als kleinste
konzeptionelle einheiten einer architektur
und darstellen von deren funktionsweise sowie
interaktionspfaden.
Ausführungs-Standpunkt: Er schildert das zeitliche Verhalten,
die Synchronisation und die Kommunikation innerhalb der
Software. Das System wird aus dem Gesichtspunkt der Laufzeitumgebung
betrachtet. Einen wichtigeren Teil bildet dabei das
Aufzeigen des Kontroll- und Datenflusses. Die Architekturpatterns
liefern hierzu die Basis für die Ausführungsmodelle. Zu
diesem Standpunkt gehören im Weiteren die Abklärungen des
Datenvolumens, das Transaktionsmanagement und die Wiederherstellung
der Daten.
TAb. 2: foKUs des aUsführUngs-standPUnKtes
bzgL. der drei arChiteKtUrebenen
Architekturebene Fokus
software engineering 19
geschäftsebene Mit welchen geschäftsprozessen soll auf die geschäftsereignisse,
also die bedürfnisse der Kunden,
reagiert werden? welche geschäftsfunktionen
sind dazu notwendig?
systemebene zu welchen weitgehend unabhängigen und
parallel ausführbaren subsystemen lassen sich die
services zusammenfassen? welche aufrufbaren
funktionen stellen diese bereit?
applikationsebene zu welchen Modulen werden die Komponenten
zusammengefasst? benennen der einzusetzenden
Middleware und technologie sowie der notwendigen
infrastruktur.
Implementations-Standpunkt: Er betrachtet das System aus
dem Blickwinkel, wie es aufgebaut und verteilt wird. Dieser
Standpunkt dient dazu, die Infrastruktur und die Systemkomponenten
zu benennen und zu beschreiben sowie aufzuzeigen, aus
welchen physischen Bausteinen das System besteht. Dies sind
typischerweise Applikationen, binäre Pakete, Bibliotheken,
Frameworks und Konfigurationsdateien. Der Implementations-
Standpunkt definiert zudem die Codeorganisation in Pakete und
Lieferobjekte.

TAb. 3: foKUs des iMPLeMentations-standPUnKtes
bzgL. der drei arChiteKtUrebenen
Architekturebene Fokus
geschäftsebene welche geschäftsrollen und akteure des Unternehmens
sind für die ausführung der geschäftsprozesse
notwendig, und wie wird der Prozess im
Unternehmen installiert und implementiert?
systemebene durch welche applikationen und hardwarebausteine
werden die subsysteme implementiert?
wie wird kommuniziert, und welches ist die
Laufzeitumgebung?
applikationsebene auf welchen physikalischen geräten und
servern laufen welche Module, wie sieht das
netzwerk aus, und mit welchen hilfsmitteln
wird entwickelt?
3.3 ASpEkTE
Jeder der drei Standpunkte betrachtet bestimmte Aspekte eines
Systems. Ein solcher Aspekt beinhaltet die Beantwortung
spezifischer Interessen bestimmter Stakeholder. Die folgende
Aufzählung nennt mögliche Aspekte, die während des Architekturentwurfs
abhängig vom jeweiligen Standpunkt zu adressieren
sind:
software engineering 21
KonzePtioneLLer standPUnKt
• Funktionalität: Welchen Zweck erfüllt die Lösung, und in
welche Funktionsblöcke sowie Subsysteme teilt sich diese
auf?
• Ergonomie: Was ist die grundsätzliche Bedienungsphilosophie?
Müssen bestimmte Auflagen zur Vermeidung von Fehlbedienungen
beachtet werden, und wie ist beispielsweise das
Produkt durch Personen mit einer körperlichen Behinderung
zu bedienen?
• Daten: Wie werden die Daten gespeichert, wie erfolgen das
Backup und eine mögliche Wiederherstellung? Wie wird die
Datenintegrität sichergestellt und der Zugriff geregelt?
• Geschäftsregeln: Rahmenbedingungen, Gesetze, Patente
und technische Limitationen schränken das mögliche Lösungsspektrum
ein. Wie werden diese Auflagen erfüllt?
aUsführUngs-standPUnKt
• Gleichzeitigkeit: Viele Abläufe finden gleichzeitig statt und
werden über verschiedene Mechanismen synchronisiert.
Wie sehen diese aus, und wie wird das System gestartet und
gestoppt?
• Kommunikation: Wie kommunizieren die verschiedenen
Modelle untereinander, und wie wird mit den Umsystemen
kommuniziert? Welche Protokolle und Kommunikationspatterns
sollen verwendet werden?
• Sicherheit: Welche Sicherheitsauflagen sind zu berücksichtigen?
Wie erfolgt die Authentifizierung und Autorisierung?
Sind die Daten zu verschlüsseln, und wie schützt
sich das System?

• Infrastruktur: Ist zusätzliche Hardware notwendig, oder
wird bestehende Infrastruktur genutzt? Netzwerktopologie
und Technologieabhängigkeiten sind zudem Fragen dieses
Aspekts.
iMPLeMentations-standPUnKt
• Entwicklung: Welcher Bauplan liegt der Architektur zugrunde?
Ist ein bestimmtes Framework notwendig, und gibt
es einzuhaltende Technologie- und Codierungsrichtlinien?
• Verteilung: Wie wird die Software verteilt und installiert?
Ist der Vorgang reversibel und wenn ja wie? Wie erfolgt eine
mögliche Migration der Daten?
• Betrieb: Wie wird die Applikation betrieben, überwacht
und konfiguriert? Wie sieht ein möglicher Support aus?
• Wiederverwendung: Auf welcher Ebene und wie findet eine
Wiederverwendung statt? Welche Komponenten werden eingekauft,
welche selbst gebaut? Wie wird die Wiederverwendung
organisatorisch sichergestellt?
Die folgende Abbildung fasst diese zwölf Aspekte nach der Aufteilung
in die drei Standpunkte grafisch zusammen:
Abb. 5: asPeKte naCh standPUnKten
Konzeptionell
funktionalität
ergonomie
daten
geschäftsregeln
ausführung
gleichzeitigkeit
Kommunikation
sicherheit
Vollständigkeit
infrastruktur
Vertraulichkeit
Verletzlichkeit
Verfügbarkeit
software engineering 23
implementation
entwicklung
Verteilung
betrieb
störung
Problem
Change
release
Konfiguration
wiederverwendung
ooP
sPL
Cbd Mda
soa Pattern

3.4 SIchTEN
Die verschiedenen Aspekte eines Standpunktes werden aus drei
Sichten beschrieben und in Diagrammen festgehalten: Struktur,
Verhalten und Interaktion. Nach dieser Aufteilung sind auch die
Diagramme in der Unified Modeling Language (UML) gruppiert.
Abb. 6: organisation naCh siChten
Verhalten
aktivität
zustand
anwendungsfall
Klasse
Komponente
Verteilung
struktur
sequenz
Kommunikation
Meldungen
strUKtUr
Die Struktur dokumentiert das Modell aus der statischen Sichtweise.
Diese Sicht zeigt, aus welchen Elementen und Bausteinen
ein System besteht. In der Unified Modeling Language werden
für die Modellierung der Struktur Klassen, Pakete, Komponenten
und Knoten verwendet. Die Klassen sind die kleinsten Teile, die
zu Paketen und dann zu Komponenten zusammengefasst werden.
Die statische Sichtweise ist im Grunde eine Aufzählung und
interaktion
software engineering 25
Gruppierung der Bestandteile eines Systems. Die Struktur lässt
sich durch die Darstellung der Klassen und Komponenten sowie
die Verteilung auf die Laufzeitumgebung beschreiben. Diese
Sichtweise sagt jedoch nichts darüber aus, wie das System funktioniert
oder sich über die Zeit verhält.
VerhaLten
Das Verhalten wendet sich dem dynamischen Teil eines Systems
zu. Es wird aufgezeigt, wie sich das System oder dessen Komponenten
über die Zeit verhalten, um bestimmte Aufgaben zu erfüllen.
Der Fokus liegt dabei auf einem ausgewählten Baustein
der statischen Sichtweise. Die UML-Elemente zur Verhaltensmodellierung
sind Zustände, Aktivitäten, Meldungsflüsse bzw. Zustandsübergänge
und Anwendungsfälle. Zustände und deren
gleichnamige Diagramme veranschaulichen das Verhalten als
ein Reagieren auf äussere Ereignisse aus einem stabilen Zustand
heraus. Aktivitäten hingegen beschreiben eine sequenzielle Abfolge
von Tätigkeiten, die eine Komponente bis zu einem bestimmten
Endpunkt ausführt. Anwendungsfälle schildern hingegen
eine Abfolge von Interaktionen zwischen einem Benutzer
und dem System.
interaKtion
Die Interaktionen sehen das System als einen Fluss von Meldungen.
Es wird dargelegt, welche Meldungen zwischen den statischen
Elementen fliessen und wie diese zeitlich zusammenhängen.
Im Gegensatz zur Verhaltenssichtweise liegt der Schwerpunkt
auf dem Zusammenspiel der Komponenten von aussen
gesehen. Betrachtet die dynamische Sicht das Verhalten eines

einzelnen Bausteins oder des Systems isoliert, so zeigt die Interaktionssicht
den dabei stattfindenden Meldungsaustausch zwischen
diesen Bausteinen auf. Die Elemente der Interaktionssicht
in UML sind Sequenz- und Kommunikationsdiagramme. Beide
bilden den zeitlichen Meldungsverlauf ab und illustrieren, welche
Spur die Verarbeitung eines bestimmten Ereignisses hinterlässt.
Mit der Beschreibung der Interaktionen lassen sich komplexe
Zusammenhänge zwischen den Bausteinen jeder Abstraktionsebene
ausdrücken. So lässt sich die Reaktion des Systems auf einzelne
Szenarien illustrieren, indem der Meldungspfad durch das
System aufgezeigt wird.
software engineering 27

4. ARchITEkTuRpATTERNS
software engineering 29
Architekturpatterns definieren grundlegende Strukturen und
Patterns, nach denen ein System aufgebaut ist. Sie charakterisieren
hauptsächlich die Art und Weise der Kommunikation zwischen
den relevanten Elementen eines Systems (Abb. 7).
Die Liste möglicher Architekturpatterns ist keine fixe Grösse und
hängt vom jeweiligen Betrachter ab. Neben den klassischen Patterns
wie «Pipe-and-Filter,» «Client-Server», «Peer-to-Peer» und
«Publish-Subscribe» finden sich viele weitere Ansätze wieder,
basierend auf einem gemeinsamen Bus, auf dem Schichtenmodell
und den Ereignis-, Ressourcen- oder Service-orientierten Architekturen.
Viele Patterns finden sich in einer etwas anderen
Bezeichnung und als auf die Problemstellung des Softwareentwurfs
adaptierte Konzepte als Designpatterns wieder.
Abb. 7: arChiteKtUrPatterns
monolith
publish-Subscribe
client-Server
Client
peer-to-peer
server
pipe-and-Filter
Shared-data
filter

wiChtig zU wissen
architekturpatterns beschreiben einen grundsätzlichen
Lösungsansatz oder ein Kommunikationskonzept.
die aM häUfigsten eingesetzten arChiteKtUrPatterns sind:
• Monolith: Die aus einem Guss bestehende Applikation ist,
insbesondere für lokal zu installierende Anwendungen, ein
gängiges Pattern.
• Client-Server: Ein Server bietet Dienste an, die vom Client über
ein klar definiertes Interface aufgerufen und vom Server sofort
(synchron) oder zeitverzögert (asynchron) beantwortet werden.
• Pipe-and-Filter: Dieses Architekturpattern skizziert eine
nacheinander geschaltete Reihe von Verarbeitungspunkten,
den Filtern, verbunden durch Pipes. Dabei funktioniert jeder
Filter ohne Wissen des Vorgängers und Nachfolgers.
• Publish-Subscribe: Der Subscriber meldet sich beim Publisher
an, um im Ereignisfall aufgerufen zu werden. Der Publisher
kann mehrere Subscriber bedienen, und die Zustellung
der gewünschten Daten erfolgt asynchron.
• Peer-to-Peer: Das System besteht aus einer beliebigen Anzahl
von Knoten (Peers), die frei untereinander kommunizieren.
Bei diesem Ansatz gibt es im Gegensatz zum Client-Server
kein steuerndes, zentrales System.
software engineering 31
• Shared-Data: Im Zentrum stehen persistente Daten, auf die
mehrere Applikationen zugreifen. Diese Datenbank beinhaltet
keine Geschäftslogik und dient lediglich dem asynchronen
Datenaustausch und der Speicherung der Daten.

5. ARchITEkTuRENTWuRF
software engineering 33
Der Architekturentwurf verläuft nach folgender Vorgehensweise:
Abb. 8: arChiteKtUrProzess
Cartoon
software requirements
specification
architekturdokument
aktivitäten
artefakte
referenzen
1.
2.
3.
4.
5.
6.
7.
8.
9.
akzeptiert
stakeholder
identifizieren
interessen
erfassen
Kontext
definieren
input
konsolidieren
szenarien
identifizieren
best Practices
und Vorgaben
identifizieren
architekturkandidaten
entwerfen
architekturoptionen
evaluieren
architektur
bewerten
nicht akzeptiert
Vision
rahmenbedingungen
referenzarchitektur
architekturpatterns
andere Projekte
architektur
10.
überarbeiten

5.1 pROzESSSchRITTE
1. Stakeholder identifizieren: Wie beim Anforderungsma-
nagement ist die Berücksichtigung der relevanten Stakeholder
entscheidend, um die Interessen aller Betroffenen
einbeziehen zu können. Neben den primären Nutzern
sind es auch Betreiber, Entwickler und Gremien, die Standards
und Strategien vorgeben.
2. Interessen erfassen: Die Interessen und Aspekte der Stakeholder
abhängig von ihrem Standpunkt erfassen und priorisieren.
Dies geschieht idealerweise mittels mehrerer Workshops.
3. Kontext definieren: Den Projektkontext abstecken und damit
festlegen, was Teil des Systems sein wird. Hierzu gehören
auch die Identifikation der relevanten Umsysteme und
die Beschreibung der Schnittstellen zu diesen.
4. Input konsolidieren: Anwendungsfälle und SRS (Software
Requirements Specification) müssen verstanden werden und
in Bezug auf die Architektur widerspruchsfrei sein.
5. Szenarien identifizieren: Szenarien sind konkrete Abläufe,
die jeweils auf einen oder mehrere Architekturaspekte
fokussiert sind. Im Gegensatz zu Anwendungsfällen beschreiben
Szenarien genau eine mögliche Abfolge durch
das System.
software engineering 35
6. Best Practices und Vorgaben identifizieren: Beim Entwurf
sind bekannte Architekturpatterns und Lösungen
aus anderen Projekten hinzuzuziehen. Allenfalls müssen
Referenzarchitekturen oder anderweitige Vorgaben und
Rahmenbedingungen berücksichtigt werden.
7. Architekturkandidaten entwerfen: Erstellen einer ersten,
groben Architektur, die die wichtigsten Komponenten und
Beziehungen aufzeigt. Die Architektur wird durch die verschiedenen
Sichten beschrieben, weiter verfeinert und im
Architekturdokument festgehalten.
8. Architekturoptionen evaluieren: Die zuvor gewählte
Architektur wird hinsichtlich der geforderten Qualitätsattribute
geprüft. Dies geschieht anhand der definierten Szenarien
mit Hilfe von Walkthroughs, Prototypen oder Tests mit
einem Programmskelett.
9. Architektur bewerten: Die Architektur wird durch die
Stakeholder geprüft. Allenfalls findet eine Validierung der
Architektur durch Methoden wie ATAM statt.
10. Architektur überarbeiten: Basierend auf den Ergebnissen
der Validierung, speziell den Risiken und den sensitiven
Punkten, wird die Architektur überarbeitet und werden die
Modelle allenfalls verfeinert.

5.2 ARchITEkTuRdOkumENTATION
Das Ergebnis des Architekturentwurfs ist das Architekturdokument
(siehe Tab. 4 und 5), das neben der Klärung der grundsätzlichen
Ziele die bereits besprochenen Aspekte aus den verschiedenen
Standpunkten adressiert. Es hat folgenden Aufbau:
TAb. 4: aUfbaU des arChiteKtUrdoKUMents (1)
Thema beschreibung
Management
summary
zusammenfassung des dokuments auf maximal
einer seite, welche die wichtigsten Punkte
beleuchtet.
systemkontext abgrenzung des Projekts und ziehen der
systemgrenzen. hierzu eignet sich neben einer
textuellen beschreibung die darstellung eines
Kontextdiagramms. das system ist dabei eine
blackbox, und alle drittsysteme, mit denen
kommuniziert wird, sind externe entitäten.
Projektziele das eigentliche Projektziel und die wichtigsten
anforderungen an das system werden wiederholt.
dabei wird auf das Visionsdokument
bezug genommen.
generelle
architekturprinzipien
auflistung von generellen Prinzipien und überlegungen,
auf denen die architektur aufgebaut
ist. entscheidungen sind zu begründen und
zu dokumentieren, damit sie für nachfolgende
Leser nachvollziehbar sind.
TAb. 5: aUfbaU des arChiteKtUrdoKUMents (2)
Thema beschreibung
software engineering 37
sichten das system wird aus dem blickwinkel der Konzeptions-,
ausführungs- und implementations-standpunkte
modelliert. dabei werden die relevanten
architekturaspekte betrachtet.
Prototyp Kritische aspekte in einem Prototyp verifizieren
zu lassen, ist oft eine einfache und effiziente
Methode, um Unsicherheiten zu reduzieren und
komplexe zusammenhänge zu veranschaulichen.
das architekturdokument nimmt bezug auf die
ergebnisse der Prototypen.
Qualitätsattribute auflistung der Qualitätsattribute und beschreibung,
wie diese durch die gewählte architektur
sichergestellt werden.
wichtige
szenarien
die wichtigsten fälle, die das system durchlaufen,
werden kurz skizziert. gerade solche konkrete
abläufe helfen, die eher abstrakte form eines
Modells besser zu verstehen.

5.3 cARTOON
Verständnis beginnt Mit eineM biLd!
Abb. 9: systeMabgrenzUng aLs Cartoon
GpS-Satelliten provider
internet
gPs-signal
gPrs/UMts · staumeldungen
· staumeldungen
Navigationsgerät
digital audio broadcast
· staumeldungen
· sperrungen
Radiostation
Die Architektur und ihre Dokumentation sind in erster Linie
Mittel zur Kommunikation. Nichts ist stärker als eine gemeinsame
Vision und Vorstellung über das zukünftige System. Dazu ist
ein Cartoon (Abb. 9) ein wichtiges Hilfsmittel, das in jedem Fall
zur Kommunikation und Veranschaulichung verwendet werden
sollte. Der Bau eines Systems beginnt im Idealfall mit dieser einfachen
und prägnanten Zeichnung, an der zukünftig viele Diskussionen
beginnen werden. Diese Zeichnung oder dieser Cartoon
zeigt mit allgemein verständlichen Symbolen die wichtigsten
Elemente des Lösungsentwurfs auf.
software engineering 39

6. ARchITEkTuRbEWERTuNG
Abb. 10: arChiteKtUrbewertUngsProzess
Qualitäts-
merkmale
1. geschäftsziele
präsentieren
2. architektur
präsentieren
3. Qualitätsbaum
erstellen
4. Qualitätsattribute
bewerten
5. szenarien identifizieren
und
priorisieren
6. architektur-
ansätze identifizieren
software engineering 41
sensitive Punkte
und Kompromisse
7. analyse nicht-risiken
risiken
aktivitäten
artefakte
Viele Softwareanwendungen müssen frühzeitig ersetzt werden, da
sie den Qualitätsattributen nicht oder nicht mehr genügen. Für
den Lebenszyklus einer Software ist eine ausgewogene Architektur
erfolgsentscheidend. Sie muss den heutigen wie auch den zukünftigen
Anforderungen nach Zuverlässigkeit, Skalierbarkeit, Performance
und Erweiterbarkeit Rechnung tragen. Der Architekturentwurf
soll mit einer Architekturbewertung frühzeitig hinsichtlich
der Erfüllung der gestellten Anforderungen überprüft werden
(Abb. 10). Die relevanten Qualitätsattribute werden den getroffenen
Designentscheiden gegenübergestellt. Dabei werden die Qualitätsattribute
in messbare Einzelanforderungen aufgegliedert und
nach deren Relevanz und Auswirkung bewertet (Tab. 6, 7 und 8).

TAb. 6: ProzesssChritte der arChiteKtUrbewertUng (1)
Task beschreibung
1. geschäftsziele
präsentieren
2. architektur
präsentieren
3. Qualitätsbaum
erstellen
der Projektverantwortliche präsentiert die
wichtigsten funktionalen anforderungen, die
Projektziele, die technischen, wirtschaftlichen
und politischen rahmenbedingungen sowie
die wichtigsten stakeholder und Qualitätsansprüche.
der architekt präsentiert die architektur
anhand der verschiedenen standpunkte und
erläutert daran die funktionsweise der gewählten
Lösung.
die Qualitätsattribute lassen sich in die
hauptkategorien Performance, wartbarkeit,
erweiterbarkeit, sicherheit, skalierbarkeit und
bedienbarkeit aufteilen und diese wiederum in
quantifizierbare anforderungen. das ergebnis
ist ein baum, dessen äste die kleinsten nichtfunktionalen
anforderungen darstellen, die es
zu bewerten gilt.
software engineering 43
TAb. 7: ProzesssChritte der arChiteKtUrbewertUng (2)
Task beschreibung
4. Qualitätsattribute
bewerten
die zuvor identifizierten Qualitätsattribute werden
nach ihrem geschäftlichen nutzen hin beurteilt.
dabei werden die äste des Qualitätsbaums nach
ihrer relevanz für den erfolg der applikation
und den Kosten für deren erreichen bewertet. es
genügt, wenn bei der beurteilung zwischen high
(H), Medium (M) und Low (L) unterschieden wird.
das folgende beispiel sagt aus, dass die relevanz
für eine antwortzeit < 1 s Medium ist und die
Kosten, um dies zu erreichen, Low sind.
beispiel für einen Qualitätsbaum:
Performance
Latenz
durchsatz
relevanz Kosten
(HM, L) antwortzeit < 1 s
(HM, H) > 1000 benutzer

TAb. 9: ProzesssChritte der arChiteKtUrbewertUng (3)
Task beschreibung
5. szenarien
identifizieren
und priorisieren
6. architekturansätze
identifizieren
hier wird nicht mehr nur die erfüllung einzelner
Qualitätsmerkmale beurteilt, sondern es werden
szenarien entwickelt, die das zu bauende
system als ganzes betreffen. ein szenario
beschreibt die art und weise, wie das system
einen konkreten fall abarbeitet.
bei der identifizierung der architekturansätze
werden die architekturstile, die designpatterns
und die gewählten technologien ermittelt, die
zur anwendung kamen.
7. analyse es wird nun geprüft, inwieweit die architekturansätze
die zuvor gewichteten Qualitätsattribute
und die signifikanten szenarien zu erfüllen
vermögen. das ergebnis der architekturanalyse
ist die auflistung und bewertung der identifizierten
risiken, der sensitiven Punkte und
der notwendigen Kompromisse. es wird keine
architektur geben, welche die geforderten
aspekte in ihrer gesamtheit zu erfüllen vermag.
es ist jedoch wichtig, die risiken zu kennen.
software engineering 45

7. dESIGNpRINzIpIEN
software engineering 47
Abb. 11: abhängigKeiten zwisChen designPrinziPien
realisiert durch
abstraktion
ausprägung
von
Lose
führt zu erhöht
Kopplung
hohe
Kohäsion
Modularität
vereinfacht
Konsistenz
realisiert durch
geheimhaltung
ausprägung von
entwurf für
Veränderungen
erhöht
erhöht
separation
of Concern
ausprägung
von
Dieses Kapitel beschäftigt sich mit den Merkmalen, die eine Architektur
oder ein Softwaredesign als gut oder schlecht qualifizieren.
Eine Architektur dient in erster Linie der optimalen Erfüllung
der vorgängig beschriebenen Qualitätsattribute. Wie beim
Schreiben einer Zeile Code, so gelten auch in der Architektur
und im Softwaredesign grundlegende Prinzipien (Abb. 11). Die
Berücksichtigung dieser Prinzipien – so allgemein sie auch sein
mögen – bildet das Fundament jeder guten Architektur. Dies gilt
heute bei Systemen von stets höherer Komplexität mehr denn je.

aUf VeränderUngen aUsgeriChteter entwUrf
Auch in der Softwareentwicklung gilt, dass die Veränderung die
einzige Konstante ist. Oft existieren hinsichtlich der technischen
Machbarkeit nicht quantifizierbare Unsicherheiten. Diese
erfordern eine Anpassung des ursprünglichen Entwurfs. Zudem
muss das System auch zukünftigen Anforderungen genügen, die
heute noch nicht abschätzbar sind. Die Fähigkeit, flexibel auf
solche Veränderungen zu reagieren, ist ein entscheidender Erfolgsfaktor
für moderne Systeme. Die lose Kopplung und die eng
damit verbundenen Ansätze einer Komponenten- und Serviceorientierten
Architektur sind Schlüsselfaktoren im Softwareentwurf.
Die Abhängigkeit von herstellerspezifischen Technologien
und Programmiersprachen ist dabei nicht zu unterschätzen. Applikationen
haben nicht selten eine Lebensdauer von einem
Jahrzehnt und mehr, und die gewählte Technologie sollte diesem
Umstand Rechnung tragen.
seParation of ConCern
Separation of Concern (SoC) folgt dem Grundsatz «Teile und herrsche»,
indem ein gegebenes Problem in Teilprobleme zerlegt wird,
die getrennt voneinander gelöst werden können. Bei der Separation
werden Dinge nach ihrem Zweck zusammengefasst, so dass
sich diese in Bezug auf ihre Funktionalität minimal überlappen.
Das Prinzip ermöglicht damit ebenso, ein Gesamtproblem arbeitsteilig
zu behandeln. Die Trennung erfolgt nach funktionalen oder
technischen Gesichtspunkten. Aus der fachlichen Sicht sind dies
Subsysteme, die weitgehend unabhängig voneinander funktionieren.
Aus dem technischen Blickwinkel sind dies Aspekte wie
Performance, Sicherheit, Nachvollziehbarkeit und Nutzbarkeit.
software engineering 49
geheiMhaLtUng
Geheimhaltung oder Information Hiding ist das Prinzip, der
Aussenwelt nur so viel preiszugeben, wie gerade notwendig ist.
Interne Datenstrukturen und Algorithmen werden verborgen.
In objektorientierten Sprachen wird der Zugriff auf die internen
Daten durch die darauf anzuwendenden Operationen geschützt.
Beim Design der Schnittstellen ist darauf zu achten, dass mit den
übergebenen Daten nicht implizit Interna über Datenmodelle
oder eingesetzte Technologien weitergegeben werden. Heutige
Werkzeuge ermöglichen beispielsweise auf einfache Weise,
Strukturen einer Datenbank direkt an die Präsentationsschicht
weiterzuleiten. Damit entsteht jedoch eine enge Kopplung zwischen
Datenbank und Präsentationsschicht.
abstraKtion
Abstraktion ist das bewusste Auslassen bestimmter Informationen
und Teilaspekte, um bestimmte Eigenschaften in der jeweiligen
Betrachtungsebene hervorzuheben. Erst die Summe aller
Ansichten ergibt wieder ein vollständiges Bild des Systems.
Abstraktion findet auch auf hierarchischer Ebene statt, indem
Einzelheiten der darunterliegenden Ebene ignoriert werden, um
Gesamtzusammenhänge zu veranschaulichen. Die Kunst der
Abstraktion ist es, die richtigen Dinge wegzulassen, um die wesentlichen
Eigenschaften der jeweiligen Betrachtungsebene unmissverständlich
zu erkennen.
ModULarität
Modularität ist ein Baukastenprinzip: Aus einzelnen Elementen
oder eben Bausteinen entsteht eine übergeordnete Baugruppe,

die mehr ist als ihre Einzelteile. Von oben betrachtet wird das
System mit umgekehrten Vorzeichen schrittweise in voneinander
getrennte Bausteine zerlegt (Abb. 12).
Konsistenz
Strukturen, Vorgehensweisen und Entwurfsentscheidungen
sollten einheitlich und durchgehend sein. Punktuelle Ausnahmen
und Umgehungslösungen sind zu vermeiden. Dieses auch
als konzeptionelle Integrität bezeichnete Prinzip lässt sich an
einem konsistenten, in sich widerspruchsfreien Entwurfsgedanken
erkennen.
Abb. 12: ModULarisierUngsstUfen
system
daten & routinen
Klasse
subsysteme
software engineering 51
Lose KoPPLUng
Die zuvor beschriebenen Prinzipien basieren alle auf den Regeln
geringer Kopplung und hoher Kohäsion. Dabei ist die Kopplung
das Mass der Abhängigkeit eines Elementes von seiner Umgebung
und die Kohäsion der Grad des inneren Zusammenhalts
eines Elementes. Einzelne Bausteine sollten weitgehend unabhängig
voneinander arbeiten und über möglichst wenig Wissen
der anderen Bausteine verfügen müssen. Die Kopplung hängt
von der Anzahl und der Art der Verbindungen zu anderen Elementen
ab. Die Anzahl externer Referenzen, die Reihenfolge von
Aufrufen sowie technologische Aspekte beeinflussen die Kopplungsintensität.
Eine lose Kopplung sorgt dafür, dass die einzelnen
Bausteine weitgehend – sowohl in inhaltlicher wie zeitlicher
Hinsicht – voneinander unabhängig funktionieren.
hohe Kohäsion
Die Kohäsion gibt an, wie sehr die Elemente eines Bausteins inhaltlich
zusammengehören. Inhaltlich bedeutet, dass alle Elemente
demselben Zweck dienen und damit der Baustein eine
klare Zuständigkeit hat. Für eine bestimmte Funktionalität sollte
es deshalb genau einen einzigen Baustein geben.

8. dESIGNpATTERNS
software engineering 53
Komplexe Architekturen und Systeme lassen sich durch die Verwendung
dieser standardisierten Patterns und Checklisten einfacher
und vollständiger beschreiben.
definition
designpatterns sind standardisierte Lösungsschablonen
für wiederkehrende entwurfsprobleme.
Die «Gang of Four» um Erich Gamma und kurz darauf eine Autorengruppe
um Frank Buschmann initiierten mit ihren etwas
mehr als 20 Patterns eine Beschreibungssprache für den Softwareentwurf,
indem sie bewährte Lösungsmuster klar benannten,
kategorisierten und strukturiert beschrieben. Diese grundlegenden
Entwurfspatterns lassen sich in die Gruppen Erzeugung,
Struktur und Verhalten aufteilen. Die für die Architektur relevanten
Patterns sind in der nachfolgenden Grafik rot gekennzeichnet
(Abb. 13).

Abb. 13: KategorisierUng Von designPattern
erzeugung Verhalten
struktur
instanzieren
Prototype
builder
factory
entkopplung
bridge
Layering
Model-View-
Controller
Konverter
adapter
einmalig
singleton
eintrittspunkt
facade
Publish-subscribe
Verwandlung
Vermittler
observer
state
delegation
Mediator
strategy
Vererbung
template
erweiterung
decorator
Platzhalter
Proxy
Protokollant
Memento
ausführer
Command
traversieren
Visitor
iterator
ganzes-/teil
Composite
software engineering 55
Exemplarisch wird auf die drei Patterns «Layering», «Model-
View-Controller» und «Facade» näher eingegangen.
8.1 lAyERING
Das Layering oder Schichtenmodell (Abb. 14) ist wohl das bekannteste
und wichtigste Konzept der Architektur, ein Gesamtsystem
in aufeinander aufbauende, logische Abschnitte zu zerlegen.
Dabei kennt im Idealfall ein einzelner Abschnitt nur die
darunterliegende Ebene.
Abb. 14: das sChiChtenModeLL
darstellung
Vermittlung
geschäftslogik
Persistenz
Präsentationsschicht
applikationsschicht
geschäftsschicht
Listen
infrastrukturschicht
Kunde
daCL
Kunde
Controller
Kunde
detail
window
adresse
daCL
name:
adresse:
X

In der Softwarearchitektur hat sich eine Unterteilung in drei
bis vier Schichten etabliert. Auf der obersten Ebene befindet
sich die Mensch-Maschine-Schnittstelle. Die Daten der darunterliegenden
Schicht werden in der für den Anwender optimalen
Weise präsentiert und Benutzereingaben als Steuerungsbefehle
weitergeleitet. Die nächste Ebene, die Applikationsschicht,
übernimmt die Koordination zwischen der
verarbeitenden Geschäfts- und der darstellenden Präsentationsschicht.
Die dritte Ebene beinhaltet die eigentliche Logik,
unabhängig von der konkreten Interaktion mit dem Benutzer
und der darunterliegenden Infrastrukturschicht.
Wichtig ist, wie bereits bei den Architekturprinzipien aufgeführt,
die inhaltliche Entkopplung der Ebenen. Die Daten der
Präsentationsschicht sind nicht zwangsläufig dieselben wie die
der Infrastrukturschicht. So sind beispielsweise die in der Datenbank
abgelegten Kundendaten nicht identisch mit den im
individuellen Ausgabemedium verwendeten und dargestellten
Informationen.
8.2 mOdEl-VIEW-cONTROllER
MVC steht für Model-View-Controller und ist eines der ältesten
und elementarsten Entwicklungspatterns, das in moderneren
Varianten wie MVP, Supervising Controller und anderen weiterentwickelt
wurde (Abb. 15). Das MVC-Pattern fordert, die Darstellung
der Daten von der eigentlichen Geschäftslogik zu trennen.
Das Model steht für die Geschäftslogik und deren Daten. Es
software engineering 57
stellt damit die eigentliche Funktionalität des Systems dar. Die
View ist die Präsentationsschicht und verantwortlich für die Visualisierung
der Daten.
Abb. 15: ModeL-View-ControLLer
1.3: daten zurückgeben
:View :Model
1.4: daten anzeigen
1.1: gebe statistik
:Controller
1 aaa 56
2 bbb 77
3 Ccc 99
4 ddd 00
1.3: daten zurückgeben
1.2: daten aufbereiten
Der Controller schliesslich fungiert als Mediator zwischen den
beiden, indem er die durch den Bediener ausgelösten Aufträge
interpretiert und gegebenenfalls an das Model weiterleitet sowie
die erhaltenen Daten für die weitere Darstellung aufbereitet.

8.3 FAcAdE
Abb. 16: faCade
businesslogik
facade
Das Fassadenpattern (Facade) liefert eine uniforme Schnittstelle
zu unterschiedlichen Komponenten oder Klassen eines Subsystems
(Abb. 16). Es abstrahiert die Bestandteile eines grösseren
Ganzen und definiert eine einheitliche Nutzung für eine Reihe
unterschiedlicher Elemente. Im Gegensatz zur Bridge fasst eine
Fassade die Arbeit mehrerer autonomer Objekte zusammen. So
wird eine eingehende Aufgabe in der Regel auf mehrere Objekte
dieses Subsystems verteilt.
Service-orientierte Architekturkonzepte sind typische Beispiele
für solche Fassaden. Dabei wird die Bedienung eines Service
software engineering 59
durch eine Vielzahl unterschiedlicher Helfer realisiert, die durch
eine zentrale Klasse orchestriert werden. In Kombination mit
dem zuvor besprochenen Schichtenmodell ist die Fassade ein
wichtiges Instrument zur Beherrschung der stetig zunehmenden
Komplexität.

9. ImplEmENTATION
software engineering 61
Das Ziel all der vorangegangenen Tätigkeiten war und ist die
Implementation eines Stücks Code, das in seiner Funktion den
Anforderungen und Erwartungen der Auftraggeber entspricht.
Dieses Stück Code wird nach seiner erstmaligen Einführung vielen
Veränderungen, Erweiterungen und Migrationen unterzogen
werden. Es ist deshalb wichtig, Clean Code zu schreiben.
Clean Code ist einfach und strukturiert. Der Fokus ist dabei auf
die spätere Weiterentwicklung gerichtet.
hinweis
dinge so einfach wie möglich gestalten, jedoch nicht einfacher
(frei nach Albert Einstein).
die foLgende aUfzähLUng fasst die wiChtigsten MerK-
MaLe soLCher Codes zUsaMMen:
• Sinnvolle Namen: Die Namen von Klassen, Datenstrukturen,
Methoden und Attributen sind sorgfältig zu wählen.
Sie sollten etwas über den Zweck und die Funktion, jedoch
nichts über die technische Implementation aussagen.
Funktionen sind Verben und die Klassen die Nomen.
• Einfache Funktionen: Jede Funktion sollte nur gerade einen
Arbeitsschritt ausführen, der im Namen klar ausgedrückt
wird.

• Kommentar: Ziel des Kommentars ist es, die eigenen Gedan-
ken, die zum nachfolgenden Code geführt haben, niederzuschreiben.
Der Kommentar sollte nicht wiederholen, was im
Code offensichtlich ist.
• Formatierung: Eine saubere Formatierung erleichtert das Lesen.
Eine klare Struktur und eine einheitliche Darstellung lassen
auf einen besonnen und strukturiert denkenden Entwickler
schliessen. Welche Formatierung gewählt wird, ist
nicht entscheidend; entscheidend ist, dass diese konsistent
angewendet wird.
• Fehlerbehandlung: Clean Code ist robust und reagiert auf
Unvorhergesehenes zweckmässig. Bei jedem Statement ist zu
bedenken, was schiefgehen könnte, um darauf entsprechend
zu reagieren. Es ist keine Sache, einen Code zu schreiben, es
ist aber eine Meisterschaft, einen zuverlässigen Code zu
schreiben!
• Systemgrenzen: Der Einsatz von Komponenten von
Drittherstellern und die Kommunikationspfade zu den Umsystemen
sind mit Bedacht zu wählen und durch entsprechende
Klassen zu kapseln. Drittsysteme haben die Gewohnheit,
sich zu verändern und sich nicht immer so zu verhalten,
wie erwartet!
• Klassen: Auch wenn nicht objektorientiert entwickelt wird,
ist in Klassen zu denken. Dinge, die zusammengehören, sollten
zusammen sein und damit die darunterliegenden Daten
verbergen (Information Hiding).
• Concurrency: Gleichzeitigkeit ist allgegenwärtig und schwer
kontrollierbar. Da das zeitliche Verhalten im Zielsystem unbekannt
ist, muss der Zugriff auf gemeinsame Daten allein
software engineering 63
durch den Code gesichert sein. Gleichzeitigkeit kann nur ansatzweise
getestet werden, weshalb dem Design eine wichtige
Rolle zukommt.
• Nicht auf Vorrat programmieren: Es ist zu vermeiden, eine
Klasse um Operationen zu erweitern, die vielleicht irgendwann
in Zukunft nützlich sein könnten. Jeder Code – auch
ein toter – muss gewartet werden.
9.1 REFAcTORING
Nicht nur Codierungsrichtlinien und eine zweckmässige Entwicklungsumgebung
helfen, die Qualität des Codes zu verbessern.
Zentrale Methoden zur Sicherstellung guter Codequalität
sind das Refactoring und in direkter Abhängigkeit das Unit-Testing,
ohne das ein Refactoring nicht möglich wäre. Da es in der
Softwareentwicklung kaum möglich ist, ein komplexes System
auf Anhieb richtig zu entwerfen, ist der Code während der Entwicklung
ständig zu verbessern.
Fowler und Beck haben diese Tätigkeit Refactoring genannt. Es
ist die stetige Bereinigung der internen Struktur einer Software
ohne sichtbare Verhaltensänderung. Dabei wird der Quellcode
kontinuierlich überarbeitet, um ihn lesbarer und einfacher änderbar
zu machen. Doppelter oder nicht mehr benötigter Code
wird eliminiert, separate Methoden zu selbständigen Klassen
werden zusammengeführt, Namen sinnvoller gewählt und Datenstrukturen
ständig verbessert.

wiChtig zU wissen
stetige Verbesserung und überarbeitung ist ein fixer bestandteil
jeder Programmierung.
Ohne kontinuierliches Refactoring degradiert eine Software zur
Unleserlichkeit, und jede weitere Änderung wird zu einem nicht
abschätzbaren Risiko. Der Aufwand für das Refactoring ist unbedingt
in die tägliche Arbeit einzuplanen. Bei jeder Änderung des
Codes oder bei sichtbaren Anzeichen von schlechtem Programmierstil
ist der Code auf Verbesserungspotenzial zu prüfen und
zu überarbeiten.
9.2 uNIT-TESTS
Unit-Tests stellen sicher, dass mit dem Refactoring die eigentliche
Funktionalität nicht verändert wurde. Unit-Tests sind Codefragmente,
die der Entwickler selbst geschrieben hat, um das
Verhalten einer Klasse zu prüfen. Durch Unit-Tests lassen sich
Zeit und Kosten einsparen sowie die Qualität erhöhen. Unerwünschtes
Verhalten nach einer Codeänderung oder einem Refactoring
wird unmittelbar sichtbar gemacht. Dies vereinfacht
eine frühzeitige Fehlerkorrektur und macht das System zuverlässiger.
Durch die konsequente Definition der möglichen Testpfade
lassen sich gleichzeitig Mängel an den Anforderungen oder
software engineering 65
am Design feststellen. Obwohl der Initialaufwand bei der Anwendung
von standardisierten Unit-Tests etwas höher ist, können
dadurch die bei den Integrations- und Systemtests identifizierten
Fehler leichter behoben werden. Die Granularität von
Unit-Tests und welche Fälle, Klassen und Methoden zu testen
sind, muss in der Anfangsphase festgelegt werden. Ein praktikabler
Weg ist, sich auf die Hauptklassen oder diejenigen Komponenten
zu beschränken, die zur grundsätzlichen Funktionalität
beitragen oder kritisch für das Verhalten des Systems sind.
Eine weitere nicht zu unterschätzende Herausforderung ist zudem
die Wartung der Unit-Tests. Unit-Tests sind, wie der eigentliche
Code auch, zu verwalten und ständig weiterzuentwickeln,
um einen positiven Gesamtnutzen zu erhalten.

Abb. 17: diagraMMe iM ProzessabLaUf
anforderung
analyse
design
implementation
systemkontext anwendungsfälle
Logische architektur
designklassen
Verteilung
geschäftsklassen
businessobjekte
sequenz
aktivität
Name: Einchecken
Kurzbeschreibung:
Starten einer neuen Reise am Touch-Point
Primären Akteur: Reisende
Vorbedingung:
Reisende hat gültiges Konto
Basisablauf:
1. Kunde bewegt Handy an den Touch-Point
2. System signalisiert dem Handy die Erkennung
3. Handy fodert Reisende auf Check-In zu bestätigen
4. System eröffnete Reise
5. Handy zeigt erfolgreiche Eröffnung an
Nachbedingung:
Reise ist eröffnet
Komponenten
sequenz
db-Modell
software engineering 67

software engineering 69
10. mEThOdEN FüR dIE umSETzuNG
In einem Projekt werden Informationen in Disziplinen bearbeitet,
konkretisiert und den nachfolgenden Disziplinen übergeben.
Für einen reibungslosen Informationsfluss zwischen Disziplinen
und Personen in einem Projekt hat es sich bewährt, interdisziplinäre
Teams zu formen und mittels Reviews, Workshops
oder anderer Methoden die Informationen weiterzugeben. Die
vorangehende Abbildung (Abb. 17) illustriert in vereinfachter
Form am Beispiel von UML-Diagrammen, welche Teilergebnisse
die verschiedenen Disziplinen produzieren und anderen zur Verfügung
stellen.
beisPieLe für Methoden, die in den disziPLinen oder deren
übergängen angewandt werden Können:
• Anforderung: Requirements Engineering (siehe ERNI
Essential «Requirements Engineering»), Priorisierung
• Analyse: Class Responsibility and Collaboration (CRC)
Cards, Use Case Realisation Workshop, Heuristiken
• Design: Domain-Driven Design (DDD), Model-Driven
Design (MDD)
• Implementation: Test-Driven Design (TDD), Refactoring,
Unit-Tests
Beim oben genannten Vorgehen ist es wichtig, die Anforderungen
zu priorisieren.

PriorisierUng
Ziele der Priorisierung sind das frühzeitige Eliminieren von tech-
nischen Risiken und die rasche Bereitstellung der wichtigsten
Funktionen. Hierzu werden Anforderungen (Use Cases, Featurelisten
u.a.) während der Analyse durch den Architekten und die
Vertreter des Geschäfts priorisiert. Die Priorisierung untersucht
dabei die Relevanz des Anwendungsfalls in Bezug auf das Geschäft
und die Architektur und ordnet dies in einer zweidimensionalen
Matrix. Basierend auf dieser Matrix werden die Anforderungen,
beginnend mit den höchstpriorisierten, auf die Projektiterationen
verteilt und implementiert.
Use Case reaLisation worKshoP
Die Nutzen von Use Case Realisation Workshops sind die vollständige
Beschreibung von Abläufen und Datenobjekten sowie
ein gemeinsames Verständnis über die Disziplinengrenzen hinweg.
Durch die sukzessive Abbildung der Use Cases in Interaktionsdiagrammen
und im Domain Object Model entstehen das Design
Model und ein Architekturkandidat. Die Use Cases bilden
dabei die Basis der Use Case Realisation Workshops, in denen
geeignete Experten und Projekt-Stakeholder die Interaktionen
zwischen den Aktoren und dem zu entwickelnden System gemeinsam
beschreiben. Jeder Workshop behandelt dabei ein spezifisches
Thema, das sogenannte Use Case Realisation Package.
Daraus lassen sich die Systemgrenze sowie die architekturrelevanten
Schnittstellen definieren. Für jeden realisierten Use Case
muss mindestens ein Interaktionsdiagramm erstellt werden. Ak-
software engineering 71
tivitäts- und Zustandsdiagramme sowie das Domain Object Model
ergänzen das Design Model. Die Erkenntnisse aus den Workshops
müssen zeitnah konsolidiert und in der Architekturdokumentation
festgehalten werden.
CrC-Karten
Die Methode der CRC-Karten ist ein unkompliziertes und effektives
Mittel, auf spielerische Art Klassen zu finden und deren
Beziehungen untereinander aufzuzeigen (Abb. 18). CRC steht für
Class Responsibility and Collaboration, übersetzt Klassenzuständigkeit
und -zusammenarbeit.
Dabei wird auf der Vorderseite einer postkartengrossen Karte der
Zweck einer Klasse als Kurzbeschreibung aufgeführt, und auf der
Rückseite werden ihre Zuständigkeit sowie ihre Verbindungen
zu anderen Klassen beschrieben. Unterhalb der Beschreibung
der Klasse auf der Vorderseite wird ein allfällig angewandtes Entwurfspattern
erwähnt. Die Zuständigkeit auf der Rückseite sind
Operationen und Attribute, die dokumentieren, was eine Klasse
tut und was sie weiss.

Abb. 18: aUfteiLUng der CrC-Karten
Vorderseite
name der Klasse superklasse zuständigkeit zusammenarbeit
Kurzbeschreibung
der Klasse, übersicht über
aufgaben der Klasse
anzuwendende Muster
rückseite
operationen
attribute
andere Klassen
Da die Methode nicht an ein spezifisches Werkzeug auf dem
Computer gebunden ist und ihre Anwendung innerhalb weniger
Minuten erklärt werden kann, eignet sie sich hervorragend
dazu, innerhalb eines Workshops gemeinsam ein initiales Klassenmodell
zu entwerfen. In einem ersten Schritt werden mögliche
Kandidaten gesammelt, ohne diese zu bewerten. Erst in einem
zweiten Schritt werden die Vorschläge geprüft und das
Klassendesign konsolidiert. Dazu werden technologiespezifische
Klassen eliminiert und Doppelnennungen zusammengeführt.
Sodann lassen sich die Karten auf Packpapier festmachen und
ihre Interaktionspfade oder statischen Beziehungen einzeichnen.
software engineering 73

11. bEGRIFFE/GlOSSAR
deutsch (inkl.
Anglizismen)
software engineering 75
Englisch bedeutung in diesem dokument
anwendungsfall Use Case Modellelement einer Modellierungssprache
für software und andere
systeme: die anwendungsfall-beschreibung
ist eine semiformale notation,
um grobe anwenderforderungen zu
dokumentieren.
architekturansatz architectural
approach
elementare architekturstrukturen wie
Patterns, styles, Kommunikationsprotokolle
usw.
artefakt artifact Produzierte daten oder dokumente
(z.B. durch ein System).
ataM ataM architecture trade-off analysis Method:
weitverbreitete Methode zur architekturbewertung.
domäne domain fach- bzw. geschäftsbereich, in dem
das system eingesetzt wird.
geschäftsobjekte business objects geschäftsobjekte repräsentieren reale
objekte der geschäftlichen welt innerhalb
von informationssystemen.
interessenvertreter stakeholder Jemand, der direkt oder indirekt einfluss
auf anforderungen hat. beispiele: der
endnutzer, der Ceo der auftraggeberfirma,
der gesetzgeber.

deutsch (inkl.
Anglizismen)
Komponente
oder baustein
Englisch bedeutung in diesem dokument
Component Klar abgrenzbarer bestandteil innerhalb
eines systems. eine Komponente
kann sich in der software
verschiedenartig manifestieren,
z.b. als Codepaket, als Codebibliothek
oder als eigenständige
applikation.
Kompromiss trade-off ataM-begriff: eine architektureigenschaft,
die mehrere Qualitätsmerkmale
berücksichtigt.
Muster Pattern ein Muster beschreibt ganz allgemein
eine bewährte Lösung zu einem
bestimmten Problem. Muster
wurden in der softwareentwicklung
populär durch designpatterns
beschrieben und werden heute
in verschiedensten disziplinen
eingesetzt.
Qualitätsbaum Utility tree hierarchische repräsentation von
wichtigen attributsspezifischen
anforderungen, in denen die Knoten
Qualitätsziele und die blätter
szenarien darstellen.
risiko risk ataM-begriff: eine architektureigenschaft,
die im widerspruch
zu Qualitätsmerkmalen steht.
deutsch (inkl.
Anglizismen)
software engineering 77
Englisch bedeutung in diesem dokument
schnittstelle interface definierter übergang zwischen zwei
abgrenzbaren einheiten. schnittstellen
bestehen auf allen ebenen, zwischen
systemen, Komponenten oder Klassen.
sensibler Punkt sensitivity Point ataM-begriff: eine architektureigenschaft,
die bei kleinen änderungen zu
einem risiko werden kann.
UML UML Unified Modeling Language: standardisierte
sprache zur Modellierung von
software und systemen.
Umsetzung implementation Codierung der im design festgelegten
Klassen und Methoden. hier wird die
eigentliche software «produziert».

12. REFERENzEN
arLow, JiM Und iLa neUstadt.
UML 2 and the Unified Process.
Addison Wesley, 2005.
bass, Len, PaUL CLeMents Und riCK KazMan.
Software Architecture in Practice.
Addison-Wesley, 2003.
software engineering 79
ben-ari, M.
Principles of Concurrent and Distributed Programming.
Addison-Wesley, 2006.
booCh, grady.
Object-Oriented Analysis and Design with Applications.
Addison-Wesley, 2007.
eeLes, Peter Und Peter CriPPs.
Process of Software Architecting.
Addison-Wesley, 2009.
erL, thoMas.
Service-Oriented Architecture: Concepts, Technology, and Design.
Prentice Hall, 2005.
ford, neaL.
Productive Programmer.
O›Reilly, 2008.

fowLer, Martin Und Kent beCK.
Refactoring: Improving the Design of Existing Code.
Addison-Wesley, 1999.
gaMMa, eriC, et aL.
Design Pattern.
Addison-Wesley, 1995.
LanKhorst, MarC.
Enterprise Architecture at Work.
Springer, 2005.
LarMan, Craig.
Applying UML and Patterns.
Prentice Hall, 2005.
Martin, robert C. CLean Code:
A Handbook of Agile Software Craftsmanship.
Prentice Hall, 2008.
reeKie, John Und rohan MCadaM.
Software Architecture Primer.
Angophora, 2006.
rozansKi, niCK Und eoin woods.
Software Systems Architecture: Working with Stakeholders
Using Viewpoints and Perspectives.
Addison-Wesley, 2005.
sPineLLis, dioMidis Und georgios goUsios.
Beautiful Architecture.
O’Reilly, 2009.
starKe, gernot.
Effektive Software-Architekturen.
Hanser, 2008.
VogeL, oLiVer.
Software Architektur.
Spektrum, 2009.
software engineering 81
wirfs-broCK, rebeCCa Und aLan MCKean.
Object Design: Roles, Responsibilities, and Collaborations.
Addison-Wesley, 2002.

diagraMMe iM ProzessVerLaUf
anforderung
analyse
design
implementation
systemkontext anwendungsfälle
Logische architektur
designklassen
Verteilung
geschäftsklassen
businessobjekte
sequenz
aktivität
Name: Einchecken
Kurzbeschreibung:
Starten einer neuen Reise am Touch-Point
Primären Akteur: Reisende
Vorbedingung:
Reisende hat gültiges Konto
Basisablauf:
1. Kunde bewegt Handy an den Touch-Point
2. System signalisiert dem Handy die Erkennung
3. Handy fodert Reisende auf Check-In zu bestätigen
4. System eröffnete Reise
5. Handy zeigt erfolgreiche Eröffnung an
Nachbedingung:
Reise ist eröffnet
Komponenten
sequenz
db-Modell
abLaUf arChiteKtUrentwUrf
Cartoon
software requirements
specification
architekturdokument
aktivitäten
artefakte
referenzen
1.
2.
3.
4.
5.
6.
7.
8.
9.
akzeptiert
stakeholder
identifizieren
interessen
erfassen
Kontext
definieren
input
konsolidieren
szenarien
identifizieren
best Practices
und Vorgaben
identifizieren
architekturkandidaten
entwerfen
architekturoptionen
evaluieren
architektur
bewerten
software engineering 83
nicht akzeptiert
Vision
rahmenbedingungen
referenzarchitektur
architekturpatterns
andere Projekte
architektur
10.
überarbeiten

enables & delivers
www.erni-consultants.com