Metamodellbasierte und hierarchieorientierte ... - RosDok

10 Grundlagen: Modellierung in ausgewählten Gebieten
werden oder lediglich als grobe Skizze dienen. Jedoch ist anzumerken, dass die UML zu den semiformalen
Spezifikationssprachen zählt, die eine Verifikation der zu erstellenden Software nicht ermöglicht.
Sehr formale Ansätze nutzen textuelle, an mathematischen Modellen angelehnte Spezifikationen, die durch
die strengen Vorschriften und mathematischen Symbole für Laien schwer zu verstehen sind. Hier sind
u.a. die algebraischen Spezifikation abstrakter Datentypen [BM04] oder das Hoare-Kalkül [Hoa69] zu
nennen. Diese Ansätze haben den Anspruch bewiesene, korrekte Software zu erstellen, die jedoch äußerst
schwierig zu bekommen ist. Die Gefahr ist groß, dass Fehler in den komplizierten Beweisen vorkommen.
Anforderungen an die Software lassen sich außerdem anhand der komplizierten Spezifikationen nicht mit
Stakeholdern diskutieren. Somit kann es passieren, dass von falschen Voraussetzungen ausgegangen wird
und obwohl der Beweis korrekt geführt wurde kann eine Software entstehen, die nicht dem gewünschten
Ergebnis entspricht.
Diese Ansätze sind des Weiteren äußerst teuer, da sehr lange Analysephasen vor der Implementierung
durchgeführt werden müssen. Außerdem kann schwer während des Entwicklungsprozesses auf wechselnde
Anforderungen der Endanwender an die Software reagiert werden, da sehr viele Analysedokumente und
Beweise bei veränderten Anforderungen vorgenommen werden müssen. Zudem sind die Spezifikationen
nicht als Dokumentation der Software geeignet, da sie i.d.R. schwerer zu lesen sind als der Programmcode
selber, auf den sie sich beziehen. Eine ausführliche Diskussion der Vor- und Nachteile von formalen
Methoden in der Softwareentwicklung, die u.a. einige der oben aufgeführten Probleme beinhaltet, ist
in [Gog04] zu finden.
Die vielen Nachteile machen die streng formalen Methoden für weite Teile der Softwareentwicklung nicht
effizient nutzbar. Für einzelne wenige Bereichen, wie z.B. Luft- und Raumfahrt, bei denen die korrekte
Funktionsweise äußerst wichtig ist und wenige Anforderungen sich während des Entwicklungsprozesses
ändern, finden die Methoden Anwendung. Dagegen ist gerade der Bereich der Wirtschaftsinformatik, bei
denen Computer Nutzer bei der Arbeit unterstützen bzw. Arbeitsabläufe automatisieren sollen, für solche
streng formalen Methoden nicht geeignet. In diesem Bereich hat man es mit permanenten Änderungen bei
Geschäftsabläufen und Umstrukturierungen zu tun, so dass Software bzw. deren Entwicklungsprozess sehr
flexibel sein muss.
In nicht formalen, agilen Entwicklungsmethoden für Software wird die Analysephase sehr kurz gehalten.
Es werden höchstens sehr informelle, visuelle Modelle (z.B. UML) als Kommunikationsmittel in der
Entwicklergruppe genutzt und es wird frühzeitig zur Implementierung übergegangen. Somit sind diese
Methoden eher als codezentriert zu bezeichnen. Generell ist die Kommunikation in der Entwicklergruppe
bei diesen Methoden sehr wichtig. Bei den Entwicklungsansätzen sind z.B. Extreme Programming [Bec00]
und SCRUM [Pic07] zu nennen. Der Vorteil hier liegt darin, dass schnell Software produziert wird und der
Endnutzer in die Entwicklung der Software intensiver mit eingebunden werden kann. Es kann rascher auf
sich wechselnde Anforderungen reagiert werden. Diese Entwicklungsmethoden bergen aber auch große
Gefahren. Da unmittelbar in die Implementierungsphase übergegangen wird, fehlt i.d.R. ein verlässliches
Design. Ein sorgfältiger Einsatz von Desgin Patterns [GHJV02], der einen guten Softwareentwurf und damit
wartbare und wiederverwendbare Software verspricht, ist damit nicht möglich.
Ein Kompromiss zwischen formalen und nicht formalen Ansätzen liegen in der semiformalen bzw. leichtgewichtigen
formalen Softwarespezifikation. Hier werden die erstellten Modelle auf Eigenschaften geprüft,
die sie erfüllen müssen. Damit wird sichergestellt, dass ein guter (objektorientierter) Entwurf vorliegt bevor
in die Implementierungsphase weitergegangen wird. Diesen Ansätzen werden u.a. ermöglicht durch die
UML-Werkzeuge USE [GBR07] und Alloy [Jac03]. Das Modell wird als UML-Klassendiagramm angegeben
und Objektdiagramme repräsentieren Systemzustände zur Runtime. Diese können semiautomatisch
von den Tools generiert werden und sind Testfälle für das Designmodell. Hierbei können zwei Arten von