UML-Tools 2006

Auf ins Modell-Land
Kommentare

Die Toolwelt ist in Bewegung. Die Hersteller versuchen mit den großen IDEs wie VS, BDS (Delphi 2006) oder Eclipse Schritt zu halten, indem sie eine Integration mit denselben anstreben. Auf der anderen Seite erhalten die autonomen Tools Auftrieb, indem bewusst Design von der Implementierung entkoppelt und neue Produkte differenziert werden. Schwerpunkt dieser Marktübersicht sollen Generatoren und die Architekturunterstützung sein.

Programmieren geht über studieren oder eben doch modellieren. Leistungsfähige Tools für eine durchgängige Entwicklung mit Teamunterstützung sind seit UML 2 mehr denn je unter Fachleuten gefragt. ITArchitekten sprechen von MDA (Model Driven Architecture) und MDD (Model Driven Development), die eine konkretere Generierung von Schnittstellen und Code aus Profilen erlaubt. Demzufolge bieten die Tools, nebst der Codegenerierung, auch das Erstellen von Code aus Patterns an, zusätzlich lassen sich Metriken und Refactoring-Techniken erkennen.

Codegenerierung der Architektur

Architektur auch deshalb, weil der Begriff SOA (Service Oriented Architecture) zum neuen Mantra wird; ähnlich dem Miniatur-Wunderland der Modellbahnfreunde. Wenn man mit IT-Architekten spricht, lassen sich eigentlich die meisten Begriffe und Zauberwörter in die drei Grundbegriffe Struktur – Funktion – Prozess einteilen. So auch die Begriffe MDA und SOA. Sowohl SOA als auch MDA heben die Plattformneutralität hervor. Wobei ich MDA eher zum Entwicklungsprozess zähle, aus dem mit SOA dann eine serviceorientierte Zielplattform entsteht! Die Plattform wiederum kann der Entwickler als Struktur mit einer Abbildungsvorschrift aus einem PSM generieren und dann mit Funktionalität bereichern. Man beginnt nach der Analyse mit der Erstellung des Designs oder einer Referenz mit einem konventionellen UML-Tool. Das Tool sollte fähig sein, mit UML-Profilen und OCL (Object Constraint Language) arbeiten zu können. Durch einen XMI-Export erhält man eine austauschbare Designdatei (PIM), die man mit dem gewünschten UML-Profil, einem MDAGenerator, füttert.

Der Generator transformiert die Designdatei mit dem Profil nach spezifizierten Abbildungsregeln (Templates) in einen konkreten Architekturrahmen als typisierte Pakete. Nun hat man das PSM, das immer noch ein Modell ist (Modell-Modell Transformation). Mit der weiteren Generierung wird dann erstmals aus dem PSM Code im Sinne eines Implementierungsrahmens erzeugt (Modell-Code-Transformation). Die geschützten Bereiche sind zunächst noch leer. Es erfolgt dann die Entwicklung der eigentlichen Fachlogik in den Klassen, die mit einer weiteren Generierung durch Interpreter oder Compiler zum ausführbaren Code bezüglich der gewählten Plattform führt. Als Abkürzung MTGCI könnten die Schritte wie folgt sein:

• Modelliere das PIM (Fachanalyse)
• Transformieren auf ein PSM (OO PSM, Component PSM, SOA PSM )
• Generieren von Code aus dem PSM (SOAP, Corba, RPC, JMS, RMI, Sockets etc.)
• Codieren der Fachlogik
• Integrieren in die Plattform (.NET, J2EE, Linux, ARM etc.)

Die meisten Entwicklungstools sind erstellt worden, um Code zu erzeugen und nicht, um Modelle zu implementieren. Mit MDA sind wir jedoch näher bei den ausführbaren Modellen. Patterns und Profile lassen sich hier als eine Art Vermittler zwischen Modell und Code einsetzen, da man den Fokus auf die Architektur legt. Eigentlich möchte man ja programmieren, wie ein T1 im Film Terminator II funktioniert. Durch das Erarbeiten der Fachlogik erhält man ein Modell, das mithilfe der „Liquid Metal“-Technik zum Code mutiert. Also eine Maschine ist selbst in der Lage, durch Beobachten der Fachwelt die Struktur und Funktion des Codes zu bauen. Der T1 als Developer verkörpert also in ca. 150 Jahren ein „laufendes“ Programm innerhalb einer autonomen Plattform.

Abb.1: Das UML-2-Testumfeld für die Tools

Gegenwart: Wird man nun weniger programmieren und vermehrt modellieren, oder induziert die Toolindustrie wieder neue Bedürfnisse? Beides, denn eine stärkere Formalisierung ist sowohl der Wunsch von uns geplagten Entwicklern wie auch die Bedingung der Industrie, Tools und Plattformen zu vereinheitlichen. All diese Vorhaben sind in UML 2.0 mit dem Ziel behaftet, ausführbare Modelle (MDA) auf eine Zielplattform (SOA etc.) zu generieren. Heute kommt man auch selten auf die Idee, den Maschinencode zu modifizieren. In der Zukunft wird dann auch das Manipulieren von Code vermehrt wegfallen, da nur noch das Modell zählt. In Tabelle 1 habe ich die beiden Konzepte (MDA – SOA) gegenübergestellt. Somit wird die Beziehung der beiden etwas klarer.

Tabelle 1: Gegenüberstellung von MDA und SOA

Tools zu beschreiben ist die eine Seite der Medaille, die andere ist, vernünftige Tests aufzustellen. Damit man einigermaßen eine Prüfstruktur erhält, wurden bei jedem Tool drei Tests angebracht. Als erste Stichprobe sei die Notation zum Paketdiagramm näher zu durchleuchten. Wenn UML 2 draufsteht, sollte auch etwas drinnen sein. Denn nach UML 2 sollte die Notation gemäß Abbildung 1 vorhanden sein. Dann wird der Import via XMI-Schnittstelle getestet, da man für den Austausch der Modellinformationen über Toolgrenzen hinweg als XML Metadata Interchange (XMI) einsetzt. Im Anschluss wird die Codegenerierung näher betrachtet. Viele Tools besitzen mittlerweile auch eine sprachengebundene Typisierung der Komponentenbibliothek an (VCL, MFC, FCL etc.), somit wird die Generierung direkter an den Zielcode gebunden. Dies scheint logisch, da die Toolhersteller Bibliotheken als eine Art „Code Patterns“ aufbereiten, welche sich dann bei Bedarf abrufen lassen, wie mit Streams, String- Buildern oder Collections zu beweisen ist.

Aufmacherbild: green field and blue sky von Shutterstock / Urheberrecht: Pakhnyushcha

[ header = Seite 2: Eine Referenzarchitektur ]

Eine Referenzarchitektur

Wir bauen uns nun ein Paketdiagramm, das sozusagen als Referenz zu den einzelnen Tools dienen soll. Als erstes nehmen wir die erhörten Geschäftsprozesse auf (Hauptund Teilgeschäftsprozesse abgrenzen, Schnittstellen zwischen Prozessen festlegen, Geschäftsprozesse in einem Ist-Modell abbilden) und teilen diese in drei Schichten (Layer) auf. Exemplarisch dient eine DelphiWebStart-( DWS-)Anwendung. In der Regel ist der höhergestellte Layer direkt vom unteren Layer abhängig. Er ist deshalb vom darunter liegenden Layer abhängig, da er ihn nur aufrufen kann, wenn er seine Implementierung kennt. Was nun, wenn der Logic Layer unabhängig vom Data Layer sein muss. Denn in einer Enterprise-Applikation will man unabhängig von der Datenquelle oder einer Fachlogik werden. Hier hilft das Prinzip der Umkehrung der Abhängigkeit weiter (Dependency Inversion).

Mit einem zusätzlichen Interface oder einer abstrakten Klasse pro Schicht sind wir unabhängig von der Datenquelle, um z.B. Oracle durch InterBase zu ersetzen oder sogar eine redundante Datenquelle in der unteren Schicht einzusetzen. In Abbildung 2 ist sichtbar, dass die Abhängigkeit durch den Einbau von Schnittstellen entkoppelt ist, obwohl die Aufrufkaskade nach wie vor nach unten erfolgt. Aber eben indirekt durch ein Höherstufen der Schnittstelle, ähnlich dem „Design by Contract“.

Abb. 2: Eine Referenzarchitektur im EAIBereich

Eine EAI-Architektur sollte folgenden Kriterien genügen:

• Die realisierende Klasse erbt von einer höher liegenden Schnittstelle
• In der LogicDomain sind nur typisierte DataSets zugelassen
• Logik, Prüfen und Berechnung erfolgt in der konkreten Klasse
• Die Methoden erscheinen als Public-Services
• Der Application Server besteht aus den Schichten LogicDomain und DataAccess

