Laden...

EBCs 2.0, deren Nähe zur prozeduralen Programmierung und deren Nutzen [inkl. Metadiskussion]

Erstellt von herbivore vor 13 Jahren Letzter Beitrag vor 13 Jahren 20.425 Views
71 Beiträge seit 2010
vor 13 Jahren

Einfach die Kommentare zu meinem Blogbeitrag beobachten. Auch hier gilt ja DRY 😃 Informationen nicht unnötig verdoppeln.

U
282 Beiträge seit 2008
vor 13 Jahren

@Uwe81: Logische Abhängigkeiten gehen mit EBC natürlich nicht einfach so weg. Darüber müssen wir hier also nicht diskutieren.

Es ist nur die Frage, ob diese unmittelbar sichtbar sind (bei einem Interface, dass ich verwende, sind sie das), bei einzelnen Methoden nicht.

Ich spinne jetzt mal rum: Wenn ich mir mein PC anschaue, sind da außen sehr viele Signale mit starken logischen Abhängigkeiten. Ist aber nicht schlimm, denn wenn ich den Monitor anschließe muss ich nicht jedes einzelne Signal verbinden, sondern ich verbinde den ganzen Stecker.

Das würde ich mir bei EBC auch wünschen (ohne dass ich eine Ahnung habe, wie das implementiert wird): Das eine Komponente eben nach außen nicht die einzelnen Methoden bereitstellt, sondern ganze Bündel von Signalen. Die die Platine dann auch als Bündel verbinden kann.

Dann muss die Platine weniger über Abhängigkeiten der Komponenten wissen und ist auch deutlich einfacher. Außerdem wären eben zusammengehörige und unmittelbar abhängige Signale auch logisch zusammengefasst.

Das die Platine einzelne Singnale verbinden muss entspricht irgendwie Methodenaufrufe, die X primitive Datentypen bekommen. Structs oder gar Objekte machen das ganze aber viel übersichtlicher.

71 Beiträge seit 2010
vor 13 Jahren

Bündel von Signalen könnten als Interfaces realisiert werden.

Von logischen Abhängigkeiten befreit das aber nicht. Die steckt ja nicht in der Kombination von Drähten zu Drahtbündeln/Steckern, sondern in den Signalen. Ein Monitor erwartet nicht nur einen Stecker einer bestimmten Form mit n Pins, sondern dass darin Signale mit Spannung/Strom fließen, wie gewünscht, und die Codierung eine bestimmte ist.

Die Analogie sollte also auch nicht zu weit getrieben werden.

Natürlich kann man ein EBC-Bauteil mit einem Interface versehen und so komplett irgendwo anstecken. Aber dann sind wir wieder bei IBC. Wer das machen will, kann es gern tun. Ich sehe darin keinen Vorteil. Bzw. damit verliere ich, was mit EBC geben: topologische Unabhängigkeit.

U
282 Beiträge seit 2008
vor 13 Jahren

Natürlich kann man ein EBC-Bauteil mit einem Interface versehen und so komplett irgendwo anstecken. Aber dann sind wir wieder bei IBC.

Nein, das hast du mich glaube ich falsch verstanden.

