UML will gelernt sein

[sakura]

Hi DP-ler,

für all die von Euch die von Ummel (UML) schon mal gehört haben aber auch gerne mal wissen würden, was das denn nun eigentlich sein könnte, hier mal ein Link zur Aufklärung.

...:cat:...

[Touchdown]

UML ist echt nichts für Praktiker, bzw. für Firmen die mit dem Produzieren von Software Gewinne erwirtschaften wollen.

Betreibt man die Softwareentwicklung mehr nach wissenschaftlichen, nicht kommerziellen Gesichtspunkten kann man UML durchaus verwenden, aber selbst hier werden am Ende anhand der fertigen Quellcodes, die UML - Diagramme quasi nachgebessert.


Ist nicht nur meine Meinung, wer das Gegenteil behauptet soll sich jetzt melden oder für immer schweigen :mrgreen:

[Sanchez]

@Touchdown
Finde ich nicht. Die Frage ist nur wieviel UML für dich sinnvoll ist.
Natürlich ist es bei kleinen Projekten, an denen einer oder zwei Leute arbeiten nicht sinnvoll die gesamte Pallette einzusetzen oder auf einen Prozess wie den Rational Unified Process einzusetzen.

Es muss jeder für sich entscheiden, was er sinnvoll einsetzen lässt.

z.B. Sind Use-Case-Diagramme doch hervoragende Grundlagen um den Funktionsumfang so darzustellen, dass es auch ein Kunde versteht.
Da ich in einer ziemlich kleinen Firma arbeite, wird es bei uns sehr wenig eingesetzt. Aber es ist auch allemal praktisch, sich zumindest im nachhinein ein Klassendiagramm generieren zu lassen um bei etwaigen Änderungen wieder schnell ins Prokjekt reinzukommen.
Komplexere Abläufe skizzier ich auch gerne mal vorher als Activity-Diagram (glaube mal, dass es so heisst).

Bei riesigen Projekten würde ich auf alle Fälle zuerst mit UML modellieren, anstatt mit ein wenig Prototyping zu beginnen.

grüße, daniel

[Tool-Box]

@Sakura

Hallo Sakura,

gibts dazu eine deutsche Übersetzung ? (Das Übersetzen ist mir momentan zu anstrengend :mrgreen: )

Gruss, Tool-Box :wink:

[sakura]

Zitat:

Zitat von Tool-Box

gibts dazu eine deutsche Übersetzung ? (Das Übersetzen ist mir momentan zu anstrengend

Nope :mrgreen:

...:cat:...

[Touchdown]

@Sanchez Ich stimme schon zu, dass große Projekte mehr Planung brauchen als kleine Projekte. Auch will ich UML nicht als vollkommen sinnlos darstellen, man sollte es nur nicht übertreiben damit.

Mir wurde mal beigebracht, dass über 50% der Softwareentwicklung aus Planung besteht, in der Praxis habe ein solches Verhältnis nie kennen gelernt. Ebenso wollte man mir beibringen, es gibt Programmierer, die den ganzen Tag nach irgendwelchen UML’s, Plänen und Diagrammen Quellcode erzeugen. Diese Programmierer wurden als nicht sonderlich qualifiziert dargestellt. Die Entwickler, die die Pläne entwerfen seinen die Experten.

Heute sage ich: Bullshit! Die Theorie und die Praxis sind nirgends weiter auseinander als in der Softwareentwicklung!

[sakura]

Meine 9ct zum Thema ;-)

Zitat:

Zitat von Touchdown

Mir wurde mal beigebracht, dass über 50% der Softwareentwicklung aus Planung besteht, in der Praxis habe ein solches Verhältnis nie kennen gelernt.

50% Planung sehe ich als passend an. Wir haben mit der Planung der Version 4 unserer Software im Januar angefangen und bis einschl. Juni nichts anderes gemacht als Gedanken zur Software, Abläufen, Kundenwünschen, etc. Anschließend haben wir mit spezifischen Diagrammen die Klassen und Objekte geplant und erste Prototypen für bestimmte Aufgaben gebaut und diese getestet.

Seit September sind wir in der eigentlichen Programmierung, diese wird bis vorraussichtlich Märt 2004 andauern. Dann haben wir das geplante (Planziel :mrgreen: ) erreicht. Die nächste Ausbaustufe (Version 4/II) ist bereits in Planung.

Damit haben wir wirklich die Hälfte der Zeit nur mit Planung und Softwaredesign verbracht.

