Softwaretechnik I ST I. 4 Systemanalyse



Ähnliche Dokumente
Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler

Softwaretechnologie -Wintersemester 2013/ Dr. Günter Kniesel

Softwaretechnik (Allgemeine Informatik) Überblick

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS Ohne Gewähr -

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Use Cases. Use Cases

Übung 4. Musterlösungen

Software-Engineering

Grundlagen der Softwaretechnik

Fachdidaktik der Informatik Jörg Depner, Kathrin Gaißer

Softwaretechnologie -Wintersemester 2011/ Dr. Günter Kniesel

Kapitel 2: Der Software-Entwicklungsprozess

Software-Engineering

Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler

Unified Modeling Language (UML)

Requirements Engineering für IT Systeme

Softwaretechnologie - Wintersemester 2011/12 - Dr. Günter Kniesel

Übungsklausur vom 7. Dez. 2007

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07

Exkurs: Formatvorlage für Anforderungsanalyse-Dokument

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert

1 Mathematische Grundlagen

Klausur Software-Engineering SS 2005 Iwanowski

Software Engineering in der Praxis

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Software Engineering in der Praxis Praktische Übungen

Software Engineering I

Ordner Berechtigung vergeben Zugriffsrechte unter Windows einrichten

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Abschnitt 16: Objektorientiertes Design

Objektorientierte Programmierung OOP

Software-Engineering SS03. Zustandsautomat

Softwareentwicklungspraktikum Sommersemester Grobentwurf

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

SEQUENZDIAGRAMM. Christoph Süsens

Lösungsvorschlag für Übungsblatt 6 Software Engineering 1 (WS 2012/13)

RUP Analyse und Design: Überblick

Motivation. Motivation

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Some Software Engineering Principles

Software Engineering in der Praxis

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Wiederkehrende Bestellungen. Tipps & Tricks

Urlaubsregel in David

SysML Die Zukunft des Systems Engineering?

Mai Hauptseminar: Nichtrelationale Datenbanken Historisch-Kulturwissenschaftliche Informationsverarbeitung Universität zu Köln

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom b

Probeklausur. Lenz Belzner. January 26, Lenz Belzner Probeklausur January 26, / 16

SWT II Projekt. Chat - Anwendung. Pflichtenheft 2000 SWT

Fragebogen zur Anforderungsanalyse

Vgl. Oestereich Kap 2.7 Seiten

1 Einleitung. Lernziele. automatische Antworten bei Abwesenheit senden. Einstellungen für automatische Antworten Lerndauer. 4 Minuten.

Wirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS

Klassendiagramm. Kurzer Überblick über UML - Stand BlaBla

Stellvertretenden Genehmiger verwalten. Tipps & Tricks

Einkaufslisten verwalten. Tipps & Tricks

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom Sebastian Iwanowski FH Wedel

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Requirements Engineering I

ISA Server 2004 Erstellen eines neuen Netzwerkes - Von Marc Grote

Generelle Einstellungen

Meet the Germans. Lerntipp zur Schulung der Fertigkeit des Sprechens. Lerntipp und Redemittel zur Präsentation oder einen Vortrag halten

Prüfung Software Engineering I (IB)

Die Softwareentwicklungsphasen!

Inhaltsverzeichnis : Sprachspeicher C 3000

Anleitung - Archivierung

Klausur Software Engineering für WI (EuI)

Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen. Wir bringen Qualität. Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen

Praktikum Software Engineering

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin

Softwaretechnik. Fomuso Ekellem WS 2011/12

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

PRÜFUNG. Grundlagen der Softwaretechnik

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Content Management System mit INTREXX 2002.

Systemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 -

FIS: Projektdaten auf den Internetseiten ausgeben

Use Cases. Die Sicht des Nutzers. Fortgeschrittenenpraktikum SS 2004

Bedienungsanleitung. Matthias Haasler. Version 0.4. für die Arbeit mit der Gemeinde-Homepage der Paulus-Kirchengemeinde Tempelhof

