Tool für High-Level Klassendesign-Entwurf
-
Hallo zusammen,
ich bin auf der Suche nach einem guten Tool für einen High-Level Klassenentwurf.
Dabei will ich nur den Namen der Klasse und ihre Zuständigkeiten in Stichworten angeben und nicht wie im UML Klassendiagramm schon konkrete Methoden und Attribute mit Signatur oder Datentyp.
Tortzdem möchte ich die Abhängigkeiten der Klassen untereinander (Nutzung anderer Klasse, Komposition, Vererbung) grafisch darstellen, also sowas wie das hier http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card,
nur als Graph und etwas konkreter was das Zusammenspiel der Klassen angeht bzw. ein abgespecktes UML Klassendiagramm.
Gibt es da nichts standardisiertes und die entsprechenden Tools?
-
Klassendiagramm ohne Attributen und Methoden
-
Stift und Zettel oder Methoden und Attribute einfach weglassen?
-
Leider zwingt einen jedes bis jetzt getestete UML/Diagramm-Tool (Enterprise Architect, visio, dia) dazu, Attribute und Methoden über komplexe Eingabemasken mit Typ, Signatur usw. anzugeben.
Einfach weglassen ist nicht die Lösung, weil ich die Zuständigkeiten der Klassen in diesen Feldern festhalten will.
Bzw. bräuchte ich im Prinzip eine Schablone mit zwei Feldern, oben der Klassenname, darunter die Zuständigkeiten als kurze Stichpunkt-Liste.Es wundert mich, dass da sonst niemand Bedarf hat.
Wie läuft denn der Design-Prozess nach UML ab?
Ich mach mir doch nicht Gedanken über Details von Schnittstellen, wenn ich noch nicht mal die grobe Architektur geplant habe.
-
Ich habe noch nie ein UML-Programm gebraucht.
Ich bin beruflich Webentwickler und mach privat jetzt in C++, dort aber noch auf Anfängerniveau. Auf Arbeit reicht mir wirklich ein Block und ein Kulli und das jetzt seit fast 15 Jahren, allerdings habe ich nie was sonderlich Kompliziertes gemacht. Meist habe ich mich in bestehende Projekte eingearbeitet und diese dann erweitert. Nur zwei Projekte habe wirklich von der Pike auf gemacht. Das waren aber die ersten Jahre als Programmierer und da hatte ich null Plan von irgendwas und habe einfach drauf losgemacht. Schließlich habe ich weder Programmierer gelernt noch studiert, noch nicht mal ein Abi habe ich.
OOP war in der Zeit auch noch kein Thema in PHP. Die Software läuft heute noch und wird erweitert. Wie gut die damit klar kommen weiß ich nicht, bin ja zum Glück nicht mehr dabei
-
C14 schrieb:
Wie läuft denn der Design-Prozess nach UML ab?
Um ehrlich zu sein, kannst du diese ganzen Tools für den Designprozess IMHO in die Tonne kloppen. Zettel und Stift sind angebracht.
Wo Tools zum Erstellen von Diagrammen dann ins Spiel kommen, ist wenn das ganze bereits Form angenommen hat und nun jemand anderem erklärt werden soll. Da macht sich ein ordentliches Diagramm natürlich viel besser als die hingekritzelten Notizen der Designer.
-
mgcmn schrieb:
C14 schrieb:
Wie läuft denn der Design-Prozess nach UML ab?
Um ehrlich zu sein, kannst du diese ganzen Tools für den Designprozess IMHO in die Tonne kloppen. Zettel und Stift sind angebracht.
Das ist ja gerade das Problem - also dass es keine vernünftigen Tools für "High Level Design" gibt (zumindest kenne ich auch keines).
Denn mit Zettel und Stift mag ich sowas auch nicht wirklich machen.
Ein Design-Prozess ist bei mir sehr dynamisch, da schieb ich oft Dinge zwischen Klassen oder Modulen hin und her.
Und mit Zettel und Stift nervt das.U.a. daher mache ich meist auch keinen Entwurf bevor ich loslege, sondern fange einfach an, und refactore dann wenn ich sehe dass irgendwas nicht passt. Also dass eine Funktionalität eigentlich wo anders hin gehört, eine Klasse in zwei gesplittet werden muss etc.
Das geht aber nur für kleine bis mittelgrosse Projekte gut, und vor allem auch nur wenn man alleine arbeitet, oder eng im Team mit anderen die ähnlich entwickeln, und vor allem auf ähnlichem Niveau sind.
Ein grösseres Projekt mit Leuten die ich eher als Anfänger bezeichnen würde könnte ich auf diese Art aber nicht umsetzen.
Also dann doch planen. Und wie gesagt: mit Zettel und Papier funktioniert das bei mir nicht wirklich.
D.h. ich würde mir auch ein Tool wünschen wie der OP es beschreibt.
Idealerweise sollte das Ding es einem ermöglichen ertmal nur mal Klassen zu definieren die nen Namen und vor allem ne hübsche Beschreibung haben. Die Beschreibung sollte Mehrzeilig sein können. Dann Abhängigkeiten erstmal einfach nur zwischen Klassen reinzeichnen -- ohne irgendwelche Member oder Parameter.
Weiters sollte das Ding unterstützen dass man Dinge (Klassen) einfärbt. Und dass man Module macht, also Container für Klassen. Dass man diese Module auch grafisch anordnen kann, ne hübsche Beschreibung reinschreiben kann etc.Und um die Module weiter zu ordnen wäre es nett wenn man Layers definieren könnte.
Die Ansicht sollte dann auch auf mehreren Detail-Ebenen möglich sein. Also z.B.
* Nur Layer mit Layer-Namen und Beschreibung
* Nur Layer + Module mit Modulnamen und Beschreibung
* Module mit Liste von darin enthaltenen Klassen (also ohne "Box" mit Inhalt für jede Klasse sondern einfach nur ein Bullet-Point mit dem Klassennamen)
* Module mit vollständiger Ansicht der darin enthaltenen Klassen (Box mit den ganzen Details)
* Einschränkung des Diagramms auf ein Modul
uswusf.Beispiel für Ansicht "Nur Layer + Module mit Modulnamen und Beschreibung":
http://i.msdn.microsoft.com/dynimg/IC407771.png
(Kommt nicht ganz hin, weil z.B. keine Dependencies eingezeichnet sind -- nur die zwischen den Layern sind implizit klar durch die Anordnung übereinander.)Dependencies sollten dabei auf allen Ebenen angezeigt werden können. Eine Dependency zwischen von einer Klasse X in Modul A, zu einer Klasse in Modul B sollte dabei einfach als Dependency von der Klasse X zum Modul B eingezeichnet werden.
Dependencies auf bestimmte Klassen/Module sollten auch ganz ausblendbar sein. z.B. damit man Dependencies zu irgend einem Logging oder Settings-System brav eintragen kann, aber nicht immer sehen muss -- weil die halt in vielen Fällen vollkommen uninteressant sind, und bloss alles unübersichtlich machen.
Dann sollte man später das ganze natürlich auch detailierter angeben können. Also z.B. Funktionen und Member hinzufügen. Für die Typen der Funktionen und Member sollten dabei automatisch Abhängigkeiten eingezeichnet werden.
Und vor allem sollte so ein Teil einfach gut bedienbar sein. Wenn man z.B. eine Funktion (inklusive aller Parameter und Dependencies) von einer Klasse in eine andere rüberschieben will, dann sollte das einfach über Drag & Drop gehen. Nicht dass man dazu irgend einen Dialog aufmachen muss, dort die Funktion auswählen und mit "cut function" entfernen, und dann den selben Dialog für die 2. Klasse aufmachen und dort mit "paste function" wieder einfügen. Oder ganz schlimm: in einer Klasse löschen und in der anderen dann neu eintragen.
Ebenso wenn man Module zwischen Layern verschieben will.Wenn das Tool dann noch bestehende Projekte parsen kann, und die darin enthaltenen Objekte erfassen, dann hätte ich auch nix dagegen. Muss aber nicht sein. Wobei es mit Tools wie Clang sogar für C++ möglich sein sollte. (Für C# geht es sowieso relativ einfach, da muss man eigentlich nur die Metadaten der fertigen Assemblies auswerten.)
Und ganz toll wäre es, wenn das Tool die Dinge die man nicht aus dem Code bzw. den Assemblies rausparsen kann (zu welchem Modul gehört eine Klasse, zu welchem Layer gehört ein Modul, etc.) doch irgendwie in den Source reinschreiben kann. z.B. in Form spezieller Kommentare, oder in C# vielleicht auch Attribute. Oder ne Klassenbeschreibung aus dem 1. Absatz der Klassendoke (Doxygen, C# XML-Kommentare, ...).Und falls es doch etwas geben sollte was auch nur grob in diese Richtung geht, bitte lasst es mich wissen!
-
hustbaer schrieb:
...
Hört sich doch nach einer recht ausführlichen Spezifikation an? Vielleicht findet sich sogar einer, der sowas schreiben würde.
-
Meinste ich soll es selbär machen?
Hab' ich mir schon manchmal gedacht. Ich glaub nur dass ich nicht das Durchhaltevermögen hätte dafür.
Und vor allem ist die Motivation was für Gratis zu machen nicht so gross bei mir
-
Enterprise Architect?
-
Wenn der EA nicht so eine besch...(eidene) Benutzersteuerung hätte (ich sage nur "Modale Dialoge mit fester Größe", dann hätte ich den auch vorgeschlagen.
Und dann beruht der auch noch intern auf einer uralt ACCESS-DB..., so daß das Anbinden an ein VCS (wir verwenden den TFS) ein echter Graus ist.
