Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.06.2001 - 

Componentware/Universal System Engineering Process

Mit Usep komplexe Systeme spezifizieren

Wer komplexe Systeme einführen will, hat es nicht nur mit Software zu tun. Um die Systemarchitektur zu modellieren, müssen auch die Anforderungen etwa an die Hardware berücksichtigt werden. Der Universal System Engineering Process (Usep) bietet hier auf Basis der UML einen Weg zur Gliederung des gesamten Systems in Komponenten. Von Markus Reinhold*

Warum verursachen Entwicklungsprojekte immer noch unkalkulierbare und oft zu hohe Kosten, werden fast nie im Zeitrahmen fertig, liefern unzureichende Qualität und frustrieren somit häufig alle Beteiligten inklusive die Anwender? Manche behaupten, es handle sich hierbei um eine Art Kunst und die lasse sich nicht ingenieurmäßig planen. Die Frage ist: Wie viele Unternehmen können mit einer derartigen Vorgehensweise im harten Wettbewerb wirklich bestehen?

Sicher lässt sich die Entwicklung komplexer Systeme nicht beziehungsweise nur sehr selten in Form von streng sequenziellen Schritten beschreiben, wie es die Wasserfallmodelle propagiert haben. Das heißt jedoch nicht, dass Erkenntnisse und Erfahrungswerte völlig ignoriert werden sollten. Speziell im Bereich System-Engineering ist hier ein großes Verbesserungspotenzial zu erkennen.

Als System wird im Folgenden ein einheitliches Ganzes bezeichnet, das sich aus Softwareanteilen sowie Nicht-Softwareanteilen (meist Hardware) zusammensetzt und die Fähigkeit besitzt, vorgegebene Anforderungen und Ziele zu erfüllen. Der Gedanke der Komponentenorientierung ist in einer solchen Umgebung ein sehr natürlicher Ansatz und bezieht sich sowohl auf Hardware als auch auf Software.

Der Universal System Engineering Process (Details zu Usep unter www.cocoo.de) basiert auf Grundideen des Unified Process von Ivar Jacobson aus dem Haus Rational sowie des deutschen De-facto-Standards V-Modell ''97. Er nutzt speziell die objektorientierten Beschreibungsmittel der UML, beschränkt sich jedoch nicht auf Software, sondern adressiert auch den Bereich System-Engineering. Usep berücksichtigt den Umstand, dass rund 60 Prozent aller Fehler innerhalb von Entwicklungsprojekten schon in der Definition der Anforderungen liegen (www.standishgroup. org). Als Anforderung wird hier die Aussage über eine zu erfüllende Eigenschaft oder Leistung eines Produkts bezeichnet. Erschwerend kommt hinzu, dass die Beseitigung dieser Fehler mehr als 80 Prozent der gesamten Kosten für die Fehlerbehebung ausmacht. Unter Berücksichtigung dieses Sachverhaltes ist es umso erstaunlicher, welcher Stellenwert dem Thema Anforderungen in den meisten Projekten eingeräumt wird. Aussagen wie "Wir kennen die Anforderungen noch nicht genau, aber der Termin und die Ressourcen sind bereits festgelegt" hört man sehr häufig. Die Erfassung und Verwaltung von Anforderungen wird häufig sträflich vernachlässigt.

Das Wechselspiel beherrschenHier liegt ein Schwerpunkt des Usep. Aufgrund der zusätzlichen Komplexität bei der Erstellung von Gesamtsystemen im Vergleich zur Erstellung von Software ist es immens wichtig, das Wechselspiel von Anforderungen und Systemarchitektur zu beherrschen. Die evolutionäre Änderung von Anforderungen (zirka ein bis zwei Prozent pro Monat) lässt sich nicht unterdrücken und sollte somit auch in der Planung berücksichtigt werden. Allein die Weiterentwicklung des Systems wird zwangsläufig dazu beitragen, dass sich auch die Anforderungen der Benutzer entsprechend konkretisieren.