BSV Ludwigsburg Erstellung einer neuen Internetseite

Dialognetze. Ziel : Beschreibung von Methoden und Beschreibungstechniken für den Entwurf und die Dokumentation von Dialogabläufen

Vorlesung vom Einführung in die geschäftsprozessorientierte Unternehmensführung

SDD System Design Document

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Inhaltsverzeichnis. 1. Fragestellung

1. Modellierung einer Weinhandlung mit der Strukturierten Analyse (SA) 2. Modellierung einer Kassenbuchverwaltung mit der Strukturierten Analyse (SA)

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können.

Klausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007

Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent

SCHRITT 1: Öffnen des Bildes und Auswahl der Option»Drucken«im Menü»Datei«...2. SCHRITT 2: Angeben des Papierformat im Dialog»Drucklayout«...

Projektmanagement PPSAP WS 03/04. Inhaltsverzeichnis : 1. Projektmanagement

White Paper. Konfiguration und Verwendung des Auditlogs Winter Release

Prüfung Software Engineering I (IB)

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

61 WHG und 91/271/EWG-Berichterstattung Prozesse und Prüfungen für den P23R aufbereiten

Transkript:

Softwaretechnik I 4 Systemanalyse Lernziele Wissen, was man unter der Systemanalyse versteht Die Grundprinzipien der Systemanalyse erklären können Wissen, was Systemmodelle sind und welche Arten es gibt Wissen, welche Analysemethoden es gibt 2015 IAS, Universität Stuttgart 196

Softwaretechnik I 4 Systemanalyse 4.1 Grundprinzipien 4.2 Systemmodelle 4.3 Analysemethoden 4.4 Zusammenfassung 2015 IAS, Universität Stuttgart 197

4.1 Grundprinzipien Systemanalyse Ausgangspunkt Anforderungsdefinition (Lastenheft / Pflichtenheft) Ziele der Systemanalyse Abgrenzung des Systems von seiner Umgebung Detailliertes Verständnis der Systemfunktionalität Erstellung einer Systembeschreibung basierend auf einem oder mehreren Systemmodellen Präzisierung der Anforderungsdefinition 2015 IAS, Universität Stuttgart 198

4.1 Grundprinzipien Einordnung in den Entwicklungsprozess Problem Requirements Engineering Anforderungsdefinition (Lastenheft / Pflichtenheft) Systemanalyse Systemmodell Softwareentwurf Implementierung Test 2015 IAS, Universität Stuttgart 199

4.1 Grundprinzipien Beispiel (1): Anforderungsdefinition Automatisierung eines chemischen Mischers /A10/ Es sind im Rahmen eines chemischen Produktionsgangs zwei flüssige Rohstoffe zu mischen. /A20/ Eine homogene Emulsion ergibt sich nur dann, wenn die Mischungsverhältnisse exakt eingehalten werden und eine von den Rohstoffen abhängige Mischtemperatur über die gesamte Emulsionsdauer eingehalten wird. /A30/ Das Automatisierungssystem Mischersteuerung soll für beliebige Rohstoffkombinationen einsetzbar sein. /A40/ Es soll über ein Sichtgerät der Name und die Menge des Mischproduktes eingestellt werden können. /A50/ In der Mischersteuerung sollen alle möglichen Rohstoffkombinationen abgespeichert sein. 2015 IAS, Universität Stuttgart 200

4.1 Grundprinzipien Beispiel (2): Wir beginnen zu analysieren...... und stellen fest: Fragen über Fragen Wie sieht die Apparatur aus, in der gemischt wird? Gibt es bereits Wärmesensoren? Welche Temperaturbereiche treten auf? Was passiert, wenn ein Rohstoff nicht ausreicht? Welches Sichtgerät soll verwendet werden? Welche Mischprodukte gibt es? Wie kann die Rohstoffmenge, die in den Mischbehälter einfließt, gemessen werden? Welcher Rechner soll verwendet werden? Müssen neue Rohstoffe aufgenommen werden können? Wie kritisch sind die Rohstoffe? Kann etwas passieren, wenn das Mischverhältnis nicht stimmt?... und, und, und... 2015 IAS, Universität Stuttgart 201

