Praxiserprobtes Verfahren für Analyse und Design

Abhängigkeiten zwischen Komponenten verringern

13.10.2000
MÜNCHEN (CW) - Eine Zerlegung von Anwendungen in Komponenten kann dann erfolgreich sein, wenn sie auf einem praktischen systematischen Ansatz beruht und nicht erst bei der Realisierung, sondern in der Analyse- und Designphase von Projekten erfolgt. Homayoun und Hamarz Mehmanesch sowie Andreas Zendler* skizzieren ein sicher nicht unumstrittenes Vorgehen, das die Identifizierung von Komponenten erlaubt und somit die Komponentenmodellierung ermöglicht.

Die Komponentenorientierung wird für die kommerzielle Anwendungsentwicklung immer wichtiger. Sie verspricht, vergleichbar der industriellen Fertigung, Systeme aus einzelnen Bausteinen schneller zu erstellen beziehungsweise miteinander zu integrieren. Für die Implementierung von Komponenten kommen heutzutage Technologien wie Active X von Microsoft, Javabeans und Enterprise Javabeans (EJB) von Sun Microsystems sowie Corba der Objekt Management Group (OMG) zum Einsatz. Diese Technologien definieren Standard-Schnittstellen und Ablaufumgebungen für die Anwendungsbausteine.

Eine wesentliche Erkenntnis aus der praktischen Arbeit auf diesem Gebiet ist, dass zwei Faktoren für den Erfolg komponentenorientierter Anwendungsentwicklung eine zentrale Rolle spielen: die Auswahl einer tragfähigen technologischen Basis (ActiveX, EJB, CORBA) sowie die geeignete Zerlegung der Anwendung, also die Identifikation und Spezifikation der Komponenten. Ersteres wird in der Regel von Unternehmen, die sich auf diesem Gebiet neu orientieren, sehr ernst genommen. Sie suchen sich im Rahmen kleiner Projekte die passende Technologie und den dazugehörigen Softwareanbieter aus. Die Zerlegung der Anwendungen in Komponenten, die die zentrale Aufgabenstellung der Analyse- und Designphase sein sollte, wird hingegen nahezu regelmäßig vernachlässigt. Die Folge ist, dass solche Projekte ohne geeignete Konzepte für die Identifikation und Spezifikation der Komponenten in der Praxis oft scheitern.

Nimmt man sich die Zeit für eine Analyse- und Designphase, dann ergibt sich heute meist folgendes Bild: Ausgehend von der Use-Case-Modellierung wird im Allgemeinen ein rein objektorientiertes Vorgehensmodell gewählt. Folgerichtig sind die wichtigsten Resultate Klassen- und Interaktionsdiagramme, die als Grundlage der Realisierung dienen. Die Aufgabe der Identifikation von Komponenten wird entweder "intuitiv" gelöst oder gänzlich der Initiative der Entwickler überlassen. Doch es existiert auch ein praktischeres Verfahren zur komponentenorientierten Entwicklung, das vor allem die Abhängigkeiten zwischen den Komponenten verringert: Die zentrale Idee ist es, das Anwendungsprogramm so zu zerlegen, dass für die Verarbeitung von Geschäftsprozessen zur Laufzeit jeweils nur eine minimale Anzahl von Komponenten geladen werden muss. Dieses Ziel ließe sich zwar sehr einfach dadurch erreichen, dass eine Komponente immer als eine "Hülle" für alle Objektklassen, die im Geschäftsprozess interagieren, konzipiert wird. Damit würde jeder Geschäftsprozess auf nur eine Komponente abgebildet. Der Nachteil dieser Lösung ist aber, dass dieselbe Objektklasse in diesem Fall in vielen verschiedenen Komponenten vorkommt. Ändert sich die Schnittstelle, heißt es alle Komponenten, die diese Objektklasse beinhalten, neu anzupassen und zu testen. Jede Objektklasse einer Anwendung sollte deshalb idealerweise in einer Komponente eingebunden werden.

