G
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