Meine Idee (wie gesagt, evtl. derzeit mit C# nicht möglich):
Angenommen, es gibt zwei Komponenten, die kommunizerien.

Comp1 {
    Out_MessageA;
    In_MessageB;
}

Comp2 {
    Out_MessageB;
    In_MessageA;
}

Die Nachrichten hängen stark voneinander ab.

Dann muss das Board derzeit beide Drähte einzeln verbinden. Ich will aber Das ganze Bündel als ein Nachrichtensystem sehen.

Also eine Sammlung von Signalen

MySignalBus{
    Out_MessageA;
    In_MessageB;
}

Und Komponenten
Comp1{
    +SignalBus;
}


Comp2{
    -SignalBus;
}

(wobei bei -SignalBus eben Out und In invertiert sind).

verbunden sind die Komponenten dennoch über das Board, aber das muss nur noch die Busse ineinanderstecken, nicht mehr die eizelnen Leitungen.

Bei IBC hingegen müsse Comp1 die Comp2 kennen (oder umgekehrt). Das entfällt bei meiner Idee.

71 Beiträge seit 2010
vor 13 Jahren

In diesem Repo findest du einen kleinen Bus für EBC: http://ebclang.codeplex.com, Verzeichnis MiniBus

Bei dem werden allerdings auch einzelne Pins verdrahtet. Find ich aber nicht schlimm. Verdrahten von ganzen Interfaces hab ich nicht als nützlich erlebt. Kannste ja aber gern versuchen.

M
153 Beiträge seit 2010
vor 13 Jahren

Hallo ralfw,

also ich empfinde EBC (2.0) als eine interessante Möglichkeit, Beziehungsgeflechte flexibler und unabhängiger zu gestalten, als dies bisher möglich und üblich ist.

Dennoch zögere ich noch, vor allem aus praktischen Erwägungen heraus. Es stellen sich mir noch einige Fragen, die, vor allem, den Produktionsalltag betreffen:*Wie groß gestaltet sich der Einarbeitungsaufwand für die Entwickler? *Was ist zu standardisieren und in welchem Umfang? *Welche Auswirkungen ergeben sich für die Tests, von den Unittests bis zu den Akzeptanztests, von der Testfallplanung bis zur (automatisierten) Testdurchführung *In welcher Weise ist das Deployment betroffen, im Hinblick auf die Granularität der Anwendung (also deploybare Einheiten) und im Hinblick auf die etablierten Continous-Delivery-Prozesse, die bereits automatisiert sind *...

Gibt es denn eine Implementierung die du empfehlen kannst und die sich so als Lehrstück und Spielwiese eignet (und deren Quellen natürlich offen sind)?

71 Beiträge seit 2010
vor 13 Jahren

ad Einarbeitungsaufwand: Den kannst du nur selbst für dich herausfinden. Einfach machen.

ad Standardisierung: Ein Schritt nach dem anderen. Erstmal damit arbeiten, Erfahrung in die Community einbringen.

ad Testauswirkungen: Eine Auswirkung ist ganz klar: Kein Mock-Framework mehr nötig. Alles andere bleibt im Grunde beim Alten. Warum auch nicht?

ad Deployment: Warum sollte sich daran was ändern? Auch die Einteilung des Codes in Assemblies hat mit EBC nichts zu tun.

Ich empfehle, die Texte, die online stehen, zu EBC zu lesen. Da sind ne Menge Beispiele. Und wenn du selbst was machst, publiziere es.

2.760 Beiträge seit 2006
vor 13 Jahren

@zommi: Guter Beitrag!

Aber vielleicht will Ralf etwas völlig anderes mit seinen EBC - nur ist mir das dann noch etwas unklar.

Das ist es mir momentan auch noch.

Ich habe noch keinen wirklichen konzeptionellen Unterschied (außer durch die Verwendung anderer technischer Mittel zur Implementierung also: .Net, Delegates, Events etc.) z.B. zu LabVIEW, einigen ausgefeilten Workflow-Engines etc. entdecken können (das Buch "Flow Based Programming" habe ich nicht gelesen).

An dieser Stelle nur soviel: Imperative Programmierung ist eben nicht (!) das Thema von EBC. EBC-Diagramme sollen keine Flowcharts sein. Das ist ja der Trick. Wer beim Modellieren mit EBC an Schleifen und Fallunterscheidungen denkt, ist schon zu tief in der Abstraktion abgestiegen. Damit haben EBC nichts zu tun.

Eines meiner großen ? ist es eben auf welchem Abstraktionsniveau ich EBCs einsetzen sollte. Ich finde solche Ansätzen nämlich in der Regel sehr reizvoll aber nur auf einem Niveau in dem ich möglichst Blackbox-artig Services miteinander "verdrahte" und Nachrichten (in welchem Format auch immer) zwischen den Services austausche.

Der Übergang zwischen Komponenten und Services (brauche ich einen Service auf einer höheren Ebene öfter so wird er dort zur Komponente) ist doch ohnehin fließend je nach dem auf welche Abstraktionsebene man geht. Ob ich jetzt auf einer "Platine" verdrahte oder auf einer "Zeichenfläche" ist unerheblich. Ob mein Graph (was es ja letztendlich ist) interpretiert wird oder erst kompiliert ist auch unerheblich für das Konzept.

Niedrigere Abstraktionen einen solchen Konzepts habe ich bei meinem alten Arbeitgeber schon erlebt und das ist trotz der Unterstützung ausgefeilter grafischer Editoren, in Bezug auf die geplanten Aufwände oft in die Hose gegangen. Deswegen stehe ich EBCs auch etwas kritischer gegenüber.

Die Frage lautet meinerseits also: Welche Arten von Komponenten/Tätern soll ich bauen?
Überspitzt formuliert (allerdings habe ich es bis zu dieser Ebene auch schon erlebt) soll ich eine Komponente mit den Eingangspins "Wert1", "Wert2", "Wert3", ..., "Rechenart" und dem Ausgang "Ergebnis" bauen oder sollte ich mich eher auf dem Level von "Kunde" -> "Kreditantrag" -> "Genehmigung einholen" -> "Kredit vergeben/Kredit ablehnen" bewegen?

Das erste Extrem bewegt sich meiner Ansichtsweise nach schon nah an der prozeduralen Programmierung das letzte ist mit prozeduraler Programmierung nicht zu vergleichen da ein Prozess abgebildet wird (Eine Fallunterscheidung ist da allerdings trotzdem drin).

Fast alles einschließlich und zwischen den beiden genannten Extremen lässt sich gut mit einer breiten Palette an Tools abwickeln (von BizTalk über die WF und vielen anderen proprietären Workflow-Engines bis hin zur Programmierung von Hand auf konventionellem Wege oder evtl. auch EBCs quer durch alle Abstraktionsebenen der funktionalität). Nur ein Problem gibt es bei allen Varianten (dazu zitiere ich einfach mal Wikipedia):

Das Interface der Komponente ist eine verbindliche Schnittstelle (Interface) zum Rest der Software. Die Schnittstelle kann daher mit einem Vertrag zwischen der Komponente und dem Rest der Software verglichen werden.
Durch die explizite Definition der Kontextabhängigkeiten wird deutlich, wie unabhängig eine Komponente tatsächlich von ihrer Umgebung ist.

Womit wir wieder bei der Frage des Abstraktionsgrades wären.

Eine etwas größere Beispielanwendung wie z.B. die von Rainbirds .NET Applikationsserver wäre schön damit man besser erkennen kann wo und wann EBCs eingesetzt werden. Eine solche Anwendung rein mit EBCs implementiert kann ich mir nämlich nicht vorstellen.

Du bist zwar nicht in der Pflicht eine solche Beispielanwendung zu erstellen aber sie würde die Akzeptanz der EBCs wahrscheinlich erhöhen und die Einstiegshürde niedriger setzen was ja eigentlich nur in deinem Interesse sein kann. Evtl. kommt bei deinem Wettbewerb etwas ähnliches raus und nimmt mir eine Hürde mir EBCs in der Praxis mal genau anzusehen.

71 Beiträge seit 2010
vor 13 Jahren

Eines meiner großen ? ist es eben auf welchem Abstraktionsniveau ich EBCs einsetzen soll

Warum darüber grübeln? Setze EBC dort ein, wo sie dir nützen. Ich tue das von der Ebene der Bounded Contexts bis runter zu Methoden. EBC (oder Flows) sind zunächst mal ein Modell, eine Art zu denken.

Du fragst ja auch nicht, auf welcher Ebene du mit dem "Objektdenken" anfangen sollst. Die Welt modelliert mit "Objekten" auf der Ebene verteilter Funktionalität (sonst gäbe es kein RPC, keine Webservices und auch kein WCF in der Form, wie es vordringlich verwendet wird) und auf der niedrigen Ebene von Datenklassen.

Dieselbe Freiheit kannst du dir mit EBC nehmen.

Die Frage lautet meinerseits also: Welche Arten von Komponenten/Tätern soll ich bauen?
Überspitzt formuliert (allerdings habe ich es bis zu dieser Ebene auch schon erlebt) soll ich eine Komponente mit den Eingangspins "Wert1", "Wert2", "Wert3", ..., "Rechenart" und dem Ausgang "Ergebnis" bauen oder sollte ich mich eher auf dem Level von "Kunde" -> "Kreditantrag" -> "Genehmigung einholen" -> "Kredit vergeben/Kredit ablehnen" bewegen?

Datenfluss bedeutet nicht Wert1, 2, 3 setzen. (Genausowenig wie verteilte Funktionalität bedeutet, Properties auf entfernten Objekten zu setzen.) Ich weiß nicht, woher der Gedanke kommt. Dazu gibt es kein einziges Beispiel. Und nicht nur bei EBC nicht, sondern überhaupt bei allem, was mit Flows zu tun hat nicht. Liest denn das keiner?

Deinen Verweis auf Wikipedia verstehe ich nicht. Interfaces sind für EBC zunächst mal irrelevant.

Wenn alle nur warten, dass irgendwer eine größere Anwendung baut, bevor sie sich mit EBC beschäftigen... dann haben wir ein Henne-Ei-Problem. Aber ist halt immer so: free riding. Lass die anderen schaffen...

Aber egal. Wer über EBC diskutieren will, sollte sich hier tummeln: groups.google.com/event-based-components. Dort wird konstruktiv darüber nachgedacht.

3.728 Beiträge seit 2005
vor 13 Jahren
EBCs in der Praxis

Das ist es mir momentan auch noch.

Es ist momentan noch sehr viel Bewegung im ganzen EBC-Konzept. Das macht es schwierig, den Überblick zu behalten. Auch die Tatsache, dass dauernd neue Entwurfsaspekte, Pattern und Varianten hinzukommen, kann etwas verwirrend sein.

Ich habe noch keinen wirklichen konzeptionellen Unterschied (außer durch die Verwendung anderer technischer Mittel zur Implementierung also: .Net, Delegates, Events etc.) z.B. zu LabVIEW, einigen ausgefeilten Workflow-Engines etc. entdecken können

Verringerung von Abhängigkeiten zwischen Komponenten durch den Einsatz von Delegaten und ausgelagerter Verdrahtung. Das würde ich als den Kern des Konzepts bezeichnen. Simpel aber genial.

Eines meiner großen ? ist es eben auf welchem Abstraktionsniveau ich EBCs einsetzen sollte.

Mir geht es genauso.

Der Übergang zwischen Komponenten und Services (brauche ich einen Service auf einer höheren Ebene öfter so wird er dort zur Komponente) ist doch ohnehin fließend je nach dem auf welche Abstraktionsebene man geht.

Service und Komponente ist in meinen Augen dasselbe. Ein Stück Software mit einer klar definierten Schnittstelle, welche so autonom wie möglich ist.

Die Frage lautet meinerseits also: Welche Arten von Komponenten/Tätern soll ich bauen?
... soll ich eine Komponente mit den Eingangspins "Wert1", "Wert2", "Wert3", ..., "Rechenart" und dem Ausgang "Ergebnis" bauen ...

Würde ich eher nicht tun. Zu filigran, zu fitzelig. Da schreibst Du am Ende mehr Verdrahtungscode, als Geschäftslogik.

... oder sollte ich mich eher auf dem Level von "Kunde" -> "Kreditantrag" -> "Genehmigung einholen" -> "Kredit vergeben/Kredit ablehnen" bewegen?

Das hört sich - finde ich - viel besser an. Anforderungen lassen sich aber nicht unbedingt immer gleichmäßig in Codekonstrukte umsetzen. Ganz interessant ist in dem Zusammenhang folgender Blog-Beitrag: Das Domänobjektmodell anders gedacht [OOP 2010]
Es gibt allerdings gar nicht immer eine GUI!

Das Interface der Komponente ist eine verbindliche Schnittstelle (Interface) zum Rest der Software. Die Schnittstelle kann daher mit einem Vertrag zwischen der Komponente und dem Rest der Software verglichen werden.

EBCs hängen nur über ihre Pins zusammen. Was eine Schnittstelle für eine Klasse ist, das ist ein Delegat für eine Methode. Man hat also viele kleine Verträge, statt eines großen Vertrages. Auf Schnittstellen könnte man deshalb sogar komplett verzichten. Das Problem sind vielmehr die Nachrichtentypen, welche trotz ausgelagerter Verdrahtung gemeinsam genutzt werden. Dafür gibt es keine Lösung! Kommunikationspartner müssen die gleiche Sprache bzw. das gleiche Protokoll sprechen. Natürlich könnte man z.B. mit untypisierten DataTables arbeiten, aber da müssen die Komponenten auch die Spalten kennen bzw. richtig interpretieren.

Eine etwas größere Beispielanwendung wie z.B. die von Rainbirds
>
wäre schön damit man besser erkennen kann wo und wann EBCs eingesetzt werden. Eine solche Anwendung rein mit EBCs implementiert kann ich mir nämlich nicht vorstellen.

Ich bin dabei, sowas zu erstellen. Es soll eine kleine verteilte Mini CRM-Anwendung werden, die aus verteilten EBCs mit Zyan aufgebaut wird. 8)
Das wird auch für mich der ultimative EBC-Praxistest.

3.971 Beiträge seit 2006
vor 13 Jahren
EBCs in der Praxis...erstmal abgebrochen

rein informativ und ohne mich selbst mit dem Inhalt des Links zu
identifizieren:

EBCs in der Praxis...erstmal abgebrochen, Beitrag von Manuel Wenk

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...