wiki:Meetings/Meet-2011-01-26

KIELER-Meeting 26.1.11

Reviewtermine (uru)

  • Designreview 31.1., 15:00, R1114/1115 - evt. 17:00, cmot klaert mit ctr
  • Codereview 7.2., 15:00, R1114/1115

Wer macht was?

  • haf: implementiert Kombinationen für View Management
  • cmot: bereitet KAOM-Poster für Ptolemy-Miniconference vor; adaptiert Code von jes
  • cds: befasst sich mit automatischer Auswertung von Qualität des Autolayouts
  • chsch: ist in Endphase der DA
  • jes: hat Syntax/Semantik? von Ausführung der Statemachines in Maude-Interpreter überarbeitet
  • msp: Verbesserungen an KIML, auch Auswahl von Algorithmen ("wird besser als IBM")
  • hdw: Arbeitet weiter an Gleiseditor, hat Kontext-Button implementiert. Wird sich hierzu fortlaufend mit jjc abstimmen, msp wird dies koordinieren
  • uru: Aufschreiben + fertig implementieren
  • mri: Anbindung von OGDF
  • soh: Farbiges Anzeigen von Hierarchien in Graphiti
  • pkl: Verbesserung von KEX; hat Kategorien um Unterkategorien erweitert; will zum nächsten Release (Anfang des nächsten Semesters) eine release-fähige Version fertig haben
  • ckru: Siehe unten

Demo Erweiterung von KAOD zu Ptolemy-Optik (ckru)

  • Ptolemy hat Rundungen in Kantenzügen.
  • Problem: GEF macht Rundungen derzeit nur für rectilinear Layout, welches sein eigenes Routing macht. D.h., eigentlich wird orthogonal Layout erwartet, welches derzeit aber nicht ausimplementiert ist. Sauberste Lösung:
    • Splineconnection um Darstellung von Rundungen erweitern (per Viertelkreise oder Rundungen - Effizienz berücksichtigen!)
    • Splineconnection in KAOM-Editor einbauen und an KARMA anbinden
    • msp: Umsetzung für Graphiti aber wichtiger?
  • Vorgehen: GMF abrunden; dann sehen, wie KARMA-Konzepte in Graphiti übertragen werden können
  • Zusandsdiagramme sind umgesetzt, aber Labels sind unterhalb der Zustände, nicht - wie sonst üblich - innerhalb
    • haf: könnte 2 Labels vorsehen (innerhalb + außerhalb)
  • Benötigt die Fähigkeit, Labels zu verstecken, auch für z.B. atomare Actoren. Das muss dann auch vom Layout berücksichtig werden.
  • Noch fehlend: Übersetzung der "komischen" Statemaschinenstruktur von Ptolemy in "vernünftige" Struktur. Hierfür gibt es bereits ein Ticket.
  • Problem: ungenaue Anbindungen der Kanten über Hierarchieebenen (#1412)
    • Vorschlag: wieder Anzeigen von Originallayout ermöglichen
  • Kommentare: erfordern derzeit "Reinitialize and save kaod diagram from model" (#1413)
  • Derzeit gibt es Menüeinträge "Generate SC/SJ-Code (new)" (#1414)
    • statt "new" eine inhaltliche Beschreibung, z.B. "via S"
    • Visibility Expression für diese Menüeinträge erstellen (auch z.B. für "Generate Esterel")
    • rvh: es ist wichtig, Menüeinträge etc. zu managen und überschaubar zu halten ("kein 50.000 Balkone")
  • Thema Kommentarlayout: Kommentare sollen beim Import Modellelementen zugeordnet werden
    • rvh: Es wäre toll, wenn eine erste Version hiervon vor dem nächsten Berkeley-Besuch von cmot (ab 14.2.) geschehen könnte.

Vortag (cds)

  • Folie 9: Was beeinflusst das Layout positiv/negativ?
    • Seitenverhaeltnis (Anzahl der Layer)
      • Bei breiten Modellen evtl mit Blocklayouter nicht nebeneinander sondern untereinander anordnen
      • Unabhaening vom Layouter fuer verbundene Objekte
      • Keine Aenderungen/Abhaenigkeiten? an Layouter
      • Beispiel: Ptolemy/KGraph-Anbindung (haf)
      • Bestimmte weitere Einschraenunkgen: Prioritaeten, Start oben links oder unten rechts
    • Portnamen, die nicht unbedingt notwendig sind
    • Anzahl der Kreuzungen
    • Anzahl der Knicke
    • Differenzieren Kanten/Boxen? (Darstellung)
  • Folie 10: Manuelle Korrekturen
    • Portanordnungen
    • Kreuzungen minimiert
  • Hierarchisches Layout
    • Bisher: Von innen nach aussen
    • Vorschlag: Hilfslayouter fuer unverbundene Teile (vermutlich erst nach dem eigentlichen Layouter)
      • Verschiedene Strategien fuer verschiedene Ebenen
    • Konzept fuer allgemeines hiearchisches Layout, z.B. mit Beruecksichtigung von Interleveltransitionen
  • Vorstellung von (relativen) Metriken
    • Relativ zu verschiedenen Algorithmen und nicht verschiedenen Diagrammen
    • vs. absolute Metriken (Kontext ist ein einziger Algorithmus)
    • Vergleich von bestimmten Layouts (bdu) vs. Vergleich von bestimmten Layouter (cds)
      • Einschraenkung auf Datenflussdiagramme (cds)
      • Vergleich von Layouter ueber Vergleich von Layouts
    • Normierung auf fixe Modelleigenschaften (rvh)
      • Metriken finden die relativ vergleichbar sind bygl Modellen z.B. unterschiedlicher Groesse
    • Metriken/Aesthetikkriterien? aus Standardliteratur
      • Diplomarbeit von Jonas V. (jvo)
      • Helen C. Purchase
      • Mit Björn (bdu) austauschen
    • Gewisse Redundanz in Metriken ist ok
    • White space ist eine wichtige Metrik (Gewichtung?)
    • Node orthogonality (bdu)
  • Fragen:
    • Sind Trendlinien ausreichend?
    • Moechte man Extremfaelle vermeiden? (Varianzminimierung)
    • Bendpoint-Metriken aufteilen in zwei verschiedene? (fuer vorwaerts und rueckwaerts gerichtete Kanten)
    • Future Work von Diplomarbeit (msp)
    • Evtl. auch variable Flussrichtung (vs. Datenfluss-Standardflussrichtung)