JavaMagazin 5/2005: Das RAD neu erfunden?

IBMs J2EE-Entwicklungsumgebung Rational Application Developer in neuem Gewand

Mit der „Atlantic“-Ankündigung hat IBM eine Reihe von Produkten annonciert, die unter anderem einen Teil der bisherigen Websphere Studio-Produkte ablösen. Der ehemalige Websphere Studio Site Developer wurde zum Rational Web Developer, der Websphere Studio Application Developer zum Rational Application Developer, kurz RAD genannt. Mit dieser Umbenennung verfolgt IBM die Konsolidierung der bisherigen Produktvielfalt – nicht nur bei den Entwicklungswerkzeugen – und positioniert entsprechend die Entwicklungswerkzeuge innerhalb der IBM-Marke Rational.

Die früheren Softwareentwicklungswerkzeuge von Websphere wurden nicht nur deswegen umbenannt, damit sie rein organisatorisch zukünftig zur Marke Rational gehören. Vielmehr fügen sich die beiden Entwicklungswerkeuge auch inhaltlich wie ein bisher noch fehlender Baustein in die bestehende Werkzeuglandschaft von Rational ein. Damit kann die Softwareentwicklungsplattform von Rational mit all ihren Werkzeugen (wie z.B. RequisitePro, Functional Tester, ClearCase, ClearQuest, etc.) den gesamten Softwareentwicklungszyklus abdecken. Die ehemaligen Websphere-Entwicklungswerkzeuge sind dabei im Bereich „Design and Construction“ der Softwareentwicklungsplattform von Rational positioniert. Abbildung 1 visualisiert die einzelnen Rational-Produkte in diesem Bereich und deren Beziehungen untereinander.



Abb. 1: Produkte von IBM Rational im Bereich „Design and Construction“ (Quelle: IBM)

Neben diesen organisatorischen Anpassungen hat sich auch das Werkzeug selbst weiterentwickelt. Je nachdem, welche der optionalen Installationskomponenten ausgewählt wurden, steigt die Anzahl der Plug-ins gegenüber dem WSAD V5 um ca. ein Drittel auf etwa 2.050 Plug-ins. Entsprechend steigt der Ressourcenbedarf des Entwicklerrechners.
Der RAD 6 basiert auf Eclipse 3.0.1. Dieser Versionswechsel alleine bedingt schon zahlreiche Neuerungen, welche bereits ausführlich in diversen Artikeln erläutert wurden. Viele Funktionen des RAD nutzen diese Neuerungen und bauen gezielt darauf auf.

UML und RUP

Einer der neuen Funktionsbereiche des RAD ermöglicht die Visualisierung von Softwaresystemen mittels der UML. Zur Verfügung stehen Klassen- und Sequenz- sowie Browse- und Topic-Diagramme als Varianten von Klassendiagrammen mit jeweils unterschiedlicher Zielsetzung.
Klassendiagramme ermöglichen die visuelle Definition von Klassen bzw. EJBs. Dabei werden die Attribute und Methoden der einzelnen Klassen bzw. EJBs sowie die Beziehungen zwischen den einzelnen Klassen und EJBs festgelegt. Komfortabel sind die Möglichkeiten des Refactorings per Drag & Drop, um beispielsweise eine Methode von einer Klasse in eine andere zu verschieben.

Die Browse-Diagramme dienen der Navigation durch ein Softwaresystem. Ausgehend von einer Klasse oder einer EJB werden dabei die in Relation stehenden Artefakte angezeigt und somit der Aufbau dieser Komponente und die Zusammenhänge zu anderen Komponenten visualisiert. Browse-Diagramme sind temporär, gehen also nach dem Schließen des Editors verloren. Entsprechend können die Inhalte von Browse-Diagrammen nicht modifiziert werden.

Soll ein Diagramm beispielsweise für Dokumentationszwecke abgespeichert werden, ist das Topic-Diagramm ein geeignetes Darstellungsmittel. Das Topic-Diagramm visualisiert Artefakte, die zu einer gewissen Thematik interessant sind. Innerhalb des Topic-Diagramms sind an den Artefakten allerdings keine Modifikationen möglich. Sequenzdiagramme schließlich visualisieren die Interaktion von Objekten, also von Instanzen der definierten Klassen. Der Fokus liegt dabei auf der zeitlichen Abfolge der einzelnen Methodenaufrufe bei der Objektinteraktion.

