Unit-Abhängigkeiten visualisieren

[grizzly]

Nachtrag vom 21.03.2008
Habe vorige Woche festgestellt, daß UnitUsage 0.5 mit den allerneusten DOT Versionen nicht mehr richtig zusammenarbeitet. DOT.exe hat scheinbar das Format seiner temporären Ausgabe-Dateien leicht verändert.
Ich habe deswegen mal einen kleinen Hot-Fix gebastelt.

Leider bin ich noch nicht dazugekommen, alle von Gruber_Hans_12345 vorgeschlagenen Änderungen aufzunehmen. Somit bringt die 0.6 nur folgende neue Features:
- Läuft mit der momentan aktuellen DOT.exe
- WMF-Export und Drucken leicht verbessert (Die alte Version verschluckte manchmal Linien am Rand)
- Hervorhebung von Units deren Source-Code neuer ist als ein vorgegebenes Datum
- Einige Kleinigkeiten auf der Oberfläche (vermutlich mit neuen Bugs)

Source und binaries wie üblich hier: UnitUsage. (Hier gibt es auch noch die alte 0.5)

und im Anhang.


---- Ursprünglicher ursprünglicher Text --------------------------------------
Nachtrag vom 12.03.2007
UnitUsage ist nun bei Version 0.5 angelangt. Ein paar kleine Verbesserungen hat es gegeben (aber leider nichts weltbewegendes).
Binaries, Screenshot und Kurzbeschreibung gibt es nach wie vor hier im Anhang. Sourcecode (in seiner ursprünglichen Häßlichkeit) gibt's auf der zugehörigen Webseite von UnitUsage.

---- Ursprünglicher Text (Links erneuert) --------------------------------------
Erst kürzlich gab es einen Thread mit einem Programm zur Visualisierung von Unit-Abhängigkeiten unter Zuhilfenahme von GraphViz.
Genau soetwas hatte ich vor längerer Zeit auch schon begonnen und dann in meiner Firma ein wenig weitergepflegt.
UnitUsage ist nicht perfekt. Es kann auch nicht analysieren, welche Units gar nicht verwendet werden (da gibt es eh schon genug Tools dafür).
Die Stärke von UnitUsage ist das bequeme Browsen mittels Maus-Klick innerhalb der Unit-Verknüpfungen:

Screenshot siehe Anhang

Ich stelle UnitUsage mal hier in der Freeware-Abteilung vor, werde es aber Open-Source machen, sobald ich den Source-Code soweit aufgeräumt habe, daß ich mich nicht mehr allzusehr genieren muß

