Diagramme für EBCs (Event Based Components) zeichnen / eigenen EBC-Designer realisieren

Hallo zusammen,

Frage an alle die gerade mit EBCs experimentieren, oder diese vielleicht schon einsetzen: Wie zeichnet Ihr eure EBC-Schaltpläne?

und mit welcher Software?

Das beste (kostenlose) was ich bis jetzt gefunden habe ist OpenOffice Draw.

Hallo,

ich hab einige Programme probiert und bin bei LatexDraw hängen geblieben.
Dies v.a. da ich dann ein PDF-Präsentation erzeugen kann mit der ich durch die Ebenen zoomen (scrollen) kann.

Ausgabeformate: SVG, PNG, JPG, PsTricks-Code (LaTeX)

Ich hab auch schon überlegt ob mir nicht eine Software zum Ertellen von (elektrischen) Schaltplänen installieren soll. Kaufen würde ich mir keine, aber irgendwo hab ich noch eine Lizenz. Der Vorteil davon wäre automatisches Layout des Schaltplan.

Letzten Ende warte ich aber auf einen Designer der ähnlich Linq2Sql oder EF-Designer die Platinen erstellen lässt und so auch den Verdrahtungscode generiert. Leider habe ich überhaupt keine Zeit so einen selber zu schreiben - da verdrahte ich lieber händisch 😉

mfG Gü

Hallo gfoidl,

LatexDraw sieht vielversprechend aus.
Danke für den Tipp.

Gruß

Rainbird

Was bedeutet "ein PDF-Präsentation erzeugen kann mit der ich durch die Ebenen zoomen (scrollen) kann."?

Ich male mit Visio oder freihand mit einem Wacom Tablet und ArtRage.

Eine Design-SW für Elektronik würd ich mir nicht installieren. Da ist zuviel Rauschen drin.

Was am Ende nur hilft, ist eine SW, mit der man eben EBC-Schaltpläne zeichnen kann und die dann auch noch Code erzeugt. Gestern sagte jmd nach meinem EBC-Vortrag auf der MS Austria Architekturkonferenz, man könne ein Plugin für Sparx Enterprise Architect recht leicht basteln. Tja... wenn das stimmt...

Ansonsten kann ich noch österreichischen Interessenten anbieten, dass sie einen FFG Fördergeldantrag stellen. Dann gibt es einen Scheck in Höhe von 5000 EUR (sehr problemlos) und mit dem kann man von der TU Wien mal sowas angehen lassen. Wer mehr dazu wissen will, melde sich bei mir. Denn wenn das "Designer-Problem" genügend klein gehackt wird, dann ist mit mehreren 5000 EUR Happen in jedem Fall was zu erreichen, z.B. ein Designer, der ein XML-File erzeugt, und getrennt davon ein Codegenerator, der aus dem XML Assemblies etc. macht.

EDIT (12.10.2010):

Ich kann empfehlen:

• Papier und Stift (und Digicam)
• Whiteboard (und Digicam)
• Visio
• http://www.tactilisapp.com/ für den iPad
• http://www.artrage.com/ für den PC

Hallo Ralf,

Was bedeutet "ein PDF-Präsentation erzeugen kann mit der ich durch die Ebenen zoomen (scrollen) kann."?

Ich finde es toll dass ich so wie im angehängten PDF (Auszug aus dem gesamten Schaltplan) durch die Ebenen zoomen kann indem ich mit dem Mausrad scrolle.
Das ist sehr angelehnt an die Bilder in deinen Blog-Beiträgen nur halt alles "in place".

Das geht natürlich auch mit PowerPoint, OpenOffice Impress, etc. aber für mich sind PDF standard. Erzeugen tu ich die PDFs mit LaTeX (hier Beamer-Klasse).

Was am Ende nur hilft, ist eine SW, mit der man eben EBC-Schaltpläne zeichnen kann und die dann auch noch Code erzeugt.

Letzen Endes sollte das dass Ziel sein. Solang jedoch das "Alpha-Stadium" noch nicht wirklich verlassen ist (so sehe ich das*) kann noch händisch gearbeitet werden. Erst wenn so genügend Erfahrung gesammelt ist kann diese gebündelt und in einen Designer gesteckt werden.

* zB da die Bezeichnung des Architekturstils, der Pins, etc. noch nicht final manifestiert ist

mfG Gü

