Anwenderkonferenz Rational Software

Codierung und Modell gehen auf Tuchfühlung

26.05.2000
Die Entwicklung objektorientierter Softwaresysteme mit Hilfe der Unified Modeling Language (UML) gehört heute zum Projektalltag. Aber Web- oder komponentenbasierte Anwendungen machen der IT-Abteilung das Leben schwer. Die Firma Rational verspricht Hilfe durch die Bündelung ihrer Tools und Best Practices. Doch auch die UML muss sich weiterentwickeln.CW-Bericht Sascha Alexander

"Eine neue Softwarewelt" entsteht, die Entwickler und Designer vor immer schwierigere Aufgaben stellt. Ihre möglichen "Gegner" bei der täglichen Arbeit sind die immer komplexeren Interaktionen der Programme, vage, fehlerträchtige Spezifikationen, verteilte und zunehmend unübersichtliche Anwendungen (Komponenten), viele parallel laufende Operationen, trickreiche Echtzeit-Applikationen sowie nichtlinear steigende Performance-Anforderungen an die Systeme. Mit diesem Szenario konfrontierte Jim Rumbaugh, Methodenexperte und Chief Scientist bei Rational Software, zum Auftakt der ersten europäischen Anwenderkonferenz in München die rund 500 Teilnehmer. Im Mittelpunkt der Veranstaltung standen dementsprechend Möglichkeiten, wie sich angesichts der steigenden Anforderungen objektorientierte Projekte in der Analyse-, Design- und Implementierungphase verbessern und erweitern lassen, und vor allem welche Strategie Rational hierbei verfolgt.

Um die Risiken und die zunehmende Komplexität insbesondere der Entwicklung großer, verteilter Anwendungen besser in den Griff zu bekommen, empfiehlt der Hersteller für größere Projekte eine durchgängige Implementierung des Lebenszyklus einer Software. Dieser verschränkt idealerweise Analyse, Design, Entwicklung sowie den Workflow zwischen den Projektbeteiligten und den beteiligten Werkzeugen miteinander. Die Strategie Rationals geht daher seit geraumer Zeit in Richtung einer Integration seiner diversen Tools zu Verwaltung, Steuerung und Design des Entwicklungsprozesses mit seinem UML-basierten Prozessmodell für objektorientierte Softwaresysteme "Rational Unified Process" (RUP).

Laut Mike Devlin, Chief Executive Officer, hat das Unternehmen in den letzten Jahren bereits wichtige Schritte in Richtung einer solchen umfassenden Entwicklungsumgebung, die Modellierung, Prozess und Werkzeuge vereint, gemacht. Beispiele sind die Verwendung der UML, die seit längerem zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Softwaresysteme dient und vom hauseigenen Tool "Rational Rose" genutzt wird. Ferner der RUP, der sich neben dem konkurrierenden "V-Modell" in Anwenderkreisen etabliert habe, sowie die integrierte Werkzeugsammlung für den Entwicklungsprozess "Rational Suite", die sich seit ihrer Einführung auf dem Markt vor 15 Monaten einer steigenden Nachfrage erfreue (zu den Umsätzen siehe Kasten "Bilanz").

Es müssten jedoch weitere Anstrengungen unternommen werden, um den Lebenszyklus eines Systems noch umfassender zu begleiten. So investiert Rational laut Devlin derzeit beispielsweise "massiv" in das Vorgehensmodell "Unified Change Management" (UCM). Dieses berücksichtigt den gesamten Entwicklungszyklus und definiert, wie mit Änderungen in den Anforderungen, dem Designmodell, der Dokumentation, der Komponenten, Testfälle oder des Quellcodes umgegangen werden soll.

Wie beim RUP ist auch UCM dabei nicht nur die Beschreibung eines bestimmten Prozesses, sondern bietet zugleich die Möglichkeit zur Implementierung mit Hilfe entsprechender Produkte, die in diesem Fall "Clearcase" und "Clearquest" heißen.

Im Entwicklungsstadium befinden sich ferner Konzepte, die Rumbaugh und Devlin als "Unified Project Management", "Quality by Design" und "Executable Architectures" bezeichneten. Zu den Inhalten und der technischen Umsetzung dieser Konzepte war in München indes noch sehr wenig zu erfahren. Es ist aber so viel klar, dass es um die engere Integration und den Datenaustausch zwischen den Rational-Produkten und den Anwendungsmodellen geht. So skizziert Devlin eine Client-Server-Architektur, in der sich die Rational-Produkte für die Datenmodellierung, das Anforderungs-, das Test- sowie für das Change-Management über die gemeinsame Schnittstelle "Rational Domain Server Interface" koppeln lassen. Das Unternehmen will zudem die Extensible Markup Language (XML) zur Beschreibung von Datenstrukturen sowie das XML Metadata Interchange Format (XMI) für den Datenaustausch verwenden.