Unsere Klasse TXMLStore hat nur ein property pBuffer, das die Größe des Buffers einstellen lässt. Zudem besteht eine Assoziation zur Klasse TFileStream in der Unit. Die entsprechenden Getter und Setter werden automatisch erzeugt. Andere Tools haben beim Erzeugen dieser Klasse schon mehr Mühe, denn auf die richtige Konfiguration und Instrumentalisierung kommt es an: 

Type
TXMLStore = class (TInterfacedObject, IDomainService)
private
FpBuffer: PChar;
function getFieldStr(field: Tfield): string;
procedure writeData(stm: TFileStream; fld:TField; s:string);
procedure writeFileBegin(stm: TFileStream; dSet: TDataSet);
procedure writeFileEnd(stm: TFileStream);
procedure writeRowEnd(stm: TFileStream; isTitle:boolean);
procedure writeRowStart(stm: TFileStream; isTitle:
boolean);
protected
procedure SetpBuffer(abuffer: PChar); virtual;
procedure writeString(stm: TFileStream; s: string); virtual;
public
constructor create;
destructor destroy; override;
procedure DatasettoXML(dSet: TDataset;
fileName: string); virtual;
property pBuffer: PChar read FpBuffer write SetpBuffer;
end;

Wichtige Tools im Überblick

Nach diesem explorativen Architekturstreifzug wollen wir die erworbenenKenntnisse innerhalb der Tools auch anwenden. Alle Tools kennen Reverse Engineering und Patterns. In diesem Bericht erfahren Sie Aktuelles von:

• Enterprise Architect von Sparx
• ModelMaker von ModelMakerTools
• Together von Borland
• objectiF von microTOOL
• innovatorAOX 2006 von MID
• Describe von Embarcadero
• Rational Rose von IBM
• StP/Ameos von Aonix

XMI und UML 2.1

Angenommen, wertvolle Diagramm- oder Codesubstanzen sind in ein Fremdtool zu importieren. Bei folgendem Code ist dies kaum möglich, da sprachspezifische Konstrukte wie eine Klassenmethode, Konstruktoren oder ein try..finally, ein Parser unterschiedlich interpretiert. Die Klassenmethode TAddressList.DBReadAllRelatedToObject(oPerson) aus einem OO-Framework besitzt die Fähigkeit, eine Adressliste anhand der übergebenen Person basierend auf dem relationalen Datenmodell zu erstellen. Eine Klassenmethode ist über eine Klassenreferenz oder eine Objektreferenz aufrufbar. Diese Konstrukte sind so sprachabhängig, dass als nächste Abstraktionsebene nur ein UML-Modell für den Austausch via XMI in Frage kommt. Somit kann der Entwickler aus dem Diagramm wieder in seiner Sprache die spezifischen Konstruktoren oder Klassenmethoden generieren lassen!

oPerson:= TPerson.Create;
oAddressList:= TAddressList.Create;
try
oPerson.Person_ID:= 30;
oAddressList:= TAddressList.DBReadAllRelatedToObject
(oPerson);
for i:= 0 to oAddressList.Count-1 do
S_MBox(oPerson.LastName+‘ ‚+oAddressList.Adresses[i].
City);
finally
oPerson.Free;
oAddressList.Free;
end;

XMI ist ein von der Object Management Group (OMG) verabschiedeter Standard für den Modellaustausch. Der Name zeigt es bereits deutlich: XMI ist ein Mitglied der XML-Sprachfamilie. Die XMI-Norm definiert für das UML-Metamodell eine XML Document Type Definition (DTD). Sie stellt die Grammatik der Sprache zur Verfügung.

Es ist festzustellen, dass die meisten UML-Tools sich betreffend der verfügbaren Diagramme und Modellinformationen einander nähern. Auch wenn zum Beispiel mit Stereotypen oder Profilen die Notation erweiterbar ist, die Elemente normieren sich. Diese Tatsache führte zum Bedürfnis, diese Modelldaten auch unter den Tools austauschen zu können.

Abb. 3: Harter Testfall als Sequence für den XMI-Austausch

Auch in der aktuellen Testreihe sind die Ergebnisse ernüchternd. Mittlerweile gibt es XMI 1.0, 1.2, 1.3 und 2.0, jedoch beim Export sind nicht alle Tools fähig, die Version zu definieren. Eine Option bezüglich der DTD/Schema sollte wahlweise vorhanden sein, wenn nicht, kann der Import schon mal an der fehlenden Definition (!DOCTYPE) scheitern. Für die Analyse hilft hier ein XMLSpy weiter. Ohne Namen zu nennen, gibt es auch Tools, die den eigenen Export nur mangelhaft importieren. Da beispielsweise Klassenstrukturen nicht immer baumartig sind, ergibt sich nicht unbedingt ein hierarchischer Dokumenttyp. Vielmehr kann das Klassendiagramm ein Netz sein, in dem sich mehrere Kanten und Knoten bilden lassen. Das Problem bei der Umwandlung kann nun auftreten, weil eine Assoziation nicht in eine endliche Baumstruktur zu überführen ist, da die Kardinalität 1 oder * ist.

Daher wird gemäß DTD die Kardinalität einfach auf 0 gesetzt und erlaubt so beliebige Ableitungen. Einfach gesagt, besteht eine XMIDatei aus einem Header- und einem Content-Bereich. Der Header beinhaltet das Metamodell und der Content demzufolge das Modell mit den zugehörigen Elementen. Das Metamodell hat als oberste Klasse das Modellelement. Diese Elemente sind dann pro Diagramm konkretisierbar, wobei hier das Problem des Layouts zum Tragen kommt, die Elemente sind beim Import verschieden positioniert. Als Testfall habe ich nebst dem Paketdiagramm in Abbildung 2 auch das Sequenzdiagramm in Abbildung 3 herangezogen. Hier werden vor allem die UML-Erweiterungen wie conditions [], constraints {} oder stereotypen <<>> zwischen den Tools erstaunlich kreativ interpretiert. Bis alle Tools die XMI 2.0 mit den nötigen Optionen unterstützen, wird wohl wieder ein Jahr vergehen. Denn die Möglichkeit, Strukturen und Modelle auszutauschen, kann auch strategische Bedeutung haben: nämlich sich als Unternehmen nicht von den Herstellern der eingesetzten Tools abhängig zu machen.

[ header = Seite 3: Enterprise Architect 5.0 ]

Enterprise Architect 5.0

Enterprise Architect ist ein Analyse-, Design- und Entwicklungs-Tool, das auch für die Datenmodellierung geeignet ist. Es unterstützt in drei Editionen den Software-Entwicklungsprozess vom Requirements Engineering über Analyse/Systemdesign und der Entwicklung bis hin zum Testen. Es ist immer wieder erstaunlich, wie vielseitig das Tool trotz seiner Kompaktheit ist. EA unterstützt alle 13 UML-2.0-Diagramme und bietet weitere Features für die Softwareentwicklung, wie zum Beispiel Round Trip Code Engineering, Database Modeling, Document Generation, HTML-Reporting, MDA Style Transformer, ist Multi-User-fähig, hat eine umfangreiche Sprachunterstützung und eine umfassende Versionskontrolle.

Die sorgfältig aufgebaute Dokumentation ist ein weiteres Highlight, die einem Vergleich mit Fachbüchern standhält. Beim Testen einer MDA-Transformation lässt sich mithilfe der Online-Dokumentation einiges in Erfahrung bringen. Der „MDA Style Transformer“ hilft, vorlagenbasiert ein plattformunabhängiges in ein plattformspezifisches Modell zu überführen.

Abb. 4: Sparx Enterprise mit raffinierten Sichten

Konkret sind folgende Profile möglich:

• DDL transformiert Klassenelemente in die spezifischen Tabellen
• EJB Entity transformiert Klassenelemente in die Pakete mit den zugehörigen Beans
• EJB Session und Java-Pakettransformation
• C# konvertiert einen PIM zu einer Standard-C#-Implemenierung
• XSD wandelt PIM Elemente zu den XSD-Elementen

Hier haben wir ein Tool in unserer Runde, das in der 5er-Version auch diverse weitere sinnvolle Vereinfachungen in der Benutzerführung (zum Beispiel Zusammenfassung von Menüpunkten) erreicht hat und sogar Reverse Engineering von Binärmodulen in Bytecode, zum Beispiel Java Archive (.jar), .NET PE Files (.exe, .dll) und Intermediate-Language-(.il-)Module erlaubt. Ein verbesserter Abgleich von Verzeichnisstruktur und XMI-Dateien mit dem Vergleichswerkzeug (Diff) runden das Bild ab. Wobei ich bei einem letzteren XMI-Import auch schon mit der Fehlermeldung, das Element sei nicht im DTD/Schema, kapitulieren musste.

