UML wurde entwickelt, um Softwarearchitektur eine formale Basis zu geben. Die exzessive Nutzung von UML führt aber weg von der Architektur hin zu programmiertechnischen Details. Man möchte das Programmieren (in einer Hochsprache) vermeiden, merkt aber nicht, dass man plötzlich mit einer grafischen Sprache programmiert. Das aber viel ineffizienter, weil Text bei einer gewissen Detailtiefe wieder mehr Übersicht bedeutet, besseres Verständnis und schnellere Änderung. Grady Booch sieht die Entwicklung von UML ähnlich negativ.
Und was die UML-Werkzeuge angeht. Ich habe schon viel benutzt und war meistens unzufrieden. Das taugt einfach nichts. Und was die Kollaboration angeht: Ein UML-Dokument ist eine Datei, das heißt, nur ein Mitarbeiter kann damit arbeiten. Bei Quelltexten hat man viele, kleine Dateien und jeder arbeitet auf einer Hand voll Dateien.
nicht ganz einverstanden - grafische Programmierung erleichtert in einer guten Umgebung die Übersicht enorm.. irgendwann wird's zu komplex, aber auch das kann man Schachteln.
Grady Booch sieht die Entwicklung von UML ähnlich negativ. Wenigstens mal einer der Fehler zugibt.
Früher war ich auch OOA/D-UML-begeistert. Mittlerweile verwende ich es nur noch wenn ich dazu gezwungen werden, ich finde das Ganze nur noch hinderlich und erinnert mehr an sinnlose Rituale anstatt an echter Arbeitserleichterung. Für Dokumentationszwecke oder Diskussionsgrundlagen ist es ok.
Ging mir auch so, während der Ausbildung und kurze Zeit danach.
Ich habe mich dann auf der Arbeit immer wieder über die "Gulasch-" Architekturen und "Gott-" Klassen Gewerke gewundert.
Das Problem liegt darin, dass 90% der OO-Anwender den Algorithmus nicht von der Architektur trennen können, bzw. die Trennlinie dieser Klientiel unbekannt ist.
Die OO-Anwender glauben, dass das "Kästchen-Malen/Klassen designen" schon irgend wann zur gewünschten Funktion führt. Tut es unter Umständen auch, wenn das Problem ein Objektorientiertes ist, wie z.B. die View/Control in Fensterbasierten Systemen. Tut es nicht wenn das Problem z.B. Sequentieller Natur ist, wie das finden von Kanten in einem Foto.
OO kam halt historisch von den grafischen Oberflächen und vergleichbaren "Anwendungsfällen" und ist für mich ein Design-Pattern für eben diese Problemstellungen. Dieses Design-Pattern auf "alle" bereiche der Informatik auszudehnen ist aus meiner Sicht ein Holzweg, führt zu mehr komplexität, schlechterer Wartbarkeit, hohem Ressourcenverbrauch und höheren Kosten.
UML wurde entwickelt, um Softwarearchitektur eine formale Basis zu geben. Die exzessive Nutzung von UML führt aber weg von der Architektur hin zu programmiertechnischen Details. Man möchte das Programmieren (in einer Hochsprache) vermeiden, merkt aber nicht, dass man plötzlich mit einer grafischen Sprache programmiert. Das aber viel ineffizienter, weil Text bei einer gewissen Detailtiefe wieder mehr Übersicht bedeutet, besseres Verständnis und schnellere Änderung. Grady Booch sieht die Entwicklung von UML ähnlich negativ.
Und was die UML-Werkzeuge angeht. Ich habe schon viel benutzt und war meistens unzufrieden. Das taugt einfach nichts. Und was die Kollaboration angeht: Ein UML-Dokument ist eine Datei, das heißt, nur ein Mitarbeiter kann damit arbeiten. Bei Quelltexten hat man viele, kleine Dateien und jeder arbeitet auf einer Hand voll Dateien.
+1
nicht ganz einverstanden - grafische Programmierung erleichtert in einer guten Umgebung die Übersicht enorm.. irgendwann wird's zu komplex, aber auch das kann man Schachteln.
Grady Booch sieht die Entwicklung von UML ähnlich negativ.
Wenigstens mal einer der Fehler zugibt.
Früher war ich auch OOA/D-UML-begeistert. Mittlerweile verwende ich es nur noch wenn ich dazu gezwungen werden, ich finde das Ganze nur noch hinderlich und erinnert mehr an sinnlose Rituale anstatt an echter Arbeitserleichterung. Für Dokumentationszwecke oder Diskussionsgrundlagen ist es ok.
>Früher war ich auch OOA/D-UML-begeistert.
Ging mir auch so, während der Ausbildung und kurze Zeit danach.
Ich habe mich dann auf der Arbeit immer wieder über die "Gulasch-" Architekturen und "Gott-" Klassen Gewerke gewundert.
Das Problem liegt darin, dass 90% der OO-Anwender den Algorithmus nicht von der Architektur trennen können, bzw. die Trennlinie dieser Klientiel unbekannt ist.
Die OO-Anwender glauben, dass das "Kästchen-Malen/Klassen designen" schon irgend wann zur gewünschten Funktion führt. Tut es unter Umständen auch, wenn das Problem ein Objektorientiertes ist, wie z.B. die View/Control in Fensterbasierten Systemen. Tut es nicht wenn das Problem z.B. Sequentieller Natur ist, wie das finden von Kanten in einem Foto.
OO kam halt historisch von den grafischen Oberflächen und vergleichbaren "Anwendungsfällen" und ist für mich ein Design-Pattern für eben diese Problemstellungen. Dieses Design-Pattern auf "alle" bereiche der Informatik auszudehnen ist aus meiner Sicht ein Holzweg, führt zu mehr komplexität, schlechterer Wartbarkeit, hohem Ressourcenverbrauch und höheren Kosten.
@Sam
Wow ... kein Wunder das du Probleme damit hast, wenn du Äpfel mit Birnen vergleichst. Ich glaube du hast gar keine Ahnung von was du da redest.