Model-Driven & Service-Oriented Architectures (MDA + SOA)

Model-Driven & Service-Oriented Architectures (MDA + SOA)

Posts 1-5 of 5
  • Milan Kratochvíl
    Milan Kratochvíl
    The company name is only visible to registered members.
    SOA - Komponenten - Konfigurieren, u. MDA-Kodautomation
    IMO., Automatisieren ist einfacher wo es bereits viele fertige Komponenten gibt, weil "funkzionelles Konfigurieren" auch auserhalb der IT-industrie durchgeprüft wird. SOA vorantreibt gerade eine Komponentenkultur, die früher nur sehr langsam Betriebsweit eingeführt werden konnte.
    "Green-lawn" Projekte dagegen sind viel schwieriger, vom Automationgesichtspunkt aus gesehen (obwohl es mehrere solche Projekte gibt die es schon praktizieren); in diesem Bereich wird die Umstellung zu MDA/UML2 als gewöhnliche/gewöhnlichste Programierungsprache noch mehrere Jahre fordern, etwa wie einmal die von Assembersprachen zu 3GL und 4GL.

    Wie kan man die bisherige Lücken in der UML2-Action Spec Standardisierung umgehen? OCL? Eigene 5GL? Any more hints?
    /Milan Kratochvíl, Stockholm
    • 23 Nov 2005, 5:50 pm
  • Christian Bühler
    Christian Bühler    Premium Member
    The company name is only visible to registered members.
    Re: SOA - Komponenten - Konfigurieren, u. MDA-Kodautomation
    Es ist bereits jetzt möglich, ausführbare Spezifikation mit der UML2 zu modellieren. Das einzige fehlende Glied in der UML-Spezifikation ist die Syntax für die UML-Action language. Die Semantik der UML.action language ist jedoch bereits im Standard. Wie eine ausführbare UML-Spezifikation aussehen könnte, wenn man der Semantik vorübergehend eine eigene Syntax zuordnet, zeigt der Artikel auf http://www.sigs-datacom.de/sd/publications/pub_article_show....
    Eine solche UML-Spezifikation ist absolut plattformunabhängig und lässt sich mit CASSANDRA/xUML direkt ausführen.

    Viel Spass
    Christian Bühler
    • 08 Dec 2005, 11:12 am
  • Milan Kratochvíl
    Milan Kratochvíl
    The company name is only visible to registered members.
    Re^2: SOA - Komponenten - Konfigurieren, u. MDA-Kodautomation
    Vielen Dank Christian, für die Antwort und deinen Artikel.

    1. Action Language
    Bist du der Meinung dass man in eine nahere Zukunft auch praktisch heutige xUML2-Modelle (welche eine eigene ASL benützen, die eine Betrieb-spezifische Sprach-Oberfläche hat aber jedoch die UML/AL Semantik folgt) auch in künftigen UML2-Werkzeugen zeigen kann, ohne zuerst einen manuellen "Fix" zu brauchen?

    2. Zustand in "enterprise systems"
    Hier gibt es, in der Kerne ("Geschäftslogiklage"), zentrale "persistente" Fachobjekte (z.B. Reservierung, Buchung, Auftrag, Konto, Versicherung, Vertrag) die ein intressantes Zustandsdiagramm haben aber doch viele Anwendungsfälle (und damit mehrere Sequenzdiagramm) durchleben und überleben (und damit also auch nur sehr langsammes "Echtzeituhr" haben). Von diesen ist es einfach Geschäftsregel zu ableiten/generieren aber kaum Programiersprachen plus SQL. Echtzeit-Apps dagegen könen ein Zustandsdiagramm direkt als Quelle benützen (das wurde schon in der Rose RT mit UML 1 getan, aber als "Action Language" gab es nur C).
    M.f.G., Milan
    • 08 Dec 2005, 3:49 pm
  • Christian Bühler
    Christian Bühler    Premium Member
    The company name is only visible to registered members.
    Re^3: SOA - Komponenten - Konfigurieren, u. MDA-Kodautomation
    Zu 1:

    Solange die verwendete Action-Language auf der UML-Semantik aufbaut, sollte ein späteres Anpassen an die definitive standardisierte Notation keine besonderen Schwierigkeiten bereiten. Eine automatisierte Konvertierung sollte eigentlich machbar sein.
    Ich hoffe jedoch nicht, dass das Fehlen eines Standards für die Notation dazu führt, dass jeder die Notation so baut, dass Sie für seinen Betrieb perfekt passt. Ziel soll es sein, einen allgemein gut anwendbaren standard zu schaffen, damit jeder UML-geschuhlte nachher alle UML-Diagramme sofort richtig lesen kann.

    Zu 2:
    Wir promoten schon seit langem, auch für die Modellierung von Informationssystemen Zustandsdiagramme zu verwenden. Ein Objekt Vertrag kann schon mal ziemlich komplexe Zustände haben. In der Tat ist es so, dass bei genauerer Betrachtung, die meisten Objekte, ein mehr oder weniger komplexes Verhalten aufweisen und es sich allemal lohnt, dieses mit einem Zustandsdiagramm zu dokumentieren. Leider werden Zustandsdiagramme oft immer mit embedded oder Realtime-Systemen in Verbindung gebracht und für Informationssysteme als zu technisch angesehen. Dabei hat ein Zustandsdiagramm, solange man nicht irgendwelchen C Code reinschreibt gar nichts mich Technologie zu tun!
    Soll aus solchen Zustandsdiagrammen Code erzeugt werden, muss zuerst die Zielplattform untersucht werden. Aspekte wie Persistenz und Transaktionsmechanismen und viele weitere Dinge müssen korrekt in die Codegeneration einfliessen.
    Prototypen von 100% Codegeneratoren habe ich entwickelt und ich bin überzeugt, dass sich eine modellbasierte Entwicklung mit 100% Codegenerierung erreichen lässt. Ich denke jedoch auch, dass es immer eine Anpassung des Generators auf das spezifische Umfeld braucht.

    M.f.G
    Christian
    • 08 Dec 2005, 5:13 pm
  • Milan Kratochvíl
    Milan Kratochvíl
    The company name is only visible to registered members.
    Re^4: SOA - Komponenten - Konfigurieren, u. MDA-Kodautomation
    Vielen Dank, Christian.

    1.
    Das glaube ich auch.

    2.
    Der Gewinn beim Modellieren ist sehr sichtlich, auf einer seite. Ohne zustand bleibt es im Program unklar, was mit einem "normal-Leben" des Objekts zu tun hat und was von der bearbeitung von Ausnahmen/Fehler ausgeht.

    Beim Codegen, auf der anderen Seite, wird es (im Vergleich mit Echzeit-Apps) schwieriger weil:

    a) ein Geschäfts-Ereignis nich genug augenblicklich ist, manchmal handelt es sich um komplette Anwendungsfälle (in denen die selbe Entität involviert wird), die in dem Zustandsdiagramm der Entitätsklasse zusammengeknüpft worden sind (Regel sind aber sehr selten ein Problem, auch z.B. SQL-Referenzintegritätsregel, weil man sie von einem Zustandsdiagramm geradeaus auslesen und herleiten kann, etwa: IF Transaktion = Abhebung AND Jetziger-Saldo = 0 THEN send event = Warnung (übergezogen).
    Vom Zustandsdiagramm der Entitätsklasse aus gesehen, ändert die Ereigniss/Transaktion eigentlich nur den Zustand des Objekts in der DB, vieles kan aber später, off-line getan werden (Rapporte usw.).

    b) Genau wie du es beschrieben hast, mehr als nur die Programsprache dabei involviert wird (z.B. SQL, die Transaktionsumgebung/middleware u.s.w.)

    (ich denke auch dass die Strukturierungsmöglichkeiten des UML2-Sequenzdiagramms/Interaction Frames es sinvoll machen, code von Zustand- und sogar Sequenzen zu generieren: ein Objekt-Programm mit vielen kleinen Objekten/Zustandsdiagrammen macht auch die Kontroll-Logik der App im Sequenzdiagram voll sichtlich).

    M.f.G.
    Milan
    • 13 Dec 2005, 6:09 pm