Neuer Thread
Ansicht umschalten Baum an
Avatar von rumpelstilz73

rumpelstilz73

967 Beiträge seit 16.07.2005

21.12.2012 01:13 Permalink

Re: Was die MDA Protagonisten leider nicht verstehen

Da hast Du Dir aber auch viel Mühe gemacht! 

> Mit einem praxisnahen MDA soll das Ziel verfolgt werden, durch
> Modelle (bzw. durch deren Anwendung) standardisierte Artefakte auf
> der Ebene von Architekturartefakte zu "generieren". Dadurch soll und
> kann unter anderem gewährleistet werden, dass (aus Architektursicht
> gesehen) bestimmte Teile der Software/Architektur einem Standard
> genügen und nicht jeder Entwickler diesen Teil der Software neu
> "erfinden" muss.

Ein typisches Artefakt, das mittels MDA generiert wird, sind
Service-Schnittstellen oder UI-Elemente. Schauen wir uns ein Beispiel
an:

Da geht man dann hin und modelliert (mit UML-)Komponenten und
Interfaces mit bestimmten Stereotypen, woraus später Code generiert
wird. Z.B. wird eine Komponente "CarRating" definiert, die eine
Schnittstelle "RatingService" anbietet. Das sieht dann UML-ähnlich
etwa so aus:

<<component>>            
CarRating
------------> 
<<service>>
RatingService +

(man stelle sich die "realizes" Beziehung und den RatingService bitte
horizontal auf gleichener Ebene wie CarRating vor - der Heise-Editor
gibt nicht mehr her...)

Daraus generiert MDA dann folgendes (angenommen die Zielsprache ist
Java):

public interface RatingService { ... }
public class CarRating implements {....}

sowie allfällig notwendige weitere Elemente für Datentypen der
einzelnen Methoden. Da es sich um ein <<service>> Interface handelt,
werden noch weitere Artefakte generiert, wie z.B. WSDL Files. Damit
die Files korrekt generiert werden können - z.B. die richten
Endpointbezeichner, Protokoll-Angaben etc. - werden auf dem
<<service>> Stereotype Attribute hinzugefügt, die der MDA Generator
dann nutzen kann. (Damit wird zwar das PIM flugs und defacto zum PSM,
aber das nur am Rande).

Nun liesse sich dasselbe und vor allem derselbe Abstraktionsgrad aber
auch erreichen, in dem man von Beginn weg die Möglichkeiten der
Sprache nutzt und ggf. erweitert, also beispielsweise:

@WebService(endPointInterface...)
public interface RatingService { ... }

Das ist nicht weniger Abstrakt als das obige Bild, mit dem feinen
Unterschied, dass diese Variante wesentlich schneller einzutippen
ist, einfacher zu warten, als jedes Diagramm oder Modell, zumal
anständige Editoren wie NetBeans oder Eclipse dafür gute
Unterstützung anbieten.

NB: Die Visualisierung dieses Konstruktes in UML hat wie schon
geschrieben eigene Vorteile, aber man braucht die Visualisierung
nicht, um Abstraktion 
zu erreichen.  

> zu 1)
> Jaein... mit der Idee eines MDA-Ansatz ist natürlich nicht gemeint
> 1:1 Java-Klassen zu modellieren. Dann hat man MDA nicht verstanden
> und nutze die Potenziale von MDA NICHT.

Glücklicherweise gibt es Dinge wie OSGi oder Jigsaw, in anderen
Sprachen ähnliches, mit denen ganze Komponenten mit klaren
Schnittstellen und Abhängigkeiten definiert, verwaltet und einfach
wiederverwendet werden. Das Klassenbeispiel habe ich nur angeführt,
weil es einleuchtend ist, dass eine gezeichnete Klasse nicht
abstrakter wird, nur weil sie gezeichnet wurde. Wahrscheinlich haben
wir hier auch keinen Dissens, es gibt aber leider Leute, die bei
einer Visualisierung erfreut "gut, weil so schön abstrakt!" rufen,
und bei Code "iiih, viel zu konkret!".

Anders gesagt: man kann mit "Codemitteln" sehr wohl Abstraktion
erzeugen, und auch Standardisierung bestimmter
Architekturkomponenten. Dafür braucht es weder UML noch einen
Generator. Es braucht jemanden, der die Abstraktion definiert, die
Schnittstellen dazu (=Sprache) definiert, mit der man diese nutzen
kann, und sie dann anbietet. Beispiele dazu sind Netzwerkprotokolle
wie TCP/IP oder relationale (und andere) Datenbanken - beides
existiert nett verpackt in Form von grösseren Softwarekomponenten,
die bestimmte Architekturmerkmale standardisieren, ohne dass dafür
der Umweg über eine grafische Darstellung oder einen Code-Generator
notwendig wäre. Ähnliches existiert auf vielen anderen
Abstraktionsebenen auch, z.B. Web-Browsers, mathematische oder
statistische Sprachen wie Matlab oder R, ja ganze ERP-Systeme. Das
sind allesamt eigentlich nichts anderes als Abstraktionen, die wie Du
sagst bestimmte Architekturmerkmale vorgeben, sodass sie nicht
jedesmal neu codiert werden müssen.

