b2aat6n

Windows-Dienste implementieren
So beherrschen Sie den Dienst
Ein Windows-Dienst ist eng in die Infrastruktur des Betriebssystems integriert.
Das erschwert automatisierte Tests.Wenn Sie den eigentlichen Kern des Dienstes unabhängig von
der Infrastruktur halten, ist er dennoch für automatisierte Tests zugänglich.
In der Aufgabenstellung zu dieser
Übung habe ich auf zwei Risiken
hingewiesen, die bei Infrastrukturprojekten
oftmals auftreten. Zum
einen bergen sie das Risiko, den Aspekt der
Wiederverwendbarkeit zu stark zu berücksichtigen.
Zum anderen ist die Versuchung
groß, „von unten nach oben“ zu entwickeln.
Beides führt in der Tendenz dazu,
dass man zu viel tut. Nun mögen Sie sich
vielleicht fragen, was denn so schlimm daran
ist, mehr zu tun als gefordert. Sicher, es
wäre schlimmer, weniger zu tun als gefordert.
Jedoch wird beim „mehr tun“ Aufwand
getrieben, den am Ende niemand
bezahlen möchte. Möglicherweise wird sogar
der geplante Termin nicht gehalten,
weil unterwegs hier und da noch zusätzliche
„Schmankerl“ eingebaut wurden. Aus
diesem Grund sollten Anforderungen möglichst
exakt umgesetzt werden.
Und damit sind wir bei einem weiteren
Knackpunkt: Was sind denn eigentlich die
Anforderungen? Solange die nicht klar sind,
kann ein Entwickler bei der Implementierung
eigentlich nur falschliegen. Folglich
sollte er so oft wie nötig nachfragen, um
unklare Anforderungen zu präzisieren.
Nun stand ich Ihnen während der Übung
nicht als Kunde unmittelbar zur Verfügung,
aber in der Aufgabenstellung war ein Feature
explizit als „denkbare Erweiterung“
aufgeführt, nämlich das Starten und Stoppen
des Windows-Dienstes. Folglich sollte
die Implementierung so voranschreiten,
dass dieses Feature nicht sofort von Anfang
an umgesetzt wird. Andererseits darf es
auch nicht aufwendiger sein, das Feature
nachträglich zu ergänzen, statt es von vornherein
vorzusehen. Hilfreich ist es deshalb,
die möglichen Features zunächst zu sammeln.
Dann können Kunde und Entwickler
die Features priorisieren und in der „richtigen“
Reihenfolge abarbeiten.
Beim Sammeln von Features muss eine
Kundensicht eingenommen werden. Alle
Features sollen dem Kunden Nutzen bringen.
Am Ende muss schließlich der Kunde
das Feature als „fertig“ akzeptieren und ab-
nehmen. Das ist nur möglich, wenn das
Feature für den Kunden tatsächlich relevant
ist. Ein Feature wie etwa „Das Programm
von 32 Bit auf 64 Bit umstellen“
spiegelt nicht den unmittelbaren Kundennutzen
wider. Lautet das Feature jedoch
„Das Programm kann mit sehr großen Datenmengen
umgehen“, liegt der Fokus auf
dem Kundennutzen statt auf einem technischen
Detail.
Featureliste
Für die Aufgabenstellung„Windows-Dienst“
könnten die Features wie folgt aussehen:
z F1: Ein Windows-Dienst kann installiert
und deinstalliert werden.
z F2: Der Windows-Dienst kann auch als
Konsolenanwendung gestartet werden,
ohne dass man ihn vorher als Dienst installieren
muss.
z F3: Der Windows-Dienst kann gestartet
und gestoppt werden.
Abnahmekriterien
Um die Anforderungen zu präzisieren, sollten
Abnahmekriterien definiert werden.
Dadurch weiß der Entwickler, wann er mit
der Arbeit fertig ist − eben dann, wenn alle
Abnahmekriterien erfüllt sind. Die Abnahmekriterien
für Feature F1 lauten:
z Wenn der Dienst mit myservice.exe /install
installiert wird, ist er unter Systemsteuerung/Services
sichtbar.
z Der Dienst kann nach der Installation
über Systemsteuerung/Services oder net
start myservice gestartet werden (und
natürlich auch gestoppt werden).
z Wenn der Dienst mit myservice.exe/uninstall
deinstalliert wird, taucht er unter
Systemsteuerung/Services nicht mehr auf.
Spätestens an dieser Stelle beschleicht
mich der Verdacht, dass hier mit automatisierten
Tests nicht viel auszurichten ist. Am
Ende hilft es nichts, der Dienst muss mit
dem Betriebssystem korrekt zusammenarbeiten.
Das lässt sich nur durch einen Integrationstest
wirklich sicherstellen. Das bedeutet
nun nicht, dass wir gar keine auto-
matisierten Tests sehen werden, aber es
werden wenige sein.
Entwurf
LÖSUNG
Für Feature F1 kann nun eine Architektur
entworfen werden. Dabei ist einerseits zu
berücksichtigen, dass möglicherweise nicht
alle Features sofort implementiert werden.
Ein Feature wird nach dem anderen implementiert,
niedrig priorisierte möglicherweise
gar nicht. Wird ein Feature nach dem
anderen implementiert, bietet das für den
Kunden sehr viel Flexibilität: Er kann die
Priorisierung von Features jederzeit ändern.
Und er kann Features streichen oder auch
neue hinzunehmen. Logischerweise gilt dies
nicht für Features, die bereits in Arbeit sind.
Aber alle noch nicht begonnenen Features
stehen zur Disposition. Folglich sollte ein
Architekturentwurf nur die Features im
Detail berücksichtigen, die konkret zur Implementierung
anstehen. Da weitere mögliche
Features schon bekannt sind, kann
und sollte man diese beim Architekturentwurf
im Blick behalten. Diese Features sollten
jedoch keinen nennenswerten Einfluss
auf die Architektur nehmen, denn es droht
jederzeit das Risiko, dass sie doch nicht benötigt
werden. Gefragt ist also ein Blick über
den Tellerrand der anstehenden Features,
ohne dass man dabei gleich zu viel tut. Orientierung
liefert die Fokussierung auf den
Kundennutzen. Für den Kunden ist es weitaus
angenehmer, das wichtigste Feature
einsatzbereit geliefert zu bekommen, als
viele unvollendete Features, die nicht einsatzbereit
sind.
Um einen möglichst flexiblen Architekturentwurf
zu erreichen, müssen die beteiligten
Funktionseinheiten lose gekoppelt
sein. So ist die Wahrscheinlichkeit groß,
dass zusätzliche Features leicht integriert
werden können. Es liegt also auf der Hand,
hier Event-Based Components (EBC) zu
verwenden. Doch bevor es so weit ist, müssen
die Anforderungen weiter präzisiert
werden, denn noch ist nicht klar, wie die
geforderte Dienstinfrastruktur eingesetzt
werden soll.
www.dotnetpro.de dotnetpro.dojos.2011 45