Systemanalyse - team.fh-kl.deteam.fh-kl.de/uploads/media/Systemanalyse-1NG.pdf · Während der Vorlesung und im Anschluss In der Sprechstunde ... Grundlagen, Begriffe, Konzepte 6

Systemanalyse

- Folien zur Vorlesung für AI3 im Sommersemester 2010 -

Hans-Jürgen Steffens(by courtesy of Prof. Dr. Thomas Allweyer)

Fachbereich Informatik und MikrosystemtechnikFachhochschule Kaiserslautern, Standort Zweibrücken

Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 2 von 36

Vorlesung

� Organisatorisches� Warum Systemanalyse?� Begriffe: System, Informationssystem, Modell� Was ist Systemanalyse?� Einordnung in den Software-Entwicklungsprozess� Beteiligte und Ergebnisse der Systemanalyse


Zur Person

Prof. Dr. Hans-Jürgen Steffens

� Lehrgebiet: Software-Engineering und Systemanalyse � Büro: Gebäude H, Raum 234� Telefon: (06332) 914 – 314� E-Mail: [email protected]� Homepage: www.informatik.fh-kl.de\~steffens� Sprechstunde: Mittwochs Vormittag


Organisatorisches

� Systemanalyse:� Vorlesung AI3, SS 2010

� Schriftliche Klausur� Termin wird noch bekannt gegeben


Organisatorisches zu den Übungen:

� Ablauf:� Teilnahme an den Übungen ist Pflicht!� Die Übungsblätter finden Sie unter www.informatik.fh-kl.de\~steffens

� Die Übungsaufgaben müssen vor jeder Übung bearbeitet sein und die Ergebnisse präsentiert werden können.

� Zwei erfolgreiche Präsentationen pro Teilnehmer sind obligatorisch


Hinweise

� Stellen Sie Fragen!� Frühzeitig, nicht bis vor der Klausur warten!� Was Sie nicht verstanden haben, haben andere oft auch nicht

verstanden. Ich erkläre es gerne noch einmal.� Versuchen Sie, „am Ball zu bleiben“

� Sie bekommen sonst Probleme im Seminar und vor der Klausur� Ich stehe Ihnen gerne zur Verfügung

� Während der Vorlesung und im Anschluss� In der Sprechstunde

(es können auch gesonderte Termine vereinbart werden)� Anregungen, Kritik, Probleme ...

� ... bitte frühzeitig äußern!� Ich werde versuchen, Ihre Wünsche bzgl. Inhalt und Ablauf

– soweit möglich – zu berücksichtigen.


Literatur

� Balzert, Heide:

Lehrbuch der Objektmodellierung. Analyse und Entwur f mit der UML 2.2.Auflage. Spektrum Akademischer Verlag, Heidelberg, Berlin 2004.

� Balzert, Helmut:

Lehrbuch der Software-Technik. Software-Entwicklung . 2. Auflage. Spektrum Akademischer Verlag, Heidelberg, Berlin 2000.(verwendet UML 1.4)

� Hitz, M., Kappel, G.; Kapsammer, E.; Retschitzegger, W.:

UML@Work. Objektorientierte Modellierung mit UML 2.3. aktualisierte und überarbeitete Auflage. dpunkt, Heidelberg 2005.

� Rupp, Chris, Hahn, Jürgen; Queins, Stefan; Jeckle, Mario; Zengler, Barbara:

UML 2 glasklar.2. Auflage. Hanser, München 2005.

� Jedes UML-Buch, mit dem Sie gut zurecht kommen Beachten Sie: Viele Bücher verwenden noch die UML-Version 1.4. VomPrinzip her hat sich nicht viel geändert, z.T. gibt es aber Änderungen in denDarstellungen.


Gliederung der Vorlesung

1. Einführung SystemanalyseSystemanalyse – Was? Warum? Wozu?

2. Objektorientierte Systemanalyse mit UMLVorgehensweise? Methoden und Werkzeuge?

3. Überblick über den Gesamtablauf: Aktivitätsdiagramme

4. Die Benutzersicht: Use Case Diagramme

5. Objektorientierung: Grundlagen, Begriffe, Konzepte

6. Struktur des Systems: Klassen und Klassendiagramme

7. Zusammenspiel der Objekte: Interaktionsdiagramme

8. Lebenszyklen und Zustandsänderungen von Objekten :Zustandsdiagramme

Beispiel-Anwendung:PraktischeUmsetzung


Einführung

� Warum Systemanalyse?� Begriffe: System, Informationssystem, Modell� Was ist Systemanalyse?� Einordnung in den Software-Entwicklungsprozess� Beteiligte und Ergebnisse der Systemanalyse� Ansätze der Systemanalyse:

� Strukturierte Analyse (SA)� Objektorientierte Systemanalyse (OOA)

