Wer nutzt die Modellansicht (UML)

[stahli]

Die Beziehungen von Klassen werden dargestellt, wenn sich die Klassen in einer Unit befinden.
Wie man aber damit im Detail arbeitet ist mir nicht klar geworden.

Man kann einer Klasse auch in dem graphischen Bereich Eigenschaften und Methoden hinzufügen. Das scheint mir aber sehr unfexibel zu sein. Z.B. ist mir unklar, was an der Stelle mit Parametern etc. ist.
(Habe mir aber auch nicht die Zeit genommen, mich lange damit auseinander zu setzen.)

Daniel hatte dazu (denke ich) mal ein wenig in einem Video/Stammtisch gezeigt - bin aber nicht mehr sicher.

Für ein Projekt kann man ein Bild erstellen lassen, das alle verwendeten Klassen graphisch darstellt, allerdings nicht die Beziehungen zueinander.

Was Enterprise zu Prof mehr kann, weiß ich auch nicht. Wenn es grundsätzlich sehr hilfreich wäre, wäre wohl mal ein Webinar sinnvoll.
Hier gibt es ein englisches zum JBuilter 2008 (vielleicht gibt es eine Ähnlichkeit), das lässt sich aber bei mir nicht abspielen.



Edit @Uwe Raabe: Danke, das lade ich gleich mal.

[haentschman]

Zitat:

Edit @Uwe Raabe: Danke, das lade ich gleich mal.

...das werde ich mir wohl schenken... Download: 70 MB ... 7 - 11 KB/s ... 1 Std 50 Minuten !

Haben die nur ne ISDN Leitung ?

[himitsu]

Zitat von Sir Rufo:

Bei Delphi kann man sich aus einer Klasse das zugehörige UML anzeigen lassen

• Ansicht / Modellansicht
• Bei der Projektverwaltung (normalerweise auf der rechten Seite) gibt es jetzt einen neuen Reiter "Modellansicht"
• Dort in dem Tree den Namespace (Unit) der Klasse auswählen und schwupps wird einem dieser Namespace mit alle Klassen als UML angezeigt

Schick ist hierbei, dass man nun dieses UML bearbeiten kann und der Sourcecode der Unit wird automatisch nachgeführt

funktioniert und ich seh endlich mal was

Ein Problem existiert aber noch.

Zitat von Medium:

UML ist eher was für Großprojekte, wo einer Vielzahl von Entwicklern vermittelt werden muss wo die Glocken hängen, und wo ein Koordinationsteam eine Gesamtübersicht über ein komplexes Geflecht wahren muss. Man wird sowas daher auch öfter in Visio ...

Visio (MS Office) haben wir auf der Arbeit nicht.
Ein Kollege macht's wohl mit Inkscape, aber in diesem Teil seh ich nicht durch, bzw. finde nichts.

Im Prinzip wollte ich kein genaues Model eines unserer Module, sondern "nur" eine funktionalere Übersicht.

Vom Aussehn etwa so wie das im Delphi, bzw. wie in NClass, nur daß ich da eigentlich keine ganz genauen Bezeichnungen wollte.
Der Propertyname/Funktionsname der wichtigsten Dinge, die entsprechenden Verknüpfungen und ein paar Kommentare/Infos wären ideal, also so, daß man "irgendetwas" frei zusammenklicken kann.
Denn mit der kompletten Klassenstruktur auf einem Blatt wird es auch nicht unbedingt gleich übersichtlicher ... da kann man auch in die Units reingucken, wenn man etwas genau wissen will.

[stahli]

Zitat von haentschman:

Haben die nur ne ISDN Leitung ?

Bei mir waren es ca. 3 Min.

Das Video ist schon interessant. Welchen Nutzen das aber letztlich im effektiven Einsatz bringt, kann ich nicht recht beurteilen (habe nur XE Prof).

[Luckie]

Unser Berufsschullehre ist voll drauf abgefahren. Aber ich denke, es ist nur nutzbar der Praxis grob die Abhängigkeiten zu skizzieren, um Kollegen die Zusammenhänge zu verdeutlichen und um über die grobe Struktur zu diskutieren. Aber zu Dokumentationzwecken ungeeignet, da es nebenbei gepflegt werden muss un das macht niemand. Ich habe schon UML-Diagramme vom Chef gesehen, die waren so was von überholt und standen noch im firmeninternen Wiki, das war mehr kontraproduktiv, weil sie vorne und hinten nicht mehr stimmten. Und bei uns war das dann auch mehr so ein kanstriertes UML, weil niemand so richtig die Syntax kannte. Pfeile und Beziehungen waren nicht richtig dargestellt, aber zur Erklärung reichte es. Meist ist es ja auch so, dass da noch Felder und Methoden hinzukommen, die man erst bei der Entwicklung hinzukommen.

