Statische Code Analyse mit NDepend 6

Die neue Version 6.2 von NDepend ist nun seit einigen Tagen verfügbar. Grund genug um zu überprüfen was sich seit meinem letzten Beitrag im April 2014 alles in Sachen statischer Code Analyse bei NDepend verändert hat.

Buch-Rezension zu „Patterns of Enterprise Application Architecture“

Egal mit was für einer Technologie oder Framework man sich beschäftigt, das Buch „Patterns of Enterprise Application Architecture“ von Martin Fowler wird wohl ein Kapitel dazu beinhalten.

MVC? OR-Mapper? Lazy-Loading? Unit of Work? Layering? Session State? Oder braucht man Tipps zur Strukturierung von Geschäftslogik? Fast jedes Thema das man beim Schreiben von Geschäftsanwendungen antrifft wird in diesem Buch behandelt und dessen Platz im grossen Puzzle erklärt.

 

Teil 1: Eine Übersicht zu Geschäftsanwendungen und deren Problemstellungen

Auf rund 100 Seiten erhält man eine Übersicht über die einzelnen Teile die eine Geschäftsanwendung ausmachen. Die Problemstellung wird so erklärt das man auch als Einsteiger in dieses Thema problemlos folgen kann.

Neben einer Definition der Begriffe erfährt man wo die Herausforderungen liegen und wie man durch eine geschickte Wahl der passenden Entwurfsmuster den eigenen Code von den häufigsten Problemen fernhält.

Wer sich schon länger mit Geschäftsanwendungen beschäftigt kann diesen Teil getrost überspringen. Man wird die besprochenen Probleme schon selber oft genug erlebt haben und möchte wohl gleich zu den passenden Lösungen im 2. Teil.

 

Teil 2: Die Patterns

Die Muster sind thematisch geordnet und nehmen die Reihenfolge aus dem 1. Teil auf. Dies macht das Buch sehr angenehm zu lesen da man so auf ein wildes hin und her springen verzichten kann.

Jedes dieser Muster wird nach dieser Schablone erklärt:

1. Welche Probleme lassen sich damit lösen
2. Ein UML-Diagramm
3. Detaillierte Erklärung wie das Pattern funktioniert
4. Eine Empfehlung wann man dies einsetzen soll (und wann nicht)
5. Weiterführende Unterlagen
6. Ein Beispiel mit Code in C# oder Java

Der grösste Nutzen liegt aus meiner Sicht nicht bei der Vorstellung der Patterns an sich, sondern beim Auflisten der Vor- und Nachteile. Stösst man im Projekt an Grenzen kann man entweder alles umbauen oder hier nachschauen was Fowler für Anpassungen empfiehlt. Dabei aber unbedingt überprüfen ob die von Fowler erwähnten Einschränkungen nicht zu noch grösseren Problemen führen. Sonst steht man nach viel Arbeit wieder an der gleichen Stelle.

 

Katalog der Enterprise Application Patterns

Wie für die Refactoring-Patterns gibt es von Martin Fowler auch einen Katalog zu den Enterprise Application Patterns. Darin werden die Patterns mit einer kurzen Beschreibung und dem UML-Diagramm vorgestellt. Dies genügt um sich über die Patterns zu unterhalten, wer allerdings eine Anwendung bauen will wird nicht um das Buch herum kommen.

 

Fazit

Mit Ausnahme von REST erklärt dieses Buch alles was heute bei den meisten Geschäftsanwendungen zum Einsatz kommt. Dabei handelt es sich nicht um irgendwelche an den Haaren herbeigezogenen Spezialfälle, sondern um konkrete Lösungen zu konkreten Problemen.

Wenn man auch intuitiv auf zahlreiche Lösungen selber kommen kann ist dieses Buch doch eine sehr hilfreiche Sammlung. Dies vor allem da auch Alternativen gezeigt und Einschränkungen offen angesprochen werden.

 

Zum Buch

„Patterns of Enterprise Application Architecture“ von Martin Fowler, 2002 Addison-Wesley, ISBN 978-0-3211-2742-6, 560 Seiten, Englisch

Von fachlichen und technischen Daten

In einer Geschäftsanwendung werden vor allem fachliche Daten bearbeitet. Daneben gibt es aber eine ganze Reihe von technischen Daten (wie einer ID oder einem Erstelldatum). Diese beiden Arten von Daten können problemlos nebeneinander abgelegt werden. Sobald man allerdings beginnt die Grenzen zu verwischen fangen die Probleme an.

Bis sich die Auswirkungen dieser Vermischung bemerkbar machen kann man sich meist nicht mehr an die dazugehörigen Entscheidungen erinnern. So beginnt ein mühsames Suchen nach den Ursachen von teils äusserst seltsamen Fehlern.