Sowohl für die Zerlegung der Anwendung in Komponenten als auch für die Festlegung von Objekten, die in einer Komponente interagieren, müssen deshalb Ge-schäftsprozesse und Klassendiagramme in Beziehung gesetzt werden. Die Schnittstelle der Komponenten sollte dabei Me-thoden bilden, deren Aufruf die Abarbeitung von Geschäftsprozessen beziehungsweise Geschäftsprozessschritten anstößt. Die eigentliche Abarbeitung der Geschäftsprozesse übernehmen die Methoden der Objektklassen, die semantisch zusammengehörend gruppiert sind. Das Kriterium für die Gruppierung von Objektklassen ist die geforderte Minimierung der Abhängigkeiten zwischen den Komponenten unter der Voraussetzung, dass eine Objektklasse wenn möglich nur in einer Komponente eingebunden wird.

Wie das Gruppierungsverfahren zur Identifikation von Komponenten aussehen kann, soll ein einfaches Beispiel zeigen (siehe Abbildung 1). Dieses setzt auf einem Klassenmodell in UML-Notation mit den fünf Klassen "Kunde", "Mitarbeiter", "Produkt", "Konto" und "Konto-Management" auf. Die Objekte dieser Klassen interagieren in drei Geschäftsprozessen, die mit Hilfe von EPKs (ereignisgesteuerten Prozessketten) modelliert wurden und als "Kundenauftrag definie-ren", "Kontostand ändern", "Produkt reservieren" bezeichnet sind.

Objektklassen richtig zuordnenIm nächsten Schritt werden die Objektklassen den einzelnen Vorgängen der Geschäftsprozesse zugeordnet und das Ergebnis in einer Tabelle zusammengefasst. Die Objektklasse "Konto" ist beispielsweise im Geschäftsprozess "Kundenauftrag definieren" nicht aber im Geschäftsprozess "Produkt reservieren" eingebunden. Die Tabelle verdeutlicht, welche Objekte in welchen Geschäftsprozessen vorkommen. Das Gruppierungsverfahren setzt beim gemeinsamen Auftreten beziehungsweise Nicht-Auftreten von Objektklassen in Geschäftsprozessen auf. Bereits die einfache Datenmatrix des Beispiels verdeutlicht, dass diese Gruppierung nicht intuitiv aus den Daten sichtbar ist. Dazu sollte vielmehr ein bekanntes und bewährtes Verfahren der Statistik, nämlich die Cluster-Analyse, angewendet werden.

Für die Bestimmung der Komponenten führt man eine hierarchische Cluster-Analyse durch. Diese konstruiert eine Folge von Zerlegungen der Objektklassen, wobei die Anforderung an die Homogenität der Komponenten schrittweise verringert wird (siehe Abbildung 2). Anhaltspunkte für die Bestimmung der Anzahl der Komponenten, in die sich eine Menge von Objektklassen sinnvoll einteilen lässt, liefert das so genannte Struktogramm, das auf den Informationen im Dendrogramm aufbaut (siehe Abbildung 3).

Die ausgewählten Komponenten und deren interne Objektinteraktionen müssen in der Regel noch weiter spezifiziert werden. Hierzu lässt sich zum einen das neue Subsystemkonzept von UML 1.3 verwenden und zum anderen speziell für die Wechselwirkungen zwischen den Objekten innerhalb einer Komponente die Interaktionsmodellierung. Ersteres ist hervorragend geeignet, große Anwendungssysteme im Top-down-Ansatz objektorientiert zu entwickeln. Zudem ist es für die komponentenorientierte Softwareentwicklung von Bedeutung, denn es erlaubt die Spezifikation von Komponenten, nachdem diese wie beschrieben identifiziert worden sind.

Wichtig für den Einsatz des Subsystemkonzeptes für die Komponentenspezifikation ist Folgendes (siehe Abbildung 4): Die identifizierte Komponente muss zuerst einen Namen erhalten. Im Beispiel ist dies die Komponente mit den Objektlassen (Konto, Kunde, Konto-Mangement); sie erhält den Namen "Kontoverkehr". Er wird in dem kleinen Rechteck, das mit einer Gabel gekennzeichnet ist, eingetragen. Die genannten Objektklassen werden im Bereich Realization Elements wiedergegeben. Zudem können neue technische und inhaltliche Objektklassen wie etwa Kredit hinzukommen, die für die gesamte Funktionalität der Komponente notwendig sind.

