 |
 |
 |
|
 |
|||
 |
|||
| SZ.5 Objektorientierte Entwicklung |
SC.5 Object-Oriented Development
 Inhalt
|
|
|---|
SZ.5.1 Ablaufbeschreibung für die Aktivitäten im Submodell SE
Objektorientierung wurde vorwiegend als Programmierkonzept bekannt. Durch den Einsatz von objektorientierten Analyse- und Entwurfsmethoden können jedoch bereits sehr früh im Entwicklungsgang objektorientierte Konzepte eingesetzt werden und von der Analyse über den Entwurf bis zur Implementierung zu einer durchgängigen Betrachtungsweise für den gesamten Entwicklungsgang zusammengefügt werden.
Der Einsatz objektorientierter Konzepte begünstigt die Identifikation, Erstellung und Wiederverwendung vorgefertigter (fachlicher und technischer) Bausteine, die gegebenenfalls in Bibliotheken projektübergreifend zur Verfügung gestellt werden. Diese als sogenannte "Klassen" vorliegenden Bausteine kapseln Daten und Funktionen. Dadurch werden die Entwurfsprinzipien der Datenkapselung und der Abstraktion umgesetzt. Änderungen an Klassen sind dann ohne Auswirkungen auf andere Systemteile durchführbar, wenn sie sich lediglich auf die innere Implementierung einer Klasse, jedoch nicht auf deren äußere Spezifikation beziehen.
Klassen und Objekte sind Bausteine einer objektorientierten Architektur. Sie werden sowohl aus statischer Sicht (Klassen- und Objektmodelle) als auch aus dynamischer Sicht (Zustands- und Interaktionsmodelle) spezifiziert. Klassen werden im allgemeinen hierarchisch in Gruppen (Subsystemmodelle) zusammengefaßt.
Eine objektorientierte Vorgehensweise ist im Grundsatz gekennzeichnet durch
- iteratives Vorgehen,
- inkrementelle Entwicklung,
- Prototyping und
- Einsatz objektorientierter Methoden.
Durch den Einsatz objektorientierter Methoden werden SE-Aktivitäten zur statischen und dynamischen Modellierung der objektorientierten Architektur unterstützt. Weiterhin dienen sie der Erfassung der an das System gestellten funktionalen Anforderungen und der Beschreibung des physischen Softwareentwurfs, der physischen Plattform der objektorientierten Architektur und der Prozeßgliederung des Systems.
Durch den Einsatz von modular zusammenfügbaren Bausteinen (Klassen) sind Änderungen an der Architektur i. d. R. mit geringerem Aufwand möglich, als bei klassischer (nicht objektorientierter) Vorgehensweise. Durch den Einsatz von Klassenbibliotheken und objektorientierte Methoden wird die Verwendung vorgefertigter Teile im Sinne einer Fertigprodukt-orientierten Entwicklungsstrategie erleichtert. Entwicklungszyklen sind schneller abwickelbar, da modulare, objektorientierte Architekturen i. d. R. änderungsfreundlich sind.
Im Rahmen einer objektorientierten Vorgehensweise sind Anwenderanforderungen Ausgangspunkt aller weiteren Arbeiten und sind im Sinne einer vertragstauglichen Arbeitsgrundlage verbindlich für die gesamte Systementwicklung. Im objektorientierten Szenario werden die Anwenderforderungen im Rahmen des Gesamthorizonts verfeinert.
Der Ablauf der SE-Aktivitäten bei einer objektorientierten Vorgehensweise ist in Abbildung SZ.5 illustriert.
Vorbemerkungen:
- Um von speziellen objektorientierten Methoden zu abstrahieren, wird - soweit wie möglich - eine für alle objektorientierten Methoden gültige Vorgehensweise dargestellt.
- Objektorientierung ist ein generelles Konzept, das sich im Prinzip für alle Teile (fachlich wie technisch) eines Systems anwenden läßt. Im Szenario wird der Fall dargestellt, daß objektorientierte Konzepte möglichst weitgehend angewendet werden und es nur vernachlässigbare "konventionelle" Anteile gibt. (1)
- Die objektorientierten Ergänzungen sind kursiv dargestellt.
Abbildung SZ.5: Ablauf der SE-Aktivitäten bei einer objektorientierten Entwicklung
Time T 0-Start
Initialisierung des Projekts und Beginn der inhaltlichen Arbeiten gemäß Submodell SE.Time T 1-Assessment with Regard to Off-the-Shelf Products to be Used
Als Ergebnis von Aktivität SE1.2 - Anwendungssystem beschreiben liegt eine grobe Systembeschreibung vor, die den Kern und den Gesamthorizont für die Funktionalität des Systems beschreibt. Hier wird das System zunächst in Bereiche untergliedert, wobei jeder Bereich aus konzeptionell fachlicher Sicht eine Einheit für die Analyse darstellt. Anwenderanforderungen werden in Form von Anwendungsfällen, sogenannten "Use Cases" beschrieben. Die so definierten Anwendungsfälle stellen mit ihren funktionalen Anforderungen eine Basis für die Ermittlung von Klassen und Objekten, für die Zuordnung von Funktionalität zu Klassen und den Entwurf von Schnittstellen dar. Sie werden auch zur Abstimmung der Anwenderanforderungen mit dem Nutzer eingesetzt. Die für ein System spezifizierten Anwendungsfälle enthalten in ihrer Gesamtheit die anwendungsorientierten, funktionalen Anforderungen an das System. Darauf aufbauend werden die objektorientierten Konzepte der Klassen- und Objektmodellierung eingesetzt, um im weiteren als durchgängige Darstellungsweise bis zur Implementierung verfeinert zu werden. Wesentliche Aufgabe der Klassen- und Objektmodellierung ist, die statischen Aspekte objektorientierter Systeme zu erfassen. Die Dynamik und die Interaktionen innerhalb objektorientierter Systeme werden mit anderen objektorientierten Elementarmethoden erfaßtFür einige der in Aktivität SE1.5 - System fachlich strukturieren identifizierten Bereiche (erste Ausbaustufe) sind die fachlichen Anforderungen zum Teil vollständig (Bereich 1), zum Teil unvollständig (Bereich 2) erstellt.
Die Beschreibung der Funktionalität enthält die Gesamtheit der Anwendungsfälle ("Use cases") und der darauf aufbauenden ersten Klassenstruktur - in der vor allem die Verantwortlichkeiten der Klassen und deren Zusammenarbeit beschrieben sind - sowie eine erste Darstellung der Dynamik und der Interaktionen zwischen Objekten der Klassen.
Time T 2-Integration of Predefined User-Level Modules
Wichtiger Bestandteil einer fortgeschrittenen objektorientierten Entwicklung ist das Vorliegen und der Einsatz von Bibliotheken mit vordefinierten Klassen.Die Verwendung vordefinierter Klassen soll
- die Entwicklungsarbeiten durch Einsparung an Entwicklungsaufwand beschleunigen,
- die Qualität durch Integration "gereifter" Klassen erhöhen,
- die fachlich und technisch ausgerichteten Entwurfsarbeiten an verfügbaren Bausteinen orientieren, um kostengünstigere Lösungen zu erzielen,
- durch evolutionäre Weiterentwicklung der Klassenbibliothek als Nebeneffekt ("spin off") der Systementwicklung zukünftige Entwicklungen fördern.
Die Ergebnisse der Aktivitäten SE1.2 - Anwendungssystem beschreiben bis SE1.5 - System fachlich strukturieren bilden zusammen die Anwenderforderungen, die zum Zeitpunkt T 2 in einer ersten Version vorliegen.
Die Anwenderanforderungen müssen so detailliert sein, daß folgende Ziele erreicht werden:
- Alle relevanten fachlichen Bereiche müssen möglichst benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt werden.(2)
- Das Zusammenspiel der Bereiche muß für die Projektbeteiligten klar dargestellt sein.
- Es muß klar sein, in welchen (bereichsspezifischen) Stufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (ggf. als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden.
Zeitpunkt T 3 - Entwurf der technischen Lösung
Als Ergebnis von Aktivität SE2.1 - System technisch entwerfen sind die Bereiche der ersten Ausbaustufe in ihrer technischen Umsetzung (in der Systemarchitektur und den Technischen Anforderungen) beschrieben.Die Beschreibung der Systemarchitektur im objektorientierten Bereich erfolgt über Klassenhierarchien. Dabei werden die Klassen und Objekte, die aufgrund der Anwenderanforderungen definiert wurden durch technische Klassen und Objekte ergänzt und zu einer objektorientierten Architektur zusammengefaßt. Hierbei ist die Anwenderorganisation als Einflußfaktor mit zu berücksichtigen
Technische Klassen und Objekte können ergänzenden technischen Bereichen zugeordnet werden, z. B. Bereichen zur Daten- und Systemverwaltung, mit Mechanismen und Funktionen zur Unterstützung der Anwenderbereiche oder in solche mit Hilfsmitteln zur Softwareimplementierung.
Wie für die fachliche Strukturierung kann auch für die technische Strukturierung auf Klassenbibliotheken aufgesetzt werden. Durch die Berücksichtigung von technischen Lösungen im Rahmen der SE1 - System-Anforderungsanalyse-Aktivitäten entsteht eine fachlich fundierte und ausreichend spezifizierte Vorgabe für die Realisierung der ersten Ausbaustufe durch einen Auftragnehmer. Die Systemarchitektur und die Technischen Anforderungen werden ergänzt und alle weiteren, realisierungsspezifischen Dokumente und Entwicklungsergebnisse erstellt.
Mit den Technischen Anforderungen und der Systemarchitektur liegen objektorientierte Modelle vor, die nahtlos als Vorgabe für die Implementierung verwendet werden können. Im Rahmen der Implementierung kann es aus technischen Gründen zur Formulierung neuer - technischer - Objekte kommen, die ergänzend in die Systemarchitektur und die Technischen Anforderungen aufgenommen werden.
Nach Abschluß der Realisierung wird die erste Ausbaustufe in die Nutzung übergeleitet.
Zeitpunkt T 4 bis T N-1 - Weitere Ausbaustufen
Zum Zeitpunkt T 4 liegt als Ergebnis der wiederholten Durchführung von Aktivität SE1.2 - Anwendungssystem beschreiben eine verfeinerte Version der groben Systembeschreibung vor. Die Verfeinerungen bewegen sich im Normalfall im Rahmen des Gesamthorizonts, der bereits zum Zeitpunkt T 1 definiert wurde. Sie stellen eine Präzisierung der Anforderungen dar. Es kann durch solche Verfeinerungen jedoch auch zu neuen Bereichen kommen.Für die Bestandteile der zweiten Ausbaustufe werden die fachlichen Anforderungen erarbeitet. Dabei können bisher nicht berücksichtigte Bereiche neu beschrieben und bereits vorhandene verfeinert werden. Insbesondere werden die fachlichen objektorientierten Modelle fortgeschrieben und verfeinert. Erste Rückmeldungen aus der Nutzung der ersten Ausbaustufe werden berücksichtigt.
Die damit in einer zweiten Version vorliegenden Anwenderanforderungen bilden den Ausgangspunkt für die Verfeinerung und Ergänzung der Systemarchitektur und der Technischen Anforderungen.
Der Realisierer, beispielsweise ein Auftragnehmer, erweitert die bereits produktive Systemversion 1 um die neu hinzugekommenen Teile und integriert sie im Rahmen der Integrationsschritte. Eventuell sind im Rahmen der Integrationsarbeiten auch Änderungen an der Systemversion 1 durchzuführen. Nach Abschluß der Realisierung wird auch die zweite Ausbaustufe in die Nutzung übergeleitet.
Diese Arbeitsschritte werden für jedes Inkrement wiederholt.
Zeitpunkt T N - vollständige Systembeschreibung
Zum Zeitpunkt T N liegen Anwenderanforderungen, Systemarchitektur und Technischen Anforderungen vollständig und konsistent vor. Nach Realisierung und Überleitung der letzten Ausbaustufe in die Nutzung befindet sich das komplette System in der Nutzung.
SZ.5.2 Zusammenspiel mit den übrigen Submodellen
Das Zusammenspiel mit den übrigen Submodellen entspricht dem Szenario zur Anwendung des V-Modells bei einer inkrementellen Systementwicklung.
SZ.5.3 Criteria for the Selection of Scenarios
Die folgende Auflistung von Vor- und Nachteilen der objektorientierten Technologie unterstützt die Entscheidungsfindung zur Auswahl der objektorientierten Vorgehensweise.
Vorteile:
- Objektorientierte Methoden zur Ermittlung der Anwenderanforderungen, Prototyping und iteratives Vorgehen ermöglichen eine intensive, stufenweise Einbeziehung des Anwenders in die Konkretisierung. Dadurch ist eine begleitende Validierung bereits während der Entwicklung möglich.
- Objektorientiert entwickelte Systeme sind weniger empfindlich gegenüber Veränderungen als "strukturiert entwickelte Systeme".
- Objektorientiert entwickelte Systeme sind leichter wartbar als "strukturiert entwickelte Systeme".
- Die Ausdruckskraft der objektorientierten Programmiersprachen kann ausgenutzt werden.
- In objektorientiert entwickelten Systemen liegen zahlreiche Performance-Risiken. Diese können verschiedene Ursachen haben, angefangen bei der Verflechtung von Klassen, die tief im Vererbungsgitter angesiedelt sind bis zum dynamischen Aufbau und dem Löschen von Objekten. Dies ist besonders beim Aufbau sehr zeitkritischer Realzeitsysteme zu beachten.
- Die Vertragsgestaltung muß Rücksicht nehmen auf sich ändernde und lückenhafte Anforderungen.
- Qualifiziertes, OO-methodisch ausgebildetes Personal,
- OO-Werkzeuge zur methodischen (CASE-Tools) und programmtechnischen Realisierung (Compiler für OO-Sprachen),
- ein geeignetes organisatorisches Umfeld,
- effizientes Konfigurations- und Änderungsmanagement,
- Forderungscontrolling in allen Entwicklungszyklen,
- Risikomanagement zu Beginn jedes Entwicklungszyklus,
- angemessene und effiziente Maßnahmen zur Qualitätsprüfung sowohl von Anforderungen als auch von lauffähigen und prüfbaren HW-/SW-/System-Anteilen,
Hinweise: (1) Im Unterschied dazu wird z. B. im Szenario für die Entwicklung wissensbasierter Systeme grundsätzlich von einer Zweiteilung in den wissensbasierten Teil einerseits und einen relevanten "konventionellen" Anteil andererseits ausgegangen.
|
|
|
This page online • GDPA Online • Last Updated 03.Mar.2004 by C. Freericks |