- Eine Einführung - (nach The Rational Unified Process - An Introduction von Philippe Kruchten)

Transkript

1 - Eine Einführung - (nach The Rational Unified Process - An Introduction von Philippe Kruchten) Ausarbeitung zum Vortrag vom im Rahmen des Seminars The Rational Unified Process an der Technischen Universität Berlin Datum: 10. Dezember 1999 von Torrens Langer und Axel Nitert

2 The Rational Unified Process Inhaltsverzeichnis 1 EINLEITUNG PROBLEME DER SOFTWAREENTWICKLUNG SOFTWARE BEST PRACTICES AUFGABEN EINES SOFTWAREENTWICKLUNGS-PROZESSES BESCHREIBUNG DES RATIONAL UNIFIED PROCESS DIE PROZEß-STRUKTUR (1. UND 2. DIMENSION) DIE DYNAMISCHE STRUKTUR - ITERATIVE ENTWICKLUNG DIE STATISCHE STRUKTUR - PROZEßBESCHREIBUNG EIN ARCHITEKTUR-ZENTRIERTER PROZEß Definition der Architektur Darstellung einer Architektur Die 4+1 Sicht auf eine Architektur des Rational Unified Process Modelle und Sichten Ein architekturzentrierter Prozeß Zweck einer Architektur EIN USE-CASE GESTEUERTER PROZEß Definitionen Beispiel für einen Use Case Ereignisflüsse eines Use Case Das Use-Case-Modell Use Cases im Entwicklungsprozeß BESCHREIBUNG DER WICHTIGSTEN WORKFLOWS DER REQUIREMENTS-WORKFLOW Zweck des Workflows Worker und Artefakte Workflow und Werkzeugunterstützung DER ANALYSE UND DESIGN-WORKFLOW Zweck des Workflows Worker und Artefakte Workflow und Werkzeugunterstützung DER IMPLEMENTATION-WORKFLOW Zweck des Workflows Worker und Artefakte Workflow TEST-WORKFLOW Zweck des Workflows Das Testmodell Worker und Artefakte Der Workflow ANHANG LITERATURVERZEICHNIS ABBILDUNSVERZEICHNIS TABELLENVERZEICHNIS... 29

3 The Rational Unified Process - Einleitung 1 Einleitung 1.1 Probleme der Softwareentwicklung Die Entwicklung von Software gewinnt immer mehr an Bedeutung. Es entstehen immer mehr und immer größere Systeme, die aufgrund ihrer Komplexität nur noch schwer verständlich sind. Es wird immer schwerer Software in einer wiederholbaren und vorhersagbaren Art und Weise herzustellen. In der Praxis sind folgende Symptome beim Scheitern von Softwareprojekten zu beobachten: unzureichendes Verständnis der Bedürfnisse der Endanwender Unfähigkeit mit wechselnden Anforderungen umzugehen Module passen nicht zusammen Software, die sich schwer warten und erweitern läßt späte Entdeckung ernstzunehmender Projektfehler schlechte Software-Qualität inakzeptable Software-Performance Durch individuelle Arbeitsweisen der Team-Mitglieder wird es erschwert zu rekonstruieren was, wann, wo und warum etwas geändert wurde. Der build-and-release Prozeß ist nicht vertrauenswürdig. Um den Prozeß zu verbessern, ist es allerdings nicht erfolgversprechend, die Symptome zu bekämpfen. Vielmehr müssen die einzelnen Ursachen ermittelt und gleich zu Beginn des Projekts berücksichtigt werden. Als Hauptursachen für das Scheitern von Softwareprojekten lassen sich die folgenden Punkte feststellen: ad hoc Anforderungsverwaltung mehrdeutige und unpräzise Kommunikation zerbrechliche Architekturen überwältigende Komplexität unentdeckte Inkonsistenzen bei Anforderungen, im Design und bei der Implementierung subjektive Einschätzung des Projektstatus Versagen bei der Bekämpfung von Risiken unkontrollierte Verbreitung von Änderungen unzureichende Automatisierung Obwohl verschiedene Projekte in unterschiedlicher Art und Weise fehlschlagen, läßt sich das Scheitern in der Regel auf eine Kombination dieser Hauptursachen zurückführen. 09. Dez Seite 1

4 The Rational Unified Process - Einleitung 1.2 Software Best Practices Die Bekämpfung der Hauptursachen dient nicht nur dazu, das Scheitern eines Projekts zu verhindern, sondern auch dazu, dem Ziel qualitative Software in wiederholbarer und vorhersagbarer Art und Weise herzustellen. Aus diesem Ziel und den zuvor beschriebenen Hauptursachen für das Scheitern von Softwareprojekten lassen sich Software Best Practices (Beste Software-Praktiken) ableiten. Dabei handelt es sich um eine kommerziell bewährte wissenschaftliche Annäherung an die Softwareentwicklung. Der Name beste Software-Praktiken stammt daher, daß diese sechs Praktiken im allgemeinen bei erfolgreichen Unternehmen beobachtet wurden. Die sechs Software Best Practices sind im einzelnen: Software iterativ entwickeln: Die klassische Vorgehensweise bei der Softwareentwicklung ist das Wasserfallmodell, bei dem die einzelnen Aktivitäten des Softwareentwicklungs-Prozesses sequentiell durchlaufen werden. Allerdings wird bei diesem Modell die Entdeckung der Risiken soweit nach vorn verlagert, daß eine Korrektur von Fehlern, falls es noch nicht zu spät ist, sehr kostspielig wird. Eine alternative Betrachtungsweise ist das Spiralmodell von Barry Boehm, bei dem die frühe Identifizierung der Risiken erzwungen wird, so daß eine Reaktion in einem vertretbaren Zeit- und Kostenrahmen möglich ist. Die einzelnen Aktivitäten (Anforderungen, Analyse und Design, Implementierung, Verteilung, Test und Auswertung) werden iterativ (wiederholend) ausgeführt, wobei das Produkt kontinuierlich wächst. Die iterative Entwicklung erzwingt die Fertigstellung bestimmter Teilprodukte und ermöglicht so eine wiederholbaren und vorhersagbaren Prozeß. Anforderungen verwalten: Die größte Herausforderung bei der Verwaltung von Anforderungen ist, daß sie dynamisch sind. Es muß erwartet werden, daß sich Anforderungen verändern. Besonders in großen Projekten ist es unmöglich, sämtliche Anforderungen festzulegen bevor mit der Entwicklung begonnen wird. Die aktive Verwaltung der Anforderungen besteht aus drei Aktivitäten: 1. Sammlung, Organisation und Dokumentation der Funktionen und Randbedingungen des Systems, 2. Veränderungen verwalten und ihre Auswirkungen feststellen und 3. Verfolgen und Dokumentieren von Aushandlungen und Entscheidungen. Komponentenbasierte Architekturen verwenden: Ein Software intensives System macht es erforderlich, verschiedene Sichtweisen (viewpoints) auf das System zu berücksichtigen. Die Architektur des Systems ist eine der geeignetsten Stellen, um die verschiedenen Sichtweisen umzusetzen. Durch elastische Architekturen entsteht die Möglichkeit, ein wirtschaftliches Maß an Wiederverwendbarkeit aufzubauen, eine klare Arbeitsaufteilung zwischen den Entwicklungsteams zu erhalten, Hard- und Software Abhängigkeiten zu isolieren, die Veränderungen unterliegen und die Pflege zu verbessern. Komponentenbasierte Entwicklung (component-based development, CBD) ist eine wichtige Herangehensweise an Softwarearchitektur, da sie die Wiederverwendbarkeit und Anpassung existierender Komponenten aus Tausenden kommerziellen Quellen ermöglicht (z.b. COM, OMG, CORBA, EJB). 09. Dez Seite 2

