objectiF

Für die Geschäftsprozess-Modellierung werden Anwendungsfall-Diagramme und Aktivitäts-Diagramme (Darstellung als Petri-Netz - Beispiel siehe UML) eingesetzt.
Über das Anwendungsfalldiagramm (Use Case Diagram) erfolgt die Kontext-Darstellung zusammenhängender Geschäftsprozesse mit dem Informationsaustausch von und zu den Akteuren.
Einem Geschäftsprozess wird ein Aktivitätsdiagramm (Activity Diagram) zugeordnet.
Über das Aktivitätsdiagramm wird die Ablaufmodellierung durchgeführt. Im Aktivitätsdiagramm wird der Kontrollfluss und optional der Informationsfluss (Datenfluss) zwischen Aktivitäten beschrieben.
Komplexe Prozesse lassen sich über beliebige Diagramm-Ebenen bis zu atomaren Aktivitäten verfeinern. So können Geschäftsprozesse in dem für jeden Beteiligten gewünschten Feinheitsgrad an Aktivitäten dargestellt werden.
Durch die Nutzung der Swimlane-Darstellung zur Gliederung lassen sich Unterschiede der organisatorischen Zuständigkeiten für Prozesse gut im Diagramm visualisieren. Eine Swimlane dient als senkrechte Bahn im Diagramm der Abgrenzung / Anordnung von Aktivitäten. Eine Aktivität wird eindeutig einer Swimlane im Diagramm zugeordnet. Über die Swimlanes können zum Beispiel Organisationseinheiten, Akteure oder Ähnliches dargestellt werden (s.a. Diagramm-Beispiel mit Swimlane-Darstellung in objectiF zum Prozess Change-Management). Das Anlegen einer neuen Aktivität in einer bestimmten Swimlane steuert die Zuordnung zu einem passenden Package (siehe unten).
Die Integration der Geschäftsprozesse in objectiF gewährleistet die Navigierbarkeit zwischen Anwendungsfall-Diagramm und Aktivitäts-Diagramm und damit zu den Ergebnissen der nachfolgenden Entwicklungsschritte.

Die Anforderungen können über Anwendungsfall-Diagramme ermittelt und als Use Case beschrieben werden. Dabei können ergänzend oder alternativ auch vorgefertigte Textschablonen verwendet werden.
Die Abläufe zu den Anwendungsfällen werden wieder über Aktivitätsdiagramme zugeordnet und in der UML im Werkzeugbeschrieben. Über ein Sequenzdiagramm kann der zeitliche Ablauf der Aktivitäten aus einem Anwendungsfall verfeinert grafisch aufbereitet werden.
In Zustandsdiagrammen wird das dynamische Verhaltan der Objekte modelliert. Das Zustandsdiagramm kann zur Modell-Transformation und für eine automatische Code-Generierung genutzt werden.
Zur Beschreibung von Anforderungen und Geschäftsprozessen werden auch in dem Projektmanagement-Tool in-Step die entsprechenden Diagrammtypen und Modellierungselemente aus objectiF genutzt.

An dieser Stelle ist in objectiF auch bereits ein Prototyping zu den entworfenen Aktivitäten integrierbar. Ein Dialog-System kann entweder als Wegwerf-Produkt mit dem ActiveX ScreenPainter (realisiert als HTML-Prototyping) oder als Web- bzw. Windows-Forms unter Visual Studio .NET mit den weiter zu verwendenden User-Interface-Klassen entworfen werden.
Dem Fachbereich stehen dann zur Überprüfung der Anforderung bereits Dialoge in der späteren technischen Umsetzungsform zur Verfügung. Aus diesen Prototypen werden die endgültigen Dialoge evolutionär weiterentwickelt.

Der gleiche ScreenPainter wird sowohl im UML-Tool objectiF als auch im Software Engineering Werkzeug für die strukturierte Entwicklung case/4/0 genutzt.

Zur Bildung und Beschreibung der Komponenten-Architektur für die Anwendung werden Paket-Diagramme (Package Diagram,  s.a. UML) als Komponentendiagramm eingesetzt. Wobei in der Konzeption von objectiF zu einem Paket alle Produkte (Komponenten) von der Geschäftsprozess-Beschreibung über die Definition der Anforderungen bis hin zur Implementierung zusammengefasst werden.
Für ein Package kann im Werkzeug jeweils ein eigener Namensraum definiert sein und es können jeweils unterschiedliche Festlegungen für die Code-Generierung getroffen werden.

