Test First <-> Design First

[Guest]

Hallo,
ich habe mich bisher nur mit Design First beschäftigt, also der Erstellung eines OOA Modells und anschließend der Entwurf etc.

Nun habe ich vor kurzem allerdings auch ein Buch zum Test First Ansatz gelesen , was natürlich zwei Welten aufeinander prallen lässt.

Mich würde mal interessieren wie es heutzutage aussieht, gibt es Bereiche in denen primär einer der beiden Ansätze verwendet wird - wenn ja welche?

Außerdem: Die Erstellung von Aktivitätsdiagrammen etc. steht ja nicht im Widerspruch zu Test-First oder? Also zumindest wenn man es nachträglich zur Dokumentation etc. verwendet (und nicht damit startet).

Würde mich über Kommentare freuen und hoffe es ist die richtige Kategorie dafür.

 

[SnooP]

Das ist nen sehr interessantes Thema .. und zufälligerweise interessiert mich das grad auch sehr.

Problem ist - das sind tatsächlich zwei Welten. Der Test-First Ansatz ist aus dem Extreme Programming entstanden. Die Idee dabei ist, erstmal zu programmieren und das Design durch Refactoring zu verbessern... grundsätzlich ist aber erstmal wichtiger die Anwendungsfälle abzuprogrammieren und ein funktionierendes Gesamtsystem zu haben - dieses ist mit Test-First durchaus auch belegbar... - danach dann halt Refactoring...

Die Extreme-Programmer sind häufig der Ansicht, dass der Code selbst so gut sein muss, dass er als Dokumentation genügt! Ob das denn tatsächlich so ist .. naja...

Nachträgliche Dokumentation ist für einen XPler ein Graus und bei genauerer Betrachtung ist das einfach unproduktiv... viel interessanter ist die Verwendung von Softwaremodellen, aus denen sich direkt Code generieren lässt - d.h. Modell und Code sind äquivalent.. - Stichwort hier ist die Model Driven Architecture (MDA), die grad ganz groß in Mode ist... - eine Idee dabei ist, beide Welten miteinander zu vereinen... Dokumentation auf der einen Seite - aber nicht nur zum reinen Selbstzweck sondern mit dem Ziel, dass die entworfenen Diagramme für die Codeprogrammierung genutzt werden können...

Beispiel dafür sind ausführbare Modelle - wie Zustandsdiagramme/Statecharts aus Rhapsody oder Statemate... oder auch einfachere Case-Tools wie TogetherJ, mit denen zumindest der statische Code aus Klassendiagrammen direkt generiert werden kann und auch Sequenzdiagramme aus der UML umgesetzt werden können...

Sehr cool ist übrigens die Idee aus Sequenzdiagrammen - Testfälle abzuleiten - sprich mit Hilfe eines Sequenzdiagrammes kann automatisch entsprechender Code generiert werden, der dann als Testtreiber für solche Test-First Szenarien dient...

Also prinzipiell spielt das so in die Richtung agiler Entwurfsmethoden.. beim XP tut sich da in letzter Zeit auch einiges, weil man gemerkt hat, dass Modellierung viel Zeit sparen kann, wenn man die Modelle tatsächlich für Code verwenden kann...

 

[Gast]

Danke für die ausführliche und interessante Antwort.

Im allgemeinen scheint es so zu sein das man weiter weg geht von der eigentlichen Programmierung weiter zu abstrakteren Konstrukten, kann man das so sagen? *g*

Einer unserer Profs meinte nur "früher oder später wird man kaum noch programmieren wie wir jetzt in den Übungen, es wird darum gehen Modelle etc. zu entwerfen aus denen der Programmcode dann generiert wird."

Das was du zu Sequenzdiagrammen gesagt hast klingt sehr interessant, werde mal schauen was ich dazu finde.

Die ganze Thematik scheint sehr interessant - da hast du vollkommen recht.

 

[Lim_Dul]

Im allgemeinen scheint es so zu sein das man weiter weg geht von der eigentlichen Programmierung weiter zu abstrakteren Konstrukten, kann man das so sagen? *g*