Der Enterprise Architect ist in der aktuellen Version ausschließlich in englischer Sprache erhältlich, kommt aus Australien und unterstützt Delphi von Hause aus, hat aber nie die Mächtigkeit eines ModelMaker. Die Version 4.1 gibt es auch als deutsche Version bezüglich des GUI. Eine Unterstützung der grafischen Modellierung in allen Diagrammen durch automatische Layouts und durch permanente Semantik- Checks sowie individuelle Sichten (Views) machen das Tool zu einem echten Favoriten. In Abbildung 4 sind die Views durch den Explorer auf der rechten Seite zugänglich. Die jeweiligen Fenster sind mit zugehörigen Registern weiter unterteilbar, ohne die Übersicht zu verlieren.

Steckbrief Architect

EA unterstützt den Life-Cycle, der den Software-Design und den gesamten Entwicklungszyklus umfasst: Prozessanalyse, Systemanforderungen, Modelle für dynamische Abläufe, Komponenten und ihre Installation, Projektmanagement, Design der Benutzeroberflächen, Testen, Wartung etc.

Nach einer intensiven Weiterentwicklung des Tools verbindet auch EA die Datenmodellierung mit UML nach dem Credo: objektorientiert entwickeln – relational speichern. So können Sie die Anwendungsentwicklung noch flexibler gestalten. Das erstaunliche ist auch die Preispolitik. Eine Mehrfachlizenz von Enterprise Architect (je nach Edition) kostet unter 200 Euro. Interessant auch, dass es für den EA auch eine kostenlose „Read-only“-Version gibt. Geben Sie diese Version an Ihre Kunden und Mitarbeiter weiter und zeigen Sie ihnen, wie gut man im Projekt vorankommt. Es ist ein integriertes Werkzeug, das Sie durch alle Phasen mit allen Diagrammen des Entwicklungsprozesses begleitet.

Abb. 5: Umfangreicher RTF-Reportgenerator bei Sparx

• Modellierungsstandard UML 2 wird voll unterstützt
• Diagramme, Quellcodes und Dokumentationen mit Reportgenerator
• Native CVS-Untersützung (Versionskontrolle)
• Testmöglichkeiten mit Unit-, System- und Akzeptanztest innerhalb von Szenarien

Ein Werkzeug ist immer so gut wie der Handwerker, der es benutzt. Durch die einfache Handhabung (Drag & Drop, Kontextmenüs, gezielte Hilfe) kann es Anfängern und Experten ein vollständiges Roundtrip Engineering für alle Phasen des Entwicklungsprozesses ermöglichen.

Beim Testen sind fünf Stufen verfolgbar: Unit-Tests, Integrationstests, Systemtests, Akzeptanztest und Szenarien, die dann in eine Wartung und Fehleraufzeichnung münden können.

EA verfügt über eine starke Dokumentationskomponente – der integrierte Dokumentationsserver erzeugt dynamisch RTF-Dokumente und wird über einen umfangreichen Formatierer angesprochen (Abb. 5). Wir hatten schon einmal ein ganzes Systemhandbuch daraus generiert. Neu in der Version 5 ist ein WYSIWYG-Vorlageneditor für RTF-Dokumentation. Die Dokumentation lässt sich an firmenspezifische Anforderungen mit einer Optionssprache leicht anpassen. Die Templates lassen sich durch Rekombinieren und Bookmarks wieder verwenden. Die flexiblen Ausgabeoptionen und die RTF-Bookmarks dienen der verbesserten Dokumentverknüpfungen in Word.

[ header = Seite 4: ModelMaker 8.1 ]

ModelMaker 8.1

Eigentlich wird ein CASE-Tool nicht angeschafft, um Software zu bauen, hier sind die entsprechenden Entwicklungsumgebungen vorhanden. Vielmehr lässt sich CASE in den Entwicklungsprozess integrieren, um diesen zu überwachen, zu steuern, zu entwerfen, zu dokumentieren und zu verbessern.

ModelMaker ist ein alter Bekannter, ein Tool, das sich vollständig in Delphi integrieren lässt und trotzdem nicht zu kompliziert ist. Schnell geladen und schlank im Umgang. Und genau das ist meines Erachtens der Angelpunkt für Qualität: so einfach wie möglich, so kompliziert wie nötig. Hinter dem Tool steckt eine engagierte Community, die in den zugehörigen Foren den richtigen Input liefert und somit das Tool ständig mit Feedback füttert und kontinuierlich verbessert, wie auch ein chinesisches oder russisches Manual verdeutlicht.

Mittlerweile gibt es das Tool nebst der bekannten Pascal-Edition auch in einer C#-Edition. Ein großer Teil der Delphi 2005 für Win32 und .NET-Syntax wird unterstützt und mit dem Syntax Highlighting Schema ergänzt. Die Version für Delphi 2006 (Delphi 10!) ist angekündigt. ModelMaker hat in der aktuellen Version 8.1 folgende Leistungsmerkmale:

