Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent: Carlos Lenz / Fabian

Gliederung I. Entstehungsgeschichte II. Der Unified Process III. Der Lebenszyklus des Unified Process IV. Anforderungs - Workflow V. Analyse - Workflow

I. Entstehungsgeschichte – 1967 Ericsson, software engineering process – 1987 Ivar Jacobson, Objectory – 1999 schreiben Ivar Jacobson, Grady Booch und James Rumbaugh das Buch "Unified Software Development Process" – Unified Software Development Process = Unified Process (UP)

I Entstehungsgeschichte – Die UML wurde parallel dazu entwickelt – Weiterentwicklung des UP ist der Rational Unified Process von IBM ● ABER: Dieses Referat ist über den Unified Process (UP)

II. Notwendigkeit des Unified Process (UP) ● Warum gibt es den UP überhaupt? – Höhere Ansprüche an Softwaresysteme (z.B. SAP) von Seiten der User (Privatleute, Firmen etc.) und sie sollen schnell verfügbar und zuverlässig sein ● Anforderung => Entwicklung => Softwaresystem – Der UP beschreibt und modelliert alle 3 Phasen, allerdings am stärksten die 2. Phase

II. Grundlagen des UP ● Der UP ist use-case-driven – Use-cases sind Anforderungen der User an ein System z.B.: Abheben bei einem Bankautomaten, Tonartbestimmung bei einem Musikstück – Von use-cases geht bei der Entwicklung alles aus. Klassen & Programme können / sollen schnell angepasst werden

II. Grundlagen des UP ● Mehrere Use-Cases zusammen bilden ein sog. Use- Case-Model – Es gibt zwei Arten von Use-Case-Models: ● Generelle Funktionsbeschreibung (normaler Ablauf) ● Optionale Funktionsbeschreibung (Abweichungen)

II. Architektur des UP ● Die Architektur eines UP besteht aus 3 Teilen: – 1. Organisation der Anforderungen – 2. Die Identifizierung von Subsystemen während des Entwurfs eines Systems – 3. Was für eine Art von Architektur optimal ist für das zu entwickelnde System ● Die Architektur stellt das „Gerüst“ dar, das mit Programmen und Interfaces gefüllt wird

II. Eigenschaften des UP ● Der Lebenszyklus des UP besteht aus 4-Phasen ● Die 4 Phasen bestehen aus n-Iterationen ● Das sog. Inkrement bezeichnet in diesem Kontext die Größe in der sich die Iterationen und ihre einzelnen Workflows bewegen (grob / detailliert etc.)

III. Der Lebenszyklus (LZ) des UP ● Der Lebenszyklus des UP besteht aus 4 Phasen

III. Die 4 Phasen ● Die 4 Phasen stellen den Lebenszyklus der Erschaffung eines Softwaresystems dar ● Phase 1: Beginn (Inception) – Eine Idee wird zu einer Vision des fertigen Endproduktes, bestehend aus Anforderungen – Fragen wie z.B. „Was wird das System den Usern hauptsächlich bringen?“ werden beantwortet (Idealfall)

III. Die 4 Phasen ● Phase 2: Ausarbeitung (Elaboration) – Die Architektur des Systems wird erdacht („Skelett“ / baseline) – Es wird versucht die Vision in kleinere use-cases aufzuteilen, um effektiver zu arbeiten – Aus diesen use-cases kann der Projektleiter die konkreten Aufgaben an sein Team vergeben – Entwicklungszeit wird geschätzt

III. Die 4 Phasen ● Phase 3: Konstruktion (Construction) – Diese Phase beinhaltet nach der konzeptuellen Planung die tatsächliche Programmierung und Implementation – Es können Fehler entdeckt werden, die dem Architekten mitgeteilt werden zur Verbesserung – Erste Tests von Seiten der Mitarbeiter, damit eine Beta- Version den Usern gegeben werden kann

III. Die 4 Phasen ● Phase 4: Übergang (Transition) – Beta-Releases werden veröffentlicht und getestet von Usern – Fehler aus Sicht der User werden mitgeteilt zur weiteren Verbesserung des Systems

III. Zusammenfassung des LZ ● Der UP besitzt 4 Phasen, die den Lebenszyklus der Entwicklung für ein Softwaresystem darstellen (1:4) ● Bei den sog. Milestones wird das Ergebnis überprüft

III. Die Iterationen in einer Phase ● Alle 4 Phasen können aus mehreren Iterationen bestehen

III. Iterationen ● Eine Phase kann mehrere Iterationen besitzen (1:n) – Es kommt erst die nächste Iteration, sobald die derzeitige Iteration vollendet ist

III. Iterationen ● Eine Iteration in sich besteht aus allen 5 Workflows (1:5) – Iterationen = Miniprojekte

III. Über die Workflows ● Wie sind die 5 Workflows in sich aufgebaut?

III. Workflows / Models ● Jeder Workflow erzeugt ein Model

III. Zusammenfassung des UP ● Ein Lebenszyklus im UPsetzt sich wie folgt zusammen: – 4-Phasen => n-Iterationen => 5 Workflows => 5-6 Models

IV. Anforderungen (1. WF) ● Man versucht in der sog. Anforderungserfassung (Requirements Capture) die Wünsche der User in Anforderungen (1. Workflow) umzusetzen – Aus diesem Grund ist jedes Softwaresystem einzigartig, da es einen Teil dieser Welt modelliert, z.B. MuWi- System <> SAP ● Man verwendet hierzu im Detail das sog. Domain Model und das speziellere Business Model

III. Domain Model ● Das Domain Model (DM) versucht wichtige allgemeine Arten von Objekten innerhalb eines Systems zu identifizieren und als Anforderung zu benennen – Hierbei sind die Anforderungen gemeint, die jedes System braucht, z.B.: Jedes Softwaresystem (z.B. SAP, Bankautomat) braucht Eingabe / Ausgabe und Interfaces für die User

III. Business Model ● Das Business Model (BM) = spezielleres Domain- Model, das für wirtschaftliche Softwaresystem wie z.B. SAP gebraucht wird – Anforderungen, die von SAP gestellt werden sind z.B. Funktionen für das Rechnungswesen, die Lohnverwaltung, Aufträge, interne Programmierung mit ABAP oder Java oder Arbeitsteilung

III. Business Model ● Im einzelnen besteht das Business Model (BM) aus: – 1. Business Use Case Model ● Eine grobe Einteilung ● eine grobe Benennung der Use-Cases – 2. Business Object Model ● Eine genauere Einteilung der User ● Genaure Einteilung der Aufgaben ● Relationen zwischen User und Aufgaben werden gebildet

III. Business Object Model ● Im einzelnen bedeutet das Business Object Model z.B. für ein SAP System: – Rechnungswesen => keine SAP Programmierung – Programmierer => keine Geschäftszugriffe ● Der Vorteil liegt hier in der Sicherheit und die in ihren Aufgaben verschiedenen User brauchen nicht Zugriff auf sämtliche Funktionen eines Systems

V. Analyse (2. WF) ● Der Analyse Workflow beinhaltet die konzeptuelle Betrachtung der Anforderungen, die für die Programmierer wichtig sein werden – Die Sprache soll eine sein, die den Programmierern zugänglich sein soll und auch aus Fachbegriffen besteht

V. Analyse ● Ziel des Analyse Workflows ist ein Analysemodell, das wie folgt aufgebaut ist und sich aus folgenden 3 Bestandteilen zusammensetzt

V. Einfluss auf die Architektur ● Der Architekt des Systems muss prüfen ob dieses Analysemodell vereinbar ist mit der Architektur ist und ob es Vorteile bringt – Weitere Personen, die sich um die Integrität der Use Cases und der Analyse Klassen / Packages sind der Use Case Ingenieur und der Komponenten Ingenieur

V. Zusammenfassung ● Analyse Workflow: – Analyse Packages werden identifiziert – Analyse Klassen liefern Informationen über ihre Verantwortlichkeit, ihre Attribute und die Relationen zu anderen Klassen – Use Case Realisierungen beschreiben, wie Use Cases umgesetzt werden können von den Progammiern – Architektur Analyse Model => Design Model

Fragen???

Vielen Dank!!!