Welche Vorteile und Risiken birgt der Wechsel zu einem modellgetriebenen Architekturansatz?

Question

Ich arbeite in einem Unternehmen mit etwa 350 Mitarbeitern, und wir sind dabei, zu wachsen. Unsere derzeitige Codebasis ist nicht sehr gut strukturiert, und wir überlegen, wie wir sie sofort verbessern können (indem wir Objekte in Namespaces organisieren, Belange trennen usw.) und zu einem modellgesteuerten Architekturansatz übergehen, bei dem wir alles zuerst mit UML modellieren und entwerfen und dann Code aus diesem Modell generieren. Wir haben uns intensiv mit Sparx Systems Enterprise Architect (EA) befasst (das UML 2.0-fähig ist) und ziehen auch die Tools in VS 2010 in Betracht. Ich weiß, dass es noch andere Tools gibt (z. B. Rational XDE), aber ich glaube nicht, dass wir zu diesem Zeitpunkt $1500+ pro Lizenz ausgeben können.

Ich suche nicht nach Antworten auf die Frage, welches Tool besser ist als ein anderes, sondern eher nach Erfahrungen mit dem Wechsel von einer Cowboy-Coding-Umgebung (d. h. wenig Planung und Design, einfach loslegen und programmieren) zu einer modellbasierten Architektur. War dies rückblickend für Ihr Unternehmen hilfreich? Was sind die Probleme? Welches sind die Risiken? Was sind die Vorteile?

Answer 1

Wir haben das einmal mit einem 3-Mloc-Logistikplanersystem gemacht, und es hat gut funktioniert. Wir haben jedoch früh erkannt, dass UML nicht ausreichen würde. Sie war einfach zu unübersichtlich, um den für die Spezifikation erforderlichen Detailgrad zu erfassen. Der beste Weg war tatsächlich die Verwendung von Pseudocode (den ohnehin jeder für die Kommunikation von Ideen verwendete)! So kam es zu dieser Erkenntnis. Die Verwendung von UML fühlte sich wie ein Schritt weg von der Klarheit an.

Als sich die Ideen zu einer Lösung zu verdichten begannen, wurde ein Versionskontrollsystem eingesetzt, um die Änderungen am Pseudocode (und an den Anwendungsfällen usw.) zu verfolgen. So konnte jeder in der Gruppe die Änderungen verfolgen. Nach und nach wurden Teile in tatsächlichen Code übersetzt, zusammen mit Dokumentation und Verweisen auf Motivationen und Diskussionen.

Letztendlich verlief der Übergang vom Modell zum Code sehr reibungslos. Der wirklich schöne Teil war, imho, die Verwendung vcs, die Sie auch die ursprüngliche Pseudo-Code ohne Wechsel der Umgebung zu sehen erlaubt.

Answer 2

Ich habe meine Bachelorarbeit über modellgetriebene Softwareentwicklung geschrieben und möchte Sie nur warnen, dass es wirklich wichtig ist, einen guten Ansatz für das zu verwenden, was Ihr Unternehmen beabsichtigt. Es gibt viele Dinge, die schief gehen können, wie z.B. die direkte Bearbeitung des generierten Codes, die Möglichkeit, den Code nur einmal zu generieren, weil manuell bearbeiteter Code nach der Generierung gelöscht wird, die Notwendigkeit einer Domänenanalyse, um ein gutes Metamodell zu erstellen und ein gutes Framework für die Codegenerierung zu verwenden... Bitte verstehen Sie mich nicht falsch, ich denke, MDSD ist großartig, aber achten Sie darauf, wie Sie es machen. Die ursprüngliche MDA und die Bücher darüber schlagen wirklich schlechte Ansätze vor, die zu kostspielig und zu spröde sind. Ich schlage vor, dass Sie sich die Website voelter.de ansehen, wo Sie Papiere, Präsentationen und Podcasts von Markus Voelter finden, der ein sehr erfahrener Berater auf diesem Gebiet ist.

Answer 3

