Date post: | 05-Apr-2015 |
Category: |
Documents |
Upload: | waldeburg-schlageter |
View: | 104 times |
Download: | 0 times |
Einführung in die Informationsverarbeitung
Stunde XIV: Planen und Realisieren
Manfred Thaller, Universität zu Köln
Köln 28. Januar 2008
2
?
Systemdesign / Systemplanung
3
(1) Entsteht Software, entstehen Informationssysteme als Ergebnis eines künstlerischen Prozesses?
(2) Oder sind sie planbar?
Die Grafiken dieser Stunde entstammen zum großen Teil den von M. Glinz unter http://www.ifi.unizh.ch/groups/req/ftp/ses/ bereitgestellten Materialien zu seiner Vorlesung "Spezifikation und Entwurf von Software".
I. Was heißt Planung?
4
I. Was heißt Planung?
5
I. Was heißt Planung?
6
Der eben beschriebene Vorgang, angewendet auf informationstechnische Probleme: Requirements Engineering.
Ia. Requirements Engineering
7
Requirements Engineering bildet Modelle eines Ausschnitts der Realität.
Ia. Requirements Engineering
8
Systeme sind daher immer in einen Kontext eingebettet, der den direkt für den Entwurf des Systems relevanten Bestandteil der Realität beschreibt.
Ia. Requirements Engineering
9
Requirements Engineering legt die Grenzen des Systems gegenüber dem Kontext fest.
Ia. Requirements Engineering
10
Unterschiedliche, aus einander abgeleitete, Betrachtungsebenen
Anforderung aus der Realität:Auf dem bestehenden Schiennenetz sollen mehr Leute transportiert werden.
Daraus abgeleitete Anforderung an das System:Die Minimaldistanz zwischen zwei Zügen ist immer größer als der maximale Bremsweg des nachfolgenden Zuges.
Daraus abgeleitete Anforderung an das umzusetzende Informationssystem ("die Software"):Der maximale Bremsweg muss alle 100 ms neu berechnet werden.
I. Was heißt Planung?
11
Wie kann man die formalisierte Beschreibung der Anforderungen in einen Gesamtprozess eingliedern, der ein Projekt zur Erzeugung eines Informationssystems insgesamt beschreibt?
Konzept des Systems Designs / Software Engineering.
I b 1. Wasserfallmodell
12
I b 2. Iteratives Vorgehen
13
I b 3. „Extreme Programming“
14
I b 4. „Ohne Namen“
15
II. Wie kann man Planen?
16
Gesucht ist eine Ausdrucksweise für Planungen, die: Ihre BenutzerInnen zur Disziplin zwingt.Die Kommunikation über unterschiedliche Planungen erlaubt.
90‘er Jahre: Verschiedene Ansätze als Bestandteil des objektorientierten Paradigmas in der Softwareentwicklung.James Rumbaugh: Object Modelling Technique (OMT)Grady Booch: Booch MethodeIvar Jacobson: Object Oriented Software Engineering (OOSE)
Konvergenz seit 1996 zur UML (Unified Modelling Language) als allgemeine „Modellierungssprache“
II 0. UML 2.0 (2003 / 04 ff.)
17
UML ist eine Sammlung von "graphischen Sprachen", d.h. Regelsystemen für die Konstruktion graphischer Schemata, die:unterschiedliche Perspektiven von Anforderungen an Systeme und Entwürfen von Systemteilen, sowie deren Zusammenwirken darstellen,einander dabei überlappen können undunabhängig voneinander verwendet werden können.
Am wichtigsten:Klassenmodelle beschreiben den strukturellen Aufbau eines Systems,Anwendungsfallmodelle (Use Cases) beschreiben die Interaktion mit dem System aus Benutzersicht.
II 1. Klassendiagramme
18
Objekt „Mitarbeiter“(kann Attribute und Methoden haben) Programmierung
II 1. Klassendiagramme
19
Binäre Assoziation beschreibt die Beziehungen zwischen Klassen
II 1. Klassendiagramme
20
Multiplizität gibt an, wie viele Objekte an einer Assoziation beteiligt sein können.
II 1. Klassendiagramme
21
Reflexive Assoziation verbindet Objekte einer Klasse miteinander.
II 1. Klassendiagramme
22
Aggregation verbindet beliebig viele Klassen zu einer übergeordneten.
II 1. Klassendiagramme
23
Generalisierungsbeziehung zwischen Superklasse und Subklasse.
II 2. Anwendungsfalldiagramme
24
Das Verhalten eines Systems kann als Sammlung von Anwendungsfällen ( = use cases) beschrieben werden.
Ein Anwendungsfall beschreibt eine Klasse möglicher Interaktionen.
Konkrete Anwendungsfälle heißen auch Szenarien. ( scenario based design.)
Anwendungsfälle werden in strukturiertem Text beschrieben.
Alle möglichen Anwendungsfälle - oder ein für ein bestimmtes Teilsystem relevanter Teil - werden als Anwendungsfalldiagramm realisiert.
II 2. Anwendungsfalldiagramme
25
Anwendungsfall als strukturierter Text (auch als Aktivitäts – oder Zustandsdiagramme)
Beispiel: "Buch an einem Selbstausleiheautomaten ausleihen"
Normallfall:1.BenutzerIn liest Ausweis in System ein; System validiert Ausweis.2. BenutzerIn wählt "Ausleihen"; System aktiviert Ausleihfunktion.3.BenutzerIn liest Buchcode ein; System identifiziert das Buch, registriert Ausleihe, deaktiviert das Diebstahletikett.
Sonderfälle:
II 2. Anwendungsfalldiagramme
26
Akteur
II 2. Anwendungsfalldiagramme
27
Anwendungsfall
II 2. Anwendungsfalldiagramme
28
Anwendungsfall-diagramm
II 2. Anwendungsfalldiagramme
29
Include:Bindet anderenAnwendungsfall ein, der an mehreren Stellen genutzt werden kann.
II 2. Anwendungsfalldiagramme
30
Extend:Modelliert Varianten, die einen Basisanwendungsfall abwandeln.
II 3. Zustandsdiagramme
31
Zustandsdiagramme modellieren das dynamische zeitliche Verhalten eines Systems.
Auch state machine state diagram
Mögliche Zustände der Objekte einer Klasse oder eines Teilsystems.
Dynamik des Systemverhaltens: Reaktionen auf äußere Ereignisse.
II 3. Zustandsdiagramme
32
II 4. Aktivitätsdiagramme
33
Aktivitätsdiagramme beschreiben Abläufe in einem System.
Verbinden Aktivitäten, einen Steuerfluss und Objektzustände miteinander.
Erinnern stark an traditionelle "Flussdiagramme" (und haben auch alle ihrer Nachteile).
II 4. Aktivitätsdiagramme
34
II 5. Interaktionssicht
35
Ziel: Darstellung der Interaktion ausgewählter Objekte in zeitlicher Folge.
Entweder als Sequenzdiagramme, die die Zeitachse in den Mittelpunkt rücken …
… oder als Zusammenarbeitsdiagramme die Objektstruktur und Aufrufe der Objekte in den Vordergrund rücken.
(Beide Diagrammtypen sind logisch äquivalent!)
II 5. Interaktionssicht
36
Als Sequenzdiagramm …
II 5. Interaktionssicht
37
… und als Zusammenarbeitsdiagramm.
II 6. Paketdiagramme
38
Ziel: Aufteilung eines großen auf mehrere kleine Systeme.
Innerhalb der Pakete müssen Namen eindeutig sein – aber eben nicht zwischen Ihnen.
(Vgl. Namespacekonzept in XML.)
II 6. Paketdiagramme
39
II 7. Komponentendiagramme
40
Ziel: Aufteilung der Gesamtfunktionalität eines Systems auf mehrere Softwaremodule, die:
Möglichst unabhängig voneinander entwickelt / gewartet werden können.Nur über genau definierte Schnittstellen miteinander kommunizieren.
II 7. Komponentendiagramme
41
II 8. Verteilungsdiagramme
42
Ziel: Aufteilung der Gesamtfunktionalität eines Systems auf mehrere Hardwaremodule (Server).
II 7. Verteilungsdiagramme
43
44
Schöne Ferien!