Diejenigen UML-Diagrammtypen, die aus der Entwicklerperspektive am interessantesten sind (Klassen- und Sequenz-Diagramme), wurden also direkt in das Entwicklungswerkzeug integriert und können zur Visualisierung der Programmartefakte verwendet werden. Der RAD ist damit jedoch kein Ersatz für ein umfassendes Modellierungswerkzeug. Wenn nicht die Implementierung, sondern die Modellierung im Vordergrund steht und die volle Darstellungsvielfalt des UML-Sprachstandards benötigt wird, sind der Rational Software Modeler bzw. der Rational Software Architect die Werkzeuge der Wahl, will man bei der Produktpalette von Big Blue bleiben.

Des Weiteren wurde das Entwicklungswerkzeug ergänzt um den Softwareentwicklungsprozess RUP (Rational Unified Process), dessen Dokumentation im Lieferumfang des RAD enthalten ist. Jederzeit kann der Process Advisor dem Entwickler entsprechende Hinweise zu seiner aktuellen Tätigkeit geben, egal in welche Perspektive er sich gerade befindet. Darüber hinaus bietet der Process Browser die Möglichkeit, in der Dokumentation des RUP zu suchen und den RUP individuell zu konfigurieren. Somit unterstützt der RAD nicht nur die rein programmiertechnischen Aspekte der Entwicklung von J2EE-Anwendungen, sondern auch die systematische Vorgehensweise bei der Anwendungsentwicklung.

Prüfung der Code-Qualität

Normalerweise steht im Softwareentwicklungszyklus nach der Implementierung eines Designs die Sicherung der Code-Qualität durch diverse Tests sowie Code Reviews an. Auch in diesem Bereich wurde die Funktionalität des RAD erweitert. Dabei analysiert der RAD den vorliegenden Quelltext nach verschiedenen Gesichtspunkten, wie z.B., dass innerhalb eines Servlets bestimmte Methoden der Klasse java.lang.Thread nicht aufgerufen werden sollten. Neben einer Reihe von vordefinierten Regeln können auch eigene Regeln in das Werkzeug integriert werden. Verglichen mit anderen Werkzeugen ist die Zahl der vordefinierten Regeln (derzeit 35) noch eher überschaubar. Da sich diese Regeln mit Import/Export austauschen lassen, werden sicherlich bald weitere Regelpakete verfügbar sein. Als Ergebnis des Code Review für ein bestimmtes Projekt erstellt der RAD eine Liste aller Regelverstöße und stellt diese in einem eigenen View dar. In einem zweiten Code Review Details View kann sich der Benutzer zu einem Regelverstoß dessen Beschreibung, ein Beispiel und eine mögliche Lösung des Problems anzeigen lassen.

Auch hinsichtlich der Component-Tests wurde das Werkzeug um Funktionalität erweitert, die über die JUnit-Unterstützung von Eclipse und die Component-Test-Funktionalität des Eclipse-Unterprojekts Hyades [1] hinausgeht. Als Erweiterung der Funktionalität von Hyades lassen sich nun auch EJBs und Web Services durch automatisierte Tests auf ihre korrekte Funktionsweise hin prüfen. So ist es möglich, zu jeder EJB und jedem Web Service entsprechende Testfälle zu definieren, deren einzelne Testläufe jeweils mit unterschiedlichen Daten durchgeführt werden. Tests werden dabei durch entsprechende Testklassen realisiert. Mittels einer Tabelle werden die Testparameter mit Testwerten belegt. Zur Ausführung eines solchen Tests wird ein temporäres J2EE-Application-Client-Projekt erzeugt, das als Test-Client gegen die J2EE-Komponenten fungiert. Die dabei aufgezeichneten Ergebnisse lassen sich anschließend untersuchen.

Server-Testumgebung