• IDE-Integration mit Delphi 1 bis 2005
• IDE-Integration mit Visual Studio 2003/2005 (nur C#-Edition)
• Method-overload-Support
• Multilevel Undo/Redo im Diagramm-Editor
• Qualifizierte Relationen zwischen den Symbolen möglich
• Design Patterns, die mit aktiven Agenten den Code verwalten
• Parametrisierbare Codetemplates, die eigene Patterns ermöglichen
• Code-Übersicht und Navigation (aus dem bekannten Code Explorer)
• Ausgebaute Refactoring-Möglichkeiten wie „Extract Method, Extract Class (Interface), Encapsulate Field (Convert Field to Property), Convert to Const“ und vieles mehr (mehr als Delphi 9 kann)
• Ausdrücke sind mit „Constraints“ in der OCL formulierbar
• Verbesserte Form der Dokumentation innerhalb des Code
• Aktuelle MMToolsApi Version 9 mit zusätzlichen Schnittstellen

Abb. 6: Das ModelMaker-GUI mit Paketdiagramm (Unit-Sicht)

Neu ist auch die Record-Unterstützung beim Code-Import und die entsprechende Abbildung im Modell. Gerade die letzten vier Punkte bereichern das Tool, ohne komplizierter zu werden. Die Dokumentationshilfen beschränken sich auf das Wesentliche, wartbaren und verständlichen Code zu produzieren. Wirklich praktisch wäre eine iterative Suchfunktion nach dupliziertem Code inklusive Vorschlag der Singularisierung.

ModelMaker hat ein wirklich gut durchdachtes GUI, das die nötigen Ansichten strukturiert und in mehreren Bereichen darstellt. Die einzelnen Rahmen sind auch kombinierbar, sodass sich aus der Unit-Sicht eine Klasse genauer mit dem zugehörigen Diagramm betrachten lässt. Die Sichten sind in einem Kontext zueinander angepasst, d.h. zu den Files gehört die Unit-Sicht, zu den Klassen der Code-Editor und zum Diagramm der Diagramm- Editor mit den Symbolen. Die einzelnen Member der Klasse sind in Abbildung 6 unten links ersichtlich, die dann jeweils durch einen aktiven Link zu den erwähnten Sichten ihre Member wechseln. Das Paketdiagramm zeigt übrigens die bekannte InterBase „MastApp“ aus den Delphi-Demos. Im Kontextmenü rechts unten wird ein Versionsvergleich zwischen dem externen File und dem internen Modell demonstriert.

An Diagrammen sind alle der UML 1.x wie Use Case, Activity, Class, State Event, Sequence oder Package vorhanden, an UML 2 ist noch wenig vorhanden. Das Package glänzt mit einer umfangreichen Analyze der Units (Unit Dependencies Analyzer), der mit dem zugehörigen Wizard alle Abhängigkeiten auf Stufe Interface und Implementierung grafisch, eben als Package, aufbereitet. Nur diese eine Funktion macht das Tool schon beinahe unentbehrlich. Die große Stärke liegt bei den Möglichkeiten, ein Klassendiagramm zu erstellen.

Abb. 7: MM mit dem Pattern Generator

Einzelne Typen und Elemente besitzen umfangreiche Filter und gezielte Codegenerierung, die sich vom MM-Editor aus nach Delphi steuern lassen. Auch bei den Templates macht MM nicht halt: Diese Einstellungen lassen sich in den „Editor Templates“ wieder verwenden und lassen sich auch laufend wie Code Snippets aktualisieren. Bei den Aktivitätsdiagrammen unterscheidet MM zwischen den Aktivitätszuständen (action state) und den restlichen Pseudozuständen wie Initial, Final, Decision, Junction, Dynamic Choice, Synchronization Bar und Transitions. Es eignet sich deshalb auch für die Modellierung von Geschäftsprozessen, jedoch nicht in der UML-2-Notation. Beim Pakettest werden <access> und <import> folgerichtig unterschieden.

Generator mit Patterns

ModelMaker ist schnell und kompakt, diese Geschwindigkeit wird durch die Modeling Engine erreicht. Diese Engine speichert und verwaltet alle Beziehungen zwischen den Klassen und deren Attribute. Das Umbenennen einer Klasse oder das Verändern eines Vorfahren aktiviert unmittelbar den Codegenerator, den man als Option automatisch oder manuell einstellen kann. Aufgaben wie das Hinzufügen eines Event, eines Property oder einer Zugriffsmethode werden als Skelette auf Mausklick hin angelegt. Der Hauptunterschied zwischen MM und anderen CASE-Tools ist sicher das Design, welches sich nahtlos in Delphi integriert und 100-prozentig OP-Code generiert. Diese hohe Übereinstimmung ermöglicht es, Änderungen in beide Richtungen kompromisslos zu aktualisieren und zusätzlich die Dokumentation zu erstellen. Auch die Möglichkeiten von Refactoring sind beachtlich. Vielfach will man im Zuge der Paketbildung eine Klasse von einer Unit in die andere Unit verschieben. Oder einige Methoden müssen sich in einer neuen Klasse wieder finden, d.h. man lagert sie in eine Service-Klasse aus. Es ist zum Beispiel nötig, eine Klasse näher an eine bestehende Klasse anzubinden, d.h. wir verschieben eine Methode und ändern die dazugehörigen Aufrufe. Bei den eingebauten Design Patterns bildet MM nicht nur eine statische Struktur oder ein Codefragment ab, sondern es besteht ein aktiver Link von Design zum Code, der unmittelbar reflektiert wird. Realisiert ist auch die Unterstützung von Design Patterns im laufenden Code. Was meint nun laufender Code? Angenommen es besteht eine Instanziierung einer Klasse. Nach weiterer Analyse kommt man zum Schluss, die Instanz darf nur einmal existieren. Nun ist es in MM möglich, den Aufruf mit einem Singleton Pattern zu erweitern, um somit die einzig mögliche Existenz dieser Klasse sicherzustellen. Oder im Zuge einer Änderung der Architektur benötige ich einen Mediator, der basierend auf einer Objektinstanz die lose Kopplung von Objekten durch das Vermitteln von Methodenzeigern (in .NET Delegates) fördert, wie der Dialog in Abbildung 7 verdeutlicht – ein typisches SOA-Muster.

Abb. 8: MM beim Erzeugen des Modells

Als weiteres Beispiel sei ein Interface-Design erklärt, das aus folgendem importierten Code (Textdatei genügt) das Diagramm in Abbildung 8 einwandfrei generiert und umgekehrt:

Type
ISpeak = interface (IUnknown)
[‘{B7F6F015-88A6-47AC-9176-87B6E313962D}‘]
procedure sayHello; stdcall;
end;
IShout = interface (IUnknown)
[‘{19A231B1-269F-45A2-85F1-6D8A629CC53F}‘]
procedure shout; stdcall;
end;
TEnglish = class (TInterfacedObject, ISpeak)
public
procedure sayHello; stdcall;
end;
TFrench = class (TInterfacedObject, ISpeak, IShout)
public
procedure sayHello; stdcall;
procedure shout; stdcall;
end;
TTRex = class (TInterfacedObject, IShout)
public
procedure shout; stdcall;
end;

Die Dokumentation in MM8 ist vorbildlich und entspricht fast einem Lehrbuch mit entsprechenden Ausführungen und konkreten Beispielen, wobei dann viele Detailfunktionen nicht erwähnt sind, sodass man versuchsweise vorgehen muss:

• Das Benutzerhandbuch beinhaltet die vollen Installationsdetails, die Basiskonzepte und eine Startdemo als Datei. Die Beispiele sind mit Quellcode vorhanden.
• Das Design-Pattern-Dokument erläutert mehr oder weniger ausführlich den Einsatz von Patterns und zeigt Schritt für Schritt den dazugehörigen Code.
• Die GUI-Referenz legt den Schwerpunkt auf die Funktionalität und die Bedienung.

Von MM ist eine 7 MB große Demo-Version zuzüglich MM-Tools auf der Website erhältlich, die nebst der vollen Funktionalität 45 Tage gültig ist. Zum Evaluieren von ModelMaker empfiehlt sich das Download und am besten starten Sie gleich mit dem Importieren eines ganzen Projektes. Während der Installation bindet sich MM selbstständig in das Delphi- Menü ein. Nach dem Importieren lassen sich die Klassen oder Pakete mit dem „Visualization Wizard“ gleich als Test darstellen und mit dem zugehörigen Editor weiter bearbeiten.

Steckbrief ModelMaker

[ header = Seite 5: Together Technologien ]

Together Technologien

Da ist es also, das Tool, das Borland gehört und in Delphi 2006 als Kerntechnologie vollständig integriert sein soll. Natürlich gibt es noch die drei dedizierten Editionen Architect, Designer und Developer (2005) und zusätzliche Ausgaben für die Integration zu Eclipse, VS und JBuilder/Together. Doch der Reihe nach.

Beim Architekten steht die Teamorientierung an erster Stelle. Das Tool ist eine Weiterentwicklung von Together ControlCenter und stellt die umfassendste Lösung der Together-Produktlinie dar. Mit dem Architekten bringen Sie Fach- und IT-Abteilungen durch den übergreifenden Einsatz leistungsstarker grafisch orientierter Modellsichten zusammen. Mit der umfassenden Unterstützung für Geschäftsanalytiker, Designer, Architekten und Entwickler bietet der Architekt eine konfigurierbare, rollenbasierte Plattform mit den passenden Funktionen für alle Rollen in Entwicklungsunternehmen. Struktur und Aufbau erinnern an Rational Rose, jedoch ist die Bedienung wie der Kontext viel intuitiver. Die Dreiteilung Explorer, Designer und Editor ist ein Defacto- Standard bei vielen Tools. Together hilft dem Softwareentwicklungsteam dabei, in kurzer Zeit anpassbare, qualitativ hochwertige Softwarelösungen zu entwickeln, die das Modellieren von Geschäftsprozessen, Daten und Anwendungen, die Visualisierung der Anwendungen sowie umfassende Audits und Metriken für Modelle und Code ermöglichen. Die Funktionalität ist entsprechend mächtig.

Abb. 9: Metriken in Together

Die Metriken sollen getestet werden. Audits und Metriken dienen der statischen Analyse von Code. Die Anwendung muss zur Analyse nicht gestartet werden. Die Metriken vereinfachen die Quantifizierung der Softwareentwicklung. Hier mal ein Auszug aus einer Together-Metrik, die man Cyclomatic Complexity CC oder Decision Points nennt und die verschiedenen Ausführpfade einer Routine „misst“. In Abbildung 9 entsteht die Zahl 4, welche nach McCabe noch tolerierbar ist. Auch die einfache Integration mit anderen Tools wie zum Beispiel Delphi IDEs zählt zu den Stärken von Together: Hier muss man wissen, dass Together nicht Repository-, sondern File-orientiert arbeitet. Somit lassen sich Zugriffe auf die Informationen von anderen Werkzeugen relativ zügig realisieren.

Auch der Designer ist eine plattformübergreifende (weil in Java) UML-Lösung für Business-Analytiker und alle Personen, die in einer Umgebung arbeiten, in der visuelle Modelle Anforderungsdefinitionen und die Kommunikation über die Softwarearchitektur und den Softwarecode optimieren können. Beim Developer stehen der Code und die Struktur im Mittelpunkt. Together bietet analog Rose die Möglichkeit, unterschiedliche Sichten auf die Anwendung zu definieren und alle Informationen dieser Sichten im Tool mit einem Hyperlink frei zu verknüpfen. Generell bieten die Together Technologien Folgendes an:

• Optimierung der Architektur durch UML-Modellierung
• Nahtlose Integration vieler Werkzeuge
• Automatisierte Dokumentation in Excel, Word, HTML
• Unterstützung bekannter Designmuster
• Refactoring ermöglicht schnelle Codeoptimierung
• Generieren von Code direkt zu VS, Eclipse etc.

Together hat die ersten Tests für den Import und Export bezüglich XMI gut überstanden, bei den Editiermöglichkeiten bezüglich Layout sind noch einige Rätsel aufgetaucht, die aber mit der Erfahrung gelöst werden.

Abb. 10: Integration von Together in Delphi (Paketdiagramm)

Together in Delphi 2006 und VS

Delphi 2006 wird die komplette Unterstützung für UML besitzen und die UML-Standards: UML 1.5 und UML 2.0 sowie die Sprachen: Delphi für Win32, VCL.NET und Delphi.NET als auch C# anbieten. Auch das Framework ECO III (Delphi.NET, C#) bietet mit Together vier Techniken an:

• OCL-Support
• State Machines
• Audits und Metriken
• Dokumentationsgenerierung

Endlich haben auch die Diagramme an der Zahl zugenommen (Class, Use Case, Sequence, Communication, State Machine, Activity, Component, Deployment, Composite Structure). Als ein Teil des Borland Developer Studio enthält Delphi 2006 neben den Programmiersprachen Delphi Win32 und Delphi.NET auch eine komplette RAD-Unterstützung für die Programmiersprachen C++ und C#, die mit Together interagieren. Together Designer integriert sich nahtlos in Visual Studio .NET und bietet alle für Analytiker erforderlichen Modellfähigkeiten an, die zur eindeutigen Definition der Softwareanforderungen und für die einfache, effektive Generierung des Codes notwendig sind. Damit sollte man sicherstellen, dass der entwickelte Code den festgelegten Kriterien entspricht. Die Hauptfeatures (gilt teilweise auch für Eclipse):

• Sprachunabhängige Unterstützung von UML-1.5- und UML-2.0-Diagrammen
• Modellierung von Software und Geschäftsprozessen
• Ausgefeilter Modell- und Diagrammentwurf
• Unterstützung von Design Patterns
• Unterstützung der Object Constraint Language (OCL)
• XMI-1.2-Import und -Export
• Import von IBM-Rational-Rose-Modelldateien (MDL)
• Automatisch generierte, HTML-basierte Dokumentation
• Erzeugung von Bilddateien Ihrer Diagramme
• Integration von Borland CaliberRM für die Verwaltung von Softwareanforderungen
• Austausch von Diagrammen und Modellen zwischen einzelnen Projekten
• Nutzen von Diagramm und Modell im Team (inklusive Versionskontrolle)

Together unterstützt auch Design Patterns mit einer umfangreichen Bibliothek. Die Muster eignen sich zum Beispiel sehr gut zu Schulungszwecken. Ein Textfile wird aus den Klassen automatisch generiert und lässt sich später modifizieren, wenn das Modell eine Änderung erfährt. Die Philosophie, Textfiles zu verwenden, erlaubt ein transparentes Vorgehen auch bei Änderungen oder Backups. Ein Abbilden der Felder zu Attributen lässt sich beispielsweise sehr direkt oder eben makrogesteuert vornehmen. Together Edition for VS.NET unterstützt die Verwendung von führenden Designmustern wie GoF und J2EE und bietet gleichzeitig die Möglichkeit, vorhandene Muster zu ändern und neue zu erstellen. Dadurch können Teams vorhandenen Code für zukünftige Projekte optimal nutzen und die Qualität der Softwarearchitektur in allen Projekten verbessern.

Steckbrief Together

Die Design Patterns sind von reicher Qualität und in der GoF oder J2EE Notation vorhanden. Als Beispiel der Builder, der ein Trennen der Konstruktion eines Objektes von seiner Repräsentation verlangt, sodass derselbe Konstruktionsprozess unterschiedliche Repräsentationen erzeugen kann. Es lässt sich festhalten: Auch bei Together (aber nie so schlimm wie Rose) sind die für die Modellierung wichtigen Detailinformationen reichlich versteckt. Man findet sich dann unweigerlich in einem Konglomerat von Karteikarten, Pop-up- Menüs, Texteingaben und Dialogen wieder, nach dem Motto: „I’m still confused, but on a much higher level“. Nach sorgfältiger Recherche der Lizenzpreise wird man den Eindruck nicht los, dass in den Preisen zwischen Vollversion und Upgrade einiges in Bewegung ist.

[ header = Seite 6: objectiF 6.0 ]

objectiF 6.0

Wenn Sie das Heft in den Händen halten, sollte die topaktuelle Version 6.0 schon auf dem Markt sein (Release November 2005). Von objectiF gibt es drei Editionen (Visual Studio, Eclipse und Enterprise), deren Standardfunktionalität identisch ist. Die Enterprise-Edition kombiniert die beiden anderen Editionen und bietet zusätzlich noch C++ an. Betrachten wir also im Folgenden das Flagschiff von objectiF. Die Enterprise-Edition bietet einerseits eine einheitliche Modellierungssprache sowie Unterstützung beim Implementieren für ein breites Spektrum an objektorientierten Sprachen. Vom Businessexperten und Systemanalytiker über den Softwarearchitekten und den Softwaredesigner bis zum Programmierer: Die Enterprise-Edition unterstützt die Entwicklung durchgängig von den Anforderungen bis zum Code in C++, C#, Visual Basic .NET und Java. Mit Klassen-, Packet-, Aktivitäts-, Use-Case-, Sequenzund Zustandsdiagrammen bietet sie alles, was für den effizienten Einsatz der UML benötigt wird.

Die Enterprise-Edition kombiniert zudem die Entwurfsfähigkeiten mit VS.NET und Eclipse. Die Werkzeuge sind nahtlos für ein einfaches und sicheres Roundtrip Engineering nach dem Motto „Modell gleich Code und Code gleich Modell“ integriert. Und wenn schon Anwendungen in C++, C#, Visual Basic .NET oder Java da sind? Dann lassen sie sich per Reverse Engineering in die Enterprise-Edition einlesen, die Architektur sichtbar machen und so eine optimale Basis für die Pflege und Weiterentwicklung der Anwendungen schaffen.

Abb. 11: Das GUI von objectiF als MDI-Architektur

Standardmäßig sieht objectiF die Codegenerierung in C#, VB.NET, C++ und Java vor, doch ist objectiF aufgrund seiner Komponentenarchitektur für andere Zielsprachen konfigurierbar, zum Beispiel für Delphi mit dem verfügbaren Skript Server als COM-Technologie und Komponenten für das Reverse Engineering. Auch mit Blick auf die zu entwickelnde Applikation „denkt“ das Tool an Komponenten: Das Konzept der Packages bietet einen Mechanismus, zusammengehörende Entwurfselemente zu gruppieren, ohne dass sie dadurch für Elemente anderer Packages unerreichbar wären. In Abbildung 11 ist ein Paketdiagramm sichtbar, das mit einem Testpaket erweitert ist.

Erfrischend ist die Art der Benutzerführung mit den unabhängigen Masken. Die GUI baut auf dem „Single Document Interface“-Prinzip auf. So hat man stets die Fenster im Zugriff, die man auch benötigt. Beim zügigen Arbeiten mit objectiF wird einem bewusst, wie wichtig eine gute Ergonomie für Kreativität und Inspiration ist. Ich schätze vor allem die feinen Details im Hintergrund, welche auch die Konsistenz der Diagramme sichern. Die Version 6 des objektorientierten Entwicklungswerkzeugs steht wieder mit Erneuerungen vor der Tür. Die neue Version ist durch Erweiterungen auf unterschiedlichstem Niveau – vom neuen Diagrammtyp bis zum komfortableren Bedienelement – gekennzeichnet. Hier einige Highlights und Neuerungen:

• Prozessmodell mit actiF, PRINCE2 oder V-XT kombinierbar
• Neu: objectiF-Editionen
• Neu: .NET-Anwendungen mit objectiF und Visual Studio .NET
• Neu: Java-Anwendungen mit objectiF und Eclipse
• Erweitert: Mehr Bedienkomfort im Klassendiagramm
• Das Modellieren von Zustandsautomaten nach UML 2.0
• Verbessert: Neuorganisation von Sichten und Kontextmenüs
• Aktivitätsdiagramme für Business Modeling und Anforderungsdefinition
• Stereotypen für Beziehungen in Use Case und Klassendiagramm
• Neu strukturierte Hierarchiebrowser
• Automatischer Import von Klassen per Drag & Drop
• Verbesserte Performance des integrierten Web-Publishers

objectiF ist ein Werkzeug für die Konzept und Anwendungsentwicklung, das methodisch voll auf UML basiert. Die Notation der UML wird in allen Diagrammen von objectiF verwendet, sodass die Analyse- und Designergebnisse auf einer einheitlichen Kommunikationsgrundlage basieren. Es werden auch keine Kompromisse mit anderen Methoden wie strukturierte Analyse oder ERD eingegangen. Umso konsequenter und übersichtlicher ist das Vorgehen bei objectiF. Nach der zügigen Installation besticht das Tool durch den schlichten Einstieg, indem mit durchdachten, kontextsensitiven Menüs nur das Erforderliche vorhanden ist.

Abb. 12: objectiF mit neuer State Machine

Apropos Version: Die objectiF Personal- Edition ist für den Einsatz auf dem Arbeitsplatzrechner im Single-User- Betrieb gemacht. Mit ihr können Sie kleine, persönliche IT-Projekte durchführen: Die Anzahl der Diagramme ist beschränkt und die Funktion Export/Import erlaubt in der Personal-Edition nur den Import. Kennzeichnend für objectiF ist auch seine maschinelle Konsistenzsicherung – auch und gerade – im Mehrbenutzerbetrieb. Ändert man mit dem Tool ein Element in einem Diagramm oder im Code, wird diese Änderung sofort überall dort wirksam, wo das Element vorkommt oder referenziert ist.

ObjectiF löst diese Aufgabe technisch so: Beim Einsatz der UML bieten sich Packages als Einheit zum Datenaustausch an. Wird ein Paket zum Export ausgewählt, erzeugt objectiF eine Datei im XML-Format. Dorthin überträgt es die ausgewählten Packages einschließlich ihrer Subpackages. Die Exportdatei spiegelt die Repository-Struktur von objectiF wider. Zusätzlich sind nach dem Export in dieser Datei eine Reihe von Informationen vorhanden, die einen späteren widerspruchsfreien Import ermöglichen. Dazu gehören zum Beispiel Angaben über die hierarchisch übergeordneten Packages und alle Objekte, die nicht in der Exportmenge liegen, aber aus ihr heraus Referenzen besitzen.

XMI mit objectiF

Wie wird ein grafisches UML-Modell nun zu einem XMI-Text? Aus konzeptioneller Sicht wird die XMI-Darstellung eines Modells in zwei Schritten gewonnen: Zunächst wird das Modell in sein Metamodell überführt. Dabei entsteht eine Hierarchie von Metamodellelementen. Die XMI-Norm definiert nun, nach welchen Regeln aus dem Metamodell ein so genannter XMI-Stream erzeugt wird. Der Hierarchie folgend wird das Metamodell in XMI umgesetzt. Konkret installiert man sich für den Export ein Skript, indem ich den Dialog Skriptverwaltung öffne. Viele Erweiterungen von objectiF basieren auf dieser Skripttechnologie. Ich klicke mit der rechten Maustaste auf der Registerkarte Skript-Server zuweisen auf das Paket und wähle im Kontextmenü den Befehl Skript-Server zuweisen. Entsprechend finde ich im Verzeichnis ..ScriptServers die Datei XMIExportActionScript.exe der objectiF-Installation. (Das gilt hier allerdings nicht für die Personal-Edition).

Die Modelleinheit für die XMI-Generierung unter objectiF ist das Paket. Die Namenskonventionen der XMI-Norm sorgen dafür, dass die Namen in den erzeugten Tags der Nutzdaten für jeden, der mit dem Metamodell vertraut ist, sprechend sind: Jeder Tag beginnt mit dem Namen des Metamodell-Package, aus dem die jeweils bearbeitete Metaklasse stammt. Es folgen die Namen der Metaklasse und des Attributs, sodass es dem erfahrenen Leser leicht möglich ist, jeden Teil des XMI-Stream mit dem entsprechenden Teil des Metamodells dann in Beziehung zu setzen.

Am Rande: Der XMI-Generator für objectiF wurde von der BITPlan (www. bitplan.de) entwickelt. BITPlan hat auch eine Generierungsmöglichkeit für Delphi, Cobol oder aktuell für PHP entwickelt (PHP2UML), die mit diversen Tools zusammenarbeiten, die den XMI-Export kennen. Die UML kennt mit Stereotypen und benutzerdefinierten Eigenschaften zwei Konzepte zur individuellen Erweiterung des Sprachumfangs. objectiF unterstützt beide Konzepte. Nützlich auch, weil Stereotypen und benutzerdefinierte Eigenschaften zusammen mit der Skripttechnologie ermöglichen, aus den Modellen sehr differenziert und spezifisch Code zu generieren. Jeder Anwender kann zusätzlich freie Referenzen zwischen beliebigen Modellelementen definieren. Einmal angelegt, pflegt das Tool diese Referenzen automatisch genauso wie alle Referenzen, die das Metamodell des Tools standardmäßig vorsieht.

Für die Realisierung von Komponentenarchitekturen bringt objectiF die Bibliotheken der Java- und .NET-Plattform standardmäßig als UML-Modelle mit. Darüber hinaus können Sie sich eigene Frameworks und Klassenbibliotheken per Reverse Engineering in objectiF verfügbar machen. Es bietet sich geradezu an, das im Repository von objectiF abgelegte Modellwissen über ein System beim Testen auszunutzen. Mit der Version 6 wird ein weiterer Schritt in diese Richtung gemacht. objectiF enthält Toolfunktionen, die den Entwicklertest der implementierten Klassen unterstützen. Testklassen lassen sich generieren und gleichzeitig steht ein Testframework für die Verwaltung von Tests zur Verfügung. Refactoring und Tests auf Architekturniveau sorgen auch in objectiF für mehr Qualität bei der Softwareentwicklung.

Steckbrief objectiF

[ header = Seite 7: innovatorAOX 2006 ]

innovatorAOX 2006

Die MID Enterprise Software Solutions GmbH hat im November auf ihrer Anwenderkonferenz Insight’05 eine neue Generation ihrer in ca. 20.000 Installationen bewährten Softwareentwicklungsplattform Innovator vorgestellt. Zum Namenswechsel des Produktes gesellen sich neu auch zwei Varianten. Zu den Highlights von innovatorAOX 2006 (vormals Innovator 8.x) gehört neben der Integrierbarkeit in Eclipse und Generierung für .NET sowie ausgefeiltem Support der V-Modell XT-konformen Entwicklung auch die parallele Unterstützung von UML 1.4 in der ClassiX-Variante und UML 2.0 in der eXcellence-Variante. In beiden Varianten ermöglicht innovatorAOX 2006 automatisierte Modelltransformationen vom Geschäftsprozessmodell bis zum Code.

Das Tool bietet eine leistungsfähige Plattform für die Modellierung und Realisierung komplexer Anwendungen im Umfeld von EJB, Web Services und MDA. Auch von Eclipse aus können Sie nun nahtlos auf die Innovator-Modelle zugreifen. Zusätzlich erweitert die Anbindung von PVCS Dimensions die Möglichkeiten im Konfigurations- und Versionsmanagement. Die strikte Ausrichtung und Anpassung an Standards sichert auch in Projekten nach herkömmlichen Methoden und Verfahren getätigte Investitionen.

Abb. 13: Der neue innovatorAOX 2006

Die Installation ist recht aufwendig und benötigt Administratorenkenntnisse. Hier erkennt man eben die angestrebte Plattformunabhängigkeit, das mächtige Repository und die Dimension, ein allumfassendes Tool oder besser gesagt, eine integrierte Toolfamilie anzubieten. Der innovatorAOX gibt es für Business Processing und Software Engineering in fünf Varianten:

• Business classiX als professionelle Geschäftsprozessmodellierung auf Basis der UML
• Object classiX nach objektorientierten Methoden der UML 1.4
• Object eXcellence mit Methoden der UML 2.0
• Data classiX mit ausgereifter Datenmodellierung mit ERM / SERM
• Function classiX nach strukturierten Methoden

Um den Möglichkeiten von neuen Modellierungsstandards (zum Beispiel UML 2.0) sowie den zahlreichen Anforderungen zur Erweiterung und Verbesserung von Innovator Rechnung zu tragen, haben sich vier herausragende Merkmale gebildet, die als Vorteil in einer größeren Unternehmenskultur zum Tragen kommen:

• Hochwertige Integrationen mit diversen Tools und kundenspezifischen Infrastrukturen: MID und ihre Partner stellen geprüfte AOX PowerTools für die spezifischen Entwicklungs- und betrieblichen Aufgaben zur Verfügung.
• Repository-basiert: So können selbst große und räumlich verteilte Teams simultan, konsistent und ohne Konsolidierungsaufwände arbeiten.
• Hochgradig skalierbar: Einzigartig in der bewährten Unterstützung umfangreicher Modelle in großen Entwicklungsteams.
• Flexibel durch offene Architektur: Unbegrenzte Anpassungs- und Erweiterungsmöglichkeiten mit Standard-Skriptsprachen

Der Innovator verfügt über eine starke Dokumentationskomponente – der integrierte Dokumentationsserver erzeugt dynamisch RTF-Dokumente basierend auf einer Struktur, die nach Vorgaben der CI sowie den Richtlinien nach DIN EN ISO 9001 entsprechen. Die Dokumentation lässt sich deshalb an firmenspezifische Anforderungen mit einer Optionssprache mit TCL leicht anpassen. Interessant ist auch der Ansatz Externe Codegeneratoren über XMI anschließen zu können, sodass via XMI Export Code generiert wird.

Mit dem innovatorAOX Web lassen sich neue Live-Ansichten der Modellinhalte von Innovator über einen beliebigen Internet-Browser anzeigen. Sie navigieren damit direkt zwischen unterschiedlichen Modellen und Methoden. Mit der Webversion können alle Projektbeteiligten von überall aus jederzeit den aktuellen Projektstatus einsehen, ohne dass sie eine Installation benötigen. Dies erleichtert zum Beispiel die Abstimmung in abteilungsübergreifenden und internationalen Teams und in Kundenprojekten. Abschließend kann man sagen, dass man Innovator eigentlich nicht gerecht wird, wenn man den Einsatz allein auf UML oder ein kleines Systemhaus bezieht. Die verschiedenen Varianten kommen am besten in einem Umfeld zum Einsatz, wo es eine Durchmischung aus strukturierter und OO-Entwicklung gibt. Wo immer es möglich ist, unterstützt Innovator bestehende Industriestandards, was das Tool gerade auch für große und schwerfällige Projekte mit hohem Investitionsschutz interessant macht.

Mit den fünf Varianten unterstützt Innovator sowohl objektorientierte sowie klassische, strukturierte Technologien (SA/SD und ERM/SERM) in Erstellung und Wartung komplizierter Softwaresysteme bis hin zur Geschäftsprozessmodellierung.

Steckbrief innovatorAOX 2006

[ header = Seite 8: Describe Enterprise ]

Describe Enterprise

Sun integrierte als erste das Tool von Embarcadero und holt damit im Bereich Modell-basierender Applikationsentwicklung auf. Nachdem beide Firmen einen definitiven Lizenz- und Entwicklungsvertrag unterzeichnet haben, hat Embarcadero Sun unbegrenzte Verteilungs- und Nutzungsrechte an Describe 6.1 erteilt, seinem erstmals in Java erhältlichen UML-Werkzeug. Die Integration ist mit Suns „Java Studio Enterprise 7.0“ erfolgt. Mit dem Deal weiten beide Hersteller ihre seit zwei Jahren bestehende Partnerschaft aus und entheben Anwender der Notwendigkeit, Describe separat zu kaufen, zu installieren, zu lizenzieren oder zu warten. In der Vergangenheit unterstützte das Embarcadero-Tool nur C++ und Windows, durch die Erweiterung auf eine Java-Architektur deckt das Tool nun Windows, Linux und Solaris ab.

Abb. 14: Describe 6.1 mit UML 2

Embarcadero bietet auch eine bidirektionale Brücke von ER/Studio zu Describe an. Dadurch können Unternehmen die vorhandene Kompetenz und die Vorteile von ER und UML integrieren. Einfache Assistenten helfen schrittweise bei der Erstellung elementarer Beziehungen, oder man kann die fortgeschrittenen Zuordnungsfunktionen benutzen, um anspruchsvolle 1-zu-n-Abbildungen zu erstellen. Die integrierte Round-Trip- Synchronisierung sorgt dafür, dass die erstellten Beziehungen bestehen bleiben, wenn das Projekt weiterentwickelt wird. ER/Studio aus demselben Hause ist eine bekannte Anwendung zur Datenmodellierung sowie für den Entwurf und Aufbau logischer und physikalischer Datenbanken. Seine leistungsstarke Umgebung mit ihrer mehrschichtigen Struktur richtet sich an die alltäglichen Bedürfnisse von Datenbankadministratoren, Entwicklern und Datenarchitekten, die sich mit dem Aufbau und der Wartung großer, komplizierter Datenbankanwendungen befassen wollen oder müssen. Die neue Version 6.1 hat seit 5.x einen entscheidenden Schritt zu mehr Integration und einem klaren Produktdesign getätigt. Viele Funktionen, die früher nur in der IDE von Describe zugänglich waren, sind jetzt auch in einer integrierten IDE möglich, von denen vier unterstützt werden:

• JBuilder 8.0
• Sun ONE Studio
• WebSphere 5.0
• Eclipse 2.1

Darin ist auch zu erkennen, dass bei der Integration nur Java zum Bitkuss kommt, bei anderen Sprachen/IDE ist aber immer noch ein direktes Arbeiten in der klar strukturierten IDE von Describe möglich. Diese Doppelstrategie hat bezüglich Versionsvielfalt und verfügbarer Funktionalität ihren Preis. Allen gemeinsam hat Describe folgende Leistungsmerkmale:

• Starke logische und physikalische Navigation und Strukturierungsfähigkeiten
• Live bidirektionale Synchronisierung des Codes
• Eine offene Architektur, die eine Erweiterung der Produktfunktionalität ermöglicht
• Leistungsstarke HTML-gestützte Dokumentationsmöglichkeiten
• Viele Assistenten für Reverse Engineering oder XMI
• Erweiterte Pattern Generierung

Das Tool ist übersichtlich aufgebaut und funktioniert nach dem MDI-Prinzip, bei welchem ein Fenster mehrere Dokumente via Register beinhalten kann. Von der Ergonomie her sind gewisse Ähnlichkeiten mit Rose auszumachen, aber Describe ist einiges strukturierter. Befremdend wirkt höchstens die Art der Darstellung von Diagrammen, Farbe wie Form sind kräftig gewählt. Durch die offene Architektur werden auch in Describe wiederum Fremdprodukte wie ClearCase, Star-Team, CVS, DOORS oder Perforce eingebunden.

Abb. 15: Describe mit Pattern Catalog

Der Import von Rose-Modellen ermöglicht dem Modellierer zusätzlich, die bisher mit Rose erstellten Modelle schnell und einfach zu importieren und diese in Describe weiterzubearbeiten. Ein kleiner Test zum Beispiel bezüglich eines Paketdiagramms und seines Einsatzes zeigte die formale Richtigkeit bei Describe. Das Modell legt die Architektur des Zielsystems fest. Es zeigt Pakete, Module und Komponenten des Systems als Ort der Gruppierung an. Ein Wermutstropfen sei das Upgrade von der 5.x auf eine 6.1. Da im Tool die Projektfiles und deren Formate innerhalb der Workspace derart geändert wurden, ist man gezwungen, alte Projekte mit XMI zu exportieren und dann neu einzulesen. Erste assistentengeführte Tests diesbezüglich waren vielversprechend.

Muster lassen sich auch in Describe nachmodellieren. Die angegebenen Parameter werden bei der Mustererstellung vom Modellierer abgefragt. Das Ergebnis ist ein konkretes Modell mit zugehörigem Diagramm. Die Grundlage dafür bilden einzigartige Funktionalitäten der Definition und Instanziierung von Mustern und Frameworks. Muster (Analyse-, Design- und Architekturmuster) lassen sich dazu mit dem Tool modellieren und als Muster definieren. Dazu wird ein „Rezept“ beschrieben, wie zum vorliegenden Muster eine Instanz zu bilden ist. Im Anschluss daran kann man das Muster beliebig häufig mit geringem Aufwand instanziieren und immer wieder einsetzen. Unterstützt sind nebst den GoF auch EJB oder konkrete Analysemuster (Requirements). Die so generierten Modelle können sowohl den Ausgangspunkt für ein neues Gesamtmodell bilden, als auch in ein bereits bestehendes Modell integriert werden.

Steckbrief Describe

[ header = Seite 9: Rational Rose XDE ]

Rational Rose XDE

Rational ist sozusagen Marktführer auf dem Gebiet der CASE-Tools. Inzwischen bietet Rational drei XDE-Varianten an, bei der auch die Integration der firmeneigenen Tools ClearCase und WebSphere weiter vorangetrieben wurde. Rational XDE Developer for Visual Studio .NET und Rational XDE Developer for Java Edition sind die beiden Flagschiffe aus dem Hause. Eine dritte neue Variante heißt XDE Developer Plus und kombiniert sozusagen die beiden Welten von .NET und J2EE in dem zwei Tools zusammengefasst sind. Zusätzlich ist noch C++ mit an Bord.

Wer in anderen Sprachen weiterentwickelt, hat immer noch den Technical Developer im Angebot. Rational XDE unterstützt nebst dem Eclipse-Framework auch die anderen Schritte eines Entwicklungsprozesses. Die .NET Edition von Rational XDE beschleunigt gemäß Rational die Softwareentwicklung dank der nahtlosen Integration in VS. Somit können Entwickler Code und Design direkt in der VS-IDE vornehmen, ohne das Tool wechseln zu müssen. Eine mächtige anpassbare Pattern Engine stellt sicher, dass Entwickler nicht auf der grünen Wiese anfangen müssen. Eigene Patterns lassen sich entweder aus bestehendem Code oder auch aus Modellen erzeugen.

Mit Instant UML hat sich Rational etwas Besonderes einfallen lassen. Während Design Patterns vor allem der Wiederverwendbarkeit dienen, kann der Entwickler mit Codetemplate in weniger Zeit mehr erreichen. Neu ist das nicht, aber die Integration in ein bestehendes Modell sowie das Einfügen der Codefragmente in eine Klasse, die man aus einem Pattern generiert, ist elegant gelöst. Auch Automatismen wie die getter/setter/letter als Code- Rümpfe erleichtern die Arbeit, zumal dies auch im Modell geschehen kann. Nebst der Visualisierung mittels UML und dem Dokumentationssupport, dem Reverse Engineering und einer Auswahl an automatisierter Synchronisation hat der Entwickler auch die Möglichkeit, die UML während des Kodierens zu erlernen. Wobei hier die Anzahl der Features schon bald die Grenzen bezüglich Übersichtlichkeit sprengt. Auch hat man teilweise mit der konfusen Bedienung zu kämpfen, das Löschen von Elementen lässt sich recht „kreativ“ angehen zumal auch das Erstellen von Diagrammen oder das Verlinken einer Assoziation unterschiedlich möglich ist.

Abb. 16: XDE mit Modell und Dokumentation in einem

Code-Synchronisation

Die Code-Synchronisation verfügt über eine Knopfdruck Synchronisation zwischen Code und Modell. Es gibt sogar eine Auto-Synchronisation mit anpassbarer Konfliktlösung, die bei mir eher mehr Konflikte produzierte. Durch Split | view Window lassen sich Code und Modell gleichzeitig anzeigen. In XDE erliegt man bereits während des Designs der Versuchung, mal schnell etwas zu programmieren. Mit der XDE, wird sicher die volle Kreativität über den ganzen Entwicklungsprozess unterstützt und gesteigert, aber bei allem Komfort kann dies auch zu Denkblockaden und Designschwächen führen. Diese zyklischen Beziehungen zwischen dem Modell aus Architektursicht und dem gleichzeitigen Blick auf den detaillierten Code verführen, den Blick aufs Wesentliche zu vergessen. Rose hat mit dem Anforderungsmanagement sowie Funktionalitäten für die Analyse für Benutzer von RequisitePro, Analyst Studio, und Development Studio auch die passenden Zusatzprodukte parat, die für die Identifikation von Problemen und Definition von Lösungen dienen.

ClearCase dient der Integration zum Konfigurationsmanagement und der integrierten Fehler- und Änderungsverfolgung. Das Roundtrip- wie das Reverse Engineering ist vielfältig vorhanden. Nicht zu vergessen sei durch die offene Schnittstelle bedingt, dass es bereits mehr als 120 Integrationen von Rose mit anderen Tools oder Erweiterungen als Add-on dazu gibt. XDE unterstützt auch Design Patterns mit einer umfangreichen Bibliothek. Die Muster eigenen sich perfekt z.B. auch zu Schulungszwecken. Durch eine Pattern Engine hat man die Möglichkeit, neue Projekte mit einem automatischen Codegerüst zu versehen. Multiple Model Support zu MDA ist ersichtlich. Ein Mapping der Felder zu Attributen lässt sich sehr direkt oder eben templategesteuert vornehmen. Auch ein Data Modeler ist mit von der Partie, welcher speziell für die Modellierung von SQL-Datenbanken gedacht ist.

Steckbrief Rational Rose XDE

[ header = Seite 10: Ameos ]

Ameos

Aonix gehört zu den weltweit führenden Anbietern von bewährten und offenen Softwareentwicklungstools – speziell im Bereich der objektorientierten Tools und Entwicklungssysteme für den technischen und kommerziellen Markt. Die Produktlinien decken den gesamten Entwicklungszyklus (Analyse, Design, Entwicklung und Integration) ab und sind konsequent aufeinander abgestimmt. Von Aonix gibt es eigentlich drei StPVarianten (SE/UML/ACD), die auch noch gewartet werden, wobei die Richtung eindeutig zu Ameos hin zeigt. Die Weiterentwicklung Richtung UML 2 passiert demzufolge nur bei Ameos. Es gibt allerdings eine Migration von StP nach Ameos, sodass bestehende Kunden umsteigen können. Mit den UML-Profilen bietet Aonix eine einfache Möglichkeit, die Standard-UMLNotation zu erweitern und an projektspezifische Anforderungen anzupassen. Der Profile Editor von Ameos ermöglicht die Definition von Stereotypen und Tagged Values und die Verknüpfung mit Elementen des Metamodells. Damit werden der Entwurf, die Dokumentation und die einfache Wiederverwendung von UML-Profilen sichergestellt.

Abb. 17: Sehr direkter Einstieg bei Ameos

Einzigartig ist die Zuordnung von Farbe in der Profile-Definition. Farbe wird dadurch auf semantischer Ebene verwendet und führt zu einer erheblich gesteigerten Lesbarkeit der erstellten Modelle. Ein weiteres Kernstück von Ameos stellt der Modelltransformator auf Basis der MDA dar. Die PIMs werden dann über Transformatoren in die Zielumgebung überführt. Mit speziell zu diesem Zweck erstellten UML-Profilen und den darauf abgestimmten Transformationsregeln können die genannten Vorteile direkt in die Praxis umgesetzt werden.

Neben den Standardlösungen für C, C++, Ada95, Java und EJB werden auch branchenspezifische Lösungen für den Automobilsektor und für sicherheitskritische Anwendungen angeboten. Ameos ist auf Win2000/XP, Solaris und Linux verfügbar und ist somit für den Einsatz in heterogenen Netzwerken prädestiniert.

Die Oberfläche von Ameos bringt eine spezielle Technik zu Tage. Bei jeder Aufgabe oder beim Start eines Tasks erhält man eine neue Ameos-Instanz, sodass man jeweils nur in einem dafür bestimmten Fenster arbeitet (wie bei objectiF). In Abbildung 17 wird aus dem Kontext Services des Modells ein neues Fenster gestartet, das gezielt das zugehörige Paket zeigt. Entsprechend einfach und karg wirkt die Umgebung am Anfang, da die meisten Aktivitäten in einem separaten Kontext ablaufen. So hat man stets die Funktion, die man braucht und freut sich ob dieser Simplifikation. Der Einstieg in das Tool gestaltet sich deshalb bei Ameos zügig. Bereits beim Erstellen des Anforderungskatalogs wird man in den Prozess eingeführt, der in einer vernünftigen Reihenfolge erfolgt und nur das bringt, was man auch braucht. Zudem unterstützt dieses CASE-Tool nebst Windows alle gängigen Linux-Plattformen und OO-Vorgehensmodelle!

Die Positionierung von Ameos wird damit als Multi-Plattform-Modellierungswerkzeug ausgebaut. Software through Pictures nennt es „Architecture Component Development“- Technologie. Dahinter steckt eine spezielle Templatesprache, die man dem Transformator füttert. Ameos ermöglicht die Trennung der fachlichen Anforderungen von den technischen Details der Implementierung. Die fachlichen Aspekte sind mit UML-Modellen und die technischen Aspekte als Template für den Transformator modellierbar. Dadurch erhält man einen sehr hohen Abstraktionsgrad in den Modellen und ein hohes Maß an Wiederverwendung durch die technischen Musterlösungen. Mittels der Templatesprache, welche eine Art Abbildungsregeln definiert, kann der generierte Teil des Codes mehr als die Hälfte betragen. Spätestens beim Komponenteneditor bemerkt man die durchdachten Checks von Syntax und Semantik bezüglich der einzelnen Diagramme. Die Integration mit weiteren Produkten wie Configuration, IDEs für verschiedene Sprachen und Testwerkzeuge sorgen für die Abdeckung des gesamten Softwarezyklus.

Weitere Leistungsmerkmale:

• Es speichert das semantische Modell in einem Multi User Repository
• Verbesserte Konsistenzprüfung auf allen Ebenen und Sichten
• UML-2-Profile, Abbildungsregeln und Codegenerierung
• Eigene bewährte MDA-Technik

Steckbrief Ameos

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -