|
|
 |
Allgemeine Diskussionen über BPM-Software.
|
 |
Clemens Ott
FBW I.T. Services GmbH
|
Kann Programmieren auf Basis von Flussdiagrammen Sinn machen?
|
21.07.2009 16:05
|
|
|
|
|
Clemens Ott
FBW I.T. Services GmbH
|
Re: Kann Programmieren auf Basis von Flussdiagrammen Sinn machen?
|
21.07.2009 16:07
|
|
Clemens Ott schrieb:
> Was wäre, wenn es ein Aktivitätsdiagramm gäbe, das in sich selbst
ablauforientiert und als Ganzes ergebnisorientiert mit logischen
Operatoren mit entsprechenden Schritten, Prozessvariablen bzw.
Prozessdaten ausgestattet werden kann? Und als Software-Funktion in
einem Compiler liefe und als solche präsentiert werden könnte?
Der Scope der Schritte wäre so gewählt, dass Programmieren kompletten Applikationen damit möglich
ist. Diese Schritte stellten die IT-Vokabel dar. Ein oder mehrere
solcher Diagramme könnten dann mit einem Geschäftsprozess-Schritt
graphisch verknüpft werden. Dieser Geschäftsprozess-Schritt wäre dann
ein Vokabel einer beliebigen Abteilung. Dies gäbe eine durchgehende,
diagrammbasierende Sprache in einer bruchfreien Umgebung. Von der Idee
über Geschäftsprozesse, zur prozessunterstützenden Applikation in einer
Umgebung mit einer Sprache. Wie klingt das?
|
Anton Kramm
valial solution GmbH
|
Re: Re: Kann Programmieren auf Basis von Flussdiagrammen Sinn machen?
|
21.07.2009 16:58
|
|
Hallo Hr. Ott,
klingt super und gibts schon. jCOM1 subjektorientiertes BPM.
Schöne Grüße
Anton Kramm
Clemens Ott schrieb:
>
> Clemens Ott schrieb:
> > Was wäre, wenn es ein Aktivitätsdiagramm gäbe, das in sich selbst
> ablauforientiert und als Ganzes ergebnisorientiert mit logischen
> Operatoren mit entsprechenden Schritten, Prozessvariablen bzw.
> Prozessdaten ausgestattet werden kann? Und als Software-Funktion in
> einem Compiler liefe und als solche präsentiert werden könnte?
> Der Scope der Schritte wäre so gewählt, dass Programmieren kompletten Applikationen damit möglich
> ist. Diese Schritte stellten die IT-Vokabel dar. Ein oder mehrere
> solcher Diagramme könnten dann mit einem Geschäftsprozess-Schritt
> graphisch verknüpft werden. Dieser Geschäftsprozess-Schritt wäre dann
> ein Vokabel einer beliebigen Abteilung. Dies gäbe eine durchgehende,
> diagrammbasierende Sprache in einer bruchfreien Umgebung. Von der Idee
> über Geschäftsprozesse, zur prozessunterstützenden Applikation in einer
> Umgebung mit einer Sprache. Wie klingt das?
|
|
Clemens Ott
FBW I.T. Services GmbH
|
Re: Re: Re: Kann Programmieren auf Basis von Flussdiagrammen Sinn machen?
|
21.07.2009 17:17
|
|
Anton Kramm schrieb:
> Hallo Hr. Ott,
>
> klingt super und gibts schon. jCOM1 subjektorientiertes BPM.
>
> Schöne Grüße
>
Sehr geehrter Herr Anton Kramm
> > Der Scope der Schritte wäre so gewählt, dass Programmieren kompletten Applikationen damit möglich
> > ist.
Mit kompletter Applikation meine ich Eingabemasken, Software interner Geschäftslogik und Datenbanken. Mit jCOM1 ist die Darstellung von Geschäftslogik im Format von Diagrammen, also die Programmierung eine kompletten Applikation nicht möglich.
|
Bernd Rücker
camunda services GmbH
|
Re: Re: Kann Programmieren auf Basis von Flussdiagrammen Sinn machen?
|
22.07.2009 13:31
|
|
Hallo.
Die alte Idee, dass man komplette Anwendungen rein per Klicki-bunti durch Fachanwender zusammenbaut? Sorry, das hat die Praxis doch gezeigt, dass das (noch) nicht wirklich funktioniert, oder nur in eingeschränkten Domänen. Zum Beispiel bei rein formularbasierten Workflows. Sobald aber mehr Logik dahintersteckt wird das schwierig. Oder es steckt eben zu viel Vorbereitung im Domänenbaukasten, so dass es sich schnell nicht mehr lohnt. Irgendwo muss die komplexität ja hin, die sonst in der Softwareentwicklung steckt.
Das ist aber ja die Story, die mit auch mit BPMN zu BPEL, BPMN 2.0, XPDL oder ähnlichen kandidaten anvisiert wird. Ist also doch nichts neues? Oder soll neu sein, dafür jetzt Aktivitätsdiagramme zu nehmen (wie in modellgetriebenen Ansätzen)?
Also Vision: ja! Klar! Aber da sind wir halt auch noch nicht...
Grüße
Bernd
Clemens Ott schrieb:
>
> Clemens Ott schrieb:
> > Was wäre, wenn es ein Aktivitätsdiagramm gäbe, das in sich selbst
> ablauforientiert und als Ganzes ergebnisorientiert mit logischen
> Operatoren mit entsprechenden Schritten, Prozessvariablen bzw.
> Prozessdaten ausgestattet werden kann? Und als Software-Funktion in
> einem Compiler liefe und als solche präsentiert werden könnte?
> Der Scope der Schritte wäre so gewählt, dass Programmieren kompletten Applikationen damit möglich
> ist. Diese Schritte stellten die IT-Vokabel dar. Ein oder mehrere
> solcher Diagramme könnten dann mit einem Geschäftsprozess-Schritt
> graphisch verknüpft werden. Dieser Geschäftsprozess-Schritt wäre dann
> ein Vokabel einer beliebigen Abteilung. Dies gäbe eine durchgehende,
> diagrammbasierende Sprache in einer bruchfreien Umgebung. Von der Idee
> über Geschäftsprozesse, zur prozessunterstützenden Applikation in einer
> Umgebung mit einer Sprache. Wie klingt das?
|
|
Clemens Ott
FBW I.T. Services GmbH
|
Re: Re: Re: Kann Programmieren auf Basis von Flussdiagrammen Sinn machen?
|
22.07.2009 15:14
|
|
Hallo Bernd
Die alte Idee, dass man komplette Anwendungen rein per Klicki-bunti durch Fachanwender zusammenbaut nicht nur als Vision: ja! Klar! Aber da sind wir halt auch noch nicht...
Wenn wir uns für einen Moment von den Standards und Schema basierendem denken enteisen behaupte ich:
Wir SIND schon DA !
Wir haben eine CRM und eine mini ERP und e-learning Applikation nur mit Diagrammen programmiert.
Grüße
Clemens
|
Dipl.-Ing. Dr. Christoph F. Strnadl
Software AG Österreich
|
Frage ist auch: Ist das die beste Art zu programmieren - Re: Re: Re: Kann Programmieren auf Basis von Flussdiagrammen
|
27.07.2009 19:50
|
|
Bernd Rücker schrieb:
> Die alte Idee, dass man komplette Anwendungen rein per Klicki-bunti durch Fachanwender
> zusammenbaut? Sorry, das hat die Praxis doch gezeigt, dass das (noch) nicht wirklich funktioniert,
> oder nur in eingeschränkten Domänen. Zum Beispiel bei rein formularbasierten Workflows.
Dem kann ich nur vollinhaltlich zustimmen.
> Sobald
> aber mehr Logik dahintersteckt wird das schwierig. Oder es steckt eben zu viel Vorbereitung im
> Domänenbaukasten, so dass es sich schnell nicht mehr lohnt. Irgendwo muss die komplexität ja
> hin, die sonst in der Softwareentwicklung steckt.
Exakt.
Die Frage ist nämlich (meines Erachtens) NICHT, OB man graphisch programmieren kann, sondern FÜR WELCHE ART von PROBLEMEN allenfalls eine derartige graphische Programmiersprache die SINNVOLLSTE Lösung darstellt ("sinnvoll" in Bezug auf: Kosten, Zeit, Qualität, was-auch-immer).
Man kann ja alles auch auf einer (universellen) Turing Maschine (UTM) programmieren - dennoch wird das nicht gemacht. Man kann nun unschwer der UML eine Semantik geben, die zeigt, dass diese UML äquivalent zu einer UTM ist - damit kann ich alles auch in UML "programmieren" - macht das aber überhaupt einen Sinn?
("executable UML" gibt es auch schon längere Zeit: E2E Technologies in der Schweiz bieten einen solchen UML Interpreter meines Wissens nach an).
Kernfrage wäre ja nicht die Möglichkeitsfrage ("OB" man das überhaupt kann), sondern: Ist eine graphische Repräsentation eines Programmes der geschriebenen Repräsentation überlegen?
Ich bin wirklich sehr visuell orientiert - aber ich glaube deshalb nicht, dass man ALLE für die Ausführung notwendigen Details sinnvoll rein in einem Diagramm/in einer Graphik darstellen können muss.
Natürlich ist ein BPMN Diagramm eines Prozesses ausgezeichnet für viele Kommunikationsprobleme und auch Ausführungsprobleme ("Execution") - aber Security, Directory, Bedingungen, Regeln an Gateways etc. würde ich doch nicht unbedingt in dasselbe BPD hineinpacken wollen.
MfG
-cfs
|
|
Bernd Rücker
camunda services GmbH
|
Re: Re: Re: Kann Programmieren auf Basis von Flussdiagrammen
|
27.07.2009 20:01
|
|
> Dipl.-Ing. Dr. Christoph F. Strnadl schrieb: ...
Kann ich mich nur anschließen!
Und ja, E2E läuft prima, kenne ich gute Anwendungen mit. Aber auf der anderen Seite kenne ich auch Kunden, die E2E dann einfach zu viel und für alles eingesetzt haben und dadurch viele Probleme meiner Ansicht nach zu komplex gelöst haben. Aufwand hat das auf keinen Fall gespart und die Entwickler haben es auch gehaßt ;-)
|
|
Clemens Ott
FBW I.T. Services GmbH
|
Re: Re: Re: Re: Kann Programmieren auf Basis von Flussdiagrammen
|
14.08.2009 11:50
|
|
Betreff:
> Die alte Idee, dass man komplette Anwendungen rein per Klicki-bunti durch Fachanwender
> zusammenbaut? Sorry ....
Dem kann ich nur vollinhaltlich zustimmen.
> Sobald
> aber mehr Logik dahintersteckt wird das schwierig
Exakt.
Bernd Rücker schrieb:
> > Dipl.-Ing. Dr. Christoph F. Strnadl schrieb: ...
>
> Kann ich mich nur anschließen!
>
> Und ja, E2E läuft prima, kenne ich gute Anwendungen mit. Aber auf der anderen Seite kenne ich auch Kunden, die E2E dann einfach zu viel und für alles eingesetzt haben und dadurch viele Probleme meiner Ansicht nach zu komplex gelöst haben. Aufwand hat das auf keinen Fall gespart und die Entwickler haben es auch gehaßt ;-)
Sehr geehrte Herrn ich, mit allem Respekt, widerspreche Ihnen Ihr liegt falsch.
Visuelles programmieren wird nicht durch BPEL oder einer der darauf aufbauenden oder genannten Produkte oder anderer Produkte in der Familie der Prozess "Exekution" unterstützt. (Da gibt es hervorragende Produkte, wie die genannten aber programmieren ist nicht der Sinn und Zweck oder das Ziel dieser Produkte )
- Das geht NICHT.
Programmieren ist der Vorgang alle Teile eines Programms, in einer Programmiersprache auszudrücken und diesen Ausdruck dann von der Maschine ausführen zu lassen. Nimmt man die Programmiersprache C als Referenz müssen folgende Elemente bei vollständiger Programmierung definiert werden:
Logischer Fluss
Datenfluss
Software Elemente und Instruktionen (z.B.:Variablen x = 3, Instruktionen "openfile","readfile" und Konstrukte wie if, while, etc.)
und für Business Applikationen folgende drei Ebenen:
UI User Interface UI
BL Business Logik BL (software interne nicht nur Business Prozess Logik)
BE Back End z.B.: Datenbanken und andere Back Ends wenn möglich.
Eine Programmiersprache muss all diese Element unterstützen um am Ende eine brauchbare Geschäftsapplikation erzeugen zu können.
So muss auch eine visuelle Programm Sprache diese Elemente unterstützen. Natürlich so das Sie schneller und einfacher zu verwenden ist aber auch ausdrucksvoll bleibt.
Wie Shu, Nan C. 1988 in "Visual Programming" im Preface schrieb:
"The challenge of this decade is to bring computer capabilities, simply and usefull, to the poeple without special training in programming - ( coding*). Visual Prgramming repesents a conceptually revolutionary approach to meet this challenge.
* ich hab das Wort programming mit coding ersetzt.
Diese Vision die Nan C. Shu 1988 festgehalten hat haben wir für den Bereich Geschäftsapplikationen 2009 in unserem Produkt ixp (www.ixp.com) als erste Firma auf der Welt in dieser Form verwirklichen können.
Wir präsentieren eine general purpose, Cross Domain spezifizierte visuelle Programmiersprache (in Diagramme und Schritte ) eingebettet in einem SaaS zum maximalen Nutzen für den Kunden im Bereich Geschäftsapplikationen an. Die Erste.
|
|
Clemens Ott
FBW I.T. Services GmbH
|
Re: Frage ist auch: Ist das die beste Art zu programmieren - Re: Re: Re: Kann Programmieren auf Basis von Flussdiagramme
|
14.08.2009 13:17
|
|
> Kernfrage wäre ja nicht die Möglichkeitsfrage ("OB" man das überhaupt kann), sondern: Ist eine graphische Repräsentation eines Programmes der geschriebenen Repräsentation überlegen?
>
Betrachten wir die Programmiersprachen relative zu ihren Abstraktionsebenen von " machine code " zu C und C++ und Java. Diese Abstraktionsebenenwerden immer höher durch Bibliotheken, Spracheigenschaften aber gleichzeitig bleiben alle Sprachen auf einer rudimentären Ebene verbunden. Eine mögliche nächste Ebene ist die echte visuelle Ebene. Da gibt es Icon -, Diagramm - und Tabellen basierende Ansätze.
Icon => scratch von M.I.T. (games) ;
Tabellen => spreadsheets von mehreren Herstellern MS office, SUN open office (Buchhaltung und ähnliche Bereiche).
Diagramme:
Die Diagramm Form ist die meist verwendete Darstellungsform von abstrakten Geschäftselementen wie Prozessen.
Wir modellieren in Organigrammen ... Anwendungsfalldiagrammen ... EPK's ..., Activity Diagrammen. Activity Diagramme mit "composite Steps " stellen Geschäftsprozesse der Fachabteilungen dar.
NEUERUNG:
Weiter programmieren wir in Activity Diagrammen mit "atomic step" die modellierten Geschäftsprozesse Schritte bis zur lauffähigen Applikation weiter aus.
So werden nicht nur die Geschäftsprozesse mit den Software internen Prozessen visuell verknüpft. Fachkräfte können sich einer gemeinsamen Sprache bedienen was Kommunikation vereinfacht. Nachhaltiges Wissen und Dokumentation Austausch innerhalb der Firma fördert sofern die menschliche Einstellung die richtige Verwendung dieses Werkzeugs ermöglicht.
Kleine Firmen können die fertigen Applikationen, visuell programmiert, verwenden und diese bei Bedarf jederzeit abändern - ohne Großen Mehraufwand.
Große Firmen die eine ausgeprägte interne Kommunikationnotwendigkeit haben oder Firmen mit einem komplexen Sachverhalt scheitern daran das sich Leute nicht verstehen.
Diagramme auf beiden Seiten, technische als auch nicht technische, sind ein Werkzeug das die andere Seite verständlicher macht und sehr schnell "Hoppalas" aufdeckt. Wenn Vokabel definiert werden wie Composite Steps und dies auch von der IT Abteilung mit visuellen Darstellung hinterlegt werden und so von eine Software unterstützt sind, kann das Verhältnis zwischen Firma und Software von den Mitarbeitern neu gestaltet werden.
Mit positiven "Hoppalas"
Diagramm basierendes modellieren und programmieren ist der nächste Schritt in Richtung
Flexibler I.T. mit wendiger Kosten für Individuelle Softwarelösungen.
Es kann auch als Kommunikationswerkzeug oder prototyping oder Training und re-Training von Wissen verwendet werden.
Sorry if I make mistakes in German, although from Vienna I have spend about half my life abroad in Texas. In these last 25 years I spoke less and less German.
|
|
|
|
Mein BPM-Statement:
"You can't control the economic climate. But you can control the processes that power success inside your organization. " (Gartner 2009)
Matthias J. Göckel, Allianz Suisse Versicherungs-Gesellschaft AG, Mitglied seit 02. December 2011
|
|
|
|
|
|
 |
| BPM-Netzwerk.de - Tue May 21 16:45:19 CEST 2013
- Impressum - AGB |
|