Eine Reihe von Neuerungen bei der Integration des Testservers entlastet den Entwickler spürbar und ermöglicht somit eine höhere Produktivität. Unter dem Begriff Websphere Rapid Deployment verbirgt sich folgendes Konzept: Sämtliche deklarativen Einstellungen zu einer J2EE-Komponente sind nun mithilfe von XDoclet-Annotationen [2] in der Komponente selbst verankert und nicht mehr verteilt in mehreren Artefakten zu finden. Beispielsweise werden direkt in einem Servlet URL Mappings, Init-Parameter und dergleichen deklariert. Der Vorteil dieses Ansatzes liegt darin, dass diese Eigenschaften somit unmittelbar an der Komponente selbst verändert werden. Beim Übersetzen des Projekts werden alle Einstellungen der Komponenten in den Deployment Descriptor übertragen, sodass der Deployment Descriptor Editor nach wie vor alle Einstellungen der Komponenten an zentraler Stelle anzeigt und sich der Benutzer diese nicht alle einzeln zusammensuchen muss. Auch die Einstellungen für Web Services bzw. EJBs können nun direkt innerhalb der Komponente deklariert werden. Diese Möglichkeit, eine EJB vollständig in einer Java-Klasse zu beschreiben, ist bereits ein Schritt in die Richtung, welche u.a. mit EJB 3.0 verfolgt wird.

Ein weiterer entscheidender Vorteil des Websphere Rapid Deployment besteht darin, dass bei einem Build einer mit derartigen Annotationen versehenen Komponente alle notwendigen Artefakte automatisch generiert und in den konfigurierten Testserver deployt werden. Der früher oft notwendige Neustart des Servers ist nun endlich nicht mehr erforderlich.

Ebenfalls ein Aspekt der Verteilung von Informationen ist die Möglichkeit, Ressourcen auf Applikationsebene zu definieren. In früheren Versionen des Werkzeuges wurde eine Data Source zu einer Applikation immer in einer zugehörigen Serverkonfiguration eingetragen. Bei der Entwicklung im Team musste sich somit jeder Entwickler selbst eine entsprechende Serverkonfiguration erstellen oder aber die Serverkonfiguration als zusätzliches Artefakt in der Sourcecode-Verwaltung abgelegt werden. Im RAD 6 können diese Ressourcen des Servers, wie Data Sources oder JMS Queues, dagegen auf Applikationsebene definiert und verwaltet werden. Ähnlich wie bei den Annotations ist also die Information zu einer Applikation bei der Applikation selbst abgelegt.

JavaServer Faces und Service Data Objects

Neben diesen Anpassungen, die das Werkzeug insgesamt runder wirken lassen, wurde insbesondere auch die Werkzeugunterstützung für Webanwendungen erheblich verbessert und erweitert. Hervorzuheben ist hier die Funktionalität für JavaServer Faces und Service Data Objects. Was im WSAD 5.1.2 schon sehr gut integriert war, aber noch nicht den vollständigen Funktions- und Spezifikationsumfang bot, ist nun im RAD realisiert. Dabei unterstützt der RAD durch verschiedene Editoren, Assistenten und Views die Erstellung von Webanwendungen, die auf JavaServer Faces aufsetzen. Bemerkenswert ist, dass der Quelltext der Artefakte nur in seltenen Fällen direkt bearbeitet werden muss. Von zentraler Bedeutung ist der JavaServer Faces Editor, über dessen Designansicht das Aussehen einer JavaServer Faces-Seite gestaltet wird, beispielsweise indem Webkomponenten aus der Palette View auf der Designfläche des Editors platziert werden. Die Anpassung der einzelnen Elemente einer solchen Seite erfolgt in der Properties View, die sämtliche Einstellungsmöglichkeiten einer JSF-Komponente in entsprechenden Masken aufbereitet. Die Properties View des RAD bietet also diejenige Funktionalität, die in den letzten WSAD-Versionen in der Attributes View verfügbar war.

Komfortabel ist auch die Einbettung einer so genannten Relational Record List in eine JSF-Seite. Mittels einer Relational Record List werden Daten einer relationalen Datenquelle in einer Webseite dargestellt. Beim Platzieren dieser Komponente wird ein Assistent gestartet, der den Entwickler durch die Konfiguration des Datenbankzugriffs führt und Informationen zur Darstellung der Ergebnisse abfragt. Aus diesen Informationen generiert der RAD passende SDO-Klassen, die dann in der JSF als Datenobjekte verwendet werden. Für den eigentlichen Zugriff wird dazu ein von IBM gelieferter JDBC Mediator verwendet. Solche komplexen UI Controls haben eine Reihe von Eigenschaften, die sehr übersichtlich in der Properties View dargestellt werden. So werden beispielsweise das Paging einer Record List festgelegt, Navigationskontrollen zu einer Tabelle hinzugefügt oder andere Dinge angepasst (Abb. 2). Der für das JavaServer Face und die erforderlichen Zugriffsklassen generierte Quelltext ist dabei aufgeräumt und sauber, so wie wir es bereits vom WSAD her gewohnt sind. Da alle Einstellungen im Sourcecode abgelegt sind, ließe sich die Seite alternativ auch per Texteditor erstellen – aber wer macht das heutzutage noch? Notwendige Meta-Informationen werden in gewohnter Weise in XMI-Dateien im Projekt abgelegt. Auffällig bei der Entwicklung von JSFs ist, dass der RAD keinen speziellen Editor für die JSF-Konfigurationsdatei faces.xml bietet. Ein solcher Editor ist jedoch überhaupt nicht notwendig, da alle in dieser Konfigurationsdatei abgelegten Informationen durch die verwendeten Assistenten und Views (z.B. Properties View) automatisch gepflegt werden.



