Solides Fundament für die Software

Gibt es Probleme, dann können die mit Hilfe des Debuggers und den komfortablen Möglichkeiten einer Integrierten Entwicklungsumgebung (IDE, Integrated Development Enviroment) leicht ausgeräumt werden - und schliesslich sind Entwickler gewohnt, bei Problemen ein paar Überstunden einzulegen. Die Modellierung hingegen bedeutet, so glauben zumindest viele, einen Zusatzaufwand, der den Zeitaufwand vergrössert und mehr Geld kostet - ganz zu schweigen davon, dass man sich in die Modellierung erst einarbeiten müsste. Darum modelliert nur ein Bruchteil der Entwickler formell. Natürlich ist diese Haltung in vielen Fällen berechtigt. Einfache Projekte brauchen kein Modell. Ein Architekt baut aus dem Stegreif eine Hundehütte, ohne Modell und ohne Plan. Geht es aber um einen Wolkenkratzer oder um ein prunkvolles Opernhaus, dann wird es der gleiche Architekt nicht als unter seiner Würde erachten, das Projekt präzis zu planen, es zu visualisieren und verschiedene Varianten durchzuspielen. Nur mit dieser Vorbereitung wird er das fi - nanzielle und technische Risiko der Realisation eingehen wollen.

Eine Softwarelösung ist weder eine Hundehütte noch ein Wolkenkratzer. Als Unterschied zu der Architektur kann Software schnell und einfach erstellt werden und sie lässt sich jederzeit ändern und erweitern. Kein Entwickler baut Werke für die Ewigkeit. Die Softwarelösungen sind niemals fertig: Sie werden weiterentwickelt, an neue Bedürfnisse angepasst und mit Fremdsystemen integriert. Und während dieser Anpassungen muss der Support gewährleistet sein. Und darin liegt ein wichtiger Grund für die Softwaremodellierung. Lösungen werden zunehmend komplex. Sie steuern über- lebenswichtige Prozesse in den Unternehmen. Software ist ein strategischer Pfeiler im Konkurrenzkampf und bedeutet einen Wettbewerbsvorteil oder -Nachteil. Der Entwickler trägt Verantwortung dafür, wie gut sich seine Kunden in einem schwierigen Umfeld schlagen - und ob sie den Anforderungen des Marktes gewachsen sind.
Softwaremodelle helfen, diesen Anforderungen Rechnung zu tragen. Sie geben ein besseres Verständnis und verschaffen dem Entwickler mehr Übersicht. Die Konzepte werden von erfahrenen Entwicklern seit Jahren praktiziert. Und es zeigt sich, dass die Modellierung den Erstellungsprozess nicht verlangsamt und meist kein Hindernis für die termingerechte Ablieferung der Projekte darstellt.
Ein Modell ist eine Abstraktion, eine vereinfachte Repräsentation der zu bauenden Wirklichkeit. Das Modell verringert die
Komplexität und hilft den Beteiligten, das Projekt zu verstehen, die Risiken zu minimieren und das beste Design auszumachen. Modelle werden seit Jahren von Analysten, Ingenieuren und Wissenschaftlern verwendet, die komplexe Systeme bauen.
Durch die Softwaremodellierung versteht der Entwickler den Ist-Zustand besser und ist sich im Klaren über den Soll-Zustand. Die Modellierung hilft ihm beim Entwerfen und Bauen der Systemarchitektur und sie erlaubt einerseits das Visualisieren des Codes. Andererseits vermag sie darüber hinaus auch die Implementierung des Projekts, das heisst seine Struktur und die Geschäftslogik abzubilden.
Entscheidet sich der Entwickler für einen Entwicklungsprozess mit Modellierung (Model driven development oder MDD), dann präsentiert sich ihm ein breites Spektrum an möglichen Abstraktionsebenen gegenüber dem Quellcode. Die folgenden Ansätze haben sich bewährt:
IDEs: Integrierte Entwicklungsumgebungen erlauben eine einfachste Form der Modellierung. Die Werkzeuge wie sprachsensitive Editoren, Assistenten oder GUIEditoren erzeugen zwar keine Modelle im strikten Sinn, doch sie können die Abstraktion gegenüber dem Quellcode erhöhen. Diese Werkzeuge gewährleisten ausserdem das zentrale Anliegen des MDD, indem sie zu einer höheren Produktivität der Entwickler führen, die Zuverlässigkeit steigern und einen effektiveren Wartungsprozess ermöglichen. Code-Visualisierung und visuelles Editieren: Ein Bild sagt mehr als Tausend Zeilen Quellcode, und Flussdiagramme sind ein effektiver Weg, Algorithmen und Programmabläufe zu beschreiben. Seit jeher verwenden Programmierer daher einfache grafi sche Darstellungen mit Pfeilen und Symbolen, um Funktionen, Abhängigkeiten und so weiter zu beschreiben. Beim visuellen Editieren wird der Code durch Diagramme bearbeitet und nicht wie bei der konventionellen IDE durch einen Texteditor. Gerade beim Refactoring von Klassen vermeiden die visuellen Editoren viele Fehler. Das visuelle Arbeiten ist aber auch komfortabel: Der visuelle Editor gestattet zum Beispiel das Verschieben einer Methode von einer Klasse in eine andere per Drag und Drop und nimmt dabei automatisch die notwendigen Code-Anpassungen vor. Code-Visualisierung und visuelles Editieren sind eine zusätzliche Methode, den Quellcode einzusehen und zu bearbeiten, aber sie führen nicht zu Modellen im eigentlichen Sinn. Die Visualisierung gewährleistet jedoch eine Abstraktion von dem zu Grunde liegenden Quellcode, und erfüllt somit ein wichtiges Anliegen der Softwaremodellierung.