Hi,
wir arbeiten gerade an einem Diagramm Editor mit Silverlight in unserer Freizeit: http://www.silverdiagram.net/.

Wäre eine nette Erweiterung für unser Tool, eventuell auch mit einer Portierung für WPF, in dem dann auch die Integration mit Visual Studio einfacher ist.

Allerdings sehe ich das wie gfoidl. Solange das noch experimentell ist, ist es schwierig, sowas umzusetzen, davor bedarf es noch einiger konzeptionellen Arbeiten was auch Notationen und Standardkomponenten (MessageBroker, Interceptor etc.) betrifft.

Ich würde mir dafür eine Standardisierung wie im Java Umfeld für Komponenten Aufbau und Integrationswerkzeugen wünschen, damit ich/wir in unserer Freizeit auch Zeit investieren können.

Ohne eine finanzielle Förderung können wir es uns im Moment leider zeitlich und finanziell nicht leisten, sowas zu bauen (leider sind wir nicht aus Österreich, sondern Deutschland und Spanien).

Ich finde das Thema aber sehr interessant, zumal wir selbst in unserer kleineren Anwendung sehr mit dem Thema Abhängigkeiten (zu viele und überhaupt) zu Kämpfen haben und z.B. der EventAggregator für Konzept der losen Kopplung nur sehr unzureichend ist.

Ganz grundsätzlich kann ich zwar verstehen, wenn man noch zögert, zuuuviel Zeit in deinen Designer zu stecken, der dann am Ende "nicht richtig" ist.

Aber auf der anderen Seite ist es so ganz unagil, eben nichts an einem Designer zu tun und auf eine "Aushärtung" der Theorie (oder Praxis ohne Designer) zu warten. Denn diese Haltung lässt außen vor, dass das schlichte Vorhandensein auch eines simplen Designers eine neue Erfahrung ist, die die Wünsche an einen Designer verändert. Und zwar so, wie es Theorie/Praxis ohne Designer nicht kann.

Wer also darauf wartet, dass das Konzept final wird, der kann lange warten. Und wer dann noch glaubt, dass dann ein Designer einfürallemal geschrieben werden kann und dass er keine großen Veränderungen mehr durchläuft, der liegt auch falsch.

Wer die Kompetenz zum Bau eines Designers hat, der sollte einfach was einfaches zusammenbasteln und mal zeigen. Es geht um ein erstes kleines Featureset, eine erste kurze Iteration.

Naja... werde wohl nicht umhin kommen, selbst was zu basteln 😉

Hi Ralf,
du hast absolut Recht, ich finde es auch sehr spannend mich in dieses neue Thema einzuarbeiten. Was ich in Kurzform sagen wollte ist, dass ich leider im Moment einfach zu sehr in mein anderes Projekt eingespannt bin, aber da sich diese beiden Projekte ja durchaus überschneiden ... vll. werde ich ja doch etwas Zeit finden.

Wer die Kompetenz zum Bau eines Designers hat, der sollte einfach was einfaches zusammenbasteln und mal zeigen. Es geht um ein erstes kleines Featureset, eine erste kurze Iteration.

Naja... werde wohl nicht umhin kommen, selbst was zu basteln 😉