Ich will gar nicht zusammenrechnen wie viele Stunden ich so verloren habe. Dabei waren es zu Beginn jeweils ganz kleine Entscheidungen die am Ende zu solchen Problemen führten. Wie klein die sein können soll das nachfolgende fiktive Beispiel rund um Auftragsformulare zeigen.

 

Wenn aus technischen Daten fachliche werden…

Meist beginnt alles mit einer kleinen zusätzlichen Anforderung. Neu soll beispielsweise das Eingangsdatum eines Formulars geführt werden. Man kann nun ein zusätzliches Feld „Eingang“ anlegen oder den Wert ins Feld „Erstellt“ hineinschreiben. Das ist ja für die Anwendung das gleiche, da alle Formulare beim Eintreffen erfasst werden.

Allerdings wird das Feld „Erstellt“ durch die Anwendung hinweg immer als technisches Feld betrachtet das man weder auf der Oberfläche anzeigt noch irgendwie sonst verwendet. Damit ist es nun vorbei. Für das Objekt „Formular“ wird das Feld „Erstellt“ nicht nur angezeigt sondern auch noch gleich umbenannt – allerdings nur auf der Oberfläche. Und in den Reports. Und im Export. Und bei allen anderen zukünftigen Verwendungen dieses Objekts.

 

… und dies zu Problemen führt

Die Sonderregelung für „Formular“ ist zu diesem Zeitpunkt schon aufwändig aber noch kein Problem. Dazu braucht es meist noch eine kleine Veränderung der Geschäftsabläufe, wie einer externen Erfassung der Formulare.

Um diese externe Erfassung zu ermöglichen kommt dann oft eine Excel-Liste als Transfermethode zum Einsatz. So müssen die externen Sachbearbeiter nichts Neues lernen und im Zielsystem wird eine kleine Importfunktion hinzugefügt. Soweit ist dies ebenfalls noch kein Problem. Doch was soll nun ins Feld „Erstellt“ geschrieben werden? Das Datum an dem die Daten importiert wurden oder das Eingangsdatum?

Aus fachlicher Sicht muss das Eingangsdatum gesetzt werden, da sich zwischen dem Eingang und dem Import Preise verändert oder Fristen abgelaufen sein könnten. Aus technischer Sicht wird das Formular mit dem Import erstellt.

Das Problem ergibt sich sobald beide Sichten „ihr“ Datum benötigen. Das technische Erstelldatum könnte beispielsweise für einen Report zur internen Kostenverrechnung dienen. Wird dieser Report nach Eingang aber vor dem Import der Formulare ausgeführt stimmen die Werte nach dem Import nicht mehr mit dem Datenbestand in der Applikation überein. Die importierten Formulare fehlen im Report, werden daher nicht verrechnet und Ende Jahr gilt es zu klären woher die Differenz kommt.

 

Ursachen

Bei den Fällen die mir bekannt sind war die Ursache oft eine verfrühte Optimierung oder der krampfhafte Versuch Diskplatz zu sparen. Weder der zusätzliche Speicherplatz noch der Aufwand ein Feld mehr anzulegen hätte man bemerkt. Im Gegensatz zu all dem Aufwand zum Aufspüren der fehlerhaften Auswertungen.

Bitte beachten: DRY (Don’t repeat yourself) gilt nur wenn es sich wirklich um die gleichen Dinge handelt. Andernfalls ist dies keine Repetition sondern erfüllt einen anderen (unabhängigen) Zweck.

 

Wie verhindern?

Im obigen Beispiel hätte man spätestens als die Importfunktion erstellt wurde die Datenfelder trennen müssen. Allerdings denkt in so einem Moment niemand an solche Zusatzaufgaben. Und nur um Daten genauer abzulegen will niemand all die Oberflächen und Reports anpassen.

Daher bin ich mittlerweile der Meinung dass bei den ersten Anzeichen einer fachlichen Verwendung der technischen Daten die Alarmglocken läuten müssen. Fängt man an bei einzelnen Objekten technische Felder einzublenden ist dies ein deutliches Zeichen das hier ein fachliches Feld fehlt. Der Aufwand dies jetzt gleich sauber zu lösen ist geringer als wenn man wartet bis dieses Feld überall verwendet wird. Und fehlt doch gerade die Zeit kann man immer einen entsprechenden Task eröffnen und im nächsten Sprint (mit zusätzlichen Informationen) beheben.

Dies gilt übrigens im gleichen Masse für fachliche Felder die technisch genutzt werden, auch wenn dieser Fall wohl weniger oft vorkommt.

 