Im Bereich Operations werden Vorgänge aus den Geschäftsprozessen als Operationen dargestellt, die die Komponente nach außen als Schnittstelle sichtbar macht: Kundenauftrag definieren, Kontostand ändern. Überdies können neue Operationen hinzukommen, zum Beispiel "Bonität berechnen", die mit Use Cases modelliert wurden. Überhaupt sieht das Subsystemkonzept vor, mit Hilfe von Specification Elements Anforderungen wiederzugeben. Auf zwei wichtige Beziehungen sei abschließend hingewiesen: Zum einen lassen sich Realization Elements mit Operations in Beziehung setzen. So hat etwa die Klasse "Kunde" die Operation "Kundenauftrag definieren" zu realisieren. Zum anderen lassen sich Realization Elements mit Specification Elements in Beziehung bringen. So hat etwa die Klasse "Kredit" den Use Case "Kredit bestimmen" zu realisieren.

Wenn es um die objektorientierte Modellierung von Anwendungssystemen geht, nimmt die Erstellung eines Klassendiagramms seit jeher eine ganz besondere Rolle ein. Viel zu wenig beachtet wird hingegen, dass für die Überführung von objektorientierten Modellen in Programmcode eine andere Darstellung ganz besonders wichtig ist: das Interaktionsmodell, welches in UML in den semantisch äquivalenten Varianten Sequenz- und Kollaborationsmodell verwendet wird.

Der Nutzen der Interaktionsmodellierung für die Entwicklung von Komponenten besteht zum einen darin, dass sich das dynamische Verhalten der Gruppe von Objekten innerhalb der Komponenten spezifizieren lässt, zum anderen die zeitlichen Abhängigkeiten von Objekten hervorgehoben werden und drittens sich der Kontrollfluss zwischen den Objekten modellieren lässt. Auf diese Weise kann mit Hilfe von Generatoren automatisch Programmcode erzeugt werden, der Aufrufe von lokalen Methoden, Kontrollfluss sowie Objekterzeugung und -freigabe widerspiegelt.

*Homayoun und Hamarz Mehmanesh, Geschäftsführer der MGM EDV-Beratung GmbH, München und MGM-Mitarbeiter Andreas Zendler sind Mitbegründer der Enterprise Javabeans Special Interest Group (www.mgm-edv.de/ejbsig).

Abb.1: Clusteranalyse

Bei der Clusteranalyse werden zunächst Konto und Kunde zusammengefasst, dann Mitarbeiter und Produkt; anschließend werden {Konto, Kunde} und Konto-Management fusioniert. Zusätzlich lässt sich dem Dendrogramm der Homogenitätsverlust zwischen den jeweils zusammengefassten Objektklassen entnehmen. Je kleiner der Wert ist, desto homogener sind die enthaltenen Objektklassen. (Abbildung 1) Quelle: MGM

Abb.2: Gruppierungsverfahren

Die Zuordnung in diesem Schaubild verdeutlicht, welche Objektklassen in der Beispielanwendung in welche Geschäftsprozesse eingebunden sind. (Abbildung 2) Quelle: MGM

Abb.3: Anzahl der Komponenten

Das Struktogramm zeigt (von rechts zu lesen), welcher Homogenitätsverlust mit jedem Fusionsschritt verbunden ist. In diesem Beispiel ist nach dem dritten Fusionsschritt eine deutliche Zunahme des Homogenitätsverlusts zu sehen. Das heißt, der Anwender trifft eine Entscheidung für die Lösung mit den fusionierten Objektklassen (Konto, Kunde, Konto-Management)und {Mitarbeiter, Produkt} als den beiden identifizierten Komponenten. (Abbildung 3) Quelle: MGM

Abb.4: Subsysteme

Das SubsystemKonzept von UML 1.3 ist hervorragend geeignet, große Anwendungssysteme im Top-down-Ansatz objektorientiert zu entwickeln. (Abbildung 4) Quelle: MGM