[mikhal]

Genau diese Aktualisierung nimmt das Two-Way-Tool von Delphi selbständig vor: bei Änderungen im Quelltext wird das Modell aktualisiert und wenn das Modell geändert wird, wird der Quelltext aktualisiert (soweit es sich um Objekt-Definitionen handelt).

Kann übrigens ModelMaker auch...

Grüße
Mikhal

[ralfiii]

Zitat von Luckie:

Aber ich denke, es ist nur nutzbar der Praxis grob die Abhängigkeiten zu skizzieren, um Kollegen die Zusammenhänge zu verdeutlichen und um über die grobe Struktur zu diskutieren. Aber zu Dokumentationzwecken ungeeignet, da es nebenbei gepflegt werden muss un das macht niemand.

Wie schon erwähnt werden die Diagramme automatisch aktualisiert.
Die Diagramme die man "per default" aus Delphi rauskriegt nutzen allerdings imho wenig.
Normalerweise erstellt man noch zu einem Programm ein paar paar Klassendiagramme (rechte Maustaste in das Modellansicht-Fenster, "Hinzufügen" -> "Klassendiagramm").

In dieses Diagrammen kann man das Zusammenspiel der Klassen in verschiedenen Aspekten zeigen.
(man - oder ich - macht ja meistens kein Klassendiagramm mit ALLEN Klassen sondern immer kleine Sub-Sets.)

z.B.:

Angenommen du hast eine Hierarchie von Klassen die Bilder in verschiedenen Dateitypen lesen können, dann wirst du die ganzen Reader-Klassen nicht in einem Diagramm zeigen dass deinen Photoshop-Clone beschreibt. Dort steht z.B. nur eine TMyPicureReader-Klasse drin.

Und in einem weiteren Diagramm willst du die Hierarchie der ganzen TMyPicureReader-Nachkömmlinge zeigen. Das machst du dann in einem weiteren Klassendiagramm.

So bleibt jedes dieser Diagramme übersichtlich.

Delphi kann sowas nicht automatisch erzeugen, da Computer nunmal nicht intelligent sind.

Praktisch in diesem Fall: Man zieht die Klassen die man zeigen will einfach auf das leere Diagramm und Delphi erzeugt automatisch die Beziehungen (die "Pfeile") dir Dir dann zeigen was woher abgeleitet ist und wo eine Assoziation sitzt.

Zum Doku-machen und zum Übersicht bewahren ein ganz nettes Tool.

In Rational Rose konnte man dann noch Use-Cases erstellen, wo man sozusagen den "Flow of events" für ein paar wichtige Use-cases auflistet und Rose hat dann auch gleich automatisch gewährleistet, dass die aufgelisteten Methoden in den Objekten da waren. Das kann Delphi Prof. nicht. Vielleicht ist das bei Enterprise ja dabei.

[Der schöne Günther]

Wenn ich denn auch einmal meinen Senf hierzu geben darf:

Ich nutze UML (zu 90% Klassendiagramme) wirklich exzessiv. Sowohl um überhaupt Klassen und Interfaces zu entwerfen, als auch Programmstrukturen und Abhängigkeiten aufzubauen und zu dokumentieren. Sowohl für mich ganz alleine, als auch um es anderen Leuten zu vermitteln.

Ich könnte es mir ehrlich gesagt auch nicht anders vorstellen.

Das, was das RAD Studio bietet, ist meiner Meinung nach leider nicht wirklich das Gelbe vom Ei. Man hat sich zwar schon Mühe mit Farbverläufen und ähnlichem gegeben, aber insgesamt schien man eher darauf bedacht sagen zu können "Wir haben volle UML-Unterstützung in beide Richtungen, wie das Visual Studio".


Also habe ich mich auf die Suche gemacht nach einer guten UML-Software, die auch volles Round-Trip-Engineering für Pascal beherrscht: Ändere ich etwas am Diagramm, ändert sich mein Quelltext. Ändere ich meinen Quelltext, sieht man das direkt im Diagramm.
Der ModelMaker hat mir wirklich die Freudentränen in die Augen getrieben - Innere Klassen, Generics, nichts bringt das Teil aus dem Takt. Die Pascal-Unterstützung ist wirklich perfekt.

