Diskussion zu UML

otze

GPC schrieb:

Ich glaube, UML hätte einen eigenen Artikel verdient.

UML verdient den Tod.

recht hast du.

estartu

Scheint, als wäre die Verwandschaft zu Struktugrammen doch enger als ich dachte.

Paul_C.

Warum seid ihr gegen UML? Was sind die Gründe?

GPC

Paul_C. schrieb:

Warum seid ihr gegen UML? Was sind die Gründe?

Ich will keine Diskussion oder Flamewar lostreten. Sagen wir einfach, wir haben unsere Gründe, u.a. weil wir schon damit arbeiten mussten. Es gibt im Rund um die Prog. und Neuigekeiten Board aber einige Threads, die das intensiv behandeln. Such danach wenn du's lesen willst und Zeit hast.

MfG

GPC

DocJunioR

Ich denke, eine Diskussion diesbezüglich sollte nochmal geführt werden.
Ich hab UML in den letzten Monaten kennen gelernt und kann mir einiges an für und wider vorstellen.

Das grundsätzliche Problem ist allerdings wahrscheinlich dieses: UML ist nicht für Programmierer gedacht. Vielmehr werden hier konsequent Rollen getrennt die den Programmierer augenscheinlich zur Tippse degradieren. (was sie eigentlich nicht tun) Eigentlich macht man ihn aber frei für die Programmierung.

Sooo umfangreich ist UML dann eigentlich zumindest von den Diagrammen her nicht wirklich. Es gibt in der UML 1.4 gerade mal 9 Diagrammarten, in UML 2.0 kommt noch eines dazu das man aber nur im embedded Bereich braucht.

Warum ich hier 5 Monate nach dem letzten Eintrag poste: Ich hab gerade im Magazin nach UML-Artikeln gesucht und nicht wirklich einen gefunden.

Ich möchte eigentlich einen Artikel lesen, der mir zuallererst mal erklärt, warum soll man UML nutzen und warum die Finger davon lassen..
Anschließend kann man dann die Diagramme erläutern.

Wie man diese einsetzt, kann man eh nicht so schnell lernen- dafür brauchts Erfahrung und nicht jeder ist zum Analysten/Designer geboren..

Ich selbst würds ja machen ^^ aaber zum Einen ist meine Zeit begrenzt und zum Anderen kenne und nutze ich auch nicht alle Diagramme..

estartu

DocJunioR schrieb:

Ich selbst würds ja machen ^^ aaber zum Einen ist meine Zeit begrenzt und zum Anderen kenne und nutze ich auch nicht alle Diagramme..

Naja, wenn man einen stetigen Fortschritt sieht, dann darfs auch länger dauern.
Wenn jemand zu lange nix schreibt, fragen wir auch mal nach.

Und man kann ja "Einführung" schreiben, das impliziert, dass es nicht komplett ist.

nep

Öhm, ich hab aber schon angefangen mit dem Artikel... aber das was du (DocJunior) vorhin erwähnt hast, hab ich da auch schon in die Einleitung so ähnlich geschrieben

GPC

nep schrieb:

Öhm, ich hab aber schon angefangen mit dem Artikel... aber das was du (DocJunior) vorhin erwähnt hast, hab ich da auch schon in die Einleitung so ähnlich geschrieben

gut, ich hoffe du schreibst ihn auch fertig

@DocJunioR
Meine Haltung bzgl. UML hat sich nicht geändert... Warum also mag ich es nicht?

UML ist nicht für Programmierer gedacht.

Stimmt, das wiederum bedeutet, dass es von Leuten benutzt wird, die nicht programmieren können. Das ist schlecht. SEHR schlecht. Denn um mit UML etwas basteln zu können, braucht man Programmiererfahrung. Möglichst viel Programmiererfahrung. Die bekommt man aber nicht, wenn man UML macht, die bekommt man nur durch's programmieren. Wofür sich viele SA'ler aber zu fein sind.

Punkt zwei: UML ist nur ein Plan. Ein Plan, in dem es sich oft zu leicht gemacht wird, aus Faulheit oder Unkenntnis bei einem speziellen Problem. Bei der Umsetzung hapert's dann unter Umständen bei einigen Komponenten und man muss eine neue Lösung entwickeln. Daraufhin darf man entweder einiges an seinem Poster ändern oder man kann gleich die ganze Architektur frisch hochziehen (na ja, worst-case Szenario halt, kam aber durchaus schon vor).

Des Weiteren halte ich es für fragwürdig, große Projekte mit UML zu planen, da man ziemlich blöd dasteht, wenn auf einmal der Kunde anruft und sagt: "Äh, ich hätt da noch nen Änderungswusch, mir egal, was es kostet." Und jetzt kann es so blöd laufen, dass diese Änderung die halbe Planung über den Haufen wirft. Blöde Sache. Und Kunden rufen viel zu oft an und wollen was geändert haben, weil die Systemspezifikationen an einigen Punkten undeutlich sind.

Das fiel mir auf die schnelle ein...

MfG

GPC

estartu

Arg, da hab ich wohl gepennt. Dann könnte man eher an dich denken, wenn sich kein fachlicher Probeleser findet.

