Ansgar Bredenfeld (GMD, Sankt Augustin):	APICES - Eine Prototyping-Umgebung für technische Anwendungen
Holger Giese, Joerg Graf, Guido Wirtz (Universität Münster):	Kontraktbasierte Modellierung verteilter Softwaresysteme
Torsten Heverhagen (Universität Essen):	Auswirkungen der OMG-Standardisierungen auf die Entwicklung von Application-Frameworks
A. Speck (Universität Tübingen):	Objektorientiertes Framework zur Entwicklung von Robotersteuerungen
Reiner Dumke, Erik Feltin (Universität Magdeburg):	Metrikenbasierte Bewertung objektorientierter Sofware-Entwicklungsmethoden
Martin Lefering (DKV, Köln):	Einsatz objektorientierter Technologien in der DKV

(wird noch nachgeliefert)

Stichworte: Verteilte Software-Systeme; Objekt-orientierte Verhaltensmodellierung, Koordination, Petri-Netze, Strukturierungskonzepte

Verteilte Softwaresysteme, die in den letzten Jahren eine ständig zunehmende Bedeutung in der Praxis bekommen haben, bringen zusätzliche Probleme mit sich: Verteilung, Nebenläufigkeit, Heterogenität und eine notwendige Interoperabilität. Die Systeme unterliegen einem ständigen A"nderungsdruck und müssen bestimmte Kriterien bzgl. Zuverlässigkeit und Durchsatz erfüllen. Hinzu kommen technische Aspekte wie Ressourcenverwaltung, Lastausgleich und Verklemmungen.

Heutige Programmiersprachen erfassen diese Eigenschaften auf einem zu niedrigen Abstraktionsniveau, so dass die Systeme aufgrund der hohen Komplexität kaum bzw. schwer entwickelbar und noch schlechter veränderbar sind. Heutige Designmethoden sind nicht in der Lage, verteilte Systeme mit den obigen Eigenschaften adäquat darzustellen. Vor allem die Verhaltensmodelle, die zur Spezifikation des Systemsverhalten in diesen Methoden verwendet werden, sind in ihrer Semantik nicht ausdrucksstark genug bzw. ungeeignet (Bsp.: Activity Diagramm und Objekt Interaktionsdiagramme [1], Message Sequence Charts [2]).

Der - nach der verwendeten Modellierungssprache Object Coordination Nets - OCoN genannte Ansatz basiert auf den folgenden Thesen:

• Die Schnittstellen müssen um das externe Interaktionsverhalten erweitert werden (Verhaltenskontrakte).
• Die Struktur und das abstrakte Verhalten muss gemeinsam entworfen werden.
• Es muss neben dem Entwurf von Klassen und Beziehungen (Feindesign) auch eine architektonische Ebene (Grobdesign mit Komponenten) geben.

Aufbauend auf dem Ansatz Objekt-orientierter Analyse und Designs wird die Strukturmodellierung für verteilte Systeme mittels Verhaltenskontrakten und Architektur Elementen erweitert.

Die Verhaltens Modellierung soll in Bezug auf Nebenläufigkeit, Konkurrenz und Kooperation durch die Verwendung der an diese Anforderungen angepassten Petrinetz-Variante Object Coordination Nets verbessert werden.

Langfristiges Ziel ist es, herkömmliche objektorientierte Analyse- und Modellierungs-Ansätze in eine für verteilte Software geeignete Methodik zu integrieren. Trotz der zur Zeit vorhandenen Schwierigkeiten (inkonsistente und unklare Semantik der Konstrukte) im Rahmen der Standardisierung der UML [1] durch die OMG, ist eine Vereinheitlichung der Notationen und ihrer Interpretation notwendig. Wir verwenden deshalb die UML.

[1] Rational Software Corporation. Unified Modelling Language 1.1, September 1997.
[2] International Telecomunication Union (ITU) Study Groups CCITT. Message Sequence Chart (MSC) Recommendation Z.120 draft version, 1996.

