Zusammenfassung - Software Bakery

Transcription

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-
• 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
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
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!
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)
1
IM HS13, Kp 3
siehe dazu auch Modul „Software Komponenten“, Kapitel 1 (Frühlingssemester 2013)
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
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).
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)).
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!)
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
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“
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>)
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.
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.?“.
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.
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
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!
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:
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
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
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
[email protected]
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
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
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
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.
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)
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!
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?“
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
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
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.
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}
Mengenverarbeitung
Zeitskala
Teil 2/4Verarbeite
Daten
Erzeuge
Daten
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
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
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
«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
Objektdiagramm
«Stereotyp1,
Stereotyp2»
Abbildung
9: Anwendungsfälle in UML
Paket::Klasse
attribut
Abstrakte
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
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.
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
UnabAbhängigkeit
Abhängige
hängige
Sichtbarkeit Attributname : Paket::Typ [Multiplizität
Ordnung] = Initialwert {Eigenschaftswerte}
Klasse
Klasse
Multiplizität
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
Anbieter
«interface»
Schnittstelle-A
Klasse
Vererbung
Nutzer
«interface»
Schnittstelle-A
Klasse2
* {ordered}
Sichtbarkeit rolle
A
O
Klasse2
i:Element
Parametrisierbare Klasse
«interface»
Schnittstelle
operation1()
operation2()
Klasse1
Notiz
Attributierte Assoziation
Seite 29
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
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()
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 SpezifikationSeite 320
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
Zustand 1
nachricht2
Zustand
[vorbedingung] aufruf() /
[nachbedingung]
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]
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
Aktive
Klasse
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
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()
«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
«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
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
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
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
«core business process»
Kern-Geschäftsprozess
aber maximal maxint-mal, falls die Bedingung [bed.] wahr ist
Sichtbarkeit:
+ public element
# protected element
– private element
~ package element
Sequenzdiagramm
Anwendungsfall
operation1()
operation2()
attribut
operation()
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}
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
Zustandslinie
nachricht()
Sek.: 0 1 2
Reservierungswunsch
Ausnahme-Parameter
(Exception)
(Partition A)
Schritt 1
nachricht3()
nachricht1()
Zustand B
Zustand C
Schritt 2
Objektfluß
Schritt 2
Erzeuge
Daten
Partition B
nachricht2()
[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
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]
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
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.
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»
«artifact»
Artefakt
Enthaltenes
Unterpaket
Seite 7
Komponentendiagramm
6.4.2
«component»
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
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
• 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
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
{<10ms}
Zeitskala
Seite 33
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
«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
Klasse1
Klasse2
Assoziationsklasse
Klasse2
Aggregation
Klasse2
Teil
Ganzes
Existenzabhängiges
Teil
Qualifizierer
Objekt
Klasse2
Komposition
Klasse1
:Klasse
Aktive
Klasse
Klasse1
«include»
Objektdiagramm
Sichtbarkeit:
+ public element
# protected element
– private element
~ package element
Beziehungen
«feature»
EinFeature
Innenorientierter
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
Abbildung 14: Assoziationen
* {ordered}
Sichtbarkeit rolle
rolle
Klasse
Nutzer
Leserichtung
«Stereotyp»
Beziehungsname
«interface»
Schnittstelle
operation1()
operation2()
Klasse2
Notiz
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
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!
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
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.
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.
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)
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
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
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.
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
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)
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
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
£ 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
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
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.
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.
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
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
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.
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
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
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).
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().
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
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.
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.
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.
Seite 60

Zusammenfassung - Software Bakery

Transcription

Similar documents

zusammenfassung swk

PDF, 597 KB

NCR SelfServ Checkout Datasheet

PDF-Download - HL7 Deutschland eV

Architekturzentrierte agile

Moderne Softwareentwicklung

Studierenden-Newsletter Liebe GFA

pdf (1/1)

Einführung in die STL anhand eines ausgewählten Beispiels

Vorlesung Softwaretechnik - Lehrstuhl für Betriebliche

Folien

Benutzerhandbuch Linksys ATA SPA2102 für Arcor

Unternehmen - Hochschule Macromedia

Activity Diagram

Hurrikan - pro

Der TFS in der Praxis