Ein Feature-basiertes Modell für Softwareentwicklung

Es ist der heilige Gral der Softwareentwicklung: Das Featureorientierte Programmieren.

Vom Prinzip her stellt sich jeder Hochschul-Professor den idealen FOP-Ansatz so vor, dass man eine Software mit einem einfachen Editor erstellen kann, indem man einfach ein paar Features miteinander kombiniert. Diese Vision erzählt der Professor dann seinen Studierenden und lässt damit die nächste Generation an Softwareentwicklern grübeln, wie man die Welt verbessern kann.

Der Wirkmechanismus dahinter ist ebenfalls bekannt: Es muss irgendein Modell geben, mit dem man Software beschreiben kann – und dann einen Compiler, der aus dem Modell die Software generiert.

Die einzige Schwierigkeit ist, ein passendes Modell zu finden, mit dem man Software gut beschreiben kann. Um das zu verdeutlichen, mal ein paar Eigenschaften, die dieses Modell erfüllen muss:

• Mit dem Modell muss man jede erdenkliche Software beschreiben können, die existiert oder existieren könnte
• Das Modell muss einfach zu erlernen sein, damit man auch genügend Entwickler findet, die so programmieren wollen
• Das Modell muss einfach zu verändern und zu bearbeiten sein, wenn man eine Software mal verbessern möchte
• Das Modell muss optimal sein in der Form, dass man einfach zu erklärende Software auch mit möglichst wenig „Code“ (Modell-Komplexität) erstellen kann

Hier ein paar bereits existierende Programmiermodelle, die bei größerer Software immer wieder scheitern:

• Imperative Programmierung
  Hier beschreibt man eine Software mit ein paar IF, THEN, ELSE, WHILE, UNTIL und GOTO-Befehlen. Das Modell ist einfach zu erlernen, erzeugt aber sehr umfangreiche Programme, in die man sich schlecht hereinfindet
• Prozedurale Programmierung
  Hier kann man imperative Programme in Funktionen und Prozeduren kapseln. Der GOTO-Befehl fällt weg. Die Software wird übersichtlicher, die Komplexität steigt aber trotzdem linear bis quadratisch.
• Objektorientierte Programmierung
  Hier kann man wiederkehrende Programmteile in Klassen einsortieren und verknüpft die Datenstrukturen (Klassen) mit den Methoden (Prozeduren) – Software wird übersichtliche und modularer. Trotzdem kann man Software noch nicht beliebig zusammensetzen.
• Funktionale Programmierung
  Hier beschreibt man alle Programmfunktionen als berechenbare mathematische Ausdrücke. Die Modularität verbessert sich gegenüber der Imperativen Programmierung. Trotzdem wird Software sehr komplex.

Was macht ein gutes FOP-Modell jetzt also aus?

Was ein gutes FOP-Modell eigentlich ausmacht, steckt schon im Namen: „Featureorientiertes Programmieren“ – es muss die Möglichkeit geben, komplette Features in der Software beschreiben und wiederverwenden zu können.

Dabei sollten Features im Gegensatz zu „Klassen“ aus der Objektorientierten Programmierung nicht nur auf eine bestimmte Datenstruktur (sprich: Klasse) passen, sondern sich einer beliebigen Datenstruktur anpassen können, für die das Feature Sinn macht.

Ein Beispiel: Das Feature „revisionssichere Datenablage“ soll dafür sorgen, dass Dokumente nicht mehr gelöscht werden können, sondern alle Änderungen nachvollziehbar abgerufen werden können. In objektoriengierter Software muss man hier sehr viel improvisieren und mit viel Handarbeit programmieren. In einer FOP-Software entwickelt man seine Basis-Komponente und gibt ihr anschließend noch das Feature „Revisionssicher“ dazu.

Wir bei Launix haben eine solche FOP-Programmiersprache entwickelt, den Compiler dafür gebaut und entwerfen damit ERP-Systeme, aber auch Kundenportale und sonstige datenbanklastige Tools für Jedermann.

Unsere Sprache basiert auf einer Beschreibungslogik, die man jederzeit um neue Begriffe – sogenannte Features – erweitern kann. Eine Software erstellt man dann, indem man die Features miteinander kombiniert. Ein Feature kann vom „Neues Eingabe-Feld in einem Formular“ bis hin zu „Ein komplettes Rechnungsprogramm“ alles darstellen, das man in seiner Software integrieren kann.

Parallel zum textuellen Programmieren gibt es dann noch den Editor, mit dem man eine grafische Ansicht (UML-Komponentendiagramm) seiner Software hat. Jede Änderung am Diagramm manipuliert sofort den Quelltext, das heißt, in einem Team können grafische und textuelle Programmierer zusammenarbeiten.

Mehr Infos dazu gibt es zum Beispiel im Beitrag über das FOP-Siegel oder über die FOP FAQ.