� Analyse, Entwurf, Implementierung� OOA und OOD (Objektorientiertes Design)

� Pflichtenheft� Überblick über die Unified Modeling Language (UML)


Typische Probleme bei der Software-Entwicklung

� Unklare Anforderungen� Sich ändernde Anforderungen� Komplexität� Benutzerbedürfnisse nicht ausreichend berücksichtigt

==> Akzeptanzprobleme� Mangelnde Kommunikation zwischen Anwendern und Entwicklern� Mangelnde Kommunikation innerhalb des Entwicklungsteams� Qualitätsprobleme� Probleme beim Einhalten von Kosten- und Terminzielen


Gründe für Probleme bei der Software-Entwicklung

� Mängel bei Projektplanung und –Management� Ziele sind nicht klar� Anforderungen sind nicht klar definiert� Anwender und Entwickler sprechen verschiedene Sprachen� Vermischung von Anforderungen und Lösung� Vernachlässigung der Anforderungsanalyse zu Gunsten einer

schnellen Umsetzung� Whiscy-Syndrom: „Why isn‘t Sam coding yet?“


Notwendigkeit einer sorgfältigen Analyse

� Herausfinden, was Auftraggeber und Anwender wirklich wollen� Sicherstellen, dass Sachverhalte des Anwendungsbereichs

korrekt in die Software umgesetzt werden� Probleme werden entdeckt, bevor das System realisiert ist� Schaffung eines einheitlichen Verständnisses zwischen

Anwendern und Entwicklern sowie innerhalb des Entwicklungsteams

� Beherrschung von Komplexität � Anforderungen und Lösung sind klar voneinander getrennt� Anforderungen sind klar definiert und dokumentiert

� Grundlage für Design, Implementierung und Test der Software

� Ermöglicht Priorisierung der Anforderungen und Entscheidung über ihre Realisierung


Ziel der Systemanalyse

Wünsche und Anforderungen eines Auftraggebers an ein neues Softwaresystem ermitteln und beschreiben


System

System

Umwelt

System-grenze(Rand)

Elemente:-atomar-Subsystem

Schnittstellen

In-/Output:-materiell-Immateriell (Information)

Im Folgenden: Konzentration auf Informationssysteme


Informationssystem

� Informationssystem:� Ein System, dessen Zweck die Beschaffung, Verarbeitung,

Speicherung, Übertragung und Bereitstellung von Informationen ist.

� Umfasst Menschen, organisatorische Regelungen und technische Einrichtungen.

� Computergestütztes Informationssystem (Anwendungssystem):� Informationssystem, dessen Informationsverarbeitung teilweise

durch Computersysteme automatisiert ist.

� Computersystem:� Besteht aus Anwendungssoftware, Systemsoftware und

Hardware.


Informationssystem

Hardware

Systemsoftware

Anwendungs-software

InformationssystemComputersystem

Basis-System

FokusderSystem-analyse


Modell

Original-System Modell (-System)

Zweck

Abbildung


� Vereinfachte Abbildung eines komplexen Systems� Je nach Zweck unterschiedliche Modelle

� Das Modell muss die für den Untersuchungszweck relevanten Merkmale des Originals beinhalten

� Nutzen von Modellen:� Untersuchungen, die am Original nicht möglich wären� Reduktion von Komplexität

� Nicht relevante Sachverhalte werden weg gelassen� Kostenersparnis� Modelle, von denen (noch) kein Original existiert

� Erkennen von Risiken

� Untersuchung von Alternativen

� Grundlage für die Erstellung eines Originals (Bauplan, Blaupause)

� Im Folgenden: Modelle von Informationssystemen

Modell


� Alle Aspekte der Implementierung werden in der Analysephase ausgeklammert

� Genaue Untersuchung der Anforderungen und Erstellung einer fachlichen Lösung

� Es wird eine „perfekte Technik“ unterstellt

� Keine Performance- oder Speicherbeschränkungen, keine Verteilungsproblematik, ...

� Technische Anforderungen werden in dieser Phase lediglich dokumentiert

� Klare Trennung zwischen den Anforderungen und ihrer Umsetzung� Analyse: Nur die Anforderungen betrachtet

(Was will der Benutzer/Auftraggeber tatsächlich?)� Entwurf: Definition, wie die Anforderungen umgesetzt werden

sollen (technische Lösung)

Analyse versus Entwurf


�Team aus:� Systemanalytikern

� Kennen die Analyse-Methoden

� Fachexperten

� Kennen das Fachgebiet und dessen Regeln

� Zukünftige Benutzer

� Kennen die Anforderungen aus Anwendersicht

� Können z. B. Prototypen ausprobieren

Wer ist an der Analyse beteiligt?


� Pflichtenheft� Textuelle Beschreibung dessen, was das System zu leisten hat� Grundlage für Modellbildung