Über die Paketdiagramme werden auch Abhängigkeiten und Schnittstellen zwischen den Komponenten definiert. Für gängige Komponententechnologien (DCOM, EJB) stehen im Werkzeug fertige Strukturen und ein Wizard als Hilfe für das Generieren von Klassen zur Verfügung.

Die statischen Strukturen des IV-Systems mit Attributen, Operationen und Beziehungen zu anderen Objekten werden in Klassen und im Klassendiagramm (Class Diagram, s.a. UML) modelliert. Für die dann Klassen-Modell  enthaltenen persistenten Objekte ist es möglich und sinnvoll, diese Persistenz-Klassen durch maschinelle Transformation in ein Datenmodell  zu überführen.
Als Weg bietet sich hierfür der vom Werkzeug unterstützte Übergang zu einem Entity-Relationship-Modell (ERM) in case/4/0 an. Aus diesem semantischen Datenmodell ist es wiederum die Generierung von Relationenmodell und Tabellen für ein relationales Datenbank-System vorgesehen.

Die Code-Generierung findet üblicherweise aus den Klassen-Diagrammen heraus statt. Über Code-Skripte für die verschiedenen Zielobjekte wird ein zum grafischen Modell immer konsistenter Software-Code erzeugt. Die Code-Skripte werden von microTOOL bereitgestellt und können auch Nutzer-seitig für die Programm-Generierung erstellt bzw. modifiziert werden. Bei der Implementierung der Software unterstützt der Kontext- und Syntax-sensitive Code-Editor im Tool durch eine Vielzahl von nützlichen Funktionalitäten:

• vielfarbige Darstellung des Code mit Differenzierung zwischen
  -  noch nicht geprüfter Eingaben
  -  Schlüsselwörtern der Programmiersprache
  -  Operatoren
  -  syntaktisch korrekter Eingaben
  -  semantisch korrekter Eingaben
  -  nicht interpretierbaren Eingaben
  -  Kommentaren;

• Schreibschutz auf aus Klassen-, Attribut- und Methodendefinitionen stammenden Code-Teile;

• gültige Änderungen von Element-Namen werden Modell-weit angepasst und über Konsistenzprüfungen abgesichert;

• Kontext-orientierte Vervollständigung von Eingaben mit Hilfe des Wissens aus dem Modell;

• Navigation im Modell aus dem Code heraus.

Auf der Basis von Stereotypen und benutzerdefinierten Eigenschaften können in objectiF beliebige Unternehmens- oder Projekt-spezifische Erweiterungen bzw. Modifikationen der Code-Generierung für die Programme vorgenommen werden.

objectiF vereinfacht den automatischen Test der erzeugten Software im Projekt. Das Tool unterstützt zu jeder Klasse das Anlegen von Testklassen und die Zuordnung der passenden Testmethoden zu diesen Testklassen. Alle in einer Test-Suite gesammelten Testmethoden zu einem Package werden gemeinsam ausgeführt. Die Ausführung und Protokollierung dieser Funktion erfolgt unter Nutzung des JUnit-Framework (Kent Beck / Erich Gamma).
Dies ist zum Beispiel besonders bei einem Agilen Vorgehen mit immer wieder auftretendem Refactoring von großem Vorteil.

Roundtrip Engineering ist verfügbar für die Kombinationen von objectiF mit:

• Visual Basic, vb.net, C#
  durch angepasste Stereotypen bei Klassen (z. B. Stereotyp "Persistent Class") und Methoden und erweiterte Menü-Funktionen;

• Visual C++
  komfortable Anbindung an das Microsoft Developer Studio;

• VisualAge
  Anlegen und Aktualisieren von Projekten in beiden Richtungen über die HTTP-Schnittstelle;

• JBuilder
  vollständiges Roundtrip Engineering für die professionelle Systementwicklung.

Für die Einbindung externer Komponenten und die Verwendung gekaufter Klassenbibliotheken ist das Reverse-Engineering für C++- und Java-Quellcode sowie Java Byte-Code sehr hilfreich. Die importierten Komponenten sind voll in das Modell integriert.