Die Idee eines Computer Aided Software Engineering (CASE), verstanden als Familie integrierter Werkzeuge für alle Phasen im Lebenszyklus eines Softwareproduktes mit einem gemeinsamen Repository für alle Zwischenergebnisse, ist sicherlich längst tot. Daß noch viele solcher Produkte auf dem Markt sind, zeigt lediglich, wie langsam eingeführte Softwaretechnologien sterben. Neue Anwendungen mit CASE-Werkzeugen gibt es nicht. Die Gründe dafür liefern die Tools selbst.
Integrierte CASE-Umgebungen sind zwangsläufig geschlossene, proprietäre Systeme. In sich sind sie schlüssig und konsistent. Sie bieten dem Anwender eine einheitliche Oberfläche und verwalten ein einziges allumfassendes Repository, in dem fachliche und technische Systemelemente integriert sind. Die Programmiersprache spielt eine untergeordnete Rolle, weil die Software in der CASE-Sprache verfaßt wird. Die Umgebungen sind relativ starr und lassen nur bestimmte Vorgehensweisen zu.
Integriertes CASE basiert auf dem Wasserfallmodell, nach dem der Software-Entwicklungsprozeß linear von einer zur anderen Phase verläuft. Jede Phase baut auf den Ergebnissen der vorhergehenden auf, ohne sie in Frage zu stellen. Falls der Ausgangspunkt nicht richtig gewählt wurde, ist die Entwicklung zum Scheitern verurteilt.
Der größte Nachteil integrierter CASE-Systeme besteht allerdings darin, daß Anwendungen, die damit entwickelt werden, von den Tools abhängig bleiben. Die Anwendungen sind für sich genommen weder wartbar, noch lassen sie sich portieren.
Offene CASE-Umgebungen sind dagegen heterogen und komplex. Sie setzen sich zusammen aus verschiedenen Werkzeugen von unterschiedlichen Lieferanten. Im Mittelpunkt steht die Programmiersprache, sie hält die verschiedenen Entwicklungs-Tools zusammen und bestimmt, welche Methoden und Werkzeuge eingesetzt werden können. Deshalb sollten nur genormte Sprachen in Betracht kommen wie Cobol, ADA, C++ oder Smalltalk 4GL-Sprachen sind zu meiden.
Außerdem können die Anwender eigene Middleware einführen und eigene Testrahmen bauen. Dadurch bleiben die Anwender autark. Dafür tragen sie allerdings auch die Verantwortung für die Integration der Werkzeuge, Methoden und Sprachen. Es empfiehlt sich ein Software-Engineering-Stab, der diese Aufgaben übernimmt.
In einer offenen CASE-Umgebung muß lediglich die Benutzeroberfläche einheitlich sein. Sie soll den Anwendern ermöglichen, beliebig auf gewünschte Tools zuzugreifen.
Zwar gilt auch für die Werkzeugdatenhaltung ein Einheitlichkeitsgebot, das garantiert, daß alle persistenten Ergebnisse über eine Standard-SQL-Schnittstelle wie ODBC oder DRDA gespeichert und wiedergewonnen werden können, doch ist dies nicht unbedingt erforderlich. Wichtiger sind Flexibilität, Austauschbarkeit und Interoperabilität der Einzelwerkzeuge.
Schließlich unterstützt der fragmentierte CASE-Ansatz ein iteratives, evolutionäres Vorgehen. Hierbei lassen sich Anforderungen anhand von Vorabversionen klären und Zwischenergebnisse neu definieren.
Die neue Generation von CASE-Werkzeugen, die gerade auf den Markt gekommen ist, zielt nur noch auf die Programmentwicklung. Der Anspruch auf Unterstützung des gesamten Lebenszyklus von Softwareprogrammen ist verschwunden.
So kann zur Zeit die Empfehlung für große Unternehmen nur lauten: kein I-CASE. Offenheit und Herstellerunabhängigkeit haben oberste Priotität. Aber auch für Klein- und Mittelbetriebe, die sich eine offene Umgebung nicht leisten können oder wollen, ist von geschlossenen CASE-Umgebungen abzuraten. Sie sollten statt dessen Standardsoftware und eine 4GL wählen. Damit kaufen die Firmen erprobte Algorithmen und Middleware, die es ihnen ermöglichen, schnell Applikationen zu erstellen.
*Harry Sneed ist Berater bei der Software Engineering Service GmbH in München.