UML

[Manfred]

Hallo,

ich denke mal das gehört hier rein.

Kennt jemand von euch ein Tool, mit dem man relativ günstig die Verknüpfungen von Tabellen grafisch darstellen kann?

Ich meine das fällt in den Bereich UML..... oder zumindest in einen Teil davon. Es geht mir alleine nur darum, die Verknüpfungen von (Relationen) Tabellen irgendwie übersichtlich und leicht änderbar darzustellen.

Ich hatte mal mit Rational Rose gearbeitet, aber das ist schon lange her und das war auch zu umfangreich.

VX 3.x soll das ja mal später können, wie die Vorausschau bei Alaska zeigt, aber solange warten?

[brandelh]

Hallo Manfred,

Früher habe ich das mit 'Flowchart' gemacht (Programm zur Anzeige von Programmabläufen, etwas zweckenfremdet
Neuerdings habe ich auch Excel verwendet, wobei das reine Handarbeit ist (Linien und Pfeile malen, Kästchen um den Text ...)

[Manfred]

Hi Hubert,

es geht mir darum, das eine Pfeilverbindung von Tabelle zu Tabelle zu erstellen ist, die auf das jeweilige Feld der einzelnen Tabellen zeigt. Wenn ich dann aus Platzgründen die Tabelle grafisch auf dem Blatt verschieben muß, dann soll die "Verknüpfung" mit dem Pfeil erhalten bleiben und automatisch nachziehen.

Mit Excel, bzw. einem Grafikprogramm habe ich das schon mal ausprobiert, aber die Pfeile bleiben dann schön treu da stehen, wo sie gezeichnet waren.

[brandelh]

Hallo Manfred,

ich sagte ja viel Handarbeit.

Mit Flowchart wurden die Linien mitgenommen, aber man kann dort nicht wirklich genau auf ein Feld zeigen, sondern nur auf einige Andockpunkte.

Vielleicht kennt ja jemand was besseres, warten wir es ab.

[Rolf]

Hi Manfred

ich hab mal mit Jumli gearbeitet. War eigentlich zufrieden bis ich aus Zeitgründen wieder zu Stift und Papier genommen habe. Schau es dir mal an.

www.jumli.de

Gruß Rolf

[Manfred]

Hi Rolf,

danke für den Hinweis. Ich habe es mal runtergeladen und werde in einer ruhigen Minute mal ein Auge darauf werfen. Ich schätze, dass kommt meinem Problem recht nahe.

[brandelh]

Hi Rolf,

War eigentlich zufrieden bis ich aus Zeitgründen wieder zu Stift und Papier genommen habe

Eigentlich sollte doch so ein Tool Zeit sparen, kannst du kurz erläutern, warum es länger dauert ?

[Manfred]

Hi Hubert,

ich schätze einmal, da dass Tool nicht für Xbase++ ist, muß eben alles händisch erfaßt werden und da geht Zeit bei drauf.
Normalerweise wid das gesamte Projekt verwaltet und generiert sich alles selbst aus den Programmdaten.

Naja, wie schon erwähnt.... VX 3.0 .........

[brandelh]

Hallo Manfred,

dass wir es für den Quellcode nicht nutzen können ist mir schon klar, aber ich denke die Planung der Datenstrukturen sollte doch mit einem Tool schneller sein als mit der Hand - vorallem bei Änderungen.

Also nur auf die Planung und Dokumentation bezog sich meine Frage.

Tja VX 3.0 noch lange ist es hin ...

[Manfred]

Hubert,

naja, dafür sind diese Tools wohl nicht gedacht. Wer braucht schon Tools, die "nur" Tabellenverknüpfungen darstellen, z.B.? Da ist dann halt jede Menge drumherum und dann wird es wieder zeitkritisch.

[brandelh]

Hallo Manfred,

eigentlich sollte man mit so einem Tool die Datenstrukturen komplett planen bevor man ans Programmieren geht.

Und 2 Jahre später wird man für jede Stunde danken, die man in die Dokumentation gesteckt hat.

[brandelh]

PS: fairer Weise muss ich zugeben, dass keine meiner Dokumentationen diesem hohen Anspruch gerecht wird

[Manfred]

Das ist jetzt mal ein Thema:

Mal ganz ehrlich, wer weiß wirklich schon am Anfang, wie alles auszusehen hat?
Alle Projekte, die ich angefangen habe, endeten später ganz woanders, als am Anfang geplant, weil irgendwer immer wieder auf der Bildfläche erschien und meinte mitteilen zu müssen, dass sich wieder etwas geändert hat, er es am Anfang ganz anders verstanden hat, oder es doch schön wäre, wenn das und das auch noch mit drin wäre. Usw. Usw. Usw.
Wenn alles so einfach wäre, dann gäbe es keine Verzögerungen, keine Fehler, keine Fehlkalkulationen.
Wer kennt irgendeine Software, die umfangreich ist/war, in der Planung lag, das Budget nicht überschritt, innerhalb kürzester Frist fertig, und somit nicht der Technik hinterherhinkte und dann auch noch danach unverändert blieb?

Na, ganz ehrlich, wer kennt sowas?

[brandelh]

Hallo Manfred,

ich nicht

Ich meinte aber auch nicht, dass die Datendefinition unveränderlich feststeht. Da kann und muss man ab und zu anpassen. Mißverständnisse gibt es auch nur all zu leicht. Gerade deshalb ist es doch schön die Dokumentation flexibel zu gestalten (das war ja auch dein Einwand gegen PAINT etc.).

Keines meiner Programme lag im Zeitplan.

Dennoch bin ich oft froh in alten Sitzungsprotokollen nachsehen zu können, was damals beschlossen wurde. Ich würde mir wirklich wünschen ein Programm zu haben, mit dem ich die Datenbeziehungen planen und grafisch darstellen kann. Wenn es daraus DBFs etc. erzeugt umso besser, aber die DOKU (inkl. Bemerkungen je Feld) würde mir schon reichen.

[Manfred]

Hi Hubert,

ich auch nicht..

So wie ich es von Rational Rose her kenne, habe ich es im groben Überblick bei jumli auch erkannt. Du erstellst die Klassen, kannst die iVar und Methoden usw. dazu erfassen, eine Erklärung eintippen und dann halt über die iVars (die bei mir auch die Datenbankfelder enthalten) die Verknüpfung untereinander machen. Bei mir hat jede DB ein Objekt, das die DB verwaltet usw. Und deshalb würde es mir schon für den Anfang so genügen, weil ich dann halt damit die RELATIONEN der DBs anzeigen kann/könnte.

[brandelh]

Hallo Manfred,

wenn ich mir das so anhöre (iVar, Klassen, Methoden ...) ist das Programm nicht das was ich brauche. Für die Datenbeschreibung eines fremden Programmes habe ich mir mal eine Anwendung geschrieben, in der ich dann die Dateien und Felder dokumentieren konnte. Allerdings ohne direkte Verknüpfung der externen Schlüssel (nur Verbal im Text).
Auch kann ich diese Verknüpfungen nicht grafisch darstellen, was ich vorgesehen habe war ein Export für SQL Dateiimporte und einer für den Text, der dann mit Cut und Paste in Word eingefügt und mit mehreren Suchen & Ersetzen Macros die Formatierung aufgebaut hat (diese war als Schlüsselwörter im Text enthalten).

Mal sehen wenn ich wieder etwas Zeit habe, eventuelle sollte ich mein Programm erweitern, grübel grübel

[Rolf]

Hi Hubert

Das Zeitproblem tritt nicht unbedingt beim Anlegen eines neuen Projektes auf. Sondern wie schon von euch erwähnt, dass Änderungen sowohl in der Dokumentation als auch im Programm eingepflegt werden müssten. Also an 2 Stellen.

Da ist es eben schneller, wenn man kurz eine Notiz an den Rand der Doku macht, als wieder alles neu zu verschieben und und und

Das Einarbeiten der Änderungen in die Dokumentation wird dann leider meistens doch vernachlässigt.

Ansonsten gilt leider Quellcode hat Vorang vor Dokumentation
was auf längere Sicht dann, aber auch nicht immer Zeit spart.


Gruß Rolf

[brandelh]

Ansonsten gilt leider Quellcode hat Vorang vor Dokumentation was auf längere Sicht dann, aber auch nicht immer Zeit spart.

Besonders wenn dann nach einiger Zeit niemand mehr weiß ob das im Quellcode so gewünscht wurde (Fehler in Vorgabe), oder ob es da Mißverständnisse bei der Umsetzung gab (Fehler des Programmierers).
[-o<

[Manfred]

Dafür gibt es ja Pflichtenhefte! Und die sollte ja jeder gute Projektleiter vorher genauestens erstellen.

[brandelh]

... Pflichtenhefte! ... Projektleiter ...

Was'n das da ...

Bei unserer Inhouse Entwicklung (PC-seitig) setzen wir uns mit dem Fachbereich zusammen und was da raus kommt, kommt in die Dokumentation rein, die dann der Entwicklung dient. Somit entspricht das in etwa deinem Pflichtenheft.

[Manfred]

Janu.... tschuldigung.....

solange das alles für "inhouse" produziert wird, geht das noch. Aber wehe, man will damit an fremde Kunden und legt nicht vorher fest, was wie wo gewünscht ist. Das dürfte ein Fiasko werden. Pflichtenheft anfertigen und dann auf jeden Fall unterschreiben lassen. Jede Änderung dokumentieren und wenn, getrennt abrechnen. Ansonsten wird es einen Fall geben, der nicht mehr endet. Das ist die oberste Warnung, die man bekommt, wenn man sich mit Trainern für Projekte unterhält. Später heißt es dann vom Auftraggeber sonst: "Das war so nicht bestellt" "Das sollte auch noch mit rein". "Dafür zahle ich nichts".
Wenn alles seinen korrekten Weg geht, dann kann später schön abgerechnet werden.

Schau Dir SAP an, da kostet alles später mehr, als vorher geplant, aber die haben in der Regel alles aufgeschrieben und kassieren dann. (habe ich so gehört)

[Jan]

Zur Zeit mache ich auch fast ausschließlich InHouse-Entwicklung.

Viele Sachen die ich da mache kommen einfach, weil im Gespräch mit einem Mitarbeiter ein Punkt angesprochen wurde. Der mir nie gemeldet wurde. Worüber sich aber jeder aufregt. Frust pur. Auf beiden Seiten. Warum können die sich nicht direkt bei mir melden und das klären?

Aber einige Dinge, besonders die, die die ganze Tabellenstruktur umwerfen, kommen vom Chef. Das sind dann meist größere Projekte. Wo er mir sagt: Das und das muß funktionieren. Der übliche Weg ist, daß ich dann mit den betroffenen Mitarbeitern rede was denn nun wirklich dahinter steckt. Und mit denen mehr opder weniger lange und ausführliche Dsikussionen habe. Denn meist tauchen da irgendwo ganz fiese Fallstricke auf, an die der Chef nicht einmal im entferntesten gedacht hat.

Die Umsetzung ist dann komplett meine Sache (ich bin schließlich der einzige Programmierer hier ) Bis zur Freigabe hat niemand eine Ahnung, was ich da treibe. Will meist auch keiner wissen.

Was ich jeweils im Code getan habe ist ebenfalls alleine meine Sache. Niemand kontrolliert das, es würde auch niemand verstehen. Wobei ich mir angewöhnt habe jede Änderung mit Datum und Namen und einer kurzen Begründung im Code zu versehen. Meine beiden Vorgänger haben das nie gemacht. Was jetzt warum wo steht kann ich oft nur in stundenlanger Suche herausfinden. Und viel zu oft auch nur durch ausprobieren feststellen. Da hätte ich mir durch eine halbwegs ordentliche Doku schon viele Stunden Arbeit und manch graues Haar sparen können!

Gleiches gilt für die Tabellenstrukturen. Die sind nirgends dokumentiert. Da kann man häufig einfach nur mit Suchfunktion durch den Code gehen und schauen, was wird wann warum in welche Tabelle geschrieben.

Gerade bei den Tabellen finde ich eine vernünftige Doku allerdings relativ aufwändig. Vor allem dann, wenn Änderungen kommen. Und man alles von Hand "gezeichnet" hat. Da würde ich mir dann auch oft ein vernünftiges Programm wünschen um das schnell und sauber ändern zu können. Aber Chefs schauen da eben immer sehr aufs Geld...

Und eine Erfahrung habt Ihr sicher auch alle schon gemacht: Es ist schwierig, sich in fremden Code reinzulesen. Vor allem undokumentierten (da schmeiße ich dann manchmal einfach riogoros raus und schreibe neu, das ist schneller als reinlesen und verstehen versuchen). Aber selbst der eigene ist nach spätestens 6 Monaten Fremdsprache, wenn man da nichts zu geschrieben hat.

Jan

[Manfred]

Hi Jan,

ich bin einmal gespannt, was ich in >6 Monaten von meinem Code halte. Ich schreibe das derzeitige Projekt komplett neu und habe versucht an allen Ecken und Kanten eine Erklärung zu schreiben, warum weshalb wieso. Mal sehen, ob ich da dann besser durchblicke als durch das Original unter Clipper. Bei dem habe ich auch graue Haare bekommen, als ich es durchgelesen hatte. Glücklicherweise habe ich noch/wieder im Kopf, in welche Richtung der Zug fahren muß, aber das hilft auch nicht immer.

[brandelh]

ein Punkt ... Der mir nie gemeldet wurde. Worüber sich aber jeder aufregt.

JA das kenne ich auch, oder noch besser, ich sehe dann wie mit Biegen und Verrenkungen Plausis umgangen werden, weil sie unerwünscht sind oder der Sachbearbeiter das anders sieht. Meist haben die Plausis recht, den anderen Fall kann man aber auch nicht ahnen ...

Die Umsetzung ist dann komplett meine Sache (ich bin schließlich der einzige Programmierer hier )

Du hast ja die Anwender vorher gefragt, also ist das OK.
Früher hat die EDV entschieden, was der Anwender so braucht, bzw. meist nicht braucht. In letzter Zeit kommt das wieder öfters vor - schließlich ist Zeit auch Geld.