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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 3 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 4 von 36
Organisatorisches
� Systemanalyse:� Vorlesung AI3, SS 2010
� Schriftliche Klausur� Termin wird noch bekannt gegeben
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 5 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 6 von 36
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.
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 7 von 36
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.
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 8 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 9 von 36
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)
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 10 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 11 von 36
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?“
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 12 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 13 von 36
Ziel der Systemanalyse
Wünsche und Anforderungen eines Auftraggebers an ein neues Softwaresystem ermitteln und beschreiben
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 14 von 36
System
System
Umwelt
System-grenze(Rand)
Elemente:-atomar-Subsystem
Schnittstellen
In-/Output:-materiell-Immateriell (Information)
Im Folgenden: Konzentration auf Informationssysteme
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 15 von 36
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.
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 16 von 36
Informationssystem
Hardware
Systemsoftware
Anwendungs-software
InformationssystemComputersystem
Basis-System
FokusderSystem-analyse
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 17 von 36
Modell
Original-System Modell (-System)
Zweck
Abbildung
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 18 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 19 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 20 von 36
�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?
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 21 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 22 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 23 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 24 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 25 von 36
Flugauskunfterteilen
Flugticketausstellen
Flug
Detaillierung des Prozesses „Flugtickets verkaufen“
1
2
Flugticket-Bestellung
Flugticket
Buchungssatz
Fluganfrage
Flugauskunft
Datenspeicher
Beispiel entnommen aus:Raasch, Jörg: Systementwicklung mit Strukturierten Methoden.3. Auflage. München Wien 1993.
Strukturierte Analyse: Datenflussdiagramm (DFD)
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 26 von 36
� 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.
Beispiel entnommen aus:Raasch, Jörg: Systementwicklung mit Strukturierten Methoden.3. Auflage. München Wien 1993.
Strukturierte Analyse: Data Dictionary
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 27 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 28 von 36
� 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)
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 29 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 30 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 31 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 32 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 33 von 36
� 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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 34 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 35 von 36
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
Prof. Dr. Hans-Jürgen Steffens Systemanalyse SS 201 0 36 von 36
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