Ich habe in der Vergangenheit größtenteils entweder kurz mit beliebiger Freeware oder Visual Paradigm oder MagicDraw - Der ModelMaker gefällt mir hierbei sogar noch am besten. Und der Preis von 200€ für einen Benutzer ist wirklich nicht übertrieben.


Ich bin verwirrt, dass das Teil hier im Forum nicht bekannter ist? Ich könnte mir nicht mehr vorstellen, nur immer auf Quelltextzeilen zu starren sondern brauche ab und an auch einen grafischen Überblick über das gesamte (Sub-)System bis hinunter zu den einzelnen Klassen - Wie handhabt ihr das sonst?

[Furtbichler]

Delphi wird klassischerweise nicht verwendet, um hochkomplexe Anwendungen in SOA, MVVM oder MVC Architektur zu entwerfen. Ich habe es in den vergangenen 30 Jahren nicht verwendet, aber beim aktuellen Projekt bringt erst UML Klarheit ins Dickicht, denn hier wird sehr großen Wert auf die klare Trennung zwischen den Subsystemen/Diensten gelegt.

Bei Delphi kann man ja eigentlich kreuz und quer Abhängigkeiten haben bzw. kann man nicht allzuviel dagegen unternehmen, denn sowas wie private Units gibt es ja nicht. Private Klassen sind zu strikt und dazwischen gibt es leider nichts.

Ich arbeite eigentlich nur noch mit C# und da ist es extrem wichtig, mit UML eine klare Struktur in das Klassenwirrwarr zu bringen.

[Daniela.S]

Es kommt immer darauf an, was man von der UML nutzt. Ich finde UseCases sind eine sehr gute Möglichkeit das System ausreichend abstrakt darzustellen, dass der Kunde und der Entwickler sich auskennen und sich einig sind welche Aufgaben das System übernimmt. Mit der Beschreibung dazu kann der Kunde selber reflektieren ob das Ding genau das tut was er will, oder er findet selbst Optimierungen. Der Aufwand hält sich dabei echt in Grenzen und wenn man UseCases Konsequenz erstellt, kann man als Entwickler auch die Klassen und den Aufbau daraus gewinnen. Bislang konnte ich bei der Anforderungsanalyse die besten Ergebnisse mit UseCases erzielen. Das schlimmste ist ja die Anforderung des Kunden nicht oder falsch verstanden zu haben und einfach darauf los zu entwickeln. (aber wer macht denn das schon? *gg*) Dann hat man zum Schluss eine vielleicht ganz tolle Anwendung, aber sie hilft dem Kunden nichts, weil sie anders arbeitet als er erwartet oder schlimmstenfalls gar nicht das tut was er möchte.

Ich verwende eigentlich nur die abstrakteren Diagramme um einen Überblick auf das System zu ermöglichen. Klassendiagramme oder Interaktionsdiagramme (Sequenz bzw. Aktivitätsdiagramm) nur ganz, ganz selten. Die sind natürlich sehr detailliert und ändern sich rasch. Da ist dann immer die Frage inwieweit sich der Aufwand dafürsteht.

Aber es stimmt leider, dass Delphi für MVVM komplett ungeeignet ist. Die Bindings sind im Vergleich zu C# in VS komplett unterlegen. Es gibt auch nichts vergleichbares zum ICommand Interface. Daher ist eine saubere Aufteilung meines Erachtens nach nur bedingt möglich - bei größeren Projekten aber unumgänglich. Das Schlimmste ist der Doppelklick auf einen Button und dann die Logik dahinter reinschreiben. Eine Aufteilung der Anwendung in Layer wird immer wichtiger, vor allem auch, wenn man für iOS, OSX oder den kommenden Android (Linux?) Plattformen programmieren möchte. Den "Compiler everywhere" Ansatz ohne Änderungen halte ich nicht für sinnvoll (Stichwort UI Guidelines der OS Hersteller).

SOA kann man aber schon gut genug umsetzen finde ich. Obwohl C# auch hier mehr Möglichkeiten bietet.

Eine Dokumentation ist halt immer ein leidiges Thema. Die, die sich mit dem System auskennen brauchen es nicht und verstehen nicht warum sie die Doku machen sollten. Dabei kommt ein neues Teammitglied ohne Doku kaum nach und spätestens nach einigen Monaten/Jahren, wenn niemand weiterentwickelt hat, wären sie selbst froh wenn sie eine Doku zu hätten. Und noch schlimmer ist eine Doku die nicht am letzten Stand ist... dann lieber gar keine Doku.