5 The Rational Unified Process - Einleitung Software visuell modellieren: Modellieren hilft dem Entwicklungsteam bei der Visualisierung, Spezifizierung, Konstruktion und Dokumentation der Struktur und des Verhaltens einer Systemarchitektur und ist daher notwendig bei der Softwareentwicklung. Die Verwendung eine standardisierten Modellierungssprache wie die UML (unified modeling language) bietet einen Weg Entscheidungen untereinander in eindeutiger Art und Weise zu kommunizieren. Visuelle Modellierungswerkzeuge erleichtern die Verwaltung dieser Modelle und helfen bei der Sicherstellung der Übereinstimmung der verschiedenen Teilprodukte. Qualität der Software verifizieren: Die Korrektur von Software-Problemen ist sehr viel aufwendiger nach der Entwicklung. Aus diesem Grund ist es wichtig, fortlaufend die Qualität eines Systems einzuschätzen im Hinblick auf seine Funktionalität, Zuverlässigkeit, Anwendungsleistung und Systemleistung. Die Überprüfung der Funktionalität des Systems beinhaltet die Erstellung von Tests für jedes Schlüsselszenario. Da die Software iterativ entwickelt wird und in jeder Iteration getestet wird, entsteht ein Prozeß der fortlaufenden Einschätzung der Qualität. Veränderungen an der Software kontrollieren: Um die Tätigkeiten und Teilprodukte der verschiedenen Entwickler zu koordinieren, müssen wiederholbare Arbeitsabläufe (workflows) für die Verwaltung der Änderungen an der Software und anderen Teilprodukten etabliert werden. 1.3 Aufgaben eines Softwareentwicklungs-Prozesses Ein Softwareentwicklungs-Prozeß hat nach Grady Booch (nach Kruchten, 1999) vier verschiedene Rollen: 1. Eine Anleitung über die Ordnung der Team-Aktivitäten liefern. 2. Spezifizieren von Art und Zeitpunkt der Erstellung von Teilprodukten. 3. Die Aufgaben einzelner Entwickler und des gesamten Teams lenken. 4. Kriterien für die Überwachung und Messung der Projektprodukte und -aktivitäten anbieten. Um das bereits zuvor erwähnte Ziel zu erreichen, qualitativ hochwertige Software in einer vorhersagbaren und wiederholbaren Art und Weise zu entwickeln, ist es notwendig, einen wohldefinierten Softwareentwicklungs-Prozeß anzuwenden. Ein solcher wohldefinierter Prozeß ermöglicht alle der genannten Software Best Practices. Das Entwicklungsteam kann daher auf die in diesem Prozeß eingearbeiteten Erfahrungen aus verschiedenen Projekten zurückgreifen. 09. Dez Seite 3

6 The Rational Unified Process - Beschreibung des Rational Unified Process 2 Beschreibung des Rational Unified Process Der Rational Unified Process ist in erster Linie ein Software Engineering Prozeß. Darüber hinaus ist er ein Prozeßprodukt, das aus einer HTML-basierten Online- Version und einem Satz von Handbüchern besteht. Zu der Online-Version gehören Werkzeug-Ratgeber (sogenannt tool mentors) und Vorlagen (templates) für Teilprodukte (artifacts) des Prozesses für verschiedene Werkzeuge (wie z.b. Rational SoDA, RequisitePro, Word, Porject, FrontPage). Der Rational Unified Process zeichnet sich durch folgende Punkte aus: Es werden regelmäßige Upgrades veröffentlicht. Er ist online verfügbar über Web-Technologie. Er kann maßgeschneidert werden. Er ist integriert in viele SW-Entwicklungswerkzeuge des Rational Suite (Rose, RequisitePro, SoDA, ClearCase, ClearQuest, TeamQuest). Aus dem Einsatz des Rational Unified Process als Prozeßprodukt ergeben sich die folgenden Vorteile für eine Organisation: Verteilung der aktuellen Version an alle Projekt-Mitglieder via Intranet. Direkte Verfügbarkeit von Schlüsselinformationen über Index und Suchmaschine. Navigation zwischen Teilen des Prozesses (Verzweigung zu Tools). Einfache Einbindung von projektspezifischen Prozeßverbesserungen. Versionskontrolle und Verwaltung von Varianten des Prozesses in verschiedenen Projekten. Außerdem liefert der Rational Unified Process ein Prozeß-Grundgerüst (framework), das von der Organisation so angepaßt und erweitert werden kann, daß es die Bedürfnisse der Organisation erfüllt. Zusätzlich erfüllt der Prozeß die zu Beginn beschriebenen sechs Software Best Practices: 1. Software iterativ entwickeln 2. Anforderungen verwalten (Rational Requisite Pro) 3. Komponentenbasierte Architekturen verwenden (MS Visual Studio, Rational Apex) 4. Software visuell modellieren (Rational Rose) 5. Qualität der Software verifizieren (Rational TeamTest, ClearQuest) 6. Veränderungen an der Software kontrollieren (Rational ClearCase) Der Rational Unified Process hat zwei Dimensionen: 09. Dez Seite 4

7 The Rational Unified Process - Beschreibung des Rational Unified Process 2.1 Die Prozeß-Struktur (1. Und 2. Dimension) Abbildung 1. Die zwei Dimensionen der Prozeßstruktur Die horizontale Achse ist die Zeitachse, die Aspekte des Lebenszyklus repräsentiert, in dem der Prozeß verläuft. Diese Dimension beinhaltet die dynamischen Aspekte des Prozesses und wird durch die Begriffe Zyklus, Phase, Iteration und Meilenstein beschrieben. Diese sind im Kapitel Die dynamische Struktur - Iterative Entwicklung näher beschrieben. Die vertikale Achse zeigt Kernprozesse, in denen zusammengehörige Aktivitäten (logisch) gruppiert werden. Diese zweite Dimension repräsentatiert den statischen Aspekt des Prozesses, der durch die Begriffe Komponenten, Aktivitäten, Workflows, Artefakte und Worker beschrieben wird. Diese werden im Kapitel Die statische Struktur - Prozeßbeschreibung näher beschrieben. 09. Dez Seite 5

