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ß

[sakura]

Zitat:

Zitat von Tyrael Y.

Aber...in der Realität wird das oft nicht gemacht, da sich viele Firmen davor scheuen lange Planungsphasen zu integrieren.

Das liegt oft auch an unwissenden Bossen. Wenige sind zufrieden, wenn man 6 Monate nur Diagramme zeigt. Es ist schwer soetwas durchzusetzen, wenn der Boss es gewohnt ist nach 2 Wochen etwas handfestes zu sehen.

Aber auch auf Seite der Mitarbeiter gibt es oft sträuben gegen ein solche Planung. Aber es muss einem wohl Spaß machen, soetwas auch zu tun, damit es geht. Wenn ich später wirklich gute Programmierer bei mir habe, dann sind die ihren Job los und kommen in die Softwaredesigngruppe. Das ist um weites komplexer vom Ansatz, aber ich finde auch spannender. Aber noch ist meine Firma zu klein und ich muss es selbst machen :roll:

...:cat:...

[Sourcemaker]

Der Einsatz und Aufwand der bei der Planung betrieben wird richtet sich nach Volumen des Auftrages (finanziell) und der Anzahl der mitarbeitenden Personen (bei großen Aufwand) und natürlich nach dem Kundenforderungen ggf. natürlich auch nach der Genialität des ausführenden Programmierers.

Grüße

Frank

[Sanchez]

Da muss ich mein Vor-Postern zustimmen.
Bei uns wird das gute alte Prototyping verwendet. Der Kunde will halt schnell was sehen und ggf noch ein paar Wünsche und Änderungen haben. Da ist es schon öfters vorgekommen, dass ich einiges total über den haufen werfen musste. Mit einer anständigen Planung und der Einbeziehung der Kunden in die Planung wäre das wohl nicht passiert.

Aber da bei uns jetzt die ISO-Zertifizierung ansteht hoffe ich, dass ich bei der Gelegenheit ein paar Neuerungen einbringen kann.

Aus diesem Grund würd ich gern wissen wie bei euch der Entwicklungsablauf so aussieht. Ich denke doch, dass nicht mehr so viele einfach drauf los einen Prototypen programmieren und den immer weiter bis zum fertigen Produkt entwickeln und dabei immer wieder bereits funktionierendes über den Haufen werfen.

[sakura]

Zitat:

Zitat von Sourcemaker

Der Einsatz und Aufwand der bei der Planung betrieben wird richtet sich nach ...dem Kundenforderungen

Bei uns ausschließlich. Wir erstellen immer erst ein Lastenheft und anschließend ein Pflichtenheft. Wenn das Pflichtenheft vom Kunden abgenommen wurde, dann wird dieses 1:1 umgesetzt. Erst im Anschluß kann/darf der Kunde weitergehende Wünsche äußernh, welche wiederum in einer erweiterten Version des Pflichtenheftes festgehalten werden. Das geht solange, bis der Kunde glücklich ist.

Wir haben auch schon Kunden nicht bekommen (nie verloren!), weil denen unsere Art nicht passte, aber die, die mitmachen verlangen seit dem dieses Vorgehen teilweise auch von anderen Dienstleistern. Es ist einfach rigeros definiert, wer was wofür und wann macht. Wenn sich alle daran halten, ist es am Ende die effektivste und preiswerteste (Kunde)/gewinnbringendste (Dienstleister) Methode ;-)

...:cat:...

[Sourcemaker]

Hi Sakura,

wenn ich bei einer Individualprogrammierung die sagen wir mal momentan 10000 Eur kosten würde ein entsprechendes Pflichtenheft erstellen würde käme das Programm wahrscheinlich das Doppelte. Wenn man also diesen Kunden fragen würde dürfte die Antwort klar sein immer vorrausgesetzt das man den Kunden durch entsprechendes Renommee von seiner Leistungsfähigkeit überzeugen kann.
Ab einer gewissen Auftragsgröße sagen wir 100000 Eur oder bei der Entwicklung einer Standardsoftware mit entsprechend großen Erstellungswert wird eine umfangreichere Planung ein muß sein.

Was ich sagen will es ist relativ.

Grüße

Frank

[Sanchez]

Wenn ich mal davon ausgehe das ein 100.000€ Projekt umfangreicher ist als ein 10.000€ Projekt, dann ist wohl beim kleineren Projekt auch weniger Planung nötig.

[kiar]

hallo.

ich gehe seit geraumer zeit genau den weg, den sakura dargelegt hat. ich programmiere zwar nur so zum hobby, aber wenn amn keine struktur drin hat kann man sehr schnell den überblick verlieren. ich habe natürlich einen vorteil ich bin kunde und dienstleister in einem, da kann man sich das pflichtenheft hinbiegen.

@sourcemaker wenn der kunde ein 10000 euro projekt nur dann akzeptiert, obwohl der dienstleister auf ein pflichtenheft besteht, kommt der kunde spätestens, wenn eine weitere implementierung angezeigt ist und der das doppelte drauf zahlt.

ausserdem läuft es in der wirtschaft doch auch nicht anders erst die ausschreibung und dann das angebot.

in meiner branche kann man auch keine kompromisse machen, wenn es sein muss, muss es sein.

raik

habe hier ein buch 'uml mit delphi' autor : max kleiner. werde ich mir wohl doch mal intensiver reinsaugen müssen

[LarsMiddendorf]

Über das Verhältnis zwischen Planung und Realisierung habe ich mir auch schon öfter mal Gedanken gemacht. Das geplant werden muß steht außer Diskussion, aber wie ist das richtige Verhältnis.Gibt es da vielleicht einen sinnvollen Mittelweg. Mich würden da mal Meinungen aus dem täglichen Alltag von Softwareentwicklern interessieren:

-Ist es überhaupt möglich ein größeres Programm komplett zu planen und dann erst umzusetzen? Kann man alle Probleme komplett voher überblicken, so daß die tatsächliche Umsetzung dann auch elegant ist, oder geht man teilweise wieder einen Schritt zurück zur Planung?

-Oder ist es eventuell sinnvoller immer inkrementell Teile des Programms zu planen und direkt umzusetzen und zu testen?

-Was ist besser beim Softwareentwurf: Top-Down oder Bottom-Up?

-Wie detailliert sollte der UML Entwurf sein? Wenn man direkt alle Felder und Methoden einträgt, dann hat man ja im Prinzip keine höhere Abstraktionsebene als wenn man es direkt programmiert? Muß man für jede kleine Klasse ein Diagramm anlegen, die man doch schneller direkt programmieren könnte? Behindert man sich dadurch nicht selber?

[sakura]

Hi Lars,

hat Dich der Thread zum mitmachen animiert :mrgreen: Freut mich, also will ich meine nächsten 9ct auch noch loswerden... Dazu würfle ich Deine Sätze ein wenig durcheinander, so daß es mir passt :angle: Ausserdem greife ich immer wieder auf ModelMaker zurück, da ich mit dem Tool seit einigen Jahren arbeite. Es soll aber nicht heißen, daß es nicht vielleicht bessere Tools gibt.

Zitat:

Zitat von LarsMiddendorf

Mich würden da mal Meinungen aus dem täglichen Alltag von Softwareentwicklern interessieren

Dann mache ich mal den Anfang ;-)

Zitat:

Zitat von LarsMiddendorf

Gibt es da vielleicht einen sinnvollen Mittelweg.

Ja, ich glaube schon. Aber ist dieser für jedes Projekt etwas anders. Soll es nur mal schnell ein Utility sein, welches sich einer speziellen Aufgabe widmet, keinen Schnick-Schnack bieten soll, dann wird man oft wohl komplett ohne UML auskommen. Nicht jedoch, ohne einen festen Plan. Manchmal mag es reichen seich das Ziel zu merken (lösche alle Dateien die "$$$*.*" entsprechen), aber sich dieses zu notieren wird nicht schaden ;-)

Sollte es etwas mehr sein (lösche alle Dateien auf allen Rechnern im Netzwerk die "$$$*.*" entsprechen und älter als eine Woche sein), dann sollte man sich zumindest schon einmal etwas Gedanken machen, ob man da nicht vielleicht ein, zwei Klassen (Netzwerksuche, Dateifilter, ...) entwickeln kann, welche man später in anderen Projekten wiederverwenden kann. Diese sollte man dann vielleicht schon in einem UML-Tool (z.B. ModelMaker) erstellen und gleich dokumentieren. Warum?... ein paar Zeilen später.

Zitat:

Zitat von LarsMiddendorf

Ist es überhaupt möglich ein größeres Programm komplett zu planen und dann erst umzusetzen?

Kommt wohl wieder auf die Größe an, aber ist das denn nötig? Nehmen wir mal ein größeres Softwareprojekt, wie es in meiner Firma zur Zeit läuft. Planungs- und Umsetzungszeitraum ca. 18 Monate.

Zitat:

Zitat von LarsMiddendorf

Wie detailliert sollte der UML Entwurf sein?

Der erste Entwurf sollte gar keine Details enthalten. Wie auch, man muss ja erst einmal eine Idee aufs Papier bringen (MindMap Diagram). Darin sollte man erst einmal alle Ideen, Erfahrungen, Gedanken, Wünsche, Kundenvorschläge :mrgreen:, etc. notieren. Dann kann man anfangen sich Gedanken zu machen, was aus den Ideen genutzt wird, was warten kann und was man gar nicht braucht oder will.

Wenn man die Komponenten (oder Utilities, Teilprogramme, Funktionen, etc.) der ersten Stufe festgelegt hat, dann sollte man sich anschließend auch daran halten, damit man später nicht vom Weg abkommt.

Nun geht es ans erste Design. Man schaut welche Komponente welche Teilbereiche hat. Diese hält man dann wieder fest. Und spätesten jetzt sollte man sich auch im Klaren sein, was die Komponenten miteinander tun sollen (nicht das wie!) Auch sollte man schauen, ob man evtl. Dinge beachten muss, die die zurückgestellten Komponenten später benötigen, um sich in das Gesamtprojekt zu integrieren.

Zitat:

Zitat von LarsMiddendorf

Wenn man direkt alle Felder und Methoden einträgt, dann hat man ja im Prinzip keine höhere Abstraktionsebene als wenn man es direkt programmiert?

Jetzt kann man anfangen für jede einzelne Komponente eine Lösung zu ermitteln und diese in Klassen aufzuteilen. Wenn man diese Klassen hat muss man anfangen zu ermitteln, wie diese untereinander kommunizieren und welche Schnittstellen es gibt. Das alles sollte imho noch im Diagramm geschehen. Hier verlasse ich meistens die Diagrammebene und gehe später in den Code-Editor von ModelMaker. Das hat den Vorteil, daß ich später den Code wieder auf Diagrammebene "zaubern" kann. *break, mehr zum weiteren Weg kommt gleich...*

Zitat:

Zitat von LarsMiddendorf

Kann man alle Probleme komplett voher überblicken, so daß die tatsächliche Umsetzung dann auch elegant ist

Komplett - bestimmt, aber man braucht nur den IQ von Einstein + 200, die Intuition aller Frauen zzgl. der Gabe in die Zukunft der Kundenwünsche zu schauen ;-) Nein, ich glaube nicht. Aber man kann sich auf viele vorbereiten und offen planen, so daß man später nicht alles wieder umstoßen muss, nur weil der Kunden gerne Icons hätte und das ja auch sinnvoll ist.

Zitat:

Zitat von LarsMiddendorf

oder geht man teilweise wieder einen Schritt zurück zur Planung?

Ja! Wenn man merkt, daß es happert, dann sollte man nicht einfach eine Lösung an Ort und Stelle bauen. Das ist zwar meistens schnell gemacht, aber bei Projekten mit Größen von mehreren 1000 A4 Code ist das auch gefährlich. Keiner kann mir erzählen, daß er/sie dann noch die Hand ins Feuer legen würde, wenn die Änderung auch andere Stellen betrifft. Also lieber zurück zum Reißbrett und versichern, daß es passt. Änderung dort eintragen und erst dann(!) implementieren.

Zitat:

Zitat von LarsMiddendorf

Oder ist es eventuell sinnvoller immer inkrementell Teile des Programms zu planen und direkt umzusetzen und zu testen?

Teile eines Programmes - was sind diese? Andere Programme, dann ja! Oder doch nur eine Unit - hm, macht man doch eh, oder arbeitest Du an 6 Units gleichzeitig :shock: !weiterlesen!

Zitat:

Zitat von LarsMiddendorf

Was ist besser beim Softwareentwurf: Top-Down oder Bottom-Up?

