Das Data Transfer Object – Be or not to be.

Praktisches Beispiel 2.2.1

Artikelübersicht
1. Teil	Das Data Transfer Object – Be or not to be.
2. Teil	Java Beans und Use Cases.
3. Teil	Data Transfer Objects - ein Antipattern?

In dieser kleinen Reihe möchte ich den Einsatz des Data Transfer Objects diskutieren. Einer meiner Absichten ist es, mit Hilfe der Community, einige Unklarheiten in meinem eigenen Kopf zu beseitigen. Nachdem ich mein eigenes Wissen über dieses Entwurfsmuster aufbereitet habe, möchte ich auf einige Einsatzbeispiele kommen und anhand dieser diskutieren, ob man dieses Entwurfsmuster so anwendet oder nicht.

Fehlerkreisläufe – Dein Freund, der Fehler.

These: Menschen die sich wohl fühlen, Menschen die geachtet werden, schaffen beachtliche Software.

Innerhalb eines Arbeitsprozesses werden Fehler gemacht. Wer nichts macht, macht auch keine Fehler. Über denen, die etwas machen sollten, sitzen die, die Anweisungen geben. Diese sind jedoch oft ungenau und beinhalten eine gewisse Zieltoleranz, um den Ausführenden in jedem Fall für seine Fehler zu bestrafen. Innerhalb unserer Kultur scheint es eine tiefe Bestrafungsphantasie für Fehler zu geben. Die eigenen Fehler werden auf Andere projiziert und mit dem Anderen ausgemerzt. Eine tiefe Befriedigung geht durch die, die sich über andere erheben. Doch leider hält diese Zufriedenheit nicht lange an. Diesem extrovertierten Fehlertyp steht der introvertierte Fehlertyp gegenüber. Er vergräbt sich in den Tiefen seiner Fehler, kann nicht schlafen und zittert schon vor dem nächsten.

Von der logischen Komponente zur technischen Komponente.

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil	Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil	Von den Funktionsgruppen zu logischen Komponenten.
3. Teil	Von der logischen Komponente zur technischen Komponente.

Im letzten Post dieser Reihe haben wir die gefundenen funktional motivierten Komponenten durch die Konzepte von Tier, Layer und Softwarekategorie weiter in logisch motivierte Komponenten unterteilt. Dabei wurde eine strenge Kommunikationsrichtung, immer von der oberen Komponente auf die untere Komponente, und ein strenger Zugriffsort, immer über die Fassade, vorgegeben.

Missing Links im Modell

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil	Missing Links im Modell.
2. Teil	Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil	Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil	Softwareentwurf ist ein organisierter Kreislauf.
5. Teil	In Softwareprojekten gibt es viel zu entdecken!
6. Teil	Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil	Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil	Mit schlanken Methoden zu gewollter Software.
9. Teil	Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil	Vom Problem seiner Rolle gerecht zu werden.
11. Teil	Wir gründen eine virtuelle Firma.
12. Teil	Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil	Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil	Ein fortgesetztes tolles Geschäft.

Das Buch [WEIL10] bot die Gelegenheit, eine Idee zu formulieren, die mir schon lange im Kopf ist. Die gesamte Softwareentwicklung und das Betreiben dieser Software setzt sich aus so vielen Einzelschritten zusammen, dass sie oft nicht zusammen gedacht werden. Das Zerreißen in kleine Schritte ist notwendig, um die Komplexität zu beherrschen. Das Zusammenfügen der kleinen Schritte jedoch auch, um das Ganze nicht aus den Augen zu verlieren. Softwareentwicklung ist nicht nur codieren. Softwareentwicklung besteht aus einer Vielzahl von Artefaktentwicklungen, die alle miteinander verwoben sind und Abhängigkeiten zueinander aufweisen. Das Suchen nach allen Schritten und den Zusammenhängen zwischen ihnen und deren Notwendigkeiten ist die Vision der Posts unter dem Thema "Prozessübersicht Softwareentwicklung".

Ein Objekt-Aufgaben-Modell für das Requirements Engineering

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil	Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil	Der Ideenraum.
3. Teil	Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil	Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil	Ein hierarchisches System von Kontextobjekten.
6. Teil	Die Geschichten der Benutzer - User Stories erstellen.
7. Teil	Die Analyse des Problemraums führt zum Zielmodell.
8. Teil	Wie User Stories Use Cases gebären.
9. Teil	Szenarien setzen sich zu Use Cases zusammen.
10. Teil	Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil	Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil	Die Vielfalt der Szenarien.
13. Teil	Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil	Ohne Abnahmekriterien läuft nichts.
15. Teil	Startschuss zur testgetriebenen Entwicklung.

Im Requirements Engineering gibt es Ideen, Ziele, User Stories, Use Cases, Szenarien, Anforderungen, und wenn es der Dokumentationshunger verlangt, einiges mehr. All diese Dinge können wir als Objekte auffassen. Sie existieren in realen Spezifikationen, in geordneten Wikis oder auch im großen Durcheinander des Projektalltags. Ein Ding ist also ein reales Objekt, welches wir auch als Artefakt bezeichnen können. Diese Artefakte werden erstellt, geändert oder gelöscht. Diese Handlungen weisen darauf hin, dass sich das einzelne Objekt in verschiedenen Status befindet.

Im September ruft die Community

Allgemeines

Am Anfang dieses Posts möchte ich mich bei allen bedanken, die meine Gedanken lesenswert finden und bei allen die mit ihren Kommentaren meine Fehler korrigieren, Wissen ergänzen und weitere Gedankenanregungen geben. Wenn ich nicht auf alles angemessen reagiere, so liegt es daran, dass die Zeit leider knapp ist und ich in erster Linie meinem Job nachkommen muss und dann erst diesem Blog frönen kann. Frönen ist übrigens etwas altertümlich und bedeutet "sich ausgiebig einer Beschäftigung hingeben, etwas gern und ausdauernd machen." (Wiktionary) In beidem liegt etwas von mir.

Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese

Praktisches Beispiel 2.1.3

Artikelübersicht
1. Teil	Das Factory Pattern – Glaube und Wirklichkeit – Teil 1
2. Teil	Das Factory Pattern – Glaube und Wirklichkeit – Teil 2.
3. Teil	Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese.

Zum zweiten Teil der Reihe Das Factory Pattern – Glaube und Wirklichkeit hat Torsten Robitzki mir geschrieben, dass ich extrem abstrakt geblieben bin. Seiner Meinung nach birgt das die Gefahr, dass vielleicht nicht alle das gleiche Verständnis entwickeln. Diese Kritik fand ich sehr berechtigt. Leider fehlte mir ein konkretes Beispiel und deshalb hatte ich Torsten gebeten ein Beispiel zu entwickeln. Dieser Bitte kam Torsten nach und ich bin ihm sehr dankbar dafür. Im nachfolgenden Text stelle ich sein Beispiel dar.