4.1 Grundprinzipien Hauptprobleme bei der Systemanalyse Verständnis über das Problemgebiet Kommunikation mit Nicht-IT-Spezialisten Ständige Änderung der Anforderungen durch neue Erkenntnisse Erkennung von Gemeinsamkeiten Aufteilung von Arbeiten Systemanalytiker vermitteln zwischen = sehr gute, erfahrene Entwickler Kunde/Nutzer, der bestimmt, was gemacht werden soll Entwickler, der die Realisierung durchführt 2015 IAS, Universität Stuttgart 202

4.1 Grundprinzipien Systemanalyse Definition: Die Systemanalyse ist die Untersuchung eines Problemgebiets mit dem Ziel, das beobachtbare Verhalten zu beschreiben, das gewünschte Verhalten konsistent, vollständig und realisierbar zu formulieren und die funktionalen Eigenschaften sowie die quantifizierbaren Leistungsparameter mit einzubeziehen. Grundlegende Analyseschritte Abgrenzung des Systems Untersuchung des Systems Beschreibung des Systems Unter Verwendung von: Systemmodellen Analysemethoden 2015 IAS, Universität Stuttgart 203

4.1 Grundprinzipien Analyse kann auf mehreren Ebenen erfolgen Systemebene Anforderungsdefinition Systemanalyse Systemmodell vor allem bei komplexen Projekten Systementwurf Systemstruktur SW-Architektur-Ebene SW-Architektur-Analyse Architekturmodell SW-Architektur-Entwurf Softwarearchitektur SW-Komponenten-Ebene SW-Komponenten-Analyse SW-Komponenten-Entwurf Komponentenmodell Komponentenarchitektur 2015 IAS, Universität Stuttgart 204

4.1 Grundprinzipien Systemmodell Vorgabe für die Entwicklung Messlatte für das Entwicklungsergebnis Systemanalyse (Definition Soll) Soll Systemmodell Entwurf / Implementierung (Produktrealisierung) Ist Produkt Systemtest (Soll / Ist-Vergleich) Soll = Ist 2015 IAS, Universität Stuttgart 205

4.1 Grundprinzipien Anspruch an Systemmodell Korrekt und vollständig Konsistent und widerspruchsfrei Minimal Einfach zu lesen und zu verstehen Einfach zu modifizieren Kurz gesagt: Das gewünschte System soll ausreichend beschrieben werden: für den Entwurf für den (späteren) Systemtest ausreichend heißt: Ein Soll/Ist-Vergleich muss möglich sein Soll nicht erreichbar muss vermieden werden Video: Systemanalyse 2015 IAS, Universität Stuttgart 206

4.1 Grundprinzipien Verschiedene Blickwinkel der Systemanalyse Externer Standpunkt Modellierung des Kontexts und der Umgebung des Systems Verhaltensansicht Modellierung des Verhaltens des Systems Strukturelle Perspektive Modellierung der Architektur des Systems oder die Struktur der vom System verwendeten Daten Unterschiedliche Blickwinkel erfordern unterschiedliche Systemmodelltypen 2015 IAS, Universität Stuttgart 207

4.1 Grundprinzipien Analysemethoden Analysemethoden definieren: Menge von Systemmodellen Prozess zur Herleitung dieser Systemmodelle Regeln und Richtlinien, die von den Systemmodellen eingehalten werden sollen CASE-Tools unterstützen die Systemmodellierung gemäß einer Analysemethode (Beispiele: RationalRose von IBM / Rational, System Architect von Telelogic) Schwachstellen von Analysemethoden Keine Modellierung von nichtfunktionalen Anforderungen Produzieren viel Dokumentation Beinhalten keine Information, ob die Methode für das gegebene Problem geeignet ist. Systemmodelle sind manchmal zu detailliert und damit schwer zu verstehen Systemmodelle sind manchmal zu grob und enthalten damit wenig Informationen 2015 IAS, Universität Stuttgart 208