Die Zukunft sind Executable ArchitecturesBeim "Unified Process Project" geht es laut Hersteller um die Erweiterung des RUP um Templates und Guidelines. Ziel ist auch hier eine engere Verzahnung des reinen Software-Entwicklungsprozesses mit einer Methode, die sich auch mit der Steuerung von Projekten befasst. Hinter der Bezeichnung Executable Architectures verbirgt sich die Entwicklung architektonischer Templates (Patterns), die vom Kunden auf das fachliche Modell angewendet werden können. Sie sollen sicherstellen, dass eine Architektur fachlich richtig umgesetzt wird, gegenüber Änderungen robuster wird sowie erweiter- und skalierbar bleibt. Letzteres sind Themen, die in der Vergangenheit häufig zu hohen Aufwänden in der Wartung geführt haben, weil stets das Rad neu erfunden werden musste.

Die Templates sind somit Modellbausteine einer vollständigen Entwicklungsumgebung für umfangreiche, normalerweise komponentenbasierte Systeme, wobei Rational sich zunächst auf das Component Object Model von Microsoft sowie die Java-2-Spezifikationen von Sun konzentriert. Bestandteile einer solchen Umgebung sind idealerweise auch ein durchgängiges Projekt-Management, integrierte UML-basierte Geschäftsprozess- und Architekturmodelle, ein jeweils projektspezifischer RUP sowie ein Repository, über das die Daten aus den diversen Rational-Produkten verwaltet und integriert werden ( siehe Grafik). Auch sollen sich Anwendungsbausteine (Komponenten, Frameworks, Patterns) verwalten lassen und dereinst eine umfassende, standardisierte Form zur Beschreibung von Designanforderungen gefunden werden. Die Executable Architectures sollen nach und nach in die Rational-Produkte einfließen. Bis zur Fertigstellung könnten laut Devlin jedoch noch einige Jahre vergehen.

James Rumbaugh betonte zudem, dass das oben geschilderte Szenario in der heutigen Softwareentwicklung auch eine ständige Weiterentwicklung des UML-Standards notwendig mache. So werden in der künftigen Version 2.0 "sehr wahrscheinlich" Möglichkeiten zur Modellierung von Architekturen hinzukommen. Ferner beschäftigen sich derzeit unter Leitung des Standardisierungsgremiums Object Management Group (OMG) eine Reihe von Arbeitsgruppen mit Erweiterungen der UML. Themen sind Enterprise Application Integration, Web-, Echtzeit- und Datenbankanwendungen sowie verteilte komponentenbasierte Systeme. Bei Letzteren geht es um Aspekte wie die geografische Verteilung der Software, parallele Client-Zugriffe oder Event-gesteuerte Transaktionen.

Für die Beschreibung von Echtzeitsystemen liegen der OMG laut Rumbaugh derzeit Eingaben vor, die sich mit Aspekten wie Befehlssemantik, Zeit- und Terminplanung, Verfügbarkeit und Fehlertoleranz sowie der Architektur solcher Programme beschäftigen. Bei der Modellierung der Interaktionen von Websites gehe es um die Darstellung von statischen und dynamischen Seiten sowie um Web-basierte Programme. Rational-Vertreterin Terry Quartani, die sich selbst als "Rose Evangelist" bezeichnet, beschrieb hierzu auf der Konferenz, wie sich Analyse, Design und Abbildung der Prozesse einer Website mit Hilfe von UML umsetzen lassen. Schwierig sei zunächst, dass sich Web-Seiten, die Script-Prozesse verwenden, schwer einer Klasse im logischen Modell zuweisen lassen. Der Trick bestehe darin, die UML um Klassen für Client- und Server-Seiten zu erweitern und ihnen eigene grafische Symbole zuzuweisen. Eine <Server Page> wäre hierbei ein Stereotyp, der das Verhalten der Web-Seite auf dem Server abstrahiert (Operationen, Attribute, Zugriffe auf andere Server-Anwendungen). Eine würde dementsprechend das Verhalten auf dem Client beschreiben (zum Beispiel Javascripts, Attribute, Assoziationen mit Ressourcen wie Active X Controls, Applets, Plug-ins oder das Document Object Model). Weitere neue Stereotypen der UML sind zudem <Hyperlinks> und für HTML-Forms. Ausführlichere Informationen zur Modellierung von Websites hat Jim Conellen, der sich seinerseits als Web-Modelling-Evangelist bei Rational sieht, in seinem dieses Jahr bei Addison-Wesley erschienenen Buch "Building Web Applications" zusammengetragen.

Neben den internen Anstrengungen und der Mitarbeit in der OMG setzt Rational auch auf Kooperationen mit Partnern und Dienstleistern. Allianzen existieren unter anderem mit Microsoft, IBM, Sun, Oracle, Ernst & Young und Deloitte Consulting. So unterstützt Rational beispielsweise die mit Windows 2000 vorgestellte Distributed Internet Applications Architecture (DNA) und arbeitet mit den Redmondern an der zum Jahresende erwarteten Version 7.0 der Sprache- und Werkzeugsammlung "Visual Studio". In München sprachen zudem Partner und Kunden wie IDS Scheer, Poet, SQS, QIS Systemhaus, Zühlke Engineering, Nexus und Reischmann Informatik über Integrationsmöglichkeiten und Erfahrungen mit Rational-Produkten, Aspekte des RUP und der OO-Entwicklung.