Unter Application-Frameworks versteht man in der Objektorientierung eine Menge von kollaborierenden Klassen, von denen mindestens eine abstrakt ist und die gemeinsam die für eine Klasse von Anwendungen notwendige Basisfunktionalität zur Verfügung stellen. Die Entwicklung von Application-Frameworks bezieht sich immer noch vorwiegend auf Anwendungen, die als nicht verteilter Client für einen Datenbankserver agieren. Es besteht deshalb meist nicht der Bedarf, einen Object Request Broker für die Verteilung von Objekten einzusetzen. Es kann aber davon ausgegangen werden, daß steigende Anforderungen an die Funktionalität der Anwendungen und an die Flexibilität der Anwendungsentwicklung den Einsatz von ORBs in Zukunft noch stärker forcieren. In der von der OMG entwickelten Object Management Architecture, deren zentraler Bestandteil der ORB ist, werden Object Services und Common Facilities definiert, die Basisfunktionalität für verteilte Anwendungen darstellen. Ein weiterer Bestandteil dieser Architektur sind die Business Objects. Der Vortrag soll anhand von Beispielen zeigen, daß sich die Object Management Architecture auch als Referenzarchitektur für klassische Client-Server Frameworks eignet. Es wird dargelegt, daß durch Einsatz der Entwurfsmuster Facade und Wrapper ein zukünftiger Anschluß eines ORBs vorbereitet werden kann. Exemplarisch wird die Umsetzung einer Facade für den Transaction-Service erläutert. Anschließend wird die Einbindung von Domain Interfaces (Business Objects) diskutiert.

1 Einleitung
Objektorientierte Frameworks sind eine neue, vielversprechende Methodik zur Softwareentwicklung. Frameworks sind teilweise vorgefertigte Softwarekomponenten, die an die individuelle Problemstellung angepaßt werden. Neben dem Quellcode wird dabei der Architekturentwurf wiederverwendet. Dadurch bieten Frameworks heute - verglichen mit anderen Vorgehensmethoden - den höchsten Grad an Wiederverwendbarkeit an.

Schon heute spielen Frameworks wie ET++, ADAPTIVE Communication Environment (ACE), MFC (Microsoft), DSOM (IBM) sowie RMI (JavaSoft) eine bedeutende Rolle.

Robotersteuerungssoftware:
Die meisten der neu entwickelten Robotersteuerungen basieren auf Standardhardware wie PCs oder Workstations. Beispiele für neue kommerzielle Steuerungen mit Standardhardware sind die KRC1 von Kuka oder die NoVal+ der Firma IRA-TEC. Die Verwendung von Standardrechnern ermöglicht den Einsatz effizienter Softwareentwicklungsmethoden beim Bau von Steuerungssystemen. Beispielsweise ist im Forschungsprojekt HIGHROBOT eine Workstation-basierte, universelle Steuerung entsprechend der objektorientierten Vorgehensweise von Booch entstanden. Die Architektur dieser HIGHROBOT Steuerung bildet die Grundlage des hier vorgestellten Frameworks.

2 Framework zur Entwicklung von Robotersteuerungen
Grundvoraussetzung für das Robotersteuerungs-Framework ist, daß bestimmte statische und dynamische Komponenten in allen (Roboter-) Steuerungen vorkommen. Die folgenden Aspekte bilden die festen Bestandteile (Frozen-Spots) des Frameworks:

• Statische hierarchische Architektur
  Die obere Ebene des Steuerungssystems (Application Layer) arbeitet die vom Benutzer geschriebenen Anwendungsprogramme (Application Tasks) ab, während die untere Ebene (Communication Layer) zur Kommunikation mit den gesteuerten Geräten (Roboterarm, sowie weitere periphere Einheiten) dient.