Fragen zur Vorlesung Frage zu 4.1 Welchen Aussagen stimmen Sie zu? f Systemanalytiker sind in der Regel normale Softwareentwickler f Systemanalytiker stehen zwischen den Entwicklern und den Kunden Das Systemmodell beschreibt das zu realisierende System Die Zerlegung bei der Systemanalyse erfolgt immer nach dem gleichen Prinzip Im Rahmen der Systemanalyse wird eine Systemstrukturierung vorgenommen 2015 IAS, Universität Stuttgart 209

Softwaretechnik I 4 Systemanalyse 4.1 Grundprinzipien 4.2 Systemmodelle 4.3 Analysemethoden 4.4 Zusammenfassung 2015 IAS, Universität Stuttgart 210

4.2 Systemmodelle Basistechniken zur Systemmodellierung Parameterdiagramm Internes Blockdiagramm Struktogramm Anforderungsdiagramm Blockdefinitions diagramm PAP (Programmablaufplan) ET (Entscheidungstabelle) Aktivitätsdiagramm Kollaborationsdiagramm Funktionsbaum Funktionale Hierarchie Geschäftsprozess Arbeitsablauf Datenflussdiagramm Informationsfluss Data Dictionary Datenstrukturen ER (Entity Relationship) Entitäten & Beziehungen Klassen diagramm Klassenstrukturen Pseudocode Kontrollstrukturen Regeln wenn-dann Strukturen Zustandsautomat Endlicher Automat Petri- Netz Nebenläufige Strukturen Sequenzdiagramm Interaktions- Strukturen Funktionale Sicht Datenorientierte Sicht Objektorientierte Sicht Algorithmische Sicht Regelbasierte Sicht Zustandsorientierte Sicht Szenariobasierte Sicht 2015 IAS, Universität Stuttgart 211

4.2 Systemmodelle Überblick über die Systemmodelle Architekturmodelle Beschreibung der grundlegenden Elemente und der Struktur eines Softwaresystems Verhaltensmodelle Beschreibung des Verhaltens eines Softwaresystems Regelbasierte Modelle Beschreibung der Entscheidungen bei ereignisgesteuerten Softwaresystemen Datenmodelle Beschreibung der Daten und Datenstrukturen eines Softwaresystems Objektmodelle Beschreibung eines Softwaresystems mittels Klassen und Objekten 2015 IAS, Universität Stuttgart 212

4.2 Systemmodelle Architekturmodelle (1) Use-Case-Diagramm Funktionales Modell Use-Case-Diagramm Beschreibt die Systemumgebung und Systemgrenzen Abgrenzung der internen Teile von den externen Elementen Gesellschaftliche und wirtschaftliche Belange können die Systemgrenzen beeinflussen Beispiel: Use-Case-Diagramm eines Anrufbeantworters Legende: Akteur Systemgrenze Use-Case Verbindung Benutzer Anrufbeantworter Nachricht abhören Nachricht hinterlassen Anrufer 2015 IAS, Universität Stuttgart 213

4.2 Systemmodelle Architekturmodelle (2) Funktionales Modell Darstellung einer funktionalen Hierarchie (z. B. Besteht-aus-Hierarchie oder Aufrufhierarchie) Ermöglicht es, Systemelemente nach ihrer Abstraktionsebene zu strukturieren Beispiel: Funktionsbaum eines Anrufbeantworters Anrufbeantworter Mikrophon Nachrichtenrecorder Ansagenrecorder Lautsprecher 2015 IAS, Universität Stuttgart 214

