Professionell entwickeln mit C# 6 und Visual Studio 2015 ... entwickeln mit C# 6 und Visual Studio 2015 – Das Praxisbuch 1.209 Seiten, gebunden, 3. Auflage 2015 49,90 Euro, ISBN

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


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.


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.


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


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



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-


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



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-


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.



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.


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.


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.



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.


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



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.)


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-



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.


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



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.


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



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


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.)



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


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:



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.


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



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:


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



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.


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.



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.


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:



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


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.


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.



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



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

Documents

Professionell entwickeln mit C# 6 und Visual Studio 2015 ... entwickeln mit C# 6 und Visual Studio 2015 – Das Praxisbuch 1.209 Seiten, gebunden, 3. Auflage 2015 49,90 Euro, ISBN