Meine These ist, dass wer "zuviel" Code schreiben muss, um ein
bestimmtes Ziel zu erreichen, vermutlich nur noch nicht die richtige
Abstraktion im Code-Sinne gefunden hat. Gilt analog wenn man
feststellt, dass immer wieder derselbe Code geschrieben werden muss.
Als ein Indiz für die Richtkeit dieser These führe ich die
Entwicklung von Java Enterprise von Version 2 zu 3 an. In Version
eins mussten mühsam Home- und Remoteinterfaces explizit codiert
werden, um Remote-Beans zu erhalten, und es waren dazu auch einige
XML-Konfigurationen notwendig dazu. Dies ist nun nicht mehr
notwendig, weil in Version 3 mit Annotationen gearbeitet wird, die
die ganze Komplexität der Technik vom Entwickler verstecken. Der
Abstraktionsgrad wurde also mit Mitteln der Sprache selbst erhöht. 


> zu 2)
> Zur richtigen Einordnung aus wiki:
> "Compiler sind spezielle Übersetzer, die Programmcode aus
> problemorientierten Programmiersprachen, sogenannten Hochsprachen, in
> eine Assemblersprache, maschinell ausführbare Maschinensprache oder
> Bytecode überführen"

> MDA bewegt sich auf einer abstrakteren Ebene und hat im engeren Sinne
> NICHTS mit Compiler, Assembersprachen usw. zu tuen. MDA beschreibt
> eher den Ansatz einer Hoch-Hochsprache, die dann in eine Hochsprache
> "übersetzt" bzw. generiert wird. Dann stimme ich dir zu.
>

Ob von einer Abstraktion genannt "Hochsprache" erst in eine andere
Hochsprache übersetzt wird, oder von einer Abstraktion direkt in
Maschinencode, macht semantisch keinen Unterschied. Es ist in jedem
Fall eine Transformation einer Sprache in eine andere.   

> zu 3)
> "... Die Produktivität sinkt damit auf ein nicht
> vertretbares Maß zurück"
> Das passiert leider mit allen Dingen im Leben, die man nicht richtig
> macht. Das ist nicht das Problem des MDA-Ansatzes, sondern deren
> falschen Anwendung bzw. Verständnisses. 


Einig.

> zu 4)
> ... das kann sogar richtig sein, hat aber auch nichts mit MDA zu
> tuen, da MDA nicht das Ziel verfolgt ein "geschlossenes" Programm zu
> spezifizieren. Wie oben erwähnt geht es um eine abstraktere Ebene,
> die Architektur-Ebene.


Ja, nur ist das Ziel der meisten Softwarentwicklungen, lauffähige
Programme zu erstellen. Architekturen sind nur Mittel zum Zweck, aber
niemals Selbstzweck. Ich bin nicht sicher, was MDA für Dich ist, aber
nach meiner Erfahrung ist damit sehr oft ein rechter Teil Selbstzweck
verbunden - es wird "MDA gemacht" weil man doch ein "PIM" braucht,
und kein "PSM", letzteres kann man gegeben das richtige PIM und den
geeigneten Generator dann doch generieren und braucht also keine oder
nur noch wenige Programmierer! :-) 

> zu 5) 
> Ich bin auch ein Freund von Pragmatismus. Viele Leute "kennen" UML
> bzw. haben entsprechenden Werkzeuge im Unternehmen. Daher gibt es
> eine große Akzeptanz bei der Modellierung in UML. MDA schlägt zwar
> UML als Beschreibungssprache vor, aber gibt es nicht zwingend vor. Es
> wird bei den meisten "MDA-Tools" als best practise verwendet. Schau
> dich aber mal um, da gibt es viele viele weitere Ansätze, (d)ein
> Modell zu beschreiben bzw. für den Menschen richtig aufbereitet zu
> beschreiben.

Einig.


> Ich höre aus deinem Beitrag heraus, dass du schlechte Erfahrungen mit
> dem Thema gemacht hast. Ich habe durchweg positive Erfahrungen mit
> einem MDA-Ansatz in unterschiedlichster Ausprägung gemacht.
> Vielleicht brauchst du nur einmal das "richtige" Projekt...


Schlechte Erfahrungen als solches würde ich nicht sagen, aber ich
habe schon sehr (zu) viele nutzlose Stunden damit verbracht, über
Metamodelle zu diskutieren, die am Ende keinen sinnvollen Nutzen
hatten. 

Bewerten - +
Anzeige

THEMENFOREN

ARTIKELFOREN