Ich könnte mir vorstellen, dass man auch mit einem recht einfachen Editor recht weit kommt. Konkret denke ich da an eine Baumstruktur. Die enthält Platinen und Komponenten. Jedes Element lässt sich aufklappen und hat einen Unterknoten "Drähte". Darunter kann man die Drähte anlegen. Mit einer mehrspalten Baumansicht a la TreeViewAdv (http://sourceforge.net/project/screenshots.php?group_id=166562&ssid=37269) sollte das grundlegende Übersicht schaffen.

Ganz grob in ASCII-Art dargestellt:

[+] Komponente1
 |
 +---[+] Drähte
 |    |
 |    +--- {Out_Pin1} => {Komponente2.In_Pin2}
 |
 + ...

Sowas ist relativ schnell gemacht und spar Zeit beim verdrahten. Der Verdrahtungscode könnte direkt mit CodeDOM generiert werden.

Was meint ihr dazu, fürs Erste?

Hallo Rainbird,

die Schachtelung von EBCs ist natürlich ein Baum mit den Platinen als Knoten und den Basisbausteinen als Blättern. Aber die Verdrahtung wird sich m.E. im Allgemeinen nicht (sinnvoll) als Baum darstellen lassen. Ich denke, es sollte schon was grafisches sein.

herbivore

Mit wäre eine visuelle Präsentation der Beziehungen wichtiger als die Code Generierung, deshalb könnte ich mit einem Baum wenig anfangen.

Das sehe ich ähnlich, Rainbird. So einfach könnte es für den Anfang sein:

Editieren des Schaltplans in einer Baumstruktur, die gleichzeitig z.B. GraphViz visualisiert wird. Dann sieht man sofort, was man da verbricht.

Im Codeplex-Projekt habe ich einen XML-Entwurf, der eigentl deine Idee zeigt, nur eben in XML. Da gibt es auch nur Platinen und Drähte. Das reicht. Daraus lässt sich Code generieren oder eine Visualisierung.

So, ich konnte es doch nicht lassen und habe mal ein Grundgerüst mit Silverlight zusammengeklickt. Wenn jemand aus dem XML Entwurf von Ralf Code generieren kann, könnte ich auf Basis eines Diagrams eine Datei mit (noch) folgenden Abstrichen liefern:

(1) Es gibt nur eine Platine
(2) Noch kein Message Type (bzw. Standard wert)
(3) Input Pin von Komponente A heisst wie Output Pin von Komponente B (wenn A und B verknüpft sind), da man Namen nur über.
(4) Wahrscheinlich viele weiteren Dinge mehr 😄

EDIT: Link fehlte: http://silverdiagram.net/EBC/Editor.html

Na, das ist doch was 😃

(1) Es gibt nur eine Platine

Damit könnten wir einen Moment leben, glaub ich. Es ginge zunächst daraum, den "Workflow" auszuprobieren. Platine malen, Code generieren, Bauteile ausfleischen, Programm starten. Dann Platine verändern, Code neu generieren, Bauteile ergänzen usw. usw.

(2) Noch kein Message Type (bzw. Standard wert)

Das ist sicherlich eine Beschränkung. Nachrichtentypen müssen eingetragen werden können. Einfach nur als String. Bei der Generierung wird dann festgestellt, ob es die schon gibt. Wenn nein, dann wird dafür auch Quellcode angelegt, den man verändern kann. Eine Rumpfklasse reicht da. Aber das ist Codegenerierung. Hat nix mit dem Desigern zu tun.

(3) Input Pin von Komponente A heisst wie Output Pin von Komponente B (wenn A und B verknüpft sind), da man Namen nur über.

Bennung ist wohl nötig.

(4) Wahrscheinlich viele weiteren Dinge mehr 😄

Klar. Ne Menge 😃

Ich denke, eine Grundsätzliche Änderung müsste rein: eine Propertysheet. Dann kann man auf Elemente klicken (Komponente, Draht, Pin), um Eigenschaften zu editieren.

Komponente(Name)
Pin(Name, Typ)
Draht(Typ)

Typen können unidirektional sein oder bidirektional. Unidirektional bedeutet, es fließt nur eine Nachricht vom Sender zum Empfänger. (Pfeilspitze einzeichnen!)

Bidirektional bedeutet, es kommt auch wieder was vom Empfänger zurück.

Typen sind also Paare, z.B. string/- (unidirektional), string/int (bidirektional), -/int (bidirektional), Query/Customer[] (bidirektional)

Bin gespannt auf die nächste Iteration.

Danke für den Kommentar, dazu 2 Fragen:

(1) Weshalb brauchen Drähte Typen: Der Typ eines Drahtes wird doch durch den Input und Output Pin bestimmt, die natürlich zusammen passen müssen -> Validierung notwendig.

(2) Für die bidirektionale Datentypen brauch ich noch ne ausführlichere Erläuterung. Ich habe EBCs immer mit Fire & Forget in Verbinung gebracht (weshalb wir auch hier EBC: Validierung und Exception Handling eine zum Ende abschweifende Diskussion über Exception Handling geführt haben).

In mein aktuelles Bild passen birektionale Nachrichten überhaupt nicht rein.

Zum Drahttypen: eigentl hast du Recht, der Draht braucht keinen Typ. In der Praxis merke ich aber immer wieder, dass ich nicht Pins modelliere, sondern Drähte. Auch in deinem Desigern ist das so. Und da ists einfacher, dem Draht einen Typ zu geben.

Zur Bidirektionalität: Grundsätzlich stimmt es, dass die Nachrichten nur in eine Richtung fließen sollen. Aber für Request/Response Kommunikation will man schon etwas Bequemlichkeit. Da gibt man z.B. dem Request einen Antwortpin mit. Das kann ein Codegenerator autom. in einem speziellen Request-Typen vorsehen. Deshalb 2 Typen, falls Req/Resp Kommunikation.

Außerdem halte ich es für erlaubt, in lokalen sync Szenarien Pins als Func<,> zu formulieren.

Zum Drahttypen: eigentl hast du Recht, der Draht braucht keinen Typ. In der Praxis merke ich aber immer wieder, dass ich nicht Pins modelliere, sondern Drähte. Auch in deinem Desigern ist das so. Und da ists einfacher, dem Draht einen Typ zu geben.

Wenn ein Output Pin nur mit einem Input Pin verbunden ist, ist es auf jeden Fall einfacher. Dann braucht man nicht zu validieren ob der Typ der beiden Pins passt, benötigt allerdings einen Splitter, falls man ein Output Pin mit mehreren Input Pins verbinden möchte.

Sollen Output Pins auch mit mehreren Input Pins verbunden sein, muss man sich halt entscheiden:

(1) Typ über Draht definiert: Haben alle Drähte von einem Output Pin weg den selben Typ?

(2) Typ bei Pins: Haben Output und Input Pin eines Drahtes den selben Typ?

In meinem Designer ist es bisher so, weil es die schnellste Lösung für die erste kurze Iteration war. Da in der nächsten Version (siehe Screen) die Pins auch pflegbar sein sollen, spielt es keine Rolle mehr. Man muss sich halt nur entscheiden, bzw. man wird ja sehen, wie dann die typischen Abläufe in der Praxis sein werden. Ich denke ich entscheide mich mal für (1).

ich find "typ am draht" nicht schlimm. denn gespeichert werden sollen am ende im xml ja auch drähte. das bedeutet zwar erstmal nur 1:1 verbindungen zwischen pins. aber das macht nix.

in deinem bild scheint mir nur die komponente fixe in/out pins zu haben. das wäre schade. und ist ja auch unnötig, wenn der draht im fokus ist. dann braucht die komponente gar keine pins in der toolbox.

Nur ein Zwischenstand, Erstellen und Löschen von Pins kommt natürlich noch 😃

Hallo malignate,

der Designer sieht jetzt schon sehr vielversprechend aus. 👍

Das bringt dann doch deutlich mehr, als eine schnöde Baumansicht.

So, mal nen Zwischenstand hochgeladen: http://silverdiagram.net/EBC/Editor.html

das ist schon ziemlich cool! 😃

pins hinzufügen und löschen.
pins benennen.
datentypen auf draht festlegen.

pfeilrichtungen wollen sich aber noch nicht so recht zeigen.
und fehlerhaft durch doppelklick angelegte drähte konnte ich nicht löschen.

aber es ist ein schöner anfang.
auch dass das eine SL app ist, find ich gut.
VS integration ist nicht nötig.
am ende muss nur halt ein XML rauskommen.

Kommt, kommt...gibts denn auch schon Freiwillige, die sich gerne durch die tausend Klassen in CodeDOM wühlen oder Spaß an T4 haben?

Der Designer muss nur XML generieren. Wenn er das tut, dann ist alles gut 😉 Denn die Codeerzeugung mach ich dann schon.

Hier nochmal mein Vorschlag für ein minimales XML-Format.

Daraus kann ich Projektmappen, Projekte und Assemblies generieren. Hab ich sogar schonmal gemacht. War nur ein etwas anderes XML. Und war kein sauberer Code 😉

pfeilrichtungen wollen sich aber noch nicht so recht zeigen.

eigendlich braucht man das ja nciht, wenn man das bild betrachtet, dann sieht man das "in" pins immer links sind und "out" pins immer rechts. daher sieht man ja schon aufgrund dem verlauf der linien, wohin der weg geht.

"in" links, "out" rechts: das ist in den diagrammen nur zufällig so. pfeilrichtungen müssen also sein.

und es gibt zwei pfeile: unidirektional für kommandos, bidirektional für queries. bei queries muss aber auch sender und empfänger unterschieden werden können. also dürfen die pfeilspitzen nicht gleich aussehen.

"in" links, "out" rechts: das ist in den diagrammen nur zufällig so.

sollte aber nciht zufällig sein. das ist dann deutlich besser zu betrachten.

Ist auch nicht zufällig. Das ist schon so gedacht wie JAck30lena es auch bemerkt hat. Das merkt man wenn man eine Komponente Doppelklickt.

Pfeilspitzen sind kein Problem. Man muss nur validieren, ob die auch richtig gesetzt sind, das heißt von Out nach In, aber Validierung muss ja sowieso sein, z.B. ob die Benennung .NET Konform ist usw.

Hallo zusammen,

ich finde, dass ein ganz wesentlicher Aspekt im Zusammenhang grafischen EBC-Designern bisher vollkommen außer acht gelassen wurde.

Ich denke, die Vorstellung, dass man einfach einen grafischen Designer nimmt und Verbindungen zwischen Pins zieht, ist zu kurz gedacht. Denn immerhin sammeln sich in der Platine alle Abhängigkeiten, die man aus den Basisbausteinen verbannt hat. Der Platinenentwickler muss also die Kontrakte der Basisbausteine beim Verbinden berücksichtigen und einhalten. Aber wie das eben ist: Da passen Formate nicht, da passen Wertebereiche nicht, da werden Werte unterschiedlich interpretiert. Das alles muss umgesetzt werden. Und selbst wenn nur String MessageA.SourceText an String MessageB.SourceCode zugewiesen werden muss. Mit dem Ziehen einer Linie ist es da nicht getan.

Die Ein- und Ausgabepins werden also oft genug nicht direkt zusammenpassen. In solchen Fällen, ist das quasi eine "Impedanzanpassung" nötig (ich bin kein Elektrotechniker und ich weiß nicht, ob die Analogie in allen Aspekten stimmt, aber ich fand sie ganz passend).

Natürlich kann man sich auf den Standpunkt stellen, dass bei der elektrotechnischen Impedanzanpassung auch extra Bausteine nötig sind, um sie zu realisieren und die selbst Platine weiterhin nur aus dummen Leiterbahnen besteht. Bei EBCs könnte es also auch extra Impedanzwandler-Komponenten geben. Nur ist die konkrete Umsetzung ja immer von der Kombination aus Ausgabe- und Eingabenachricht abhängig. Da man das in meinen Augen nicht generisch hinbekommt(*), würde man unzählige, kleine Komponenten brauchen, die die Umsetzungen machen.

Wenn man mit dem Designer schon das Verdrahten automatisieren oder zumindest stark vereinfachen will, dann halte ich es für einen wesentlichen Punkt, auch eine Lösung für die Impedanzwandlung zu finden. Zum Beispiel könnte man das so realisieren, dass es möglich ist, auf einen Draht (doppel) zu klicken und dann ein Fenster aufgeht, in dem man direkt den Code für die Impedanzwandlung eingeben kann.

Wenn die Platine generiert wird, muss man den Code natürlich irgendwo unterbringen. Dafür sehe ich zwei Möglichkeiten. Entweder der Code wird bei der Verdrahtung in Form von Lambda-Ausdrücken direkt eingeklingt oder oder für jeden Code wird eine private Methode generiert und diese wird per Lambda-Ausdruck in die Verdrahtung eingebunden.

Gut, nun kann man sagen, dass es erstmal um einen ganz einfachen Designer geht. Sicher richtig. Dennoch wollte ich schon mal auf diesen Aspekt hinweisen, weil ich mir sicher bin, dass so ein Feature nötigt ist, bevor überhaupt daran zu denken ist, einen solchen Designer nicht nur für Übungsbeispiele einzusetzen.

herbivore

(*) Natürlich könnte man eine generische Standard-Mapping-Komponente schreiben, die nur noch mit dem individuellen Mapping-Code parametrisiert wird. Aber die würde so gut wie keine Arbeit abnehmen und man bräuchte immer noch eine weitere Komponente, die diesen Mapping-Code enthält. Man spart also nichts.

Ist auf jeden Fall ein wichtiger Punkt. Ich würde aber Standard Bausteine bevorzugen, die ich über eine partielle Methode dann in Visual Studio implementieren kann, z.B. in diesem Fall ein Message Translator oder Adapter oder wie man den dann auch immer nennen möchte.

Ich werde aber sobald ich Zeit habe (vorraussichtlich heute Abend) erstmal mit der XML Generierung weitermachen. Und sobald dann Ralfs Code Generator steht hat man schonmal eine Basis zum Testen.

Wenn das ganze weiterentwickelt wird, muss man ja eh schauen, wie man die Vorstellungen und Ideen sammelt und daraus ein richtiges Tool baut. Dann kommt natürlich auch noch das Thema Finanzierung hinzu.

Mir ist noch aufgefallen, dass noch Elemente für die Input und Output Pins des Mainboards benötigt werden. Hat jemand Vorschläge für Symbole?

Hallo malignate,

die gleichen wie für allem anderen EBCs.

Von innen weiß man, ob etwas eine Platine oder ein Basisbaustein ist, von außen nicht. Deshalb kann und sollte es einem ganz egal sein, ob die Pins zur einer Platine oder einem Basisbaustein gehören. Sie sollten überall gleich sein.

herbivore

Generell sehe ich das genauso, aber da wir ja in dem beschränkten Editor nur innerhalb einer Platine sind ist es vll. leichter das durch verschiedene Symbole unterscheidbarzu machen.

Allerdings kann man es ja uach durch die Verdrahtung unterscheiden.

Hallo malignate,

zeichne die Platine als Rahmen um alles, von Pins die auf dem Rahmen liegen, weiß man dann, dass sie zur Platine gehören.

Das hat auch den Vorteil, wenn man später mal wirklich rauszoomen kann, muss man nichts ändern.

herbivore

Ich habe jetzt die einfachste Varianet gewählt und einen Pfeil für Input und Kreis für Output verwendet. Das ist natürlich nur eine Prototyp Lösung.

Des Weiteren enthält die aktuelle Version nen simplen Exporter, es gibt aber keine Validierung (bzw. kein Output), das heisst damit ein Wire exportiert werden kann, müssen folgende Bedingungen erfüllt sein:

• Kompoinente braucht einen Namen
• Pins benötigen einen Namen
• Wires müssen von Output zu Input Pins gehen bzw. von Platinen Input zu Komponenten Input oder Platinen Ouput zu Komponenten Output
• Wires müssen einen Typ haben

@All:
Konnte schon jemand die neueste Version testen?

@Ralf:
Wann steht der Code Generator bereit? 😉

cool - da passiert jawas!

Mir fällt auf, dass die Drähte übereinander liegen können. So is natürlich unklar, was wo hin geht - siehe Bildchen.
Kann man nicht machen, wennich von A--->B ziehe, dass dann Pins generiert werden?
Datentypen findich klar über den Draht definiert - die Pin-Typen _müssen _dem folgen.
Überhaupt - alle Spezifikationen könnten im PropertyGrid des Drahtes editiert werden, also auch die Pins.
Mw. bleiben die Pins bestehen, wenn der Draht gelöscht wird - aber editieren reicht, wenn das nur am Draht möglich ist, weil ein pin ohne Draht ist ja sinnlos.
Wo ich noch für wäre, dass am selben Pin mehrere Drähte ansetzen können. Schließlich repräsentieren die Pins Events und Methoden, und Events können von mehreren Handlern abonniert werden, und Methoden können mehrere Events abonnieren.
IMO wären die Diagramme ohne RasterGitter leichter lesbar.
Und ich hätte türlich lieber eine Desktop-App, die bei Doppelklick auf Ebcml-Dateien (Ebc markup language 😉 ) diese öffnet und anzeigt.

Auch ist mir EBC als Konzept nicht ausdiskutiert genug. ZB. halte ich bidirektionalität nicht wirklich für erforderlich, stattdessen hätte ich gerne Getter-Pins (In und Out), deren Code je statt eines Parameters einen Rückgabewert hat, gugge diese Diskussion: EBC erweitern, um auf eine Anfrage einen direkten Rückgabewert zu bekommen?.
Einen Getter-Draht würde ich im Diagramm zB. mit umgedrehter Pfeilspitze kenntlich machen, also
Setter-Verdrahtung: A------>B
Getter-Verdrahtung: A------<B

Hmm - vlt. machichmich auch an ein Designer, mit olle WinForms, ma sehn 😉

Danke fürs Testen. Man muss dabei bedenken, dass das ein Prototyp ist.

Mir fällt auf, dass die Drähte übereinander liegen können. So is natürlich unklar, was wo hin geht - siehe Bildchen.

Ja, das sehe ich als das einzig richtige Problem an. Das hat man bei allen Diagram Designer im Normalfall. Da man in vielen Apps aber die einzelnen horizontalen Pfade verschieben kann, kann man sich dann seine Verbindung bessr hinlegen. Ist kein einfacher Task, wird aber irgendwann folgen.

Kann man nicht machen, wennich von A--->B ziehe, dass dann Pins generiert werden?
Datentypen findich klar über den Draht definiert - die Pin-Typen _müssen _dem folgen.
Überhaupt - alle Spezifikationen könnten im PropertyGrid des Drahtes editiert werden, also auch die Pins.
Mw. bleiben die Pins bestehen, wenn der Draht gelöscht wird - aber editieren reicht, wenn das nur am Draht möglich ist, weil ein pin ohne Draht ist ja sinnlos.
Wo ich noch für wäre, dass am selben Pin mehrere Drähte ansetzen können. Schließlich repräsentieren die Pins Events und Methoden, und Events können von mehreren Handlern abonniert werden, und Methoden können mehrere Events abonnieren.

Das meiste ist ja Geschmackssache. Wenn ich das so umsetzen würde, würde jemand anderes kommen und es komisch finden. Sprich, es ist nötig, so Dinge einstellen zu können.

IMO wären die Diagramme ohne RasterGitter leichter lesbar.

Vll, ich pack mal ne CheckBox in die nächste Iteration.

Und ich hätte türlich lieber eine Desktop-App, die bei Doppelklick auf Ebcml-Dateien (Ebc markup language 😉 ) diese öffnet und anzeigt.

Ich auch, aber wie gesagt: Prototyp.

Hmm - vlt. machichmich auch an ein Designer, mit olle WinForms, ma sehn 😉

Hau rein, aber such dir ne Bibliothek für Diagramme z.B. yFiles oder IBM ILOG, sonst bist du mit diesen Themen länger als mit der eigentlichen Anwendung beschäftigt.

Hallo,

Mir fällt auf, dass die Drähte übereinander liegen können. So is natürlich unklar, was wo hin geht - siehe Bildchen.

Wenn das in der Analogie zu elektrischen Schaltplänen betrachtet wird so ist das kein Problem.

Liegen die Linien nur übereinander sind sie immer nocht unabhängig. Ist im Schnittpunkt ein Punkt vorhanden dannn ist das eine Verbindung.

Das kann man hier auch so übernehmen.

mfG Gü

Es geht ja nicht um die Überschneidung zwischen Draht Out->In2 und Out->In1 sondern um Out->In1 und Out->In2.

Die liegen übereinander können aber unterschiedliche Datentypen haben. Zudem ist nicht ersichtlich ob die Verbindung von Out nach In1 geht oder von Out nach In2.

Das meiste ist ja Geschmackssache. Wenn ich das so umsetzen würde, würde jemand anderes kommen und es komisch finden. Sprich, es ist nötig, so Dinge einstellen zu können.

"Geschmacksache" kriege ich oft zu hören, wennich mit Ergonomie argumentiere. Ergonomie ist aber keine Geschmacksache, sondern eine ziemlich handfeste Kategorie, nach der man ein UI optimieren kann.
Man kann klar aufzeigen, was mehr oder weniger Arbeit in der Benutzung macht

Kann man nicht machen, wennich von A--->B ziehe, dass dann Pins generiert werden? es macht eindeutig weniger Arbeit, wenn ich durch einen Zieh-Vorgang 2 Pins und den Draht erzeugen kann, als wennich erst an der einen Komponente agieren muß, dann an der anderen, und dann erst den Draht ziehen kann.

Datentypen findich klar über den Draht definiert - die Pin-Typen _müssen _dem folgen.

es macht klar weniger Arbeit, wenn ich nur den Draht-Typen definieren muß, als die beiden Pin-Typen jeweils einzeln - und der Typ muß ja doch derselbe sein

Überhaupt - alle Spezifikationen könnten im PropertyGrid des Drahtes editiert werden, also auch die Pins. Klar weniger Arbeit, wenn ich nur ein PropertyGrid aufsuchen muß, anstatt 2 oder gar 3.

Wo ich noch für wäre, dass am selben Pin mehrere Drähte ansetzen können. Schließlich repräsentieren die Pins Events und Methoden, und Events können von mehreren Handlern abonniert werden, und Methoden können mehrere Events abonnieren.

Das ist jetzt keine Frage der Ergonomie, sondern eine Frage der Abbildung der Realität. Da Code-seitig ein Pin von mehreren Komponenten aus angesprochen werden kann (bei meinem FileBrowser-Sample ergibt sich das zB wie von selbst), muß der Designer das auch abbilden können.

Man muss dabei bedenken, dass das ein Prototyp ist.

Wohl war. Und ist natürlich deine App, und selbstverständlich machst dus so, wie dus für richtig hälst.
Ich meine meine Gesichtspunkte auch nur als Anregungen, habe deine Aufforderung zum Testen so verstanden, dass das erwünscht ist. Kommt wahrscheinlich fast wie Gemecker rüber, weil ich bin diplomatisch voll unterbelichtet. Also wenn ich herumzumeckern scheine, bedeutet das in erster Linie, dassich das Thema hochinteressant finde, und wert, dassich mir darüber nen Kopf mache. 👍

Hau rein, aber such dir ne Bibliothek für Diagramme z.B. yFiles oder IBM ILOG, sonst bist du mit diesen Themen länger als mit der eigentlichen Anwendung beschäftigt.

Hatte ich jetzt erstmal nicht dran gedacht, aber vlt. haste recht. Bin sonst immer mit selbstgezeichneten Sachen ganz gut klargekommen, aber immer nur Einzel-Aspekte, und beim Designer kommt doch einiges zusammen (schachtelbare Shapes, Adorner, Linien, Ankerpunkte...) mussich echt ma gucken, was eine Lib einem da abnehmen kann.

Hallo,

@ralfw

VS integration ist nicht nötig.

Aber wenn es doch so einfach geht...

Ich habe mal ein Screenshot angehängt, in dem man einen aller, aller, aller ersten Entwurf eines EBC Designers sieht. Das Ding ist mit dem VS2010 Modelling SDK gebastelt. Das ganze jetzt noch durch ein T4 Template gejagt und man hat ein fertiges XML in der gewünschten Form.

Sieht zwar noch nicht wirklich schön aus, aber VS bringt ein alles mit was man braucht (fast alles). Um das Zeichnen muss man sich absolut nicht kümmern. Man muss nur die Klassen bauen, die gezeichnet werden. Überaus einfach...

Wow, ich muss nicht neidlos anerkennen, das die Lösung cooler ist. Würdest du den Source Code veröffentlichen?

Dein Silverlight Editor finde ich aber auch sehr gut. Da ich mich gar nicht bis kein bisschen mit Silverlight/WPF auskenne, finde ich es sehr genial was du da gebaut hast. Respekt!

Würdest du den Source Code veröffentlichen?

Selbstverständlich mach ich das. Das was du da siehst ist allerdings momentan echt nur ein grober Entwurf. Dauert noch ein bisschen bis was vernünftiges bei raus kommt.

cool!
Da kannich mein WinForm-Ansatz wohl stecken lassen. Aber meine Ergonomie-Wunschliste ist natürlich dieselbe (unabhängig davon, ob die Sachen bei dir bereits drin sind).
Und kommt noch ein Wunsch dazu: nämlich Notizen machen. ZB beim Grob-Entwurf in EBC erweitern, um auf eine Anfrage einen direkten Rückgabewert zu bekommen? finde ichs sehr nützlich, dassich Komponenten-Features/Verantwortlichkeiten schon mal reinschreiben kann, v.a. wenn Features sich nicht in Drähten wiederspiegeln.
Ich will ja v.a. konzepteln mittm Platinen-Diagramm, und da sind die Stadien von Unfertigkeit eigentlich wichtiger als das Endergebnis, wo ich dann den Haken dranmach.

Aber auch im Endergebnis isses glaub nett, wenn Komponenten-Features schoma grob angerissen sind, ohne dass man reinzoomen muß.

Coole sache !

gibts dazu weitere news ?

Bin gerade über die Bitreactive Building Blocks gestolpert und dachte mir ich poste das hier einfach mal. Ist zwar Java aber schaut ziemlich vielversprechend aus.

Mal etwas mehr aus dem Context der bisher bestehenden Designer heraus,
hat jemand schon

EBC Designer

betrachtet?

[ist ein VSIX Installer Projekt]