Abb. 2: Display Options einer Relational Record List im Properties View

Die Liste der Verbesserungen und Erweiterungen ließe sich noch lange weiterführen. Insgesamt sind die einzelnen Features konzeptionell durchdacht und sehr gut in das Gesamtkonzept einer Eclipse-basierten Entwicklungsumgebung eingebettet. Die Aufteilung, wo welche Einstellungen vorzunehmen sind, ist dabei in sich schlüssig, sodass man nicht lange suchen muss, um die entsprechenden Eigenschaften zu editieren.

Fazit

Zusammenfassend lässt sich sagen, dass sich trotz der organisatorischen Anpassung – Websphere Studio Application Developer wird zu Rational Application Developer – für den bisherigen WSAD-Kenner ein neues Major Release präsentiert, das zusammen mit der mitgelieferten Testumgebung des WAS 6 ein harmonisches Werkzeug bietet. Die bereits bekannte Funktionalität wurde den aktuellen Spezifikationen und Standards entsprechend erweitert und verbessert. Der RAD ist damit ein Entwicklungswerkzeug, das für die Erstellung von J2EE Applikationen – nicht nur für IBM WebSphere Application Server – bestens geeignet ist. Für den bisherigen WSAD-Benutzer erschließt der RAD neue Bereiche des Softwareentwicklungszyklus zumindest zum Teil (Visualisierung mit UML, RUP, Code Qualität). Darüber hinaus wurde die Unterstützung bei der Entwicklung für Frameworks (Struts, JSF) und Websphere Portal weiterentwickelt.
Wie für ein „Punkt Null“-Release typisch finden sich hin und wieder noch Ecken und Kanten im Werkzeug, die aber jedoch mit einem der nächsten Fixpacks bereinigt sein dürften. Die täglichen Entwicklungsaufgaben lassen sich mit dem Werkzeug gezielt und effizient erledigen. Grundlage dafür bildet Eclipse 3 ebenso wie die vielen zusätzlichen Funktionen, die sich sowohl konzeptionell als auch von der Bedienung her in die IDE sehr gut einfügen.

Über den Autor

Michael Müller ist Consultant und Trainer bei ARS Computer und Consulting (www.ars.de) in München und im Unternehmensbereich Application Development und J2EE-Technologien tätig.

Steckbrief

IBM Rational Application Developer for WebSphere Software V6.0

Betriebssysteme

• Windows 2000 Professional (SP3 oder 4), Windows 2000 Server (SP3 oder 4), Windows 2000 Advanced Server (SP3 oder 4), Windows XP (SP1 oder 2), Windows Server 2003 Standard, Windows Server 2003 Enterprise
• Red Hat Enterprise Linux Workstation, Version 3.0 (alle Service Packs), oder SUSE LINUX Enterprise Server, Version 9 (alle Service Packs)

• J2EE 1.2, 1.3, 1.4
• WebServices WB-I 1.0
• Struts 1.0.2 und 1.1
• JavaServer Faces 1.0
• Portlet Development für WebSphere Portal und JSR 168 Portlets
• Service Data Objects (SDOs)
• XML, XSLT, DTD, XML Schema, XPath
• JUnit, ANT
• UML 2.0 (Klassen- und Sequenzdiagramme)
• Rational Unified Process
• IBM WebSphere Application Server Version 4.0, 5.0, 5.0 Express, 5.1, 5.1 Express, 6.0
• IBM WebSphere Portal 5.0 und 5.1
• BEA WebLogic Server, Version 6.1, 7.0 und 8.1 (mit IBM Rational Deployment Toolkit for WebLogic Server)