Zitat:

Zitat von Touchdown

Ebenso wollte man mir beibringen, es gibt Programmierer, die den ganzen Tag nach irgendwelchen UML’s, Plänen und Diagrammen Quellcode erzeugen. ... Diese Programmierer wurden als nicht sonderlich qualifiziert dargestellt. Die Entwickler, die die Pläne entwerfen seinen die Experten.

Gibt es ja. Und es ist wirklich der einfachere der beiden Jobs. Die ganzen Gedanken und Machbarkeitsstudien sind bereits abgeschlossen, wenn der Programmierer ans Werk geht. Einige mögen das als altmodisch ansehen, aber zusammen mit einigen Neuerungen der Programmierung immer noch sehr effektiv.

Damit ist es aus meiner Sicht wirklich um weites schwerer die Software zu planen, als diese Pläne im Anschluß umzusetzen ;-)

...:cat:...

P.S.: Unser letztes Kundenprojekt hatte 4 Monate Planung/Design und 2 Wochen Programmierung ;-)

[Sanchez]

Zitat:

Zitat von Touchdown

Diese Programmierer wurden als nicht sonderlich qualifiziert dargestellt. Die Entwickler, die die Pläne entwerfen seinen die Experten.

Ich würde mal sagen, dass in diesem fall sowohl die Software-Architekten als auch die Programmierer Experten in ihrem Gebiet sind. Für Projekte an denen die Archtekten sich die Software ausdenken und die Programmierer sie dann umsetzen müssen spielt die UML bestimmt eine große Rolle. Stell dir mal die Kommunikation zwischen denen ohne einen Standard wie die UML vor.

Ich persönlich schau mir immer an, welche Ansätze ich für mich gebrauchen kann, die mir die arbeit also erleichtern und nicht umständlicher machen.

Das die Planung einen großen Teil ausmacht ist schon klar. Immerhin tippt man ja nicht den ganzen Tag wie ein Irrer, sondern überlegt sich schon wie man eine Sache angeht.

[Chewie]

Zitat:

Zitat von sakura

Damit ist es aus meiner Sicht wirklich um weites schwerer die Software zu planen, als diese Pläne im Anschluß umzusetzen ;-)

Dem stimme ich zu. Ich hab zwar keinerlei Wissen, wie Unternehmen größere Projekte planen, aber aus eigener Erfahrung habe ich gelernt, dass eine gute Planung essentiell ist. Mit zwei anderen Leiten habe ich ein etwas größeres Projekt angefangen, aber das hat sich im Sande verlaufen. Zu einem Teil lag das auch an fehlender Zeit, aber ein großer Teil hing auch damit zusammen, dass es ein 10.000 Zeilen zuhammenhangsloser Code war, für dessen Einarbeitung man Stunden gebraucht hätte, bis man vernünftig hätte arbeiten können. Jetzt sind wir das ganze noch mal von vorne angegangen, und legen besonderen Wert auf die Planung, die eigentliche Programmierung soll dann nur noch eine Art "Malen nach Zahlen" sein. Inwiefern das klappt, wird sich herausstellen, aber wenn es schon in, verglichen mit riesigen Softwareprojekten in der Wirtschaft, relativ kleinen Projekten ohne Zeitdruck so schwierig ist, wie schwierig wird es dann, wenn ein Megaprojekt bis zum Stichtag fertig sein muss?

[Tyrael Y.]

Bei guter Planung braucht man für die Implementiereung wirklich nur sehr wenig Zeit,
da der Programmierer sich keine Geadnken mehr um die Zusammenhänge machen muss.
Er setzt einfach 1:1 um was laut Planung festgelegt ist.
Da kann ich sakura nur zustimmen.

Aber...in der Realität wird das oft nicht gemacht, da sich viele Firmen davor scheuen lange Planungsphasen zu integrieren. Ich denke da steckt der Wunsch dahinter, daß man möglichst schnell was
in der Hand haben möchte. D.h. irgend etwas was schon (teilweise) funktioniert soll möglichst schnell verfügbar sein, um es eventuellen Vorgesetzten oder Kunden zu präsentieren.

Ich denke, daß dadurch viele Projekte länger dauern als sie müssten.
Da während der Implementation immer wieder etwas auffällt was noch zu beachten ist.
Hätte es man vorher audführlich geplant würde so etwas nicht passieren.

Ich finde es auch als falschen Ansatz, aber so ist es nun mal in den meisten Betrieben.

Gruß