8 The Rational Unified Process - Beschreibung des Rational Unified Process 2.2 Die dynamische Struktur - Iterative Entwicklung Im Gegensatz zum klassischen Wasserfallmodell der Softwareentwicklung ist im Rational Unified Process eine iterative Vorgehensweise implementiert. Hier findet sich das Best Practice Iterative Softwareentwicklung wieder. Jede Iteration ähnelt dabei einem kleinen Wasserfall und beinhaltet die Aktivitäten der Anforderungsanalyse, des Designs, der Implementierung und des Testens. Jede Phase wird durch einen Meilenstein abgeschlossen: Abbildung 2. Die vier Phasen und Meilensteine des iterativen Prozesses Im Detail sehen die vier Phasen wie folgt aus: Konzeption (Inception): Die eigentliche Idee - also die Spezifizierung der Endproduktversion und ihrer Geschäftsvorfälle sowie die Definition des Umfangs des Projektes. Die Phase wird abgeschlossen durch den Meilenstein LCO (Life Cycle Objective => Ziel des Lebenszyklus) Entwurf (Elaboration): Die Planung der notwendigen Aktivitäten und der erforderlichen Ressourcen sowie die Spezifizierung der Eigenschaften und das Design der Architektur. Der Meilenstein LCA (Life Cycle Architekture => Architektur des Lebenszyklus) beendet die Phase. Konstruktion (Construction): Die Erstellung des Produkts und die Entwicklung der Vision, der Architektur und aller Pläne, bis die vollständige Version des Produktes fertig zur Auslieferung ist. Diese Phase wird durch den Meilenstein IOC (Initial Operational Capability => Erste Funktionsfähigkeit) abgeschlossen. Übergang (Transition): Die Übergabe des Produktes an seine Endbenutzer. Enthalten sind hier Aktivitäten wie Auslieferung, Training, Einsatzunterstützung und Wartung, bis die Anwender zufrieden sind. Der Release-Meilenstein beendet diese Phase und gleichzeitig den gesamten Zyklus 09. Dez Seite 6

9 The Rational Unified Process - Beschreibung des Rational Unified Process Von Iteration zu Iteration und von Phase zu Phase ändert sich die Bedeutung der Aktivitäten: Abbildung 3. Bedeutung von Aktivitäten über einen Entwicklungszyklus Betrachtet man die Aktivitäten in der Mitte jeder Phase, so lassen sich folgende Aussagen treffen: Der Schwerpunkt liegt in der Konzeptionsphase auf dem Verstehen der Anforderungen und der Planung des Realisierungsaufwandes. In der Entwurfsphase liegt der Schwerpunkt zwar auf den Anforderungen, in Form von Prototyping wird bereits mit dem Design und der Implementierung der Architektur begonnen, so daß ein ausführbarer Architekturprototyp entsteht. In der Konstruktionsphase liegt der Schwerpunkt auf dem Design und der Implementierung. Der bisherige Prototyp wird zu einem operationellen Produkt ausgebaut. In der Übergangsphase wird sichergestellt, daß das System die notwendige Qualität erreicht hat und mit den gesteckten Zielen übereinstimmt. Fehler werden behoben und Anwender trainiert und fehlende Elemente ergänzt. Das Produkt wird fertiggestellt und ausgeliefert. Im Vergleich zum traditionellen Wasserfallmodell besitzt der iterative Ansatz mehrere Vorteile: Risiken (z.b. Integrationsrisiko) können eher erkannt und eingedämmt werden. Änderungen (z.b. Anforderungsänderungen) können besser gemanagt werden. Es existiert ein höherer Grad der Wiederverwendung durch frühe Design Reviews. Das Projektteam kann während des Projekts (von Iteration zu Iteration) hinzulernen. Die Gesamtqualität des Produkts ist höher durch mehrmaliges Testen und Anpassen an die Benutzeranforderungen. 09. Dez Seite 7

10 The Rational Unified Process - Beschreibung des Rational Unified Process 2.3 Die statische Struktur - Prozeßbeschreibung Ein Prozeß beschreibt, wer was wann und wie tut. Der Rational Unified Process wird durch die folgenden Modellierungselemente dargestellt: Worker: wer Aktivitäten: wie Artefakte: was Workflow: wann Den Zusammehang zwischen den einzelnen Modellierungselementen verdeutlicht folgende Abbildung: Abbildung 4. Worker, Aktivitäten und Artefakte Der Begriff Worker definiert das Verhalten und die Verantwortlichkeit einer einzelnen Gruppe oder einer Personengruppe, die als Team zusammenarbeiten. Das Verhalten wird durch eine Anzahl von Aktivitäten beschrieben, die von jedem Worker ausgeführt werden. Jedem Worker wird dabei eine Anzahl von zusammenhängenden Aktivitäten zugeordnet. Die Verantwortlichkeiten des Workers werden in Zusammenhang zu den Artefakten gesetzt, die er erzeugt, ändert oder kontrolliert. Worker: Im Rational Unified Process bezieht sich Worker auf eine bestimmte Rolle, die festlegt, wie eine Person eine Rolle ausführen soll. Eine Person kann einerseits verschiedene Workerausprägungen zugeordnet bekommen. Ein Worker wiederum kann durch mehrere Personen repräsentiert werden. Ein Worker ist Eigentümer einer bestimmten Menge von Artefakten. Aktivitäten: Eine Aktivität, die ein Worker durchführen soll, ist ein bestimmter Teil einer Tätigkeit, die eine Person in dieser Rolle ausüben soll. Eine Aktivität dient für gewöhnlich der Erstellung oder Überarbeitung von Artefakten, wie z.b. einem Modell, einer Klasse oder eines Plans. Jede Aktivität wird einem bestimmten Worker zugeordnet. Artefakte: Ein Artefakt ist Teil einer Information, die von einem Prozeß erstellt, geändert oder genutzt wird. Artefakte sind immer konkrete Produkte eines Projekts. Sie werden von Workern als Input benutzt, um Aktivitäten auszuführen und sind ebenso als Output von Aktivitäten zu betrachten. 09. Dez Seite 8

