Im Gegensatz zu dem Eindruck, den die Ereignislosigkeit dieses Blogs hervorrufen mag, ist das Projekt nicht gestorben. Es hat sich nur von Eclipse/Java auf Eclipse/Rails verschoben - und obwohl Ruby und Rails wirklich unglaublich sind, ist eine Einarbeitung in ein doch reichlich neues Metier auch immer zeitaufwändig.
Rubys ausgeprägte Metaprogrammierungs-Qualitäten und Rails' Angebot an Funktionalität zur Datenbank gestützten Web-Programmierung machen eine Fortsetzung des Projekts aber tatsächlich erfolgversprechend, wenn auch in einer abgewandelten Version:
Wie in den Anmerkungen beschrieben, sieht das Projekt somit folgendermaßen 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 Ruby-Codes aus dem
ML-Modell
5.
Erstellen der Metadaten für die „fertigen Programmteile“
(MDA) – sowie Erstellen der „fertigen Programme“
(möglichst im eigenen System!)
6. Test
Hierarchischer Aufbau der Prozesse:
Sortiere deine Aufgaben nach Einzelfall-Abhängigkeit in die drei Ebenen:
System (Unabhängigkeit), Typ (Gemeinsamkeiten aller betrachteten Einzelfälle) und Einzelfall (individuelle Problematik)
Oder einfacher gesagt: wenn du mehr als 5-7 Statements mehrfach programmiert hast, kannst du sie mindestens eine Ebene nach oben schieben. Gilt dies nicht für alle deine betrachteten Fälle, dann hast du einen neuen Sub-Typ entdeckt – ML-Methode in Comic-Version. Dieser Tipp ist verwandt mit dem ...
DRY-Prinzip von Ruby On Rails: Don't Repeat Yourself
KISS (Keep it Simple and Stupid) - Erfahrung aus der Praxis:
So regelbasiert (und dadurch kompakt) deine Anwendung im Inneren sein muss, um erweiterbar und pflegeleicht zu sein, so primitiv und in Stein gehauen muss sie nach außen aussehen. Das heißt ein höchstens dreidimensionaler Zugang mit klaren, verständlichen Alltagsbegriffen. Bloß um alles in der Welt die Komplexität der dahinter steckenden Applikation verbergen! Oberstes Muss für eine Software, die nicht nur genutzt, sondern gerne genutzt werden soll: lieber weniger können, dafür einfacher zu bedienen sein.
Oder mit anderen Worten: Wenn schon keine einfach Matrix als Schaltstelle für deine Anwender genügt, dann wenigstens Multiple-Choice - und wenn immer es geht, „freie Fragen“ vermeiden.
Nachtrag 09.12.2005: Nachdem ich nun lange versuchte, Java mit seiner arbeitsintensiven Gewaltigkeit auf etwas zu reduzieren, was eine Person alleine in vertretbarer Zeit bewältigen kann, gebe ich es genauso auf, wie ich es vor Jahren schon einmal tat. Damals zog ich eine 4GL-Umgebung vor, heute...
suche ich noch. Mein Projekt (aktuell) reduziert sich darauf, Möglichkeiten und Wege erst einmal zu bestimmen, mit der die ML verwaltet werden kann (Punkt 1 und 2 meines veralteten Projekts), um dann aus diesen Objektvorgaben lauffähige Programme zu erzeugen, wobei die Problematik der "mighty classes" bzw. vorgefertigten Programm-Templates letztlich erhalten bleibt sowie die Aufgabenstellung, alle beteiligten Komponenten übersichtlich anzubieten.
Veraltete Version:
Unser Projekt beschränkt sich, wie in den Anmerkungen beschrieben, auf die Punkte 3 und 5:
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.
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.“ (s. SOA)
Aufgrund der aktuellen Entwicklung wurde Punkt 5 aus dem Projekt entfernt. Damit verlieren die kursiv/grau gedruckten Texte ihre Bedeutung für dieses Projekt, wenn auch nicht für den generellen Ablauf eines Software-Projektes.
© bussole IV 2004 (außer Zitate)