Für mich ist der wichtigste Aspekt, manchmal pragmatisch zu sein. Modellierung sollte keine boolesche Aktivität sein (wir modellieren nicht entweder oder nicht). Wir sollten in der Lage sein, die Modellierungsebene/Präzision an die Merkmale des Projekts (siehe z. B., was Leute, die an agiler Modellierung arbeiten, tun) und des Unternehmens anzupassen. Zu wenig oder zu viel Modellierung kann problematisch sein (bei zu wenig Modellierung sehen Sie vielleicht keinen Nutzen, bei zu viel Modellierung kann Ihr Unternehmen überfordert sein, besonders wenn Sie am Anfang des Übergangs stehen oder nicht über die erforderlichen Werkzeuge verfügen).

In meinem Portal/Blog ( http://modeling-languages.com ) diskutieren wir oft über die Vorteile der Modellierung oder darüber, wie die Modellierung eingesetzt werden sollte. Vielleicht ist es für Sie interessant

Answer 4

Unsere derzeitige Codebasis ist nicht strukturiert nicht sehr gut strukturiert und wir suchen sowohl nach wie wir sie sofort verbessern können [...] und den Wechsel zu einem modellbasierten Architektur-Ansatz, bei dem wir modellieren und entwerfen alles zuerst mit uml, und dann Code aus diesem Modell generieren.

Zunächst einmal ist es großartig, dass Sie und Ihr Unternehmen erkennen, dass Ihr Softwareentwicklungsprozess einige Mängel aufweist und dass es eine Bereitschaft zur Verbesserung .

Es scheint jedoch, dass noch viel Arbeit vor Ihnen liegt und viele Dinge in verschiedenen Richtungen zu verbessern sind. Mein erster Rat wäre, nicht zu versuchen, etwas zu ändern. alles sofort. Die Menschen sind im Allgemeinen zurückhaltend gegenüber Veränderungen, und jeder braucht eine gewisse Zeit, um neue Veränderungen zu verdauen. Es ist auch sehr wichtig, ein gemeinsames Verständnis darüber zu schaffen, was eingerichtet werden muss. Dieses gemeinsame Verständnis lässt sich nicht an einem Tag herstellen. Solche Veränderungen erfordern eine mittel- oder langfristiges Engagement .

In Bezug auf die MDA ist es wichtig zu wissen, dass sie einige Disziplin . Abhängig von Ihrem Team könnte es gut sein, dass Sie zuerst daran arbeiten, um den nächsten Schritt vorzubereiten, nämlich die Einführung von MDA. Ich sage das, weil Sie sagen, dass Sie einen "Cowboy"-Prozess haben, was bedeutet, dass die Leute wahrscheinlich gewohnt sind, zu tun, was sie wollen - das ist ein No-Go für MDA.

Dann kommt die Einführung der MDA selbst. Es gibt verschiedene Möglichkeiten, MDA durchzuführen (und ich werde hier nicht näher darauf eingehen), aber die immer noch vorherrschende Methode ist die sogenannte Round-Trip-Technik . Das größte Problem besteht dann darin, das Modell und die Quelle synchron zu halten.

(Meiner Meinung nach führt MDA nur dann zu einer positiven Investitionsrendite, wenn das Modell für mehrere Projekte wiederverwendet werden kann. Das bedeutet, dass Sie die Dinge, die Sie immer wieder tun, identifiziert haben müssen und eine ausreichend klare Sicht auf das Problem haben müssen, um ein ausreichend vollständiges Modell und Transformationen erstellen zu können, die Sie projektübergreifend wiederverwenden können. Ich glaube nicht, dass MDA funktioniert, wenn jedes Projekt völlig anders ist; der Zeitaufwand für die Erstellung des richtigen Modells und der Transformationen usw. wird größer sein, als wenn man nur mit Code und Dokumentation arbeitet. )

Ein anderer Ansatz ist, MDA nicht vollständig umzusetzen - man generiert keinen Code aus dem Modell - sondern das Bewusstsein der Leute für Modellierung und Design zu erhöhen, z.B. mit UML. Auf diese Weise werden Sie nicht mit Round-Trip-Problemen konfrontiert, verbessern aber dennoch die Reife Ihres Softwareentwicklungsprozesses.