4.2 Systemmodelle Verhaltensmodelle (1) Zustandsautomat Zusicherungsdiagramm / Parameterdiagramm (SysML) Zustandsautomat Modellierung des Systemverhaltens als Reaktion auf Ereignisse Zustandsdiagramme zeigen Systemzustände und Ereignisse, die Übergänge von einem Zustand zum anderen auslösen Beispiel: Zustandsmodell eines Anrufbeantworters Legende: Anfangszustand Ansage & Aufzeichnung Mode-Knopf Name Ereignisse Zustand Übergang Mode-Knopf Nur Ansage 2015 IAS, Universität Stuttgart 215

4.2 Systemmodelle Verhaltensmodelle (2) Zusicherungsdiagramm / Parameterdiagramm beschreibt die Definition von parametrischen Beziehungen zwischen Eigenschaften von Systembausteinen wird benutzt um Einschränkungen (Gleichungen) zu beschreiben ConstraintBlocks enthalten die Gleichungen <<constraint>> Constraints Parameter Beispiel: Zusicherungsdiagramm für Parameter eines Fahrzeugs <<block>> VehicleStructure::Vehicle v <<constraintblock>> StraightLineVehicleDynamics <<constraintblock>> DistanceEquation Constraints {v = dx*dt} Parameter v: velocity x: position t: time <<constraintblock>> VelocityEquation Constraints {a = dv/dt} Parameter a: acceleration v: velocity t: time Quelle: Vogel-Heuser:, B. Vorlesung IND SWE ING, Kapitel 3, ITM, TUM <<constraintblock>> AccelerationEquation Constraints {F = m*a} Parameter F: force m: mass a: acceleration <<constraintblock>> BrakingForceEquation Constraints {f = (tf*bf)*(1-tl)} Parameter f: force tf: force bf: force tl: loss 2015 IAS, Universität Stuttgart 216