Fazit

Das Single Responsibility Principle (SRP) gilt nicht nur für Klassen und Methoden, sondern auch für Daten. Bevor man für eine kleine Einsparung bei der Datenmenge anfängt Felder mehrmals zu verwenden sollte man sich über die möglichen Konsequenzen bewusst werden und darauf verzichten. Angesichts der aufwändigen Fehlersuche bezweifle ich das durch ein „eingespartes“ Feld wirklich Kosten gespart werden können.

Buch-Rezension zu „Domain-Driven Design“

Wenn man sich mit Behavior Driven Development (BDD) und dem Schreiben von Akzeptanztests beschäftigt stösst man immer wieder auf ein Buch:
„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans.

Dieses Buch gilt weit herum als Standardwerk das man unbedingt kennen muss. Beim Lesen merkt man schnell das Evans sehr viel Erfahrung hat und weiss wovon er schreibt. Leider macht er dies so ausführlich dass man kaum vorwärts kommt. „Man müsse die Informationen herausschürfen“ ist eine Bemerkung über dieses Buch die man beim Lesen im Hinterkopf behalten sollte.

 

Kernpunkte

Von all den Themen die Evans behandelt stechen für mich diese Punkte besonders hervor:

Mit Hilfe einer Ubiquitous Language (einer einzigen gemeinsamen Sprache) sollen alle am Projekt beteiligten Personen kommunizieren. Dadurch das alle die gleichen Begriffe benutzen können Missverständnisse und Übersetzungsprobleme (im Sinne von Fachspezifisch zu Technisch) früh erkannt werden oder entfallen ganz. Auch ist es für Entwickler einfacher sich an die Spezifikationen zu halten wenn die Objekte im Code gleich heissen wie in den Anforderungen und den Testszenarios.

Bei Refactoring denkt man meistens an einen technischen Vorgang um Code besser zu strukturieren. Neben diesem technischen Aspekt gibt es aber auch einen fachlichen. Evens zeigt bei „Refactoring Toward Deeper Insight“ auf wie man nach und nach das Domänenmodell um neue Erkenntnisse verfeinern kann.

Entwickelt man nach Model Driven Design darf das Modell nicht in einem Vakuum erstellt werden. Ist dieses Modell technisch nicht umsetzbar wird in der Entwicklung gezwungenermassen eine Lösung gefunden die davon abweicht. Damit verliert man alle Vorteile und muss ständig zwischen mehreren Modellen hin und her wechseln. Neben höheren Kosten leidet dabei auch die Kommunikation.

Bounded Context: Das eigene Domänenmodell kann noch so gut sein, wenn man es nicht abgrenzt fliessen die unterschiedlichen Konzepte der Umsysteme hinein. Evens zeigt eine ganze Reihe von Ansätzen um dies zu verhindern (wie das Pattern „Anticorruption Layer“).

Software-Entwicklung ist mehr als das Schreiben von Code. Es geht um das Lösen von Problemen. Damit man die passende Lösung finden kann ist eine Zusammenarbeit mit allen beteiligten Parteien nötigt.

 

Kritik

Die gleichen Namen und Bezeichnungen zu verwenden ist ein grosser Schritt in die richtige Richtung. Nur ist es damit nicht getan. Mir fehlt wie man auch zu einer gemeinsamen Bedeutung kommt und überhaupt die Wiedersprüche aufdecken kann. (Wenn alle von Autos sprechen, wie merkt man das der eine einen Golf meint und der anderen einen Ferrari?)

Die ersten beiden Teile sind sehr schwerfällig geschrieben. Immer wieder springt Evans von einer Idee zur nächsten und wieder holt dieses hin und her mehrmals. Würde dies aus unterschiedlichen Perspektiven geschehen wäre dies ein Plus fürs Buch. Leider sucht man die ganze Zeit nach den Unterschieden zum bereits behandelten und findet meist keine. Dies bremst den Lesefluss und schlägt auf die Motivation.

Anstelle der vielen Wiederholungen wären Beispiele zur technischen Umsetzung hilfreich. Statt so viel über Code zu sprechen hätte Evens diesen zeigen können – dies ginge schneller und hätte einen Praxisnutzen. So bleibt zu viel eine schöne Idee ohne Hinweis auf deren Umsetzung.

 

Alternative

Abel Avram und Floyd Marinescu sahen ebenfalls einige Verbesserungsmöglichkeiten und schrieben 2006 das Mini-Book „Domain Driven Design Quickly„. Auf rund 100 Seiten gibt es all die Konzepte aus dem Buch von Evans, ein Interview mit ihm und es hat noch Platz für Ergänzungen aus „Applying DDD“ von Jimmy Nilsson.

