Voraussetzungen und Schwierigkeiten
Voraussetzungen:
- Diplom-Physik mit Schwerpunkt Theorie/Mathematik
- langjährige Berufserfahrung in der ERP für gehobenen Mittelstand auf der /38->AS/400->i-Series (© geschützter Markennamen der IBM Corporation)
- langjährige Berufserfahrung in prozessorientierter Programmierung in Studio
- diverse mehr oder minder tiefgehende und/oder veraltete Kenntnisse in allen möglichen Entwicklungsumgebungen und Skriptsprachen
- einfache Datenbankvermessung: 4fF-Methode wie beschrieben in „Die individualität liegt in den Daten“, ISBN 3-935031-00-9
- einfache Modellierungsmethode, aus verbalen Vorgaben zu einem grundlegenden Objektmodell (Roadmap) zu gelangen: ML-Methode wie beschrieben in „Die Fliege oder das Handwerk der Datenbank-Programmierung“, ISBN 3-935031-02-5 und „ML Method – a basic technique of analysis to create specifications for database software“ (pdf, 127 KB) (Beispiel für die Anwendungsbreite: die Anwendung auf ein Grimms Märchen)
- grundlegendes Verständnis der Information, der Struktur, die sie Informationsverarbeitungen aufzwingt sowie der Strategien der Informationsverarbeitungen, wie beschrieben in „Physik der Information“, ISBN 3-935031-03-3
Schwierigkeiten:
Das Projekt soll mit Eclipse und Rails durchgeführt werden, wobei jedoch die Programmier-Erfahrung wenig Hilfestellung bei all den Problemen rund um die Web-Programmierung liefert und auch die Sprache „Ruby“ ist noch reichlich neu.
Ist aber alles „nur eine Frage der Zeit“.
Ziel: „Die offene Entwicklung eines Kernel-Konzepts von Grund: Von der Analyse der Problemstellung ausgehend von den verbalen Vorgaben der Auftraggeber zu einem logischen Grobkonzept mithilfe der ML-Methode zum lauffähigen Programm a la „Model Driven Architecture“ unter Ausnutzung von Kernel-Strukturen“
Kurz und unpräzise (der kurz-und-präzise-Part ist am Ende von „Projekt“ aufgeführt):
Es soll ein Produkt geschaffen werden, das mit einem Blatt Papier gefüttert wird und mit ein paar ganz einfachen Fragen und vielleicht noch einfachsten, allereinfachsten Programmierkenntnissen eine lauffähige, erweiterbare und bequem zu wartende Software schafft.
Wozu?
Ein solches Produkt könnte von den Power-Usern, den Anwendern mit „nur“ praktischen IT-Kenntnissen, genutzt werden, Software zu erstellen. Das tun sie nämlich schon längst. Sie machen es mit diesen kleinen Tools ganz verschiedener Hersteller, mit denen sich schnell und bequem genau die Software erstellen lässt, die tut, was die Anwender gerade brauchen.
Warum dann überhaupt noch Handlungsbedarf besteht?
Weil diese Software wirklich nur genau tut, was sie soll, weil sie zumeist die Überdrüber-Einzelfall-Lösung ist, die für nichts anderes taugt und wahrlich Riesenprobleme macht, wenn sich, wie es nun mal ist bei Informationsverarbeitungen, die Anforderungen ändern und die Software ein bisschen anders reagieren soll. Weil diese Software letztendlich für jeden einzelnen Arbeitsplatz neu gebastelt werden muss, weil jeder einzelne Arbeitsplatz ein wenig andere Bedürfnisse hat, weil diese Software nicht nur ungünstig zu warten und zu pflegen ist, sondern auch nicht dazu gedacht wurde, mit anderen Software-Produkten zu interagieren – und weil manchmal auch die Power-User wechseln und dann jemand anderes das kleine Tool kennen muss, mit dem die Software gewartet werden soll. Wie oft gerät in solch einem Fall eine heiß geliebte, praktische kleine Anwendung nur deshalb in Vergessenheit, weil der neue Amtsinhaber „selber etwas Besseres“ machen kann?
Würde eine solche Software nicht direkt in irgendeiner Toolsprache/-logik geschrieben, sondern mit den allgemeinen Hilfsmitteln und einer weithin bekannten Programmiersprache, dann wäre vielleicht der neue Amtsinhaber eher bereit, sich das Vorhandene einmal anzusehen?
Außerdem wird es die Zukunft sein, Software aus „allgemeineren“ Modellen zu erstellen und nicht mehr direkt aus den Programmiersprachen. Viele große Entwicklungsumgebungen bieten immer häufig MDA-Verfahren (model driven architecture), bei denen, wie bei meinem Kernel, einfach die Tatsache ausgenutzt wird, dass die üblichen Lösungen zumeist recht ähnlich sind und sich durch Metadaten steuern lassen, sodass es genügt, diese Metadaten im Modell zu bestimmen und dann die „vorgefertigten Programmteile“ oder auch „Cartridges“, wie es manchmal heißt, an den individuell modellierten Teil anzudocken und somit sofort ein Stück fertige Software zu besitzen. Dann muss nämlich „nur“ noch der individuell modellierte Teil in Programmiercode umgesetzt werden.
Was eben noch keines dieser Systeme besitzt, ist die Erstellung des Modells aus verbalen Vorgaben heraus, sodass auch die bisherige Modellierung IT-Experten verbleibt.
Die Aufgabenstellungen aber kommen immer noch von den Auftraggebern, sie erklären uns, was sie wollen, wie sie es wollen und wozu sie es wollen – in Worten. Sind diese Worte nun in sich konsequent und schlüssig, dann lassen sie sich mithilfe der ML-Methode in ein Objektmodell umsetzen, das funktioniert schon. Was also nun gebraucht wird, ist noch die Übertragung dieses Modells in ausführbahren Code, der mit „mighty classes“ zur fertigen Software führt.
Gefällt das Ergebnis nicht, wird dann das ML-Modell solange geändert, bis das Ergebnis zufrieden stellt.
Damit lässt sich das Projekt differenzieren gemäß den folgenden Schritte für eine Software-Erstellung:
1. Erstellung der verbalen Vorgabe mit Worten der Auftraggeber, knapp, präzise und konsequent – und nicht zu detailverliebt.
2. Erstellen des ML-Modells aus den verbalen Vorgabe
3. Erstellen des Ruby-Codes aus dem ML-Modell
4. Erstellen der Metadaten für die „fertigen Programmteile“ (MDA)
5. Test
Warum ich es tue?
Weil es meiner ganz persönlichen Meinung nach die einzige Chance ist, Arbeitsplätze in Deutschland zu retten. Wieso?
Weil es die ganze IT-Industrie ändern wird – ...
wie sich bereits (24.07.2007) gezeigt hat, ist diese Veränderung voll im Gange: Open Source verändert die IT-Welt, das Internet mit den Web-Services schenkte Unabhängigkeit, SOA (mein „Kernel“ in luxuriösem Gewand) erobert die Industrie, Ubuntu wird zu Microsofts Albtraum...
doch immer noch ist die „Orchestrierung“ der SOA und ja, simple Software-Erstellung ein Thema ...
während im Moment die IT freilich wieder gute Geschäftsaussichten hat, ist das Problem der Unterschätzung der Programmiertätigkeit immer noch vorhanden. Immer noch denken Menschen, dass die Ausarbeitung von Software etwas ist, was sich billig nach Indien und China geben lässt, auch wenn sich bereits sehr nachdrücklich zeigt, was geschieht, wenn Know How so bereitwillig verschenkt wird. Denn eines muss klar sein: wer die Arbeit macht, lernt sie kennen. Wir schaffen uns mit Outsourcing somit nicht nur einen Mangel an Kompetenz im eigenen Lande, wir schaffen uns auch noch mächtige Konkurrenz - und zahlen noch dafür!
Nicht nur diese Branche hechelt doch immer noch dem modernen amerikanischen Modell (the winner takes it all) in einem geradezu erbärmlichen Maße nach, als hätten deutsche Ingenieure nicht ihre eigenen, probaten und über inzwischen mehr als einem Jahrhundert als nützlich bewiesenen Vorzüge!
Eine solch lange und erfolgreiche Überlebensfähigkeit muss das moderne amerikanische Modell erst noch beweisen.
Sind wir einmal ehrlich: Alles, was deutsche Manager im Augenblick so hörig-gläubig vom amerikanischen Großindustriellen übernehmen – wie Offshoring, Mitarbeiter-Downsizing und Ablehnung jeder sozialen Verantwortung, was Anstand und Ehrlichkeit zur Dummheit verkommen lässt – hat sich nicht wirklich bewährt. Nach den „goldenen 90ern“ brach dieses System bereits in sich zusammen, die letzten Jahre davon nur gehalten durch Lug und Betrug (Stichwort Enron), bloß um noch schneller Arbeitsplätze zu verlieren. Zurück in den Schuldenturm und die Leibeigenschaft des Mittelalters = Rettung der Wirtschaft?
Wer soll auf Dauer denn noch den schwachsinnigen Luxus à la USA kaufen, wenn sogar die teuren White-Collars nach China und Indien gehen?
Und wie heißt es bei Offshoring-Projekten so schön? Be careful what you wish for. You just might get it.
Bei Projekten in Asien heißt es, genau zu sagen und zu kontrollieren, was geschieht, weil die Leute dort hoch qualifiziert sind, freilich gewöhnt, sich gegenüber den Obrigkeiten als nicht zu kritisch zu erweisen: die Vorzüge eines alten, streng stabshierarchisch organisierten Führungsstils.
So macht man aber keine gute IT – ist ein bisschen wie bei der universitären Forschung. Wenn das Projekt in seinen bindenden Umrissen bekannt ist, dann lässt es sich in abgeschlossenen Befehlsketten gut handhaben, wo freilich gelernt werden muss, braucht es die Offenheit der Intelligenz. Dies wird nicht nur wunderbar von Mutter Natur am menschlichen Großhirn demonstriert (man denke nur an die ersten 10 Jahre der Kindheitsentwicklung), es ist inzwischen auch bekanntes Ergebnis der Wissenschaft: Dummheit zahlt sich in unveränderlichen Umgebungen aus, Intelligenz in veränderlichen.
Was das mit meinem Projekt zu tun hat?
Die „Orchestrierung“, wie der Fachjargon inzwischen heißt, ist immer noch etwas, was viel Sachverstand braucht - aber vor allem doch Sachverstand über das, was eine Software tun soll, nicht wie sie es tun soll. Nicht umsonst ist Excel wohl die meistgenutzte „Software-Entwicklungsumgebung“ in Firmen.
Wie viele Software-Statements in all diesen diversen kleinen Tools dienen dazu, die Bedürfnisse „vor Ort“ zu befriedigen, die die großen Monolithen der Software zwar versprechen, freilich niemals halten - und wenn, dann so unhandlich, dass es keiner nutzen mag, der unter Druck steht, etwas zu erledigen und (sind wir ehrlich) ganz andere Probleme zu bewältigen hat als die technikverliebten Details irgendeines Softwaresystems zu beherrschen, das weitaus mehr von sich selbst hält als von den „unprofessionellen“ Kunden.
Oder mit anderen Worten – wer diesen cleveren, arbeitswilligen und kompromissbereiten Experten eine Möglichkeit gibt, sich einfache, aber vernünftige Software aus der eigenen Erfahrungswelt heraus zu erstellen, der wird nicht nur diese Experten in ihrem Job unterstützen (und deshalb den Job in Deutschland effektiv und profitabel halten), der wird auch selbst immer wieder (vor Ort) nachgefragt werden. Ja sicher werden die Kernel-Bestandteile, die „Cartridges“ oder wie man sonst die fertigen Programmteile nennen will, in China oder Indien gebaut, weil sich dort der Arbeitslohn fast auf Sklavenniveau bewegt, was dann aber die eigentliche Wertschöpfung ausmacht, die Kombination und Anordnung dieser als Sackgassenkomponenten konzipierten, hochverfügbaren Programmbausteine - das wird vor Ort geschehen müssen.
Solange die Arbeit noch vor Ort ist, natürlich.
(Nachtrag: In CW 14/2004, S. 42, „Offshore-Projekte langfristig planen“ beschreibt der Autor Edwin Schumacher auch die modernen Ansätze, Anwendungsentwicklung (Stichwort MDPB) zu automatisieren, und dadurch den negativen Auswirkungen des Outsourcings – und letztendlich auch dem Outsourcing selbst – zu entgehen. Pass'd scho'...
MDPB heißt übrigens model-driven pattern-based development – so hätte ich mein Projekt natürlich auch beschreiben können, vor allem, wenn du weißt, dass die design patterns per Best Practices direkt in Code umgesetzt werden!)
Erläuterungen
06.02.2004: Komplexe Komponenten versus Sackgassen
Zur Klarstellung: die „fertigen Programmteile“ sollen wirklich „fertig“ sein. Es sollen fertige Fenster, fertige Drucke, fertige Websites, fertige Messaging-Systeme, fertige WasWeißIchNoch sein, ganz das schöne, kleine, praktische Beispiel eines Druckaufrufes. Hier bietet dir das Betriebssystem ein Fenster an, bei dem du Drucker auswählen und Kopien bestimmen kannst, es erfolgt nur ein Aufruf des Fensters und eine Abfrage seines Ergebnisses im Programm, absolut easy und alltäglich.
Ein solches Fenster ist nichts weiter als eine praktisch verwendbare Komponente. Der Unterschied zu meinen „fertigen Programmteilen“ ist im Grunde nur, dass diese hier „Sackgassenkomponenten“ sind. Sackgassen sind verwendbar wie Variable, überall, beliebig, bedenkenlos, problemlos.
Warum?
Weil sie situationsunabhängig sind, wunderschön erkennbar daran, dass sie beispielsweise vom Betriebssystem gestellt werden. Das offeriert uns zwar eine mächtige Umgebung, freilich eine, die für all die vielen Millionen User in Amerika, China, Deutschland und der Elfenbeinküste (praktisch) gleich ist – kann mit unserem Problem also gar nichts zu tun haben.
Eine komplexe Komponente ist dagegen keinesfalls mehr als Variable einsetzbar – sie ist, in meinem Sprachgebrauch (ML-Methode) ein „Handlungsträger“, eine Rolle, die sehr direkt nicht nur mit unserem Problem zu tun hat, sondern ein ganz spezifischen Teil davon ist.
03.02.2003: „Und das ist das, was der Begriff ‚Rolle’ kennzeichnet: eine Kombination von Anfangszustand und Regel.“
Eine komplexe Komponente ist deshalb aktiver, unverzichtbarer Bestandteil des Programmes, bei der es sehr wohl einen Unterschied macht, wo und wann sie aktiviert wird. Genau das ist das Problem bei ESA, das den Software-Giganten ziemlich bald dämmern wird: Müssen sich deine Programmierer nicht mehr um Kleinvieh kümmern, haben sie auch keine Ausreden mehr. Dann müssen sie unbedingt den Überblick über das gesamte (Teil-)System haben, um diese komplexen Komponenten zu einen vernünftigen, effizienten Zusammenspiel zu bewegen. Denn komplexe Komponenten sind ausgelegt wie die autarken Objekte der Biologie: Sie erhalten einen Auftrag (in der Biologie schlicht „überleben“) und haben ihren Möglichkeiten gemäß diesem Auftrag selbständig auszuführen. Da ist keine Programmierung, keine Arbeit mehr nötig, höchstens an ein paar klar bestimmten API’s für die individuelle Ausprägung.
Genau diese Form komplexer Komponenten habe ich bereits in meinen Kernelsystemen vorliegen, es funktioniert prächtig – solange das Problem klar umrissen ist.
Das ist nämlich jetzt nicht mehr zu verdrängen: Zu wissen, was du tust, deine Aufgabe so deutlich zu machen, dass du deine komplexen Komponenten nicht nur mit konkreten Vorgaben füttern kannst, sondern sie auch zu einem effektiven System „komponierst“, das ist und bleibt unabdingbare Voraussetzung für jegliche Problemlösung, mit und ohne Software.
Nun ja, das erledigt die ML-Methode bereits, wenn du wenigstens deine Aufgabe so gut verstanden hast, dass du sie sauber in Worten beschreiben kannst – Information ist schließlich Physik und Physik ist berechenbar, muss nicht „aus dem Bauch heraus“ beschrieben werden und keiner „herrschenden Meinung“ folgen. Die Software-Giganten kennen sie zwar nicht, die Design Patterns werden sich jedoch genau in diese Richtung entwickeln: Best Practices führen auch zur besten Lösung, wie Mutter Natur beweist, die nichts weiter als dieses evolutionäre Verfahren hat, um „form follows function“ (optimale Lösungen) zu demonstrieren. Warum es beste Lösungen gibt? Weil Information Wirkung ist und damit dem Prinzip der geringsten Wirkung folgt.
Und was Punkt 4 meines Projektes nun eigentlich heißt, ist nichts weiter als: Bestimme das Interface für den Kernel.
Was ich (natürlich) nicht einfach für eine komplexe Komponente „Fenster“ oder „Listendruck“ oder „Website“ als Einzelfall machen möchte, sondern (natürlich) so typisieren, dass die Grundstruktur des Interfaces auch für alle anderen „Fertigbausteine“ taugt.
Meine Bewunderung gilt dabei Mutter Natur: Sie hat mit einer Handvoll Sinne uns dazu ausgerüstet, in unserer Welt zu leben.
Das nenne ich eine „schlanke Schnittstelle“.
SOA!
Das ist mein neues Zauberwort – das ist mein Kernel, endlich ein vernünftiger Fachausdruck, der mich nicht sofort in die Laienschublade stopft.
„Service-Oriented Solutions… Applications must be developed as independent sets of interacting services offering well-defined interfaces to their potential users“
Klingt das nicht genau wie: „Denn komplexe Komponenten sind ausgelegt wie die autarken Objekte der Biologie: Sie erhalten einen Auftrag (in der Biologie schlicht „überleben“) und haben ihren Möglichkeiten gemäß diesem Auftrag selbständig auszuführen“ (s.o).
Anderes Eigenzitat vom 30.01.2004: „Moderne Prozessorientierung hat diese Struktur aufgebrochen. Die angesprochene Infrastrukturplattform erlaubt zwar den Anwendern und/oder anderen Programmen, Prozesse anzustoßen, doch die Steuerung liegt hier auf einer wesentlich höheren Ebene. Die Infrastrukturplattform hat keinerlei Rechte und Befugnisse mehr, sich in die Arbeitsweise der angestoßenen Objekte einzumischen, nicht einmal in den Verlauf des gesamten Prozesses. Sie kontrolliert nur, was sie selbst aufruft: die erste Ebene. Diese erste Ebene muss dann selbst wissen, was als nächstes kommt und was sie aufrufen und kontrollieren muss ... Das Problem, das in dieser Art der Struktur ist, wird sich aber ganz, ganz schnell auch den Riesen der Software-Industrie offenbaren: Irgendwas oder irgendwer muss den Prozess gewährleisten. Wenn du eine solch „liberale“ Art hast, autonome Objekte zu einer Arbeit zu bewegen, musst du umdenken. Da nützt das heutige Bossdenken mit strengen hierarchischen Befehlsketten nicht viel, einfach weil du gar nicht weißt, welche Objekte an deinem ganz individuellen Einzelfall-Prozess wie aktiv werden müssen - du musst anfangen, wirklich in Kosten und Ertrag zu denken wie Mutter Natur und deine Objekte sehen wie Menschen in einer gemeinsamen Kultur, du musst deine Ziele in die Objekte pflanzen wie Mutter Natur das Lustprinzip in ihre Objekte pflanzte. Weil das Objekt letztendlich die Kontrolle über seine spezifischen internen Arbeitsvorgänge hat und niemand sonst.“
„Similarly, supporting technology must be available to allow application developers to browse collections of services, select those of interest, and assemble them to create the desired functionality.“ (A. Brown, Large-Scale, Component-Based Development, Prentice Hall, 2000)
Genau das habe ich vor: Das ist die beste aller Projektbeschreibungen, das werde ich umgehend oben einfügen (auch wenn ich das nachträgliche Einfügen sonst nicht leiden mag aus Gründen der Nachvollziehbarkeit).
Die Quelle ist ein WhitePaper von Rational/IBM („Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications“ by Alan Brown, Simon Johnston, Kevin Kelly, © All rights reserved, Quelle 11.02.2004, 629 KB) - und wenn es auch nicht „tief“ genug geht, um mein Kernel-Konzept zu erklären, so sind die Ähnlichkeiten unverkennbar:
„Coarse-grained — Operations on services are frequently implemented to encompass more functionality and operate on larger data sets, compared with component-interface design.“
Meine „Fachausdrücke“ waren hierzu „komplexe Komponente“ und „Sackgasse“.
„Interface-based design — Services implement separately defined interfaces. The benefit of this is that multiple services can implement a common interface and a service can implement multiple interfaces.“
Meine Worte: „Der Witz ist, dass die Schnittstelle nach den Systemanforderungen normiert sein muss oder wenigstens einen normierten Part haben muss.“
„Discoverable — Services need to be found at both design time and run time, not only by unique identity but also by interface identity and by service kind.“
Das habe ich nie so klar ausgedrückt, fällt mir jetzt auf: Ist aber ein Grund für die strenge Standardisierung von Namen, die ich meinen „komplexen Instanzen“ gebe, weil dies nämlich die Wiederauffindbarkeit garantiert („also ein „Objekt“, das „der Rede wert“ ist, einen eigenen, die Metadaten bestimmenden Namen aufweist“)
„Single instance — Unlike component-based development, which instantiates components as needed, each service is a single, always running instance that a number of clients communicate with.“
Das sind nicht ganz meine Fenster, doch einwandfrei meine System- und Dateitasks, ein Teil meiner komplexen Instanzen, die permanent im Hintergrund warten, um Befehle auszuführen.
„Loosely coupled — Services are connected to other services and clients using standard, dependency-reducing, decoupled message-based methods such as XML document exchanges.“
Ja, das ist unabdingbar, willst du ein System komplexer Komponenten mit hoher Austauschbarkeit der einzelnen Subsysteme ermöglichen, Stichwort „Lustprinzip“ – und es schafft Probleme bei der „Traktierbarkeit“. Wer am Ende einer Kette von Clients das Endergebnis tatsächlich verwenden will, ist innerhalb der Kette dann einfach nicht immer zu erkennen.
„Asynchronous — In general, services use an asynchronous message passing approach; however, this is not required. In fact, many services will use synchronous message passing at times.“
Hmmm – das habe ich nur bei Fensterkommunikationen berücksichtigt, denn dort geht es gar nicht anders. Warum? Weil eben Anwender alles mögliche machen dürfen und nicht immer genau das tun, was Programmierer sich so denken.
19.03.2004: The Theory of Comprehension and Problem Solving
Aus „Cognitive Support Features for Software
Development Tools“, DISSERTATION
(Zip-Version
501 KB), submitted in partial satisfaction of the requirements
for the degree of DOCTOR OF PHILOSOPHY in Information and Computer
Science by Jason Elliot Robbins, UNIVERSITY OF CALIFORNIA, IRVINE,
1999,
Theories of Designers' Cognitive Needs, Design Visualization
Theories:
„The theory of comprehension and problem solving observes that designers must bridge a gap between their mental model of the problem or situation and the formal model of a solution or system (Kintsch and Greeno, 1985; Fischer, 1987). The situation model consists of designers' background knowledge and problem-solving strategies related to the current problem or design situation. The system model consists of designers' knowledge of an appropriate formal description. Problem solving or design proceeds through successive refinements of the mapping between elements in the design situation and elements in the formal description. Successive refinements are equated with increased comprehension, hence the name of the theory.
In the domain of software development, designers must map a problem design situation onto a formal specification or programming language (Pennington, 1987; Soloway and Ehrlich, 1984). In this domain, the situation model consists of knowledge of the application domain and programming plans or design strategies for mapping appropriate elements of the domain into a formal description. The system model consists of knowledge of the specification or programming language's syntax and semantics. Programming plans or design strategies enable designers to successively decompose the design situation, identify essential elements and relationships, and compose these elements and relationships into elements of a solution. At successive steps, designers can acquire new information about the situation model or about the system model.“
Sieht so aus, als wäre ArgoUML genau die richtige Plattform für die Umsetzung der ML-Methode in UML. Denn genau dies hier beschreibt – endlich mal in „professionellen Worten“ -, was die ML-Methode tut: Sie nimmt Begriffe und Beschreibungen, die aus der verbalen Darstellung der Aufgabe resultieren, setzt sie zueinander in Beziehung und erstellt daraus Objekte mit öffentlichen Methoden und deren Verbindungen.
Begriffe und Beschreibungen = „consists of knowledge of the application domain“
Objekte mit öffentlichen Methoden/Verbindungen = „a formal description“
ML-Methode, basierend auf der Definition der Information = „programming plans or design strategies for mapping appropriate elements of the domain into a formal description“
„Pennington observed that programmers benefited from multiple representations of their problem and iterative solutions“
Je unterschiedlicher die Darstellungen, umso höher die Wahrscheinlichkeit, fehlende (binäre) Verbindungen zwischen Elementen (Begriffen) aufzudecken. (Wende ich übrigens – nicht nur hier – an, um die Definition der Information oder die ML-Methode mit „gängigen“ Worten alias Darstellungen immer wieder in anderem verbalen Kleid zu offerieren, bis endlich der Groschen trotz der Blockaden fällt.)
Die ML-Methode geht hier einen anderen Weg – umgekehrt. Aus den Begriffen und Beschreibungen ermittelt sie sich eine Repräsentation des Problems, die den strukturellen Anforderungen Genüge tut. Da sie außer der Kenntnis über Information und der effizienten Bauweise einer Informationsverarbeitung kein weiteres Wissen implantiert hat, kann sie auch keine inhaltlichen Elemente verwerten: Die Lösung, die die ML-Methode anbietet, erfüllt zwar die Voraussetzungen für eine optimale Lösung hinsichtlich der Konstruktion, nicht jedoch unbedingt auch hinsichtlich der inhaltlichen Voraussetzungen, denn das Optimum des Szenariengewichts ist leider nicht das, was mathematisch als „hinreichend“ bezeichnet wird, es ist nur „notwendig“.
Aber – sie bietet eine Lösung an, die Schritt für Schritt auf einfachster Ebene überprüft werden kann: Es müssen nur zwei Begriffe betrachtet werden, logisch noch ganz innerhalb der „application domain“, und dann muss gefragt werden, ob ihre direkte Abhängigkeit tatsächlich in der vorgeschlagenen Reihenfolge gegeben ist. Erfahrungsgemäß zeigt alleine diese Kontrolle einfacher Verknüpfung sehr schnell ebenfalls fehlendes Wissen und Widersprüche auf, die durch weitere Interviews geklärt werden müssen, bis die vorhandene Beschreibung und resultierende Terminologie tatsächlich vollständig ist.
Doch trotz unterschiedlicher Hilfestellung bei der Gewinnung der Lösung: Wenn ArgoUML die Analyse durch viele Darstellungsformen unterstützt, muss es einen sehr typisierten Zugang zu den Daten haben. Das muss sich verwenden lassen, schätze ich.
BTW: Der große Unterschied zwischen den bisherigen „programming plans or design strategies for mapping appropriate elements of the domain into a formal description“ gegenüber der ML?
Die ML funktioniert automatisch – nur die Begriffserstellung einerseits und die Kontrolle der Lösung andererseits erfordern menschliches „knowledge of the application domain“.
SOA ist zum heißen Thema geworden, scheint’s mir – wird sicher eines der neuen Schlagworte, mit denen die Schriftgelehrtenwissenschaft IT nachweisen will, wie fortschrittlich sie ist. Doch wie schreibt die Computerwoche (20/2004, S. 37): die Idee hieß früher mal Componentware.
Und genau hier stammt die Ähnlichkeit zu meinem Kernel her, wenn auch nicht in den technischen Details, die bei SOA wirklich hoch erfreulich modern sind. Denn mein Kernel war konstruiert, um „komplexe Komponenten“, wie ich es im Gegensatz zu Sackgassenkomponenten nannte, zu handhaben.
Hier stammt dann auch die zwischen meinem Kernel und der SOA-Architekur übereinstimmende Eigenschaft her, extrem schnittstellenorientiert zu sein, um einen Verbund von lauffähigen „Kleinprogrammen“ zu einem funktionierenden System zusammenzukoppeln. Weil nicht nur einfach das aktuelle Problem gelöst werden sollte, sondern das auch korrekt, planmäßig und qualitativ hochwertig erfolgen sollte - und vor allem, weil es wartbar und veränderbar sein musste: form follows function, „das Problem sucht sich seine Lösung, ein schönes Indiz für die Erkenntnis vieler Programmierer, dass es „beste Lösungen“ gibt, auch wenn alle Lösungen in der Mathematik gleichwertig sind – nicht aber in der Physik, wo es das Variationsprinzip „geringste Wirkung“ gibt.“
Eine weitere interessante Folgerung, die ich aus meinem Kernel schloss, wird auch angesprochen - und sogar in zwei Facetten.
Die Analyse des Problemgebietes rückt in den Vordergrund.
Die durch Schnittstellen und Teillösungen in Form standardisierter Prozesse geprägte SOA erlaubt/erzwingt eine Entwicklung, die sich diese Schnittstellen/Prozesse wieder und wieder zunutze macht, was zu Modellierungswerkzeugen und MDA mit dem so genannten Roundtrip führt: Die Erstellung und auch Wartung von Code via Modell mit sogar der Fähigkeit, veränderten Code wieder zurück in das Modell einfließen zu lassen.
Die zweite Facette, die Analyse als Abbildung des Problemgebietes auf eine effiziente Lösung, wird eher indirekt angesprochen: Nur „erfahrene Programmierer“ würden sich für die Modellierung eignen.
Was aber bedeutet „erfahren“? Es bedeutet, dass sie die Abhängigkeiten und Wirkungsketten von Programmen in einer spezifischen Realisierung, mit definierter Programmiersprache und Betriebssystemumgebung, gut kennen und ein Gefühl für Wechselwirkungen entwickelt haben.
Genau das also, was meine ML-Methode leistet. Sie entstand letztendlich aus exakt dem Grund: Weil ich gerade im Zusammenhang mit dem Kernel feststellte, dass die Vielschichtigkeit einer solchen Architektur, die extreme Orientierung auf Schnittstellen und Messages (Kommunikation) von vielen Programmierern nicht verstanden wurde, die im schlimmsten Fall sogar kontraproduktiv mit Aggression und Ablehnung reagierten: Der Unterschied zwischen „aktiver und passiver“ Verarbeitung ist schließlich gewaltig. Deshalb hatte ich begonnen, mich nach einer automatischen Lösung umzusehen, denn „jedes Problem sucht sich seine Lösung“. So würde ich schlicht auf diese „Erfahrung“ verzichten können – und dann stünden mir sehr viel mehr Programmierer zur Verfügung, so dachte ich mir. Nun ja, die ML-Methode funktioniert – mein Organisations- und Verkaufstalent freilich nicht.
Darum auch mein Projekt hier – die ML-Methode muss noch effektiver werden, sie muss deshalb in den MDA-Prozess integriert werden, überzeugen zu können, dass Joseph Bertrand recht hatte: „Jede noch so unwesentliche Information verbessert messbar die Prognose.“
Und eine Information, die vielen fürchterlich unwesentlich erscheint, bringt hier besonders großen Nutzen: das Verständnis, was Information eigentlich ist – die Definition der Information.
19.05.2004: Verzeichnisse und andere Hinweise auf die Dreiecksstruktur oder die Anwendbarkeit der ML-Methode
Noch’n Artikel aus der Computerwoche (20/2004, S. 41), diesmal über die integrative Wirkung von Web-Services. Zwar seien die Web-Services „nur“ Schnittstellen, doch zusammen mit UDDI (Universal Description, Discovery and Intergration) und WSDL (Web Services Description Language) bilden sie eine SOA – eine serviceorientierte Architektur.
Verzeichnisse – überall tauchen sie auf, in der neuen Grid-Technologie, in den diversen Komponentenmodellen genauso wie im realen Leben als Telefonbuch oder Branchenverzeichnis. Denn was nützen die schönsten Schätze, wenn sie keiner finden kann? Sie müssen also auffindbar sein.
Und „auffindbar sein“ heißt nichts weiter „dem System zur Verfügung stehen“ – die einfachsten Varianten der Aufzählung sind dabei sicher der Wühlkorb und die irgendwie geartete lineare Sortierung. Erstere ist völlig nutzlos bei größeren „Sammlungen“, weil es nichts weiter als eine unstrukturierte Anhäufung irgendwelcher Elemente ist. Funktioniert solange, solange der Überblick gewährleistet ist – letztendlich ist jede größere Datenmenge immer in Gefahr, zum reinen Wühlkorb zu verkommen, wenn sie nicht sauber genug strukturiert ist, damit sie anhand dieser Strukturmerkmale auf „überschaubare“ Kleingruppen zusammengesucht werden kann (4fF-Methode). Die zweite Verzeichnisstruktur, die einfache Sortierung, ist freilich auch nicht viel besser. Egal, nach was sortiert wird, erreicht die Überschaubarkeit, die Voraussetzung jeder Auffindbarkeit, auch hier schnell ihre Grenzen.
Je genauer dagegen strukturiert wird, umso leichter lassen sich die gesuchten Schätze finden – deshalb sind die Menüstrukturen unserer Programme alle als „Treelist“ organisiert: Du unterteilst alles, was du anbietest in nur ein paar Gruppen, die dann immer tiefer aufgegliedert werden, wobei jede Untergruppe ebenfalls nicht zu groß werden darf, um übersichtlich zu bleiben. So lässt sich über allgemeine und immer weniger allgemeine Anforderungen an ein gesuchtes Element die unübersichtliche Masse im Angebot reduzieren auf ein paar, aus denen am Ende das Gewünschte ausgewählt werden kann – ohne dass zuvor wirklich allzu viel spezifisches Wissen erforderlich gewesen wäre.
Und das ist die Dreiecksstruktur der Fliege: 1 Oberelement, gerne auch „Root“ genannt, fächert sich hierarchisch auf in Untergruppen/Elemente fächert sich hierarchisch auf in Untergruppen/Elemente fächert sich hierarchisch auf in Untergruppen/Elemente .... – 1 Eingang, viele Ausgänge: Dreiecksform.
Jede solche Treelist/Baum-/Menüstruktur lässt sich deshalb mit der ML-Methode so organisieren, dass am Ende die durchschnittlich kürzesten Suchwege im Angebot stehen.
Und dabei ist es völlig gleichgültig, ob diese Hierarchie eine Arbeitsorganisation ist und die ML-Methode dazu dient, Organigramme zu erstellen, oder eine Menü-Struktur, und die ML-Methode dazu dient, die sachlich angepassteste Struktur zu finden – oder eben eine SOA, die über Verzeichnisse auch immer in eine Dreiecksform gepresst wird.
Egal, wie „multidimensional“ die Programmierer denken können – sollen autarke Objekte effektiv miteinander kooperieren, müssen sie irgendwo eine zentrale Einheit aufweisen, die Entscheidungen für alle treffen kann, die Übersichten für alle bietet, die Rahmenbedingungen für alle offeriert: die Dreiecksform.
Das menschliche Gehirn führt doch bestens vor, dass sogar ein Multimilliarden-Teilnehmer-Projekt (oder wie viele Zellen erbauen den menschlichen Körper?) in solchen gestuften Hierarchien mit einer Zentralsteuerung funktionieren kann. Hätte es eine multidimensionale Lösung gegeben für effiziente Informationsverarbeitungen, hätte diese Erde sicher ein Biotop dafür gefunden.
Anmerkung: Was keineswegs ausschließt, dass auf Objektebene ein mehrdimensionales Vorgehen das effektivste sein kann, genauso wie Schleifen in der Gesamtstruktur nicht auftreten dürfen, die im Objekt freilich unersetzlich sind.
Kleine Nebenbemerkung: Die SOA-Architektur aus WSDL, SOAP und UDDI weist jedoch via UDDI nicht nur auf die Dreiecksform als effizienteste Struktur einer Informationsverarbeitung hin, sie weist auch direkt auf die Natur der Information als Regelwerk hin, das sich über definierte Zustände fixieren lässt. WSDL ist dabei die Repräsentation des Regelwerks, SOAP die Repräsentation definierter Zustände sprich identifizierbarer Objekte.
Für genau diese dynamische Dreiecksform, die „Fliege“, die sich aus der Notwendigkeit kooperierender Sub-Informationsverarbeitungen zu einem effizienten Gesamtsystem ergab, ist die ML-Methode geschaffen, sie eignet sich deshalb zweifelsfrei für das Projekt, aus verbalen Vorgaben eine vernünftige UML- und dann SOA-Struktur zu erzeugen.
Und das wissen bereits viele Menschen schon intuitiv – sonst hätten sie nicht den Vergleich des Orchesters oder des Tanzes für diese Problematik herangezogen, bei der ein Dirigent oder Choreograph die Zusammenarbeit der Individuen zu einem harmonischen Ganzen „komponiert“: Das Problem wurde im obigen Artikel als „Orchestrierung“ beschrieben, eine der Gruppen, die sich damit beschäftigen, nahm „Choreography“ in ihren Namen auf – und das Resultat der vielen Einzelteile zum Ganzen wurde mit „transaktionaler Klammerung“ bezeichnet.
Wobei den Web-Services Dank zu leisten ist dafür, dass sie „die Gestaltbarkeit“ solch inhomogener Einzelteile zu einem Gesamtsystem überhaupt erst demonstrieren. Es geht also – solange du dich an die Bedingungen hältst, die dir Information auferlegt.
24.07.2007: Neue Arbeitsumgebung - Anpassung Projekt
Lautete die Anforderung an die Entwicklungsumgebung anfangs noch:
Das Projekt soll mithilfe von Eclipse (© Copyright IBM Corp. and others 2000, 2003. All rights reserved) und Java (© Sun-Markenzeichen) als Entwicklungsumgebung und – bis jetzt noch – ArgoUML als Grundstock des Modell-Erstellungsteils durchgeführt werden. (Zu den Rechten: 1. UML ist eine Notation, die von einem Konsortium gepflegt wird, OMG oder UML 2 Working Group, 2. ArgoUML: http://argouml.tigris.org/: “ArgoUML is not only a free UML modelling tool, it is also an Open Source Development project where you are invited to contribute“.)
Doch weder liegen bisher “praktische Erfahrungen” mit Eclipse vor, noch mit Java oder UML oder gar ArgoUML, nicht mal angefragt wurde bisher dort.
Wer freilich Studio kennen gelernt hat, denkt meistens auch nicht, dass es sich ohne fremde Hilfe erlernen lässt – ich habe das, mit vorzeigbarem Ergebnis. Ich habe da keinerlei Bedenken, dass ich das Projekt, wenigstens im ersten Teil in vertretbarer Zeit, auch erfolgreich beenden kann.
so wurde bereits auf den gewaltigen Java-Überbau verzichtet - nachdem ein Einführungsprojekt in Ruby On Rails zeigte, wie mächtig und dabei bequem Sprache und Framework sind, soll das Projekt also auf dieser Grundlage erstellt werden.
(Nachtrag: Studio ist die Kurzfassung für Omnis Studio)
Was nun soll „Die ‚offene’ Entwicklung eines Kernel-Konzepts von Grund auf: Von der Analyse der Problemstellung ausgehend von den verbalen Vorgaben der Auftraggeber zu einem ersten logischen Grobkonzept mithilfe der ML-Methode über ein UML-Modell zum lauffähigen Programm a la „Model Driven Architecture“ unter Ausnutzung von Kernel-Strukturen“ eigentlich bedeuten?
Kurz und unpräzise (der kurz-und-präzise-Part ist am Ende von „Projekt“ aufgeführt):
Es soll ein Produkt geschaffen werden, das mit einem Blatt Papier gefüttert wird und mit ein paar ganz einfachen Fragen und vielleicht noch einfachsten, allereinfachsten Programmierkenntnissen eine lauffähige, erweiterbare und bequem zu wartende Software schafft.
Wozu?
Ein solches Produkt könnte von den Power-Usern, den Anwendern mit „nur“ praktischen IT-Kenntnissen, genutzt werden, Software zu erstellen. Das tun sie nämlich schon längst. Sie machen es mit diesen kleinen Tools ganz verschiedener Hersteller, mit denen sich schnell und bequem genau die Software erstellen lässt, die tut, was die Anwender gerade brauchen.
Warum dann überhaupt noch Handlungsbedarf besteht?
Weil diese Software wirklich nur genau tut, was sie soll, weil sie zumeist die Überdrüber-Einzelfall-Lösung ist, die für nichts anderes taugt und wahrlich Riesenprobleme macht, wenn sich, wie es nun mal ist bei Informationsverarbeitungen, die Anforderungen ändern und die Software ein bisschen anders reagieren soll. Weil diese Software letztendlich für jeden einzelnen Arbeitsplatz neu gebastelt werden muss, weil jeder einzelne Arbeitsplatz ein wenig andere Bedürfnisse hat, weil diese Software nicht nur ungünstig zu warten und zu pflegen ist, sondern auch nicht dazu gedacht wurde, mit anderen Software-Produkten zu interagieren – und weil manchmal auch die Power-User wechseln und dann jemand anderes das kleine Tool kennen muss, mit dem die Software gewartet werden soll. Wie oft gerät in solch einem Fall eine heiß geliebte, praktische kleine Anwendung nur deshalb in Vergessenheit, weil der neue Amtsinhaber „selber etwas Besseres“ machen kann?
Würde eine solche Software nicht direkt in irgendeiner Toolsprache/-logik geschrieben, sondern mit den allgemeinen Hilfsmitteln von UML und einer weithin bekannten Programmiersprache, dann wäre vielleicht der neue Amtsinhaber eher bereit, sich das Vorhandene einmal anzusehen?
Außerdem wird es die Zukunft sein, Software aus „allgemeineren“ Modellen zu erstellen und nicht mehr direkt aus den Programmiersprachen. Viele große Entwicklungsumgebungen bieten immer häufig MDA-Verfahren (model driven architecture), bei denen, wie bei meinem Kernel, einfach die Tatsache ausgenutzt wird, dass die üblichen Lösungen zumeist recht ähnlich sind und sich durch Metadaten steuern lassen, sodass es genügt, diese Metadaten im Modell zu bestimmen und dann die „vorgefertigten Programmteile“ oder auch „Cartridges“, wie es manchmal heißt, an den individuell modellierten Teil anzudocken und somit sofort ein Stück fertige Software zu besitzen. Dann muss nämlich „nur“ noch der individuell modellierte Teil in Programmiercode umgesetzt werden – und das tun bereits viele Produkte, auch ArgoUML.
Was eben noch keines dieser Systeme besitzt, ist die Erstellung des Modells aus verbalen Vorgaben heraus, sodass auch die bisherige Modellierung IT-Experten verbleibt.
Die Aufgabenstellungen aber kommen immer noch von den Auftraggebern, sie erklären uns, was sie wollen, wie sie es wollen und wozu sie es wollen – in Worten. Sind diese Worte nun in sich konsequent und schlüssig, dann lassen sie sich mithilfe der ML-Methode in ein Objektmodell umsetzen, das funktioniert schon. Was also nun gebraucht wird, ist noch die Übertragung dieses Modells in UML, das dann via gängigen Produkten in Java-Code (© s.o.) umgesetzt werden kann und mit „mighty classes“ zur fertigen Software führt, die sich dann richtig ausführen und damit demonstrieren lässt.
Gefällt das Ergebnis nicht, wird dann das ML-Modell solange geändert, bis das Ergebnis zufrieden stellt. Vielleicht werden auch Änderungen am UML-Modell nötig sein, das deshalb mit den Berechnungen der ML-Methode ausgerüstet werden muss, um die nützlichen Hinweise der ML-Methode auch dort den „programmierenden Anwendern“ anzubieten.
Damit lässt sich das Projekt differenzieren gemäß den folgenden Schritte für eine Software-Erstellung:
1. Erstellung der verbalen Vorgabe mit Worten der Auftraggeber, knapp, präzise und konsequent – und nicht zu detailverliebt.
2. Erstellen des ML-Modells aus den verbalen Vorgabe
3. Erstellen des UML-Modells aus dem ML-Modell
4. Erstellen des Java-Codes (© s.o.) aus dem UML-Modell
5. Erstellen der Metadaten für die „fertigen Programmteile“ (MDA)
6. Test, ggf. Iteration ab 2/3
Klingt richtig einfach, nicht wahr? Schon komisch, dass noch nicht einmal die großen amerikanischen Wunderfirmen so etwas Einfaches bisher gemacht haben! Ganz ehrlich, sie sind aber jetzt dabei, es zu tun. Denn was gerade im Jahr 2003 an IT-Geschichte so interessant war, ist, dass all die berühmten Namen, die Schritt 4 als Produkt erfolgreich anbieten, von den Größten der Branche aufgekauft wurden – ein „Firmenkauf sagt mehr als 1000 Worte“.
Ein weiterer Teil dieser Schritte steht bereits ganz real zur Verfügung: Schritt 2 existiert (als Produkt) für kleine Softwareprobleme (ca. 10 Dateien max) und auch MDA-Verfahren liegen marktreif vor. Doch natürlich möchte ich meine Kernel-Logik anbinden und keine fremden Produkte.
Diese Kernel-Logik arbeite ich gerade an meinem kleinen Studio-Projekt „Zeitfresser“ aus. „Zeitfresser“ soll eine einfache und hochsteuerbare kleine Arbeitserfassung sein, deren Hauptgewicht jedoch nicht auf Kundenabrechnung steht, sondern auf der Bestimmung der gesamten Tätigkeiten, die bei irgendeinem Job anfallen. Besonders der Anteil der „Kleinigkeiten“ soll damit wenigstens grob bestimmt werden, denn nicht der volle Umfang an Information pro Arbeitsschritt steht im Vordergrund, sondern der möglichst volle Umfang an Arbeitsschritten selbst. Soll heißen, dass es wichtiger ist, bei einem Telefonat schnell den Button „Telefon“ zu drücken, als genau zu beschreiben, was denn bei diesem Telefonat gesagt wurde. Das nächste Telefonat kann nämlich schon in der Leitung warten und muss auch erledigt werden! Das Problem bei den vielen kleinen Zeitfressern ist nämlich, dass sie einfach untergehen – und am Ende des Tages sagst du dann „was habe ich eigentlich gemacht“? Und vielleicht sagt das sogar dein Arbeitgeber, den du mit einer einfachen Liste dann überzeugen kannst, dass du nicht schläfst oder auf dem Internet herumspielst. Vielleicht hast du ja auch ein paar Minuten Zeit und trägst noch ein paar Erinnerungsfetzen nach – oder vielleicht war das Telefonat wichtiger, als du dachtest, dann protokollierst du sofort ordentlich, mit wem du gesprochen hast und worüber.
Naja gut, soviel zu dem Problem.
Dieses Projekt hat mir bereits folgende Konkretisierung gebracht:
zu 5:
Metadaten sind zu strukturieren nach Input/Logic/Output (huhu, kommt das jemand bekannt vor? Ja, ist derselbe Grundsatz wie beim ModelViewController-Konzept, weil eben Information zyklische Wirkung ist und damit messbar über Anfang, regelkonformen Verlauf und Ende: hat nichts mit menschlichem Genie zu tun, meine armen lieben Genies, einfach nur mit der „Natur“ der Information).
zu 1: ist generell nicht unsere Sache. Was jemand will, muss diese Person schon selbst wissen und uns sagen, so funktioniert menschliche Gesellschaft nun seit der Erfindung der Sprache. Solange kein Gehirn-Scanner existiert, wird den „wünschenden“ Personen auch nicht einmal teilweise erspart bleiben, ordentlich und genau genug zu beschreiben, was sie denn wollen. Wenn andere ihnen helfen sollen, müssen sie schließlich auch verstehen können, was zu tun ist.
Und auch der Test bleibt, bei aller professionellen Unterstützung, letztendlich Kundensache, denn wer sollte sonst so genau entscheiden können, ob es das ist, „was gewünscht wurde“?
Wenn wir uns noch auf den „Umfang“ beschränken, den die realisierte ML-Methode im Moment bzw. ArgoUml hinsichtlich Schritt 4 anbietet, also kleinere, kompakte Software mit max. 10 Dateien bzw. nicht zu komplexe Modelle, dann sieht unser Projekt wie folgt aus:
1. Erstellung der verbalen Vorgabe mit Worten der Auftraggeber, knapp, präzise und konsequent – und nicht zu detailverliebt.
2. Erstellen des ML-Modells aus den verbalen Vorgabe
3. Erstellen des UML-Modells aus dem ML-Modell
4. Erstellen des Java-Codes (© s.o.) aus dem UML-Modell
5. Erstellen der Metadaten für die „fertigen Programmteile“ (MDA) – sowie Erstellen der „fertigen Programme“ (möglichst im eigenen System!)
6. Test, ggf. Iteration ab 2/3
Punkt 3 und 5 hängen natürlich zusammen, vielleicht ist dies ja auch der interessanteste Teil am Projekt, doch die Modellierung und Erstellung der „mighty classes“ ist mit Sicherheit der arbeitsaufwändigste – und endet sicher nie wirklich. (Weitere Erklärungen: s. Erläuterungen und Nachtrag Projektmotivation)
Und was natürlich dazugehört: „Similarly, supporting technology must be available to allow application developers to browse collections of services, select those of interest, and assemble them to create the desired functionality.“ (Quelle s.u.)
Aufwandsschätzung? Personenjahre.
Und dabei müssen noch die „Zeitfresser“ fertig gestellt und eine kleine Auftragsbearbeitung in Angriff genommen werden. Das ist aber keine ganz projektfremde Arbeit, weil dort die (oder einige der) „fertigen Programmteile“ der „mighty classes“ zumindest in Studio erzeugt werden.
Ich befürchte, dass der Blog eine Weile also nur darum geht, wie Autodidakten sich etwas beibringen – und über die „Zeitfresser“. Ob ich den Blog listen lassen soll?
(Nachtrag: Projektreduktion auf Punkt 3: s. Erläuterungen 30.06.2004)
30.06.2004: Fokussierung auf Punkt 3. Erstellen des UML-Modells aus dem ML-Modell
Aufgrund der aktuellen Entwicklung erweist sich der zweite Teil meines Projektes (Punkt 5. Erstellen der Metadaten für die „fertigen Programmteile“ (MDA) – sowie Erstellen der „fertigen Programme“) als überflüssig.
Begründung: Die aktuelle Entwicklung hinsichtlich SOA und MDA setzt viel Kapazitäten auf die neue komplexe Systemstruktur an, die sich längst nicht nur bei Webservices, sondern in praktisch jeder IT-Umgebung nutzen lässt. Die Strukturen und Frameworks sind dabei gerade im Open-Source-Bereich schon sehr weit fortgeschritten (Stichwort EBS, JMS, MOM, MDPB), sodass es keinen Sinn macht, das Rad ein zweites Mal zu erfinden – und das dazu noch später als der „normale Markt“.
Diese Entwicklung hin zu flexiblen modularen Strukturen der SOA wird zwangsweise den Fokus auf die Roadmaps der zu erstellenden Systeme lenken und damit auf Modellierung. Dies wieder trifft sich mit der Entwicklung hin zu MDA, die aus solchen Modellierungen lauffähige Software erzeugen soll. Denn neben den Erfordernissen einer SOA, den Überblick zu behalten, wird die aus der SOA resultierende Flexibilität und Wartungsfreundlichkeit des Gesamtsystems den Wunsch nach Änderungen und Ergänzungen nur anheizen – und das wiederum unterstützt ebenfalls den Trend zur MDA: Die Roadmaps werden dann nicht nur den Ist-Zustand darstellen und unterstützen, sondern als Soll-Zustand zur Programmierung der noch erforderlichen Services dienen.
Das heißt im Klartext: Der einzige Punkt meines zweiteiligen Projektes, den der Markt bisher (und auch in absehbarer Zeit) noch nicht anbietet, weil er bisher noch keine exakte Vorstellung davon hat, was er denn in Wahrheit tut – sprich was exakt Information ist, wie sie deshalb messbar, kontrollierbar und verarbeitbar wird und wie aus genau dem Grund eine Informationsverarbeitung im Idealfall auszusehen hat (ML-Methode) – bleibt Punkt 3:
Somit sieht mein Projekt zur Vervollständigung des gesamten Software-Entwicklungsprozesses (wie in „Projekt“ beschrieben) wie folgt aus:
1. Erstellung der verbalen Vorgabe mit Worten der Auftraggeber, knapp, präzise und konsequent – und nicht zu detailverliebt.
2. Erstellen des ML-Modells aus den verbalen Vorgabe
3. Erstellen des UML-Modells aus dem ML-Modell
4. Erstellen des Java-Codes aus dem UML-Modell
5. Erstellen der Metadaten für die „fertigen Programmteile“ (MDA) – sowie Erstellen der „fertigen Programme“
6. Test, ggf. Iteration ab 2/3
Das Problem der Anpassung des UML-Modells an den MDA-Sektor muss damit ebenfalls diesem Sektor überlassen werden. Was neben der Aufgabe, aus verbalen Vorgaben methodengestützt UML-Modelle zu erstellen, beim Alten bleibt, sind die Hilfsmittel: Wie bisher sollen es Java, Eclipse und ArgoUML sein (Urhebervermerke siehe Randleiste Blog).
09.12.2005: Aufgabe der Arbeitsumgebung - Anpassung Projekt
Nachdem ich nun solange erfolglos versuchte, die gewaltige Masse "Java" plus Frameworks mehr oder weniger nebenbei zu erobern, gebe ich es auf - so wie ich vor Jahren auch schon C++ aufgegeben habe, als ich damals zugunsten der Schnelligkeit und des Komforts auf eine 4GL zurückgegriffen habe (Studio). Und das werde ich nun wieder tun. Java-Programme brauchen einen Stall voll Entwickler, das stemm' ich nicht. Deshalb wird mein Punkt 3 auch ein wenig fragwürdig hinsichtlich des Teils "UML", denn so übermächtig sich diese Modellierungssprache auch gelegentlich darstellt, so scheint es doch auch Gegenströmungen zu geben. Also wird UML durch "Repräsentation" ersetzt.
1. Erstellung der verbalen Vorgabe mit Worten der Auftraggeber, knapp, präzise und konsequent – und nicht zu detailverliebt.
2. Erstellen des ML-Modells aus den verbalen Vorgabe
3. Repräsentation des ML-Modells auf der gewählten Daten- und Codebasis
4. Erstellen der Daten und des Codes aus dem Modell
5. Erstellen der Metadaten für die „fertigen Programmteile“ – sowie Erstellen der „fertigen Programme“
6. Test, ggf. Iteration ab 2/3
Die Frage ist natürlich nun, was die "gewählte" Daten- und Codebasis ist - da bin ich noch am Suchen. Und Punkt 2 ist deshalb wieder offen, weil das Tool zur Berechnung der ML-Methode auch darauf basieren sollte, also neu erstellt werden muss.
© bussole IV 2004 (außer Zitate)