4.2 Systemmodelle Regelbasierte Modelle Regelbasierte Verhaltensmodellierung von ereignisgesteuerten Systemen Systemfunktionen werden als Regel dargestellt, die jeweils aus Bedingungen und resultierenden Aktionen zusammengesetzt sind Bedingungen stellen den aktuellen Systemzustand, ein internes oder externes Ereignis dar. Aktionen sind auszuführende Operationen oder der folgende Systemzustand Prüfbar auf Vollständigkeit, Redundanz und Widerspruchsfreiheit Beispiel: Betriebsmodi eines Anrufbeantworters R1 R2 R3 Regel Bedingung ("Wenn... ") B1 Betriebsmodi (AnsageAuf, NurAnsage) B2 Mode-Knopf AnsageAuf 1 NurAnsage 1 0 Don t care Aktion ( Dann... ") A1 Bestätigen Betriebmodiwechsel durch Ansage NurAnsage A2 Bestätigen Betriebsmodiwechsel durch Ansage AnsageAufzeichnung X X 2015 IAS, Universität Stuttgart 217

4.2 Systemmodelle Datenmodelle Beschreibung der logischen Datenstruktur, die das System verarbeitet Menge aus Entitäten des Systems, ihrer Attribute und Beziehungen Werden beispielswiese bei der Datenbankentwicklung eingesetzt Beispiel: Entity-Relationship-Diagramm von Daten eines Anrufbeantworters Legende: Name Name n Name m Entität Attribut Beziehung mit Kardinalitäten Anrufbeantworter 1 Nimmt n an Betriebsmodus Nachricht Text Datum/Zeit 2015 IAS, Universität Stuttgart 218

4.2 Systemmodelle Objektmodelle (1) Klassenmodell Vererbungsmodell Interaktionsmodell Eigenschaften von Objektmodellen Objektmodelle beschreiben das System in Form von Klassen Klassen sind eine Abstraktion aus einer Menge von Objekten mit gleichen Attributen und Operationen (Funktionen) Vor- und Nachteile Natürlicher Weg, die Objekte aus der "realen Welt" widerzuspiegeln Die Identifizierung von Klassen ist ein schwieriger Prozess, der ein gutes Verständnis der Anwendungsdomäne erfordert Höhere Abstraktion macht das Modell komplexer 2015 IAS, Universität Stuttgart 219

4.2 Systemmodelle Objektmodelle (2) Klassenmodell Klassenmodell stellt die Beziehung der Klassen untereinander dar Vergleichbar mit Entity-Relationship-Diagramm Beispiel: Teil eines Klassendiagramms des Anrufbeantworters Anrufbeantworter betriebsmodus: integer ansageaufzeichnen() ansageabspielen() nachrichtaufzeichnen() nachrichtabspielen() 1 1 * 2 Ansage text: AudioStream Nachricht text: AudioStream datum: Date 2015 IAS, Universität Stuttgart 220

4.2 Systemmodelle Objektmodelle (3) Vererbungsmodell Organisierung der Klassen in einer Hierarchie Klassen im oberen Teil der Hierarchie stellen die gemeinsamen Eigenschaften aller darunter liegenden Klassen dar Klassen erben ihre Attribute und Operationen von einer oder mehreren Superklassen Beispiel: Vererbungsmodell der Audio-Hardware des Anrufbeantworters Audio-Hardware verstärkung: integer setzeverstärkung(integer neuer Wert) Mikrophon samplingrate: integer aufzeichnen() : AudioStream Lautsprecher stummschaltung: boolean abspielen(audiostream text) 2015 IAS, Universität Stuttgart 221

4.2 Systemmodelle Objektmodelle (4) Interaktionsmodell Darstellung von Interaktionen zwischen Objekten Sequenzdiagramme (oder Kollaborationsdiagramme) in UML werden benutzt, um die Objektinteraktionen zu modellieren Beispiel: Sequenzdiagramm - Wechsel des Betriebsmodus des Anrufbeantworters Objekt :modeknopf :anrufbeantworter :ansagerecorder :Lautsprecher gedrückt() Aktivierung Selbstaufruf wechselmodus() spieleansage(aktuellermodus) spiele(ansage) Nachricht mit Argumenten Objekt-Lebenslinie o.k. o.k. 2015 IAS, Universität Stuttgart 222

Fragen zur Vorlesung Frage zu 4.2 Welchen Aussagen stimmen Sie zu? f Entscheidungstabellen beschreiben das Verhalten des Systems In Datenmodellen werden funktionale Abhängigkeiten zwischen einzelnen Systemelementen dargestellt Das Use-Case-Diagramm beschreibt nur die Schnittstelle zu anderen Systemen, Prozessen und zum Benutzer Regelbasierte Modelle können auf Vollständigkeit, Konsistenz und Widerspruchsfreiheit geprüft werden 2015 IAS, Universität Stuttgart 223

Softwaretechnik I 4 Systemanalyse 4.1 Grundprinzipien 4.2 Systemmodelle 4.3 Analysemethoden 4.4 Zusammenfassung 2015 IAS, Universität Stuttgart 224

4.3 Analysemethoden Analysemethoden Richtlinien zur Vorgehensweise im Analyseprozess Analysemodelle, um eine komplette Systembeschreibung zu erhalten Zusätzlich: Formale Regeln zur Überprüfung der Systembeschreibung auf Vollständigkeit, Widerspruchsfreiheit und Konsistenz 2015 IAS, Universität Stuttgart 225

4.3 Analysemethoden Objektorientierte Analyse (OOA) Objektorientierte Analyse (OOA) Use Case Diagramm Klassendiagramm Sequenzdiagramm Zustandsdiagramm Kollaborations - diagramm Systemabgrenzung Systemstruktur Systemverhalten 2015 IAS, Universität Stuttgart 226

4.3 Analysemethoden Beispiel: Use Case Diagramm für Anrufbeantworter Anrufbeantworter Ansage aufzeichnen Anrufer Ansage hören (und Nachricht hinterlassen) Audiostream aufzeichnen Aufgezeichnete Nachrichten abrufen Audiostream abspielen Benutzer Betriebsmodus ändern 2015 IAS, Universität Stuttgart 227

4.3 Analysemethoden Beispiel: Klassendiagramm für Anrufbeantworter Hardware status doselftest() Lautsprecher lautstärke spiele(text) Mikrophon verstärkung aufzeichnen() 1 1 1 1 1 Anrufbeantworter betriebsmodus ansageaufzeichnen() ansageabspielen() nachrichtaufzeichnen() nachrichtabspielen() 1 Nachricht NachrichtenRecorder nachrichtenzähler nachrichtabspielen() nachrichtaufzeichnen() AnsagenRecorder 1 1 1 2 * text datumzeit text Ansage ansageaufzeichnen() ansageabspielen() 1 2015 IAS, Universität Stuttgart 228

4.3 Analysemethoden Beispiel: Sequenzdiagramm für Anrufbeantworter Use Case 3: Betriebsmodus ändern :modeknopf :anrufbeantworter :ansagenrecorder :lautsprecher gedrückt() wechselmodus() spieleansage(aktuellermodus) spiele(ansage) Use Case 4: Aufgezeichnete Nachrichten abrufen :abspielknopf :anrufbeantworter :nachrichtenrecorder :lautsprecher gedrückt() [betriebsmodus = ansageundaufzeich] spielenachrichten() *[für alle Nachrichten] spiele(nachricht) 2015 IAS, Universität Stuttgart 229

Fragen zur Vorlesung Frage zu 4.3 Identifizieren Sie alle Fehler des Use-Case-Diagramms und der dazugehörigen Sequenzdiagramme Use-Case-Diagramm Sequenzdiagramm Artikel suchen Hardware-Online-Shop Kunde :Shop :Lager Kunde Artikel suchen Bestellung senden Rechnung erstellen Versand suche(artikel) Artikeldaten suche(artikel) Artikeldaten suche (Artikel) Sequenzdiagramm Bestellung senden Sequenzdiagramm Rechnung erstellen Shop Kunde Versand Vertrieb :Shop bestellen() lade Warenkorb() erstellerechnung (Bestellnummer) ladebestelldaten (Bestellnummer) Bestellbestätigung Bestellnummer Rechnung ladekundendaten() 2015 IAS, Universität Stuttgart 230

Softwaretechnik I 4 Systemanalyse 4.1 Grundprinzipien 4.2 Systemmodelle 4.3 Analysemethoden 4.4 Zusammenfassung 2015 IAS, Universität Stuttgart 231

4.4 Zusammenfassung Zusammenfassung Systemanalyse bedeutet: Abgrenzung des Systems gegenüber der Umgebung Entwicklung eines detaillierten Verständnisses des Systems Erstellung einer Systembeschreibung in Form von Systemmodellen Die Systemanalyse basiert im Wesentlichen auf der Modellierung. Ein Modell ist eine abstrakte Systemsicht. Analysemethoden integrieren verschiedene Systemmodelltypen. 2015 IAS, Universität Stuttgart 232

4.4 Zusammenfassung Vorbereitungsfragen zu 4 Frage 1: Systemanalyse (WS 06/07) Welchem Zweck dienen Use Case Diagramme im Rahmen der Systemanalyse? Nennen Sie je zwei Unterschiede und Gemeinsamkeiten von Use-Case-Diagrammen und Kontextdiagrammen der Strukturierten Analyse (SA). Frage 2: Welche Aussagen zur Systemanalyse sind richtig? (WS 06/07) Im Datenflussdiagramm werden zeitliche Abhängigkeiten zwischen einzelnen Teilprozessen dargestellt. In einem Klassendiagramm können keine Attribute vererbt werden. Entity-Relationship-Diagramme sind für den Datenbankentwurf ungeeignet. In einem Sequenzdiagramm werden Interaktionen zwischen Objekten beschrieben. Bei regelbasierten Modellen können Vollständigkeit, Konsistenz und Widerspruchsfreiheit überprüft werden. 2015 IAS, Universität Stuttgart 233