� Analysemodell (Fachkonzept)� Fachliche Beschreibung des zu realisierenden Systems� I.d.R. Grafiken (Diagramme) und Text

� Prototyp der Benutzungsoberfläche� Falls erforderlich / sinnvoll

Ergebnisse der Systemanalyse


� Konsistent� Das Modell muss allen Anforderungen der Ausgangssituation

genügen� Das Modell muss in sich widerspruchsfrei sein

� Vollständig� Alle fachlichen Funktionen, Objekte, usw. müssen erfasst sein

� Eindeutig� Es muss sich um klare Vorgaben für die Entwurfsphase

handeln, die nicht verschieden ausgelegt werden können.

� Realisierbar� Es muss sich prinzipiell mit heute vorhandener Technologie

umsetzen lassen� Wie diese Umsetzung geschieht, wird jedoch in dieser Phase

noch nicht berücksichtigt

Eigenschaften des Analysemodells


� Strukturierte Analyse (SA)� Wichtige Konzepte:

� Funktionsorientierte Zerlegung des Systems

� Kontextdiagramme (Datenaustausch mit der Umgebung)

� Datenflussdiagramme (DFD)

� Data Dictionary

� Objektorientierte Analyse (OOA)� Wichtige Konzepte:

� Objektorientierte Zerlegung des Systems

� Use Case Diagramme (Anwendungsfälle)

� Klassendiagramme (Statische Struktur)

� Interaktionsdiagramme: Sequence und Collaboration Diagramme (Dynamisches Verhalten)

Ansätze der Systemanalyse


Flugticketsverkaufen

Kunde

Finanzbuch-haltung

Fluganfrage

Flugauskunft

Flugticket-Bestellung

Flugticket

Buchungssatz

Genau ein Prozess,repräsentiertGesamtsystem

Schnittstelle Datenflüsse nach außen

Beispiel entnommen aus:Raasch, Jörg: Systementwicklung mit Strukturierten Methoden.3. Auflage. München Wien 1993.

Strukturierte Analyse: Kontextdiagramm


Flugauskunfterteilen

Flugticketausstellen

Flug

Detaillierung des Prozesses „Flugtickets verkaufen“

1

2

Flugticket-Bestellung

Flugticket

Buchungssatz

Fluganfrage

Flugauskunft

Datenspeicher


Strukturierte Analyse: Datenflussdiagramm (DFD)


� Buchungssatz = Name + Flugnr + Betrag� Flugticket-Bestellung = Name + Flugnr + Startzeit� Fluganfrage = Termin + Route� Flugauskunft = [„Flug nicht im Angebot“ | „kein Platz frei“

| Preis + Startzeit + Zielzeit + Flugnr ]� Flugticket = Name + Flugnr + Startzeit + Route + Preis� Flug = Flugnr + Flugdatum + Route + Startzeit +

Zielzeit + Preis + Anzahl_freie_Sitze� Route = Startort + Zielort� Startzeit = Datum_Zeit� Zielzeit = Datum_Zeit� Datum_Zeit = Tag + Monat + Jahr + Stunde + Minuteusw.


Strukturierte Analyse: Data Dictionary


� Verwendete Symbole und ihre Bedeutung:� = ist äquivalent� + Sequenz (und)� [..|..] Auswahl (entweder, oder)� { } Wiederholung (beliebig oft)� n{ }m Wiederholung (mindestens n mal, höchstens m mal)� 1{ } Beliebig oft, aber mindestens einmal� 2{ }5 zwei bis fünf Mal

Strukturierte Analyse: Data Dictionary


� Durchgängigkeit der Beschreibung über alle Phasen der Softwareentwicklung hinweg

� Nutzung der gleichen Konzepte für Analyse, Design und Implementierung (bei Nutzung von objektorientierten Programmiersprachen)

� Erleichtert die Nachvollziehbarkeit und Änderbarkeit

� Verständlichkeit� Objekte als Konzept aus der realen Welt intuitiv verständlich� Reduzierte Komplexität durch Bildung von gekapselten Objekten

� Wartbarkeit und Erweiterbarkeit� Änderungen an einer Stelle haben wenige Auswirkungen auf andere

Teile des Systems

� Wiederverwendbarkeit� Relativ abgeschlossene Objektdefinitionen und –implementierungen

lassen sich leicht wiederverwenden

Objektorientierte Analyse (OOA)


Analyse Entwurf

Objektorientierte Analyse (OOA)

� Fachliche Beschreibung der Systemanforderungen

� Was soll das System machen, nicht: wie soll es umgesetzt werden

� Implementierungsaspekte ausgeklammert

� Es wird von „perfekter Technik“ ausgegangen

Objektorientiertes Design (OOD)