So, PC aus bevor ich noch irgendwas verbassel.

nep

Also da bin ich anderer Meinung. UML wird sehr wohl von Leuten benutzt die auch programmieren können. Da wo ich mal gearbeitet habe, war es z.B. so, dass es ein Entwickler-Team gab, welche die Software geplant und mit UML modelliert haben, und das Geplante auch implementiert haben. Ok kann sein, dass das vielleicht eher die Ausnahme ist und in vielen Unternehmen anders gehandhabt wird, aber so ist das IMHO schon sehr produktiv.

Stimmt, das wiederum bedeutet, dass es von Leuten benutzt wird, die nicht programmieren können. Das ist schlecht. SEHR schlecht. Denn um mit UML etwas basteln zu können, braucht man Programmiererfahrung. Möglichst viel Programmiererfahrung. Die bekommt man aber nicht, wenn man UML macht, die bekommt man nur durch's programmieren. Wofür sich viele SA'ler aber zu fein sind.

Da bin ich genau der gleichen Meinung. Um ein Softwaresystem entwerfen zu können, muss bzw. sollte man auch Programmiererfahrung haben. Und genauso wichtig: Man sollte auch von der jeweiligen Domäne Ahnung haben

Aber da ist auch schon der nächste Punkt. Wer ein Softwaresystem *vollständig* mit UML plant, ist selbst schuld. Man kann UML aber sehr gut dazu benutzen, um z.B. die Kernkomponenten des Softwaresystems zu beschreiben und zu modellieren, und die sollten sich im Großen und Ganzen nicht komplett ändern. Wenn doch, dann wurde wohl schon bei der Anforderungsanalyse gepennt. Und das kann dann wiederrum als Kommunikationsgrundlage für das Entwickler-Team verwendet werden bzw. sogar auch zum Austausch mit dem Kunden, auch wenn das hier fürs Forum wohl eer irrelevant ist.
Das worauf es ja letzlich ankommt, ist, dass man sein Softwaresystem auf einer höheren Abstraktionsebene designt, anstatt gleich mit dem Codieren zu beginnen. UML ist dafür auch nur ein Werkzeug, nicht mehr, aber auch nicht weniger. Und da es eben eine Sprache ist, gibt es Formalismen an die man sich halten muss, und deshalb bietet es sich schon ganz gut dafür an. Man kann diese Aktivitäten auch gänzlich ohne UML erledigen, dadurch wird es auch nicht schlechter. Hauptsache man TUT es. Da UML heutzutage aber sowas wie der Standard dafür ist, spricht auch nichts dagegen es zu nutzen. Und wie bei jedem Werkzeug gilt auch hier, dass man erst mal die Grundprinzipien erlernen muss, wobei das bei UML ja sehr sehr einfach ist.

Naja mein Senf dazu...

phlox81

Ich denke UML ist schon ganz gut einsetzbar.
Es kann sicher nicht die Programmierung ersetzen,
aber es kann sie doch vereinfachen. Gerade in der Analyse
und Designphase in Projekten kann man so Sachen darstellen,
man muss garnicht mal ins Detail gehen, und so einen Grobentwurf
der Software bereits haben, bevor man auch nur eine Codezeile
geschrieben hat.

Ebenso wichtig ist UML imho für die Dokumentation, da man hiermit
einen raschen Überblick über ein Projekt geben kann.

Und Use-Case Diagramme können Sachverhalte auch so darstellen, das
sie auch nicht Programmierer/ITler verstehen.

DocJunioR

GPC schrieb:

Punkt zwei: UML ist nur ein Plan. Ein Plan, in dem es sich oft zu leicht gemacht wird, aus Faulheit oder Unkenntnis bei einem speziellen Problem. Bei der Umsetzung hapert's dann unter Umständen bei einigen Komponenten und man muss eine neue Lösung entwickeln. Daraufhin darf man entweder einiges an seinem Poster ändern oder man kann gleich die ganze Architektur frisch hochziehen (na ja, worst-case Szenario halt, kam aber durchaus schon vor).

Ich hab das auch schon ein paar mal mitgemacht @ worst case Szenario.
Da möchte ich mal frech und blauäugig sagen, die Serviceorientierte Anwendungsentwicklung heilt alles. Das Problem ist nur, dass man diese Service-Orientierung nur schwer erreicht. Der Plan ist auch nicht so gedacht, dass er unveränderlich ist. Allerdings ist die Änderung im Notfall minimal, wenn man es richtig macht.
Funktionsgruppen werden in einzelne Klassen oder Komponenten gepackt. Serviceorientiert ist, wenn man sämtliche Fälle einer Funktionsgruppe implementiert, ob man sie braucht oder nicht. Das meint, dass man auch eine Löschfunktion für Daten implementieren sollte, auch wenn es derzeit nicht vorgesehen ist, zu löschen.

GPC schrieb:

Des Weiteren halte ich es für fragwürdig, große Projekte mit UML zu planen, da man ziemlich blöd dasteht, wenn auf einmal der Kunde anruft und sagt: "Äh, ich hätt da noch nen Änderungswusch, mir egal, was es kostet." Und jetzt kann es so blöd laufen, dass diese Änderung die halbe Planung über den Haufen wirft. Blöde Sache. Und Kunden rufen viel zu oft an und wollen was geändert haben, weil die Systemspezifikationen an einigen Punkten undeutlich sind.