Die Rolle des Requirement-Engineering bezüglich der Erfassung und Darstellung von Zielen und Anforderungen aus dem Blickwinkel des Auftraggebers ist bei der Erstellung von integrierten Systemen dem reinen Software-Engineering sehr ähnlich. Bei komplexen Systemen kommt es jedoch häufig vor, dass nicht die Software die treibende Kraft bezüglich der nächsten Architekturentscheidungen ist, sondern die Hardware. Es ist also sinnvoll, die Systemgliederung in einem engen Regelkreis mit der Anforderungsdetaillierung zu betreiben. Sowohl die Aggregation und Dekompostion, das heißt das Bilden von Komponenten, als auch die Abstraktion und Detaillierung sind Mittel zur Komplexitätsbewältigung, die beide auf einem Hierarchisierungsgedanken aufsetzen und somit auf dieser Ebene kombinierbar sind.

Leicht verständliche DarstellungZu Projektbeginn muss die fachliche Sicht auf das zu erstellende System unter Berücksichtigung der vorgesehenen Einsatzumgebung beschrieben werden. Diese als "Anwenderforderungen" bezeichnete Sicht drückt aus, wessen Perspektive hier wiedergegeben werden soll. In der Regel bildet diese Information die Grundlage für die Abnahme des Systems durch den Auftraggeber. Hieraus ergibt sich eine sehr wichtige Rahmenbedingung für die Erstellung und Repräsentation der "Anwenderforderungen". Der Auftraggeber muss in der Lage sein, diese Information zu verstehen. Andererseits haben die Inhalte der "Anwenderforderungen" hohen Qualitätsansprüchen zu genügen, sonst sind sie für eine spätere Abnahme ungeeignet.

Die erste Rahmenbedingung erzwingt die Verwendung einer Darstellungsform, die für den Auftraggeber leicht verständlich ist. Eine solche Auswahl ist immer kundenspezifisch zu treffen. Pauschale Zuweisungen von semiformalen Beschreibungstechniken im Sinne von UML-Diagrammen sind hier problematisch. Viele Auftraggeber wünschen eine Beschreibung in textueller Form. Dieser Anforderung nach Verständlichkeit muss Rechnung getragen werden. Es ist überaus bedenklich, wie oft versucht wird, an dieser Stelle mit "EDV-Fachchinesisch" etwa in Form einer großen Fülle von UML-Diagrammen den Auftraggeber zu beglücken. Andererseits ist es äußerst kompliziert, den oben erwähnten Qualitätsansprüchen mit reiner textueller Darstellung gerecht zu werden. Wie also lässt sich dieses Problem lösen?

Um Anforderungen zu kennzeichnen, muss ein Formalismus genutzt werden, der es erlaubt, jede Anforderung klar zu identifizieren, um eine eindeutige Referenzierung aus den Architektur- und Entwurfsdokumenten heraus zu ermöglichen. Bei der Formulierung der Anwenderforderungen ist darauf zu achten, dass nur das "Was" einer gestellten Aufgabe zu beschreiben ist, und nicht das "Wie" - das heißt, sie müssen frei von versteckten Entwurfsentscheidungen sein. Ferner muss jede Anforderung prüfbar, eindeutig und widerspruchsfrei sein.

Usep stellt für die Spezifikation der Anwenderforderungen eine Dokumentenvorlage zur Verfügung. Hier wird eine konkrete Aufbaustruktur vorgeschlagen, die dem Ersteller des Dokuments helfen soll, alle zu berücksichtigenden Aspekte bezüglich der Anwenderforderungen zu erfassen. Derartige Strukturen sind durchaus umfangreich und eher als Checkliste zu verstehen. Abhängig vom Auftraggeber können die Anwenderforderungen in mehr oder wenig formaler Form beschrieben werden. Häufig ergibt sich hier die Notwendigkeit, ohne komplexe, für Auftraggeber nur schwer verständliche Darstellungsmittel auszukommen.

Da es sich in diesem Fall um ein komplexes System handelt, folgt nun dessen Zerlegung in Komponenten, die ihrerseits wieder als eine Art System betrachtet werden können. Dieser Vorgang wird so lange wiederholt, bis klare Software- und Hardwareanteile identifiziert sind.