� Erweiterung des OOA-Modells zu einem OOD-Modell

� Berücksichtigung von Effizienz- und Standardisierungsaspekten

� Erweiterung um systemnahe Klassen� Schnittstellen

� Benutzungsoberfläche

� Datenhaltung

� Verteilung

� OOD-Modell soll direkt implementierbar sein


AnalyseOOA-Modell

Pflichtenheft

Oberflächen-prototyp

OOD-Modell Fachkonzept

Entwurf

Benutzungs-oberfläche

Datenhaltung

DatenbankKlassen-bibliotheken

Verteilung

Code (z. B. Java, C++)Implementierung

Analyse und Entwurf


� Detaillierte verbale Beschreibung der Anforderungen� Enthält auch nicht-formalisierbare Anforderungen

� Können nicht in Modellen dargestellt werden� Z. B. Antwortzeiten, Sicherheitsaspekte, ...

� Beschreibt das Was, nicht das Wie� Adressaten

� Auftraggeber� Projektteam� Ausgewählte Benutzer

� Pflichtenheft ist Grundlage für juristischen Vertra g� Leistungsbeschreibung

Pflichtenheft


1. Zielbestimmung: Muss-, Wunsch- und Abgrenzungskrite rien2. Produkteinsatz: Anwendungsbereiche, Zielgruppen,

Betriebsbedingungen3. Produktübersicht4. Produktfunktionen – mit Verweis auf OOA-Modell5. Produktdaten – mit Verweis auf OOA-Modell6. Produktleistungen (z. B. bzgl. Zeit, Genauigkeit)7. Qualitätsanforderungen8. Benutzungsoberfläche (z. B. Style Guides, Zugriffsrec hte)9. Nichtfunktionale Anforderungen (z. B. bzgl. Sicherhe it, einzuhaltende

Gesetze)10. Produktumgebung: Software, Hardware, Schnittstellen , Organisatorischer

Rahmen11. Anforderungen an die Entwicklungsumgebung12. Gliederung in Teilprodukte13. Ergänzungen

Nach: Balzert, Helmut: Lehrbuch der Software-Technik. Software-Entwicklung. 2. Auflage. Heidelberg Berlin 2000.

Pflichtenheft: Muster für Grob-Gliederung


� Interview mit Auftraggeber� Interviews mit Fachleuten / zukünftigen Benutzern� Ist-Analyse:

� Wie werden die Aufgaben heute durchgeführt (ohne System / mit einem Alt-System)?

� Dokumentenanalyse� Analyse von benutzten Formularen und Belegen (Auftrag,

Rechnung, ...)� Nutzung von Beispielen

� Analyse vergleichbarer Lösungen und Systeme

Ermittlung der Anforderungen


Methode

Konzepte Notation Vorgehen

- Objekt- Attribut- Klasse- Vererbung- Assoziation...

Beispiel:Konzepte derObjektorientierung

Beispiel:Unified ModelingLanguage (UML)

- Diagramme- Text

Beispiel:Rational UnifiedProcess (RUP)

- Schritte- Regeln- Beispiele

Nach: Balzert, Heide: Lehrbuch der Objektmodellierung. Heidelberg Berlin 1999

Methode


UML: Unified Modeling Language

� Grafische Modellierungssprache (Notation) für objektorientierte Analyse und Design von Softwaresystemen

� Modelltypen zur Darstellung verschiedener Aspekte:� Anforderungsdefinition� Statische Struktur� Dynamisches Verhalten

� UML integriert verschiedene frühere objektorientierter Ansätze (Booch, Rumbaugh, Jacobson, Harel, ...)

� Standardisiert durch die Object Management Group (OMG), aktuelle Version UML 2.0

� (Viele Bücher und Tools nutzen noch UML 1.4. Grundlegende Prinzipien sind gleich, einige Darstellungen sehen etwas anders aus)

� Weite Verbreitung in der Praxis


UML – Diagrammtypen

Use Case Diagram(Anwendungsfälle)

Class Diagram(Klassendiagramm,

Struktur des Systems)

Interaction Diagrams:Sequence Diagram,

Collaboration Diagram(Interaktionen zw. Objekten)

Statechart Diagram(Zustandsänderungen

von Objekten)

Activity Diagram(Abläufe)

Implementation Diagrams:Component Diagram, Deployment Diagram

(Aufteilung in Komponentenund physische Verteilung)

Dynamisches Verhalten Statische Struktur Implementier ungsaspekte

Anforderungsdefinition

Pfeile: Typische Reihenfolge, in der die Diagrammeentwickelt werden

Documents

Systemanalyse - team.fh-kl.deteam.fh-kl.de/uploads/media/Systemanalyse-1NG.pdf · Während der Vorlesung und im Anschluss In der Sprechstunde ... Grundlagen, Begriffe, Konzepte 6