• Dynamischer zyklischer Ablauf der Steuerung
  Die Steuerungssoftware läuft zyklisch in einer Echtzeitschleife ab. Die einzelnen Schritte dieser Schleife sind:
  1. Einlesen der aktuellen Werte von den Geräten
  2. Abarbeiten der Anwendungsprogramme aufgrund der aktuellen Daten
  3. Ausgabe der Ergebnisse der Anwendungsprogramme an die Geräte

Durch flexible Hot-Spots kann das Robotersteuerungs-Framework an den jeweiligen Verwendungszweck angepaßt werden. Die wichtigsten flexiblen Anteile sind die Art der Anbindung der gesteuerten Geräte an den Steuerungsrechner (z.B. durch Einzelverdrahtung oder über einen Feldbus) und die Struktur der Daten, die mit den Geräten ausgetauscht werden. Ebenso wird die Dauer der Echtzeitschleife sowie der zeitliche Ablauf der einzelnen Application Tasks flexibel vorgegeben. Das Framework bietet auf Basis des POSIX.4 Standards verschiedene Mechanismen an, mit denen die Echtzeitanforderungen eingehalten werden können. Weitere Mechanismen können als Hot-Spots hinzugefügt werden.

Als vorgefertigte Module bietet das Robotersteuerungs-Framework eine Klasse zur Steuerung eines SCARA Roboters (Selective Compliance Assembly Robot Arm), die Klasse SoftPLC zur Emulation einer SPS (speicherprogrammierbaren Steuerung) und eine Klasse zur Steuerung eines Transfersystems an. Diese Klassen können durch Vererbung zur Steuerung weiterer Maschinen modifiziert werden. Die Anwendungsprogramme nutzen die Methoden dieser Steuerungsklassen.

3 Anwendung des Frameworks
Durch dieses Framework wird eine erfolgreich verwendete Technik in den Bereich der Echtzeitsteuerungssysteme übertragen. Im Gegensatz zu bisher bekannten Frameworks müssen bei dem Robotersteuerungs-Framework besonders die Echtzeitanforderungen beachtet werden.

Das Framework ist bei der Entwicklung von Robotersteuerungssystemen auf verschiedenen SPARC Workstations und Windows NT PCs eingesetzt worden. Durch die abgeleiteten Steuerungssysteme werden neben einem Bosch SR60 SCARA Roboter verschiedene weitere Geräte wie E/A Module, Transfersysteme und unterschiedliche weitere Antriebe kontrolliert.

Bei der Darstellung und insbesondere dem Vergleich von objektorientierten (OO) Entwicklungsmethoden werden zumeist tabellarische Formen gewählt, die die jeweiligen Techniken, wie Klassen, Vererbung, Assoziation, Skalierung, Aggregation usw., auflisten und bei jeder Methode ein Ja/Yes bzw. Nein/No eintragen. Die Methode mit den meisten "Ja" scheint dann die "beste" oder geeignetste zu sein.

Unser Beitrag geht von einer Quantifizierung der OO-Entwicklungsmethodiken mit (wirklichen) OO-Metriken, d. h. einer objektorientierten Sicht auf die Entwicklungsmethoden selbst, aus. Es werden daher Metriken für

• die Umsetzung bzw. Berücksichtigung der Problemanforderungen (als funktionaler Aspekt einer Entwicklungsmethode),
• die Komplexität der jeweiligen Komponenten (Diagramme, Regeln, Modelle) einer Methode als (statische) qualitative Sicht,
• die ("Workflow-") Komplexität einer Entwicklungsmethode bei ihrer Einführung und Anwendung als weitere (dynamische) qualitative Sicht

eingeführt und für einige "klassische" OO-Methoden, wie OOD, HOOD, RDD, OOA, OMT, OOSE und OOSA, angewandt. Ihre Rolle hinsichtlich der Design Patterns, dem CORBA und insbesondere der UML wird diskutiert.

Abschließend werden erste Bewertungsergebnisse vorgestellt und offene Fragen diskutiert.

(wird noch nachgeliefert)

zur FG-Startseite

letzte Änderung: 10.1.98