Zu den Highlights unter den Anwendervorträgen gehörte die Präsentation der Methodenberater Thilo Jocher und Matthias Holl im Entwicklungscenter der IZB Soft, dem Systemhaus der bayerischen Sparkassen. Um die immer noch sehr ungenaue Aufwandsschätzung in Projekten zu verbessern, haben sie eine formale Methode für die OO-Entwicklung geschaffen, die Use-Case-zentriert ist und mit Objektmodellen arbeitet. Sie kombiniert beziehungsweise passt hierzu Teile der bereits existierenden Schätzverfahren "Function-Point-Analyse" (FPA) und "Cocomo II" an. Als Ergebnis lassen sich die "Bearbeitermonate/-jahre" und damit die Kosten des OO-Projektes schon in der Analyse- und Entwurfsphase genauer als bisher beziffern (siehe Kasten Seite 20 "Kosten"). IZB will nun eine Methode entwerfen, die das Verfahren auch für die konventionelle Softwareentwicklung nutzbar macht.

KostenIZB Soft, das Systemhaus der bayerischen Sparkassen, zeigte auf der Konferenz ein Verfahren, mit dem sich die Kosten von objektorientierten Projekten genauer schätzen lassen als bisher. Hierzu wurden Teile von zwei Standardmethoden gekoppelt:

1. Die Function-Point-Analyse (FPA)

Sie existiert seit 1979 und ist in der Industrie weit verbreitet. Basierend auf den vorhandenen Anforderungen, werden mit Hilfe von 14 "Faktoren" und speziellen Formeln nicht die Codezeilen, sondern der Funktionsumfang der geplanten Software gemessen. Die geschätzten Kosten ergeben sich, allgemein gesprochen, aus den gezählten Function Points (FP) durch Nachschlagen in einer Tabelle, in der erst im Laufe der Zeit entstehende Erfahrungswerte über die Korrelation zwischen FP und Aufwand enthalten sind. Weitere Informationen unter: http://www.ifpug.org/).

2. Cocomo II

Es gibt drei Schätzarten, von denen die IZB Soft nur die "Post Architecture" benutzt, da sie gut kalibriert ist und sich als praxistauglich erwiesen hat. Wieder allgemein gesprochen, verrechnet das Verfahren Kilo Source Lines of Code (KSLOC) über einige Formeln mit 22 Bewertungsfaktoren, zum Beispiel "Qualität des Analytikers", "Datenbankgröße" oder "Stabilität der Plattform".

(Ausführlicher unter: http://www.sunset.usc.edu/COCOMOII/cocomo.html). Cocomo II hat gegenüber FPA den Vorteil, dass die Faktoren detaillierter und unterschiedlich stark und realitätsnaher gewichtet sind. FPA ermöglicht maximal eine Korrektur des Gesamtaufwands von etwa 35 Prozent. Bei Cocomo II können einzelne Punkte je nach ihrer Beurteilung den Gesamtaufwand um bis zu 300 Prozent verändern. Zudem ist Cocomo II sofort nutzbar, während FPA erst im Laufe der Jahre seine Reife entwickelt.

Umsetzung

Der erste Zeitpunkt für eine aussagekräftige Schätzung liegt am Ende der Konzeptionsphase mit einer Genauigkeit zwischen kalkuliertem und tatsächlichem Aufwand von 50 bis 200 Prozent. Die nächsten Termine sind zu Beginn der ersten Iteration, wenn erste Erfahrungen vorliegen, sowie am Ende der Entwurfsphase, wenn die Architektur und damit die kritischsten Use-Cases bestimmt sind. Dann sind erfahrungsgemäß nur noch Abweichungen von etwa zehn Prozent zu erwarten.Vorausgesetzt, es gibt erfahrene Mitarbeiter im Unternehmen, läuft dabei die von der IZB beschriebene Aufwandskalkulation aus FPA und Cocomo II ab: Use-Case-Analyse, Erstellung eines vorläufigen Fachmodells, Schätzung von Use-Cases, Zählung des Objektmodells (Entity-Klassen) und die Bewertung mit Hilfe der 22 Cocomo-II-Faktoren.

BilanzMit Umsatzzuwächsen gegenüber dem Vorjahreszeitraum von 39 Prozent auf rund 572 Millionen Dollar hat Rational Software ein erfolgreiches Geschäftsjahr (Ende 31.März 2000) abgeschlossen. Allein 180,4 Millionen Dollar wurden dabei im vierten Quartal verbucht. Der Gesamtgewinn betrug laut Hersteller rund 94,5 Millionen Dollar oder 99 Cent pro Aktie. Wichtiger Umsatzträger im abgelaufenen Geschäftsjahr war das Modellierungswerkzeug "Rational Rose", auf das laut Reinhard Nielsen, Vice President Europe, rund 25 Prozent der Einnahmen entfielen. Zufrieden zeigte man sich auch mit den Verkaufszahlen der Werkzeugsammlung "Rational Suite", die im ersten Jahr ihrer Vermarktung bereits über 100 Millionen Dollar eingebracht habe.

Abb: Rational will Tools, Komponenten und Modelle über eine Architektur vereinen. Quelle: Rational