Wer ins Thema DDD einsteigen will sollte sich erst einmal das PDF bei InfoQ herunterladen.

 

Fazit

Mit Domain-Driven Design wurden viele wichtige Ideen erstmals in Buchform veröffentlicht. Die darin behandelten Themen sind auch heute noch aktuell und ein Umsetzen der von Evens vorgestellten Ansätze würde so manches aktuelle Problem lösen.

Leider verzettelt sich Evans mit seinen Erklärungen und macht es dem Leser äusserst schwer diese Konzepte zu verstehen. Als Einstiegslektüre ins Thema DDD kann ich dieses Buch daher nicht empfehlen. „Domain Driven Design Quickly“ ist dafür die bessere Wahl, da die gleichen Konzepte viel besser auf den Punkt gebracht werden.
Kehrt man nach diesem Umweg zu Evens zurück versteht man seine Ideen viel besser und erkennt dann auch was sonst noch alles für Informationen in diesem Buch stecken.

 

Zum Buch

„Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans, 2003 Addison-Wesley, ISBN 978-0-3211-2521-7, 560 Seiten, Englisch

Buch-Rezension zu „Building Enterprise Applications with WPF and the MVVM Pattern“

„Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern“ von Raffaele Garofolo erschien im März 2011 bei Microsoft Press. Das MVVM Pattern ist für Silverlight und WPF Anwendungen schon fast ein Muss. Für den geringen Betrag von 15$ bekommt man ein gutes Buch zu MVVM.

 

Das Buch startet wie zu erwarten mit einer Einführung ins Model View ViewModel Pattern und dessen Abgrenzung gegenüber den sonstigen UI Patterns wie MVC oder MVP. Mit diesen Grundlagen ist man gerüstet um die einzelnen Schichten einer Anwendung anzuschauen. Vom Domänenmodell geht es über den Data Access Layer durch die Geschäftslogik zur Oberfläche der Anwendung.

Als Abschluss bietet das Buch eine kurze Übersicht zu MVVM Frameworks und Toolkits wie Caliburn, Prism, MVVM Light Toolkit oder Cinch.

Am Ende jedes Kapitels findet man ein grösseres Beispiel in dem die gerade beschriebenen Punkte zu einem realistischen Szenario verbunden werden. Dies sollte man unbedingt anschauen, da der Text im Kapitel selber wohl nicht jedem genügen wird.

 
Klein, aber fein?
Das Buch ist mit nur 224 Seiten recht dünn, behandelt aber dennoch eine grosse Anzahl von Themen. So kann vieles nur angeschnitten werden, für eine Vertiefung fehlt es an Platz. Wer hier eine detaillierte Einführung in Caliburn erwartet muss zwangsläufig enttäuscht werden.

Es gibt aber Themen wie das Repository- oder das Unit of Work Pattern, die mit ausreichendem Tiefgang beschreiben werden. Der Mehrwert dieses Buches liegt für mich beim kombinieren der einzelnen Themen und Ansätze zu einem Gesamtbild.

Im Grossen und Ganzen hätte der Verzicht aufs eine oder andere Toolkit oder Framework dem Buch wohl mehr Profil gegeben. Jetzt wird zwar jeder angesprochen, doch wer eine Empfehlung für ein spezifisches Produkt sucht wird enttäuscht.

 
Test-Driven
Garofolo legt sehr viel Wert auf die Testbarkeit der vorgestellten Ansätze. So findet man neben einer minimalen Einführung in Test Driven Development über das ganze Buch verteilt immer wiederkehrende Beispiele wie man in dieser Situation nun genau den Code testen kann. Diese Hilfestellung fand ich sehr gut und ich wünschte mir, dass mehr Autoren so viel Wert auf die Testbarkeit legen würden.

 
Downloads
Beim Link zu den Code-Beispielen gab es scheinbar einige Probleme. Der Source Code finden sich auf http://examples.oreilly.com/9780735650923-files/9780735650923_files.zip. Man könnte für die Zukunft noch die ReSharper-Dateien und Binaries weglassen, wodurch das Zip deutlich kleiner würde.

 
Fazit
Wer eine kurze und günstige Einführung ins MVVM Pattern sucht wird in diesem Buch das gewünschte finden. Man muss sich aber mit WPF oder Silverlight auskennen, denn dies ist keine Einführung in diese Technologien.

 
Zum Buch
„Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern“ von Raffaele Garofolo, 2011 Microsoft Press, ISBN Print 978-0-7356-5092-3, ISBN E-Book 978-0-7356-4982-8, 224 Seiten, Englisch