Montag, 30. September 2013

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.

Mittwoch, 25. September 2013

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.

Freitag, 20. September 2013

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.

Sonntag, 15. September 2013

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

Dienstag, 10. September 2013

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.

Donnerstag, 5. September 2013

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.

Mittwoch, 4. September 2013

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.