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

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

This thread has been closed so unfortunately you can't post here any more.

Posts 11-12 of 12
  • Post visible to registered members
  • Andreas Leue
    Andreas Leue    Group moderator
    The company name is only visible to registered members.
    Re^3: Benutzeroberflächen - Cross-Compiler vs. MDA ?
    Hallo allerseits,

    die Diskussion ist zwar schon etwas älter, die folgende Antwort jedoch nach wie vor relevant.

    Wie seht ihr die Entwicklung im Bereich der Benutzeroberflächen?
    Wir arbeiten seit 1993 an dem Thema, verfolgen seit 1995 einen bestimmten UI-Architektur-Ansatz, evaluierten diesen 1996 bis 1999 in konkreten Projekten, kombinierten ihn 2000 erneut mit generativen Verfahren, 2005 boten wir das Produkt "SirFace" isoliert an, heute integriert in unser EM/OS-System in der Version 2.0. Details EM/OS: http://www.sphenon.de

    Stand heute können Web-Oberflächen und eclipse/SWT/TCP-Oberflächen out-of-the-box aus einem annotierten UML-Modell heraus erzeugt werden, wobei man noch zur Laufzeit die Oberfläche wechseln kann. Die Oberflächen sind mehr oder weniger vollständig, also nicht zum Spielen, und können, ohne Konflikt zum Generat und mit vertretbarem Aufwand, individualisiert werden.

    Das funktioniert wie im folgenden erklärt.

    Ein ewiges Thema... Softwareindustrie...seit 15 Jahren keine substanziellen Fortschritte gibt....
    Eine gemeinsame Modellierungssprache für GUIs müsste wohl sowas wie die Schnittmenge der o.g. Sprachen sein. ...genau die Elemente (Widgets, Container, o. Ä.) enthält...
    Die Annahme, daß das Problem auf diese Weise gelöst werden müßte, ist genau der Grund, warum es bisher nicht funktioniert hat.

    Das hat mit der "Blickrichtung der Abstraktion" zu tun, und diese stammt aus uralten Programmierzeiten, als man sich in seinem Code mit dem An- und Ausschalten von Pixeln beschäftigte. Seit dieser Zeit schaut der Architekt vom Standpunkt des Programmierers aus in Richtung der technischen Oberfläche. Aus dieser Sicht entsteht der Wunsch, "über alle Oberflächen hinweg" generalisieren zu wollen, und Oberfläche meint dabei eben die konkreten, technischen Oberflächen.

    Und so funktionert es: man drehe sich um und schaue vom Anwender aus durch den Bildschirm hindurch und durch die technischen Oberflächen hindurch bis knapp vor die Geschäftslogik. Aus dieser Richtung versuche man abgestuft abstrahierende Schichten zu bilden.

    Was dabei herauskommt, ist ein ausgebautes MVC, wir haben das "M3V" getauft, ein Model, 3 Views, beschrieben hier:

    http://www.m3v.org

    Setzt man diesen Architekturansatz um, ergibt sich die Forderung, sämtlichen Business-Logik-bezogenen Code, also Validierungen, Texte, Abläufe (!) usw. aus den oberen Schichten zu eliminieren und zurück in die Geschäftslogik zu schieben. Detaillierter ist die Gesamtarchitektur hier beschrieben, im zweiten Teil des Artikels:

    http://test.sphenon.de/emos/architecture2010.pdf

    Es gibt sich insbesondere in Konsequenz architektonisch eine abstrakte Oberflächenschicht, die wir "Virtual User Interface" (VUI) nennen, siehe dort.

    weil man sie nicht richtig formal beschreiben kann. Daran wird sich wohl auch so bald nichts ändern.
    Man kann es, wenn man konsequent dem beschriebenen Ansatz folgt. Die Beschreibung setzt sich aus folgenden Teilen zusammen:

    A Oberflächen-unabhängig:
    A.1 UML-Kern-Klassengerüst, also die fachlichen Klassen (Person, Adresse, usw.)
    A.2 UI-Equipment, entspricht etwa dem, was Martin Fowler mit dem Presentation Pattern erreichen möchte, also Texte, Validierungscode usw.
    A.3 Der Interaktionsschicht, formuliert in UML, in der sich Transaktionen und Workspaces auf geschäftslogischem Niveau befinden
    A.4 weiteren UML-Modell-Annotationen, die Filterungen, Berechtigungen, Prioritäten, Gruppierungen u.ä. beinhalten
    A.5 Style-Annotationen auf allen Ebenen, das sind einfach textliche Klassifikationen wie "wichtig", "geheim", "ProjektX" usw.

    B Oberflächen-spezifisch
    B.1 fallweise individuelle Renderer, etwa JSP-Seiten - es gibt einen Pool von Standard-Renderern, die polymorph den VUI-Klassen zugeordnet werden
    B.2 CSS layout finetuning
    B.3 fallweise SSCSS layout finetuning (SSCSS = server side CSS, wird beim rendering process ausgewertet)

    Beim Einsatz von MDA/UML lassen sich nicht beliebige Benutzeroberflächen komplett generieren, sondern "nur" solche, die bestimmten Konventionen folgen sollen.
    Diese Einschränkung ist mit dem geschilderten Ansatz nicht mehr gegeben, im Gegenteil sind Kunststückchen möglich, die mit klassischen Ansätzen undenkbar wären: wechsel der Oberfläche vom Desktop zum Handy in der gleichen Session (!), substantieller Wechsel des Layouts während der Arbeit usw.

    Wie sieht es mit dem modellieren von Abhängigkeiten der Zustände der Benutzeroberfläche aus? Zum Beispiel auf View-Ebene:
    Zustände werden eingeteilt in:

    - geschäftslogische Zustände (gültiges Objekt, ungültiges Objekt)
    - abstrakte Oberflächenzustände (hier etwa: momentan greyed out)
    - spezifische Oberflächenzustände (dieses oder jenes Tab ist aktiv)

    Für Fragen und weiteres stehe ich gerne zur Verfügung.

    Viele Grüße,
    Andreas Leue
    • 10 Jul 2009, 10:12 am