Die Systemzerlegung bildet letztlich einen Teil der Systemarchitektur, die aus einem strukturellen wie auch aus einem kooperativen Blickwinkel beschrieben wird. Für die Darstellung solcher Sachverhalte eignen sich verschiedene Beschreibungstechniken der UML sehr gut. Hier kann nun auch mit den semiformalen Beschreibungsmitteln gearbeitet werden, da meist alle auftraggeberrelevanten Sachverhalte in der Informationsmenge "Anwenderforderungen" aufgeführt sind.

Um bei der Systemzerlegung nicht den Bezug zur Realität (Anwenderforderungen) zu verlieren, muss parallel zu jedem Schritt eine dazu passende Aufteilung beziehungsweise Detaillierung der Anforderungen geschehen. Eine reine Aufteilung ist nicht ausreichend, da mit der Zerlegung neue Schnittstellen entstehen, die als zusätzliche Anforderungen erfasst werden müssen. Somit ergibt sich folgender Kreislauf: das System um eine Stufe verfeinern - (System-)Anforderungen aufteilen, detaillieren und um die zusätzlichen Schnittstellen-Anforderungen ergänzen - jedes (Teil-) System aus dem ersten Schritt erneut um eine Stufe verfeinern.

Dieser Prozess von Aufteilung und Detaillierung wird von den "Technischen Anforderungen" abgebildet. Dabei werden sowohl das eigentliche Element der Systemarchitektur wie auch dessen Schnittstellen (systemintern und extern) betrachtet. Anforderungen, ob funktionaler oder nicht funktionaler Natur, lassen sich dann beschreiben. Wichtig dabei ist, dass die Anforderungen an ein Element der Systemarchitektur dieses als eine Art Black Box betrachten, also nicht den nächsten (Design-)Schritt in der Systemarchitektur vorwegnehmen.

Für die Darstellung dieser Anforderungsaufteilung und -detaillierung bietet die Core-UML leider keine ausreichenden Mechanismen. Speziell die Tatsache, dass Anwendungsfälle (Use Cases) nicht grafisch verfeinert werden können, ist problematisch. Hier kann man jedoch mit Hilfe der Erweiterungsmechanismen der UML (Stereotypen) in Verbindung mit den verfeinerbaren Aktivitätsdiagrammen Abhilfe schaffen.

Grundsätzlich ist die Frage zu klären, ob die "Technischen Anforderungen" ebenso wie die "Anwenderforderungen" in der Sprachwelt des Auftraggebers verfasst werden müssen. In der Regel ist dem nicht so, da die Kundenabnahme auf Basis der "Anwenderforderungen" erfolgt. Das würde bedeuten, dass bei der Aufteilung und Detaillierung innerhalb der "Technischen Anforderungen" Darstellungsmittel genutzt werden können, die ein Maximum an Präzision innerhalb des Entwicklungsbereiches ermöglichen. Hier sollte also mit den jeweils geeigneten Diagrammen der UML gearbeitet werden. Bei modellgestütztem Arbeiten ergibt sich ein Vorteil gegenüber dem natürlichsprachlichen Ansatz: Widersprüche und Lücken lassen sich in Modellen wesentlich einfacher beseitigen als in Prosatexten. Aber wie meist im Leben macht erst der richtige Mix den Erfolg aus.

*Diplominformatiker Markus Reinhold leitet das Münchner Competence Centre Objectorientation (Cocoo - reinhold@cocoo.de).

TermineInteressenten können sich zum Thema "Verbesserungspotenzial durch erprobte Entwicklungsprozesse: Rational Unified Process versus V-Modell ''97" im Rahmen bundesweiter Veranstaltungen diverser Anbieter näher informieren. Der nächste Termin am 21. und 22. Juni findet in München statt (weitere Informationen und Termine siehe auch unter www.cocoo.de). Ein inhaltlicher Überblick über beide Rahmenwerke unterstützt die Bewertung eines möglichen Einsatzes beziehungsweise einen Vergleich mit eigenen, bereits vorliegenden Ansätzen.