Modellieren und Round-Trip-Engineering: Diese Stufe im Modellierungs-Spektrum entspricht dem aktuellen Stand der MDDEntwicklung. Ein methodengesteuerter Prozess erstellt visuelle Methoden. Dieser Prozess geht von den Anforderungen aus und setzt diese zu einem High-Level-Architekturdesign- Modell um. Die Entwickler erstellen dann das Detaildesign-Modell, aus dem wiederum das Skelettmodell des Codes für eine IDE generiert wird. Mit Hilfe dieser IDE wird der eigentliche Code entwickelt. Jede Modell-relevante Änderung am Code wird mit dem Modell synchronisiert und jede Änderung am Modell führt zu den notwendigen Anpassungen am Code.
Legacy Integration: Diese Form der Modellierung unterstützt die Integration von Drittsystemen, zum Beispiel vorhandene Systeme oder neue. Die Modellierung hat in diesem Fall nicht das Ziel, das komplette System abzubilden. Angestrebt wird das Verständnis aller relevanten Komponenten, der Schnittstellen, sowie der grundlegenden Architektur. Reverse-Engineering ist eine Möglichkeit der Legacy Integration. Rapid Application Development (RAD): RAD wird seit den frühen Achtzigern betrieben. Es stellt hoch produktive Wege zur Codegenerierung und Codewartung zur Verfügung. RAD bietet einen höheren Abstraktionslevel als der Quellcode, braucht also per defi nitionem Modelle.
Business-Modellierung und Modell-Ausführung:
Business-Analysten modellieren die Geschäftsprozesse unabhängig von der Softwareentwicklung. Das Ziel ist eine Optimierung der Abläufe. Spezielle Werkzeuge simulieren den Ist-Zustand und leiten ein optimiertes Soll-Modell ab. Diese Modelle sind massgeblich für die im zweiten Schritt stattfi ndende Softwareentwicklung.

Diese sechs Stufen zeigen, dass es verschiedene Abstufungen der Modellierung gibt, die sich auch dadurch unterscheiden, wie eng das Modell mit der resultierenden Anwendung assoziiert ist. Bei einigen Applikationsumgebungen sind die Soll-Modelle derart rigoros spezifi ziert, dass komplette Applikationen vom Modell generiert werden können: Das garantiert maximale Produktivität und die optimale technische Lösung für das anstehende Geschäftsproblem.Die Unifi ed Modelling Language (UML) ist ein offener Standard zur Repräsentation von Modellen und abstrakten Darstellungen. Sie ist in der Softwareindustrie am weitesten verbreitet. UML defi niert einen Standard zur grafi schen Notation. Als Modellierungssprache verfügt UML wie andere natürliche oder künstliche Sprachen aberauch über eine Syntax (Konstruktionsvorschriften und Strukturregeln) und bestimmt die Semantik (die Bedeutung der Text- und Grafi kelemente). Nebst anderen Neuerungen unterstützt die Version zwei Meta-Modelle. Diesen kommt für die zukünftige Modellierung eine zentrale Bedeutung zu. Sie bilden die Basis, wie automatisierte Tools Daten austauschen und kommunizieren. Von dieser Fähigkeit profi tieren nicht nur die Modellierungswerkzeuge, sondern alle Tools in der Softwareentwicklung: Das Anforderungsmanagement, Kompilation, Test und das Konfi gurationsmanagement.

Der Nutzen der Softwaremodellierung liegt auf der Hand - auch wenn die uneinheitliche Anwendung gegenwärtig noch eine Hürde darstellt: Die Modellierungsebenen werden in verschiedenen Berufsfeldern und Kulturen und mit den unterschiedlichen Modellierungstools nicht übereinstimmend umgesetzt. Die verschiedenen Welten werden in Zukunft aber näher zusammenrücken. Diese Entwicklung wird nicht notwendigerweise durch ein Standardtool oder eine allgemeingültige Modellierungssprache eingeläutet. Die ordnende und vereinheitlichende Wirkung wird durch die Kombination von verschiedenen offenen Standards herbeigeführt. Eclipse und die IBM Rational Software Development Platform mit dem IBM Rational Software Architect sind gute Beispiele hierfür.
In der Softwareentwicklung geht es inzwischen zu und her wie im internationalen Spitzensport: Die Teams treten in ständig wechselnder Aufstellung, in verschiedenen Ländern, Kulturen und Sprachen gegeneinander an. Die Modellierung sorgt unter zunehmend komplexen Umständen für reguläre Wettkampfbedingungen.