Eine notdürftige Bedienungsanleitung findet sich hier: PDF 400KB (Die hat's bitter nötig, weil das User-Interface ist ein wenig sonderbar)

Unit-Usage 0.5 gibt es gezippt hier: ZIP 430KB
(Verwenden auf eigene Gefahr. Braucht's hier einen Disclaimer?)

Bei der Code-Analyse berücksichtigt UnitUsage zwar Compiler-Direktiven und Switches (auch so Zeug wie $ifopt etc...), liest auch Include-Dateien, kommt aber mit einigen neuen Konstrukten (Wie z.B. {$IF...} ) nicht zurecht. Units mit solchen Compiler-Direktiven werden dann ohne "Child"-Units angezeigt.

Nicht vergessen: Um UnitUsage zu verwenden benötigt ihr dot.exe von www.graphviz.org. Das ist das Teil, was den Löwenanteil der Arbeit übernimmt.

Gruß
Michael

[edit=sakura] Der ScreenShot reicht als Anhang und muss nicht gleichzeitig im Text gepostet werden. Mfg, sakura[/edit]

[MaBuSE]

Zitat von Gruber_Hans_12345:

wollte es mal probieren, als WMF exportieren, und dann ins coreldraw rein, das hat ja nen posterdruck

allerdings macht das dot bei den pfeilen ein paar fehler, (sieht zumindest so aus) da gibts ein paar pfeile ohne linien ... leider hab ich das wmf nicht mehr, werds bei gelegenheit noch mal neu machen, und reinzoomen

Du kannst auch in der *.dot Datei die Auflösung (size="10" -> 10 inches) und das Seitenverhältnis (ratio="0.7")ändern.
[edit]Was vorallem bei jpg & co interesant ist. Aber auch bei Vektorgrafik wird die Schrift kleiner je größer das size ist.[/edit]

Code:

DiGraph Uses {
  graph [ratio="0.7"];
  node [label="unit dependencies for Project1.dpr"];
  "Project1.dpr" [shape=box, style=filled, color=red]
  "Project1.dpr" -> "Unit1.pas";
  "Project1.dpr" -> "Unit2.pas";
...
}

Siehe Handbuch (Anhang Tabelle 3 auf Seite 13 "graph attributes")

Viel Spaß

[grizzly]

Zitat von Gruber_Hans_12345:

...allerdings macht das dot bei den pfeilen ein paar fehler, (sieht zumindest so aus) da gibts ein paar pfeile ohne linien ...

Da muß ich dot.exe jetzt in Schutz nehmen. Die angezeigte Grafik wird ja gar nicht von Dot.exe gezeichnet. Das mache ich innerhalb UnitUsage ja selber. Vermutlich ist das das Problem. Man könnte sich natürlich in DotGlob.pas beim Aufruf von Dot (In Prozedur RunDot, ca. Zeile 567) auch gleich eine Vektorgrafik mit ausgeben lassen (z.B. mit -Tsvg), dann sähe man ja, wo der Hund begraben ist.

Gruß
Michael

[Gruber_Hans_12345]

das meine ich mit falschen pfeilchen, (ist als WMF exportiert und im coreldraw dann vergrößert)

im unitusage kann man nicht so stark vergrößern, nachdem es 1GB RAM verbraten hat, kommt dann out of system ressource (obwohl, der rechner hätte noch ein paar reserven .... )

[grizzly]

So hatte ich das ja auch verstanden.

Was ich meinte war: Wenn dot.exe das Bild selbst gemalt hätte, dann wären die Pfeile vermutlich richtig gewesen. Dot.exe kann ja auch Bilder und Vektorgrafiken ausgeben. Das nutze ich in UnitUsage aber nicht. Ich rufe dot.exe mit dem Parameter Tplain-ext auf und erhalte damit eine Datei mit Informationen, wie ich das Bildchen zu zeichnen habe. Die Angaben zu den Pfeilen bestehen aus einer Liste von Punkten, die sich glücklicherweise mit dem Befehl Canvas.PolyBezier(...) identisch zu den von DOT selbst erzeugten Bildern zeichnen lassen. Den Kopf der Pfeilchen muß ich mir aber selbst errechnen (TDot.CalcArrowEdges). Vielleicht hab' ich da ja noch irgendwo einen Fehler. Kann natürlich sein, daß es durchaus auch schon von DOT falsch berechnet wird. In der Regel bin aber immer ich schuld.

Ein WMF Export in UnitUsage exportiert immer nur meine "Interpretation" der DOT Grafik. Eine unangetastete, original unverfälschte DOT Grafik erhielte man eben über einen zusätzlichen Parameter (wie beispielsweise das erwähnte -Tsvg).

1GB verbraten? Nicht schlecht. Vielleicht sollte ich wenigstens von pf24bit auf pf8bit runterschrauben...

Gruß
Michael

[Gruber_Hans_12345]

hi grizzly,

wollte mal kurz nachfragen, ob du noch verbesserungen brauchst ...

hab noch eines beim RTF export
DelDirective.pas / 891

Delphi-Quellcode:

        FUNCTION ProcessInclude(FileName: string): integer;
        { Handles recursive procedure call to process an include file }
        BEGIN
          Result := -1;
          if ExtractFileExt(FileName) = '' then
            ChangeFileExt(FileName, '.pas');
          FileName := FileSearch(FileName, SearchPath);
          IF FileName = '' then
            EXIT;
          Result := RemoveDeadCodeEx(FileName, SourceFileName, Row, SLOriginal, SLProcessed, [b]SLSourceRTF[/b], SLRoutines, ParseAction, SearchPath, DefList, ErrMsg); << SLSourceRTF
        END; {ProcessInclude}

und hab auch noch (zwar ein etwas Quick and Dirty reingebaut (aber habs auf die schnelle gebraucht und funkt auch) das er bei den uses im projekt Source file die in erkennt und das richtige file lädt (beim alten hat er IMMER im Search Pfad gesucht) .. sind aber ein paar kleinere Änderungen an verschiedene Stellen ...

[grizzly]

Aber immer gerne!
Das mit dem IN war eines der nächsten Dinge, die ich eigentlich anpacken wollte, allerdings haben mich wieder tausend andere Dinge aufgehalten. Auch gut, wenn's schon fertig ist. Das mit dem Quick-und-Dirty ist bei meinem restlichen Code schließlich auch kein Problem.
Bei nächster Gelegenheit werde ich Deine Änderungen und Erweiterungen mit einbauen.
In knapp zwei Wochen sollte ich dafür mal wieder Luft haben...

Grüße
Michael

[grizzly]

Habe soeben die Version 0.6 im ersten Eintrag dieses Threads verlinkt. Update war nötig, weil das alte UnitUsage mit den neuesten DOT Versionen nicht mehr zurecht kam.
Die von Gruber_Hans_12345 vorgeschlagenen Änderungen sind allerdings noch nicht drin (Ich hab' das Tool bis vor kurzem nicht mehr benötigt und deshalb nicht mehr dran rumgeschraubt.)
Sourcecode ist auch nicht aufgeräumt, umstrukturiert oder sonstwie überarbeitet. Ist halt "as is", entstanden aus einer Experimentier-Laune heraus


Gruß
Michael

[himitsu]

Das mit dem IN hab ich auch grad gemerkt, als einige Dateien nicht geladen wurden

Und dann gab's noch andere Probleme:

Zitat:

Demo_Tree.dpr parsed.
himXMLi.pas parsing error: " himXMLi.pas Line 18: Unknown compiler directive REGION
himXMLi.pas Line 18: Unexpected end of file in comment started on line 19"
himXML.pas parsing error: " himXML.pas Line 18: Unknown compiler directive REGION
himXML.pas Line 18: Unexpected end of file in comment started on line 19"
Demo_TreeU.pas parsed.
Time: 0,0sec.
Error parsing 2 file(s). No "child" units will be displayed for these units.

und ich rechne mal Stark, daß dieses $REGION nocht das kleinste Problem sein wird.

Ich weiß, meine Units sind ein Kraus für derartige Verarbeitungen.

Die vordefinierten Compilerschalter gehen nur bis D7 und es wäre kein Problem die Fehlenden selber anzugeben oder eben noch nachzurüsten, nur leider gibt es ja größere Problemchen.



Eigentlich wollte ich nur mal sehen, in wie weit sich etwas anderes Nachrüsten läßt...

Auf den Delphi-Tagen kam unter Anderem die Frage wieder auf,
nach einer "optimaleren" Unit-Reinfolge, damit das Projekt eventuell schneller kompiliert werden würde.
Und da dacht ich mir, warum nicht gleich einen "feritgen" Parser ausnutzen, bzw. es gleich hier mit einbauen und nur noch das Ergebnis durchzugehn.


Na gut, da der Aufwand nun größer werden dürfte, werd' ich das erstmal rausschieben und andere Dinge fertigmachen.

Als Test hatte ich himXML > demos > Demo_Tree.dpr verwendet, falls es wen interessiert.



[add]
was ich mich grad fragte: Man kann doch in die IDE irgendwie Zusatzmodule integrieren und daraus auf die "aktiven" Dokumente zugreifen.
Gäbe es da eine Möglichkeit direkt den delphieigenen Parser zu nutzen und darüber direkt die Units abzufragen?

[grizzly]

Richtig, wenn man REGION und ENDREGION nachrüstet (Unit DelDirective.pas, SkipMinorCompilerDirectives), dann ist man nicht viel weiter: Des Pudels Kern ist {$IF . Da müßte ich beginnen, den folgenden Bedingungen auszuwerten und abzuprüfen etc. Das war mir dann doch zuviel (und bei meinen Projekten benötige es (noch) nicht.). Mein Ansatz des "Parsens" war derart primitiv, daß sich diese Auswertung nicht bequem drauf aufsetzen läßt.

Sorry
Michael

[add] Dafür den Delphi-eigenen Parser nehmen zu können wär ein Traum. Aber davon versteh' ich leider noch weniger...

[omata]

klick