Wie an den jetzigen Ausführungen merkst, gibt es keine eindeutige Antwort. Ich verfolge beide Wege gleichzeitig. Erst einmal Top-Down: Was will ich am Ende sehen und was soll es können. Danach jedoch strikt Bottom-Up: Ich weiß jetzt, was jede Komponente tun soll und auch etwa welche Klassen drinne sind. Jetzt stricke ich jede Lösung durch Lösung ihrer kleinen Probleme zu einem Gesamtwerk, welches hoffentlich auch hält ;-)

Zitat:

Zitat von LarsMiddendorf

Muß man für jede kleine Klasse ein Diagramm anlegen, die man doch schneller direkt programmieren könnte?

Bei mir: ja :!: Na gut, fast. Da nicht jede Klasse im Diagramm auftaucht, aber jede Klasse existiert in ModelMaker um evtl. bei Bedarf im Diagramm zu landen ;-) Warum denn? Na ja, wenn es ohne ModelMaker so viel schneller geht, dann werde ich nicht sofort wiedersprechen. Es ist bestimmt einfacher die Klasse mal schnell in Delphi einzutippen. Na gut, mache ich auch, aber im Anschluß importiere ich diese nach ModelMaker und dokumentiere diese auch. Anschließend erstellt ModelMaker mir mein RTF welches ich zu einer HLP-File als Doku kompiliere.

Warum? Einfach, ich kann jetzt víer Wochen/Monate später zurück kommen, schnell in die Doku schauen und den Fehler beseitigen oder vielleicht eine neue Funktion einfügen. Tools wie ModelMaker beiten einfach einen besseren Überblick über die einzelnen Strukturen, Beziehungen und Aufgabenlösungen.

Zitat:

Zitat von LarsMiddendorf

Behindert man sich dadurch nicht selber?

Anfangs dachte ich es auch, aber inzwischen liebe ich diesen Weg, da der auf Dauer immer schneller ans Ziel führt als noch einmal durch 5000 Zeilen Code zu springen, um sich die Beziehungen unter 3 Klassen anzuschauen.

Abschluß :roll:

Mit ModelMaker verwalten wir die aktuelle Version unserer Software (zumindest den Delphi-Teil) von Beginn an, importieren meist auch 3rd Party Codes, damit diese besser verständlich werden und noch behalte ich den Überblick über mehr als 7 MB Delphi-Quellcodes, 2 MB XML Definitionsdateien, 3 MB ASP Quellcodes und fast 3 MB Hilfedateien (ohne wirklichen Inhalt :shock:) :mrgreen:

...:xmas:...

[marvin.maybe]

Hallo,

UML (oder eine andere Modellierungstechnik) ist für kleine und große Software-Projekte ratsam. Bevor sich ein Entwickler an seinen Computer setzt und beginnt seine Ideen in Code zu gießen, sollte er sich wirklich überlegen, was er eigentlich tun möchte (bzw. muss) und dazu ist UML sicherlich gut geeignet.

Eine große Gefahr bei UML als Kommunikationsform innerhalb größerer Entwicklungsteams liegt darin, dass wenig begabte oder unerfahrene Leute UML-Diagramme erstellen und diese von anderen implementiert werden sollen. Wenn ich mir vorstelle, ein saumäßiges Design implementieren zu müssen, bekäme ich Ausschlag... Analyse, Design und Implementierung sollten dieselben Personen machen.

Ich fänd es klasse, wenn ich mein gesamtes Programm in einem UML-Builder "malen" könnte (incl. Attribute und Typen) und diese dann direkt in den Source-Code übertragen könnte. Natürlich müßte auch der Rückweg funktionieren: Wenn ich bespielsweise während der Implementierung merke, dass ich weitere Methoden benötige, müßten diese auch im UML-Diagramm erscheinen.

(Meiner Erfahrung nach, umfasst Implementierung ("Code tippen") ca. 20% einer Entwicklungsphase, der Rest ist Planung (Verstehen was gemeint ist, Design und Specification schreiben, ...), Test und Korrektur).

Gruß,
Jan.

[Tool-Box]

Hier ein Beitrag zu UML in deutscher Version (wer kein Englisch mag :twisted: ) :mrgreen:
http://www.toolbox-mag.de/data/tx42003artikel1.pdf

Gruss, Tool-Box :angle2: