Zusammenfassung - Software Bakery
Transcription
Zusammenfassung - Software Bakery
HSLU Hochschule Luzern IT Konzepte und Modelle Modulzusammenfassung IT Systeme und Modelle The Software Bakery Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz 20. Januar 2014 Zu diesem Skript. Dieses Skript stützt sich auf die Vorlesungen im Fach IM bei A. Kurmann und M. Jud während des Herbstsemesters 2013 und verarbeitet die dort gehörten Inputs mit ausgewählten Aspekten aus diverser Fachliteratur. Die Kapitelüberschriften korrespondieren mit den entsprechenden Kapiteln der Vorlesungen. i TAKE CARE OF OUR ENVIRONMENT – PLEASE CONSIDER BEFORE YOU PRINT OUT. Inhaltsverzeichnis 1 Bestandteile eines Grobkonzepts 1.1 Das IT-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IM 5 5 1.2 Themen eines Grobkonzepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 Requirements Engineering & Management 7 2.1 Requirements Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Anforderungsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Sammeln der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Ausarbeitung von Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5 Verwalten der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Scope & Resultate 13 3.1 Scope (Gültigkeitsbereich) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Projektresultate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4 Projekt- & Vorgehensmodell 14 4.1 Überblick über SoDa (Software Development Agile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Scrum: agil, iterativ & inkrementell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 Planung von Software-Projekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4 Meilensteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5 Projektstrukturplan (Projektphasen-Modell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6 Rahmenplan und Erstellung der Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.7 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.8 Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.9 Testen mit SoDa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.10 Projektcontrolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5 Modellierung 24 5.1 Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2 Modellbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3 „3 Sichten“ der Modellierung: Daten-, Prozess- und Funktionssicht . . . . . . . . . . . . . . . . . . . . . . . 25 6 UML (Unified Modeling Language) 26 6.1 Ebenen der Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.2 Verhaltensdiagramme: Aktivitäten und Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.3 Strukturdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.4 Interaktionsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.5 Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7 Prozess-Modellierung 35 7.1 Einführung in Geschäftsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2 Modellierung von Prozessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.3 Sprachen für die Prozessmodellierung: Beispiel EPK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.4 Erweiterte EPK (eEPK): Rollen und Informationsobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8 Funktionsmodellierung 38 8.1 Objektorientierte Funktionsmodellierung: CRC-Karten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.2 Grundlagen der Dekomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.3 Dekomposition von DV-Systemen (Funktionale Zerlegung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9 Kontextdiagramm 42 10 Datenmodellierung 43 10.1 Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.2 Datenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.3 Informations(struktur)modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.4 Entity-Relationship Modell (ER-Modell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.5 Vereinfachtes ER-Modell und Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.6 Beispiel eines Informationsmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11 Systemdesign 48 11.1 Einflussfaktoren & Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 11.2 Von der Idee zur Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.3 Heuristiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 11.4 Systemdesign kommunizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11.5 Entwurf der Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 11.6 Architekturaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Literatur The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz 60 Seite 4 1. Bestandteile eines Grobkonzepts IM 1.1. Das IT-Projekt Business-OE ’Business’ Benutzer ? Anforderung IT IT IT Ziel Konzeption Realisierung Einführung Voranalyse Nutzung / Nutzung / Einführung Einführung WAS ist das Problem? SOLLEN wir etwas tun? WAS sollen wir tun? Lohnt es sich? Machbar? Die rot geschrieben Punkte sollten unbedingt VOR dem eigentlichen Projektstart geklärt werden. Sie werden festgehalten in einem Grobkonzept. Der Projektstart soll erst erfolgen, sofern eine Motivation zur Lösung des Problems / der Aufgabe besteht. Dabei wird genau herauskristallisiert, WIESO am Projekt gearbeitet wird. Folgende Fragen stehen dabei im Zentrum: • Welche Informationen müssen in welcher Tiefe und Granularität vorhanden sein, damit man über ein Projekt entscheiden kann? • Welche Teile umfasst ein Grobkonzept? 1.2. Themen eines Grobkonzepts Im Grobkonzept werden in der Initialisierungsphase zwei Fragen geklärt: a) Was soll das System leisten? b) Wie sieht das System grob aus? 1.2.1 Struktur des Grobkonzepts Das Grobkonzept kann sec und einfach daherkommen (z.B. in Form von Slides, siehe Dokument „AlpineRe_Grobkonzept.pdf“). Folgende Punkte sollten allerdings darin enthalten sein: (A) VISION lierung der Ziele (aus der Sicht der Benutzer). SollAussage über das System. • Ausgangslage: Problemstellung und wichtigste Stakeholder • Ziel(e): Zustand / Situation nach dem Projekt • Scope: was gehört zum Projekt und was nicht (Gültigkeitsbereich, Abgrenzung, Einschränkungen) • Anforderungen: wichtigste Anforderungen zur Detail- The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz • Resultate: Arbeitsergebnisse, welche konstruiert werden. Diese beschreiben genauer, was der Auftraggeber oder die Benutzer „in die Hand“ kriegen. Resultate sind präzis und klar zu umschreiben. • Business Case / Nutzenanalyse: von den Zielen abgeleiteter Nutzen (Mehreinnahmen, Kostenreduktio- Seite 5 1.3 Ziele nen, Erfüllung externer Zwänge), bestehend aus ei- • Approach / Lösungsskizze (optionaõ): Wie gedenkt nem qualitativen (Beschreibung) und quantitativen man, mit dem Projekt die Probleme zu lösen. Dies (Berechnung) Teil. kann eine Optimierung eines Prozesses sein (B) PMP (PROJEKT MANAGEMENT PLAN) • Grobplanung (Aufwand und Zeit): a) grobe Zeitund Meilenstein-Planskizze, b) Aufwand- und Kosten- (C) SYSTEM-SPEZIFIKATION • Kontext-Diagramm: Übersicht über die Umsysteme und die Komplexität • Informationsmodelle: wichtigste Informationsobjekte und deren Zusammenhänge, welche eine zentrale Rolle spielen. • Prozesslandkarte / Prozesse (optional): Überblick schätzung • Projektorganisation & -struktur: Interessengruppen, Rollen und deren Besetzung über die zu automatisierenden Geschäftsprozesse erhalten. • Funktionale Zerlegung (Funktionsdiagramm): die wichtigsten Funktionen oder Funktionsblöcke eines IT-Systems, Sicht „von aussen“ • Systemdesign: physischer Aufbau (einzusetzende Software- und Hardwarekomponenten) → siehe Übung 2.2: Bestandteile eines Grobkonzepts 1.3. Ziele Definition 1: Ziel(e) Ziel(e) beschreiben einen Zustand / eine Situation. Dabei geht es um die Frage, WAS man mit dem Projekt erreichen will bzw. was NACH dem Projektende „besser“ oder „anders“ als vorher sein soll. → siehe Übung «AlpineRe_Grobkonzept.pdf»: Slide 4 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 6 2. Requirements Engineering & Management IM Requirements Engineering ist diejenige Disziplin, welche die Anforderungen an das Zielsystem aktiv durch ihren gesamten Lebenszyklus begleitet. Definition 2: Requirement Ein Requirement ist eine Anforderung. Über ein System oder einen Prozess soll eine Soll-Aussage entstehen, die etwas Wahrnehmbares für einen Beobachter oder ein Umsystem beschreibt (z.B. eine Leistung / ein Verhalten oder eine Eigenschaft). Anforderungen können im Projektverlauf ändern aufgrund von: • • • • veränderten Bedürfnissen von Kunden Veränderungen von Märkten / Aufkommen neuer Märkte Änderungen der Organisation (kundenseitig oder entwicklerseitig) neuen / geänderten politischen oder rechtlichen Randbedingungen Ziel des Requirements Management Merke: Anforderungen stabil halten und Veränderungen kon- 60% der Fehler passieren in der Analyse, in De- trolliert zulassen. sign und Implementierung aber nur 40%. Die Kosten der Fehlerbehebung steigen aber exponentiell mit dem Zeitpunkt der Entdeckung. Daraus leitet sich das Konfigurationsmanagement für Anforderungen ab. → siehe Übung 3.1: Aufgabe 1 Christof Ebert © 2009 Vector Consulting Services GmbH 2.1. Requirements Engineering Ebenen der Anforderungen Requirements Engineering dient den folgenden Zwecken: • Abstimmung mit den Anforderungen des Auftraggebers • zur „Baubarkeit“ des Systems (Anforderungen definieren den Zweck) • der Verfolgbarkeit möglicher Änderungen über das Projekt hinweg IM HS13, Kp 3 18 M. Jud Merke: Requirements Engineering → Verfolgbarkeit von Anforderungen → Spezifikation der Module → Testen des Systems The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 7 Aus einem STRAW’01 Paper von Bashar Nuseibeh 2.2 Anforderungsverwaltung Development of Requirements & Architecture 2.2. Anforderungsverwaltung Eine Anforderungsverwaltung sammelt und verwaltet die Anforderungen. Anforderungen und mögliche Lösungen stehen dabei in einem wechselseitigen Zusammenhang (siehe Bild). Die Wechselwirkung bzw. gegenseitige Beeinflussung ist dabei imminent. Requirements Engineering ist damit nicht einfach nur „die erste Stufe des Projektablaufs“, sondern vollzieht sich über das gesamte Projekt. Imkrementelle Vorgehensweisen1 erhöhen die Erfolgschancen dessen. Merke: IM HS13, Kp 3 M. Jud 25 Früh damit beginnen, Muster und Prototypen zu entwickeln und danach Feedbacks beim Kunden einholen! → siehe Übung 3.1: Aufgabe 2 Kontextdiagramm 2.3. Sammeln der Anforderungen Das Sys - 2.3.1 Systemkontexte Das Kontextdiagramm (siehe auch Kapitel 9) zeigt die Systemgrenzen eines Projekts auf. Die Anforderungen beschreiben damit also das System und seine Schnittstellen: a) Was muss ermittelt werden? Systemgrenze - System b) Wie sieht die Systemumgebung aus (Umsysteme)? c) Welche Schnittstellen sind nötig? Kontextdiagramme in UML - Kontextdiagramme können als Use Case-Diagramme (siehe Kapitel 2.6) in UML erstellt werden (siehe auch Vorschlag dazu im Kapitel 2.4). Als Quellen zur Ermittlung der Anforderungslisten gelten: • Stakeholder: Ansprechpartner beim Auftraggeber • bereits vorhandene Dokumentationen bzw. allgemein Dokumente • Gesetze und existierende Verordnungen Systemumgebung Umsystem(e) → siehe Übung 3.1: Aufgabe 4 1 IM HS13, Kp 3 siehe dazu auch Modul „Software Komponenten“, Kapitel 1 (Frühlingssemester 2013) The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz 29 Seite 8 Die das Sch 2.4 2.3.2 Ausarbeitung von Anforderungen Techniken Reihenfolge: Technik Zweck Nutzen Interview mindestens am Anfang, so früh wie mög- liefert viele nützliche Daten lich, oft wiederholen Fragebogen Fragen sind bekannt, zu befragende Klärung der „Lager“ Workshops bei komplexen Themen Szenarien durchspielen beim ersten Entwurf liefert nötige Details Prototyp Prosa-Spezifikation in abstrakter Form, Gefühl für das spätere System erfahren, direk- technisch, nicht primär für den Benutzer tes Feedback (z.B. GUI-Prototyp) Gruppe ist gross intensiv, aber eher aufwändig 100% verständlich Beobachten vor Ort falls Prozesse und das Umfeld für den reduziert das Risiko, implied needs zu überse- Auftragnehmer unbekannt sind, Einbli- hen, Missverständnisse minimieren cke ins Business und in die Prozesse des Kunden gewinnen → siehe Übung 3.2: Aufgabe 1 2.4. Ausarbeitung von Anforderungen Auf die Requirements sind zwei Gruppen angewiesen: • Auftraggeber Spezifikationen verstehen und abnehmen → nicht zu detailliert, nicht zu technisch • Entwickler müssen wissen, was zu bauen / entwickeln ist → muss detailliert und technisch sein Präsentiert werden diese Anforderungslisten einer Management-Gruppe, indem ein „Big Picture“ knapp die wichtigsten Eigenschaften und den Kontext eines Systems darstellt. Hier eignen sich UML Use-Cases (mit entsprechendem Stereotyp «requirement») zur Beschreibung von Requirements sehr gut (siehe Oestereich (2009, S. 41ff). → siehe Übung 3.2: Aufgabe 2 2.4.1 Kategorisierung von Anforderungen Merke: Dabei zählen qualitative Anforderungen (z.B. System uptime = 7 × 24) sowie funktionale (z.B. Use-Case-Diagramme) und nicht funktionale Anforderungen. Man unterscheidet die folgenden Anforderungen voneinander: • funktionale (Geschäftsregeln: Bedingungen, Zustand, Zusicherung) / nicht funktionale (Zuverlässigkeit, Wartbarkeit, Be- • Vorschriften, welche erfragt werden müssen • Annahmen / Tatsachen • hart (Sperrung nach Ablauf) / weich (einfach nutzbar) nutzbarkeit, Änderbarkeit, Übertragbarkeit, Effizienz) Alle Anforderungen sollen in einer Spezifikationsschablone (Tabelle) gesammelt werden (siehe hierzu Oestereich (2009, S. 41ff)). The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 9 2.5 Verwalten der Anforderungen Achtung: Anforderungen statt Lösungen formulieren! Anforderungen sollten NIE Lösungen beschreiben; auf eine Anforderung passen immer mehrere Lösungen! Beispiel. Lösung: „Die Händlerstammdaten müssen um ein Feld für einen dritten Mehrwertsteuersatz erweitert werden.“ Anforderung: „Das System muss Anträge mit einem von drei Mehrwertsteuersätzen abrechnen können.“ Quantifizierbare Anforderungen Qualitative Anforderungen sollen – wenn immer möglich! – quantifizierbar sein. Beispiel. „Das System muss schnell sein“ (→ nicht quantifizierbar!) „Antwortzeit in 95% der Fälle < 2 Sekunden“ (→ alles quantifizierbar!) → siehe Übung 3.1: Aufgabe 4 2.5. Verwalten der Anforderungen Aus: Vorlesung Requirements Enfineering I, Kapitel 14 Verwalten von Anforderungen, © 2006 Prof. Martin Gliz,, Uni Zürich Änderungsprozess Alle Anforderungen kommen in eine gemeinsame Datenbasis. Der Änderungsprozess sollte definiert sein, wie folgendes Musterbeispiel zeigt: • Geregeltes Prozedere • Entscheidung durch Steuerkomitee *) - Mitglieder: Vertreter von Auftraggeber und Auftragnehmer - Vorsitz: Projektleiter *) Synonyme: Lenkungsausschuss Change Control Board IM HS13, Kp 3 60 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz M. Jud Seite 10 2.6 Use Cases 2.6. Use Cases Anforderungen an ein System werden in folgende Punkte unterteilt: • Use- und Systemcases • nicht-funktionale Anforderungen • andere funktionale Anforderungen die nicht von den Usecases beschrieben sind 2.6.1 Formale Aspekte Use- und Systemcases werden in UML beschrieben (siehe dazu Kapitel 6.2.3). Normalerweise beinhaltet dies 1. ein Diagramm, welches die Aktoren und die Aktivität beschreibt 2. sowie eine textuelle Beschreibung. Die Diagramme sind nur notwendig für komplexe oder wichtige Usecases. Die textuelle Repräsentation kann jedoch immer erstellt werden. Eine Vorlage hierfür ist im Abschnitt 2.6.4 enthalten. 2.6.2 Namenskonventionen Lodging Damit die Usecases einheitlich und sauber dargestellt werClient den, sind folgende Konventionen einzuhalten: book room Portier • Usecase-Namen sind in englischer Sprache zu halten • Usecase-Namen bestehen aus wenigen Wörtern und allocate room beinhalten ein Verb sowie ein Nomen2 • Die Usecase-Bezeichner bestehen aus den zentralen Guest Acquiring Worten des Namens und sind in PascalCase zu halmanage room ten3 Marketing 2.6.3 Accounting Beschreibung der Aktoren Die Aktoren werden in tabellarischer Darstellung beschrieben. Aktore, die nicht verwendet werden, sind hierbei wegzulassen. Beispiel: Actor Description CIS User The CIS user is a person usually belonging to one of the client teams. Since CIS is a read-only system, any user might perform any action on the CIS system. 2.6.4 2 3 Usecase Template Bsp.: „create or edit data type“ Bsp.: „CreateEditDataType“ The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 11 2.6 Use Cases Attribute Description Name <name> Identifier <identifier> Type (Base|Included) Description ::= Eine kurze Beschreibung zum Usecase. Actors(s) { <actor-identifier> } Preconditions ::= Eine Aufzählung von Konditionen dier erfüllt sein müssen damit der Anwendungsfall Gültigkeit hat. Bspw.: „The user is authorized“ Basic flow ::= Beschreibt den Normalablauf des Usecases. Alt. flow 1 ::= Beschreibt einen möglichen alternativen Fluss. Zum Beispiel wenn der user die Aktion abbricht. Alt. flow n ::= Weitere alternative Flüsse. Postconditions ::= Eine Aufzählung von Konditionen die anschliessend an das Usecase zutreffen müssen. Non-functional Requirements ::= Nicht funktionale Anforderung wie bspw.: „Dieses Use-Case muss von 20 Benutzern parallel ausgeführt werden können“ Special considerations ::= Restriktionen der einzugebenden Daten. Create date ::= Erstellungsdatum (dd.mm.yyyy) des Usecases. Modification ::= Modifikationen und Änderungen des Usecases (dd.mm.yyyy <description>) The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 12 3. Scope & Resultate IM 3.1. Scope (Gültigkeitsbereich) Definition 3: Scope Der Scope definiert den Gültigkeitsbereich (Abgrenzung) eines Projekts. Dazu gehört in der Praxis vor allem die Auflistung, welche Bereiche nicht zu einem Projekt gehören (Einschränkungen, „constraints“). Der Scope wird meistens in Punkteform aufgelistet und in Stichworten kurz ausformuliert. → siehe Übung «AlpineRe_Grobkonzept.pdf»: Slide 5 3.2. Projektresultate Definition 4: Projektresultate Resultate beschreiben die Arbeitsergebnisse, welche das Projekt abzuliefern hat. Damit sind jene „Dinge“ gemeint, welche dem Auftraggeber bzw. Benutzer nach deren Vollendung zur Verfügung stehen. Resultate sind keine Aktivitäten! Das Projektcontrolling überprüft die Resultate; sobald alle Resultate vorliegen ist das Projekt beendet. Ziele → Hauptresultat → Teilresultat → Arbeitspaket Merke: Projektresultate sollen präzise / vollständig definiert und beschrieben sein für die Detaillierung der Arbeitspakete, die Aufwandschätzung, das Projekt-Controlling und -Reporting. Alle wichtigen Projektplanungs- und -Reporting-Instrumente hängen direkt von der klaren Formulierung der Resultate und Arbeitspakete ab. Die Ergebnisliste enthält eine Auflistung aller Arbeitsergebnisse, welche das Projektteam im Laufe der Projektarbeit erstellen wird. Sie wird sowohl für die Planung (Aufwand, Zeitbedarf) wie auch für die Ressourcenallokation (Fähigkeiten, Kapazität) verwendet. 3.2.1 Ergebnisraster Die Ergebnisse eines Projekts können (fast) immer in folgende Klassen unterteilt werden: 1. Applikationssoftware 4. Migration 2. Applikationsdokumentation 5. Rollout 3. Prozesse / BO 6. Projektmanagement-Ergebnisse Dabei kann für jede Klasse gefragt werden „Welche Resultate erzielen wir für 1., 2., 3., . . . , 6.?“. → siehe Übung «AlpineRe_Grobkonzept.pdf»: Slide 7 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 13 4. Projekt- & Vorgehensmodell IM 4.1. Überblick über SoDa (Software Development Agile) 4.1.1 Projektverständnis nach Jenny Jenny unterscheidet in Projekten zwischen Projektführung und Projektdurchführung. Vereinfacht kann man sagen, dass die Projektführung in allen Arten von Projekten die gleichen Aufgaben in unterschiedlicher Ausprägung umfasst. Demgegenüber ist die Projektdurchführung je nach Projektart ab einem gewissen Grad sehr spezifisch (unterschiedliche Vorgehensmodelle, Standards sowie Deliverables): • Projektführung → Allgemein die Planungsaktivitäten • Projektdurchführung → Konkrete Arbeiten und Arbeitspakete Abbildung 1: Projektverständnis nach Jenny – zwei Ebenen (Führung & Durchführung) 4.1.2 Projektführung Die Projektführung ist weitgehend unabhängig von der Art des Projektes. Allgemein kann der Ablauf gem. Abbildung 2 beschrieben werden. Abbildung 2: Phasen der Projektführung nach Jenny Insbesondere das Planen der Aufgaben sowie das Steuern und das Kontrollieren müssen bis zum Projektabschluss je nach Projektumfang periodisch oder fortlaufend gemacht werden und stellen somit keine einmalige Tätigkeiten dar. Es ist vorwiegend der Projektleiter, der diese Projektführungs- respektive die Managementtätigkeiten wahrnimmt. Das Element Projektführung hat zum Ziel, dass ein Projekt durchdacht und kontrolliert durchgeführt wird. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 14 4.1 4.1.3 Überblick über SoDa (Software Development Agile) Projektdurchführung Die Gliederung der Projektdurchführung in Phasen (vgl. Abb. 3) ist in der Regel ebenfalls unabhängig von der Art des Projektes. Abbildung 3: Phasen der Projektdurchführung nach Jenny Die Phasen (vgl. Abb. 3) sind lediglich eine zeitliche Anordnung und sagen nichts in Bezug auf den Inhalt aus. Oftmals befinden sich Meilensteine zwischen den Phasen um kritische Deliverables zu prüfen. Diese Abschnitte bilden eine Art „Schnittstelle“ zu anderen Branchen / Disziplinen. Jenny lässt die Freiheit der Gestaltung durch relativ „schwammige“ Überbegriffe. Dabei weisen die einzelnen Phasen je nach Projektart eine andere Charakteristik auf und stützen sich oft auf spezialisierte Vorgehensmodelle (vgl. Kap. 4.1.4). 4.1.4 Vorgehensmodelle 1. Klassische Modelle (Frühe Vorgehensmodelle) • Wasserfallmodelle Sequentielles Vorgehen, Phasen = Aktivitäten, Kontrolle der Aktivitätenergebnisse und Tests. • V-Modelle Sequentielles Vorgehen, Bezug zwischen analytischen und synthetischen Schritten, QS-Sicht: Verifikation und Validierung. Problem bei klassischen Modellen: Die Zusammenführung findet erst am Schluss der Sequenz statt (sequentieller Ablauf)! Innerhalb der Software-Entwicklungsbranche wäre es also von Vorteil andere Methoden nutzen zu können. Iterativ-Inkrementelles Vorgehen 2. Neuere Vorgehensmodelle. Besonders bei Software-Entwicklungsprojekten ist es meist nicht möglich bereits in derInsbesondere Initialisierungsphase alle Anforderungen vollständig zu erfassen. Zudem ist die Trennung zwischen bei Software-Entwicklungsprojekten ist es meist nicht möglich bereits in der Initialisierungsphase die Anforderungen vollständig zueher künstlich. Konzeption (SW-Design) und Realisierung (Programmierung) bei der Software-Entwicklung erfassen. Ein Vorgehen, wie bspw. in Scrum (Kapitel 4.2) beschrieben, erlaubt in mehreren Durchgängen die Anforderun- istund dieanzupassen Trennungund zwischen Konzeption (SW-Design) und Realisierung gen zuZudem ergänzen die Software schrittweise zu entwickeln (entwerfen & programmieren): (Programmierung) bei der Software-Entwicklung eher künstlich. Abbildung 4: „Erweiterung“ des Modells nach Jenny: die Konzeptions- und Realisierungsphase fallen in Projekten der Software-Entwicklung • – sinnvollerweise! – ganz oderbeispielsweise teilweise in iterativ abgewickelte Phasen. Ein Vorgehen, wie in Scrum beschrieben, erlaubt in mehreren Durchgängen die Anforderungen zu ergänzen und anzupassen und die Software schrittweise zu entwickeln (entwerfen & programmieren). Iterativ = „stete Wiederholungen“: die Aktivitäten des Entwicklungszyklus werden mehrmals durchlaufen, bereits Iterationen werden lauffähige Programmteile geschaffen (Prototypen). M. Jud IM HS13,in Kpfrühen 5a 9 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 15 4.2 Scrum: agil, iterativ & inkrementell • Inkrementell = „kontinuierlicher Funktionszuwachs“: die Releases erhalten mit jeder Iteration einen grösseren Funktionsumfang. Merke: In der Software-Entwicklung wird sinnvollerweise ein iterativ-inkrementelles Vorgehen angestrebt in Abstimmung an die Phasen von Jenny (Stichwort: Schnittstellen)a . a Um so die Zusammenarbeit mit anderen Disziplinen (falls beteiligt) sicherzustellen Top-Down-Prinzip Bottom-Up-Prinzip • Vom Groben zum Detail • Konzept auf oberer Ebene gilt als Orientierungshilfe • Es liegen sofort konkrete Lösungen vor • Verbesserung vorhandener Lösungen • Es liegen schnell Lösungen vor Durch wiederholtes Wechseln der Perspektive wächst das Problem-Verständis ständig4 . → siehe Übung 5.1: Aufgaben 1 – 4 4.2. Scrum: agil, iterativ & inkrementell Scrum basiert auf der Theorie der empirischen Prozesssteuerung und stützt sich auf die drei Säulen: Transparenz, Überprüfung und Anpassung. Es ist ein Framework, das die Entwicklung komplexer Produkte unterstützt und setzt sich zusammen aus sogenannten Scrum Teams, den zugehörigen Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente des Frameworks dient einem bestimmten Zweck und ist wesentlich für die erfolgreiche Anwendung von Scrum. Scrum Teams liefern Produkte in regelmässigen Abständen (iterativ) und stufenweise erweiternd (inkrementell) aus. Dadurch werden die Gelegenheiten für Feedback maximiert. Die inkrementelle Lieferung „fertiger“ Produkte stellt sicher, dass immer eine potentiell gebrauchsfertige und nutzbare Version des Produktes zur Verfügung steht.5 SoDa als agiler Software-Entwicklungsprozess baut in seiner Konstruktion auf Scrum auf. 4.2.1 Sprints (siehe auch Kapitel 4.6.2) Der Sprint ist das Herz von Scrum. Sprints haben während eines Entwicklungsvorhabens eine gleichmässig feste Dauer während der ein fertiges, getestetes, nutzbares und potentiell auslieferbares Produktinkrement entwickelt wird. Sprints bestehen aus mehreren Teilen: • Sprint Planning • Daily Meeting Ziel ist der Informationsaustausch • Eigentliche Entwicklungsarbeit • Sprint Review (Abnahme) am Ende des Sprints • Sprint Retrospektive (Reflexion) zwischen Review und dem neuen Sprint Planning Sprints ermöglichen Vorhersagbarkeit durch regelmässige z.B. monatliche Überprüfung des Arbeitsfortschrittes sowie Anpassung der Planung und gegebenenfalls der Zielsetzung. 4 5 Dies wird auch JoJo genannt. Auch dann, wenn das Projekt vorzeitig abgebrochen wird – nie leere Hände! The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 16 4.3 4.2.2 Planung von Software-Projekten Rollen In SoDa-Projekten werden vier Rollen unterschieden: • Projektleiter/-in Schlüsselrolle in der Initialisierungs- und Einführungsphase: Rahmenplanung, Organisation, Meilensteine, Produkteinführung • Product Owner Schlüsselrolle in Konzeptions- und Realisierungsphase („oberster Produktentwickler“): Pflege & Priorisierung des ProductBacklog, Sprint-Planung & -Abnahme, im Idealfall für Kunden der Ansprechpartner, der das Produkt sehr gut kennt (in Realität aber oftmals ein eigener Mitarbeiter, welcher vorwiegend im Kundenkontakt steht und das Produkt genau kennengelernt hat), vertritt die Wirtschaftlichkeit des Produkts für die Firma • Scrum Master «servant leader» für das Team und den Product Owner: ist verantwortlich, dass Scrum gelingt, unterstützt das korrekte Vorgehen und stellt die Qualität sicher – schützt das Team und schaut, dass Scrumvorgaben eingehalten werden (z.B. dass der SprintBacklog nicht plötzlich noch wächst, da Kunde im laufenden Sprint ein Feature noch „reinquetschen“ will), nimmt Probleme auf und kümmert sich darum • Scrum Team Entwickler/innen, die selbstorganisiert und eigenverantwortlich in den Sprints die Software entwerfen, erstellen und testen (Backlog-Einträge umsetzen) 4.2.3 Product Owner etwas genauer 1. Verwaltung des ProductBacklog (laufend) • • • • Erfassen und klares Formulieren der Einträge im ProductBacklog ordnen der Einträge in eine zielführende Fertigstellungsreihenfolge Transparenz sicherstellen des ProductBacklog für alle Beteiligten fortlaufende Pflege („Grooming“) des ProductBacklogs 2. Sprintplanung (zu Beginn jedes Sprints) • mit dem Entwicklungs-Team den Inhalt des SprintBacklogs verhandeln und Zielkonflikte auflösen • Bei Bedarf den Umfang des SprintBacklogs nachverhandeln 3. Sprintabschluss (am Ende jedes Sprints) • ermitteln, was „done“ ist (Testplan) und das Inkrement freigeben • verbleibende Arbeit ermitteln und Fertigstellungsdatum hochrechnen Weitere Infos (z.B. bezüglich Artefakte) siehe Kap. 4.7.2. 4.3. Planung von Software-Projekten Um stets die Überschaubarkeit der Projektabwicklung gewährleisten zu können, braucht es eine klare Gliederung der bevorstehenden Gesamtaufgaben in einzelne plan- und kontrollierbare Teilaufgaben. Instrumente dazu sind: a) Projektstrukturplan: deckt Zusammenhänge auf, gewährt eine Übersicht, „Projektplan-Fundament“ b) Rahmenplan: gibt eine grobe Vorstellung des übergeordneten Projektablaufs (zeigt die Projektdauer und Meilensteine sowie Iterationen [Sprints] auf) 4.4. Meilensteine Definition 5: Meilenstein Ein geplanter Punkt im Projektablauf, an dem vorher festgelegte (Zwischen-) Ergebnisse vorliegen, die es erlauben den Projektfortschritt zu messen. Der Meilenstein ist erreicht, wenn die geforderten Artefakte vorliegen und ihre Überprüfung (Review / Test) erfolgreich war. Zwischen den Milestones liegen die Sprints: The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 17 4.5 Verteilung der Meilensteine Initialisierungs Phase Konzeptions Phase Projektstrukturplan (Projektphasen-Modell) Realisierungs Phase Einführungs Phase 1 2 3 4 5 Projekt Start Start Umsetzung SystemDurchstich Start Einführung Projekt Ende Zeit S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 MS Termin Deliverables 1 01. Jan. Auftrag GL «Start Initialisierungsphase» 2 15. Feb. Grobkonzept liegt vor / Auftrag GL «Start Umsetzung» 3 30. Juni System-Durchstich erfolgt / Projektziele revalidiert (GL) 4 10. Nov. Umsetzung abgeschlossen / Auftrag GL «Einführung» 5 31. Dez. Projekt-Abschluss liegt vor, durch GL abgenommen Für die Initialisierungsphase kann wenn nötig eine detaillierte Zu jedem Meilenstein gehören Artefakte wie z.B. Prototypen, Entwurfsdokumente, Testprotokolle, . . . . Arbeitsplanung gemacht werden. Bei einer fixen Sprintdauer von 4 Wochen ergeben sich hier 10 Sprints. Die detaillierte Zielsetzung und Arbeitsplanung für die Konzeptions- und 4.5. Projektstrukturplan (Projektphasen-Modell) Realisierungsphase erfolgt im Rahmen der Sprintplanung. Merke: IM FS13, Kp 5b M. Jud 15 Der Projektstrukturplan (PSP) gliedert das Projekt in zeitliche Phasen (Projektphasen nach Jenny) und ergänzt diese um die Aufgaben des Projektleiters (Vorbereitungstätigkeiten) als eigener Strukturast: Projektführung Initialisierung «Plans are nothing – Planning is everything.» 4.5.1 Konzeption Realisierung Einführung — Dwight D. Eisenhower Der „Cone of Uncertainty“ Zu Beginn eines Projekts ist es schwierig, Aufwände genau einzuschätzen. Der „Cone of Uncertainty“ versucht die (statistisch modellierte) Abschätzung von Ungewissheiten zu einem bestimmten Zeitpunkt innerhalb eines Projekts anzugeben. Dabei soll das Mass der Unsicherheiten bei einer Abschätzung zum Zeitpunkt des Projektbeginns mit Faktor 4 bzw. 1 4 beschrieben werden (siehe Grafik): die tatsächlich benö- tigte Zeit für ein Projekt könnte daher 4× bzw. 14 × so lang sein wie ursprünglich geschätzt. Die Ungewissheit („Uncertainty“) wird sich nie von selbst optimieren („blaue Hülle“); auf das Ziel hin (dicke Linie) muss aktiv gearbeitet werden. Unsicherheiten in Bezug auf die Genauigkeit der Einschätzungen nehmen während des Projektverlaufs stetig ab – und die Einschätzungen werden dadurch immer genauer, klarer und abgrenzbarer. 4.6. Rahmenplan und Erstellung der Inhalte Ziel des Rahmenplans Den Ablauf schon früh genug grob festhalten und richtig einschätzen zu können The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 18 4.6 Rahmenplan und Erstellung der Inhalte In Bezug auf die dauernd vorhandene Unsicherheit im Projektprozess (siehe „Cone of Uncertainty“) hilft eine zweistufige Vorgehensweise: (1) ein Rahmenplan und (2) eine rollende Detailplanung . 4.6.1 1. Stufe: Erstellung eines Rahmenplans (Initialisierungsphase) Merke: Wird durch den Projektleiter erstellt, basiert auf dem Projektphasenmodell (siehe Abbildung 3), enthält die wichtigsten Meilensteine und Termine. Der Rahmenplan wird nach aussen kommuniziert. Er soll möglichst stabil sein, da häufig andere Projekte vom Stand der aktuellen Entwicklung abhängig sind. Darin enthalten sind Projektdauer (geplanter Start- und Endtermin) sowie die Meilensteine (und deren Verteilung). Vorgehen bei der Rahmenplanung: 1. Endtermin festlegen (meist vorgegeben) 2. Starttermin setzen (aufgrund Ressourcenverfügbarkeit, Entscheide der GL) 3. Meilensteine definieren (Termine und Deliverables) 4. Iterationen planen (Sprintdauer ↔ Anzahl Sprints in Konzeption & Realisierung; je nach Einflussnahme / -notwendigkeit unterschiedlich) für die Planung: Konsequenzen für die Projektplanung Konsequenzen Die Komplettheit aller Requirements kommt erst nach unendlich langer Zeit. Darum („Daumenregel“, abgeleitet aus dem „Pareto-Prinzip“): – nach t = 14 → 12 (50%) der Ergebnisse erzielt (kurze Zwei wesentliche Initialisierungsphase muss genug Klarheit schaffen, um Konsequenzen ergeben sich aus ! rasch beginnen zu können) der 80/20 – Regel – nach t = 21 →> 54 (80%) der Ergebnisse erzielt (beim für die „mittleren Pfeiler“ (50% der Projektdauer) sollten über Projektplanung: mit der Umsetzung zu (Konzeption und Realisierung) 90% der Projektresultate vorliegen; ein funktionierender Prototyp [„System-Durchstich“] muss vorliegen!) 1.Die 100% vollständigen Requirements, die 100% perfekte 2. Stufe: Rollende Detailplanung (Erstellung in der Konzeptionsphase) Spezifikation sind erst nach unendlich langer Zeit zu haben. «gut genug» ist das Ziel: eine kurze Initialisierungsphase Merke: muss genug Klarheit schaffen, um mit der Umsetzung zu (Konzeption und Realisierung) rasch beginnen zu können. Der Product Owner priorisiert Anforderungen aus dem Backlog dauernd nach Geschäftsnutzen, Aufwandschätzung im Team, und erstellt eine detaillierte Sprint-Planung der jeweils nächsten 2 Iterationen. 2.Wenn der «mittlere Pfeiler» nach 50% der Projektdauer angesetzt wird, müssen nach Abschluss der Konzeptionsphase weit über 90% der Projektresultate vorliegen. Innerhalb des Rahmenplans werden die nächsten Iterationen im „Timeboxing“ (fixe Dauer, flexibler Inhalt) geplant: Ein funktionierender Prototyp «System-Durchstich» ist eine Mindestvorgabe für diesen Meilenstein! 4.6.2 IM FS13, Kp 5b 14 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz M. Jud Seite 19 Innerhalb des Rahmenplanes werden die nächstfolgenden Iterationen im «Timeboxing» (fixe Dauer, flexibler Inhalt) geplant. Rahmenplan undes Erstellung der Inhalte Dabei wird der unmittelbar bevorstehende Sprint detailliert4.6geplant und wird für den darauf folgenden Sprint eine Grobplanung gemacht: [Modul] [Kapitel] SoDa Sprintplanning IM FS13, Kp 5b siehe Arb M. Jud 18 Wichtig: die Sprintplanung wächst damit iterativ! Zu Beginn jedes Sprints erarbeitet der ProductOwner das neue Sprint-Ziel gemeinsam mit dem Team auf Basis • der Rahmenplanung Der SoDa-Sprintplan • der aktualisierten Risikobewertung und Der SoDa-Sprintplan enthält die Sprintziele (aktualisier- te Risikoliste [siehe Kapitel 11.1.4] , zu erledigende De- • des priorisierten liverables, . . . ) und das Initial Taskboard. plan t: Der Product Owner macht für jede Aufgabe im Product Backlog6 eine Schätzung des Aufwands und eine Priorisierung für den jeweiligen Sprint7 . Die am höchsten priorisierten User Stories werden in den Sprint Backlog8 übertragen und dann vom Entwicklungsteam während des Sprints be- Es wird geprüft, wie viele der höchst priorisierten ProductBacklog-Items arbeitet. ste (Stories) in das SprintBacklog übernommen werden können, so dass print prinzipiell erreicht werden Initial Taskboard den UserStories (→etc.) in der Software-Entwicklung: "Bedürfnis eines Anwenders" bzw. bewusst • einmit sinnvolles Sprintziel dneten Das Projekt-Lieferobjekten, Meilensteinen kurz gehaltene Spezifikation einer Software-Anforderung) enthält alle Aufgaben aus dem Sprint Backlog: • mit den verfügbaren Ressourcen tobias.maestrini@bluewin.ch alte Schule • in der vorgesehenen Timebox erreicht werden kann. IM FS13, Kp 5b 19 ories , done» nung ories echen) User Story Example M. Jud As a student I want to see my marks online so that I know as soon as possible whether I have passed a course. • • • • Direct link to results can be sent / received by e-mail Swiss marking scale Unambiguous visualisation of pass / fail Results can be sorted by subject or exam date Der Product eine priorisierte Liste, die abgelegt. alles enthält, was entwickelt werden soll. Es ist nie vollständig, der Product Owner ist alleine für w erden im PBacklog M Pistals Anhang 6 www.bbv.ch die Eintragungen verantwortlich. 7 Die Auswahl basiert dabei auf der Priorität des Sprintziels, auf den verfügbaren Ressourcen und der vorgesehenen Timebox. 8 Der Sprint Backlog enthält eine Liste aller Aufgaben (Stories), die erledigt werden müssen: als Basis dienen die Items im Product Backlog mit der M. Jud 20Priorisierung. höchsten The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 20 4.7 Dokumentation Das Initial Taskboard enthält also alle Tasks (des Sprint Backlogs), die sich aus den für diesen Sprint ausgewählten ProductBacklog-Items ergeben, inkl. «definition of done»9 , Aufwand und Zuordnung sowie Abfolge im Sprint. Merke: Für die UserStories im Sprint Backlog wird immer eine Schätzung des erwarteten Aufwands und der erwarteten Dauer vorgenommen. Am Ende des Sprints muss immer „potentially shippable Software“ vorliegen. → siehe Übung 5.2: SoDa (Software Development Agile) 4.7. Dokumentation Hauptnutzung der Dokumentation Wissenssicherung, denn «eine Software lebt länger als wir denken» (Jud, 04.04.2013): 80% der Softwareentwicklung ist Pflege bestehender Systeme. Weiter hilft Dokumentationsarbeit beim Problemverständnis (z.B. Kundenanforderungen und Softwareanforderungen) und bei der Konsensbildung (z.B. Architekturmodelle und Projektpläne). Dokumente wie Softwarearchitektur sind bereits (Zwischen-) Produkte des Entwicklungsprozesses. 4.7.1 Was wird dokumentiert? Dokumentation: Was? – Für wen? Projektplanung Konfig.-Management Entwicklerinnen QS Planung Test- und Abnahmeplanung Entwurf Produkt Code Testprotokolle Anforderungen SoDa Dokumente SoDa ist agile Dokumentation. Agile Dokumentation . . . Für wen wird dokumentiert ? Was wird dokumentiert ? Prozess 4.7.2 • legt bewusst fest, was dokumentiert werden soll • ist inhaltlich aktuell und korrekt, dabei aber kompakt und gut strukturiert • leistet einen effektiven Beitrag zur Unterstützung der anderen Projektaufgaben Installation Kunden Betrieb IM FS13, Kp 5c M. Jud 4 Dabei werden folgende Dokumente gefordert: Projektebene Dokument Erstellungszeitpunkt Projektführung • Projektplan Erstellung in der Initialisierungsphase, Aktualisierung Projektdurchführung • Grobkonzept • Product Backlog • Sprint Backlog • Sprintplan • Sys Spezifikation • Testplan • Testprotokoll bei jedem Meilenstein 9 Initialisierungsphase Initialisierungsphase zu Beginn jeden Sprints zu Beginn jeden Sprints Initialisierungsphase, Ergänzung pro Inkrement im Projektplan, Ergänzung pro Inkrement pro Inkrement zu Beginn festgelegte Kriterien, wann eine User Story als «done» akzeptiert wird The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 21 4.8 Projektmanagement-Plan. Testen Zur Projektführung wird in der Initialisierungsphase ein Projektplan erstellt. Insbesondere das Kapitel „Projektführung“ wird bei jedem Meilenstein nachgeführt. Folgend die Inhalte eines ProjektmanagementPlans: • Projektorganisation – Konfigurationsmanagement – Organisationsplan, Rollen & Zuständigkeiten – Reviewplanung – Projektstrukturplan – Abnahmeplanung • Projektführung • Testplan – Rahmenplan – Testdesign & Abläufe – Projektkontrolle – Testfälle – Risikomanagement (siehe Kapitel 11.1.4) – Projektabschluss • Projektunterstützung – Tools für Entwicklung, Test und Abnahme • Anhänge – Sprintpläne – Meilensteinberichte – Reviewprotokolle 4.8. Testen Am V-Modell lassen sich die Zusammenhänge des Testens besonders gut zeigen: Zu jeder Disziplin (Anforderungen, Entwurf, Implementierung) gibt es eine Entsprechung auf der Test-Seite. Unterschied „Validierung“ und „Verifikation“ Validieren (haben wir das Richtige entwickelt?) und verifizieren (haben wir es richtig gemacht?) • Unit- / Komponententests / Funktionale Tests → Verifikation • Abnahmetests → Validierung Abnahme ist nicht nur dann, wenn die Entwicklung fertig ist – sondern auch dann, wenn ein Sprint zu Ende ist und ein neues Release bevorsteht. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 22 4.9 Testen mit SoDa Testen ist unumgänglich, denn je nach Statistik findet man mit jeder Testart und jedem Review etwa 33% bis 67% der Fehler, die in einer Software stecken. Die Komplexität von Software-Produkten erfordert einen Testentwurf nach Modellen. 4.9. Testen mit SoDa Da die 100%ige Abdeckung der Tests schon aus wirtschaftlicher Sicht nicht realisierbar ist, beschränkt man sich bei SoDa auf ein adäquates Soll, welches getestet wird. Dieses Soll setzt sich aus folgenden Punkten zusammen: • welche Konfigurationen (HW/Daten/SW) und Abläufe/Interaktionen bergen die grössten Risiken? • was ist Teil der Abnahme? • was sind anwendbare Vorschriften? Getestet wird opportunistisch, da es aufwändig ist. Tests, die sich ohne grossen extra Aufwand durchführen lassen, werden zusätzlich durchgeführt. Bei umfangreicheren Zusatztests wird das Delta zum adäquaten Soll ermittelt und nach Aufwand/Ertrag durchgeführt. Testen ist in SoDa eine Haupttätigkeit und kommt daher in allen Phasen des Softwareprojektes wieder vor (iterativ). In dieser Tätigkeit werden Tests für geeignete Einheiten (Komponenten/Subsysteme) realisiert und sichergestellt, dass diese bei einem Release vorher erfolgreich ausgeführt wurden. Tests werden für Kundenabnahmen verwendet und reduzieren so das Risiko des Entwicklers. Ausserdem wird der Aufwand für die Gesamtabnahme reduziert. Iterative Tests werden auf allen Ebenen (Unit, Komponenten, Subsysteme, Systeme) durchgeführt. Das iterative Vorgehen besteht nicht nur aus iterativen Tests und Abnahmen; auch Dokumente werden iterativ freigegeben um Konsistenz über die ganze Entwicklung sicherzustellen. Aus Sicht der Testtätigkeit sind folgende Dokumentationen wichtig: • Testplanung • Testprotokoll • Softwarefehlerverfolgung (Bsp. Bugzilla) → siehe Übung 5.1: Aufgabe 6 4.10. Projektcontrolling Bei der Analyse des Projektfortschritts steht die Frage nach dem jeweiligen Fertigstellungsgrad der durchzuführenden Entwicklungsarbeiten an zentraler Stelle. Das Problem beim Ermitteln des Fertigstellungsgrades liegt im Fixieren des fertigen Arbeitsvolumens. 4.10.1 Die Frage nach dem Restaufwand Grundsätzlich sollte ein Fertigstellungsgrad auf Basis der Werte „verbrauchter Aufwand“ und „geschätzter Restaufwand“ berechnet werden. Deshalb sollte der Projektleiter nicht nach dem Grad der Fertigstellung, sondern immer nach dem zu leistenden Restaufwand fragen: es geht also nicht um die Fragen nach „wieviel“ und „wie lange noch“, sondern nach „fertig oder nicht fertig“10 . In einem agilen, iterativ-inkrementellen Projekt lässt sich der Restaufwand nur für die aktuelle Iteration klar bestimmen: der ProductBacklog kann sich ja im Projektverlauf stets ändern, neue Anforderungen kommen dazu, bestehende werden geändert oder fallen weg. 10 „fertig“ bedeutet, dass der Code komplett integriert und auch getestet ist! The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 23 5. Modellierung IM Ein Modell . . . • • • • ist ein vereinfachtes Abbild der Realität dient einem bestimmten Zweck zeigt eine erwünschte „Genauigkeit“ auf nach einer gewissen Relevanz stützt sich auf einen Plan 5.1. Modelle Definition 6: Modell Konkretes oder gedankliches Abbild eines vorhandenen Gebildes oder Vorbild für ein zu schaffendes Gebilde in der Wahrnehmung der beteiligten Personen für einen bestimmten Verwendungszweck. Dabei wird dieses bewusst abstrahiert und gestaltet – nicht mit dem Ziel, das Original bestmöglichst nachzubauen. Es ist also immer mit Abstraktion verbunden und durch die Wahrnehmung der modellierenden Person(en) geprägt. Zu jedem Modell gehört eine Abbildung, welche die Details des Originals auf diejenigen des Modells abbildet. 5.1.1 Wozu Modelle? Somit: Gedankliches Hilfsmittel zum Gestalten, Bewerten Verwendungszweck oder Kritisieren eines geplanten Systems. Ermöglicht die Durchführung von Experimenten, die am am Original nicht • Verstehen eines Systems • Kommunizieren über ein System • Spezifikation von Anforderungen an ein geplantes durchgeführt werden sollen, können oder dürfen. Gebilde 5.2. Modellbildung Diese Schritte sind beim Vorgehen nötig: 1. Reflektieren: Worum geht es? Was lassen wir weg? Wie 3. Beschreiben: Gewonnene Informationen verstehen, soll das Modell aussehen? 2. Gewinnen: Infos gewinnen über den Sachverhalt ordnen, strukturiertes Modell erstellen: Entitätsmengen, Daten, Beziehungen, . . . (Workshops durchführen in Gruppen der Beteilig- 4. Validieren: Modelle (Zwischenergebnisse und fertiges ten), diskutieren, lesen, fragen, suchen, . . . Modellbildung (3) Modell) in Review-Workshops überprüfen lassen: „Entspricht das Modell dem, was wir wollen und brauchen?“ The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 24 5.3 „3 Sichten“ der Modellierung: Daten-, Prozess- und Funktionssicht 5.3. „3 Sichten“ der Modellierung: Daten-, Prozess- und Funktionssicht 5.3.1 Exkurs: Zweck der IT Zweck der IT Geschäftsprozess Die IT-Abteilung unterstützt die Geschäftsprozesse einer Einkauf Firma mit IT-Applikationen. Diese IT-Applikationen werden Prod. Vertrieb Unterstützt entwickelt und/oder betrieben von der IT-Abteilung und IT-Applikation (IT-Service) unterstützen die Geschäftsprozesse massgeblich. Dabei wird die IT-Abteilung in zwei Sparten aufgeteilt: stellt entwickelt Anforderungen betreibt a) die Entwicklung und b) den Betrieb: a) Entwicklung und Unterhalt von IT-Applikationen im IT-Entwicklung „entwickelt“ Rahmen von Projekten IT-Betrieb „betreibt“ b) Betrieb von IT-Services einer Unternehmung in geübergibt nügender Verfügbarkeit in einer Linienorganisation A. Kurmann SSM: Kapitel 3 5.3.2 4 3 Sichten einer Unternehmung: Daten-, Prozess- und Funktionssicht Sehr gute Einführung: http://www.leed.ch/history/eepk/ > ARIS-Haus Eine Unternehmung besteht typischerweise Sichten aus verschiedenen Sichten (siehe Bild links, vertikale Anordnung). Die Betrachtung aus verschiedenen Modellierung stützt sich dabei immer auf die Betrachtungsweise aus verschiedenen Sichten (weiteres Beispiel Bild rechts: „Architektur integrierter Informations-Systeme (ARIS)“) und deren Ebenen (Bild links, horizontale Schichtung): Prozesse Sichten und Beschreibungsebenen Die Ebene des „Fachlichen Konzepts“ (= formale vonDarstellung ARIS der entsprechenden Sicht) enthält jeweils in der. . . A. Kurmann IM Kapitel 7 23 • Organisationssicht → Organisationsstruktur bzw. einheiten: Organigramme (Strukturen & Beziehungen) • Funktionssicht → Notwendige Funktionen der Geschäftsprozesse und ihre Verbindung (Funktionshierarchiebäume) • Datensicht → Informationsobjekte (Umfelddaten, Ereignisse, Nachrichten): ER-Modellierung (S. 43) • Prozess- / Steuerungssicht → Verknüpfung aller Sichten & Ableitung / Beschreibung von Geschäftsprozessen: eEPK (S. 36) IM Kapitel 7 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz A. Kurmann 28 Seite 25 6. UML (Unified Modeling Language) IM UML ist heute die dominierende Sprache für die Softwaresystem-Modellierung: sie definiert wichtige Begriffe und legt mögliche Beziehungen zwischen diesen fest. Damit werden Arbeitsabläufe (Softwareentwickler) und Installationspläne (Systemingenieure) erstellt. → siehe Übung 8.2: UML 6.1. Ebenen der Modellierung Konzept-Ebene: Analyse / Domain / Requirements • Aktivitäts-Diagramme • DFD, Kontext-Diagramme Architektur-Ebene: Spezifikation • Komponenten, Parts, Ports • Datenfluss Implementations-Ebene: Programmierung • Sequenzdiagramme Abbildung 5: Modellierungsebenen UML-Diagramme sagen sowohl etwas aus über die Struktur („Strukturdiagramme“, linke Hälfte) sowie das Verhal- UML Metamodell: Diagramme ten („Verhaltensdiagramme“ und „Interaktionsdiagramme“, rechte Hälfte) von Software: UML Diagram Structure Diagram Class Diagram Behavior Diagram Component Diagram Object Diagram Composite Structure Diagram Activity Diagram Use Case Diagram Interaction Diagram Package Diagram Deployment Diagram Interaction Overview Diagram Sequence Diagram Communication Diagram IM HS13, Kp 8a State Machine Diagram 9 Timing Diagram M. Jud Abbildung 6: Metamodell von UML The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 26 6.2 Verhaltensdiagramme: Aktivitäten und Zustände 6.2. Verhaltensdiagramme: Aktivitäten und Zustände 6.2.1 Aktivitätsdiagramm Aktivitätsdiagramme modellieren das Verhalten von Systemen. Im Aktivitätsdiagramm werden Folgen von Aktionen (Abläufe), die zusammen eine Aktivität ergeben, dargestellt. Knoten sind durch Objekt- und Kontrollflüsse miteinander verbunden. Dabei unterscheidet man Aktions-, Objekt- und Kontrollknoten: Aktivitätsdiagramm Aktivität Parameter1: Typ Parameter2: Typ «precondition» Vorbedingung «postcondition» Nachbedingung Unterbrechbarer Aktivitätsbereich Signal {weight=5} (Partition B) Schritt 2 [Bed. 1] Eingangsparameter (Partition A) Schritt 1 Objektknoten [Zustand] (Partition A) Schritt 3 «datastore» Objektknoten Signal senden [Bed. 2] (Partition B) Schritt 4 [weiter] Ausgangsparameter [stopp] Schritt 4 Schritt 4.1 A B Schritt 4.3 Schritt 4.2 C {joinSpec = (A and B) or (A and C)} Teilung (Splitting) [x<0] Synchronisation (Und) Teilung und Synchronisation [x>0] Signal senden Zeitereignis empfangen [x<0] [x=0] Schritt 1 Schritt 1 Schritt 1 Objektfluss Oder-Semantik Kontrollfluss Und-Semantik Objektfluss Und-Semantik [x>=0] Entscheidung Reservierungswunsch aufnehmen Signal empfangen Spezifizierte Synchronisation Zusammenführung (Oder) Entscheidung und Zusammenführung Erzeuge Daten Abgebrochene Anfrage Ausnahme-Parameter (Exception) Partition A Partition B «parallel», «iterative» o.Ä. Mengenverarbeitung Reservierungswunsch Startknoten Eintrag {stream} Endknoten Eintrag {stream} Verarbeite Daten Ablaufende Eingangsmenge Einzelobjekt Mengenverarbeitung Einzelobjekt Ausgangsmenge Interaktionsübersicht sd Übersichtsdiagramm lifelines: x:Klasse1, y:Klasse2 Schritt 1 (Partition A) Schritt 1 Schritt 3 ref «datastore» Objektknoten Interaktionsverweis Schritt 2 [Abbruch] (Partition B) Schritt 2 (Partition A) Schritt 3 [ok] sd Interaktion y:Klasse2 x:Klasse1 P1 P2 Aktionsknoten P3 P4 P5 P6 P7 A Schritt 1 A nachricht() Schritt 2 © 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oose.de/uml Abbildung 7: Aktivitätsdiagramm UML-Notationsübersicht Teil 3/4 Signale (vgl. Oestereich, Kap. 2.5.4) erlauben z.B. die Synchronisation paralleler Prozesse. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 27 Unterpaket Komponentendiagramm 6.2 bereitgestellte Schnittstelle «component» Komponente Verhaltensdiagramme: Aktivitäten und Zustände «component» Komponente «component» Komponente genutzte Schnittstelle 6.2.2 «provided Zustandsdiagramm interfaces» Portname Port-B Schnittstelle X :Klasse A [1] Port-A Schnittstelle Multipledie Portsein Objekt im Laufe seines Lebens einnehmen «required interfaces» Ein Zustandsdiagramm zeigt eine Folge von Zuständen, kann und Schnittstelle Y Teil (part) Aktivitätsdiagramm aufgrund welcher Stimuli Zustandsänderungen stattfinden. (Oestereich, 2009) SSt-4 SSt-3 SSt-2 SSt-1 «realizations» 1 Klasse A :Klasse B Zustandsautomaten lassen sich mittels ZustandsdiagrammenAktivität modellieren: die Knoten beschreiben die Zustände (vgl. Klasse B «component» «precondition» Vorbed Nachb «artifact» Parameter1: Typ «artifacts» Komponentedie Zustandsübergänge komponente.jar als «postcondition» Oestereich, Kap. 2.6.1) während Kanten Parameter2: Typ (vgl. Oestereich, Kap. 2.6.2) dargestellt werden. komponente.jar «manifest» Zustandsdiagramme modellieren das dynamische Verhalten eines Systems und konzentrieren sich dabei auf die ReakUnterbrechbarer Aktivitätsbereich tionen dessen. Deshalb eignen sich diese sehr gut zurKommunikationsdiagramm Modellierung des Verhaltens von GUIs. (Kecher, 2011) Zustandsdiagramm Signal (Partition B) {weight=5} Obje [Zu Schritt 2 name {extended} Startzustand Seite 318 1:nachricht1() ereignis[bedingung]/aktion after(n Zeit) [x <= 0] [Bed. 2] fangen werden, finden die entsprechenden Symbole aus den entry/aktion do/aktion exit/aktion ereignis/aktion when(Zeit) :Lebenslinie Aktivitätsdiagrammen Anwendung. (Partition B) Schritt 4 Ausserden können gleich2:nachricht3() dem Aktivitätsdiagramm Entschei1.1:nachricht2() dungsrauten, Splitting und Synchronisation im Zustandsdia[weiter] [stopp] [x > 0] 1.2:nachricht3() gramm verwendet werden: Zustand {final} Sc 4 A abbruch Ausgangspunkt sd Protokollautomat {protocol} Zeitdiagramm Zustand 1 [x<0] [x>0] Zustand Lebenslinie x:Klasse2 [vorbedingung] aufruf() / [nachbedingung] Zustand A [x=0] Zeitbedingung {t..3*t} Teilung und Synchronisation nachricht2() nachricht1() t=now Entscheidung Zustand C Schri [x>=0] Zustandslinie Entscheidung und Zusammenführung (Oder){<10ms} © 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oose.de/uml Mengenverarbeitung Zeitskala UML-Notationsübersicht Teil 2/4Verarbeite Daten Erzeuge Daten Abgebrochene Anfrage Ausnahme-Parameter (Exception) Anwendungsfälle Objek Oder-Se Zusammenführung Abbildung 8: Zustandsdiagramm Reservierungswunsch Sek.: 0 1 2 e Spezifizierte Synchronisation [x<0] nachricht3() Zustand B Reservierungswunsch aufnehmen Sc C {joinSpec = (A and B) or (A and C)} Teilung Synchronisation (Splitting)Zustand 2 (Und) Zustand B Zeitdiagramm Zustand 6.2.3 Schritt 4 y:Klasse2 Endzustand state machine x:Klasse1 start2 H Zustand «datastore» Objektknoten sd Kommunikation (Partition A) EingangsWenn bei einem Zustandsübergang Signale gesendet oder empparameter Schritt 1 Zustand Seite 320 Zustand [Bed. 1] Eingangspunkt y:Klasse1 state machine Eintrag {stream} Eingangsmenge Eintrag {stream} Interaktionsü Partition A Partition B Anwendungsfalldiagramme (Use Case Diagrams) modellieren die Funktionalität eines SystemsEndknoten auf hohem AbstraktiStartknoten Ablaufende onsniveau aus Sicht des Anwenders (Black-Box-Sicht). Die Zusammenhänge zwischen einer Menge von Anwendungsfällen und den beteiligten Akteuren stehen im Zentrum (Oestereich, 2009): es werden nur die Anwendungsfälle definiert, die ein Anwender wahrnehmen kann und deren Schritt Ausführung ihm einen Nutzen bringt. 1 sd Übersichtsdiagra ref «datastore» Die Modellierung beschreibt, was für Anwendungsfälle das System anbietet und nicht, wie(Partition sie imA) SystemObjektknoten realisiert werden: Schritt 1 Schritt 3 Schritt 2 Merke: (Partition B) Schritt 2 (Partition A) Schritt 3 Die Anwendungsfalldiagramme beschreiben kein Verhalten und keine Abläufe. sd x:Kl Die Beschreibung der Anwendungsfälle (vgl. Oestereich, Kap. 2.1.7) ist P3 P4 wichtiger dabei P5 A selbst. Der alsSchritt das1 Diagramm AktionsAkteur (vgl. Oestereich, Kap. 2.1.13) hat eine wichtige Rolle P1 im Anwendungsfall-Diagramm. P2 knoten P6 P7 A Schritt 2 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz © 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oose.de/uml Seite 28 6.3 Strukturdiagramme Use Case Diagramme werden überwiegend während der Analyse und Definition im frühen Stadium eines Softwareprojekts eingesetzt. (Kecher, 2011) Anwendungsfalldiagramm Geschäftsanwendungsfall Anwendungsfall Geschäftsprozess Anwendungsfall Condition: {bedingung} extension point: ext. point ext. point «extend» «include» Abstrakter aktiver Geschäftspartner Systemanwendungsfall Spezialisierter Anwendungsfall Systemanwendungsfall «secondary» Sekundärer Anwendungsfall «secondary» Sekundärer Anwendungsfall «include» Stereotypisierte Klassen Akteur Passiver Geschäftspartner Konkreter aktiver Geschäftspartner Fremdsystem als Akteur Klassendiagramm Außenorientierter Geschäftsmitarbeiter «requirement» Anforderung «feature» EinFeature «include» Innenorientierter Geschäftsmitarbeiter Objektdiagramm «Stereotyp1, Stereotyp2» Abbildung 9: Anwendungsfälle in UML Paket::Klasse attribut Abstrakte Anwendungsfalldiagramm Klasse operation() Klasse Entity Objekt Boundary Control :Klasse Anforderungen (Requirements) werden grundsätzlichGeschäftswie Anwendungsfälle in Form von Ellipsen mit dem «Stereotyp1» Anwendungsfall anwendungsfall attribut = wert Aktive Geschäftsprozess Stereotyp «requirement» notiert. Klasse Anwendungsfall Objekt:Klasse ext. point Syntax für Attribute: Sichtbarkeit Attributname : Paket::Typ [Multiplizität Ordnung] = Initialwert {Eigenschaftswerte} Eigenschaftswerte: {readOnly}, {ordered}, {composite} Syntax für Operationen: Sichtbarkeit Operationsname (Parameterliste):Rückgabetyp {Eigenschaftswerte} attribut = wert Abstrakter aktiver 6.3. Strukturdiagramme Sichtbarkeit: Parameterliste: Richtung Name : Typ = Standardwert Geschäftspartner + public element Eigenschaftswerte: {query} # protected element Richtung: in, out, inout 6.3.1 Klassendiagramm – private element ~ package element «include» Parametrisierte Klasse<Parameter> Aktives Objekt System- i:Element Parametrisieranwendungsfall bare Klasse Systemanwendungsfall Spezialisierter Anwendungsfall Objekt «secondary» Sekundärer Anwendungsfall Ein Klassendiagramm (Class Diagram) beinhaltet die statischen Strukturbestandteile eines Systems, deren Eigen«include» schaften und Beziehungen. 2011) Vererbung Es fungiert als eine Art Bauplan für Objekte. (Kecher, Attributierte Assoziation Klasse1 Klasse1 Klasse2 Klasse2 Es gibt eine allgemeine Notation für Klassen (vgl. Oestereich, Kap. 2.2.1) und für spezielle Arten von Klassen wie Generics Stereotypisierte Akteur (vgl. Oestereich, Kap. 2.2.2), abstrakte Klassen (vgl. Oestereich, Kap. 2.2.3)Klassen und sog. aktive Klassen (vgl. Oestereich, Kap. «requirement» Passiver AssoziationsAnforderung Geschäftspartner klasse 2.2.4), die in einem Assoziation eigenen Thread laufen. Auch Enumerationen (vgl. Oestereich, Kap. 2.2.9) und Schnittstellen (vgl. OesteKlasse1 Klasse2 aktiver mit Klassendiagrammen dargestellt werden. Ein mächtiges Konzept der UML sind Stereotypen reich, Kap. Konkreter 2.2.10) können Geschäftspartner Fremdsystem Außenorientierter Innenorientierter als Akteur (vgl. Oestereich, Kap. 2.2.12) wie Entity, Control, Boundary. Geschäftsmitarbeiter Geschäftsmitarbeiter Aggregation Klasse1 gerichtete Assoziation Klassendiagramm Klasse2 «Stereotyp1, Stereotyp2» Paket::Klasse qualifizierte Assoziation Klasse1 Klasse2 Qualifizierer Abstrakte Klasse Klasse Klasse1 Realisierung Klasse2 Teil Ganzes Komposition attribut operation() Klasse1 «Stereotyp1» attribut = wert Obje Existenzabhängiges Teil Mehrgliedrige Entity Assoziation Control «inclu Boundary O Klasse2 Aktive Klasse Klasse3 Syntax für Attribute: UnabAbhängigkeit Abhängige hängige Sichtbarkeit Attributname : Paket::Typ [Multiplizität Ordnung] = Initialwert {Eigenschaftswerte} Klasse Klasse Eigenschaftswerte: {readOnly}, {ordered}, {composite} Multiplizität Syntax für Operationen: SichtbarkeitSchnittstelle Operationsname (Parameterliste):Rückgabetyp {Eigenschaftswerte} «Stereotyp» Anbieter Sichtbarkeit: + public element # protected element – private element "Stecker" ~ package element bereitgestellte Schnittstelle genutzte Schnittstelle "Buchse" Klasse1 Nutzer 1 Parametrisierte Klasse<Parameter> Leserichtung Beziehungsname Parameterliste: Richtung NameKlasse1 : Typ = Standardwert rolle Eigenschaftswerte: {query} Richtung: in, out, inout Anbieter «interface» Schnittstelle-A Klasse Vererbung Nutzer «interface» Schnittstelle-A Klasse2 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz © 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oose.de/uml * {ordered} Sichtbarkeit rolle A O Klasse2 i:Element Parametrisierbare Klasse «interface» Schnittstelle operation1() operation2() Klasse1 Notiz Attributierte Assoziation Seite 29 UML-Notationsübersicht Teil 1/4 Assoziations- «extend» «include» 6.3 er fall «secondary» Sekundärer «secondary» Anwendungsfall Sekundärer Anwendungsfall include» 6.3.2 Objektdiagramm Strukturdiagramme Wenn exemplarisch die Beziehungen zwischen einzelnen Objekten (statt allgemein zwischen den zu Grunde liegen«requirement» «feature» den Klassen) modelliert werden sollen, helfen Objektdiagramme (vgl. Oestereich, Kap. 2.4.1): ein Objektdiagramm (ObAnforderung EinFeature «include» ject Diagram) stellt eine Momentaufnahme der Objekte eines Systems dar, die nach dem Bauplan eines Klassendiagramms gebildet wurden. (Kecher, 2011) Objektdiagramm Objekt Boundary :Klasse ive sse Objekt:Klasse attribut = wert sierte ameter> Aktives Objekt i:Element trisierlasse Objekt Abbildung 10: Objektdiagramm Attributierte Assoziation 6.3.3 Klasse2 Komponentendiagramm AssoziationsEine Komponente ist eine spezielle Klasse, die eine austauschbare Einheit in einem System repräsentiert, deren Bestandteile klasse gekapselt sind. Die Funktionalität wird über Schnittstellen nach aussen zur Verfügung gestellt. (Oestereich, 2009) Komponentendiagramme eignen sich besonders für die Spezifikation von Softwarearchitekturen (Black-Box-Sicht). In der Phase des Entwurfs und Designs werden u.a. die Aufgaben grosser Softwaresysteme auf kleinere Subsysteme Aggregation Teil verteilt: Systeme, Subsysteme und deren Komponenten, d.h. die Laufzeitsicht, lassen sich hierarchisch mittels Kom- Komposition ponentendiagrammen (vgl. Oestereich, Kap. 2.4.2 / 2.4.3) beschreiben. Das Diagramm zeigt die Organisation und ExistenzAbhängigkeitenabhängiges der Komponenten und wird häufig parallel zu Verteilungsdiagrammen (siehe Kapitel 6.3.5) eingesetzt Teil (Kecher, 2011). Die linke Abbildung zeigt ein Beispiel für zwei Komponenten und von welchen Klassen sie realisiert werden: Mehrgliedrige Assoziation Klasse2 Klasse3 lizität Leserichtung «Stereotyp» Beziehungsname * {ordered} Sichtbarkeit rolle Klasse2 Eine Komponente wird als Rechteck notiert mit dem Schlüsselwort «component». Zusätzlich kann im rechten Bereich ein „Lego-Symbol“ eingezeichnet werden. «interface» Schnittstelle Notiz operation1() operation2() The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz UML-Notationsübersicht Seite 30 6.4 6.3.4 Interaktionsdiagramme Paketdiagramm Klassen, Anwendungsfälle und andere Modellelemente der Entwicklungssicht lassen sich hierarchisch in Paketdiagrammen (vgl. Oestereich, Kap. 2.4.4) zusammenfassen. Paketdiagramm Paket 1 Einsatz- un «merge» Paket 2 Paket Paket 1 Paket 1 «import» Paket 2 «access» Enthaltenes Unterpaket «database» Datenbank-Server «execut rdbms «artifact» Artefakt Paket 2 Paket «deployment specification» Deployment Spezifikation Enthaltenes Unterpaket Komponentendiagramm Abbildung 11: Paketdiagramm bereitgestellte Schnittstelle «component» Komponente 6.3.5 genutzte Schnittstelle Einsatz- und Verteilungsdiagramm (Deployment) «provided interfaces» Schnittstelle X «compone Kompone «component» Komponente Port-B :Klasse A [1] Wie die Komponenten eines Softwaresystems auf die Hardware verteiltPort-A werden kann mittels eines Deployment Multiple Ports «required interfaces» Diagramms (vgl. Oestereich, Kap. 2.4.6) beschrieben werden. Sie zeigen, welche Software (Komponenten, Objekte) Schnittstelle Y Teil (part) SSt-4 SSt-3 SSt-2 bestehen. SSt-1 auf welcher Hardware (Knoten)«realizations» laufen und welche Kommunikationsbeziehungen dort So definiert ein VerEinsatzund Verteilungsdiagramm aket 1 Klasse A «merge» Paket 2 also die Architektur teilungsdiagramm Klasse Beines verteilten Systems, wie sie zur Laufzeit vorgefunden wird. «component» Komponente «artifacts» komponente.jar aket 1 aket 1 «import» Paket 2 «access» «manifest» Client {OS = Windows XP} «database» Zustandsdiagramm Datenbank-Server myClientPrg.exe «executable» rdbms.exe «artifact» Artefakt Paket 2 state machine name {extended} Eingangspunkt1 Startzustand Paket «deployment specification» Deployment SpezifikationSeite 320 ereignis[bedingung]/aktion Zustand Seite 318 «artifact» komponente.jar after(n Zeit) Kommunikationsdiagramm 5 http/LAN sd «deploy» Kommunikation 1:nachricht1() Zustand :Lebenslinie «artifact» entry/aktion do/aktionArtefakt exit/aktion ereignis/aktion 2:nachricht3() when(Zeit) Abbildung 12: Deploymentdiagramm m gestellte nittstelle genutzte nittstelle [x <= 0] [x > 0] start2 umfasst auch Hardware und KommunikatiDie Definition beschränkt sich nicht auf Software-Umgebungen, sondern H onswege (Kecher, 2011). «component» Komponente 6.4. Interaktionsdiagramme Port-B 6.4.1 Zustand «component» Zustand Komponente {final} abbruch Endzustand :Klasse A [1] Port-A Multiple Ports Sequenzdiagramm Teil (part) Die Interaktion verschieden SSt-4 SSt-3 SSt-2zwischen SSt-1 Zustand Objekten Portname Zeitdiagramm Schnittstelle Ausgangspunkt sd Zeitdiagramm oder Rollen kann ablauffokussiert durch ein Sequenzdiagramm 1 ded} Objekten betont,«artifact» jedoch keine Informationen über Beziehungen der Objekte (Kecher, 2011). «manifest» komponente.jar state machine Protokollautomat {protocol} Zustand 1 nachricht2 Zustand Kommunikationsdiagramm [vorbedingung] aufruf() / [nachbedingung] The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Eingangs- Zustand Lebenslinie x:Klasse2 «component» Komponente y:Klasse1 (vgl. Oestereich, Kap. 2.7.2) modelliert werden. Dabei wird der zeitliche Ablauf des Nachrichtenflusses zwischen den Zustand 2 :Klasse B Zustand A Zustand B Zustand C nachricht1() Seite 31 t=now {<1 6.4 Interaktionsdiagramme Sequenzdiagramm sd Interaktion i:Integer sd x:Klasse1 Interaktion +lokalesAttribut:Typ z:Klasse3 ref Detailinteraktion y:Klasse2 x:Klasse1 nachricht() alt [i>0] y:Klas sync. Nachricht nachricht1() Antwort Zustand async. Nachricht [else] {i == 0} Lebenslinie nachricht2() Interaktionsverweis ref sd Zeitliche Zusicherungen x:Klasse1 Interaktionsverweis y:K Ausführung nachricht1() d=duration nachricht3() nachricht2() {0..12} t=now Selbstaufruf create {t..2*t} :KlasseX ObjektKonstruktion nachricht3() ObjektDestruktion Kompositionsstrukturdiagramm gerichtete Pfeile Nachricht bzw. Antwort, siehe dazu Abbildung 13 auf Seite 33 Observer Ausführungsbalken vertikaler Balken (→ Ausführung) gibt an, welche Rolle gerade aktiv ist Auto Lokale Attribute z.B. Schleifenzähler o.A. können oben links im Diagramm deklariert werden subject :Queue Erzeugen und Entfernen Erzeugen (Objektkonstruktion) durch eine Nachricht, die auf ein Rollensymbol trifft, angezeigt; vorne:Rad observe :scrollb Entfernen (Objektdestruktion) durch ein Kreuz am Ende des Steuerungsfokus. Zustände besagen, dass sich das Objekt zu diesem Zeitpunkt in dem genannten Zustand befindet antrieb Alternative Abläufe Es existieren vordefinierte Operatoren, beispielsweise alt, um alternative Abläufe und m :verschiedene Motor hinten:Rad /Rolle:Klasse Verzweigungen auszudrücken: Bedeutung Unified Modeling Language (UML) 2.1 - Notationsübersicht Operator Bed./Param. alt [bed. 1], [bed. 2], [sonst] «Stereotyp1, Stereotyp2» Paket::Klasse loop «interface» Schnittstelle minint, maxint, [bed.] Boundary «Stereotyp1» attribut = wert Abstrakte Klasse {abstract} Control Der Block wird als Schleife wiederholt für mind. minint-mal, Notiz Entity Kern-Geschäftsanwendungsfall i:Element Parametrisierbare Klasse Aktive Klasse Syntax für Attribute: Sichtbarkeit Attributname : Paket::Typ [Multiplizität Ordnung] = Initialwert {Eigenschaftswerte} Eigenschaftswerte: {readOnly}, {ordered}, {composite} Parametrisierte Klasse<Parameter> Multiplizität Leserichtung «Stereotyp» Beziehungsname 1 Klasse1 Multiplizität Ordnung * {ordered} «interface» Schnittstelle-A Anbieter «interface» Schnittstelle-A «business process» Geschäftsprozess (unterstützender ) Geschäftsprozess «derive» «derive» Schnittstelle-A Klasse2 Anbieter Abstrakter aktiver Geschäftspartner Systemanwendungsfall Spezialisierter Anwendungsfall nicht-navigierbares Assoziationsende Klasse1 Komposition Existenzabhängiges Teil Mehrgliedrige Assoziation Klasse1 Realisierung Klasse1 Klasse2 Stereotypisierte Klassen oose. oose Innovative Informatik GmbH, Straßenbahnring 7, 20251 Hamburg. Merke: Unterklasse2 Unterklasse3 Unterklasse5 Aktivität Parameter1: Typ Parameter2: Typ «precondition» Vorbedingung «postcondition» Nachbedingung Sponsoren Signal Eingangsparameter Paketdiagramm {weight=5} (Partition B) Schritt 2 :Klasse attribut = wert Unter www.o gibt es den U Enthaltenes Unterpaket Paket Startknoten (Partition A) Schritt 1 Objektknoten [Zustand] Endknoten Ablaufende (Partition A) Schritt 3 Signal empfangen «datastore» Objektknoten Signal senden [Bed. 2] Paket Objekt:Klasse {d..3*d} nachricht3() Unterbrechbarer Aktivitätsbereich Unterklasse6 [Bed. 1] Objektdiagramm y:Klasse2 nachricht2() {0..12} {t..2*t} :KlasseX Aktivitätsdiagramm Noch komprimierter ist unsere UML-Notationsübersicht auf einem Becher. Auch diesen können Sie bei uns bestellen: www.oose.de/becher Unter www.o können Sie n stehendes U beziehen. nachricht1() d=duration t=now create Sie können dieses Poster bei uns bestellen: www.oose.de/poster Diskriminator 3 Unterklasse1 x:Klasse1 nachricht3() Systemanwendungsfall «include» sd Zeitliche Zusicherungen Interaktionsverweis Wir unterstützen Sie mit Schulungen, Coaching, Beratung und Projektarbeit in den Bereichen Geschäftsprozesse, Analyse, Design, Architektur, Projektmanagement, Java/J2EE-Technologien, SystemsEngineering, Testen/Qualitätssicherung, Organisationsentwicklung, Soft-Skills und OO-Grundlagen. Generalisierung Diskriminator 1 Klasse2 Assoziationsklasse «include» Fremdsystem als Akteur Unterklasse4 Klasse1 nachricht2() ref «feature» EinFeature Innenorientierter Geschäftsmitarbeiter «requirement» Anforderung Innovative Informatik OberklasseB Diskriminator 2 OberklasseA y:Klasse2 Antwort async. Nachricht Klasse2 Qualifizierer Klasse2 Klasse3 «secondary» Sekundärer Anwendungsfall [else] {i == 0} Außenorientierter Geschäftsmitarbeiter Passiver Geschäftspartner Teil Ganzes x:Klasse1 nachricht1() Zustand «secondary» Sekundärer Anwendungsfall dieser Stelle eingebunden wird Nutzer Aggregation Klasse2 z:Klasse3 ref Detailinteraktion y:Klasse2 sync. Nachricht [i>0] Geschäftsentität Geschäftsanwendungsfall qualifizierte Assoziation Klasse1 Interaktion +lokalesAttribut:Typ x:Klasse1 alt «extend» Ausführung Klasse1 sd nachricht() ext. point «include» Unabhängige Klasse Abhängigkeit Abhängige Klasse Interaktion i:Integer Condition: {bedingung} extension point: ext. point Anwendungsfall Akteur Systemanwendungsfall Konkreter aktiver Geschäftspartner navigierbares Assoziationsende sd Dies ist ein Verweis auf ein weiteres Sequenzdiagramm, das an Klasse2 Sichtbarkeit rolle rolle Nutzer Klasse KernGeschäftsprozess Lebenslinie ref bereitgestellte Schnittstelle genutzte Schnittstelle Parameterliste: Richtung Name : Typ = Standardwert Eigenschaftswerte: {query} Richtung: in, out, inout «core business process» Kern-Geschäftsprozess aber maximal maxint-mal, falls die Bedingung [bed.] wahr ist Syntax für Operationen: Sichtbarkeit Operationsname (Parameterliste):Rückgabetyp {Eigenschaftswerte} Sichtbarkeit: + public element # protected element – private element ~ package element Sequenzdiagramm Anwendungsfall operation1() operation2() attribut operation() Anwendungsfalldiagramm Abstrakte Klasse Klasse UML 2.1 Verzweigung zu mehreren Möglichkeiten Klassendiagramm (Partition B) Schritt 4 Einer der führenden Fachverlage auf den Gebieten Mathematik, Informatik, Naturwissenschaften und Technik. Signal senden Ausgangsparameter Wenn eine Vielzahl der Ablaufmöglichkeiten ausgedrückt werden möchte, so verwendet man besser ein Aktivitäts[weiter] [stopp] Schritt 4 www.oldenbourg.de Enthaltenes Unterpaket Aktives Objekt Schritt 4.1 Objekt Objektverbindung (Link) Objekt1 «merge» Paket 1 Paket 2 Objekt2 Komponentendiagramm «import» Paket 1 1:nachricht1() :Klasse B hinten:Rad 1.1:nachricht2() state machine name {extended} ereignis[bedingung]/aktion Zustand [x <= 0] Übersichtsdiagramm H bereitgestellte Schnittstelle entry/verhalten do/verhalten exit/verhalten ereignis/verhalten «component» Komponente «manifest» [x<0] [x>0] observer :scrollbar [x>=0] Entscheidung Zeitdiagramm Einsatz- und Verteilungsdiagramm interaction Zeitdiagramm Zusammenführung (Oder) Schritt 1 Schritt 1 Schritt 1 «database» Datenbank-Server Zustand 2 Objektfluss Oder-Semantik Kontrollfluss Und-Semantik Objektfluss Und-Semantik «executable» rdbms.exe «artifact» Artefakt Zustand 1 Partition A Zustand Lebenslinie x:Klasse2 Zustand Reservierungswunsch aufnehmen Zustand A t=now http/LAN {<10ms} 1 Schritt 3 Eintrag {stream} Stream Eintrag Eintrag Verarbeite Daten Verarbeite Daten Ausnahme Schritt P1 P2 Aktionsknoten Schritt 2 (Partition B) Schritt 2 Schritt (Partition A) Schritt 3 Ausnahmebehandlung P3 P4 P5 P6 P7 Mengenverarbeitung «parallel», «iterative», «stream» 5 Client Zeitskala Eintrag {stream} Schritt 1 «deployment specification» Deployment Spezifikation Zustandslinie nachricht() Sek.: 0 1 2 Reservierungswunsch Abgebrochene Anfrage Ausnahme-Parameter (Exception) (Partition A) Schritt 1 nachricht3() nachricht1() Zustand B Zustand C Schritt 2 Objektfluß Schritt 2 Erzeuge Daten Partition B nachricht2() Protokollautomat {protocol} [vorbedingung] aufruf() / [nachbedingung] A Entscheidung und Zusammenführung Zeitbedingung {t..3*t} y:Klasse1 Zustand Schritt 2 Objekt [Zustand] Schritt 1 Erzeuge Daten SSt-2 SSt-1 [ok] state machine A [x<0] [x=0] subject :Queue «artifact» komponente.jar abbruch [Abbruch] Objekt [Zustand] Port-B SSt-4 SSt-3 Endzustand Schritt 2 Objekt [Zustand] Schritt 1 Port-A at(Zeitpunkt) Ausgangpunkt y:Klasse2 «datastore» Objektknoten Spezifizierte Synchronisation Schritt 1 «component» Komponente genutzte Schnittstelle [x > 0] Zustand {final} Interaktionsverweis Interaktion Teilung und Synchronisation start2 Geerbter Zustand interaction Übersichtsdiagramm lifelines: x:Klasse1, y:Klasse2 Synchronisation (Und) 1 Observer Eingangspunkt Zustand after(n Zeit) x:Klasse1 Teilung (Splitting) 2 /Rolle:Klasse Startzustand y:Klasse2 {joinSpec = (A and B) or (A and C)} 2 «artifacts» komponente.jar Zustandsdiagramm 1.2:nachricht3() sd antrieb m : Motor x:Klasse1 2:nachricht3() ref Schnittstelle Teil (part) «realizations» Klasse A Klasse B C Schritt 1 vorne:Rad :Klasse A [1] «required interfaces» Schnittstelle Y B Auto Portname «provided interfaces» Schnittstelle X Paket 2 interaction Kommunikation :Lebenslinie «component» Komponente «component» Komponente Paket 2 «access» Paket 1 Zeitereignis empfangen Kompositionsstrukturdiagramm A Kommunikationsdiagramm Schritt 4.3 Schritt 4.2 diagramm, ansonsten eine unübersichtliche, mehrfach verschachtelte Darstellung resultiert. «deploy» «artifact» Artefakt Eingangsmenge Einzelobjekt Mengenverarbeitung Einzelobjekt Ausgangsmenge myClientPrg.exe © Copyright 2006 by oose Innovative Informatik GmbH, Hamburg; Bezug dieses Posters über www.oose.de/poster Erfahrung nutzen, Ziele erreichen. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz © 2006 by oose.de GmbH Aktuelle Fassung, Info und Download: http://www.oose.de/uml oose. oose. Seite 32 Innovative Informatik Innovative Informatik UML 6.5 Beziehungen Observer: Definiert eine Abhängigkeit zwischen einem Objekt (ConcreteObject), dessen Beispiel: Observer-Pattern Status ändern kann (setState()), und einer Menge von Objekten (ConcreteObserver, ConcreteObserver2), die darüber informiert werden sollen: Paketdiagramm Paket 1 «merge» Einsatz- und Verteilungsdiagramm Paket 2 Paket Paket 1 Paket 1 «import» «access» Paket 2 Client {OS = Windows XP} «database» Datenbank-Server myClientPrg.exe «executable» rdbms.exe «artifact» Artefakt Paket 2 5 http/LAN 1 Enthaltenes Unterpaket Paket «deploy» «deployment specification» Deployment Spezifikation «artifact» Artefakt Enthaltenes Unterpaket Seite 7 Komponentendiagramm 6.4.2 «component» Kommunikationsdiagramm Komponente bereitgestellte Schnittstelle «component» Komponente «component» Komponente Die folgende Tabelle stellt die wichtigsten Elemente dergenutzte Sequenzdiagramme dar: Portname Schnittstelle Port-B kann rollenfokussiert durch ein Kommunikations«provided interfaces» Die Interaktion zwischen verschiedenen Objekten oder Rollen Schnittstelle X grafisches Element Bedeutung :Klasse A [1] Port-A Multiple Ports diagramm (vgl. Oestereich, Kap. 2.7.1) modelliert werden. Im Gegensatz zum Sequenzdiagramm setzt es den Fokus Schnittstelle auf «required interfaces» Schnittstelle Y Teil (part) die Kommunikationsbeziehungen der Objekte SSt-4 während einer Interaktion (Kecher, 2011). SSt-3 SSt-2 SSt-1 Eine «realizations» Lifeline: Klasse A Kommunikation zwischen bspw. Prozessen kann synchron oder asynchron Klasse B hiermit wird ein Teilnehmer an der Kommunikation «component» «artifact» «artifacts» beschrieben; Komponente komponente.jar komponente.jar «manifest» das kann ein Akteur, ein Objekt, ein String, ein Rechner, etc. kom1 1 :Klasse B ablaufen: • Bei synchronem Austausch müssen alle Partner zur gleichen Zeit an der Kommunikation teilnehmen. Beispiel: „Telefon“. sein Zustandsdiagramm Kommunikationsdiagramm • asynchrone Kommunikation erfolgt zeitversetzt. Beispiel: „E-Mail“. Ausführungssequenz (execution specification); state machine name {extended} Eingangszeigt an, dass der entsprechende Kommunikationspartner punkt aktivStartzustand ist; sd 1:nachricht1() aktiv ist er auch, wenn er auf eine Antwort wartet oder eine Zustand Seitenimmt 320 Nachricht entgegen Zustand synchrone Nachricht asynchrone Nachricht Antwort ereignis[bedingung]/aktion eine synchrone Nachricht: Seite 318 die Pfeilspitze after(n Zeit) ist ausgefüllt; when(Zeit) Kommunikation :Lebenslinie entry/aktion do/aktion exit/aktion ereignis/aktion x:Klasse1 1.1:nachricht2() 2:nachricht3() ein Methodenaufruf ist eine spezielle synchrone Nachricht <= 0] [x > 0] eine asynchrone [x Nachricht: die Pfeilspitze ist nicht ausgefüllt start2 H eine Antwortnachricht resultierend aus einem Methodenaufruf: Zustand die Linie ist gestrichelt; {final} die Darstellung von Antworten ist optional abbruch 1.2:nachricht3() y:Klasse2 Zustand Tab. 1. UML Elemente für Sequenzdiagramme Endzustand Abbildung 13: Kommunikationsdiagramm Zeitdiagramm 6.5. Beziehungen y:Klasse1 Das folgende Beispiel zeigt ein Kalkulationsobjekt, welches zwei synchrone Anfragen an ein Ausgangspunkt sd Datenbankobjekt schickt. Synchron sind diese Anfragen, weil die Kalkulation erst nach Erhalt der Zustand Nachricht fortgeführt werden kann. Am Ende der Kalkulation schickt das Objekt eine asynchrone Nachricht an ein Print Objekt. Diese Warteschlange des Objekts (diese kann auch von z.B. der Middleware für das Objekt zur Verfügung gestellt werden) speichert die Nachricht ab. Irgendwann wird das Print Objekt die Nachricht abholen undProtokollautomat den (print) Job ausführen. state machine {protocol} Zeitdiagramm Zeitbedingung {t..3*t} Zustand 2 Zustand 1 Zwischen den in einem UML Diagramm dargestellten Knoten (z.B. Klassen) kann es verschieden geartete Beziehungen nachricht2() geben: So lassen sich die Konzepte der Generalisierung bzw. Spezialisierung (vgl. Oestereich, Kap. 2.3.1) darstellen. Zustand Zustand nachricht3() Zustand A Lebenslinie x:Klasse2 [vorbedingung] aufruf()ist / die Assoziation (vgl. Oestereich, Kap. nachricht1() Die allgemeine Beziehung zwischen Klassen 2.3.2), die sich auch konkreter als [nachbedingung] Zustand B gerichtete Assoziation (vgl. Oestereich, Kap. 2.3.3), als Aggregation (vgl. Oestereich, Kap. 2.3.7) oder als Komposition (vgl. t=now Zustandslinie Oestereich, Kap. 2.3.8) modellieren lässt. Zustand C Sek.: 0 1 2 The Software Bakery©· 2006 Tobiasby Maestrini, oose.de Bruno GmbH Leupi, Marcel Burri, Ralph Kyburz Aktuelle Fassung, Info und Download: http://www.oose.de/uml {<10ms} Zeitskala Seite 33 UML-Notationsübersicht Teil 2/4 anwendungsfall Anwendungsfall anwendungsfall Sekundärer Anwendungsfall «secondary» Sekundärer Anwendungsfall «include» Passiver Geschäftspartner Konkreter aktiver Geschäftspartner Fremdsystem als Akteur Klassendiagramm Außenorientierter Geschäftsmitarbeiter «requirement» Anforderung attribut operation() «Stereotyp1» attribut = wert Entity Vererbung Assoziation Klasse1 Klasse1 gerichtete Assoziation Control Objekt Boundary Objekt:Klasse attribut = wert Parametrisierte Klasse<Parameter> Aktives Objekt i:Element Parametrisierbare Klasse Attributierte Assoziation Klasse1 Klasse2 Assoziationsklasse Klasse2 Aggregation Klasse2 Teil Ganzes Existenzabhängiges Teil qualifizierte Assoziation Qualifizierer Objekt Klasse2 Komposition Klasse1 :Klasse Aktive Klasse Parameterliste: Richtung Name : Typ = Standardwert Eigenschaftswerte: {query} Richtung: in, out, inout Klasse1 «include» Objektdiagramm Syntax für Attribute: Sichtbarkeit Attributname : Paket::Typ [Multiplizität Ordnung] = Initialwert {Eigenschaftswerte} Eigenschaftswerte: {readOnly}, {ordered}, {composite} Syntax für Operationen: Sichtbarkeit Operationsname (Parameterliste):Rückgabetyp {Eigenschaftswerte} Sichtbarkeit: + public element # protected element – private element ~ package element Beziehungen «feature» EinFeature Innenorientierter Geschäftsmitarbeiter «Stereotyp1, Stereotyp2» Paket::Klasse Abstrakte Klasse Klasse 6.5 Stereotypisierte Klassen Akteur Klasse2 Mehrgliedrige Assoziation Realisierung Klasse1 Klasse1 Klasse2 Klasse2 Klasse3 Abhängigkeit Abhängige Klasse Unabhängige Klasse Multiplizität Schnittstelle Anbieter "Stecker" bereitgestellte Schnittstelle genutzte Schnittstelle "Buchse" Nutzer Anbieter Klasse1 1 «interface» Schnittstelle-A «interface» Schnittstelle-A © 2006 by oose.de GmbH Abbildung 14: Assoziationen Aktuelle Fassung, Info und Download: http://www.oose.de/uml The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz * {ordered} Sichtbarkeit rolle rolle Klasse Nutzer Leserichtung «Stereotyp» Beziehungsname «interface» Schnittstelle operation1() operation2() Klasse2 Notiz UML-Notationsübersicht Teil 1/4 Seite 34 7. Prozess-Modellierung IM 7.1. Einführung in Geschäftsprozesse Betrieb = Einheit von zusammenwirkenden Personen und Produktionsmitteln zum Hervorbringen von Gütern und Leistungen. • zum Hervorbringen von Gütern und Dienstleistungen (Output) aus Eingangsmaterialien (Input) • für Dritte • mit dem Zweck der Erzielung eines Gewinns. Geschäftsprozesse in Unternehmen • Darstellung von Prozessen ... Definition 7: Geschäftsprozess Input Verarbeitung Output Ein Geschäftsprozess ist ein Ablauf von Aktivitäten, die der Erzeugung eines Produktes/einer Dienstleistung dienen. Er wird durch ein oder mehrere Ereignisse gestartet und durch ein oder mehrere Er- ... und Prozessketten eignisse abgeschlossen. Es liegt eine Organisationsstruktur zu Grunde. Definition eines Prozesses 1 A. Kurmann IM Kapitel 8 13 → siehe Übung 9.2: Tante Emma-Laden Ein von Prozess ist ein allgemeiner Ablauf mehrerer Schritte, 7.2. Modellierung Prozessen bei denen es sich um Aufgaben, Ausführungen, Arbeitsschritte oder Ähnliches handeln kann. Zwischen Definition 8: Prozess diesen Prozessabschnitten bestehen bestimmte Abhängigkeiten. Ein Prozess ist ein allgemeiner Ablauf mehrerer Schritte, bei denen es sich um Aufgaben, Ausführungen, Arbeitsschritte oder Ähnliches handeln kann. Zwischen diesen Prozessabschnitten bestehen bestimmte Abhängigkeiten. Beispiel: Urlaubsbeantragung Beispiel: IM Kapitel 8 Abbildung 15: Beispiel einer Urlaubsbeantragung (Prozess) A. Kurmann 25 Falls möglich sollten die einzelnen Prozess-Aktivitäten (Synonym: Funktion, Prozessschritt) parallelisiert werden. Damit spart man Zeit. Ein typischer Prozess umfasst: • • • • • Startereignis (Auslöser) – auch mehrere Aktivität(en) Sequenz Parallelität Abschlussereignis(se) – auch mehrere The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 35 7.3 Sprachen für die Prozessmodellierung: Beispiel EPK 7.3. Sprachen für die Prozessmodellierung: Beispiel EPK Ereignisgesteuerte Prozessketten (EPK) 7.3.1 Ereignisgesteuerte Prozessketten (EPK) Siehe Link: http://www.leed.ch/history/eepk/ Merke: Grundprinzip: auf eine Funktion folgt IMMER ein Ereignis – oder auf ein Ereignis IMMER eine Funktion! Hinweis: Wir unterscheiden für unsere Arbeit keine durch- Ereignisgesteuerte Prozessketten - Notation Antrag gestellt IM Kapitel 8 Antrag bearbeiten A. Kurmann Ereignis: Anfang oder Schlussereignis, Zwischenereignis Zustand des Prozess verändert sich gezogenen und gestrichelten Pfeile. 29 Funktion: Aktivität oder Prozessschritt Steuerfluss / Datenfluss: definiert Abhängigkeit zwischen Ereignissen und Funktionen V Konnektoren: Verzweigung oder Zusammenführung von Steuerflüssen UND V ODER X Exlusives ODER (XOR) IM Kapitel 8 A. Kurmann 30 → siehe Übung 9.4a: Urlaubsantrag 2.4.4 Verbotene Beziehungen Die beiden folgenden Verknüpfungen sind nicht erlaubt. Konnektoren 7.3.2 Beschreibung der verschiedenen Konnektoren 7.3.3 Verbotene Beziehungen Begründung: Von einem Ereignis läuft der Kontrollfluss zu mindestens zwei Funktionen. Welche Funktion ausgewählt wird, hängt von einem Entscheidungsprozess ab. Ein Ereignis kann aber keine Entscheidungen treffen ist eine Funktion! DieEntscheidung beiden treffen. folgenden Verknüpfungen sind generell bei (e)EPK nicht erlaubt: Ereignis 1 Ereignis 1 XOR Funktion 1 Funktion 2 Funktion 1 Funktion 2 Die ODER- / Exklusives ODER-Verzweigung funktioniert analog. Bei der ODER-Verzweigung können mind. 1, max. alle Ereignisse eintreffen. IM Kapitel 8 Begründung: Von einem Ereignis läuft der Kontrollfluss zu mindestens zwei Funktionen. Welche Funktion ausgewählt A. Kurmann 33 wird, hängt von einem Entscheidungsprozess ab. Merke: Ein Ereignis kann aber keine Entscheidung treffen – Entscheidungen treffen ist eine Funktion! The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 36 Erweiterte EPKs (eEPK) 7.4 Erweiterte EPK (eEPK): Rollen und Informationsobjekte 7.4. Erweiterte EPK (eEPK): Rollen und Informationsobjekte Um entsprechende Rollen und Informationsobjekte einer bestimmten Funktion zuordnen zu können, hält die erweiterte EPK (eEPK) die obige Notation bereit. IM Kapitel 8 A. Kurmann 36 → siehe Übung 9.4b: Kreditvergabe → siehe Übung 9.5: Bestellung ab Lager The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 37 8. Funktionsmodellierung IM 8.1. Objektorientierte Funktionsmodellierung: CRC-Karten Die CRC-Karten-Methode (CRC = Class – Responsibility – Collaboration) hilft bei der objektorientierten Funktionsmodellierung. Dabei identifiziert man zuerst alle Nomen und Verben in der Aufgabenstellung (bspw. mit der Verben/Nomen Methode). Anschliessend werden alle Nomen – die Klassen – auf eigene CRC-Karten geschrieben. Gleich darunter notiert man die Verantwortungen (Verben) dieser Karte und die Beziehungen zu anderen Karten. Nun spielt man alle erdenklichen Szenarios (Use Cases) durch und prüft ob alle Verantwortlichkeiten und Zusammenhänge notiert sind. Ist dies nicht der Fall, sollten diese ergänzt werden. Wichtig ist, dass man nicht von vornherein versucht Karten wegzulassen. Es kann sein, dass zusätzliche Karten beim Spiel hinzukommen. Beispiel einer CRC-Karte. Auf der Rückseite finden eine Die fertigen CRC-Karten können dann mehr oder weni- kurze Beschreibung dieser Karte sowie die enthaltenen Atger direkt als Klassen implementiert werden. tribute Platz. 8.2. Grundlagen der Dekomposition Die Grundidee der Funktionsmodellierung ist die Reduktion der Komplexität eines Informationssystems. Dies geschieht vortrefflich durch die Zerlegung dessen in einzelne, abgegrenzte Teileinheiten. Definition 9: Informationsmodell eines Software-Systems Ein Informationsmodell veranschaulicht das Software-System mit seinen Objekten sowie den Fluss der Informationen dazwischen. 8.2.1 Das Funktionsmodell Definition 10: Funktionsmodell eines Software-Systems Stellt das System dar als zusammengesetzte Bausteine, die eine klar eingrenzbare und beschriebene Funktionalität (Aktionen und Veränderungen der Daten) abdecken. Dies sind auf der Ebene der Systemarchitektur die Software-Systeme: • Subsysteme • Komponenten • Subkomponenten • Klassen • ... Merke: Ziel der Funktionsmodellierung ist also die Komplexitätsreduktion eines Systems durch die Zerlegung in einzelne Teileinheiten. Einzelne Teilsysteme sind Subsysteme, Komponenten, Subkomponenten und Klassen. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 38 8.2 Grundlagen der Dekomposition Abbildung 16: Funktionsbaum bzw. -hierarchie (links) sowie Funktion und Ereignis in EPK (rechts). 8.2.2 Grundprinzipien der Architektur Bei der Dekomposition werden die zwei Grundprinzipien unterschieden: 1. Separation of Concerns: Verantwortlichkeiten der jeweiligen Software-Subsysteme in undlagenTrennung der der Dekomposition a) fachliche Komponenten (senkrecht): basierend auf deren fachlichen Verantwortlichkeiten ie Trennung der erantwortlichkeiten Separation of Concerns“ ührt im Idealfall zu ner doppelten Modularisierung: fachliche Komponenten urch die Trennung der chlichen erantwortlichkeiten enkrechte Gliederung) Schichten oder durch die rennung der technischen erantwortlichkeiten waagerechte Schichtung) p 10-2 Separation of Concerns b) Schichten (waagrecht): basierend auf deren technischen Verantwortlichkeiten Präsentationsschicht Schnittst. Komp. 1 Anwendungskern Komp. 1 Pers. K 1 Datenzugriffsschicht Komp. 1 Schnittst. Komp. 2 Komp. 2 ... Pers. K 2 Komp. 2 ... Datenbank < Beispiel: 3-Schichten-Architektur Abbildung 17: Beispiel einer 3-Schichten-Architektur 9 2. Information Hiding: M. Jud Man zeigt einem Nutzer nur diejenigen Informationen, die er zur Erfüllung seiner Aufgabe braucht: a) OOP: Alle Daten sind „private“, Zugriff auf Daten von aussen nur über dedizierte Methoden b) Fassade, die den Zugriff auf ein ganzes Subsystem regelt und das Subsystem vor direktem Zugriff schützt c) Schichten-Architektur: Schicht n sieht nur Schicht n − 1, die anderen bleiben verborgen. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 39 Systementwicklung von Bedeutung, die verschiedene Aspekte von Funktionen modellieren. 8.3 Dekomposition von DV-Systemen (Funktionale Zerlegung) • Das Konzept der Funktion ist in etlichen Methoden der Systementwicklung von Bedeutung, die verschiedene Im Bereich technischer Datenverarbeitungs-Systeme (DV-Systeme) kennt man die Leittechnik-Pyramide. Dabei kommt Aspekte von Funktionen modellieren. jeder Ebene der Pyramide eine eigene Aufgabe in der Produktion zu, wobei es je nach betrieblicher Situation fliesIM HS13, Kp 10-2 8.2.3 6 Die Leittechnik-Pyramide sende Grenzen gibt. IM HS13, Kp 10-2 M. Jud 6 Unternehmensebene Betriebsleitebene Planen Planung Disposition (Prozess-) Leitebene Operation Steuerungsebene Sicherheit Feldebene Ebene Aufgaben Unternehmensebene Produktionsgrobplanung, Bestellabwicklung Betriebsleitebene Produktionsfeinplanung, Produktionsdatenerfassung, KPI- 11 Ermittlung , Material-Management, Qualitätsmanagement Bedienen und Beobachten, Rezeptverwaltung und Ausführung, (Prozess)leitebene Messwertarchivierung Steuerungsebene Steuerung, Regelung Feldebene Schnittstelle zum technischen Produktionsprozess über Ein- und Ausgangssignale 8.3. Dekomposition von DV-Systemen (Funktionale Zerlegung) Technische DV-Systeme werden meist entlang der Grenzen der elektrischen / mechanischen Systemkomponenten, welche diese steuern, zerlegt. Kriterien: • Sicherheit • „Intelligenz“ • Art der Kommunikation • Fehler- und Alarmierungspropagation → siehe Übung 10.2: Funktionale Zerlegung 8.3.1 Software-Kategorien Der erste Schritt bei der funktionalen Zerlegung eines Systems ist daher die Aufstellung von Software-Kategorien und die Analyse der Abhängigkeiten dazwischen. 11 Als Der Key Performance Begriff fasst alle Indicators werden betrieblichen Schlüsselkennzahlen Kenngrössen, die in bezeichnet, irgendeiner die Form die unternehmerische Erfolge bzw. Misserfolge Leistung widerspiegeln. abbilden, zusammen. (http://www.controllingportal.de/Fachinfo/Kennzahlen/Key-Performance-Indicators-KPI.html) The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 40 M. Jud 8.3 Dekomposition von DV-Systemen (Funktionale Zerlegung) Definition 11: Software-Kategorie Eine Software-Kategorie bestimmt in grober Übersicht, was das System tut, kann und weiss (im Sinne von „KnowHow“ eines bestimmten Gebietes). Techniken und Tools Die entstehenden Kategorien liefern bereits eine erste grobe Aufteilung des Systems in funktionale Bausteine (z.B. Komponenten). • Deployment-Diagramme unterstützen die Modellierung verteilter Systeme. Subsysteme und Komponenten 8.3.2 Deployment-Diagramme können Knoten zugeordnet werden. Die Kommunikationsverbindungen zwischen denSysteme: Knoten Deployment-Diagramme (siehe Kapitel 6.3.5) unterstützen die Modellierung verteilter Subsysteme und Komponenten können Knoten zugeordnet werden werden, Kommunikationsverbindungen undsich Abhängigkeiten zwischen kann dargestellt und bei Bedarf lassen den Elementen werden aufgezeigt. Abhängigkeiten zwischen den Elementen aufzeigen. :Web Server TCP/IP anOracleDB:DB Server :Oracle.Dll :Regist. App Database TCP/IP :Windows PC :Regist Applet :Browser Techniken und Tools 8.3.3 IM HS13, Kp 10-2 Komponenten-Diagramme M. Jud 25 • Komponentendiagramme unterstützen dieunterstützen Strukturierung von Systemen Komponentendiagramme die Strukturierung von Systemen in Subsysteme und Komponenten. in Subsysteme und Komponenten. System «subsystem» A «component» A1 «subsystem» B «component» A2 IM HS13, Kp 10-2 26 «component» B1 M. Jud → siehe Übung 10.3: Funktionale Zerlegung CIS The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 41 9. Kontextdiagramm IM Das Kontextdiagramm veranschaulicht in der Konzeptionsphase das Umfeld des zu realisierenden IT-Systems. Inbesondere wird klar abgegrenzt, was zum Aufgabenbereich des IT-Systems gehört und was nicht (Inhalte & Rollen). Weiter veranschaulicht es grob, welche Informationen in das System hinein fliessen und welche Informationen das System liefern kann. In der Praxis werden Kontextdiagramme durch Use Case-Diagramme12 (UML) ausgedrückt. Kontextdiagramm Das Kontextdiagramm zeigt auf, welche Schnittstellen der Umsysteme zum eigentlichen Projekt vonnöten sind und wie die Datenflüsse laufen. Die Architektur ist oft sehr komplex und somit oft teuer zu implementieren. Stammdaten CMS Kundentermine Outlook Client Manager User Dialog Marktdaten Factiva Treaty IUF Underwriter Performance pro Produktlinie SRS CIS Verträge GFS DB Tools Schadenszahlen Helpdesk CMP DWH Autorisierung Auswertung / Reports RBAM Archivdaten GroupManager Archive Abbildung 18: Beispiel eines Kontextdiagramms für CIS (Customer Information System). Dabei steht das System (bzw. dessen Grenzen) im Zentrum; links davon Inhalte (Systeme) und Informationsfluss, rechts die Akteure / Rollen. Die Pfeile in der Abbildung zeigen dabei die Flussrichtung der Information. Hier gibt es auch bidirektionale Verbindungen13 . Oftmals müssen auch die Systeme der Gegenseite für den Informationsfluss angepasst werden. Diese entstehenden Kosten «müssen» dann auch vom Projekt getragen werden. Merke: Anschliessend an die schematische Darstellung des Kontextdiagramms werden alle Schnittstellen und Datenflüsse sehr detailliert und einzeln dokumentiert. → siehe Übung 11.1: AlpineRe „Kontext-Diagramm“ 12 13 Dabei lässt man die eigentlichen Use Cases weg und zeigt nur Systemgrenze sowie beteiligte Inhalte (links) bzw. Akteure / Rollen (rechts) auf. diese sind oft teuer, da mehrere Systeme betroffen sind The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 42 10. Datenmodellierung 12.1 Einführung 10.1. Begriffe IM Begriffshierarchien Daten Angaben über Sachverhalte und Vorgänge auf- grund bekannter oder unterstellter Abmachungen in einer maschinell verarbeitbaren Form. (DIN 44 300) Datenbank selbständige, auf Dauer und für den flexiblen und sicheren Gebrauch ausgelegte Datenorganisation. Datenmodell Formale Beschreibung des Schemas, z. B. in Form eines Diagramms oder einer Datenstruktur. • Strukturierte Darstellung der Daten der Diskurswelt mit einem formalen Beschreibungsmittel Datenmodellierung Prozess, der sicherstellen soll, dass eiIM Kapitel 11 A. Kurmann ne Datenbasis zu jedem Zeitpunkt ein korrektes Abbild der Diskurswelt wiedergibt. Einführung: Datenmodell - Datenmodellierung 10.2. Datenmodellierung 1) Abbildung= 19: Datenmodell –Datenmodell Datenmodellierung 1) In der Praxis: Semantisches Logisches IM Kapitel 11 A. Kurmann 13 10.3. Informations(struktur)modell Definition 12: Informationsmodell Ein Informationsmodell ist eine grafische Darstellung und verbale Beschreibung von Informationsobjekten, ihren Beziehungen und Attributen. Ziel eines Informationsmodells ist es, eine abstrakte, vereinfachte Sicht der Realität darzustellen, welche trotzdem alle wichtigen Elemente und die relevanten Beziehungen wiedergibt. Das Informationsmodell schafft damit eine gemeinsame Sprache: es dient gleichzeitig als Ausgangspunkt für die spätere IT-Umsetzung (Datenmodell / Datenbankdefinition), als auch als Verständigungsbasis für alle Beteiligten. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 43 6 10.4 10.3.1 Entity-Relationship Modell (ER-Modell) Informationsobjekte Objekte der Warnehmung oder Vorstellung, • • • • • die vom Menschen beschrieben und unterschrieben werden können die in Bezug auf die gegebene Problemstellung relevant sind Merkmale charakterisieren die zugehörigen Informationsobjekte Gleichartige Merkmale werden als Ausprägungen einer gemeinsamen Merkmalsklasse verstanden Alle Merkmale, die einem Informationsobjekt zuzuordnen sind, werden als charakterisierende Merkmalskombination bezeichnet 10.3.2 12.2 Verknüpfungen zwischen Informationsobjektklassen: Schritt 3 Verknüpfung zwischen Informationsobjektklassen Verknüpfungstypen Verknüpfungstypen • Nach der Kardinalität: 1:1, 1:N oder M:N • Nach der Kardinalität: 1 : 1, 1 : N (bzw. 1 : mc) oder M : N (bzw. m : mc) oder anderen Verknüpfungskombinationen • Nach der Optionalität: feste oder optionale Verknüpfungen • Nach der Optionalität: feste oder optionale Verknüpfungen c Professoren Professoren 1 besetzen geben c mc Lehrstühle Vorlesungen sind Voraussetzung c mc für Testate Studenten mc hören mc Prüfungen Vorlesungen Abbildung 20: Verknüpfungstypen IM Kapitel 11 10.3.3 A. Kurmann 17 Vorgehen bei der Informationsstrukturierung • Definition der Informationsobjekte und ihrer Merkmale (Eigenschaften) • Definition der Informations-KLASSEN unter Berücksichtigung der – relevanten Informationsobjekte – der charakterisierenden und identifizierenden Merkmalsklassen und -kombinationen – vollständigen Auflistung der relevanten Merkmale • Definition der Verknüpfungen zwischen den ausgewählten Informationsklassen unter Berücksichtigung der – Qualifizierung der Verknüpfungen – Auflösung komplexer Verknüpfungsstrukturen 10.4. Entity-Relationship Modell (ER-Modell) • semantisches Datenmodell nach P. Chen (1976) • Grafische Darstellungsform verbreitet in verschiedenen Notationen – IDEF1X Federal Information Processing Standards – IE (Informations Engineering) nach James Martin (auch „Krähenfuss Notation“) • insbesondere Vorbereitung für logisches Datenmodell vom Typ Relationenmodell • Vielfache Erweiterung – EER (Erweitertes ER-Modell) mit Min-Max-Notation – SER (Strukturierte ER-Modell) mit Subtypen- und Generalisierungshierarchien The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 44 10.5 10.4.1 Vereinfachtes ER-Modell und Regeln Strukturelemente im ER-Modell • Eine Entity ist ein unterscheidbares Objekte der Realwelt, das ein reales Objekt oder eine gedankliche Abstraktion darstellen kann. • Ein Entity-Typ ist eine Zusammenfassung von gleichartigen Entities, welche die gleichen Eigenschaften besitzen. Entity-Typen stehen für Mengen von Objekten. • Die Eigenschaften eines Entity-Typs werden Attribute genannt. – Jedes Attribut hat einen bestimmten Wertebereich. – Ein Attribut oder eine Attributmenge, das jede Entity eines Entity-Typs eindeutig identifiziert, heisst Schlüssel bzw. Schlüsselkandidat. – Existieren mehrere Schlüssel für einen Entity-Typen, dann wird einer als Primärschlüssel ausgewählt und als solchen entsprechend bezeichnet (Unterstreichung). • Eine Beziehung (Relationship) ist eine Verknüpfung von zwei oder mehreren Entities. • Ein Beziehungstyp (Relationship-Typ) ist eine Zusammenfassung von gleichartigen Beziehungen, welche zwei EntityTypen miteinander verknüpfen. 12.3 Mögliche Beziehungen zwischen Entity-Typen 10.4.2 Mögliche Beziehungen zwischen Entity-Typen Schlitten Nikolaus Kind Schmutzli Abbildung 21: Beziehungstypen in der CHEN-Notation (links) und Beispiel in der Krähenfussnotation (rechts) A. Kurmann IM Kapitel 11 26 → siehe Übung 12.4: Weiterbildungszentrum 12.5 Das klassische ER-Modell wird zu... 10.5. Vereinfachtes ER-Modell und Regeln • Relationship-Typen weglassen, stattdessen die Be- Studenten zeichnung der Beziehungen der beiden Entitäten m hören > mc < wird gehört angeben (z.B. „hören >“, „< wird gehört“) • Definition der Attribute in einem separaten Dokument • kurze Beschreibung pro Entitätsmenge und Attribut Beziehungen werden häufig mit Verben benannt. Für die 2 Leserichtungen passen häufig Aktivund Passivform. (ebenfalls in separatem Dokument), siehe Beispiel zeichnet (Unterstreichung) wird gelesen ↓ liest ↑ „Informationsmodell“ im Kapitel 10.6 • das primäre Schlüsselattribut (primary key) wird ausge- Vorlesungen mc 1 Das Kapitel 10.6 enthält ein Informationsmodell mit allen beschriebenen Eigenschaften. IM Kapitel 11 Professoren A. Kurmann → siehe Übung 12.6: CMDB IT-Betrieb (die Übung zeigt eine Modellierung als vereinfachtes ER-Modell) The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 45 43 10.5 10.5.1 Vereinfachtes ER-Modell und Regeln Generalisierung 14 Das Prinzip der Generalisierung wird eingesetzt, um eine übersichtlichere und natürlichere Strukturierung der EntityUni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Typen zu erzielen. Gemeinsame Eigenschaften (Attribute und Beziehungen) ähnlicher Entity-Typen werden „herausfaktorisiert“ und einem gemeinsamen Obertyp zugeordnet. es unterschiedliche wobei die folgende am engsten an die E-R- die nicht allen UntertyDie beteiligten Entity-Typen sind dannStrategien, Untertypen dessich jeweiligen Obertyps. Eigenschaften, Modellierung hält: pen gemeinsam sind, bleiben beim entsprechenden Untertyp. Wir verwenden für die Kennzeichnung die Bezeichnung • Für jeden Entitätstypen E in der Generalisierungshierarchie gibt es eine is-a mit dem Raute-Symbol. Relation mit den Schlüsselattributen des Obertypen und den Attributen von E Fachgebiet Rang is_a WissMitarbeiter RaumNr UniAngestellter Professor Name PersNr UniAngestellte : {[PersNr, Name, RaumNr]} Professoren : {[PersNr, Rang]} WissMitarbeiter : {[PersNr, Fachgebiet]} 10.5.2 Eine Alternative wäre die Überführung des abgeleiteten Entitätstypen E in eine Relation, die als Attribute alle Attribute des Obertypen sowie die Attribute von E besitzt. In dieser Variante würden in der Relation des Obertyps nur Instanzen 11 Spezialisierunggespeichert, die zu keinem der Subtypen gehören. UniAngestellte : {[PersNr, Name, RaumNr]} Die Spezialisierung ist die inverse Operation zur Generalisierung. Professoren : {[PersNr, Name, RaumNr, Rang]} WissMitarbeiter : {[PersNr, Name, RaumNr, Fachgebiet]} Zusammenführen von Relationen Die direkte Überführung wie oben beschrieben liefert oft nicht die bestmöglichen Relationen. Oft kann man nun noch Relationen zusammenführen. Allgemein gilt: Relationen mit dem gleichen Schlüssel kann man zusammenfassen (aber auch nur diese). Ein binärer Beziehungstyp R zwischen Entitätentypen E und F, an dem mindestens einer der beiden beteiligten Entitätstypen (sagen wir E) mit Funktionalität 1 teilnimmt, kann mit der E entsprechenden Relation zusammengeführt werden. Dazu führt man eine Relation mit folgenden Attributen ein: • die Attribute von E • die Primärschlüsselattribute von F Merke: • die Attribute der Beziehung R Kennzeichnend ist die Vererbung von Eigenschaften (Untertypen erben von Obertypen). Praktikum Datenbanken / DB2 Seite 3 von 5 Woche 3: Relationenschemata, 1. Normalform → siehe Übung 12.7: AlpineRe „Informationsmodell“ (die Übung zeigt eine komplette Modellierung inkl. Dokumentation) 14 http://www2.tcs.informatik.uni-muenchen.de/lehre/lehrerausbildung/db_ermodell.pdf The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 46 Swiss Risk Trading and Reinsurance Company Schweizerische Risikohandels- und Rückversicherungsgesellschaft Projekt CIS Information Model 1. Übersicht mc 1 mc m Personal 1 Contract mc m m 1 nimmt teil > gehört zu > mc 1 mc Meeting 1 1 Client is-a m c hat Teilnehmer > m < gehört zu 1 Alpine®Re < Kontakt von < Neuigkeit von hat > Company mc FinancialInstrument mc NewsArticle m ClientContact Das vorliegende Business Information Model wurde aufgrund der verfügbaren Unterlagen als Basis für die Entwicklung des Prototypen/Proof of Concept erarbeitet. Diese Version ist noch nicht endgültig! c FrameClaim m 1 mc incomingPayment ContractSection Group teilnehmer > Die Einzelheiten zu den Informationsobjekten sind in den nachfolgenden Objektbeschreibungen zusammengestellt. Fallstudie Alpine Re Teil 1: Die Unternehmung 1/6 Swiss Risk Trading and Reinsurance Company Schweizerische Risikohandels- und Rückversicherungsgesellschaft ClientID Eindeutige Client-Nummer. Diese wird bei der Erfassung des Kontakts vergeben und bleibt anschliessend unverändert. Der Kontakt gehört zu einem bestimmten Client und arbeitet für diesen. Alpine®Re Anmerkungen Bezeichnung / Verschlagwortung Ansprechpartner des Clients in Frage kommen. Wichtige Attribute Bezeichner Rolle, welche der Kontakt gegenüber Alpine®RE einnimmt £ Ein ClientContact wird einem bestimmten Client zugeordnet Rolle Beziehungen NewsArticle [Kundenmitteilung] Nachrichtensendung, Nachrichten Bemerkung Verwandte Begriffe Eindeutige Nummer. Diese wird von der Factiva-DB erzeugt und bei der Erstellung eines neuen NewsArticles vergeben. Der Wert bleibt anschliessend unverändert. Definition Factiva_NewsID Bezeichnung / Verschlagwortung £ Ein NewsArticle kann mehreren Clients zugeordnet werden Headline FACTIVA besitzt die Möglichkeit, Mitteilungen für Kunden zielgerichtet zu erstellen. Diese werden in Form von News-Artikeln im CIS hinterlegt und bestimmten Kunden zugeordnet. Anmerkungen Wichtige Attribute Beziehungen FinancialInstrument [Zahlungsmittel] Wichtige Attribute Anmerkungen Definition Verwandte Begriffe £ siehe Diagramm Bezeichner FinanceInstrID Bezeichnung / Verschlagwortung Identifikation des FinancialInstruments Beispiel: ISIN, IBAN, Scheck Als FinancialInstrument gilt ein (1) bevorzugtes Zahlungsmittel, welches in Verbindung mit einem Client benützt wird. Geld, Währung, Valuta, Kapital, finanzielle Mittel Bemerkung Beziehungen Bemerkung Besprechung, Zusammenkunft, Treffen, Sitzung Informationen kommen aus vorhandenem CMS System. Meetings [Sitzung] Verwandte Begriffe Identifikation des Meetings Definition MeetingID 3/6 Ein Meeting ist ein Treffen zwischen einem oder mehreren Mitarbeitern und einem Client. An diesem werden gewisse Dinge geklärt, vereinbart und Verträge unterzeichnet. Anmerkungen Wichtige Fallstudie Alpine Re Teil 1: Die Unternehmung Seite 47 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Claim mc outgoingPayment < wird kategorisiert < underwriter von Im Modell sind vier Themenbereiche farblich unterschieden: Bereich Kundeninformation (gelb), Vertrag (grün), Schaden (blau) und Zahlung (rot). Nicht überraschend für ein Kunden Informationssystem ist der Bereich der Client Information der am stärksten detaillierte. Payment is-a < hat < beinhaltet gehört zu > < hat Beispiel eines Informationsmodells 10.6 10.6. Beispiel eines Informationsmodells 11. Systemdesign IM 11.1. Einflussfaktoren & Vorgehen Es gibt kein deterministisches Verfahren, das in jedem Fall zu guten Software-Architekturen führt. Wesentliche Schritte, die zu einem guten Systemdesign führen, sind: 1. Informationen sammeln 2. Systemidee entwickeln 3. Einflussfaktoren und Randbedingungen würdigen 4. Risiken identifizieren 5. Qualität explizit beschreiben 6. Lösungsstrategien entwickeln 11.1.1 Informationen sammeln Gute Lösungen lassen sich in der Regel auf bekannte Dinge zurückführen, völlig eigenständige Ansätze sind oft unnötig aufwändige Folgen mangelhafter Recherche und nicht wirklich genial. • Wie haben andere vor Ihnen ähnliche Probleme gelöst: – Lassen sich Ergebnisse anderer Projekte in der Organisation wieder verwenden? – Sind im Internet ähnliche Systeme beschrieben, kann man möglicherweise sogar geeignete Komponenten kaufen? – Passen Referenzarchitekturen, Architektur- oder Entwurfsmuster auf die Problemstellung? 11.1.2 Systemidee entwickeln Die Systemidee ist die Grundlage sowohl für die Abstimmung mit dem Kunden / Auftraggeber als auch mit dem Projektteam. Sie ist zudem die Basis für künftige weitere Entwurfsentscheidungen. • Systemidee: – Kernaufgabe Ein Satz, was das System macht + fünf Schlüsselbegriffe der Fachdomäne. – Nutzungsart und Nutzer Online / Decision Support / Batch / Embedded. Benutzergruppen und -oberflächen. – Schnittstellen Beziehungen zu andern Systemen, Daten und Mengen, Kontrolle, synchron / asynchron. – Datenhaltung Persistenz: wo / Datenvolumina / Integrität / Transaktionen / Sicherheit / Recovery. – Kontrolle event-driven / prozedural / parallel / regelbasiert. 11.1.3 Einflussfaktoren und Randbedingungen würdigen Ingenieure tendieren dazu, organisatorische und politische Faktoren zu unterschätzen. Das kann im Extremfall dazu führen, dass an sich lauffähige Systeme realisiert werden, die aber nie zum Einsatz kommen. Faktoren, die möglicherweise für das Systemdesign relevant sind: – Organisatorische und politische Faktoren: Die Politik – und nicht die Technik (!) – bestimmt, was in einem Projekt erreicht werden kann → politische Stakeholder identifizieren und deren Ziele verstehen. Vorgehen, Werkzeuge und Ressourcen sind meist durch die Organisation vorgegeben. – Technische Faktoren: vorhandene Hard- und Software-Infrastruktur, Frameworks, Libraries, Datenstrukturen, Schnitt- stellen und Methoden – System- bzw. Produktfaktoren: funktionale Anforderungen und Features / nicht-funktionale Anforderungen; z.B. Per- formance, Flexibilität etc. / geforderte Verfahren und Techniken / Abhängigkeit von anderen Systemen. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 48 11.1 11.1.4 Einflussfaktoren & Vorgehen Risiken identifizieren Entwurfsentscheidungen und Projektrisiken beeinflussen sich gegenseitig. Ein gutes Risikomanagement hilft Entwurfsentscheidungen so zu fällen, dass bestehenden Risiken aus dem Weg gegangen wird ohne dabei neue Risiken in Kauf zu nehmen. Typische Risiken in Softwareprojekten sind: • • • • • Unterschätzer Aufwand und Komplexität überschätzte Ressourcen-Verfügbarkeit (Personen und Sachen) Ungeeignete Ressourcen (Personen und Sachen) Unzuverlässige Basissysteme und Drittsysteme (Schnittstellen) Unvollständige, widersprüchliche und instabile Anforderungen 11.1.5 Qualität explizit beschreiben Qualität entsteht nicht von selbst – sie muss konstruiert werden. Qualitätsmerkmale sind Entwurfsziele. Qualitätsmerkmale wie Performance, Wartbarkeit und Verständlichkeit sind nur auf der Grundlage eines entsprechenden Systemdesigns erreichbar. Starke (2008) empfiehlt, Szenarien dafür einzusetzen und so Qualitätsmerkmale zu operationalisieren und praxisgerecht zu konkretisieren: Anwendungsszenarien: beschreiben geforderte Funktionalität und Performance Beispiel: Die Benutzeranfrage muss in 0.5 Sekunden beantwortet werden. Änderungsszenarien: beschreiben den Aufwand für absehbare Änderungen am System Beispiel: Die Portierung auf eine andere Plattform muss innert 50 Personentagen möglich sein. Stress- und Grenzszenarien: beschreiben, wie das System auf Extremsituationen reagiert Beispiel: Das redundante System muss für die Benutzer innert 5 Minuten wieder erreichbar sein. 11.1.6 Lösungsstrategien entwickeln Für die typischen Herausforderungen bei Softwareprojekten gibt es zwar keine „silver bullets“ (Brooks, 1986) aber immerhin erprobte Strategien bei. . . Mangel an Zeit, Budget und Erfahrung: Enge Kooperation mit dem Projektmanagement, Offenlegen der Risiken, Etap- pierung der Auslieferung, Anpassung der Anforderungen, und: „addig people to a late project makes it even later“. Performanceproblemen: Optimieren nur, wenn z.B. durch Profiler-Systeme „Bottlenecks“ identifiziert sind; zusätzliche oder leistungsfähigere Hardware ist billiger als Optimieren, ungünstige Verteilung und suboptimale Kommunikation sind Ressourcenfresser. Problemen mit Anpassbarkeit und Flexibilität: Subsysteme und Komponenten über Adapter, Fassaden, Proxies, ent- koppeln; explizite Interfaces vorsehen, Konfigurationsdaten in Dateien statt im Code. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 49 11.2 Von der Idee zur Struktur Begrifflichkeit und Strukturen aus: Starke G., Effektive Software-Architekturen, © 2008 Hanser Verlag München Einflussfaktoren & Vorgehen Aktivitäten 11.1.7 – Aktivitäten Einige der Aktivitäten aus deraus Abbildung links können par• Einige der Aktivitäten allel stattfinden – im Kopf oder auf verschiedene Personen Abbildung können parallel verteilt. In jedem Fall sollte regelmässig geklärt werden, stattfinden - in Ihrem Kopf welche Anforderungen und Einflussfaktoren sich geändert oderhaben. auf Darauf verschiedene hin sind eventuell bereits gefällte EntscheiPersonen verteilt. dungen zu überarbeiten und die Architektur eines Systems sogar anzupassen. • In jedem Fall klären Sie regelmässig, welche Anforderungen und Einflussfaktoren sich geändert haben. • Darauf hin müssen Sie eventuell Ihre Entscheidungen überarbeiten und die Architektur Ihres Einflussfaktoren & VorgehenSystems – Iterationen anpassen. 11.1.8 Iterationen Begrifflichkeit und Strukturen aus: Starke G., Effektive Software-Architekturen, © 2008 Hanser Verlag München (angepasst) IM HS13, Kp 13-1 • Sowohl IhrewieKunden Sowohl Kunden auch anderewie Projektbeteiligte ändern Anforderungen und Einflussfaktoren. Aufgrund dieser Änauch andere derungen muss sich das Systemdesign Projektbeteiligte ändern immer wieder den veränderten Gegebenheiten anpassen. Anforderungen und Einflussfaktoren. Merke: • Aufgrund dieser Architekturen, die sich an den wirklichen BedürfÄnderungen müssenorientieren, Sie nissen und Anforderungen entstehen Ihriterativ. Systemdesign immer wieder den veränderten Gegebenheiten anpassen. M. Jud 14 • Architekturen, die an den wirklichen Bedürfnissen und Anforderungen orientiert sind, entstehen iterativ. 11.2. Von der Idee zur Struktur IM HS13, Kp 13-1 11.2.1 15 M. Jud Komplexität „Everything should be as simple as possible, but not simpler.“ Albert Einstein natürliche Komplexität ist die Komplexität des zu Grunde liegenden Problems. Eine Software kann nicht einfacher sein als das Problem, welches sie löst. → beherrschen künstliche Komplexität kommt bei der Entwicklung dazu, trägt aber nichts zur Lösung des Problems bei. → vermeiden The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 50 11.3 Heuristiken „Wenn du es in fünf Minuten nicht erklären kannst, hast du es entweder selbst nicht verstanden, oder es funktioniert nicht.“ Eberhardt Rechtin, Mark Maier – The Art of Systems Architecting 11.3. Heuristiken Systementwurf ist keine exakte Wissenschaft; die Kombination von Grundsätzen der Zerlegung, Architekturmuster, Entwurfsprinzipien und Heuristiken kommt den Entwürfen der Entwicklung zugute. Merke: Heuristiken sind Regeln zum Umgang mit komplexen Aufgaben, entstanden aus verallgemeinerten und abstrahierten Erfahrungen. Darum können Heuristiken lediglich Hinweise geben auf dem Weg zum guten Systementwurf, aber ohne Erfolgsgarantie, denn Entwurf bleibt (zum Glück) eine kreative Tätigkeit. 11.3.1 Beispiele gängiger Heuristiken So einfach wie möglich (Umgang mit Komplexität). Das Konzept sollte so einfach wie möglich gehalten, unnötige Ele- mente eliminiert und so wenige Beziehungen wie möglich umgesetzt werden. Separation of Concerns (Entwerfen nach Verantwortlichkeit). Eine Komponente, ein Paket, eine Klasse und sogar eine Methode sollten nur für jeweils eine (!) klar definierte Aufgabe verantwortlich sein. Interface Segregation (auf Schnittstellen hin entwerfen). Klassen sollten – nur, wenn überhaupt erst nötig – ausschliess- lich von Schnittstellen und nicht von anderen Klassen abhängen. Robustness (Fehler berücksichtigen – Fehlertoleranz bezüglich Anwender-Hardware und SW-Fehlern). Softwareelemente sollten eine gewisse Fehlertoleranz berücksichtigen. Loose coupling, high cohesion (Lose Kopplung und hohe Kohäsion). Softwareelemente sollten nur lose untereinander gekoppelt, aber deren Verantwortung sehr stark eingeschränkt sein (siehe Separation of Concerns). Open Close (Offen-Geschlossen Prinzip – Erweiterbarkeit ohne Eingriff in den Code). Software sollte offen gegenüber Erweiterungen aber geschlossen gegenüber Änderungen sein: Code nicht anpassen, sondern erweitern (bspw. Methodenüberladung, Interfaceabstraktion)! Cyclic Redundancy (Keine zyklischen Abhängigkeiten (Wie sich zyklische Abhängigkeiten umgehen lassen). Die Klassen- Struktur sollte keine zyklischen Abhängigkeiten besitzen. Ist dies nicht möglich, dann dient ein Interface als Abstraktion (z.B.: Observer, siehe Observer-Pattern). Das „Liskov Substitutionsprinzip“ (Einschränkung der Vererbung). Jede Unterklasse sollten anstelle ihrer Oberklasse(n) einsetzbar sein. Vorsicht bei starker Polymorphie! Dependency Injection. Ist eine Klasse grundsätzlich nur vom Interface einer anderen Klasse abhängig, sollte sie diese (d.h. die implementierte Klasse) auch nicht erzeugen! Ein drittes Element (z.B.: eine Factory) soll diese Aufgabe übernehmen und die Instanz dann entsprechend übergeben. → siehe Übung 13.1: Heuristiken The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 51 11.4 Systemdesign kommunizieren 11.4. Systemdesign kommunizieren Beim Systementwurf werden wichtige Entscheidungen gefällt, die Einfluss auf Entwicklung, Betrieb und Wartung haben. Deshalb müssen Entwurfsentscheidungen den entsprechenden Stakeholders kommuniziert und erklärt werden. Mögliche Stakeholders dabei sind beispielsweise: • Auftraggeber / Nutzer • Entwicklungsteam • Betrieb und Wartung Da die Lebensdauer von IT-Systemen in der realen Welt oft Jahrzehnte beträgt, muss deren Architektur so dokumentiert werden, dass Generationen von Entwicklern das System verstehen und dieses an neue Bedürfnisse anpassen / erweitern können.15 Merke: Die Abstraktion (Abstraktionsniveau) muss immer an die Situation, in welcher der Entwurf gelten soll, angepasst werden («angepasste Flughöhe» wählen). Dementsprechend müssten beispielsweise Klassendiagramme unterschiedliche «Tiefen» aufweisen. 11.4.1 Reduktion der Komplexität: Einführung von Sichten In einer einzelnen Darstellung lässt sich die Vielschichtigkeit und Komplexität eines Systemdesigns nicht ausdrücken. Sichten erlauben die Konzentration auf bestimme Aspekte, indem sie von Details abstrahieren, welche für die gewählte Perspektive nicht von Bedeutung sind. Nach Starke (2008) existieren folgende vier Sichten: • Kontextsichten (siehe Kap. 11.5.1 bzw. 9): Einbettung System in Umgebung, Blackbox, Vogelperspektive, Vision, abstrakter als übrige Sichten. • Bausteinsichten (siehe Kap. 11.5.2): Interner Aufbau, zeigen statische Strukturen (Architekturbausteine, Subsysteme, Komponenten und deren Schnittstellen, sollte „top-down“ (ausgehend von einer Kontextsicht) entwickelt werden, letzte Verfeinerungsstufe der Zerlegung bildet der Quellcode. Übersicht der verschiedenen Sichten nach Starke (2008) • Laufzeitsichten (siehe Kap. 11.5.3): Beschreiben, wie Bausteine zur Laufzeit des Systems zusammenwirken, haben eine dynamische Struktur im Gegensatz zur statischen Betrachtungsweise (Bausteinsichten). • Verteilungssichten (siehe Kap. 11.5.4): Beschreiben Merke: Die Sichten zeigen alle das gleiche System, beleuchten aber unterschiedliche Aspekte daraus («Bausteine»). die Umgebung des Systems, Hardwarekomponenten wie Rechner, Prozessoren, Netztopologien und -protokolle & weitere Bestandteile der physischen Systemumgebung – wobei die Infrastruktursicht das System aus Betreibersicht zeigt. 15 Gegenteilig können Schulprojekte betrachtet werden: diese werden oft in geschützten Umgebungen für eine kurze Zeit – üblicherweise für 1-2 Semester – genutzt. Danach geraten diese wieder in Vergessenheit. Somit muss das System auch nicht durch mehrere Entwickler-Generationen gewartet und erweitert werden. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 52 11.5 Entwurf der Sichten 11.5. Entwurf der Sichten Sichten beeinflussen sich gegenseitig. Somit gibt es keine zwingende Reihenfolge für deren Entwurf. • Wenn ein bestehendes System erweitert oder umgebaut wird, ist die Bausteinsicht ein guter Ausgangspunkt. • Wenn Verantwortlichkeiten und Zusammenspiel der Komponenten unklar sind, so sollte man mit der Laufzeitsicht beginnen. • Wenn die Infrastruktur durch Randbedingungen eingeschränkt oder vorgegeben ist, entwirft man zuerst die Verteilungssicht. • Allgemein ist die Kontextsicht ein sinnvoller Einstieg. 11.5.1 Kontextsicht (siehe auch Kapitel 9) Kontextsichten stellen eine Abstraktion der übrigen Sichten, mit Fokus auf die Beziehungen des Systems zu seinem Umfeld, dar. • • • • • System als BlackBox Schnittstelen zu Anwendern, Nachbar- und Fremdsystemen, inkl. Daten & Steuerfluss TopLevel Use Cases Technische Umgebung (Infrastruktur: Kommunikationskanäle, Rechnersysteme, usw.) die Interaktionen mit wichtigen Stakeholdern Merke: Die Kontextsicht sollte vollständig sein in Bezug auf externe Schnittstellen, Nachbarsysteme und Nutzergruppen. Da in der Kontextsicht abstrakte Darstellungen der Baustein-, Laufzeit- und Verteilungssichten gezeigt werden, können auch deren jeweiligen Notationen verwendet werden: • • • • Darstellung «grosser» Systemstrukturen anhand Komponentendiagrammen (angereichert mit Paketen & Klassen) Schnittstellen in Komponentendiagrammen mit Ball und Socket Schnittstellen in Klassendiagrammen über Assoziationen zu anderen Systemen / Akteuren Anwendungsfälle oder Abläufe mit dynamischen UML-Diagrammen (Sequenz-, Kommunikations- oder Aktivitätsdiagramme) Stammdaten CMS Kundentermine Outlook Client Manager User Dialog Marktdaten Factiva Treaty IUF Underwriter Performance pro Produktlinie SRS CIS Verträge GFS DB Tools Schadenszahlen Helpdesk CMP DWH Autorisierung Auswertung / Reports RBAM Archivdaten GroupManager Archive Abbildung 22: Beispiel einer Kontextsicht in UML (links) bzw. als Kontextdiagramm (rechts, bekannt aus Kapitel 9 The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 53 11.5 11.5.2 Entwurf der Sichten Bausteinsicht Bausteinsichten unterstützen den Projektleiter und den Auftraggeber bei der Projektüberwachung. Zudem dienen sie der Zuteilung von Arbeitspaketen und fungieren als Referenz für Softwareentwickler. Die Bausteinsichten zeigen ebenfalls die Aufteilung der Funktionalität des Systems. Dies sind aus Entwicklungssicht Pakete und evtl. Klassen, sowie aus Systemsicht Subsysteme bzw. Komponenten. Beispiel 1: Aufbau einer modellartigen Bausteinsicht Merke: Die Bausteinsicht sollte vollständig sein in Bezug auf Schnittstellen & Abhängigkeiten der dargestellten Elemente. Vorgehen hierarchische Verfeinerung („top down“): 1. Subsysteme 2. Komponenten Verantwortlichkeiten und Schnittstellen von BlackBoxes. 3. Objekte Eine Verantwortlichkeit beschreibt den Zweck eines Bau- steins auf abstrakter Ebene: wozu dient er, welche Aufgabe erfüllt er? Schnittstellen können verschiedene Ausprägungen annehmen, etwa: • Aufruf/Rückgabe (call-return) • synchron-asynchron • push/pull • Benachrichtigung (event notification) Die Semantik dieser Beziehungen sollte immer angemessen dokumentiert werden. Auf der Ebene von Klassen und Objekten kann eine Schnittstelle durch Assoziationen und public-Methoden dargestellt werden. Auf Subsystemund Komponentenebene sind hingegen Ball und Socket sowie Ports sinnvolle Darstellungsformen. Abbildung 23: Bausteinsicht mit Ball, Socket und Ports The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 54 11.5 Entwurf der Sichten Bausteinsichten ermöglichen auch das Erkennen von Strukturen in Form von Whiteboxes. Zum Beispiel: • Ein Diagramm (UML Paket- oder Klassendiagramm), welches die innere Struktur dieser Whitebox zeigt. • Eine Liste der lokalen Blackbox-Bausteine. (Deren interne Struktur kann in einer weiteren Verfeinerungsebene dargestellt werden.) • Eine Liste der Abhängigkeiten und Beziehungen zwischen den lokalen Bausteinen. • Gründe, die zu dieser Struktur geführt haben. 11.5.3 Laufzeitsicht Laufzeitsichten zeigen, wie die Systembestandteile bei der Ausführung zusammenwirken. Spezielle Aspekte der Laufzeit werden dokumentiert. So beispielsweise: • Wie sich das System beim Hochfahren verhält (notwendige Startskripte, Abhängigkeit von externen Systemen, Datenbanken etc.) • Wie werden wichtige UseCases bearbeitet • Wie arbeiten wichtige Systemkomponenten zusammen Merke: Die Laufzeitsicht sollte Daten- und Kontrollflüsse zwischen den dargestellten Laufzeitelementen vollständig darstellen. Elemente der Laufzeitsichten sind Instanzen der Architekturbausteine, von denen zur Laufzeit Exemplare erzeugt werden (also z.B. Objekte oder Komponenten, aber nicht abstrakte Klassen oder logische Interfaces). Sinnvollerweise wird die Laufzeitsicht mit UML-Sequenz-, Aktivitäts- oder Kommunikationsdiagrammen dokumentiert. Diese können auf verschiedenen Abstraktionsebenen gezeichnet werden. 11.5.4 Verteilungssicht Verteilungssichten beschreiben die technische Infrastruktur, auf der das System abläuft. Wesentliche Elemente sind: • Knoten (Rechner vom Mainframe bis zum Mikrocontroller) • Kanäle (Kommunikationsverbindungen) • Komponenten (Software) Merke: In Verteilungssichten sollte die Ablaufumgebung des Systems wie Prozessoren, Speicher, Netzwerke, Router und Firewalls mit den beteiligten Protokollen beschrieben werden. In heterogenen, verteilten Systemlandschaften wird detailliert die technische Infrastruktur wie Netztopologien, Protokolle, Kapazitäten sowie Prozessoren und Speicherkapazitäten dokumentiert. Weiter sollten Angaben zur Verfügbarkeit gemacht werden. Zudem ist es wichtig, die Verteilungssicht mit den Mengengerüsten der beteiligten Daten abzugleichen: Genügt die verfügbare Hardware und genügt der Durchsatz der Kommunikationskanäle? Bei Bedarf können die Leistungsdaten und Parameter der beteiligten Elemente wie beispielsweise: • Speichergrössen • Kapazitäten • Mengengerüste dargestellt werden. Natürlich lassen sich auch Betriebsysteme oder andere externe Systeme darstellen (vgl. Abb. 24). The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 55 11.6 Architekturaspekte Abbildung 24: Darstellung einer Verteilungssicht mit möglichen Parametern → siehe Übung 13.2: Systemdesign 11.6. Architekturaspekte Unter Architekturaspekten versteht man Dinge, die Software-Architekten beim Systementwurf beschäftigt. Für viele dieser Aspekte gibt es daher typische (bewährte) Lösungsansätze, auf welchen man eine konkrete Lösung aufbauen kann. 1. Persistenz 7. GUI-Ergonomie 2. Geschäftsregeln 8. Internationalisierung 3. Legacy 9. Workflow-Management 4. Verteilung 10. Sicherheit 5. Kommunikation 11. Logging 6. GUI-Ablaufsteuerung 12. Fehlerbehandlung 11.6.1 Persistenz Sämtliche kommerziellen und viele technische SoftwareSysteme benötigen einen effizienten Zugriff auf persistent gespeicherte Daten. Problem: viele Änderungen am Quellcode beim Handling durch Objekte. Im einfachsten Fall stellt man den Fachklassen dedizierte Datenklassen zur Seite (JDBC / ADO / ...). Bei einer grossen Anzahl an Fachklassen – wenn bspw. vernetzte Objektstrukturen persistiert werden müssen bzw. die Abbildung auf die Datenbank(en) komplex ist – lohnt sich der Entwurf einer Persistenzschicht. Persistenzschichten vermitteln zwischen Anwendung und unterschiedlichen Speichersystemen. Fachklassen benutzen dann lediglich Methoden wie save(), read() oder delete(). The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 56 11.6 11.6.2 Architekturaspekte Geschäftsregeln Geschäftsregeln legen Abläufe in Abhängigkeit von bestimmten Bedingungen fest. Die Implementation dieser Fachlogik durch «if-then-else»-Konstrukte in den Fachklassen erschwert die Verständlichkeit und Wartbarkeit eines Systems. Alternativ kann man die Geschäftsregeln in einer Regelsprache beschreiben. Eine RuleEngine führt dann die Fachlogik auf den Geschäftsobjekten aus. 11.6.3 Legacy Insbesondere kommerzielle SW-Systeme werden in der Regel in einem Umfeld bestehender Anwendungen, d.h. in einem Legacy-Kontext entwickelt. Ein solcher Eingriff in die Legacy soll minimal invasiv gestaltet werden. Einen minimal invasiven Ansatz stellt die Integration über ein Gateway dar. So lassen sich die Details der Kommunikation mit dem Legacy-System kapseln und bei Bedarf auch weiteren Clients Zugang zum Altsystem schaffen. Alternativ kann ein Wrapper, der typischerweise auf der Legacy-Plattform realisiert wird, eine Schnittstelle zu deren Diensten anbieten. 11.6.4 Verteilung Aus verschiedensten Gründen kann es notwendig sein, dass ein Softwaresystem auf unterschiedlichen Rechnern abläuft. Entferne Methodenaufrufe sind ressourcenintensiv(er); verteilte Objekte benötigen eine komplexere Infrastruktur und die Fehlerbehandlung über Systemgrenzen hinweg ist aufwändiger. Tipps • • • • • 11.6.5 Verteilung nur wenn nötig (Komplexität) Verarbeitung möglichst nahe bei betroffenen Daten stabile Schnittstellen anstreben lieber höhere Serverbelastung als höherer Datentransfer Zusatzaufwand für Test und Deployment einplanen Kommunikation Beim Entwurf verteilter Systeme kommt der Kommunikation wegen der vielfältigen Möglichkeiten mit entsprechenden Vor- und Nachteilen grosse Bedeutung zu. Es stellen sich beispielsweise folgende Fragen bez. Kommunikation: • • • • • • • synchron oder asynchron stateful oder stateless direkt oder via Middleware Stil (RPC, publish/subscribe, broadcast, poll, usw.) nur TCP/IP oder zusätzlich IIOP, SOAP, HTTP, usw. Datenkodierung (little/big endian, Zeichensatz, usw.) Semantik (aktuelle Werte oder nur Deltas) 11.6.6 GUI-Ablaufsteuerung Der Programmablauf (User Führung16 ) kann durch eine geschickte GUI-Ablaufsteuerung besser unterstützt werden. Beispielsweise durch: • Frage/Antwort-Systeme – Formulare, Bildschirmmasken, aufeinander folgende Dialoge (im Hintergrund durch einen Zustandsautomaten repräsentiert) • Objektorientierte Oberflächen – Unterscheidung von Werkzeug, Verwendung und Material. 16 Ja, Papa The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 57 11.6 Architekturaspekte • MVC – Trennen von Verarbeitungslogik und Steuerungselementen (Model / View / Control); Sinnvoll pro unabhängiger Maske eigene MVC-Tripel vorzusehen. Bei Thin-Client Systemen wird MVC auf Server realisiert, wobei der Controller auf Anfrage des Clients die Views vorbereitet. 11.6.7 GUI-Ergonomie • Arbeitsmetaphern (Struktur der Arbeitsabläufe) • Interaktionsstile (Art der Darstellung) – Objektorientiert – wenn die Daten grafisch gut repräsentierbar sind, z.B. Textverarbeitung. – Frage/Antwort – wenn der Ablauf vom System vorgegeben ist, z.B. Install-Wizard – Formularbasiert – wenn (repetitiv) Daten erfasst bzw. abgefragt werden, z.B. Stammdatenverwaltung – Menü und Fenster – als Applikationsrahmen für die einzelnen Anwendungsfälle • Effektivität, Effizienz und Akzeptanz – Heuristiken, welche helfen können eine intuitive und den Erwartungen der Nutzer entsprechende Oberfläche zu designen. Abbildung 25: Heuristiken zum ergonomischen GUI-Design 11.6.8 Internationalisierung Je nach Markt sind nebst Sprache, Währung, gängiger Formatierung etc. auch rechtliche (z.B. Datenschutz) und kulturelle Aspekte zu beachten. Internationalisierung beeinflusst deshalb nicht nur die Architektur, sondern den gesamten Entwicklungsprozess. Wenn also das Businessmodell für einen grossen Markt ausgelegt ist, sollte dies bereits zukunftsorientiert gestaltet werden. 11.6.9 Workflow-Management Unter Workflow-Management versteht man die systemübergreifende Ablaufsteuerung und Koordination von SoftwareSystemen. Grundsätzlich können drei Lösungsansätze unterschieden werden: 1. Steuerung durch externes WMS bzw. BPMS 2. Manuelle Steuerung (mittels E-Mail oder Groupware) 3. Embedded Workflow mittels Zustandsautomat Dies ist stückzahlabhängig (Rasierer versus Einzelstück Maschinen) – bei geringen Stückzahlen sollte ein billiger Controller verbaut werden, da der Controller in diesem Kontext nur eine kleine Rolle. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 58 11.6 11.6.10 Architekturaspekte Sicherheit Insbesondere im Bereich eCommerce sind Sicherheitsaspekte von zentraler Bedeutung. Gesetzliche Vorgaben beschränken den Entscheidungsspielraum, z.B. Verschlüsselungsverbot vs. -pflicht. Oftmals stellen sich auch organisatorische Fragen, welche sich dann auf Einsatz von Firewalls, PKI, Hardware allgemein auswirken. Ziel der Sicherheit ist es Vertraulichkeit / Integrität /Authentizität / Autorisierung zu gewährleisten und die Verfügbarkeit sicherzustellen (bspw. Schutz vor DoS Attacken). Trennung durch OSI Schichten: • Netzwerk (Layer 3): z.B. VPN, für Anwendungen transparent • Transport (Layer 4): z.B. SSL, Anwendung kennt Zertifikate • Anwendung (Layer 7): z.B. S/MIME E-Mail Anwendungen 11.6.11 Logging Logging kann fachliche und/oder technische Protokollierung sein. Unter Tracing versteht man technische Protokollierung zu Debugging-Zwecken. Das „Rad“ muss man nicht neu erfinden, aber zu Projektbeginn ein geeignetes Framework festlegen!17 . Wichtig ist es, Loglevels und Kriterien zu definieren. Weiter erleichtert instrumentierter Code die Fehlersuche. Somit ist es von Vorteil wichtige Bereiche durch Logging zu „überwachen“18 . 11.6.12 Fehlerbehandlung Das Exception-Handling der Programmiersprache ersetzt nicht ein angemessenes Ausnahme- und Fehlerbehandlungskonzept! Typische Fragen, die man sich stellen sollte, sind beispielsweise Welche Ausnahmen- und Fehlerkategorien gibt es?, In welcher Form reagieren?, Wie sieht es mit der Testbarkeit der Fehlerbehandlung aus? Tipps • Fokus auf Schnittstellen, keine leeren Catch-Klauseln • Logging klar definieren 17 18 z.B. log4j Interaktionen an Benutzeroberflächen, Interaktion zwischen Subsystemen und Komponenten, usw. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 59 Literatur Literatur IM Kecher, C. (2011). UML 2. Das umfassende Handbuch (4. Aufl.). Bonn: Galileo Press. Oestereich, B. (2009). Die UML-Kurzreferenz 2.3 für die Praxis (5. Aufl.). München: Oldenbourg Verlag. The Software Bakery · Tobias Maestrini, Bruno Leupi, Marcel Burri, Ralph Kyburz Seite 60