Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
1.1 Motivation
1.2 Anforderungen an den Leser
1.3 Aufbau der Arbeit
2 Wiederverwendung von SW-Komponenten
2.1 Begriffsklärungen
2.1.1 Begriff der SW-Komponente
2.1.2 Begriff der Wiederverwendung
2.2 Ziele der Wiederverwendung
2.3 Facetten der Wiederverwendung
2.4 Arten der Wiederverwendung
2.4.1 Ad Hoc-Wiederverwendung
2.4.2 Geplante Wiederverwendung
2.4.2.1 Generative Wiederverwendung
2.4.2.2 Kompositionelle Wiederverwendung
3 Use Cases
3.1 Einordnung von Use Cases in den SW Engineering Prozess
3.2 Zweck und Aufgaben von Use Cases
3.3 Aufbau von Use Cases
3.3.1 Allgemeines
3.3.2 Akteure und Ziele
3.3.3 Standardablauf
3.3.4 Alternativablauf
3.3.5 Beziehungen zwischen Use Cases
3.3.6 Aufbau von Use Cases bei VW
3.4 Use Cases und UML
3.4.1 Allgemeines
3.4.2 Grafischer Aufbau eines Use Case Model
3.4.3 Generalisierung/Spezialisierung
3.5 Ein Use Case Problem liegt im Detail
4 Aufwandsabschätzung bei SW Projekten
4.1 Überblick über vorhandene Modelle
4.2 Abschätzung von Projektaufwand mittels UCP-Methode
4.3 Beurteilung der UCP-Methode
5 Use Case basierte Wiederverwendung von SW-Komponenten
bei der Volkswagen Bank
5.1 Analyse der Ausgangssituation
5.1.1 Beschreibung von SEP (VW Richtlinie zur SW Entwicklung)
5.1.1.1 SEP als Konzernstrategie
5.1.1.2 Modellbeschreibung
5.1.2 SW-Entwicklung auf der Grundlage von Use Cases
5.1.2.1 Beschreibung des Ist-Zustands
5.1.2.2 Vorzunehmende Veränderungen
5.1.3 Beschreibung der Produkte der Volkswagen-Bank, I-SEP
5.2 Generelles zur Beschreibung der Systematik zur Aufwands- und Wiederverwendungsabschätzung von SW-Komponenten
5.2.1 Vorstellung des Konzepts als Metaprozess
5.2.2 Einordnung des Konzepts anhand bereits vorhandener Ansätze
5.2.3 Durchführung von Entwicklerinterviews
5.3 Vorstellung des Konzepts im Detail
5.3.1 Idee
5.3.2 Vorbedingungen
5.3.3 Entscheidungsgrundlage
5.3.4 Bewertung der Elemente eines Use Case
5.3.5 Suche nach einem "ähnlichen" Use Case
5.3.6 Bewertung und Korrektur durchzuführender Tätigkeiten
5.3.7 Festlegung der Skalierung
5.3.8 Die Korrekturfaktoren
5.3.8.1 Zweck der Tätigkeitskorrekturfaktoren
5.3.8.2 Zweck des zweiten Korrekturfaktors
5.3.9 Umwandlung des gemessenen Aufwands in Zeiteinheiten
5.3.9.1 Vorgehen und Ergebnisse
5.3.9.2 Probleme während des Vorgangs
5.3.9.3 Änderungsvorschläge
5.4 Simulation eines Auswahlvorganges zur Wiederverwendung
von SW-Komponenten
5.4.1 Analyse der Simulationsumgebung und Bewertung der
neuen Anforderungen
5.4.1.1 Allgemeines
5.4.1.2 Beschreibung des neuen Use Case (UC_A)
5.4.1.3 Ermittlung der Komplexität für UC_A
5.4.1.4 Beschreibung von UC_B
5.4.1.5 Beschreibung von UC_C
5.4.2 Suche nach dem ähnlichen Use Case
5.4.3 Aufwandsermittlung bei einer Wiederverwendung
5.4.3.1 Ermittlung des Aufwands im Vergleich zu UC_B
5.4.3.2 Ermittlung des Risikofaktors für UC_B
5.4.3.3 Ermittlung des Gesamtaufwands für UC_B
5.4.3.4 Ermittlung des Aufwands im Vergleich zu UC_C
5.4.3.5 Ermittlung des Risikofaktors für UC_C
5.4.3.6 Ermittlung des Gesamtaufwands für UC_C
5.4.4 Berechnung des Wiederverwendungsquotienten
5.4.4.1 Wiederverwendungsquotient für UC_B
5.4.4.2 Wiederverwendungsquotient für UC_C
5.4.5 Auswahl der Komponente
5.5 Beurteilung des Konzepts
6 Vorschlag für eine toolbasierte Unterstützung des Konzepts
7 Fazit/Ausblick
8 Anhang
Glossar
Literaturverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2-1: Generative Wiederverwendung
Abbildung 2-2: Kompositionelle Wiederverwendung
Abbildung 3-1: Aktivitäten der Systementwicklung
Abbildung 3-2 The Hub and Spoke model of requirements
Abbildung 3-3: Grafische Darstellung eines Use Case Model
Abbildung 3-4: Darstellung einer Spezialisierung
Abbildung 5-1: SEP-Modell objektorientiert
Abbildung 5-2: SEP-Modell, Detailansicht Phase
Abbildung 5-3: ER-Modell Auftragsvergabe VW
Abbildung 5-4 : Architektur der Web-Applikationen der VW-Bank
Abbildung 5-5: Killerkriterien
Abbildung 5-6: Bewertung Anpassung
Abbildung 5-7: Bewertung Übernahme
Abbildung 5-8: The estimating dilemma
Abbildung 6-1: Architekturvorschlag
Tabelle 2-1: Facetten der Wiederverwendung
Tabelle 4-1: Gewichtung der Akteure nach Karner mit Rechenbeispiel
Tabelle 4-2: Gewichtung der UC Typisierungen mit Rechenbeispiel
Tabelle 4-3: Übersicht und Gewichtung der technischen Faktoren
Tabelle 4-4: Gewichtung der Umgebungsfaktoren
Tabelle 5-1: Umrechnung UCPs in Aufwand nach Karner
Tabelle 5-2: Durchschnittlicher Aufwand pro Schritt intervallbezogen
Tabelle 5-3: Übersicht über die neue Bewertung
Tabelle 5-4: Neuverteilung des Aufwands für die Akteure
Tabelle 5-5: Berechnung der Aufwandspunkte
Tabelle 5-6: Aufschlüsselung der GUI
Tabelle 5-7: Aufschlüsselung der Extended Use Cases
Tabelle 5-8 Vergleich zwischen UC_B und UC_A
Tabelle 5-9: Vergleich der Transaktionen zwischen UC_C und UC_A
„Handle stets so, daß weitere Möglichkeiten entstehen.“
Heinz von Foerster
Aufwandsabschätzungen für komplette SW-Projekte oder auch nur Fragmente eines einzelnen SW-Projektes sind für Unternehmen ein wichtiges Planungs- und Steuerungsinstrument. Hierdurch sollen Überschreitungen von Budget- und Zeitvorgaben vermieden werden. Eine termingerechte Auslieferung der SW-Produkte ist ein wesentliches Merkmal, um weiterhin im Wettbewerb zu bleiben und das Unternehmen zu stärken [8]. Zur Verkürzung von Budget- und Zeitvorgaben ist es von Vorteil, mögliche Potenziale von wieder zu verwendenden SW-Bestandteilen zu erkennen und einzusetzen. Die Entwicklungszeiten und die Kosten eines Projekts können hiermit erheblich verkürzt werden [1]. Die Entscheidung, ob ein bereits implementiertes SW-Artefakt noch einmal in einem neuen System zum Einsatz kommt, ist einerseits von der Ähnlichkeit des alten Artefakts zu den neuen Anforderungen abhängig, andererseits wird eine Entscheidung aber auch von den Kosten beeinflusst [1]. Oftmals wird die Entscheidung über eine Wiederverwendung von bereits implementierten Artefakten auf Code-Ebene getroffen [8]. Aus diesem Grund findet eine Beurteilung erst spät innerhalb des SW-Engineering Prozesses statt. Wünschenswert ist es für das Unternehmen jedoch, bereits innerhalb der Anforderungsanalyse zu einer Entscheidung über eine mögliche Wiederverwendung von SW-Bestandteilen zu gelangen. Für Zeit- und Kosteneinsparungspotentiale gilt es, diese so früh wie möglich zu entdecken, um vorzeitig den Umfang des Aufwands für ein Projekt planen zu können [8].
Auf Grund dieser Annahmen wird der Versuch unternommen ein Konzept zu modellieren, dass eine Aussage über die Wiederverwendung von SW-Artefakten auf der Grundlage von textuellen Use Case Beschreibungen ermöglicht. Das Modell soll dabei die Funktion erfüllen, den Aufwand für ein Fragment absolut in Aufwandskennzahlen zu darzustellen und über die Berechnung eines Wiederverwendungsquotienten eine Aussage über die Effizienz der Wiederverwendung der SW-Komponente zu liefern.
Um einen Umsetzungsvorschlag für die Praxis zu erlangen, soll abschließend in dieser Ausarbeitung eine Idee umschrieben werden, die eine Wiederverwendung von SW-Komponenten auf der Grundlage von Use Cases toolunterstützt ermöglicht. Hierzu soll ein Use Case Repository gebildet werden, welches dem gesamten Unternehmen zur Verfügung stehen soll.
In der folgenden Ausarbeitung wird eine Möglichkeit vorgestellt, mit der ohne besondere fachliche Vorkenntnisse eine Aufwandsabschätzung des Programmierumfangs auf der textuellen Ausprägung von Use Cases getroffen werden kann. Dem Leser werden zum Verständnis für dieses Konzept die angrenzenden Themengebiete aufgezeigt. Diese werden innerhalb der Ausarbeitung diskutiert und in Konzeptrichtung angepasst. Somit sind keine besonderen Fachkenntnisse zu den einzelnen Themengebieten erforderlich.
Über die unter Punkt 1.1 genannten Aspekte hinaus enthält diese Ausarbeitung folgende Inhalte:
In Punkt 2 dieser Ausarbeitung werden die Beweggründe für eine SW-Wiederverwendung genauer im Detail beschrieben. Es werden verschiedene Arten der Wiederverwendung von SW-Komponenten dargestellt und in welcher Weise eine Anwendung dieser innerhalb von Unternehmen zum Tragen kommt. Außerdem findet eine Einordnung des entwickelten Konzepts in die verschiedenen Arten der Wiederverwendung von SW-Komponenten statt.
Im Mittelpunkt von Gliederungspunkt 3 stehen Use Cases. Hier wird beschrieben, aus welcher Phase des SW Engineering Prozesses Use Cases resultieren, in welcher Ausprägung sie vorkommen und welchem Zweck sie dienen. Des Weiteren wird die UML-Notation von Use Cases vorgestellt. Unter Gliederungspunkt 3.3 werden die Eigenschaften von Use Cases im Detail erläutert, damit eine spätere Bewertung dieser Kriterien möglich ist. Beendet wird das Kapitel 3 mit der Betrachtung des Detailliertheitsgrades, der beim Verfassen von Use Cases stark vom Autor abhängt und somit unterschiedlich sein kann. Dieses Problemfeld bringt Schwierigkeiten bei der späteren Bewertung mit sich.
Punkt 4 dieser Ausarbeitung beinhaltet die Thematik der Aufwandsabschätzung für zukünftige SW-Projekte. Zu Beginn wird ein Überblick über bereits vorhandene Methoden und Ansätze der Aufwandsvorhersage gegeben. Im Anschluss daran wird eine Methode vorgestellt, die vor einigen Jahren in dem Unternehmen "Rational" erfunden wurde, um Aufwandsabschätzungen für SW-Projekte auf der Grundlage von Use Cases zu treffen. Diese "Use Case Point-Methode" bedient sich leider, trotz ihrer Einfachheit, einer nicht sehr großen Popularität. Das Kapitel wird mit der Bewertung dieser Methodik auf Grundlage von Forschungsberichten beendet.
Der Fokus des Gliederungspunktes 5 der Ausarbeitung liegt auf der Vorstellung des entworfenen Konzepts zur Aufwandsermittlung einzeln zu implementierender Use Cases auf der Grundlage von textuellen Beschreibungen. Zunächst werden die VW Bank internen Spezifikationen erläutert. Hierzu wird der "Systementwicklungsprozess (SEP)" von der VW Bank erörtert, der sehr stark einem traditionellen SW Engineering Prozess gleicht, jedoch um einzelne Volkswagen spezifische Dokumentationen ergänzt wurde. Des Weiteren wird eine mögliche Systemarchitektur beschrieben, die von der VW Bank für die Erstellung von internetbasierten Verkäuferarbeitsplätzen benutzt werden könnte. Anschließend wird das Konzept zur Aufwandsabschätzung von wieder zu verwendenden SW-Komponenten als Metaprozess erklärt und in vorhandene Systematiken zur Abschätzung von Wiederverwendungspotentialen eingegliedert. Nachdem im Gliederungspunkt 5.3 das Konzept im Detail erklärt wurde, findet unter dem darauf folgenden Punkt 5.4 eine Simulation des Konzepts statt. Hier wird davon ausgegangen, dass zwei bereits bewertete und implementierte Use Cases zur Auswahl für eine Wiederverwendung stehen. Die Requirements einer Funktionalität des neuen Systems soll anhand einer geschätzten Aufwandsberechnung darüber entscheiden, welche SW-Komponente für eine Wiederverwendung ausgewählt werden soll. Kapitel 5 wird mit einer detaillierten Evaluierung des Konzepts geschlossen.
Da diese Ausarbeitung rein theoretischer Natur ist und eine Ergebnisbetrachtung der Praxis nicht stattfinden kann, wird im Kapitel 6 eine Idee für die Umsetzung eines toolbasierten Ansatzes der Methodik unterbreitet.
Die Ausarbeitung endet mit einem Fazit und einem Ausblick bezüglich des entworfenen Konzepts.
"Systematic software reuse and the reuse of components influence almost the whole software engineering process (independent of what a component is)."
Johannes Sametinger
In der Literatur existieren mehrere unterschiedliche Definitionen über den Umfang und den Inhalt einer SW-Komponente. Eichinger et al. spricht davon, dass eine Komponente ein speziell zur Wiederverwendung geschaffener Baustein ist [8]. Bei dem Unternehmen Texas Instruments ist die Bedeutung eine andere [[33] nach [32]]:
„Eine Software Komponente ist ein Code-Modul, das ein oder mehrere klar definierte Dienste implementiert, die durch einen Satz von öffentlichen Schnittstellen festgelegt sind.“
Im Rahmen einer Vorlesung an der Universität Stuttgart ist eine Komponente jegliche Beschreibung von Zusammenhängen, aus der Code generiert werden kann. Darüber hinaus werden auch alle wesentlichen Ergebnisse des SW-Engineering Prozesses als Komponenten betrachtet, somit auch der resultierende Programmcode [34].
Sametinger, der in Komponenten die gleichen Aspekte sieht wie [33], beschreibt in seinem Buch „ Software Engineering with Reusable Components “ einzelne Eigenschaften, die eine Komponente erfüllen sollte [28]:
1. Self-containedness:
"Components should be self-contained, i.e., reusable without the need to include other components for reuse. In this sense, a function is regarded as a component if it can be used on its own, i.e., without the need of any other functions […]."
2. Identification:
"Components have to be clearly identifiable, e.g., contained in a file rather than being spread over many locations and intermixed with other artefacts of software or documentation […]."
3. Functionality:
"Components describe and/or perform specific functions; i.e., components have a clearly specified functionality which they perform or describe […]."
4. Interfaces:
"Components have to have clear interfaces and hide details that are not needed for reuse […]."
5. Documentation:
"Documentation is indispensable for reuse. The most useful component is rendered useless for reuse purposes when appropriate documentation is not available […]."
6. Reuse status:
"Components must be maintained to support systematic reuse. The reuse status contains information about who is the owner of a component, who maintains it, who can be contacted in case of problems arise, and what is the quality status of a component […]."
Innerhalb dieser Ausarbeitung soll die Definition nach [32] ihren Geltungsbereich haben. Eine Komponente sollte eine bestimmte Funktionalität besitzen und mit anderen Komponenten über Schnittstellen kommunizieren. Aus diesem Grund sind Methoden, Module oder auch ein Sortieralgorithmus innerhalb einer Methode, als Komponenten zu betrachten. Bei der Entwicklung auf der Grundlage von Use Cases ist es häufig der Fall, dass die funktionalen Anforderungen nicht zwingender maßen etwas über die Struktur oder den resultierenden Code des folgenden Programms oder deren Komponenten aussagen [14]. Insofern wird für diese Ausarbeitung eine "weichere" Betrachtung einer Komponente gewählt, die nicht unbedingt an den o.g. Eigenschaften festgemacht werden kann.
Wird die Begrifflichkeit der SW-Wiederverwendung genauer betrachtet, so kann zwischen zwei verschiedenen Ausprägungen unterschieden werden. Die SW Wiederverwendung (Reuse) beschreibt den aktiven Prozess des erneuten Einsatzes von Objekten in veränderten Umgebungen. Die Wiederverwendbarkeit (Reusability) hingegen beurteilt, ob ein Objekt wieder verwendet werden kann [14].
In den folgenden Ausführungen wird ein Konzept vorgestellt, mit dem eine Feststellung der Wiederverwendbarkeit von SW-Komponenten beurteilt wird. Diese Beurteilung findet auf der Grundlage des aufzubringenden Aufwands für die Anpassung der Komponente statt. Insofern wird versucht, auf eine klare Zuweisung der Begrifflichkeit zu achten, wobei die Grenzen nicht immer eindeutig zu ziehen sind [14].
Der Drang zu einer Wiederverwendung von SW hat seinen Ursprung in oftmals knapp geplanten Zeit- und Kostenkorridoren einzelner Projekte. Durch knappe Ressourcen wächst der Drang, bereits entwickelte SW-Komponenten wieder einzusetzen. Hierdurch sollen eine Erhöhung der Produktivität, eine Verbesserung der Qualität und eine Reduktion der Wartungskosten erreicht werden [8, 10]. Die Produktivität stellt das Verhältnis vom Output zum Input dar [23]. Eine Steigerung kann durch eine Verkleinerung des Inputs oder durch eine effizientere Produktionsmethode erzielt werden. Somit folgt eine Erhöhung der Produktivität aus einer Reduktion des Wartungsaufwandes oder/und durch eine Verkleinerung des Entwicklungsaufwandes. Im Folgenden findet eine nähere Erläuterung der Sachverhalte statt.
- Reduzierung des Entwicklungsaufwands:
Durch die Wiederverwendung von SW werden redundante Arbeiten vermieden. Somit kann die Entwicklungszeit verkürzt werden. Dies hat zur Folge, dass kürzere Time to Market Zeiträume erreicht werden können. Sametinger berichtet von einer Verkürzung der Entwicklungszeit von bis zu 42% [[16] zitiert nach [28]].
- Reduzierung des Wartungsaufwands:
Wenn geprüfte und bereits korrigierte Codefragmente erneut eingesetzt werden, wird davon ausgegangen, dass diese Fragmente einen geringen Wartungsaufwand verursachen [28]. Sollten dennoch Fehler auftreten, wird es leichter sein, diese zu finden. Defekte in bereits bekannten und überarbeiteten Komponenten sind leicht zu lokalisieren. Somit wird die Suche nach Fehlern verkürzt. Ebenfalls werden Einarbeitungszeiten verringert [32].
- Erhöhung der SW-Qualität:
Damit eine SW-Komponente wieder verwendbar ist, muss sie bestimmten Anforderungen gerecht werden. Sind die Kriterien für eine Wiederverwendbarkeit erfüllt, so ist auch gleichzeitig die Qualität der SW hoch einzuschätzen. Demzufolge wird durch eine angestrebte Wiederverwendung von SW die Qualität steigen [14].
Bei näherer Betrachtung der Wiederverwendung von SW-Komponenten gibt es eine Vielzahl von Blickwinkeln, die zu berücksichtigen sind. Küffmann liefert hierzu folgende Aufgliederungen der verschiedenen Facetten der Wiederverwendung [14]:
Tabelle 2-1: Facetten der Wiederverwendung [14].
Abbildung in dieser Leseprobe nicht enthalten
Die Abbildung zeigt, dass eine Wiederverwendung aus vielen verschiedenen Perspektiven zu betrachten ist. Die obere Zeile der Tabelle zeigt unterschiedliche Charakterisierungsmöglichkeiten für eine Wiederverwendung. Die Ausprägung der einzelnen Eigenschaften listet jeweils eine Möglichkeit auf, eine Wiederverwendung durchzuführen. So bringt die Betrachtungsweise "By Scope" beispielsweise die Möglichkeiten einer entwurfsstufenfremden, domäneninternen (horizontal) oder einer domänenfremden (vertikal) Wiederverwendung an.
Die Facette "By Intention" bietet folgende Varianten:
Wird sich für eine „Black-Box" Wiederverwendung entschieden, so wird das wieder zu verwendende Objekt ohne Veränderungen eingebaut. Die "White-Box" Variante hingegen bietet eine Modifikation der Komponente an. Während die erstgenannten beispielhaft erläuterten Facetten keine Überschneidungspunkte haben, besitzt die Kategorie "By Mode" teilweise Eigenschaften der "By Intention"-Kategorie. Beispielsweise werden bei einer „Ad-hoc“ Wiederverwendung SW-Bestandteile ungeplant übernommen und modifiziert in die neue Umgebung eingesetzt [14]. Eine ähnliche Eigenschaft bietet der „White-Box“ Ansatz [28]. Die vorgestellten Techniken der Wiederverwendung schließen sich nicht zwingend voneinander aus. Je nach Unternehmen und Art der Wiederverwendung sind Mischformen möglich. Somit wird beispielsweise in der VW Bank eine „Ad-hoc“ Wiederverwendung und eine kompositionelle Wiederverwendung genutzt. Im nächsten Kapitel werden deshalb die Bereiche „By Mode“ und „By Technique“ näher betrachtet.
Ein Charakteristika der "Ad hoc" Wiederverwendung ist das ungeplante und nicht systematische Verwenden von SW-Bestandteilen auf Code Ebene. Der Prozess beschreibt das Wiederfinden von bestehenden Entwicklungsprodukten über das Erinnerungsvermögen des Entwicklers. Hierbei kommen nach Küffmann vor Allem drei Tätigkeiten zum Zuge: "Copy, Paste and Modify" [14].
Die unsystematische Wiederverwendung von SW verspricht weder starke Einsparungen noch hohe Produktivitätssteigerungen [14]. Der Grund dafür liegt in der spezifisch entwickelten SW. Der Quelltext wurde für ein spezielles Problem geschrieben und erfordert im Allgemeinen einen hohen Aufwand, um an die neuen Anforderungen angepasst zu werden [33].
Bei der generativen Wiederverwendung wird von einer Formalisierung immer wiederkehrender Problemlösungen ausgegangen. Je nach dem, wie automatisiert diese eingesetzt werden können, kann eine Unterscheidung zwischen "Design Patterns" und "Reusable Patterns" getroffen werden.
Bei den "Design Patterns" steht eine Verwendung von Entwurfsmustern im Vordergrund. Diese Entwurfsmuster stellen Lösungsansätze für immer wiederkehrende Entwurfsprobleme zur Verfügung [33]. Durch den wiederkehrenden Einsatz dieser "Schablonen" findet eine Aufnahme von Erfahrungswerten statt. Dadurch können Konzepte für SW-Projekte von Mal zu Mal schneller geschaffen werden [10]. Design Patterns sind unabhängig von jeglicher Programmiersprache zu betrachten. Durch die Verwendung von Design Patterns können große und komplexe SW-Projekte leicht verständlich gemacht werden [11]. Ein denkbares Beispiel für ein Design Pattern könnte die Beschreibung eines einheitlichen Datenbankaufbaus für einzelne Konzerne innerhalb eines Unternehmens sein.
Bei den "Reusable Patterns" kommt zu den Entwurfsmustern noch die automatisierte Erzeugung des Quellcodes hinzu [18]. Hierbei wird aus den programmiersprachenunabhängigen Beschreibungssprachen über einen Generator Quellcode erzeugt, der wiederum mit der Hilfe eines Compilers in eine (mehrere) funktionierende Applikation(en) übersetzt wird. Ein Beispiel hierfür ist der Anwendungsgenerator "Composer" der Firma Texas Instruments. Abbildung 2-1 soll das Szenario der automatischen generativen Wiederverwendung verdeutlichen:
Abbildung 2-1: Generative Wiederverwendung [18].
Abbildung in dieser Leseprobe nicht enthalten
Bei einer kompositionellen Wiederverwendung werden neue Anforderungen auf der Basis von vorhandenen "Bausteinen" befriedigt. Hierbei werden komplexe Anforderungen durch viele einzelne, "kleinere" zusammengesetzte Bausteine erfüllt. Diese sollten möglichst unverändert eingesetzt werden. In den meisten Fällen ist diese Vorgabe jedoch kaum zu erfüllen [28]. Unter der Maßgabe der kompositionellen Wiederverwendung sollten ausschließlich Programmteile neu implementiert werden, die nicht vorhanden sind und auch nicht durch leichte Modifikation angepasst werden können.
Abbildung 2-2: Kompositionelle Wiederverwendung [18].
Die kompositionelle Wiederverwendung basiert auf der Sammlung und Aufbewahrung von Funktionalitäten innerhalb eines Komponenten Repositories. Diese Funktionenbibliothek bildet die Grundlage für den Auswahlprozess einzelner Bausteine, aus denen durch Änderung und Erweiterung eine neue Anwendung entsteht.
"Under normal circumstances , they serve as a means of communication from one person to another, often among people with no special training. Simple text is, therefore, usually the best form."
Alistair Cockburn
Betrachtet man den „Plan-Driven“ Prozess, wie er von Jacobson et al. dargestellt wird [12], so ergeben sich innerhalb des SW-Entwicklungsprozesses drei Kernphasen: die Phasen der Systemanalyse und -konstruktion und die Phase des Systemtests. Abbildung 3-1 zeigt die Phasen der Systementwicklung.
Abbildung 3-1: Aktivitäten der Systementwicklung [12].
[Abbildung in dieser Leseprobe nicht enthalten] In der ersten Phase des Systementwicklungsprozesses, der Analysephase, werden die Anforderungen, die das neue System zu erfüllen hat, herausgearbeitet. Innerhalb dieser Phase wird somit festgelegt, welche Funktionen das zukünftige Programm erfüllen muss. Diese funktionalen Anforderungen werden in einem so genannten „Anforderungsmodell“ festgehalten. Dieses Modell zeigt die Systemgrenzen auf und betrachtet detailliert die einzelnen Systemnutzer und deren Eigenschaften. Durch die identifizierten Akteure, deren Beziehungen zueinander und den zu erfüllenden Systemaufgaben entsteht in grafischer Form das „Use Case Model“ [12]. Dieses bildet die Grundlage für die weitere Entwicklung des Systems. Eine Darstellung eines Modells in UML erfolgt in Kapitel 3.4.
Leider ist nicht für jeden Auftraggeber ein solch abstraktes Modell von den auszuführenden Tätigkeiten des Systems verständlich. Somit werden die funktionalen Anforderungen an das System mit zunehmender Beliebtheit in ausführlicher Textform verfasst. Da die Auftraggeber bei der Festlegung der Anforderungen an das System beteiligt sind, werden die Funktionen des Systems in einer semi-formalen Sprache erfasst, die für einen nicht-fachmännischen Kunden verständlich ist und für den Entwickler klare Systemgrenzen und Funktionen aufzeigt.
Anhand von Use Cases sollen funktionale Anforderungen eines Systems dargestellt werden. Somit sollte sich der Verfasser darüber im Klaren sein, welche Funktion ein bestimmter Use Case erfüllen soll, bevor dieser geschrieben wird. Demzufolge steht bei jedem Use Case eine Zielerreichung im Mittelpunkt [6], die sich auch in dem Namen der entsprechenden Funktion widerspiegeln sollte [5]. Für eine Software, die in einer Videothek zur Verwaltung von Kunden eingesetzt werden soll, könnte ein Use Case beispielsweise den Namen „Kunden anlegen“ tragen. Werden nun alle Ziele, die das System erfüllen soll, festgelegt, so erhält man die funktionalen Anforderungen für die komplette Software. Innerhalb des Use Case „Kunden anlegen“ wird eine Interaktion zwischen den Akteuren, den Teilnehmern an dem Use Case und dem System beschrieben. Alle Ausnahmesituationen, die innerhalb eines solchen Vorgangs entstehen können, werden ebenfalls in demselben Use Case niedergeschrieben. Somit haben Use Cases die Aufgabe, in transparenter und verständlicher Art und Weise den Umfang des Systems und deren Funktionalitäten darzustellen.
Das Modellieren mit Use Cases gibt vorerst keine Auskunft über die nicht-funktionalen Anforderungen eines Systems. Somit gehen Datenformate, Systemarchitekturen und Hardwareanforderungen nur im entfernten Sinne aus Use Cases hervor, stehen aber letztlich im Mittelpunkt dieser Überlegungen, und bilden über die Darstellung der funktionalen Anforderungen hinaus, die Basis für weitere Anforderungen innerhalb der Systementwicklung. Abbildung 3-2 soll den Zusammenhang von Use Cases mit den weiteren Systemanforderungen verdeutlichen. Die Abbildung zeigt die Use Cases im Mittelpunkt des Rades. Somit stellen sie die Nabe dar, um die sich alle Systemanforderungen drehen. Die nicht funktionalen Anforderungen wie Datenformate, Leistungsfähigkeit des Systems oder Aussehen der Benutzeroberfläche schaaren sich um die Nabe und stellen die Speichen des Rades dar, die ihren Ursprung in der Nabe haben. Damit sich das Rad weiter drehen kann und keine Stabilitätsverluste einbüßt, müssen sowohl Nabe als auch die Speichen vorhanden sein. Über diesen Sachverhalt kann eine Verbindung zu dem Systementwicklungsprozess gezogen werden: Fehlen die Use Cases, so können nicht funktionale Anforderungen nur schwer identifiziert werden.
[...]
