LeseprobeDies ist der ideale Leitfaden fr Softwareentwickler, die beim IT- Projektmanagement nichts dem Zufall berlassen wollen. Die Lese- probe macht Sie vertraut mit Softwarearchitektur und gibt Ihnen erste Einblicke in die Neuerungen von .NET. Auerdem erhalten Sie das vollstndige Inhalts- und Stichwortverzeichnis aus dem Buch.
Matthias Geirhos
Professionell entwickeln mit C# 6 und Visual Studio 2015 Das Praxisbuch1.209 Seiten, gebunden, 3. Auflage 2015 49,90 Euro, ISBN 978-3-8362-3929-5
www.rheinwerk-verlag.de/3994
Einfhrung Softwarearchitektur und wichtige Designfragen .NET fr Fortgeschrittene
Inhaltsverzeichnis
Index
Der Autor
Leseprobe weiterempfehlen
Wissen, wies geht.
https://www.rheinwerk-verlag.de/professionell-entwickeln-mit-c-6-und-visual-studio-2015_3994/?GPP=lpnmailto:?body=Leseproben-Empfehlung:%20%C2%BBProfessionell%20entwickeln%20mit%20C#%206%20und%20Visual%20Studio%202015%20%E2%80%93%20Das%20Praxisbuch%C2%AB%20von%20Rheinwerk,%20http://gxmedia.galileo-press.de/leseproben/3994/leseprobe_rheinwerk_professionell_entwickeln_mit_c_sharp_6_visual_studio_2015_praxisbuch.pdf&subject=Leseprobe:%20%C2%BBProfessionell%20entwickeln%20mit%20C#%206%20und%20Visual%20Studio%202015%20%E2%80%93%20Das%20Praxisbuch%C2%AB
25
1Kapitel 1
1 Einfhrung
Wo die Praxis des Lebens fehlt, ist das Studium immer nur eine
halbttige Arbeit. (August Graf von Platen Hallermund)
In diesem ersten Kapitel erfahren Sie etwas ber die Motivation zu diesem Buch,
ber das verwendete Fallbeispiel, und ich stelle Ihnen die einzelnen Kapitel vor.
1.1 Lehre und Praxis der Unterschied
Erinnern Sie sich noch an die erste Generation der sogenannten RAD-Tools? Pro-
gramme sollten zusammengeklickt statt programmiert werden. Fr alle vorgefertig-
ten Probleme wren fertige Bausteine in der Toolbox, und an die Stelle von
individuellem Code sollten gut lesbare, hbsche Diagramme treten. Mit einem Satz
an Regeln sollten sich alle denkbaren Probleme lsen lassen, schnell, fehlerfrei und
ohne groen Einarbeitungsaufwand, sogar durch die Fachabteilung selbst.
Was theoretisch gut klang, scheiterte an der Praxis, an dem Variantenreichtum der
Aufgabenstellungen, der Vielzahl der Produkte auf dem Markt und nicht zuletzt
an der Fantasie der Produktmanager. Softwareentwicklung ist eben nicht mit ande-
ren Ingenieurdisziplinen vergleichbar, in denen es feste Regeln und Normen gibt, die
oft ber lange Zeitrume entwickelt wurden. Die Herangehensweisen an ein Problem
sind hchst unterschiedlich, und der daraus resultierende Code ist bei keinen zwei
Entwicklern identisch.
Softwareentwicklung ist jedoch kein wissenschaftsfreies Gebiet im Gegenteil, die
Kenntnis der theoretischen Zusammenhnge erleichtert die Entwicklung ungemein.
Aber alle Theorie muss sich in den Kontext der realen Aufgabenstellung einfgen.
Was die Statik in der Architektur der Gebude verbietet, muss die Softwarearchitek-
tur trotzdem mglich machen. Der Markt bestimmt Aussehen und Funktionalitt
einer Software, und er nimmt wenig Rcksicht auf die Sachzwnge der eingesetzten
Technologien.
Anstelle fester Lsungswege gibt es Best Practices und Patterns, Handlungsempfeh-
lungen und Lsungsskizzen, die sich wie Bausteine in eigenen Projekten verwenden
lassen, aber bei Bedarf noch zurechtgeklopft werden mssen.
3929-5.book Seite 25 Montag, 30. November 2015 3:07 15
1 Einfhrung
26
Seit einiger Zeit gibt es wieder ein neues RAD-Tool von Microsoft, Visual Studio
LightSwitch. War ich in der letzten Auflage darber noch etwas euphorisch, hat mich
die Realitt wieder eingeholt denn so recht mag das Tool nicht vom Fleck kommen,
auch nicht in Visual Studio 2015. Vielleicht liegt das auch an einem unvermeidbaren
Zusammenhang: Je komplexer die Anforderungen werden, desto komplexer werden
auch die Konfigurationen solcher RAD-Tools bis zu einem Punkt, an dem es einfa-
cher ist, eigenen Code zu erstellen, als sich durch Dutzende von Dialogen mit unzh-
ligen Optionen zu klicken.
1.1.1 Gute Software, schlechte Software
Vor rund 15 Jahren hatte ich den ersten Kontakt mit einem damals neuartigen
Online-CMS (Content Management System). Es war kurz vorher bei einem Unterneh-
men eingefhrt worden, in dem ich als Leiter der Online-Entwicklung eingestellt
wurde. Es stammte von einem renommierten Unternehmen, hatte einen klangvol-
len Namen, und die Verkufer konnten mit einer langen Referenzliste aufwarten. Es
war gruppenweit fr einen stattlichen sechsstelligen Betrag erworben worden.
Meine Aufgabe sollte es sein, auf Basis dieses Systems zahlreiche neue Online-Auf-
tritte zu entwickeln, gemeinsam mit eigenen und freiberuflichen Mitarbeitern.
Fr den Einkufer dieses CMS war das eine sichere Sache, sollte man meinen. Im
praktischen Einsatz wurden sehr bald die Mngel deutlich, und die waren gravierend:
Das System lahmte selbst auf den schnellsten Servern, es war instabil, ganz und gar
kontra-intuitiv zu bedienen, schwer zu administrieren und mit allerlei eigenen, pro-
prietren Lsungen fr ganz alltgliche Probleme ausgestattet.
Hotline, Entwicklung und Geschftsleitung des Softwareherstellers hatten das Prob-
lem lngst ausgemacht: Der Kunde sei das Problem, das System laufe schlielich in
groen Installationen zuverlssig und, soweit man wisse, problemlos. Das wollte ich
nicht recht glauben, und so begann ich, mit diesen Referenzkunden zu telefonieren
und sie zu besuchen. Und wie es zu erwarten war, glichen sich die Probleme. Viele
Unternehmen berichteten ber genau die Schwierigkeiten, die auch wir hatten.
Und so war das Ende unausweichlich: Nach einigen erfolglosen Releases tauschten
wir das System gegen ein CMS aus, das auf offenen Standards wie PHP und MySQL
aufbaute, kaum ein Zwanzigstel so teuer und wenigstens zehnmal so schnell war.
Dieses System luft auch heute noch.
Seitdem habe ich mich in zahlreichen Projekten immer wieder gefragt: Was macht
gute Software aus, und was unterscheidet sie von schlechter Software? Warum lsst
sich die eine Software elegant und preiswert erweitern, whrend sich andere Pro-
gramme vehement gegen jede Form der Anpassung struben? Warum gibt es Lsun-
gen, mit denen es sich flssig arbeiten lsst, whrend bei anderen jeder Klick zum
Geduldsspiel wird, und warum gibt es so viele gute Benutzeroberflchen, aber
3929-5.book Seite 26 Montag, 30. November 2015 3:07 15
1.1 Lehre und Praxis der Unterschied
27
1warum auch so viele schlechte? Wieso kann der Aufwand fr das Customizing einen
Bruchteil des Kaufpreises ausmachen, aber auch leicht ein Mehrfaches, und warum
mssen manche Softwareprodukte bei jedem neuen Release in groen Teilen neu
geschrieben werden, whrend andere ber viele Jahre hinweg scheinbar mhelos
erweitert werden knnen?
1.1.2 Wege zur Lsung
Ich behaupte nicht, die Antwort auf all diese Fragen zu kennen. Aber ich habe ber
die Jahre zahlreiche Muster entdeckt, Fallstricke, wenn Sie es so nennen mchten
aus den eigenen Projekten heraus, aber vor allem in der Zusammenarbeit mit mei-
nen Mitarbeitern, externen Programmierern, Auszubildenden und Consultants. Aus
meinen und ihren Erfahrungen ist dieses Buch entstanden. Es verfolgt drei Ziele:
Wissen erweitern
Gerade in kleineren Unternehmen mssen Entwickler oft wahre Allrounder sein.
Denn neben fundierten Fertigkeiten in verschiedenen Programmiersprachen ben-
tigen sie noch viele weitere Kenntnisse, beispielsweise in Fragen der Softwarearchi-
tektur, im Softwaredesign, in ihrer Entwicklungsumgebung, in den verschiedensten
eingesetzten Technologien, in Softwaretests, Projektmanagement und Datenbank-
entwurf.
Nicht jeder Entwickler hat die Zeit, Lust oder Gelegenheit, sich durch viele Regalme-
ter Fachliteratur zu arbeiten. Dieses Buch macht den durchaus gewagten Versuch, die
wichtigsten Bereiche der Softwareentwicklung in einem einzigen Werk zu behan-
deln, von der richtigen Architektur ber die Umsetzung bis hin zur Softwarepflege
nach der Einfhrung. Damit ist es ein Buch fr Aufsteiger, also Entwickler, die
dazulernen mchten und die ber Bekanntes aus einem anderen Blickwinkel neu
nachdenken wollen.
Probleme vermeiden helfen
In diesem Buch finden Sie immer wieder Ksten mit dem Titel Aus der Praxis. In
diesen Ksten finden Sie das eine oder andere Problem, das ich in der Vergangenheit
selbst erlebt habe, und meist einen Lsungsansatz dazu. Vielleicht erkennen Sie bis-
weilen Ihr eigenes Projekt darin wieder, dann betrachte ich Sie als Leidensgenossen,
wenn Sie erlauben. Ansonsten tten Sie mir einen groen Gefallen, wenn Sie diese
Probleme vermeiden wrden.
Ich habe beim Schreiben bisweilen selbst gestaunt, wie viele Fehler mir whrend der
Jahre unterlaufen sind. Viele wren leicht zu vermeiden gewesen, bei anderen lagen
die Ursachen etwas tiefer.
3929-5.book Seite 27 Montag, 30. November 2015 3:07 15
1 Einfhrung
28
Best Practices vermitteln
Der Begriff Best Practices stammt eigentlich aus der Betriebswirtschaft und bezeichnet
bewhrte Verfahren, die sich fr gleiche oder hnliche Aufgabenstellungen eignen.
Entwurfsmuster oder Design Patterns sind fertige Lsungen oder Lsungsschablonen
fr hufig wiederkehrende Probleme in der Softwareentwicklung. Sie knnen damit
ebenfalls im weiteren Sinne den Best Practices zugerechnet werden.
Myriaden von Problemen entstehen durch die falsche oder unzureichende Implemen-
tierung hufig wiederkehrender Aufgabenstellungen. Nicht selten hat jeder Entwickler
seine eigene Lsung entwickelt. Dabei sind viele dieser Aufgabenstellungen im Detail
komplex, die Lsungen aber meist zu einfach, wie das folgende Beispiel zeigt.
Aus der Praxis
Um mit Services zu kommunizieren, die mit WCF (Windows Communication Founda-
tion) entwickelt wurden, bentigt man einen Proxy, ein Objekt also, das die Kommu-
nikation mit dem Service kapselt. In vielen Lehrbchern findet man dazu Beispiele
wie:
MyServiceClient client = new MyServiceClient();client.Open();try{a
client.DoSomething();}catch(Exception ex){
MessageBox(...);}client.Close();
Dieses Beispiel funktioniert und ist daher in vielen Programmen verwirklicht. Es ist
aber wenig praxistauglich, denn Verbindungsabbrche, Timeouts, Sicherheitspro-
bleme und einige andere auftretende Ausnahmen verlangen nach jeweils speziellen
Behandlungen. Das ist unverzichtbar fr ein robustes und fehlertolerantes Pro-
gramm.
Im Grunde genommen msste sich nun jeder Entwickler in die Tiefen der WCF-Kom-
munikation begeben, um selbst eine adquate Lsung zu entwickeln, oder er greift
auf das Client-Pattern in Kapitel 6, Windows Communication Foundation, zurck.
Leider kommen Best Practices in Studium und Ausbildung meist viel zu kurz. Im Stu-
dium mag der mangelnde wissenschaftliche Bezug der Grund dafr sein, in der Aus-
bildung fehlt oft schlicht die Zeit. Und so wei ich, da ich seit vielen Jahren ausbilde,
dass viele Auszubildende nach ihrer Ausbildung oft das Gefhl haben, erst am
Anfang ihrer Entwicklung zu stehen.
3929-5.book Seite 28 Montag, 30. November 2015 3:07 15
1.2 Das Fallbeispiel
29
11.2 Das Fallbeispiel
An der einen oder anderen Stelle verwende ich ein Fallbeispiel, gewissermaen als
Kontrastprogramm zu den allerorts beliebten Hallo Welt!-Beispielen. Herzlich will-
kommen also in der Welt der Kalimba Sunfood GmbH, dem Premium-Importeur fr
sonnenverwhnte Frchte aus aller Welt mit Sitz in Hamburg.
Abbildung 1.1 Firmenlogo
Unsere Firma importiert Waren aus aller Welt und bentigt hierfr eine Enterprise-
Resource-Planning-(ERP)-Software zur Steuerung aller betrieblichen Funktionen,
also:
Warenwirtschaft
Kundenverwaltung
Finanz- und Rechnungswesen
Verkauf und Marketing
Controlling
Personalwirtschaft
Es werden etwa 800 Mitarbeiter beschftigt, die Hlfte am Stammsitz in Hamburg,
die andere Hlfte verteilt auf mehrere Standorte weltweit. Kalimba Sunfood kauft die
Frchte vor Ort ein, beispielsweise Orangen aus Brasilien oder Mangos aus Indien,
exportiert sie nach Deutschland und vertreibt sie dort an Grohndler und die
Getrnkeindustrie. Darber hinaus betreibt die Gesellschaft einen Onlineshop fr
Cocktail-Fruchtsfte, in dem Privatkunden direkt bestellen knnen.
Die beiden Niederlassungen in den USA und Indien sind breitbandig an die Zentrale
angeschlossen, ihre Mitarbeiter nutzen Rich-Client-Anwendungen. Die Bros der
Einkufer sind schmalbandig angeschlossen, daher greifen die dortigen Mitarbeiter
ber das Internet auf Webanwendungen zu. Natrlich setzt die hausinterne Entwick-
lungsabteilung auf .NET (selbstverstndlich in der aktuellen Version 4.6 als Kerntech-
nologie und dazu noch auf:
WinForms fr die Rich-Client-Anwendungen
ASP.NET fr die Webanwendungen
Kalimbasunfood
3929-5.book Seite 29 Montag, 30. November 2015 3:07 15
1 Einfhrung
30
WCF fr die serviceorientierte Mittelschicht
WF fr die Verarbeitung der Bestellungs-Workflows
Windows Server 2012R als Serverbetriebssystem
Visual Studio 2013 und 2015 als Entwicklungsumgebung
SQL Server 2012 und 2014 als Datenbanksystem
Abbildung 1.2 Standorte (Quelle: CIA Factbook)
Das zu entwickelnde ERP-System nennt unsere Firma das Kalimba.ERP.
1.3 Die einzelnen Kapitel
Das Buch orientiert sich in groben Zgen an den Entwicklungsphasen eines Projekts.
Da immer mehr Unternehmen agile Prozesse wie etwa Scrum in der Softwareent-
wicklung einsetzen, sind diese Phasen nicht mehr so starr getrennt wie frher. Sie
gehen ineinander ber und wiederholen sich hufiger in den Teilschritten eines Pro-
jekts. Dennoch erfordern alle Phasen spezielles Wissen und ihre jeweils eigenen Fer-
tigkeiten. In greren Projekten werden sie oft von verschiedenen Personen oder
Abteilungen geleitet. Was erwartet Sie auf den folgenden Seiten?
Kapitel 2, Softwarearchitektur und wichtige Designfragen
Um die Architekturfindung geht es im zweiten Kapitel. Architekturthemen sind
immer besonders wichtige Themen, da die dort getroffenen Entscheidungen meist
weittragend und nur mit hohem Aufwand whrend oder nach der Implementierung
zu ndern sind, wenn das berhaupt mglich ist.
Niederlassung,USA
Stammsitz,Hamburg
Einkaufsbro,China
Nieder-lassung,Indien
Einkaufsbro,Australien
Einkaufsbro,Sdafrika
Einkaufsbro,Brasilien
3929-5.book Seite 30 Montag, 30. November 2015 3:07 15
1.3 Die einzelnen Kapitel
31
1In der Softwarearchitektur geht es darum, die Einheiten oder Komponenten einer
Software zu identifizieren und sie zueinander in Bezug zu setzen. Dazu muss das Pro-
blem geistig zerlegt, die Strukturen mssen erkannt und Hierarchien gebildet wer-
den. Die UML kann hierbei gute Dienste leisten, weswegen wir sie uns aus praktischer
Sicht nher ansehen.
Architektur findet auf verschiedenen Ebenen statt. Auf einer unteren Ebene geht es
um Komponenten und deren Wiederverwendbarkeit, auf einer hheren Ebene um
die innere Struktur des Codes, beispielsweise die Bildung von Layer und Tier. Auf
einer der oberen Ebenen schlielich betrachten wir grundlegende Architekturpara-
digmen, beispielsweise die heute so beliebten serviceorientierten Architekturen.
Gerade beim Thema Softwarearchitektur ist es von groer Bedeutung, von der Theo-
rie zur Praxis zu gelangen. Sie wollen schlielich keine Schaubilder entwickeln, son-
dern konkrete Software. Die einzelnen Ebenen sollen ineinander bergreifen und
eine jede Schicht einen Beitrag zum Ganzen leisten. Mein Fallbeispiel soll dies illust-
rieren, im Kleinen wie im Groen. Dabei geht es mir weniger um die Darstellung
mglichst vieler Technologien als darum, Ihnen die verschiedenen Perspektiven
nherzubringen und das so, dass Sie die richtigen Fragen stellen knnen. Deshalb
gehe ich zunchst auf Anforderungen ein und weswegen sie bereits in dieser Phase
eines Softwareprojekts unverzichtbar sind.
Kapitel 3, Softwaredesign
Das dritte Kapitel beschftigt sich mit wichtigen Designfragen. Es fhrt das Thema
Architektur weiter aus, jedoch auf den unteren Ebenen, den Ebenen der Klassen,
Dateien, Assemblys und Projekte. Auch hier gibt es wieder wichtige Ziele, die den
Kontext des folgenden Kapitels bilden sollen. Danach geht es um die objektorien-
tierte Analyse und um objektorientiertes Design (OOA/OOD), mit deren Hilfe Klas-
sen gebildet und zueinander in Beziehung gesetzt werden.
Kaum eine Software kommt ohne Schnittstellen aus. Doch gerade hier lauern beson-
ders viele Fallstricke, gilt es doch, meist zwei oder mehrere an sich inkompatible Sys-
teme miteinander zu verbinden. Leider wird dieser Bereich in der Praxis hufig
vollkommen unterschtzt. Dabei ist er doch fr so viele Fehlschlge von Software-
projekten verantwortlich.
Danach geht es um die Benutzeroberflche. Keine Angst, es erwartet Sie kein Design-
kurs, und Sie mssen auch nicht zu Papier und Bleistift greifen. Unter den vielen
Facetten konzentrieren wir uns hier auf diejenigen, die Entwicklern erfahrungsge-
m am meisten Probleme bereiten. Ein hufig unterschtztes Thema ist beispiels-
weise der Umgang mit der Zeit, also mit Aktionen, die nicht innerhalb der
Wahrnehmungsspanne abgeschlossen werden knnen, sondern ein wenig lnger
dauern, wie beispielsweise eine Kopieraktion. Hier gilt, wie berhaupt beim GUI-
3929-5.book Seite 31 Montag, 30. November 2015 3:07 15
1 Einfhrung
32
Design, dass ein guter Entwurf kaum mehr Arbeit macht als ein schlechter, er erfor-
dert lediglich Wissen und die Bereitschaft, sich darauf einzulassen.
Die Frage nach dem richtigen Speicherort und der richtigen Behandlung von Konfi-
gurationsdaten ist ebenfalls eine ganz praktische und verdient einen eigenen
Abschnitt. Zum Schluss zeige ich Ihnen anhand der Enterprise Library (EL), wie gut
gemachte Bibliotheken und Tools gerade diese Phase vereinfachen knnen.
Kapitel 4, .NET fr Fortgeschrittene
Ich gehe in diesem Buch davon aus, dass Sie bereits ber C#-Kenntnisse verfgen.
Dennoch begegne ich oft Entwicklern, denen einige der neueren Sprachkonstrukte
und Technologien noch nicht gelufig sind, beispielsweise LINQ, parallele Verarbei-
tung (Multithreading) oder die Neuheiten in C# 6.
Einige der hier behandelten Technologien sind wahre Beschleuniger, beispielsweise
regulre Ausdrcke. Andere wiederum machen erst richtig Spa, wenn man sie ein-
mal etwas grndlicher betrachtet. Transaktionen sind ein gutes Beispiel dafr. Wie-
der andere Technologien sind notwendig (oder sinnvoll), wenn Sie spezielle Arten
von Anwendungen entwickeln wollen, zum Beispiel Windows-10-Apps. Und dann
gibt es noch solche, deren Einsatz sowohl Vor- als auch Nachteile mit sich bringt, die
also ein Abwgen erfordern.
Die neue Compilerplattform Roslyn erhlt ein eigenes Tutorial, nach dessen Studium
Sie Visual Studio selbst um die Fhigkeit erweitern knnen, Ihren Code zu analysie-
ren und zu verbessern eine wirklich coole Sache und uerst praktisch obendrein.
Auerdem habe ich aus der Praxis einige Stolpersteine herausgepickt, wo sich bei-
spielsweise C# nicht so verhlt, wie man es vermuten knnte.
Zu zahlreichen Themen gibt es eigene, manchmal sehr umfangreiche Bcher. Mein
Anspruch ist es also nicht, diese Themen umfassend zu behandeln; aber vielleicht ist
das gerade der Grund dafr, warum Sie sich bisher nicht damit beschftigen konnten,
und meine Praxis-Einfhrungen regen Ihr Interesse an. Dann freue ich mich mit Ihnen.
Themenauswahl und Tiefe der behandelten Themen sind mir hier besonders schwer-
gefallen, und von mir aus htte dieses Kapitel auch noch ein-, zweihundert Seiten
mehr haben knnen. Aber das Konzept des Buches ist ja gerade nicht absolute Voll-
stndigkeit, sondern das Setzen thematischer Schwerpunkte. Daher trste ich mich
also mit dem Gedanken, dass ich die Seitenzahl ohnehin bereits berschritten habe,
und hoffe, dass Sie auf der Suche nach C#-Neuigkeiten fndig werden.
Kapitel 5, Professionell codieren
Studenten, Schler und Auszubildende erfahren oft mehr ber die syntaktisch richtige
Benennung von Variablen, als sie behalten knnen, aber oft wenig bis gar nichts ber
deren sinnvolle Benennung. Sie kennen die Mglichkeiten, Kommentare als solche
3929-5.book Seite 32 Montag, 30. November 2015 3:07 15
1.3 Die einzelnen Kapitel
33
1auszuzeichnen, niemand erklrt ihnen jedoch, wann Kommentare notwendig sind
und wie diese aussehen sollten. Auch zur Formatierung des Quellcodes liest und hrt
man erstaunlich wenig. Das kommt wie gerufen fr ein Praxisbuch, und deswegen
habe ich fr Sie in diesem Kapitel viele Tipps und Empfehlungen dazu gesammelt.
Einen weiteren Schwerpunkt bilden verschiedene Konstrukte der Sprache C#. Erfah-
ren Sie hier beispielsweise, wann Sie statt auf Schnittstellen lieber auf eine Klassenhi-
erarchie setzen sollten oder was es bei Aufzhlungen zu bercksichtigen gilt. Das
Kapitel liegt mir besonders am Herzen, weil sich schnell Gewohnheiten einschleichen,
die nicht immer dem Ziel dienlich sind, qualitativ hochwertigen Code zu erzeugen.
Der wachsenden Bedeutung von Refactoring widmet sich ein eigener Abschnitt,
denn es auf Anhieb richtig zu machen ist nahezu ein Ding der Unmglichkeit, das
Lernen entlang des Weges ein Teil der praktischen Entwicklung.
Visual Studio 2015 ist wahrlich ein Schlachtschiff, dessen Beherrschung nicht immer
ganz einfach ist. Um die Sache fr Sie leichter zu machen, habe ich in diese Auflage
einige Tipps und Tricks aufgenommen, darunter auch solche, die wenig bekannt sind.
Neu ist auch ein Abschnitt, in dem ich einige Tipps zur Steigerung der Produktivitt
vorschlage.
Zum Schluss stelle ich Ihnen mit FxCop ein nettes Werkzeug vor, das ber die Einhal-
tung konfigurierbarer Regeln wacht und eigentlich unentbehrlich ist, wenn Ihr Code
sauber und wartbar sein soll.
Kapitel 6, Windows Communication Foundation
Die Antwort auf die Webservices der Java-Welt nennt Microsoft Windows Communi-
cation Foundation oder kurz WCF. Wer in der .NET-Welt serviceorientiert entwickeln
mchte, kommt daran (immer noch) nicht vorbei und muss es auch nicht: WCF bie-
tet eine Menge und lsst sich gut programmieren, erfordert jedoch von Entwickler
und Architekt auch eine andere Herangehensweise.
Wenn Sie bisher ausschlielich zweischichtig entwickelt haben darunter verstehe
ich die Anwendung und eine Datenbank (z. B. SQL Server) , dann helfen Ihnen viel-
leicht meine Ratschlge fr Neueinsteiger, die ich aus der Lernpraxis meines eigenen
Teams gewonnen habe. Dennoch ist Kapitel 6 nicht nur fr Einsteiger interessant,
sondern behandelt auch fortgeschrittene Themen wie das Hosting ber WAS oder
die Verwendung von Message Queuing in eigenen WCF-Anwendungen.
Kapitel 7, Datenbank und Datenzugriff
In Kapitel 7 geht es um einige fortschrittliche Technologien, die beraus ntzlich
sind, aber noch relativ selten in realen Projekten eingesetzt werden, wie zum Beispiel
die Mglichkeit, .NET-Assemblys in den SQL Server zu laden und dort auszufhren.
Das ist eine praktikable Methode, den Wirkungsbereich von .NET auf das Datenbank-
3929-5.book Seite 33 Montag, 30. November 2015 3:07 15
1 Einfhrung
34
Backend-System auszudehnen. Diese sogenannte CLR-Integration erffnet ganz
neue Mglichkeiten, um beispielsweise bestehenden T-SQL-Code zu migrieren oder
datenbanknahe Schnittstellen damit umzusetzen.
Gleiches gilt fr XML-Daten, also vorstrukturierte Daten innerhalb der Datenbank,
wofr der SQL Server geeignete Werkzeuge zur Abfrage und zur Manipulation bietet.
Das ist besonders fr Integrationen ntzlich. Um XML geht es auch bei LINQ to XML,
einer eleganten Mglichkeit, XML-Daten zu schreiben und abzufragen, ohne dass
dafr viel Code notwendig wre.
Weitere Abschnitte beschftigen sich mit (relativ) neuen Technologien bzw. mit
Technologien, die gerade erst erwachsen geworden sind, z. B. dem Entity Framework
und WCF Data Services. Aber die seit Visual Studio 2012 vorhandenen Datenbank-
Tools sind nicht nur hbsch, sondern auch praktisch. Schon lnger gibt es hingegen
die Volltextsuche im SQL Server, eine Technologie, die ihre Zeit trotzdem noch vor
sich hat. Ein Blick darauf lohnt sich auf alle Flle; sie ist sowohl vielseitig als auch leis-
tungsfhig.
Den Schluss bilden einige ganz praktische Empfehlungen, die dem Umstand geschul-
det sind, dass sie (zu) hufig nicht beachtet werden: der richtige Umgang mit Indizes
zum Beispiel oder die Bedeutung guter Testdaten.
Kapitel 8, Workflow Foundation
Der wesentliche Unterschied zwischen manuellen Prozessen und solchen, die in
Software abgebildet sind, liegt in der Synchronisierung. Prozesse in Software sind
meist synchron. Eine Aktion wird ausgelst, und die Verarbeitung wird so lange
unterbrochen, bis das Ergebnis vorliegt (Request/Reply-Pattern). Manuelle Prozesse
hingegen sind oft asynchron, ein Prozess wird gestartet, aber in diesem Moment
nicht abgeschlossen, beispielsweise die Genehmigung eines Einkaufs oder der Ein-
gang einer Bestellung (Fire-and-Forget-Pattern).
Seit der Version 3.0 gibt es dafr eine Untersttzung in .NET, Workflow Foundation
genannt. Damit lassen sich solche langlaufenden Workflows abbilden. Ein Workflow
kann jederzeit persistiert und spter wieder abgerufen und fortgefhrt werden.
Workflows in WF lassen sich programmieren oder, praktischer, in XAML beschreiben.
Dies hat den Vorteil, dass Sie den Workflow spter verndern knnen, ohne die
Anwendung verndern zu mssen. In .NET 4.0 erfuhr diese Technologie ein grndli-
ches Redesign, oder sagen wir lieber, sie wurde von Grund auf neu programmiert.
Damit verprellte Microsoft allerdings viele Entwickler, weil der bislang erstellte Code
aufs Abstellgleis manvriert wurde. Seit .NET 4.5 wurden wir wieder ein wenig ver-
shnt, und die Features der Workflow Foundation sind wieder nahezu komplett. In
.NET 4.6 hat sich in dieser Hinsicht wenig gendert.
3929-5.book Seite 34 Montag, 30. November 2015 3:07 15
1.3 Die einzelnen Kapitel
35
1Mit WF 4.6 lernen Sie eine vllig neue Art der Programmierung kennen: elegant,
effizient, visuell und erweiterbar. Wenn das keine guten Grnde sind, um WF zu
erlernen ?
Kapitel 9, Windows-Apps und WinRT
Wirkte die Kacheloberflche in Windows 8 noch neu und fremdartig, haben wir uns
in Windows 10 doch schon ein Stck an sie gewhnt. Wie Sie Anwendungen fr
Windows 10 entwickeln, ist Gegenstand von Kapitel 7. Sie werden sehen, es macht
Spa, damit zu arbeiten, erst recht, wenn Sie sich den Luxus eines eigenen Windows-
Tablets gnnen und nach Herzenslust durch Ihre neu entwickelten Anwendungen
scrollen intuitiv, bunt und butterweich.
Doch vor den Erfolg hat Microsoft die Lernkurve gesetzt oder genauer: zwei Lern-
kurven. Zum einen gibt es eine neue API, Windows Runtime (WinRT) genannt, die
direkt auf dem Windows-Kernel aufbaut und neue Namensrume, Methoden und
Mglichkeiten mitbringt. Zum anderen sind Windows-Apps aber auch viel standardi-
sierter als herkmmliche Anwendungen, sollen sie doch auch jenseits von Intel auf
ARM-Gerten laufen und sich einfach und schnell ber den Microsoft Store installie-
ren lassen.
Der vielleicht beste Weg, das alles zu lernen, fhrt ber ein Fallbeispiel, das daher ein
wenig umfangreicher ausgefallen ist. Aber, keine Angst, die einzelnen Abschnitte
bauen aufeinander auf, wie immer.
Kapitel 10, Softwaretests
Das Testen von Software ist oft eine ungeliebte Aufgabe, dabei ist gerade dieser Teil
der Softwareentwicklung fr das Endresultat besonders wichtig und oft genauso
erfolgskritisch. Im Kern geht es darum, Softwaretests als Teil der Entwicklung zu ver-
stehen und zu integrieren und sie nicht alleine an deren Ende zu stellen. Dabei kann
das Testen von Software auch eine sehr interessante Ttigkeit sein, mit den richtigen
Werkzeugen und jeder Menge Know-how.
Zum Glck hat sich seit .NET 4.5 und Visual Studio 2012 eine Menge getan, zum Bei-
spiel hat sich das Produkt fr andere Unit-Test-Werkzeuge geffnet und die Integra-
tion in den (ebenfalls neuen) Team Foundation Server (TFS) wurde weiter verbessert.
Softwaretests sind vor allem aber auch praktisch durchzufhren, also gerade recht
fr ein Praxisbuch der Softwareentwicklung. Und so erfahren Sie in diesem Kapitel
nicht nur etwas ber die Grundlagen, sondern auch, wie Sie am besten vorgehen und
wie Sie Ihre Tests praktisch gestalten knnen.
3929-5.book Seite 35 Montag, 30. November 2015 3:07 15
1 Einfhrung
36
Kapitel 11, Softwarepflege und Projektmanagement
Ein Kapitel ber Softwarepflege in einem Buch ber Softwareentwicklung? Passt das
zusammen? Und ob, Programme sind schlielich keine Eintagsfliegen, und nach
dem Produktiveinsatz wartet der grere Teil der Arbeit, jedenfalls ber die Zeit ge-
sehen.
Sptestens jetzt ist es hchste Zeit, sich ber Release-Zyklen, Versionsplanung und
den Umgang mit laufenden Anforderungen Gedanken zu machen. Nicht minder
wichtig und interessant sind die verschiedenen Mglichkeiten, Aufwnde zu scht-
zen, gerade dann, wenn Sie agile Methoden einsetzen, womit Kapitel und Buch
schlieen.
3929-5.book Seite 36 Montag, 30. November 2015 3:07 15
37
2
Kapitel 2
2 Softwarearchitektur und wichtige Designfragen
Wer hohe Trme bauen will, muss lange beim Fundament verweilen.
(Anton Bruckner)
Ein Kapitel ber Softwarearchitektur in einem Praxisbuch, passt das zusammen? Ja,
wenn wir Softwarearchitektur als das verstehen, was sie ist als notwendige Grund-
lage fr den Bau erfolgreicher Software.
Architektur ist kein Selbstzweck, und Architekturdiagramme sind nur selten etwas,
wofr der Auftraggeber bezahlen mchte. Der allseits bemhte Vergleich mit den
Architekten im Bauwesen stellt klar: ohne Architekt kein Gebude, ohne Software-
architekt kein Softwareprodukt. Ich meide solche Vergleiche jedoch, denn Bau- und
Softwarearchitekten haben nur wenig gemeinsam. Whrend es im Baugewerbe
unzhlige Regeln und Normen gibt, treffen wir in der Softwareentwicklung, wenn
berhaupt, auf Best Practices. Und wo sich die Bauvorhaben groteils hneln, ist jede
Software eine Einzelanfertigung. Mehr noch: Im Gegensatz zum Bauarchitekten gibt
es fr Softwarearchitekten keine allgemein anerkannte und weitverbreitete Ausbil-
dung, ja, noch nicht einmal ber deren Aufgaben besteht Einigkeit. Und einer jahr-
hundertelangen (manche wrden sagen: jahrtausendelangen) Erfahrung der
Bauarchitekten kann die Softwareentwicklung nur wenige Jahrzehnte entgegenstel-
len, wenn man die Erfahrungen aus den frhen Anfngen der Softwareentwicklung
berhaupt mitzhlen mchte.
Softwarearchitekten stehen nicht im Ruf, Pragmatiker zu sein, und meist leisten sich
nur groe Projekte einen eigenen Architekten. Dabei kann auf eine gute Software-
architektur als Grundlage fr moderne Software nicht verzichtet werden. Architektur
findet immer statt. Die Frage ist nur: Ist sie das Ergebnis planvollen Handelns vor der
Implementierung, oder entsteht sie aus der Erfahrung einzelner Entwickler heraus
whrend der Entwicklung?
Ich mchte Ihnen in diesem Kapitel die Softwarearchitektur als eigenen Teilschritt
innerhalb des Entwicklungsprozesses nherbringen. Sie werden sehen: Software-
architektur kann viel praktischer sein, als Sie vielleicht denken, und viele Fragestel-
lungen wirken direkt auf die sptere Implementierung.
3929-5.book Seite 37 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
38
Dieses Kapitel handelt zwar von der Softwarearchitektur, dennoch ist die Grenzlinie
zum Softwaredesign nicht scharf zu ziehen. Es verschmilzt daher sozusagen mit dem
nchsten Kapitel zu einer Einheit. Mein wichtigstes Ziel ist, das Feld zu bestellen, auf
dem Architektur stattfindet, und die richtigen Fragen zu formulieren, die dann zu
den richtigen Antworten fr Ihr Projekt fhren.
2.1 Einfhrung
In diesem Abschnitt werden wir Softwarearchitektur dingfest machen. Sie werden
sehen, warum es sich lohnt, Zeit darauf zu verwenden, und Sie werden die Grundzge
guter Architektur kennenlernen.
2.1.1 Das Problem
Die Kalimba Sunfood GmbH mchte ihr Angebot um eine Online-Bestellmglichkeit
fr Einzelhndler erweitern. Alice, die Programmmanagerin, und Bob, der Entwick-
lungsleiter, treffen sich zu einer Besprechung:
Alice: Hi Bob, es geht um das Konzept, das ich dir letzte Woche gemailt habe. Wie du
weit, findet in zwei Monaten die Food-Pro-Messe in Barcelona statt, und wir mch-
ten unser neues Vertriebskonzept fr Einzelhndler vorstellen. Dafr bentigen wir
einen Online-Shop, der in unsere Warenwirtschaftssoftware integrierbar ist und den
wir dort prsentieren knnen.
Bob: Okay. Dein Grobkonzept lsst aber viele Fragen offen. Wie identifizieren wir bei-
spielsweise unsere Kunden im Web, wie kommen die individuellen Verkaufskonditi-
onen auf die Internetseite, und wie luft dann die Bestellabwicklung ab?
Alice: Aber das sind doch alles technische Details, dafr seid ihr ja in der Entwicklung
zustndig. Fr mich sind die fachlichen Aspekte wichtig, die ich im Konzept doch
ausfhrlich beschrieben habe.
Bob: Nichts fr ungut, aber fr eine Umsetzung sind sieben Seiten nicht gerade aus-
reichend. Es geht auch darum, wie wir diese neue Software in die bestehende Soft-
warelandschaft einbinden knnen. Der neue Vertriebsweg ist ja nicht eigenstndig,
viele Prozesse laufen auch auerhalb der Website, beispielsweise im Kalimba.ERP,
und die Daten sollen doch zentral gespeichert werden, oder?
Alice: Von Datenbanken verstehe ich nichts, aber wenn wir die Software nicht zur
Food-Pro vorstellen knnen, dann verlieren wir Marktanteile unsere Wettbewerber
bieten solche Lsungen schon seit Jahren. Hier geht es um time-to-market, die
Lsung muss unbedingt fertig werden, in Schnheit sterben knnen wir spter auch
noch.
3929-5.book Seite 38 Montag, 30. November 2015 3:07 15
2.1 Einfhrung
39
2
Bob: Wenn wir dir jetzt eine vermeintlich einfache Lsung bauen, dann wird uns die
Pflege ein Vielfaches kosten, die Werbeabteilung hat keinen einheitlichen Blick mehr
auf den Kunden, und viele Prozesse werden manuell ablaufen mssen.
Alice: Wenn wir keine einfache Lsung zur Messe haben, dann werden die Kosten viel
hher sein. Kannst du nicht einfach einen Prototyp bauen? Wir wissen ja noch gar
nicht, wie das neue Vertriebsmodell ankommt, und deswegen steht auch kaum Bud-
get bereit. Wenn es funktioniert, dann bringen wir einfach eine Version 2 mit all den
tollen Features, die ihr Programmierer euch wnscht!
Es kommt, wie es kommen muss: Zur Messe steht eine Version 1 zur Verfgung,
ein Provisorium, fr dessen grundlegende berarbeitung dann spter Zeit und Geld
fehlen. Aber: Was ist daran auszusetzen?
2.1.2 Gute Softwarearchitektur, schlechte Softwarearchitektur
Softwarearchitektur ist schwer zu greifen, weil ihre Aufgaben so vielschichtig sind.
Dennoch gelingt es uns leicht, die Auswirkungen schlechter Architekturentschei-
dungen zu erkennen:
Merkmal Auswirkung
Komplexitt Lsungen erscheinen uns unbeherrschbar komplex, das
Gesamtbild ist nicht erkennbar, vor allem die ersten Schritte
zur Umsetzung sind unklar.
Kosten-/Termintreue Die Projektkosten laufen aus dem Ruder, der Zeitplan gert
ins Wanken. Die Lsung muss immer wieder umgebaut wer-
den, da neu entwickelte Teile nicht zu den bereits vorhande-
nen Teilen passen.
Redundanz Dieselben Aufgabenstellungen werden mehrfach gelst, in
unterschiedlichem Kontext und unterschiedlichen Modulen.
Dennoch lassen sich diese Module aber nicht mehr in ande-
ren Anwendungen wiederverwenden.
Performance Das System ist zu langsam, die einzelnen Komponenten
arbeiten nur unzureichend zusammen.
Integration Die einzelnen Module passen nicht so recht zusammen, sie
enthalten oft Hilfskonstruktionen, damit sie berhaupt
kompatibel sind, und verlieren damit an Unabhngigkeit. Es
gibt viele Schnittstellen, die alle recht unterschiedlich imple-
mentiert sind.
Tabelle 2.1 Symptome unzureichender Softwarearchitektur
3929-5.book Seite 39 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
40
Natrlich liegen die Grnde fr die oben genannten Probleme nicht ausschlielich in
einer mangelhaften Architektur. Manchmal ist auch einfach nur die Umsetzung feh-
lerhaft, oder die Tests wurden nicht gewissenhaft genug durchgefhrt. Dennoch sind
die Symptome typisch, und einige davon finden sich mit Sicherheit in einer Software
wieder, wenn der Architektur nicht der ntige Stellenwert zukommt.
2.1.3 Aufgaben
Literatur und Wissenschaft bieten uns viele Definitionen des Begriffs Softwarearchi-
tektur, aber alle Kenntnisse der altgriechischen Sprache fhren zu keiner eindeuti-
gen und, wie ich meine, brauchbaren Definition. Vielversprechender scheint mir die
Frage zu sein: Womit beschftigt sich Softwarearchitektur? Wir knnten nun einfach
sagen: Sie beschftigt sich damit, die oben dargestellten Probleme zu vermeiden! Das
wre nicht verkehrt, aber es geht auch ein wenig genauer:
In der Softwarearchitektur geht es darum,
die Komponenten eines Softwaresystems zu identifizieren,
diese in Beziehung zueinander zu bringen und die Art dieser Beziehungen zuerkennen und zu beschreiben,
die Konfiguration und deren Eigenschaften zu bestimmen,
Wartbarkeit/
Evolvierbarkeit
Neue Anforderungen lassen sich nur umsetzen, wenn immer
wieder groe Teile der Software umgebaut werden. Nur
wenige Mitarbeiter beherrschen daher die Implementierung
neuer Funktionen.
Konfiguration Anforderungen mssen programmiert werden, auch wenn
eine Konfigurationsnderung eigentlich gengt htte.
Dokumentation Die Dokumentation ist schwer zu lesen, beschreibt viele Aus-
nahmen und lsst den inneren Zusammenhalt vermissen.
Pflegephase Die Umsetzung neuer Anforderungen dauert lange, kostet
viel und birgt ein hohes Risiko fr neu auftretende Fehler.
Qualitt Anwender, Entwickler und Tester bemngeln die Qualitt
der Software. Sie benimmt sich zunehmend unberechenbar,
und der Aufwand fr die Fehlersuche und Fehlerbehebung
nimmt berproportional zu.
Merkmal Auswirkung
Tabelle 2.1 Symptome unzureichender Softwarearchitektur (Forts.)
3929-5.book Seite 40 Montag, 30. November 2015 3:07 15
2.1 Einfhrung
41
2
die Infrastruktur um diese Komponenten herum richtig auszuwhlen und richtiganzuwenden und
die einzelnen Softwaresysteme so miteinander zu verbinden, dass ein funktionie-rendes Ganzes entsteht.
Oder anders ausgedrckt: Architektur macht Komplexitt erst beherrschbar und
setzt sie in einen Rahmen. Wichtigstes Hilfsmittel ist also die Analyse. Eine Aufgabe
wird zerlegt, und die Komponenten werden den Zielen entsprechend angeordnet.
Kommunikation ist eine weitere wichtige Aufgabe heutiger Architekten, denn Archi-
tektur betrifft unmittelbar die Interessen aller Beteiligten, die man heute gerne als
Stakeholder bezeichnet. Lsungen mssen gesucht, Kompromisse ausgehandelt,
Budgets eingefordert werden. Gelegentlich berschneiden sich die Aufgaben hier
mit denen des Projektmanagers.
2.1.4 Anwendungstypen
In der praktischen Architektur ist es nicht ausreichend, Komponenten, Beziehungen
und Schichten ausfindig zu machen bzw. zu entwerfen, sondern es mssen Grundla-
genentscheidungen getroffen werden. Hier verschwimmt die Grenze zum Software-
design. Betrachten wir eine Anwendung wie das Gespann Outlook/Exchange. Mit
dieser knnen Daten auch lokal, ohne Zugriff auf einen Server, bearbeitet werden.
Eine solche Software bentigt ein anderes Design, aber auch eine andere Architektur
als eine reine Client-Server-Lsung, in der ein Server immer zur Verfgung steht.
Es ist daher sinnvoll, einige Anwendungstypen zu definieren, wobei auch hier die
Trennlinie nicht messerscharf zu ziehen ist.
Mobile Anwendung
Eine Anwendung dieser Kategorie luft auf einem mobilen Gert, also einem Gert,
das nicht fr die stndige Verfgbarkeit einer Netzwerkverbindung brgen kann, die
berdies von schlechter Qualitt sein kann. Ist das Gert beispielsweise ein Mobil-
telefon, dann gelten auch noch Hard- und Softwareeinschrnkungen. Oft synchroni-
sieren solche Anwendungen ihre lokalen Inhalte mit einem Server, manchmal setzen
sie auch eine stndige Internetverbindung voraus.
Embedded-Systeme
Hier geht es um Funktionen, die in einem technischen Umfeld bereitgestellt werden,
beispielsweise in einem Fahrzeug oder einer Industrieanlage. Oft stehen Steuerungs-
und Regelfunktionen im Vordergrund. Die darauf laufenden Anwendungen mssen
oft besonders robust sein, und bisweilen ist das Timing entscheidend, wenn es um
Echtzeitanwendungen geht. Diese Systeme sind technisch oft ber einheitliche Stan-
3929-5.book Seite 41 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
42
dards und Schnittstellen angebunden, etwa einen CAN-Bus, der hufig in Fahrzeugen
anzutreffen ist.
Services
Ein Service ist eine Komponente, die eigenstndig lauffhig ist und einem Client
Dienstleistungen anbietet, die dieser nutzen kann. Die Kommunikation luft dabei
ber Nachrichten ab, die vom Client zum Service und zurck gesendet werden.
Webanwendungen
Solche Anwendungen sind meistens plattformunabhngig, jedenfalls vonseiten des
Clients. Sie verwenden standardisierte Technologien wie http und HTML und einen
Browser fr die Anzeige der Bedienoberflche.
Rich Client Application
Anwendungen dieses Typs werden lokal (oder auf einem Terminal Server) ausgefhrt
und stellen dem Anwender meist eine reiche Benutzeroberflche zur Verfgung,
zum Beispiel aufwendige Controls oder Grafiken. Eine typische Technologie ist etwa
WinForms.
Rich Internet Application (RIA)
Wo HTML & Co. nicht ausreichen, knnen Technologien wie Silverlight (und neuer-
dings auch HTML 5) das Look and Feel einer Rich-Client-Anwendung in eine Webum-
gebung bringen. Das geschieht freilich nicht, ohne dabei einige Eigenschaften der
Webanwendung aufzugeben oder einzuschrnken, etwa die Plattformunabhngig-
keit.
Spiele
Ja, ich wei, in diesem Buch geht es manchmal ein wenig geschftig zu, wie wir in
Bayern zu sagen pflegen. Natrlich gibt es aber auch die Fun-Industrie, deren zuneh-
mendes Interesse es ist, Spiele nicht nur auf einer einzigen Plattform anbieten zu
knnen, sondern mglichst zeitgleich auf vielen verschiedenen Plattformen.
Betriebssysteme und Serversysteme
Greifen wir aus dieser groen Gruppe stellvertretend ein Beispiel heraus: Daten-
banksysteme. Diese mssen vor allem zahlreiche Standards untersttzen, perfor-
mant, robust und flexibel sein und eine reiche Tooluntersttzung mitbringen. Die
Architekturentscheidungen wirken oft weitreichend und unmittelbar, nicht nur auf
den Datenbankserver an sich, sondern auf alle damit verbundenen Anwendungen.
3929-5.book Seite 42 Montag, 30. November 2015 3:07 15
2.1 Einfhrung
43
2
2.1.5 Der Architekt
In greren Unternehmen sind Softwarearchitekten meist die erfahrensten Mitar-
beiter im Unternehmen. In kleineren Unternehmen bernehmen oft Entwickler
diese Aufgabe als Querschnittsfunktion. Wie auch immer, es gibt einige Merkmale,
die gute Architekten auszeichnen. Sie
denken analytisch, knnen auch komplexe Probleme sinnvoll zerteilen und dieKomponenten auf immer neue Weise anordnen,
kennen die eingesetzten Technologien, deren Strken und Limitationen,
haben selbst schon viel programmiert und besitzen dementsprechend viel Erfah-rung in der Softwareentwicklung,
verstehen den Anwender und entwerfen die Architektur so, dass die entstehendeSoftware fr und nicht gegen ihn arbeitet,
knnen sich auf verschiedenen Ebenen bewegen und betrachten ein Problemimmer wieder von diesen verschiedenen Ebenen aus,
besitzen ein hohes Abstraktionsvermgen, das sie aber zugunsten leichterer Ver-stndlichkeit auch einmal vor dem Gesprchspartner verstecken knnen,
passen die Architektur an die Aufgabenstellung an und verstehen, dass Architek-tur kein Selbstzweck ist,
kennen die gngigen Architekturstile und knnen diese situationsgerecht anwen-den,
beziehen alle beteiligten Personen in den Prozess mit ein, egal ob Anwender, Ent-wickler, Tester oder Systemintegratoren.
Gerade in greren Projekten gibt es auch unter den Architekten noch eine Speziali-
sierung:
Der Lead Architect trgt die Gesamtverantwortung.
Der Data Architect konzentriert sich auf die Themenfelder Datenbanken, Persis-tenz, Content Management Systeme etc. und alle sich daran angrenzenden Frage-
stellungen wie Performance, Integration und Verfgbarkeit.
Der Infrastructure Architect erstellt eine Software- und Hardwareinfrastruktur alsGrundlage fr die Anwendung selbst.
Der Integration Architect wiederum bringt die Dinge zusammen, bindet Fremd-systeme an und vereinheitlicht Schnittstellen.
Der Application Architect ist der Architekt im engeren Wortsinne, der Struktur undBeziehungen der Anwendung entwirft.
Die Rolle des Architekten ist dabei nicht immer so klar definiert, wie man sich das
wnschen wrde. Es gibt Architekten, deren Aufgaben auch in die Implementierung
und in das Produktdesign reichen. Es ist aber nicht verkehrt anzunehmen, dass
3929-5.book Seite 43 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
44
Architekten hufig in der Mitte des Prozesses zu finden sind. Sie halten Kontakt zum
Auftraggeber, Geschftsfhrer, Entwickler, zu den Administratoren und Systemin-
genieuren und zum Produktmanager. Der Architekt bentigt selbst Informationen
von diesen Personen, und diese Personen bentigen Informationen von ihm. Das
macht klar, dass Kommunikationsstrke eine wichtige Voraussetzung ist.
Und dann gibt es noch den wohl hufigsten Fall: den Architekten in Personalunion,
der diese Aufgabe nur in Teilzeit ausfhrt und nebenbei noch entwickelt oder das
Design der Software entwirft.
Nun wre das Feld bestellt. Jetzt wird es aber hchste Zeit fr mehr Praxis und was
knnte da praktischer sein als der Ursprung vielen Handelns, die Anforderung?
2.2 Anforderungen
Anforderungen stehen am Anfang einer jeden Softwarearchitektur. Obgleich ein-
leuchtend, sind die Anforderungen in der Praxis oft das schwchste Glied in der
Kette. Warum?
Oft werden die Anforderungen erst in einer viel spteren Phase des Projektsbeschrieben.
Dies liegt hufig daran, dass das Schreiben von Anforderungen von vielen Ent-
scheidungstrgern mehr als Verwaltung denn als Grundlage empfunden wird.
Klar, man braucht sie, das leuchtet meist schon ein aber besser nicht zu viel Zeit
darauf verwenden!
Eine Anforderung ist dann fertig, wenn die dafr vorgesehene Zeit aufgebrauchtist, denn Papier ist bekanntermaen ein sehr geduldiges und verzeihendes
Medium.
Es ist nicht klar, welche Anforderungen Auswirkungen auf die Architektur haben.
Daraus folgt: Anforderungen sind qualitativ und/oder quantitativ sehr hufig ein-
fach nicht ausreichend.
Ich habe es schon mehrfach angesprochen: ohne Spezifikation kein Projekt, ohne
Anforderungen keine Softwarearchitektur. Worauf sollte die denn sonst auch auf-
bauen? Anforderungen knnen von allen Projektbeteiligten stammen. Wichtig ist
nicht so sehr, wer die Anforderung stellt, sondern ob es sich wirklich um eine Anfor-
derung handelt.
Definition
Eine Anforderung ist die zwischen Auftragnehmer und Auftraggeber vereinbarte
Eigenschaft eines Systems oder eine Funktion, die diese Software erfllen soll.
3929-5.book Seite 44 Montag, 30. November 2015 3:07 15
2.2 Anforderungen
45
2
Ein Wunsch wird also erst dann zur Anforderung geadelt, wenn er Teil einer Verein-
barung ist. Das zieht die Notwendigkeit nach sich, diese schriftlich zu erfassen. ber
Anforderungen ist in diesem Buch an verschiedenen Stellen zu lesen, daher soll es
hier nur um Anforderungen zum Zwecke der Architekturfindung gehen.
2.2.1 Arten von Anforderungen
Zunchst unterscheiden wir zwischen
funktionalen Anforderungen (functional requirements), also Anforderungen, die mitden Funktionen einer Software zu tun haben, beispielsweise Berechnungen, Ablu-
fen oder verwendeten Daten. Kurzum: Es geht darum, was eine Software tun soll.
nichtfunktionalen Anforderungen (non-functional requirements) darunter fallenAnforderungen, die das System als solches qualitativ nher beschreiben. Sicher-
heit, Performance, Benutzerfreundlichkeit, Skalierbarkeit und Wartbarkeit fallen
in diese Kategorie. Hier geht es also darum, wie eine Software beschaffen sein soll.
In Projekten fehlen oft die nichtfunktionalen Anforderungen, und so entstehen
manchmal Architekturen, die am Kern einer Sache vorbeigehen. Scheinbar kleine
Anmerkungen knnen die Welt verndern, wie z. B.:
Die Anbindung soll auch funktionieren, wenn das Zielsystem zeitweise nicht zurVerfgung steht. Achtung! Lokale Datenhaltung und Replikation der Daten mit
dem Server alle wichtigen Funktionen mssen ebenfalls lokal ausgefhrt werden.
Die Daten sollen auch auf einem Notebook mitgenommen werden knnen.Achtung! Sicherheit knnte ein wichtiges Thema werden, Authentifizierung und
Autorisierung sowieso.
Wir wollen die Software spter beim Kunden erweitern knnen, beispielsweisedurch separat lizenzierte Plug-ins. Achtung! Nur lose Kopplung vorsehen, viel mit
Schnittstellen und Add-in-Strukturen arbeiten.
Die Schwierigkeit liegt oftmals darin, dass Anwender (oder Produktmanager) diese
Anforderungen nicht explizit definieren. Meist wissen sie gar nicht, welche Auswir-
kungen solche Anforderungen auf die Softwarearchitektur haben. Es wird also umso
mehr Ihre Aufgabe sein, diese Anforderungen zu hinterfragen.
Oft geschieht das nicht, aus der Befrchtung heraus, Begehrlichkeiten zu wecken.
Denn wer wrde auf die Frage Wie hoch soll denn die Verfgbarkeit sein? nicht
spontan antworten: So hoch wie mglich, am besten 100 %! Bieten Sie doch ver-
schiedene Optionen an, aus denen der Auftraggeber whlen kann, und versehen Sie
jede Option mit einem Preisschild.
Denken Sie einfach immer daran: Auch wenn eine Software alle funktionalen Anfor-
derungen erfllt, kann sie dennoch in der Praxis unbrauchbar sein. Was ntzt schon
3929-5.book Seite 45 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
46
eine korrekt funktionierende Auftragserfassung, die nicht bedienbar ist, oder eine
Software fr die Terminbrse, die nicht mit der anfallenden Last zurechtkommt?
Nicht alle dieser nichtfunktionalen Anforderungen sind fr jedes Projekt gleicherma-
en wichtig. Sie knnen sich jedoch daran orientieren, wenn Sie mchten.
Anforderung Beschreibung
Performance Beschreibt mglichst harte Kennzahlen, beispielsweise:
Das System soll in der Lage sein, in Spitzenzeiten bis zu
1.000 Bestellungen in der Minute zu verarbeiten.
Skalierbarkeit Im obigen Beispiel war schon von Spitzenzeiten die Rede, ein
Hinweis auf Skalierbarkeit. Ein weiteres Beispiel: Die Soft-
ware soll so erweiterbar sein, dass wir damit knftig unsere
Wachstumsziele abbilden knnen (die dann natrlich quan-
titativ erfasst sein mssen).
Sicherheit Definiert sicherheitsrelevante Anforderungen, zum Beispiel:
Die Komponente zur Verbindung mit unseren Zulieferern
soll in einem abgesicherten Bereich ausgefhrt werden, mit
speziellen Zugriffsrechten und ohne die Mglichkeit, auf
andere Bereiche der Software zuzugreifen.
Benutzerfreundlich-
keit
Hier es ist mitunter schwierig, dieses Merkmal messbar zu
machen. Helfen knnen Usability-Tests. Eine mgliche
Anforderung wre dann: Die Software soll eine durch-
schnittliche Benotung von 2.2 oder besser erreichen.
Erweiterbarkeit Eine allgemeine Aussage gengt hier nicht, denn von jeder
Software kann erwartet werden, dass sie erweiterbar ist. Es
geht mehr um spezielle Anforderungen wie: Es ist geplant,
bis zum Jahresende unseren Kunden drei neue Module zu
verkaufen, die diese dann separat lizenzieren und installie-
ren knnen.
Kompatibilitt Ist dann wichtig, wenn die Software kompatibel mit einem
System sein muss oder gar ein Testat bentigt wird. Beispiele:
Unsere Software muss der GDPdU-entsprechen und Der
Export muss Open XML-kompatible Dateien erstellen.
Auch Anforderungen zur Interoperabilitt knnen in diese
Kategorie fallen. Oder aber es werden gesetzliche Anforde-
rungen gestellt, beispielsweise wenn die Medizingertever-
ordnung zur Anwendung kommt.
Tabelle 2.2 Nichtfunktionale Anforderungen
3929-5.book Seite 46 Montag, 30. November 2015 3:07 15
2.2 Anforderungen
47
2
Diese Aufstellung ist zwar nicht vollstndig, aber vermutlich werden Sie damit gut
zurechtkommen. Dennoch: Vielleicht gibt es ja gerade fr Ihr Projekt zustzliche
nichtfunktionale Anforderungen? Manchmal zhlt man auch die Ressourcen zu den
nichtfunktionalen Anforderungen. Ich sehe das nicht so, denn letztlich steht das
gesamte Projekt unter den Einschrnkungen der verfgbaren Zeit und der vereinbar-
ten Kosten. Wichtig ist jedoch, dass der gesamte Prozess der Gewinnung von Anfor-
derungen dem Rechnung trgt. Oder anders ausgedrckt: Wnsche sind unbegrenzt,
Anforderungen sind es nicht.
Aber auch wenn Sie kleinere Brtchen backen alleine das Bewusstsein fr die nicht-
funktionalen Aspekte von Softwaresystemen ist der vielleicht schon wichtigste
Schritt. Sie knnen fr jeden Aspekt zudem entscheiden, ihn nicht (oder nicht sehr
weitgehend) zu bercksichtigen, was als explizite Entscheidung zu verstehen ist.
Beispiel:
Die Software Kalimba.Vertriebsinfo wird ausschlielich im Intranet von der Ver-
triebsleitung verwendet. Die Anforderungen an die Sicherheit beschrnken sich auf
eine Authentifizierung und auf ein einfaches Rollenkonzept, wobei jeder Rolle Pro-
grammfunktionen zugewiesen werden knnen.
berlassen Sie das Ergebnis nicht dem Zufall oder: besser entschieden als ignoriert!
Robustheit/Ausfall-
sicherheit
Dieser Aspekt wird oft in prozentualer Verfgbarkeit ange-
geben: Es wird eine Verfgbarkeit von 99,3 % zugesichert.
Oft sind an solche Aussagen Support Level Agreements (SLA)
gebunden und/oder es wird eine bestimmte Wiederherstel-
lungszeit gefordert (Desaster Recovery). 99,3 % mssen Sie,
nebenbei bemerkt, nicht sonderlich beunruhigen, entspricht
dies doch einem Ausfall von bis zu 61 Stunden im Jahr.
Supportbarkeit Solche Anforderungen sollten meist konkreter gefasst wer-
den, denn der Begriff an sich ist nicht sehr ergiebig. Beispiel:
Unser Support soll auf Wunsch des Kunden Zugriff auf alle
Fehlermeldungen erhalten. In diese Kategorie fallen auch
Anforderungen zu Logging und Tracing.
Dokumentation Besonders dann, wenn eine Software im Kundenauftrag
erstellt wird, kann es fr Art und Umfang der Dokumentation
gewisse Anforderungen geben. Beispiel: Der Auftragnehmer
erstellt fr die fnf wichtigsten Prozesse (...) Tutorials mit
einem Umfang zwischen 510 Seiten pro Tutorial.
Anforderung Beschreibung
Tabelle 2.2 Nichtfunktionale Anforderungen (Forts.)
3929-5.book Seite 47 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
48
2.2.2 Anatomie einer Anforderung
Nicht alle Anforderungen sind fr die Architektur entscheidend, viele von ihnen
bestimmen nur Programmfunktionen nher. Um das zu entscheiden, sind aber alle
Anforderungen zu sichten wie wollen Sie sonst wissen, welche Anforderungen Jus-
tagen an der Architektur erfordern und welche nicht?
Die meisten Anforderungen, die mir im Laufe der Zeit begegnet sind, waren wenig bis
gar nicht strukturiert. Fr einen Softwarearchitekten (und auch fr die meisten Ent-
wickler) gibt es nichts Schlimmeres, als sich durch Dutzende Seiten kafkaesken Pro-
satext zu qulen, der noch dazu unprzise, widersprchlich und lckenhaft ist. Wenn
mglich, geben Sie doch einfach den Aufbau vor. Eine Anforderung sollte enthalten:
die Bezeichnung und eine eindeutige Referenznummer
das Ziel bzw. den Zweck dieser Anforderung (eventuell noch ergnzt um den quan-titativen Nutzen, der aus der Erfllung der Anforderung entsteht)
die beteiligten Systeme und Menschen, die daran mitwirken
die Eingabedaten
die Schritte der Verarbeitung
die Ausgabedaten
die Prioritt (z. B. von 1 = wichtig bis 5 = nice to have)
die Relevanz fr die Softwarearchitektur (Diesen Abschnitt ergnzen Sie.)
Beispiel
No. FR6934:
Die Artikelstammdaten sollen in XML exportiert werden knnen.
Ziel, Zweck:
Artikel knnen so zwischen Standorten und Mandanten ausgetauscht werden, und
unsere Kunden knnen die Daten selbst weiterverarbeiten.
Beteiligte:
Der Export wird manuell gestartet.
Eingabedaten:
Alle Artikeldaten von allen Produkten, die nicht bereits stillgelegt wurden.
Schritte:
Auswahl der Programmfunktion
Auswahl eines Verzeichnisses und Dateinamen
Export
Vermerken des Vorgangs im Systemprotokoll
Ausgabedaten:
XML-Datei mit allen Artikeln und deren Daten
3929-5.book Seite 48 Montag, 30. November 2015 3:07 15
2.2 Anforderungen
49
2
Prioritt:
2 (4, wenn die Multi-Mandantenfhigkeit umgesetzt wird)
Architekturrelevanz:
Da die Daten auch fr Kunden interessant sein knnten, sollte das Exportformat
variabel sein. Auswirkung: Funktion als Plug-in im eigenen Layer implementieren.
Wenn Sie jetzt noch ein einheitliches Werkzeug zur Erfassung und Dokumentation
solcher Anforderungen einsetzen, dann haben Sie sich die Sache ein wesentliches
Stck einfacher gemacht.
Fassen wir noch einige qualitative Merkmale zusammen, die eine gute Anforderung
ausmachen:
Sie ist knapp, przise, mglichst vollstndig und konkret.
Sie ist frei von (oder sagen wir besser: arm an) Widersprchen.
Sie ist fachlich formuliert, denn diejenigen, die Anforderungen stellen, kommennur selten mit technischen Begriffen klar.
Sie stammt von den richtigen Mitarbeitern, also den Mitarbeitern, die ein Inter-esse an der jeweiligen Anforderung haben.
Sie lsst sich abschtzen bzw. messen und vermeidet allgemeine Formulierungen.
Sie bercksichtigt, dass man nicht alles haben kann. Eine Mglichkeit, dies zu zei-gen, sind Prioritten.
Idealerweise steht sie nicht alleine, sondern befindet sich in einem Kontext, bei-spielsweise ist sie Teil eines Use Cases.
Noch idealer ist es, wenn man sie gerne lesen mag, weil sie auch sprachliche Qua-litt besitzt.
2.2.3 Das richtige Ma
Wenn hier von Anforderungen die Rede ist, dann immer in dem Ma, wie sie fr die
Softwarearchitektur notwendig sind. Die beiden wichtigsten Aufgaben des Software-
architekten sind also:
1. sicherstellen, dass die Anforderungen (besonders auch die nichtfunktionalen) so
vollstndig wie mglich vorliegen
2. diejenigen Anforderungen auswhlen, die einen mageblichen Einfluss auf die
Architektur der Software haben
Die Relevanz einer Anforderung fr die Architektur ist nicht immer leicht zu erken-
nen. Vielleicht helfen Ihnen dabei einige Kriterien, die eine solche Anforderungen
erfllen kann:
3929-5.book Seite 49 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
50
Sie beschreibt eine Verbindung nach auen, beispielsweise durch eine Schnitt-stelle.
Beispiel: Eine Anwendung integriert sich in Social-Media-Plattformen.
Sie veranschaulicht einen erfolgskritischen Bereich der Software.
Beispiel: Bei einer Software fr den automatischen Versand von Newslettern wre
die Versende-Engine selbst so ein Modul.
Sie ist schwer zu erfllen.
Beispiel: Wegeoptimierung in einer Software fr die Lagerverwaltung.
Sie birgt ein gewisses Risiko.
Beispiel: Das Data Warehouse in einem Unternehmen mit seinen wichtigen
Berichten und Analysen
Sie beeinflusst mageblich die Datenhaltung.
Beispiel: Der Einsatz eines verteilten Caches zur Verbesserung der Performance
Vermutlich werden die Anforderungen den Rahmen sprengen. Das ist nicht grund-
stzlich schlecht, denn es zeigt, dass die Beteiligten auch Anforderungen haben. Und
es erffnet die Mglichkeit auszuwhlen, also die Aspekte umzusetzen, die den bes-
ten Kosten-/Nutzenfaktor versprechen. Zu guter Letzt nimmt es einen Teil des Pro-
duktlebenszyklus vorweg, denn nicht umgesetzte Anforderungen knnen ja immer
noch in einer Folgeversion umgesetzt werden.
Der gesamte Prozess zur Gewinnung solcher Anforderungen wird gerne als Require-
ments Management bezeichnet und kann in der Praxis beliebig komplex werden. Das
richtige Ma bedeutet also auch, rechtzeitig aufzuhren. Wenn Sie die Anforderun-
gen definieren, hinterfragen, auf ihre Bedeutsamkeit hinsichtlich der Architektur
untersuchen, dokumentieren und idealerweise noch priorisieren, dann sind Sie ver-
mutlich auf der sicheren Seite und knnen sich dem nchsten Schritt zuwenden, der
Identifizierung der beteiligten Komponenten.
Das richtige Ma gilt freilich auch fr die andere Seite: Fehlen Anforderungen oder
sind die vorhandenen Anforderungen lckenhaft, widersprchlich oder sonst von
minderer Qualitt, wird Ihre Architektur zwangslufig auf Annahmen grnden ms-
sen, um diese Lcken zu fllen.
2.3 Komponenten
Der Begriff Komponente ist ganz allgemein zu verstehen, nmlich als eine nahezu
beliebige Einheit eines Softwaresystems. Damit ist es eine der wichtigsten Aufgaben,
solche Komponenten erst einmal zu identifizieren.
3929-5.book Seite 50 Montag, 30. November 2015 3:07 15
2.3 Komponenten
51
2
2.3.1 Komponenten identifizieren
Dies kann beispielsweise aufgrund folgender Kriterien geschehen:
Funktionale Zusammengehrigkeit eine Komponente umfasst also Funktionen,die hnliche Aufgaben erfllen.
Beispiel: Die Komponente Login-Verwaltung beinhaltet alle Funktionen zum
Anmelden neuer Benutzer, zum Login bestehender Anwender und fr die Verwal-
tung, beispielsweise das Zusenden vergessener Passwrter.
Fachliche Zusammengehrigkeit eine Komponente bedient also denselben fach-lichen Kontext.
Beispiel: Die Komponente Werbung beinhaltet alle werblichen Aspekte, beispiels-
weise den Newsletter-Versand oder die Anreicherung der Anwenderdaten mit
Daten, die aus dem Anwenderverhalten gewonnen werden.
hnliche Daten Komponenten nutzen also dieselben Tabellen und andereDatenbankobjekte.
Beispiel: Die Komponente Kunde greift auf Objekte des gleichlautenden Daten-
bankschemas zu, beispielsweise die Kundenstammtabelle oder die Adresshistorie.
Neben diesen Ordnungskriterien gibt es noch viele weitere. In diesem Kapitel ver-
wende ich den Begriff Komponente fr jegliche Detailtiefe, was die Sache einfacher
macht. In der Literatur sind noch die Begriffe System und Subsystem anzutreffen, die
dann hufiger auf den oberen Ebenen der Architektur angewendet werden, aber hu-
fig dasselbe meinen. Mein Tipp: Trennen Sie nicht, was nicht zu trennen ist, und spre-
chen Sie in dieser Phase der Architekturfindung lieber von Komponenten.
Arten von Komponenten
Grundlagen fr die Komponenten sind:
funktionale und nichtfunktionale Anforderungen
ein umgebendes System, also die IT-Landschaft, in der die neue Applikation einge-bunden werden soll
Geschftsobjekte und Funktionsbereiche der Software
Daraus ergeben sich verschiedene Arten von Komponenten:
fachliche Fremdsysteme, z. B. eine bereits vorhandene Buchhaltungs-Software
technische Fremdsysteme, z. B. der eingesetzte SQL Server
Schnittstellen und andere Formen der Verbindung, z. B. die Anbindung an eineCRM-Software, an die Kundenstammdaten bergeben werden
3929-5.book Seite 51 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
52
explizite Grenzen, z. B. Sicherheitsgrenzen einer DMZ, in der Komponenten ausge-fhrt werden
Komponenten, die Funktionen ausfhren, z. B. eine Komponente fr die Verwal-tung des Lagers
Daten, z. B. der Speicherort fr gemeinsam genutzte Daten
technische Komponenten, z. B. die Leistungsberwachung von Windows, an dieandere Komponenten ihre Laufzeitdaten bermitteln
Infrastruktur-Komponenten, z. B. ein Enterprise Service Bus
Der Prozess
Die meisten Architekten folgen einem Top-down-Ansatz. Zuerst identifizieren sie
also die obersten Komponenten und verfeinern dann jede Komponente, bis sie den
gewnschten Grad an Detailreichtum erreicht haben.
Das klingt gut, ist in der Praxis aber hufig nicht zu realisieren. Denn eine solche Vor-
gehensweise verlangt, dass die Komponenten der Ebene nach benannt werden kn-
nen. Viel hufiger ist daher ein iterativer Ansatz anzutreffen, in der (zunchst im Top-
down-Ansatz) Komponenten identifiziert und in Beziehung zueinander gebracht
werden. Im Laufe des Prozesses werden immer mehr Anforderungen in die Architek-
tur eingebracht, und die vorhandenen Komponenten werden einem Refactoring
unterzogen: Komponenten werden entfernt, zusammengefasst, aufgeteilt, in der
Hierarchie nach oben oder nach unten versetzt oder neu angeordnet.
Um Komponenten zu identifizieren, knnen Sie die folgenden Fragen stellen:
Ist die Komponente wirklich fr eine eigenstndige Funktion zustndig, und istsie lose an andere Komponenten gekoppelt?
Ist sie auch wirklich nur fr einen Funktionsbereich zustndig?
Kann sie wiederverwendet werden, stellt sie also eigenstndige Dienstleistungenzur Verfgung?
Gibt es Einschrnkungen, die die Bildung einer eigenen Komponente erforderlichmachen, zum Beispiel weil die Komponente eine Sicherheitsgrenze darstellt?
Ist die Komponente Teil einer greren Komponente, oder ist sie unabhngig?
Ergibt sich die Komponente aus dem technischen Umfeld oder aus den fachlichenAnforderungen?
Ebenfalls hufig trifft man auf das umgekehrte Modell, also einen Bottom-up-Ansatz:
Die Komponenten werden erst einmal aus den Anforderungen destilliert und gesam-
melt. Erst im zweiten Schritt wird dann eine Struktur daraus gebildet, und jede Kom-
ponente enthlt ihren Platz. Einen pauschalen Ratschlag fr Ihre Situation kann ich
Ihnen nicht geben, so gerne ich das auch tte, aber einige Empfehlungen:
3929-5.book Seite 52 Montag, 30. November 2015 3:07 15
2.3 Komponenten
53
2
Vielleicht gibt es bereits Komponenten anderer Systeme, dann bilden diese einenersten Ordnungsrahmen.
Gleiches gilt auch fr technische Komponenten, beispielsweise einen bereits vor-handenen Anwendungsserver.
Wenig Mhe bereitet meist die Bildung von Komponenten mit einigem Umfang,zum Beispiel Werbung, Auslieferung oder Kundenverwaltung. Diese Kom-
ponenten knnen Sie dann zuerst niederschreiben und im Folgenden aufteilen,
anordnen und verfeinern.
Es lohnt sich eigentlich immer, Schnittstellen als eigene Komponenten darzustel-len.
Nicht selten sind wichtige Komponenten aus den Anforderungen schwer oder garnicht herauszulesen. Der Katalog der nichtfunktionalen Anforderungen kann
Ihnen dann weiterhelfen, wenn Sie beispielsweise fragen: Wird eine Benutzer-
und Rechteverwaltung bentigt? Daraus ergeben sich dann meist weitere Kom-
ponenten, im genannten Beispiel knnte dies die Anbindung an ein vorhandenes
Active Directory sein.
Am Ende steht ein erster Entwurf, eine Komponentensammlung. Das ist, grob gesagt,
eine Liste mit zugehrigen Beschreibungen. Mehr ist jetzt noch nicht ntig, denn die
Komponenten werden sich vermutlich gleich noch einmal ndern, wenn es um die
Beziehungen untereinander geht.
2.3.2 Beziehungen
Die Frage, wie Komponenten zusammenwirken und in welcher Beziehung sie zuein-
ander stehen, bestimmt oft mageblich die Auswahl und Abgrenzung der Kompo-
nenten selbst. Dabei knnen Komponenten auf verschiedene Weise voneinander
abhngig sein:
Hierarchisch: Komponenten haben bergeordnete allgemeinere Komponenten.
Enge Kopplung: Einzelne Komponenten sind eng aneinander gebunden, lassensich also nicht ohne diese anderen Komponenten verwenden.
Lose Kopplung: Die Komponenten sind nur lose gekoppelt, ihre Implementierunglsst sich also leichter ndern, ohne das Gesamtsystem zu gefhrden, und sie las-
sen sich fr andere Aufgaben einfacher wiederverwenden.
Dependency Injection: Die Objektnetze lassen sich zur Laufzeit knpfen, vorwie-gend durch flexible Konfiguration statt durch feste Programmierung.
Diese Abhngigkeiten sind nicht nur technisch zu sehen, sondern auch fachlich
(mit Ausnahme der Dependency Injection, die ein technisches Entwurfsmuster
3929-5.book Seite 53 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
54
beschreibt). Die technische Abhngigkeit sollte der fachlichen Abhngigkeit ent-
sprechen, wenn mglich.
Neben der Abhngigkeit gibt es noch weitere, konkretere Mglichkeiten, Beziehun-
gen zu bestimmen. Dabei geht es um die Frage, warum zwei Komponenten ber-
haupt in Beziehung zueinander stehen. Das kann sein, weil
eine Komponente Funktionen einer anderen Komponente verwendet. Beispiel:Der Service zur Verarbeitung von Bestellungen verwendet den Lagerservice,
indem er dort Abbuchungen vornimmt.
eine Komponente Daten an eine andere Komponente sendet. Beispiel: Ein E-Mail-Marketing-Werkzeug sendet der Komponente zur Verwaltung der Werbeaktionen
Informationen darber, welche Kunden welche Werbung erhalten haben.
eine Komponente beim Eintreten eines Ereignisses informiert werden mchte.Beispiel: Die Komponente zur Berechnung des Data Warehouse mchte infor-
miert werden, sobald alle Buchungen des Tages verarbeitet werden, damit sie dar-
aufhin die Berechnung der Cubes starten kann.
Beziehungen knnen unidirektional oder bidirektional sein.
Bei der Bestimmung der Beziehungen werden sich vermutlich die Komponenten
noch einmal ndern. Das ist normal und kein Anzeichen fr eine unzureichende Vor-
bereitung. Dazu ein Beispiel:
Beispiel
Eine Software fr die Verwaltung eingehender Warenmuster soll verschiedenen
Benutzergruppen verschiedene Funktionen anbieten dem Wareneingangslager
beispielsweise Funktionen fr die Zubuchung und Bestandskorrektur, dem Labor
Funktionen fr die qualitative und quantitative Bewertung der Muster. Das war
bereits aus den Anforderungen klar, Sie haben daher ein Modul fr Authentifizierung
und Autorisierung vorgesehen.
Whrend der Modellierung der Beziehungen hat sich ergeben, dass dieses Modul
selbst wiederum von dem Modul fr die Kommunikation mit den Lieferanten
abhngt, weil in diesem Modul Warenlieferungen elektronisch angekndigt werden
und Prfergebnisse in vereinfachter Form zurckgeliefert werden. Dabei berlegen
Sie, dass dies Fremdsysteme sind, die ber eigene Authentifizierungs- und Autori-
sierungssysteme verfgen. Eine mgliche Lsung wre nun, das Modul aufzubre-
chen in ein generisches Modul und in implementierungsspezifische Module, zum
Beispiel in ein Modul fr lokale Rechteverwaltung das mit dem Active Directory
verbunden ist , und in ein Modul, das mit Claims arbeitet also Securitytokens
ber das Netzwerk.
3929-5.book Seite 54 Montag, 30. November 2015 3:07 15
2.4 Prozesse
55
2
2.4 Prozesse
Komponenten und ihre Beziehungen sind kein Selbstzweck, ihr Zweck ist es viel-
mehr, an Prozessen teilzunehmen und diese dadurch erst zu ermglichen. Die Ver-
bindungen sind:
Anforderungen beschreiben Prozesse oder Teile von Prozessen.
Prozesse bedienen sich Komponenten fr die Ausfhrung.
Komponenten knnen aber auch nichtfachliche Prozesse bedienen.
Der Begriff Prozess hat viele Bedeutungen. Gemeint ist hier der Geschftsprozess als
Grundlage fr die meisten heutigen Geschftsanwendungen.
2.4.1 Was ist ein Prozess?
Prozesse bringen die Komponenten in einen zeitlichen Kontext. Aus der Ausfhrung
einzelner Aktivitten entsteht ein Prozess, wenn das Ergebnis einer Aktivitt wiede-
rum mit einer anderen Aktivitt verbunden ist. Prozesse sind charakterisiert durch:
einen Anfang
ein Ende
Aktivitten, den Bausteinen von Prozessen
Verbindungen zwischen den Aktivitten, die diese entweder schrittweise oder fall-bezogen miteinander verknpfen
ein Ziel, dem der Prozess dient
Ein Prozess befindet sich zu einem bestimmten Zeitpunkt in einem gewissen Status.
Das Unterbrechen eines Prozesses, das Speichern seines Status und seine sptere
Wiederaufnahme und Fortfhrung sind wichtige Funktionen der meisten Anwen-
dungen und damit auch Gegenstand der Softwarearchitektur. Dies gilt umso mehr,
weil die meisten Unternehmen ber ausgeprgte Ablauforganisationen verfgen,
die eine Vielzahl hchst individueller Prozesse hervorbringen, und weil viele Anwen-
dungen berhaupt erst ntig sind, weil diese Prozesse optimiert werden sollen.
Prozesse knnen ineinander verschachtelt sein. Ein Prozess ist dann Teil eines gre-
ren Prozesses, zum Beispiel ist die Ist-Aufnahme Teil der jhrlich stattfindenden
Inventur. Meist finden sich solche Modelle im Lastenheft eines Projekts. Das ist auch
gut so; allerdings knnen Geschftsprozesse auch auf die Architektur einer Anwen-
dung erheblichen Einfluss nehmen, zum Beispiel in den folgenden Fllen:
Die einzelnen Komponenten sind ber Prozesse miteinander verbunden und sol-len daher so verteilt werden, dass die Performance nicht darunter leidet.
3929-5.book Seite 55 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
56
Drittsysteme sollen in einen Prozess eingebunden werden, zum Beispiel berEnterprise Application Integration(EAI)-Software.
Der Prozess luft von auen ereignisgesteuert ab, und daher mssen Kommuni-kationssysteme entworfen werden, die auf diese Ereignisse reagieren.
Man knnte auch sagen: Prozesse bringen Komponenten in einen gemeinsamen
fachlichen Kontext. Wie so oft, wenn Dinge miteinander vernetzt werden hier die
einzelnen Aktivitten untereinander , entsteht mehr, als es die Summe seiner Teile
vermuten lsst. Dieses Mehr ist oft architekturrelevant, whrend es die einzelnen
Aktivitten hufig nicht sind.
2.4.2 Geschftsprozessmodellierung
Fr gewhnlich werden Prozesse mithilfe von Modellierungssprachen modelliert,
beispielsweise mit der Business Process Modeling Language (BPML). Ich vertrete aller-
dings die Ansicht, dass es ziemlich unwichtig ist, ob Sie BPML, ereignisgesteuerte Pro-
zessketten (EPK) oder einfache Flussdiagramme dafr verwenden, vorausgesetzt
natrlich, der Prozess lsst sich mit dem jeweiligen Werkzeug abbilden.
Wichtig erscheinen mir hingegen einige Merkmale guter Prozesse, auf die Sie unbe-
dingt achten sollten, bevor Sie eine Architektur entwerfen:
Ein Prozess trgt immer ein Datum und/oder eine Versionsnummer.
Prozesse mssen widerspruchs- und berschneidungsfrei entworfen werden. Dasbedeutet aber nicht, dass sie nicht Teil eines anderen Prozesses sein drfen, son-
dern dass Teile eines Prozesses sich nicht pltzlich in anderen Prozessen wieder-
finden (Redundanz).
Prozesse haben immer einen Anfang und ein Ende, wobei den Anfang ein vorgela-gerter Prozess und das Ende ein nachgelagerter Prozess ausmachen kann.
Przision ist eine wichtige Eigenschaft guter Prozesse, ebenfalls Vollstndigkeitund Verstndlichkeit.
Sie sollten, wenn mglich, ein Verfahren zur Beschreibung von Prozessen verwen-den und, auch das hat sich als hilfreich erwiesen, eine Software.
Zu einem Prozess gehren einerseits das Diagramm und andererseits dieBeschreibung. Nicht alle Eigenschaften, Bedingungen und Besonderheiten eines
Prozesses lassen sich in ein Diagramm quetschen.
Bei DIN A3 ist Schluss; Ausnahmen besttigen die Regel.
Vermeiden Sie die allseits beliebten Blcke mit der Aufschrift Hier geschieht einWunder. Das knnten Aktivitten sein wie Lageroptimierung oder Versand-
steuerung.
3929-5.book Seite 56 Montag, 30. November 2015 3:07 15
2.4 Prozesse
57
2
Eine Aktivitt enthlt eine Verrichtung, die Beschreibung dazu, die beteiligten Sys-teme und Abteilungen.
Es gibt keine unverknpfte Aktivitt; die Verknpfungen sind eindeutig, redun-danz- und widerspruchsfrei.
So viel zur Theorie. Wie so hufig gilt auch hier: Die Unterschiede zwischen Theorie
und Praxis sind in der Praxis einfach grer als in der Theorie. Soll heien: Prozesse
werden oft von den Fachabteilungen selbst modelliert, und die Fachleute sind nur
selten Spezialisten fr die saubere Modellierung von Prozessen und noch viel weni-
ger fr eine gewisse Notation, die der BPMN. Da hilft alles nichts: Sie mssen die Qua-
litt beurteilen und gegebenenfalls um Nachbesserung bitten und, auch das
mchte ich nicht verschweigen, das eine oder andere Mal selbst Hand anlegen. In
manchen Unternehmen oder Abteilungen mssen Sie vielleicht schon froh sein,
wenn Sie nicht blo mit Textwsten epischen Ausmaes zugeschttet werden. Ver-
stehen Sie einfach jedes Prozessdiagramm, erst recht wenn es gut gemacht ist, als
schtzenswertes Kleinod.
Vor allem aber gilt: Entwickeln Sie ein Verstndnis fr den gesamten Prozess und
lesen Sie vor allem zwischen den Zeilen und Symbolen.
2.4.3 Auswirkungen auf die Architektur
Wenn Sie einen Prozess vor sich haben, mssen Sie noch entscheiden, ob er Auswir-
kungen auf die Architektur hat oder lediglich fr die Implementierung bzw. das Soft-
waredesign wichtig ist. Einige Indizien fr mgliche Auswirkungen auf die
Softwarearchitektur sind:
Prozesse betreffen wichtige nichtfunktionale Aspekte. Beispiel: Die Ansteuerungeiner Werkzeugmaschine muss in Echtzeit erfolgen.
Es werden Schnittstellen beschrieben. Beispiel: Die Nachbestellung eines Artikels,bei dem der Meldebestand unterschritten wurde, erfolgt automatisch und direkt
an das Bestellsystem eines Zulieferers.
Es werden komplexe Aktivitten beschrieben, die eine eigene Infrastruktur erfor-dern. Beispiel: In einer Berechnungssoftware kann ein Anwender komplexe For-
meln eingeben, die eine eigene Komponente erforderlich machen.
Beispiel
In einer Anforderung zur Verarbeitung von Eingangsrechnungen findet sich dieses
einfache Prozessdiagramm:
3929-5.book Seite 57 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
58
Abbildung 2.1 Verarbeitung eingehender Rechnungen
Was sind mgliche Auswirkungen auf die Architektur und welche Fragen ergeben
sich?
Wie wird die Eingangsrechnung erfasst? Manuell oder ber eine Software zurautomatischen Erkennung solcher Belege?
Bei den Aktivitten zur Auffindung korrespondierender Bestellungen sind Kom-ponenten anderer Softwaresysteme betroffen, in denen solche Bestellungen
erfasst und ausgelst werden.
Manuell prfen bedeutet (bersetzt in die Architektursprache) einen asynchro-nen Vorgang. Eventuell sind seitens der Architektur Vorkehrungen zu treffen,
dass sich Rechnungen fr immer in dieser Aktivitt verfangen, beispielsweise
eine Watchdog-Komponente, die eine Timeout-Automatik implementiert.
Eingangsrechnungscannen
Eingangsrechnungerfassen
Bestellungvorhanden?
N
N
N
J
J
Mit Bestellungvergleichen
Manuellprfen
Stimmtberein?
Sachlichkorrekt?
Zahlen
ProzessRechnungskorrektur
auslsen
Archivieren
3929-5.book Seite 58 Montag, 30. November 2015 3:07 15
2.5 Layer (Schichten)
59
2
Die Aktivitten Zahlen und Archivieren haben Schnittstellen zur Folge, zum Bei-spiel zur Banksoftware fr die Erfassung von Auszahlungen und zu dem vorhan-
denen Archivsystem.
Von hier aus kann es nun wieder weitergehen. Wurde zum Beispiel die Anbindung an
das hauseigene Archivsystem als Schnittstellenkomponente identifiziert, lsst sich
die Beziehung dorthin modellieren, was vielleicht weitere Vernderungen nach sich
zieht. Sie sehen: Eine Architektur aufzustellen ist eben ein iterativer Vorgang.
Damit sollte nun das erste Modell stehen Sie werden es vermutlich noch weiter ver-
feinern und im Detail revidieren, aber nicht mehr grundlegend ndern. Warum auch?
Wir sind aus den Anforderungen gekommen, haben daraus Komponenten identifi-
ziert, zueinander in Beziehung gesetzt das alles auch aus der Sicht der Prozesse, an
denen sie beteiligt sind. Ihre Komponenten bilden nun die funktionalen und nicht-
funktionalen Anforderungen ab. Jetzt geht es um die nchste, feinere Ebene, die
Schichten einer Anwendung. Wir bewegen uns damit schon ein Stck auf die sptere
Implementierung zu bzw. das, was landlufig als Design bezeichnet wird.
2.5 Layer (Schichten)
Ein Layer umfasst Komponenten, die zusammengehren. Es ist damit ein wichtiges
Strukturierungsmittel innerhalb der Softwarearchitektur. Ein Layer strukturiert ein
Softwaresystem logisch.
2.5.1 Grundlagen
In Abbildung 2.2 werden drei Dinge deutlich:
Die einzelnen Layer erfllen jeweils ganz eigene Aufgaben.
Die einzelnen Layer sind zwar voneinander abhngig, aber nicht so sehr wie dieeinzelnen Komponenten innerhalb eines Layers, zum Beispiel Klassen.
Layer bilden oftmals eine Hierarchie, die durchlaufen werden muss, um eine Auf-gabe zu erfllen.
Die Kommunikation findet in genau festgelegter Form statt, idealerweise nur von
oben nach unten. Der Data Layer muss sich also um die Implementierung des Busi-
ness Layers keine Gedanken machen, und dieser wiederum kennt den Presentation
Layer nicht. Aber auch wenn die Zugriffsrichtung in der Praxis nicht immer einseitig
ist, sollten Sie in jedem Fall eine Regel beherzigen: keine Zugriffe ber einen Layer
hinweg. Im oberen Fall wrde das bedeuten, dass der Presentation Layer direkt auf
den Data Layer zugreifen wrde.
3929-5.book Seite 59 Montag, 30. November 2015 3:07 15
2 Softwarearchitektur und wichtige Designfragen
60
Abbildung 2.2 Drei Layer in einer Anwendung
Der Begriff Layer ist sehr allgemein und nicht geschtzt. In .NET begegnen Ihnen Layer
hufig in Form von Projekten. Dann wird jeder Layer durch ein eigenes Projekt abge-
bildet, oft in Form einer Klassenbibliothek (bzw. Assembly/DLL). Manchmal werden
auch Klassen als Layer bezeichnet. Nicht selten begegnen mir Anwendungen, die von
sich behaupten, vier, fnf oder gar sechs Schichten, also Layer, aufzuweisen aber nur
aus einer EXE bestehen. Gewhnen Sie sich am besten an, Layer auch in Visual Studio
als eigene Projekte anzulegen und als eigenstndige Dateien auszuliefern.
Wozu das Ganze?
Die Komplexitt wird verringert. Das scheint zwar vordergrndig nicht der Fall zusein schlielich bedeuten Layer zunchst einmal zustzlichen Aufwand , aber
die Trennung der Aufgaben in Layer frdert einen klaren und nachvollziehbaren
Programmierstil. Schlecht gemacht, trifft das Gegenteil zu: Zu viele Layer erhhen
die Komplexitt. Ich fhre das spter noch aus.
Die Sicherheit lsst sich leichter gewhrleisten, denn jeder Layer stellt auch eineSchnittstelle dar, in der sich die Berechtigungen prfen und einschrnken lassen.
Einzelne Layer lassen sich leichter austauschen. Beispielsweise knnte der DataLayer durch eine Version ausgetauscht werden, die MySQL statt des SQL Servers
von Microsoft untersttzt.
Layer frdern eine klare Zustndigkeit; sie knnen weitgehend separat entwickeltund gewartet werden. Programmierer, die von anderen Layern abhngig sind,
knnen gegen standardisierte Schnittstellen programmieren, ohne die Imple-
mentierung im Detail zu kennen.
Ich mchte Ihnen aber auch die andere Seite nicht verschweigen:
Layer kosten zustzlichen Programmieraufwand.
Jede Zeile Code birgt das Risiko zustzlicher Fehler, auch wenn der Einsatz von Lay-ern insgesamt der Softwarequalitt zutrglich ist.
Presentation Layer
Business Layer
Data Layer
3929-5.book Seite 60 Montag, 30. November 2015 3:07 15
2.5 Layer (Schichten)
61
2
Das Deployment und die Versionierung werden aufwendiger. Einerseits mssenmehr Dateien ausgeliefert werden, andererseits ist die Version jedes Layers fr die
Funktion entscheidend. Das wird klar, wenn wir in einer Benutzeroberflche ein
Control hinzufgen. Dieses zustzliche Feld muss durch alle Layer hindurch bis
zur Datenbank gefhrt werden. Es bestehen also Abhngigkeiten zwischen den
Layern.
Das Durchreichen von Informationen von Layer zu Layer macht Ihre Anwendungnicht schneller. Eine Software fr das Number Crunching ist sicherlich flacher
strukturiert als eine Software fr die Warenwirtschaft.
Manche Aufgaben fallen dadurch mehrfach an, beispielsweise die Validierung vonEingabewerten.
Daraus folgt wie so hufig in der Softwarearchitektur: Zu viel ist nichts, zu wenig ist
aber a