11 The Rational Unified Process - Beschreibung des Rational Unified Process Artefakt ist ein Begriff, der speziell im Rational Unified Process genutzt wird. In anderen Prozessen beschreiben Begriffe wie work unit, Produkt, usw. das gleiche. Ausgeliefert wird an den Endkunden immer die Gesamtmenge aller Artefakte. Artefakte können verschiedene Ausprägungen wie Modell, Element eines Modells, Dokument, Quellcode, ausführbare Datei haben. Workflows: Ein Workflow ist eine Abfolge von Aktivitäten, die ein Ergebnis von nachweisbarem Wert erzeugen. Ein Workflow ist in der UML-Notation vergleichbar mit einem Sequence-Diagramm, einem Collaborations- Diagramm oder einem Aktivitätsdiagramm. Workflows koordinieren Aktivitäten und Worker anhand der Ergebbnisse der Produkte. Mit der beschriebenen Struktur bildet der Rational Unified Process ein Prozeß-Framework. Worker, Artefakte, Aktivitäten und ergänzende Prozeßelemente sind die Elemente, die entweder hinzugefügt oder ausgetauscht werden können, um den Prozeß in einem Unternehmen einzuführen oder ihn dort anzupassen. 2.4 Ein Architektur-zentrierter Prozeß Definition der Architektur Ein bekanntes Zitat lautet: Architektur ist das, was übrigbleibt, wenn man nichts mehr wegnehmen kann und trotzdem das System noch versteht und auch noch versteht, wie es arbeitet. Der Rational Unified Process definiert Architektur wie folgt: Architektur umfaßt signifikante Entscheidungen über die Organisation eines Software-Systems. die Auswahl der Strukturelemente und deren Schnittstellen, durch die das System zusammengesetzt wird, zusammen mit dem Verhalten, das bezüglich des Zusammenspiels obiger Elemente definiert wurde. die Zusammensetzung dieser Elemente zu zunehmend größeren Subsystemen. den Architekturstil, der Softwareentwicklungsabteilungen hinsichtlich dieser Elemente und Schnittstellen, deren Zusammenspiel und Zusammensetzung weiterhilft. In der Definition der Architektur des Rational Unified Process findet sich das Best Practice Verwendung komponentenbasierter Architekturen der Softwareentwicklung wieder. Eine Architektur hat aber nicht nur etwas mit Struktur und Verhalten zu tun, sondern auch mit Handhabung, Funktionalität, Performance, Wiederverwendbarkeit, technologischen Aspekten, Ästhetik und vielem mehr. 09. Dez Seite 9

12 The Rational Unified Process - Beschreibung des Rational Unified Process Darstellung einer Architektur An der Softwarearchitektur sind verschiedene Seiten interessiert, wobei jede Seite eine andere Sicht auf die Architektur hat: Der Systemanalytiker nutzt die Architektur, um die Anforderungen zu organisieren und zu besprechen. Außerdem braucht er sie, um technologische Zusammenhänge und Risiken zu verstehen. Der Endanwender oder Kunde braucht die Architektur, um frühzeitig zu erkennen, was er erhalten wird. Der Projektleiter organisiert mit Hilfe der Architektur sein Team und plant die Entwicklung. Bei offenen Systemen brauchen andere Entwicklungsabteilungen die Architektur, um zu erkennen, an welchen Schnittstellen sie ansetzen müssen. Wenn es Unterauftragnehmer gibt, brauchen diese die Architektur, um ihren Aufgabenbereich abgrenzen zu können. Architekten können anhand der Architektur Aussagen über die Weiterentwicklung und Wiederverwendung treffen. Damit diese verschiedenen Stakeholder miteinander kommunizieren und diskutieren können, wird eine Darstellung der Architektur benötigt, die jeder versteht. Sobald eine Darstellung gewählt wird, werden einige nicht direkt greifbare Faktoren vernachlässigt Die 4+1 Sicht auf eine Architektur des Rational Unified Process Für ein Softwaresystem existieren unterschiedliche Sichtweisen für unterschiedliche Zwecke. Der Rational Unified Process verfolgt einen Fünf-Sichten-Ansatz: Abbildung 5. Die 4+1-Sicht auf eine Architektur Die logische Sicht: Diese Sicht beinhaltet die funktionalen Anforderungen an das System. Hier wird beschrieben, was das System leisten soll bzw. was die Endanwender vom System erwarten. Die logische Sicht ist eine Abstraktion des Designmodells und identifiziert die wesentlichen Designpakete, Subsysteme und Klassen. Ein Beispiel wäre ein Flug, ein Flugplan, ein Luftweg, ein Flughafen und ein Luftfrachtpaket. 09. Dez Seite 10

13 The Rational Unified Process - Beschreibung des Rational Unified Process Die Implementierungssicht: Diese Sicht beschreibt die statische Struktur eines Softwaremoduls (Quellcode, Dateien, Komponenten, ausführbare Dateien) innerhalb der Entwicklungsumgebung in Form von Paketen und Schichten und aus der Sicht des Konfigurationsmanagements (Besitz, Release- Strategie). Sie behandelt Aspekte wie Vereinfachung der Softwareentwicklung, Wiederverwendbarkeit, Unteraufträge und externe Komponenten. Beispiele wären der Quellcode für eine Flugklasse und die Library für den Code einer Flugdatenbank. Die Prozeßsicht: Diese Sicht beinhaltet die parallelen Aspekte eines Systems zur Laufzeit - Aufgaben, Threads und Prozesse sowie deren Zusammenspiel. Man beschäftigt sich hier mit Nebenläufigkeit, Parallelität, Systemstart, Systemende, Fehlertoleranz und der Verteilung von Objekten. Die wesentlichen Elemente dieser Sicht sind Dinge wie Deadlocks, Antwortzeitverhalten, Durchsatz und Isolierung von Funktionen sowie Skalierbarkeit. Beispiele wären der Prozeß zum Management des Fluges, der Prozeß zum Aufruf des Flugplanes und der Prozeß zum Management des Luftraumes. Die Verteilungssicht: Diese Sicht zeigt, wie die unterschiedlichen ausführbaren Dateien oder Laufzeitkomponenten auf die Plattformen im Netz verteilt werden. Hier treffen Softwareengineering und Systemengineering aufeinander. Behandelt werden Aspekte wie Verteilung, Installation und Performance. Ein Beispiel wäre, daß der Prozeß zum Management des Fluges auf dem Flugprozessor läuft, während der Prozeß zum Aufruf des Flugplanes auf einer Workstation läuft. Die Use-Case-Sicht: Diese Sicht spielt hinsichtlich der Architektur eine besondere Rolle. Sie enthält einige wenige Schlüsselszenarios oder Use Cases. Anfangs werden diese in der Konzeptions- und Entwurfsphase genutzt, um die Architektur zu planen und zu entwerfen. Später kommen sie ebenfalls bei der Validierung der unterschiedlichen Sichten zum Einsatz. Diese Szenarios können als Illustration der Softwarearchitektur angesehen werden, die beschreibt, wie die anderen Sichten funktionieren. Beispiele wären die Anmeldung eines Flugplanes oder die Übergabe der Verantwortung an einen anderen Lotsen Modelle und Sichten Die Architektursichten sind wie Querschnitte von Modellen, die nur die wichtigen und signifikanten Elemente dieser Modelle enthalten. Folgende Elemente sind signifikant für eine Architektur: Wesentliche Klassen, insbesondere Klassen, die die wichtigsten Entitäten repräsentieren. Mechanismen der Architektur, die das Verhalten dieser Klassen definieren, z.b. Persistenz oder Kommunikation Patterns und Frameworks Schichten und Subsysteme Schnittstellen 09. Dez Seite 11

14 The Rational Unified Process - Beschreibung des Rational Unified Process Wesentliche Prozesse oder Kontrollmechanismen Die Sichten, die für das System von Bedeutung sind, werden in dem Artefakt Software-Architektur-Beschreibung zusammengefaßt. Zwischen Modellen und Sichten existieren folgende Beziehungen: Modell Designmodell Designmodell Implementierungsmodell Verteilungsmodell Use-Case-Modell Architektursicht Logische Sicht Prozeßsicht Implementierungssicht Verteilungssicht Use-Case-Sicht Ein architekturzentrierter Prozeß Nachdem ein Unternehmen überzeugt ist, daß mit der Darstellung der Architektur die wesentlichen Aufgabenstellungen abgedeckt sind, beginnt im nächsten Schritt der Designprozeß für die Architektur. Der Rational Unified Process definiert zwei wesentliche Artefakte, die in Zusammenhang mit der Architektur zu sehen sind: 1. Die Software-Architektur-Beschreibung, die die für das Projekt relevanten Architektursichten beschreibt. 2. Den Architekturprototyp, der einerseits zur Validierung und andererseits als Baseline für den restlichen Entwicklungsprozeß dient. Diese beiden Schlüsselartefakte bilden die Grundlage für andere Artefakte wie die Design-Richtlinien, die Produktstruktur und die Teamstruktur. Der Rational Unified Process definiert den Worker Architekt als Verantwortlichen für die Architektur. Trotzdem sind auch andere Mitglieder des Projetteams in die Definition und Implementierung der Architektur involviert, besonders in der Entwurfsphase. So konzentrieren sich die Designer z.b. auf die für die Architektur relevanten Klassen. Integratoren kümmern sich um die Integration der wesentlichen Softwarekomponenten, um anschließend die Schnittstellen testen zu können. Tester untersuchen den Architekturprototyp hinsichtlich Performance und Robustheit. All diese Aktivitäten sollen sicherstellen, daß keine neue Designentscheidung getroffen wird (werden muß), die die Architektur schwächen oder vernichten würde Zweck einer Architektur Architekturen sind auch von Bedeutung für die intellektuelle Kontrolle, die Wiederverwendung und als Entwicklungsbasis. Mit Hilfe einer Architektur wird die intellektuelle Kontrolle innerhalb eines Projektes sowohl gewonnen als auch beibehalten. Darunter versteht man das Management der Komplexität und die Wartung der Integrität des Systems. Architekturen liefern eine gute Basis für die Wiederverwendbarkeit durch die genaue Beschreibung der Komponenten und der kritischen Schnittstellen zwischen diesen Komponenten. Architekturen und die in der Entwurfsphase geleistete Arbeit stellen eine Basis für eine weitere Entwicklung dar, einschließlich der Designrichtlinien, Prinzipien, Vorgehensweisen, Patterns und Mechanismen der Wiederverwendung. 09. Dez Seite 12

15 The Rational Unified Process - Beschreibung des Rational Unified Process 2.5 Ein Use-case gesteuerter Prozeß Im Rational Unified Process sind Use Cases implementiert, um das Verhalten des Systems zum Ausdruck zu bringen. Mit ihrer Hilfe soll ein sichtbarer roter Faden durch das gesamte System geschaffen werden. Dadurch sollen die Analyse des objektorientierten Modells und das Feststellen, wie das System das tut, was es tun soll, ermöglicht und erleichert werden. Use Cases bieten gerade in der Problemmodellierung eine Art und Weise der Prozeßmodellierung an, die von einer Vielzahl am Prozeß beteiligter Stakeholder (Endanwender, Entwickler, Architekten) verstanden wird. Use Cases stellen eine wichtige Verbindung zwischen den Systemanforderungen und anderen Artefakten der Softwareentwicklung wie Design und Test dar. Andere objektorientierte Methoden bieten ähnliche Elemente unter anderen Namen, wie zum Beispiel Szenarien, an. Da der Rational Unified Process durch den Use-Case-gesteuerten Ansatz geprägt wird, bilden die für das System definierten Use Cases die Grundlage für den gesamten Softwareentwicklungsprozeß. Sie spielen eine wesentliche Rolle in den verschiedenen Workflows des Prozesses, besonders beim Anforderungs-, Design-, Test- und Managementworkflow. Außerdem sind sie der Schlüssel für die Geschäftsprozeßmodellierung Definitionen Im Rational Unified Process sind zwei Schlüsselkonzepte definiert: Use cases und Akteure. Ein Use Case ist eine Sequenz von Aktionen, die für einen bestimmten Akteur ein verwertbares Ergebnis liefern. Ein Akteur ist eine Person oder Sache außerhalb des Systems, die mit dem System interagiert Beispiel für einen Use Case Ein Bankkunde (Akteur) kann ein Kundenterminal einer Bank dazu benutzen, Geld abzuheben, Überweisungen zu tätigen oder seinen Kontostand abzufragen. Diese Möglichkeiten lassen sich durch eine Reihe von Use cases darstellen: Abbildung 6. Use Cases für ein Bank-Kunden-Terminal Hinter jedem Use Case steht eine Funktionalität des Systems, die dem Bankkunden einen Nutzen bringt. Die Summe der Use Cases stellt dar, wie man das gesamte 09. Dez Seite 13