Das war aber schon immer der Fall, wenn man sich den Weg anschaut von: Maschinensprache - Assembler - Prozeduraler Programmierung - Objektorientier Programmierung.

 

[SnooP]

Jo - der Trend existiert schon immer... Modelle sind da vermutlich noch nichtmal das Ende ...

nen nettes Buch von meinem Proff :
http://www.sse.cs.tu-bs.de/books/flyer_agile_model_uml.pdf

das zeigt son paar Ansätze in dem Bereich und ist bei uns Grundlage zu ner Vorlesung gewesen... in letzter Zeit gab es auch einige Artikel in der iX über MDA & Co. ... und so wie es aussieht wird sich auch meine Diplomarbeit um MDA drehen

 

[AlArenal]

Ich denke es dreht sich einfach um Abstraktionsebenen. Die Weiterentwicklung in der IT (Geschwindigkeit der Rechner, Menge an vrefügbarem Speicher) findet auf Basis neuer und komplexerer Anwendungsfelder statt. Um diese auch in Softwaresystemen noch hanhaben zu können, haben sich die Programmiersprachen evolutionär von recht systemnahen Sprachen hin zu immer weiter abstrahierunden Formen entwickelt.
Gleichzeitig steigen dann aber auch die Anforderungen an das Projektmanagement und die Systematiken, mit deren Hilfe diese Entwicklungen dann noch planbar, wartbar und übersichtlich darstellbar sind.

Wer Anwendungen entwickelt, entwickelt für Anwender und entsprechend gefragt sind Methoden und Hilfsmittel um möglichst problemnah arbeiten zu können, ohne jedes Bit selbst in die Hand nehmen zu müssen. Von daher teile ich die Meinung, das zukünftig die Entwicklung weitergehen wird; XP, SOA, MDA, etc. sind da nur Stichworte.
Die Erfahrung zeigt aber auch, dass es nie schadet die Basics zu beherrschen, um Systeme in ihrer Gänze verstehen und beherrschen zu können. Nicht zuletzt muss ja auch jemand solche Tools wie Together erstmal entwickeln..

Ich mache mir also keinen Kopf darum, dass ich irgendwann von jemandem ersetzt werde, der nur noch in einer Anwendung per Mausklick irgendwelche Icons schubst und miteinnander verbindet.

 

[SnooP]

Das Formulieren von Algorithmen - also meinetwegen zustandslose Funktionen wird wohl auch weiterhin im Abstraktionsniveau einer entsprechenden Programmiersprache bleiben - das ist in bestimmten Teilen ja auch nicht weiter schlimm... - kritisch ists imho nur dort, wo größere Systeme zusammengestellt werden und das ganze ohne vernünftiger Entwurfsmethodik passiert... und schlecht ist imho auch, dass offenbar immer noch UML-Diagramme lediglich zur Dokumentation erstellt werden, diese aber gar nicht grundlage der Programmierung sind... bzw. es mehr oder weniger davon abhängt ob die 100 Programmierer die ich beschäftige das Dokument in Gänze verstanden haben... da ist es wesentlich präziser, wenn der Code automatisch erzeugt wird, wenn der Formalismus eine entsprechende Semantik besitzt die eh eindeutig ist... - schlimm ists dann eher, wenn man UML-Diagramme sehr schwammig formuliert und dem Entwickler zu viel Entscheidungsspielraum gibt, der eigentlich so gar nicht gemeint war ... - also ich bin bei großen Projekten sehr für mda und etwas formalere Entwurfsmethoden, wenn sie denn tatsächlich transformierbar sind und nicht blöder Selbstzweck - nach dem Motto - sieht alle her, ich kann auch Statecharts malen

Nen ganz gutes Tool ist für letzteres imho Rhapsody von ILogix - mit dem kann aus Statecharts, Klassendiagrammen und Objektdiagrammen direkt Javacode generiert werden, der dann lauffähig ist... vor allem kann dadurch vorher sehr viel getestet, simuliert und auch model-gechecked werden und ich hab am Ende trotzdem Code der im Endprodukt genutzt werden kann...