Vielleicht seh ich das anders, weil wir hier nur ein gigantisches Softwaresystem für unsere eigene Organisation schreiben und die Anforderungen mehr oder weniger bekannt sind. Es ist doch aber so, dass man vor dem Beginn der Entwicklung genau wissen sollte, was der Kunde will und dieses auch vertraglich fest steht. Wenn er dann noch was will, hat er einfach ein Problem. Ist die Funktionalität ohne änderung der Architektur machbar, wirds gern noch reingenommen. Ist die Architektur nicht fähig, dieses zu tun, würde ich auf den Vertrag verweisen..

Der Analyst in der SOA ist ein Prozesskenner. Eigentlich braucht dieser nur Ahnung vom Geschäftsprozess haben, der Rest ist ein "nice to have".
Der Designer hat nun das Problem, hieraus am Ende Anwendungsfälle zu beschreiben aus denen sich Klassen bilden lassen. Er sollte schon Programmierer sein, aber nicht innerhalb des Projekts programmierern- wozu er in großen Projekten eh nicht kommen würde.
Dem steht natürlich der allgemeine Mangel an Arbeitskraft entgegen, aber dies ist die dunkelgraue Theorie

UML kann man eigentlich ohne eine entsprechende Rollenverteilung im Projekt kaum entsprechend leben und es ist meiner Meinung nach auch nicht immer notwendig- uch vor der UML gab es gute Programme - aber es hat seinen Stellenwert.

GPC

Morgen,

sorry dass ich erst jetzt antworte, aber gestern war es mit der Erreichbarkeit des Forums nicht gerade gut bestellt, zumindest als ich es versuchte^^

nep schrieb:

Das worauf es ja letzlich ankommt, ist, dass man sein Softwaresystem auf einer höheren Abstraktionsebene designt, anstatt gleich mit dem Codieren zu beginnen.

Dieses Ziel sollte jeder gute Projektleiter und auch die Entwickler verfolgen, nur halte ich UML nicht gerade für das Mörderwerkzeug dafür.

phlox81 schrieb:

Ebenso wichtig ist UML imho für die Dokumentation, da man hiermit einen raschen Überblick über ein Projekt geben kann.

Das einzige was man imo dazu gebrauche kann, sind die Klassendiagramme und die Use-Cases. Und mir persönlich sind doxygen oder javadoc Dokus viel lieber, denn dann bekomme ich zusätzlich zur Schnittstelle eine Beschreibung der Klasse, der Methoden, der Parameter, der Rückgabewerte und noch ein paar Verweise auf andere Klassen, die mit dieser arbeiten. Mich interessiert nicht immer ob die Methode public oder private ist, was ist mir virtual, static usw?

Das hat noch einen Vorteil: Dadurch, dass die Dokumentation aus dem Quellcode erstellt wird, ist es ZWINGEND notwendig, den Quellcode zu dokumentieren, was natürlich von Vorteil ist.

Und Use-Case Diagramme können Sachverhalte auch so darstellen, das sie auch nicht Programmierer/ITler verstehen.

Jo, UML ist halt nicht für Programmierer gemacht. Vor Allem bringt mir UML nichts "hinter den Kulissen", denn ich kann mir zwar ne Klassenschnittstelle zusammenbasteln, aber das, was dahinter in den Routinen steht (und für Entwickler nunmal auch sehr wichtig ist), bleibt undokumentiert.

DocJunioR schrieb:

Es ist doch aber so, dass man vor dem Beginn der Entwicklung genau wissen sollte, was der Kunde will und dieses auch vertraglich fest steht.

Sollte, ja, man sollte es wirklich vorher wissen. Aber dann steht im Anforderungskatalog dann folgendes drin: "Bestmögliche Performance", ah ja, und was heißt das jetzt genau? Besser wäre: "Die 20 Hauptdialoge müssen Reaktionszeiten kleiner 2 sekunden haben". Das wäre gut, aber das ist halt nicht immer so, jedoch ist das kein Problem von UML

Wenn er dann noch was will, hat er einfach ein Problem. Ist die Funktionalität ohne änderung der Architektur machbar, wirds gern noch reingenommen. Ist die Architektur nicht fähig, dieses zu tun, würde ich auf den Vertrag verweisen..

Wenn der Kunde bereit ist, für eine Änderung zu zahlen, wirst du in äußerst seltenen Fällen nein sagen.

UML kann man eigentlich ohne eine entsprechende Rollenverteilung im Projekt kaum entsprechend leben und es ist meiner Meinung nach auch nicht immer notwendig- uch vor der UML gab es gute Programme - aber es hat seinen Stellenwert.

ACK. Den Stellenwert kann ja jeder für sich einschätzen. Ich halte dennoch nicht viel von UML und bin der Meinung, dass UML hauptsächlich in größeren Firmen verwendet werden, weil die Zeit und Geld für den Spass haben.

MfG

GPC