16 The Rational Unified Process - Beschreibung des Rational Unified Process System nutzen kann. Bereits durch Betrachten des Use-Case-Namens sollte man ableiten können, was der Use Case macht Ereignisflüsse eines Use Case Der wichtigste Bestandteil eines Use Case während des Anforderungs-Workflow (Requirements-Workflow) sind die Ereignisflüsse, die die Abfolge der Aktionen beschreiben. Die Beschreibung erfolgt in normaler Sprache in einem einfachen aber konsistenten Stil unter Nutzung von Begriffen, die aus einem Glossar des Problembereiches kommen. Zur Verdeutlichung soll der Use Case Kontostand prüfen aus dem obigen Beispiel beschrieben werden: 1. Der Use Case wird dadurch gestartet, daß der Kunde seine Scheckkarte in das Kundenterminal schiebt. Das System liest und prüft die Daten auf dem Magnetstreifen. 2. Das System fragt nach der PIN. Der Kunde gibt seine PIN ein und das System prüft sie über das Banknetzwerk. 3. Das System fragt nach der durchzuführenden Aktivität, und der Kunde gibt Kontostand prüfen ein. 4. Das System zeigt den Kontostand an. 5. Das System fragt den Kunden, ob er einen ausgedruckten Kontoauszug möchte. Diese Funktion wird aber nur dann ausgeführt, wenn noch Papier im Terminal ist. 6. Das System bittet den Kunden, die Scheckkarte zu entnehmen und der Kunde entnimmt die Karte. 7. Das System druckt den Kontoauszug, wenn der Kunde das gewünscht hat. 8. Der Use Case ist beendet. Bei kompletter Betrachtung der Aktionen stellt man fest, daß es verschiedene Pfade innerhalb der Ereignisflüsse des Use Case gibt. Es existieren alternative Wege und unterschiedliche Szenarien. Desweiteren können unterschiedliche Werte und Effekte hervorgerufen werden. Der letztendlich beschrittene Pfad ist abhängig von verschiedenen Faktoren: Eingaben des Akteurs: Der Akteur kann auswählen, was er als nächstes machen möchte. Im o.g. Beispiel könnte der Bankkunde zu jeder Zeit den Vorgang abbrechen oder entscheiden, daß er keinen ausgedruckten Kontoauszug benötigt. Interner Systemstatus: Zum Beispiel kann es passieren, daß im Kundenterminal kein Papier für das Ausdrucken von Kontoauszügen mehr vorhanden ist. Time-outs und Fehler: Wenn der Kunde innerhalb einer gewissen Zeit keine Eingabe tätigt, wird das Terminal den Vorgang von sich aus abbrechen. Wenn der Kunde mehrmals eine falsche PIN eingibt, wird der Vorgang ebenfalls abgebrochen und die Karte einbehalten. Es soll aber nicht jeder mögliche Alternativfluß in einem seperaten Use Case dargestellt werden. Vielmehr werden diese mit verwandten Ereignisflüssen von Use Cases gruppiert und zu einer Use-Case-Klasse zusammengefaßt. Jede Instanz 09. Dez Seite 14

17 The Rational Unified Process - Beschreibung des Rational Unified Process einer Use-Case-Klasse ist dann ein Ereignisfluß bzw. ein Pfad durch einen Use Case und wird auch als Szenario bezeichnet. Szenarien werden im Prozeß benutzt, um eine bestimmte Abfolge von Aktionen zu betonen. Wenn zu Beginn eines Projektes nach Use Cases gesucht wird, ist es oft einfacher, mit Szenarien zu beginnen. Die werden dann um zusätzliche Ereignisflüsse angereichert und zu echten Use Cases verallgemeinert Das Use-Case-Modell Das Use-Case-Modell ist ein Modell der vorgesehenen Funktionen des Systems und deren Umgebung. Es dient als eine Art Vertrag zwischen Kunden und Entwicklern. Das Use-Case-Modell erfaßt die gesamte Funktionalität des Systems, denn es enthält alle Use Cases für das System, zusammen mit der Menge aller Akteure. Das vorgestellte Modell des Kundenterminals wäre durch das Hinzufügen von Use Cases für das Bankpersonal und das Installationspersonal zu vervollständigen. Nichtfunktionale Beschreibungen komplettieren das Modell. Dazu zählen zum einen Aspekte, die sich nicht so einfach durch einen Use Case ausdrücken lassen und zum anderen Aspekte, die für mehrere oder alle Use Cases zutreffen. Dies können Anforderungen bezüglich Performance, Sicherheitsaspekte und Zusammenhänge in der Entwicklung sein Use Cases im Entwicklungsprozeß Da der Rational Unified Process ein Use-Case-gesteuerter Ansatz ist, sind die für ein System definierten Use Cases die Grundlage für den gesamten Entwicklungsprozeß: Abbildung 7. Use Cases fließen durch diverse Modelle Das Use-Case-Modell ist ein Ergebnis des Anforderungs-Workflow. Die Use Cases dienen zum Erfassen dessen, was das System aus Sicht der Endanwender leisten soll und sind somit das Kommunikationsmittel zwischen Kunden (=Endanwender) und Entwicklern. In der Analyse und im Design sind die Use Cases die Verbindung zu den Anforderungen und Designaktivitäten. Sie sind die Basis für Use-Case- Realisierungen, die beschreiben, wie ein Use Case von interagierenden Objekten ausgeführt wird. Durch das nähere Betrachten der Use Cases werden die Objekte und Klassen einfach gefunden. Diese Technik stellt sicher, daß das geforderte Verhalten des Systems im Systemdesign berücksichtigt wird. 09. Dez Seite 15

18 The Rational Unified Process - Beschreibung des Rational Unified Process Während der Implementierung stellt das Designmodell die Spezifikation für die Implementierung dar. Da Use Cases die Basis für das Designmodell sind, werden sie in Form von Designklassen implementiert. Use-Case-Realisierungen im Designmodell werden benutzt, um die Dynamik des Systems zu verstehen und die Performance zu optimieren. Während des Testens dienen die Use Cases der Identifizierung von Testfällen und Testprozeduren, d.h. jeder Use Case dient zur Verifizierung des Systems. Auch andere Aktivitäten werden in Use Cases ausgedrückt. So drücken Use Cases z.b. aus, wie ein Akteur mit dem System zusammenwirkt. In ihnen sind also viele Informationen enthalten, die für das Benutzerhandbuch verwendet werden können. 09. Dez Seite 16

19 The Rational Unified Process - Beschreibung der wichtigsten Workflows 3 Beschreibung der wichtigsten Workflows Nachfolgend werden die einzelnen Workflows des Rational Unified Proces einführend beschrieben. Die einzelnen Abschnitte sind gegliedert in Zweck des Workflows, Worker und Artefakte, Workflow und Werkzeugunterstützung. 3.1 Der Requirements-Workflow Zweck des Workflows Innerhalb des Requirements-Workflows sollen die folgenden Ziele erreicht werden: Übereinstimmung mit dem Kunden und Benutzer darüber, was das System leisten soll Systementwickler erhalten ein besseres Verständnis über die Anforderungen des Systems Funktionalität des Systems definieren Grundlage für die Planung der technischen Inhalte der Iterationen Grundlage für Kosten- und Zeitabschätzung Benutzerschnittstelle definieren Der Requirements Workflow beschreibt wie eine Vision des Systems definiert und in ein Use-Case-Modell umgewandelt wird. Aus den einzelnen Bedürfnissen der Stakeholder (alle Personen, die in Interesse an dem System haben) wird das Visionsdokument (vision document) entwickelt, das allgemein die Fähigkeiten des Systems beschreibt. Das Visionsdokument muß anschließend in eine detaillierte Anforderungsspezifikation überführt werden. Dazu werden Use-Case-Modelle und ergänzende Spezifikationen (supplemenary specifications) erstellt. Zusätzlich wird die Benutzerschnittstelle entworfen, wodurch Anforderungen an die Bedienbarkeit des Systems abgebildet werden können Worker und Artefakte Wie bereits zuvor beschrieben wurde, werden im Rational Unified Process die Begriffe Worker, Artefakte, Aktivitäten und Workflows verwendet. Die nachfolgende Abbildung stellt die Worker und Artefakte des Requirements Workflows dar. Die Haupt-Worker bei diesem Workflow sind: System Analyst: Der System Analyst leitet und koordiniert die Sammlung der Anforderungen (requirements elicitation) und die Use-Case-Modellierung, indem er die Systemfunktionalitäten umreißt und das System eingrenzt. Use-Case Specifier: Der Use-Case Specifier verfeinert alle oder Teile der Systemfunktionalitäten, indem er die Anforderungen eines oder mehrerer Anwendungsfälle beschreibt. Architect: Der Architect ist verantwortlich für die Identifizierung der architekturrelevanten Anwendungsfälle und Anforderungen. User-Interface Designer: Der User-Interface Designer leitet und koordiniert den Entwurf und die Entwicklung der Prototypen für die Benutzerschnittstelle. 09. Dez Seite 17

20 The Rational Unified Process - Beschreibung der wichtigsten Workflows Requirements Reviewer: Der Requirements Reviewer überprüft die erzeugten Artefakte. Abbildung 8. Worker und Artefakte des Requirements-Workflows Die folgende Tabelle zeigt die wichtigsten erzeugten Artefakte: Tabelle 1. Schlüsselartefakte des Requirements-Workflows Artefakt Stakeholder Needs Vision Document Use-Case Model Supplementare Specifications Requirements Attributes User-Interface Prototype Beschreibung Bedürfnisse der Stakeholder (allgemein) Visionsdokument (allgemein) Anwendungsfall-Modell aus der UML (detailliert) Anforderungsbeschreibungen, die nicht mittels Use- Case-Modell abgebildet werden können (detailliert) Charakteristiken der verschiedenen Arten von Anforderungen und Abhängigkeiten (detailliert) Prototyp der Benutzerschnittstelle 09. Dez Seite 18

21 The Rational Unified Process - Beschreibung der wichtigsten Workflows Workflow und Werkzeugunterstützung Die einzelnen Workflows des Rational Unified Process lassen sich am besten mit der nachfolgenden Abbildung darstellen, die aus der Online-Version des Rational Unified Process stammt. Für detaillierte Beschreibungen kann in der Online-Version auf die einzelnen Elemente (z.b. Worker, Artefakte) mit der Maus geklickt werden. Abbildung 9. Requirements-Workflow Zusammen mit der ausführliche Gliederung auf der linken Seite der Abbildung bilden der Index und die Suchmaschine ein umfangreiches Werkzeug zum Auffinden der gewünschten Informationen. Auf der linken und rechten Seite des Workflows sind die bereits beschriebenen Worker des Workflows beschrieben. Zu jedem Worker gibt es eine gewisse Anzahl an Aktivitäten, die er in diesem Workflow auszuführen hat. Die Reihenfolge und damit auch Abhängigkeit zwischen den Aktivitäten wird durch Pfeile gekennzeichnet. Der System Analyst beginnt mit der Entwicklung einer Vision und sammelt anschließend die Stakeholder Bedürfnisse. Er findet die verschiedenen Akteure und Anwendungsfälle, die die Grundlage für den Use-Case Specifier und den Architect bilden. Der Use-Case Specifier verfeinert die Anforderungen und liefert so die Grundlage für den User-Interface Designer, der anschließend einen Prototypen entwickelt. Alle von den einzelnen Workern gelieferten Anforderungsbeschreibungen werden von dem Requirements Reviewer geprüft. Die einzelnen Worker sind nicht als Personen sondern als Rollen zu verstehen, d.h. es kann z.b. mehrere System Analysts geben. Unterstützt wird die Beschreibung der Anforderungen von dem Werkzeug Rational RequisitePro. Für die Visualisierung der Use-Cases gibt es das Werkzeug Rational Rose. Rational SoDa hilft bei der Zusammenstellung der Dokumentation aus unterschiedlichen Quellen. 09. Dez Seite 19

22 The Rational Unified Process - Beschreibung der wichtigsten Workflows 3.2 Der Analyse und Design-Workflow Zweck des Workflows Der Zweck des Analyse und Design-Workflows liegt darin, die gesammelten Anforderungen in eine Spezifikation zu übertragen, die zeigt, wie das System implementiert werden soll. Die einzelnen Anforderungen müssen mittels der Analyse in eine Form gebracht werden, die ein Softwareentwickler versteht (Klassen und Teilsysteme). Dabei werden die nichtfunktionalen Anforderungen und Randbedingungen außer acht gelassen und es entsteht ein beinahe ideales Bild des Systems. Ziel des Designs ist es nun das Ergebnis der Analyse mit den nichtfunktionalen Anforderungen und Randbedingungen wieder in Einklang zu bringen. Dabei geht es darum den Entwurf des Systems zu optimieren und die Einhaltung aller Anforderungen sicherzustellen Worker und Artefakte Die Worker und Artefakte des Analyse und Design-Workflows werden anhand der Abbildung aus der Online-Version des Rational Unified Process beschrieben. Abbildung 10. Worker und Artefakte des Analyse & Design-Workflows Die Hauptbeteiligten am Analyse und Design-Workflow sind: Architect: Der Architect leitet und koordiniert die technischen Aktivitäten und Artefakte während des Projekts. Im Gegensatz zu den Sichten der anderen Worker hat der Architect eher einen Überblick über das Gesamtsystem anstelle der detaillierten Sicht. Designer: Der Designer definiert die Verantwortlichkeiten, Operationen, Attribute und Beziehungen zwischen verschiedenen Klassen. Er bestimmt wie die Klassen auf die Implementierungsumgebung abgestimmt werden. 09. Dez Seite 20

23 The Rational Unified Process - Beschreibung der wichtigsten Workflows Database Designer: Der Database Designer wird benötigt, wenn das System die Verwendung einer Datenbank mit einschließt. Architecture Reviewer and Design Reviewer: Diese beiden Reviewer sind in diesem Workflow (genau wie der Database Designer) optional. Sie sind Spezialisten, die die Schlüsselartefakte des Workflows überprüfen. Die folgende Tabelle zeigt die Schlüsselartefakte diese Workflows: Tabelle 2. Schlüsselartefakte des Analyse & Design-Workflows Artefakt Design Model Software Architecture Document Beschreibung Hauptskizze des zu konstruierenden Systems Beschreibt verschiedene Architektursichten auf das System Workflow und Werkzeugunterstützung Die einzelnen Aktivitäten der Worker während des Analyse und Design-Workflows werden in der folgenden Abbildung dargestellt. Abbildung 11. Analyse und Design-Workflow Während der Architectural Analysis definiert der Architect wie die Architektur organisiert wird. Er sucht nach grundlegenden Architekturmustern, Schlüsselmechanismen und Modellierungskonventionen für das System. Aus dieser Aktivität resultieren lebenswichtige Informationen für die Projektplanung. Anschließend identifiziert der Designer bestimmte Klassencharakteristika und Beziehungen (Use-Case Analysis). Die entstandenen Klassen werden von dem Architect auf architekturrelevante Klassen hin untersucht und zu Design Packages 09. Dez Seite 21

