Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 7. Januar 2010.

Ähnliche Präsentationen


Präsentation zum Thema: "Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 7. Januar 2010."—  Präsentation transkript:

1 Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 7. Januar 2010

2 Rekapitulation 2 Der Gang der Argumentation 1.Der Rohstoff: Information 2.Darstellung der Information auf dem Rechner: Datenstrukturen. 3.Verarbeitung der Information auf dem Rechner: Algorithmen. 4.Verbindung der Bausteine im Kleinen: Simulationen 5.Verbindung der Bausteine im Großen: Google 6.Abstrakte Lösungen für den Entwurf von Systemen: Graphen

3 3 ?

4 Systemdesign / Systemplanung 4 (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 bereitgestellten Materialien zu seiner Vorlesung "Spezifikation und Entwurf von Software".

5 Ein ernstes Problem … 5 Erfolg von IT Projekten laut Umfragen: 45,2 % aller Softwareprojekte erfolgreich. 19,4 % Zeit- und Kostenüberschreitungen. 35,4 % Fehlschläge.

6 Ein ernstes Problem … 6 In Abhängigkeit von der Teamgröße. Erfolgreiche Projekte bei einer Teamgröße von: Bis 4 Personen 60 % 4 – 8 Personen 38 % 8 – 20 Personen 32 % Mehr als 20 Personen 18 %

7 I. Was heißt Planung? 7

8 8

9 9 Der eben beschriebene Vorgang, angewendet auf informationstechnische Probleme: Requirements Engineering.

10 Ia. Requirements Engineering 10 Requirements Engineering bildet Modelle eines Ausschnitts der Realität.

11 Ia. Requirements Engineering 11 Systeme sind daher immer in einen Kontext eingebettet, der den direkt für den Entwurf des Systems relevanten Bestandteil der Realität beschreibt.

12 Ia. Requirements Engineering 12 Requirements Engineering legt die Grenzen des Systems gegenüber dem Kontext fest.

13 Ia. Requirements Engineering 13 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.

14 I. Was heißt Planung? 14 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.

15 I b 1. Wasserfallmodell 15

16 I b 2. Iteratives Vorgehen 16

17 I b 3. Extreme Programming 17

18 I b 4. Ohne Namen 18

19 II. Wie kann man Planen? 19 Gesucht ist eine Ausdrucksweise für Planungen, die: Ihre BenutzerInnen zur Disziplin zwingt. Die Kommunikation über unterschiedliche Planungen erlaubt. 90er Jahre: Verschiedene Ansätze als Bestandteil des objektorientierten Paradigmas in der Softwareentwicklung. James Rumbaugh: Object Modelling Technique (OMT) Grady Booch: Booch Methode Ivar Jacobson: Object Oriented Software Engineering (OOSE) Konvergenz seit 1996 zur UML (Unified Modelling Language) als allgemeine Modellierungssprache

20 II 0. UML 2.0 (2003 / 04 ff.) 20 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 und unabhä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.

21 II 1. Klassendiagramme 21 Objekt Mitarbeiter (kann Attribute und Methoden haben) Programmierung

22 II 1. Klassendiagramme 22 Binäre Assoziation beschreibt die Beziehungen zwischen Klassen

23 II 1. Klassendiagramme 23 Multiplizität gibt an, wie viele Objekte an einer Assoziation beteiligt sein können.

24 II 1. Klassendiagramme 24 Reflexive Assoziation verbindet Objekte einer Klasse miteinander.

25 II 1. Klassendiagramme 25 Aggregation verbindet beliebig viele Klassen zu einer übergeordneten.

26 II 1. Klassendiagramme 26 Generalisierungsbeziehung zwischen Superklasse und Subklasse.

27 II 2. Anwendungsfalldiagramme 27 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.

28 II 2. Anwendungsfalldiagramme 28 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:

29 II 2. Anwendungsfalldiagramme 29 Akteur

30 II 2. Anwendungsfalldiagramme 30 Anwendungsfall

31 II 2. Anwendungsfalldiagramme 31 Anwendungsfall- diagramm

32 II 2. Anwendungsfalldiagramme 32 Include: Bindet anderen Anwendungsfall ein, der an mehreren Stellen genutzt werden kann.

33 II 2. Anwendungsfalldiagramme 33 Extend: Modelliert Varianten, die einen Basisanwendungsfall abwandeln.

34 II 3. Zustandsdiagramme 34 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.

35 II 3. Zustandsdiagramme 35

36 II 4. Aktivitätsdiagramme 36 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).

37 II 4. Aktivitätsdiagramme 37

38 II 5. Interaktionssicht 38 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!)

39 II 5. Interaktionssicht 39 Als Sequenzdiagramm …

40 II 5. Interaktionssicht 40 … und als Zusammenarbeitsdiagramm.

41 II 6. Paketdiagramme 41 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.)

42 II 6. Paketdiagramme 42

43 II 7. Komponentendiagramme 43 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.

44 II 7. Komponentendiagramme 44

45 II 8. Verteilungsdiagramme 45 Ziel: Aufteilung der Gesamtfunktionalität eines Systems auf mehrere Hardwaremodule (Server).

46 II 7. Verteilungsdiagramme 46

47 47 Herzlichen Dank!


Herunterladen ppt "Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 7. Januar 2010."

Ähnliche Präsentationen


Google-Anzeigen