24 The Rational Unified Process - Beschreibung der wichtigsten Workflows und Teilsystemen gruppiert. Es schließen sich die anderen Architektursichten an: Prozeßsicht und Verteilungssicht. Die Erstellung der Implementierungssicht erfolgt im Implementation-Workflow. Aus den Ergebnissen des Architects erzeugt der Designer Teilsystem-Schnittstellen. Anschließend können die Use-Cases vollständig entworfen werden (u.a. mittels Sequenz- und Kollaborationsdiagrammen). Bei großen Datenmengen wird der Database Designer hinzugezogen, der aus den persistenten Klassen Datenbanktabellen entwirft. Auch während einer Iteration können diese Einzelaktivitäten (z.b. aufgrund von später entdeckten Klassen) mehrfach durchlaufen werden. Als Beschreibungssprache der einzelnen Modelle wird UML verwendet. Bei der visuellen Modellierung unterstützt Rational Rose. Rational SoDA hilft bei der automatischen Erstellung von Dokumenten und Berichten. 3.3 Der Implementation-Workflow Zweck des Workflows Der Implementierungs-Workflow verfolgt vier Ziele: Er definiert die Organisation des Quellcodes. Diese wird in Form von in Schichten dargestellten Subsystemen vorgenommen. Die Implementierung von Klassen und Objekten in Form von Komponenten (Quellcodedateien, Binärdateien, ausführbare Dateien) Das Testen der entwickelten Komponenten als einzelne Einheiten Die Integration der Ergebnisse der einzelnen Entwickler oder Teams in ein ausführbares System. Der Implementierungs-Workflow ist auf das einzelne Testen individueller Komponenten beschränkt. System- und Integrationstest sind erst im Test-Workflow näher beschrieben. Der Grund für diese Trennung liegt darin, daß der Entwickler für den Test (s)einer Einheit verantwortlich ist Worker und Artefakte Die wichtigsten Worker des Implementierungs-Workflows sind: Der Implementierer, der die Komponenten und Artefakte entwickelt sowie die einzelnen Einheiten testet. Der Systemintegrator, der ein Build erzeugt. (Ein Build ist eine operationale Version eines Systems oder des Teils eines Systems. Ist ein Build ein Teil eines Systems, so beinhaltet er eine Teilmenge der Funktionen, die im fertigen System enthalten sind.) Andere beteiligte Worker sind: Der Architekt, der die Struktur des Implementierungsmodells mit seinen Schichten und Subsystemen festlegt. Der Codegutachter (Code reviewer), der den Code auf Qualität und Übereinstimmung mit dem Projektstandard untersucht. 09. Dez Seite 22

25 The Rational Unified Process - Beschreibung der wichtigsten Workflows Die wesentlichen Artefakte der Implementierung sind: Implementierungssubsystem: Dies ist eine Ansammlung von Komponenten und anderen Subsystemen der Implementierung. Es wird zur Strukturierung des Implementierungsmodells genutzt, indem es in kleinere Teile zerlegt wird. Komponente: Eine Komponente ist ein Stück Software (z.b. Quellcode, ausführbare Datei) oder eine Datei, die Informationen enthält (z.b. readme- Datei). Eine Komponente kann auch ein Aggregat von anderen Komponenten (z.b. Anwendung aus mehreren ausführbaren Dateien) sein. Integrationsplan für Builds: Dieses Dokument bestimmt die Reihenfolge, in der die Komponenten und Subsysteme entwickelt werden sollen. Desweiteren spezifiziert es die Builds, die bei der Integration erstellt werden müssen. Die folgende Abbildung verdeutlicht die beteiligten Worker und die Artefakte der Implementierung: Abbildung 12. Worker und Artefakte im Implementierungs-Workflow 09. Dez Seite 23

26 The Rational Unified Process - Beschreibung der wichtigsten Workflows Workflow Die folgende Abbildung zeigt einen Implementierungs-Workflow: Abbildung 13. Ein Workflow während der Implementierung Aufbauend auf der Struktur des Implementierungsmodells definiert der Systemintegrator, wie das System integriert werden soll. Der für ein Subsystem verantwortliche Implementierer (Entwickler) führt die gleiche Aktivität auf der Ebene eines Subsystems durch, bevor er mit der aktuellen Implementierung beginnt. Auf der Ebene der Einheiten führt der Implementierer dann die entsprechenden Tests durch, bevor er mit der Integration des Subsystems beginnt. 3.4 Test-Workflow Zweck des Workflows Der Zweck des Testens besteht in der Bewertung und Beschreibung der Testlaufergebnisse im Vergleich zu den Qualitätsanforderungen, die an das zu entwickelnde Produkt gestellt wurden. Der Rational Unified Process konzentriert sich darauf zu verifizieren und zu messen, in welchem Grad das Produkt die erforderliche Qualität erreicht hat oder nicht. Hier findet sich das Best Practice Prüfung der Softwarequalität wieder. Der Test-Workflow beinhaltet folgende Aktivitäten: Verifizieren des Zusammenspiels von Objekten und Komponenten Verifizieren der korrekten Integration aller Komponenten in die Software Verifizieren, daß alle Anforderungen vollständig und korrekt implementiert wurden Sicherstellen, daß alle gefundenen Fehler behoben wurden, bevor die Software ausgeliefert wird 09. Dez Seite 24

27 The Rational Unified Process - Beschreibung der wichtigsten Workflows Das Testmodell Das Testmodell stellt dar, was alles getestet werden soll. Es beinhaltet eine Auflistung aller Testfälle, Testprozeduren, Testskripte, und der erwarteten Testergebnisse. Außerdem enthält es eine Beschreibung der untereinander bestehenden Beziehungen. Somit besteht das Testmodell aus folgenden Inhalten: Testfälle: Unter Testfällen versteht man die Menge aller Testdaten, Ausführungsbedingungen und der erwarteten Testergebnisse, die für ein bestimmtes Testobjekt definiert werden. Testfälle können von Use Cases, Designdokumenten oder aus dem Quellcode abgeleitet werden. Testprozeduren: Testprozeduren sind eine Menge detaillierter Instruktionen zur Instanzierung, zur Ausführung und zur Evaluierung der Testergebnisse für die Testfälle. Testskripte: Testskripte sind (im Idealfall) maschinenlesbare Anweisungen, um den Testprozeß zu automatisieren. Zwischen diesen drei Artefakten existieren folgende Beziehungen: Ein Testfall kann durch eine oder mehrere Testprozeduren beschrieben werden. Eine Testprozedur kann den gesamten oder einen Teil eines Testfalls implementieren. Ein Testskript kann entweder eine gesamte, mehrere oder einen Teil einer Testprozedur implementieren. Die folgende Abbildung verdeutlicht noch einmal alle Bestandteile eines Testmodells und ihre Beziehungen zueinander: 09. Dez Seite 25