779 lines
30 KiB
Markdown
779 lines
30 KiB
Markdown
---
|
||
title: Softwaretechnik 1
|
||
date: Wintersemester 20/21
|
||
author: Robert Jeutter
|
||
---
|
||
|
||
> Software: Menge von Programmen oder Daten zusammen mit begleitenden Dokumenten, die für Ihre Anwendung notwendig oder hilfreich sind [Hesse]
|
||
|
||
Gute Software ist schwer herzustellen
|
||
- Entspricht Kundenwünsche, Vollständigkeit
|
||
- Funktioniert Korrekt
|
||
- Kosten- und Termintreue bei der Erstellung
|
||
- weitere nicht-funktionale Qualitätsforderungen
|
||
- Benutzerfreundlichkeit, Ergonomie
|
||
- Sicherheit
|
||
- Zuverlässigkeit, Fehlertoleranz
|
||
- Performanz
|
||
- Ressourcen-Effizienz, Skalierbarkeit, Übertragbarkeit
|
||
- Wartbarkeit, Änder- und Erweiterbarkeit
|
||
|
||
Softwaretechnik
|
||
- Technische Disziplin der Software Herstellung
|
||
- Zielorientierte Bereitstellung uns systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen [Balzert]
|
||
|
||
Wie kann man Software besser entwickeln?
|
||
- Ingenieursmäßige Herangehensweise
|
||
- Verwendung bekannter Prinzipien und Methoden
|
||
- Systematische Vorgehensweise
|
||
- Verwendung von:
|
||
- Abstraktion, Modelle, Notation, Simulation
|
||
- Wiederverwendung:Muster, Komponenten, Framework
|
||
- Organisation
|
||
- Arbeitsteilung, Integration, Planung
|
||
- Verwendung von Werkzeugen
|
||
- IDE (Integrated Development Environment)
|
||
- Versionierung, Bugtracker, Modellierungswerkzeug
|
||
|
||
# Modellierungskonzepte
|
||
> Modell: ist eine Abstraktion eines Systems mit der Zielsetzung, das Nachdenken über ein System zu vereinfachen, indem irrelevante Details ausgelassen werden [Brügge]
|
||
$\rightarrow$ Beschreibung eines Ausschnitts der Realität
|
||
|
||
- erstellen einer Abstraktion
|
||
- abbilden signifikanter Eigenschaften
|
||
- Deskriptiv/präskriptiv (real oder geplant)
|
||
- Sichtweise auf ein System (Struktur, Verhalten, Zustand,...)
|
||
- heißt Weglassen
|
||
- setzt Verstehen voraus
|
||
- ist nicht automatisierbar
|
||
|
||
Verschiedene Modelle:
|
||
- Analysemodell
|
||
- Entwurfsmodell
|
||
- Implementierung (-smodell)
|
||
- Vorgehensmodell
|
||
- Produktmodell
|
||
- Dokumentation, Alternativen-Auswahl
|
||
|
||
Modelle für:
|
||
- Sichten
|
||
- Funktionen
|
||
- Daten
|
||
- Algorithmen
|
||
- Systemumgebung
|
||
- Dynamisches Verhalten
|
||
- Objektorientierte Modelle
|
||
|
||
## Klassische Modelle
|
||
- Funktionen:
|
||
- Funktionsbaum
|
||
- Hierarchische Dekomosition der Fkt
|
||
- nummerieren der Ebenen/Funktionen möglich
|
||
- Bsp: Abonnement Verwaltung
|
||
- Blockschaltbild
|
||
- eingebettetes System, HW/SW
|
||
- Daten
|
||
- Data Dictionary
|
||
- Verzeichnis von Daten mit Strukturinformationen
|
||
- Backus-Naur-Form, kontextfreie Grammatik
|
||
- Entity Relationship Diagram
|
||
- Daten und ihre Beziehungen
|
||
- Systemumgebung
|
||
- Datenflussdiagramm
|
||
- Fluss und Transformation von Daten zwischen Funktionen, Speichern und Schnittstellen
|
||
- kein Kontrollfluss
|
||
- Algorithmen
|
||
- Entscheidungstabelle
|
||
- Regelbasierte Beschreibung
|
||
- Bedingung
|
||
- Aktionen
|
||
- Reduktionsregeln
|
||
- Pseudocode
|
||
- von Programmiersprache abstrahierende, detaillierte Beschreibung eines Algorithmus
|
||
- Programmablaufplan
|
||
- Grafische Beschreibung des Kontrollflusses
|
||
- DIN 66001
|
||
- Unstrukturiert
|
||
- Struktogramm
|
||
- Nassi-Shneidermann-Diagramm
|
||
- keine Sprünge
|
||
- Dynamisches Verhalten (diskrete Zustände und atomare zustandübergänge)
|
||
- Zustandsautomat
|
||
- Verhalten mit Zuständen und -übergängen
|
||
- Automatenmodelle und -theorie
|
||
- Ggf zerlegung oder kommunizierende Automaten
|
||
- Flow-Chart
|
||
- Ereignisgesteuerte Prozesskette (EPK)
|
||
- Geschäftsprozesse
|
||
- BPM
|
||
- Petri-Netz (ggf. mit Zeitmodell)
|
||
- Grafische Beschreibung von Nebenläufigkeit und Synchronisation
|
||
- Objektorientierte Modelle
|
||
- Klassendiagramme
|
||
- UML
|
||
|
||
|
||
## Objektorientierung
|
||
- bessere Strukturierung für komplexe Zusammenhänge
|
||
- Abstraktere Sichtweise
|
||
- Grundprinzip: Zerlegung; Teile und Herrsche
|
||
- ein System besteht aus vielen Objekten
|
||
- ein Objekt hat
|
||
- definiertes Verhalten
|
||
- Menge genau definierter Operationen
|
||
- Operation wird beim Empfang einer Nachricht ausgeführt
|
||
- inneren Zustand
|
||
- Zustand des Objekts ist Privatsache
|
||
- Resultat einer Operation hängt vom aktuellen Zustand ab
|
||
- eindeutige Identität
|
||
- Identität ist unabhängig von anderen Eigenschaften
|
||
- Mehrere verschiedene Objekte mit identischem Verhalten und identischem inneren Zustand im gleichen System möglich
|
||
- Klasse
|
||
- Gleichartige Objekte mit ggf. verschiedenen Zuständen
|
||
- Verhaltensschema – Operationen
|
||
- Innere Struktur – Attribute
|
||
|
||
Vorteile der Objektorientierung
|
||
- Zuständigkeitsbereiche
|
||
- Daten, Operationen und Zustand: lokal und gekapselt
|
||
- Klare Schnittstellen
|
||
- Definiertes Objektverhalten, Nachrichten
|
||
- Hierarchie
|
||
- Vererbung und Polymorphie (Spezialisierung), Klassenschachtelung
|
||
- Baukastenprinzip
|
||
- Benutzung vorgefertigter Klassenbibliotheken, Anpassung durch Spezialisierung (mittels Vererbung)
|
||
|
||
|
||
## Unified Modeling Language
|
||
- Grafisches Beschreibungsmittel für Aspekte des Softwareentwurfs diskreter Systeme
|
||
- Spezifikation, Entwurf, Visualisierung, Konstruktion, Dokumentation von Software
|
||
- Für OO-Softwareentwicklung und -prozess geeignet
|
||
- UML ist weder Methode noch Prozess
|
||
|
||
Warum UML?
|
||
- Objektorientierung ist zur Zeit das vorherrschende Modellierungs-Paradigma, Industrie-Standard
|
||
- Kombination von Struktur-, Verhaltens-, Interaktions-, und Verteilungsmodellen
|
||
- Für Analyse, Entwurf, Implementierung und Test einsetzbar
|
||
- Gute Werkzeugunterstützung für Editieren, Versionierung, Codegenerierung
|
||
- Erweiterbarkeit der UML mit Stereotypen und Tags
|
||
- Semi-formale Modelle, z.T. verschiedene Interpretationen
|
||
- Offenheit: Erweiterung mit stereotypes, tags, constraints
|
||
|
||
Nachteile UML
|
||
- UML ist in vielen Facetten nicht präzise festgelegt
|
||
- Werkzeuge für Transformation, Analyse etc. fehlen noch
|
||
- UML ist keine „kleine Sprache“: Lernaufwand notwendig
|
||
- Komponenten sind nicht adäquat darstellbar
|
||
- Sprachen wie die UML werden erlernt durch Übung!
|
||
- Aber: LV SWT ist kein kompletter UML-Kurs
|
||
|
||
### Überblick über Modelle
|
||
- 14 Diagrammarten
|
||
- Struktur-Diagramme
|
||
- Klassen-, Objekt-, Komponenten-, Kompositions-Struktur-,
|
||
- Paket- und Verteilungsdiagramm
|
||
- Profildiagramm – zur UML-Erweiterung
|
||
- Verhaltens-Diagramme
|
||
- Use-Case-, Aktivitäts- und Zustandsdiagramms
|
||
- Interaktionsdiagramme: Sequenz-, Kommunikations-, Timing- und Interaktionsübersichts-Diagramm
|
||
|
||
#### Use-Case-Diagramm
|
||
- Beschreiben Systemfunktion aus Benutzersicht (Was, nicht Wie)
|
||
- Erste Anforderungsspezifikation (requirements)
|
||
- Planbare Einheiten als Inkremente für die Entwicklung
|
||
- Keine Modellierung eines Ablaufs!
|
||
- Erstellen von Testfällen (test case generation)
|
||
- Grundelemente
|
||
- Anwendungsfall: Use Case
|
||
- Beteiligte: Aktor
|
||
- Verfeinerung mittels Use-Case-Realisierung notwendig
|
||
- Textuelle Beschreibung
|
||
- Verhaltensdiagramme
|
||
|
||
#### Klassendiagramm
|
||
- Modellierung der Struktur (Aufbau) eines Systems
|
||
- Modellierung von statischen Aspekten
|
||
- Modellierung der Struktur von Daten
|
||
- Klasse im Mittelpunkt
|
||
- Aufbau: Attribute, Operationen
|
||
- Beziehungen zueinander: Assoziationen, Vererbung
|
||
- Verbreitetstes und bekanntestes Diagramm der UML
|
||
|
||
#### Objektdiagramm
|
||
- Struktur des Systems zur Laufzeit zu einem Zeitpunkt
|
||
- Tatsächliche Zusammenhänge und Belegungen von Attributen von Objekten zu einem Zeitpunkt
|
||
- Eine detaillierte Sicht auf einen Aspekt
|
||
- Keine vollständige Beschreibung (zu komplex)
|
||
- Für kompliziertere Abhängigkeiten (z.B. Rekursion)
|
||
- Objektdiagramm für alle Arten von Exemplaren
|
||
- z.B.: Klasse (Objekt), Komponente, Knoten, ...
|
||
- Keine Exemplare von Operationen -> Ablauf -> Verhaltensdiagramme / Interaktionsdiagramme
|
||
- Kein Verlauf der Wertebelegung über die Zeit
|
||
|
||
#### Paketdiagramm
|
||
- Gliederung (Strukturierung) des Systems in Teile (Pakete)
|
||
- Zuordnung von Elementen zu einem Paket
|
||
- Bildung von Hierarchien (Enthält-Beziehung)
|
||
- Abhängigkeiten zwischen den Paketen
|
||
- "Include" von Quellcode-Dateien (<<import>>)
|
||
- Anwendung:
|
||
- Zum Grobentwurf von Systemen
|
||
- Definition von Schichten
|
||
|
||
#### Komponentendiagramm
|
||
- Strukturierung des Systems durch Komponenten
|
||
- Komponente: Modulare, austauschbare Einheit (Substitution)
|
||
- Modellierung der Abhängigkeiten zwischen Komponenten
|
||
- Modellierung der inneren Struktur von Komponenten
|
||
- Definition von Schnittstellen
|
||
|
||
#### Kompositionsstrukturdiagramm
|
||
- Teile-Ganzes-Strukturen -> Kompositionsstruktur
|
||
- Strukturell statische Kompositionsstrukturen:
|
||
- Kurzschreibweise bei vielen Kompositionen
|
||
- Modellierung des Aufbaus komplexer Systeme
|
||
- Strukturell dynamische Kompositionsstrukturen:
|
||
- Notwendige Strukturen zur Realisierung eines Verhaltens
|
||
- Definition von Rollen, zur Lösung wiederkehrender Probleme -> Modellierung von Mustern
|
||
- Starke Verwandtschaft mit dem Klassendiagramm
|
||
- Spezialisierte Kompositionsbeziehung -> erweiterte Semantik
|
||
|
||
#### Aktivitätsdiagramm
|
||
- Modellierung von
|
||
- Kontrollflüssen
|
||
- Datenflüssen
|
||
- Parallelem Verhalten
|
||
- Verzweigungen, bedingten und gewichteten Abläufen
|
||
- Geschäftsprozessmodellierung möglich
|
||
- Abstrakte und detaillierte Verhaltensbeschreibung möglich
|
||
- Grundlage zur Codegenerierung
|
||
- Zur Verfeinerung von
|
||
- Use-Cases
|
||
- Operationen / Interaktionen
|
||
- anderen Aktionen und Aktivitäten
|
||
|
||
#### Interaktionsdiagramme
|
||
- Modellierung von
|
||
- Kommunikation zwischen Kommunikationspartnern (Lebenslinie)
|
||
- Operationen (Modellierung eines Programms)
|
||
- Informationsaustausch / Nachrichten
|
||
- Gemeinsames Grundkonzept der Interaktionsdiagramme
|
||
- Sehr detaillierte Diagramme
|
||
- Meist nicht zur vollständigen Beschreibung eines Systems
|
||
- Betrachtung eines wichtigen Teilaspekts
|
||
- Grundlage zur Codegenerierung
|
||
|
||
#### Sequenzdiagramm
|
||
- Genaue zeitliche Abfolge von Nachrichten
|
||
- Umfangreichstes Interaktionsdiagramm
|
||
- Kontrollelemente möglich (Schleifen, Verzweigungen)
|
||
|
||
#### Kommunikationsdiagramm
|
||
- Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund
|
||
- Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen
|
||
|
||
#### Timing-Diagramm
|
||
- Genaue zeitliche Darstellung von Zustandsübergängen
|
||
- Kommunikation abhängiger Zustandsautomaten
|
||
- Modellierung einzelner Interaktion
|
||
|
||
##### Prinzipieller Aufbau
|
||
- Zeitlicher Verlauf senkrecht
|
||
- Kommunikationspartner waagerecht (unsortiert)
|
||
- Lebenslinie
|
||
- Rechteck mit gestrichelter senkrechter Linie
|
||
- Start, Ende und Dauer der Ausführung einer Operation
|
||
- Rekursive Aufrufe möglich
|
||
- Ereignisspezifikation
|
||
- Stelle des Sendens / Empfangens der Nachricht
|
||
- Definition der Reihenfolge des Auftretens
|
||
- Trace: Folge von Sende- und Empfangsereignissen
|
||
|
||
##### Weitere Elemente des Sequenzdiagramms
|
||
- Nachrichten ohne Sender
|
||
- z.B. am Beginn einer Interaktion
|
||
- Verlorene Nachrichten (ohne Empfänger)
|
||
- Nachricht ohne dargestellten Empfänger
|
||
- z. B. am Ende einer Interaktion
|
||
- Erzeugen von Lebenslinien
|
||
- Gestrichelte Linie mit geöffnetem Pfeil
|
||
- Keine Rückgabenachricht
|
||
- Zeitliche Einrückung des Rechtecks
|
||
- Zerstören von Lebenslinien
|
||
- Durchgezogene Linie mit Dreieckende
|
||
- Kann Rückgabenachricht erzeugen
|
||
|
||
##### Nachrichten in Interaktionsdiagrammen
|
||
- Ereignis des Sendens bzw. Empfangens von Nachrichten
|
||
- Typen:
|
||
- Operationsaufruf (synchron / asynchron)
|
||
- Antwort Nachricht
|
||
- Signal (asynchron), Create-/ Delete Message
|
||
- Operationsaufruf: Parameterliste muss kompatibel sein
|
||
- Nachrichtentypen
|
||
|
||
#### Zustandsdiagramm
|
||
- Modellierung des (vollständigen?) Verhaltens
|
||
- Zustände von Klassen / Objekten / Komponenten
|
||
- Übergänge zwischen den Zuständen
|
||
- Ereignisse, die Zustandswechsel auslösen
|
||
- Modellierung von endlichen Automaten (Zustandsmaschinen)
|
||
- Deterministische
|
||
- Nichtdeterministische
|
||
- Verfeinerung von Zuständen möglich
|
||
- Modellierung von verteilten Systemen / parallelem Verhalten
|
||
- Grundlage zur Codegenerierung
|
||
|
||
|
||
# Analyse
|
||
- Einordnung in den Projektablauf
|
||
- Was ist eine Anforderung?
|
||
- Merkmal, Eigenschaft, Bedingung oder Einschränkung eines Systems
|
||
- Notwendig für die Akzeptanz vom Kunden
|
||
- Definition (IEEE 610.12-1990)
|
||
- Dokumentierte Darstellung einer Fähigkeit oder Eigenschaft
|
||
- von Anwender benötigt zur Problemlösung bzw. um Ziel zu erreichen
|
||
- Muss von System oder Komponente erfüllt werden, um Vertrag oder Standard zu erfüllen
|
||
|
||
- Funktionale Anforderungen - Was soll es tun?
|
||
- „...Legt eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder Service dar“ [Balzert]
|
||
- Was leistet das System
|
||
- Welche Funktionen bietet es
|
||
- Wie interagiert es mit der Umgebung
|
||
- Anforderungen an:
|
||
- Verhalten
|
||
- Struktur
|
||
- (Alternativ: Statik, Dynamik, Logik)
|
||
- Nichtfunktionale Anforderungen – Wie?
|
||
- „...legen qualitative oder quantitative Eigenschaften des Softwareprojektes oder einer Komponente fest“ [Balzert]
|
||
- Auch Bezeichnet als:
|
||
- Quality of Service
|
||
- Qualitätsanforderungen
|
||
- Arten - FURPS (ISO 9126):
|
||
- Functionality (Funktionalität)
|
||
- Usability (Benutzbarkeit)
|
||
- Reliability (Zuverlässigkeit)
|
||
- Performance (Effizienz) / Portability (Übertragbarkeit)
|
||
- Supportability (Änderbarkeit/ Wartbarkeit)
|
||
|
||
- Funktionalität
|
||
- Angemessen, Genauigkeit
|
||
- Sicherheit: Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit
|
||
- (Nicht ausreichend spezifizierte funktionale Anforderung)
|
||
- Benutzbarkeit
|
||
- Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität
|
||
- Zuverlässigkeit
|
||
- Reife (Fehler-Anzahl), Fehlertoleranz, Wiederherstellbarkeit
|
||
- Effizient/ Leistungsanforderungen
|
||
- Zeitverhalten, Verbrauchsverhalten, Wirtschaftlichkeit
|
||
- Portabilität
|
||
- Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit
|
||
- Wartbarkeit
|
||
- Analysierbarkeit, Änder- und Erweiterbarkeit, Stabilität (bei Änderungen), Testbarkeit
|
||
- Weitere:
|
||
- Konformität zu Konventionen und Bestimmungen
|
||
- Interoperabilität zu anderen Systemen
|
||
- Implementierungsanforderungen
|
||
- Schnittstellenanforderungen
|
||
- Skalierbarkeit (Änderungen des Problemumfangs)
|
||
- Betriebliche und rechtliche Rahmenbedingungen
|
||
- Liefer- und Verpackungsanforderungen
|
||
|
||
### Nichtfunktionale Anforderungen
|
||
Schwierigkeit nichtfunktionaler Anforderungen
|
||
- Hängen oft von Verhalten ab: daher komplex und nicht direkt sichtbar
|
||
- „Das Auto hat vier Räder“ (Struktur)
|
||
- „Wenn der Blinker betätigt wird, blinkt das Auto dreimal wenn die Zündung an ist; ansonsten wird das Standlicht einseitig eingeschaltet“ (Korrektes Verhalten)
|
||
- „Das Motorsteuergerät darf innerhalb von 5 Jahren und 150.000km Laufleistung höchstens mit 0.1% Wahrscheinlichkeit ausfallen“ (Zuverlässigkeit)
|
||
|
||
Umgang mit nichtfunktionalen Eigenschaften
|
||
- Nicht direkt „by construction“ zu realisieren
|
||
- Naive Herangehensweise: Ignorieren!
|
||
- Entwerfen und Implementieren der Software ohne Berücksichtigung nichtfunktionaler Eigenschaften
|
||
- Testen der nichtfunktionalen Eigenschaften
|
||
- Wenn nicht erfüllt: Entwurf und Implementierung ändern!
|
||
- Funktioniert nur bei sehr einfachen Systemen, bzw. wenn nichtfunktionale Eigenschaften nicht wichtig sind!
|
||
|
||
Sinnvoller Umgang mit nichtfunktionalen Eigenschaften
|
||
- Untersuchung der Projektrisiken bereits in der Analysephase
|
||
- größte Risiken zuerst betrachten!
|
||
- Immer fragen: Geht das so überhaupt?
|
||
- Festlegungen des Entwurfs möglichst früh gegen Anforderungen prüfen – aber wie?
|
||
- Modellbasierter Entwurf
|
||
- Modellierung des Systems und seiner Umwelt
|
||
- Bewertung des Modells (Simulation)
|
||
- Lehrveranstaltungen Systementwurf, KIS, LTS
|
||
|
||
Randbedingungen
|
||
- „... Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.“
|
||
- Werden nicht umgesetzt
|
||
- Schränken Lösungsraum ein
|
||
- Beispiele:
|
||
- Kosten
|
||
- Durchlaufzeit: Time to Market
|
||
- Vorgaben durch Marketing und Vertrieb
|
||
- Technische Randbedingungen (nichtfunktionale Anforderung)
|
||
|
||
|
||
|
||
|
||
Geforderte (Meta-)Eigenschaften
|
||
- Vollständig: alle Szenarien sind beschrieben
|
||
- Konsistent: keine Widersprüche
|
||
- Eindeutig: nur eine Interpretation möglich
|
||
- Korrekt: genaue und richtige Darstellung
|
||
- Realistisch: unter geg. Einschränkungen implementierbar
|
||
- Überprüfbar: durch Tests am Endprodukt nachweisbar
|
||
- Rückverfolgbar: Auswirkungen bis zur Implementierung nachvollziehbar (Testfälle, Auswirkung von Änderungen)
|
||
- Klassifizierbar (Risiko, Priorität, Dringlichkeit, Nutzen ...)
|
||
- Validierung mit dem Kunden
|
||
|
||
- Requirements Engineering
|
||
- Ermittlung, Analyse und Verwaltung von Anforderungen
|
||
- Ausgangspunkt: Projektidee
|
||
- Anforderungsermittlung
|
||
- requirements elicitation, requirements definition
|
||
- Bestimmen und dokumentieren der Anforderungen an das geplante System
|
||
- Beteiligt: Entwickler, Kunde, Benutzer
|
||
- Ergebnis: Anforderungsspezifikation - Glossar, Vertrag, Lastenheft
|
||
- Anforderungs-Analyse
|
||
- requirements analysis, system modeling
|
||
- Beschreibung im Detail und formal strukturiert
|
||
- Beteiligt: Entwickler
|
||
- Ergebnis: funktionale Spezifikation - Produktdefinition, Analysemodell, Pflichtenheft
|
||
|
||
|
||
|
||
| | Anforderungsermittlung | Systemmodellierung |
|
||
| -- | -- | -- |
|
||
| Ergebnis | Anforderungsspezifikation im Lastenheft, Glossar, Lastenheft | funktionale Spezifikation in Produktdefinition, Analysemodell, Pflichtenheft |
|
||
| Notation | Text | Text + (semi-) formales Modell |
|
||
| Kommunikation | mit dem Kunden | zwischen Entwicklern |
|
||
| Sichtweise | des Anwenders | äußere Systemaspekte |
|
||
Vor allem: Kommunikationsleistung!
|
||
|
||
Bedeutung:
|
||
- Falsche Anforderungen führen zu falschem System
|
||
- Frühe Fehler im Entwicklungsprozess sind teuer!
|
||
|
||
Fehlerentstehung und Fehlerquellen bei Anforderungserfassung
|
||
- 83% sprachliche Fehler (Un- bzw. Missverständlich)
|
||
- 75% Logische Fehler (Widersprüchlichkeit, Redundanz)
|
||
- 73% Inhaltliche Fehler (Falsche Sachverhalte, Unvollständig)
|
||
|
||
## Ermiteln von Anforderungen
|
||
Woher kommen Anforderungen?
|
||
- Ausgangspunkt
|
||
- Projektidee, schriftliche Skizze
|
||
- Kurz und knapp
|
||
- Stichpunkte der wichtigsten Funktionen
|
||
- Lastenheft (falls schon existiert)
|
||
- Interessenhalter (stakeholder)
|
||
- Identifizieren, Wichtigkeit bewerten (berücksichtigen?)
|
||
- Ansprechpartner? Interessen und Erwartungen
|
||
- Fachexperten, Verantwortliche, Betroffene
|
||
|
||
Beteiligte Rollen
|
||
- Endbenutzer
|
||
- Aufnahme Ist-Zustand, Domänenwissen, Anforderungen
|
||
- Kunde
|
||
- Definiert Ziel des Systems, Vertragsverhandlung
|
||
- Konfigurationsmanager
|
||
- Revisionsgeschichte der Dokumente, Nachvollziehbarkeit
|
||
- Architekt
|
||
- Integration von Anwendungsfall- und Objektmodellen
|
||
- Analytiker
|
||
- Modelliert das System und erstellt Anwendungsfälle
|
||
- Redakteur
|
||
- Prüfer
|
||
|
||
Wie ermittelt man Anforderungen?
|
||
- Problem: Entwickler müssen sich in Begriffs- und Denkwelt des Kunden einarbeiten, sonst Kommunikationsprobleme
|
||
- Systematische Vorgehensweise
|
||
- Kommunikation mit Kunden
|
||
- Geschäftsprozess (business process)
|
||
- fachlicher Ablauf, der Wert oder Kosten verursacht
|
||
- Akteur (actor)
|
||
- Benutzer, Schnittstelle nach außen
|
||
- Szenario (scenario)
|
||
- Interaktion mit System als Ablauf
|
||
- Anwendungsfall (use case)
|
||
- Automatisierter Arbeitsschritt, vom System ausgeführt
|
||
- Interviews mit Fachanwendern
|
||
- Mitschrift, später strukturierter Text und Tabelle
|
||
- Strukturierte Spezifikation
|
||
- Vorlagen / sprachliche Anforderungsschablonen
|
||
- Formulare
|
||
- Reduzierung sprachlicher Mehrdeutigkeiten
|
||
- Anwendungsfalldiagramm (Use-Case-Diagramm)
|
||
- Arbeitsschritt eines Geschäftsprozesses, der durch das System ausgeführt wird
|
||
- Anforderungen an das System modellieren – was soll das System leisten
|
||
- Systemgrenzen / Systemkontext festlegen
|
||
- Systembeteiligte modellieren
|
||
- Planbare Einheiten als Schritte für die Entwicklung
|
||
- Verwendung bereits ab Projektbeginn
|
||
- Keine Modellierung eines Ablaufs!
|
||
- Umgang mit Szenarien und Anwendungsfällen
|
||
- Zunächst nur zum Verständnis kurz aufstellen
|
||
- Systemgrenze definieren
|
||
- Beschreibungen verfeinern
|
||
- Änderungen mit Kunden abstimmen
|
||
- Prototypen nur zur visuellen Unterstützung
|
||
- Benutzungsschnittstelle erst beginnen, wenn funktionale Anforderungen in etwa klar sind
|
||
|
||
Leitfaden für Anwendungsfälle
|
||
- Benennen mit Verbalphrasen, die Anwendersicht beschreiben (Simuliere)
|
||
- Akteure mit Substantiven benennen (Anwender)
|
||
- Systemgrenzen klären. Arbeitsschritte von Akteuren und System kennzeichnen
|
||
- Schritte im aktiven Stil beschreiben (Auto bremst)
|
||
- Ursächliche Beziehung zwischen Folgeschritten
|
||
- 1 Anwendungsfall = 1 vollständige Transaktion
|
||
- Normalfall darstellen; Ausnahmen gesondert beschreiben
|
||
- Nicht die Benutzungsschnittstelle beschreiben (statt dessen visuellen Prototypen verwenden)
|
||
- Übersichtlichkeit (max. 2-3 Seiten), sonst zerlegen
|
||
|
||
- Typische Probleme
|
||
- Kommunikations- und Verständnisprobleme
|
||
- Viele verschiedene Beteiligte
|
||
- Kunden wissen nicht, was sie genau wollen und was geht
|
||
- Verwendung von Fachsprachen
|
||
- Widersprüchliche Anforderungen, verschiedene Interessen
|
||
- Nicht-technische organisatorische, historische oder rechtliche Rahmenbedingungen
|
||
- Zusätzliche Beteiligte können auftauchen
|
||
- Anforderungen ändern sich während der Entwicklung
|
||
- Anforderungsänderungen
|
||
- Sind die Regel
|
||
- Tätigkeiten der Anforderungsanalyse
|
||
- Anforderungen strukturieren
|
||
- Eigenschaften der Anforderungen bestimmen
|
||
- Anforderungen priorisieren
|
||
- Anforderungen in Textform, Grafiken, Modellen dokumentieren
|
||
- Anforderungen modellieren
|
||
- Anforderungen auf inhaltliche Qualität prüfen
|
||
- Auf Übereinstimmung mit den Zielen prüfen
|
||
- Ziel Abnahme der Anforderung
|
||
- Hängt mit Analyse des Systems zusammen
|
||
- Anforderungen strukturieren
|
||
- Unterteilung
|
||
- Funktional, Nichtfunktional
|
||
- Muss, Kann,... oder Haupt- und Nebenanforderung
|
||
- Hierarchische Zerlegung
|
||
- Unterteilen, Verfeinern
|
||
- Ordnung festlegen, eindeutig Nummerieren
|
||
- auf Einmaligkeit achten
|
||
- Beziehungen festhalten
|
||
- Verwendung von Werkzeugen
|
||
- MS-Project, Doors, Git issues, Trac, Bugzilla, MKS,...
|
||
- Modellierungswerkzeuge
|
||
- Eigenschaften bestimmen
|
||
- Wahl der Eigenschaften firmen- bzw. projektspezifisch
|
||
- Wichtige Eigenschaften
|
||
- Identifikationsnummer
|
||
- Kurzbezeichnung
|
||
- Beschreibung (Text, ggf. Grafik, Modell)
|
||
- Aufwand
|
||
- Priorität der Anforderung
|
||
- Bearbeitungsstatus / Restaufwand
|
||
- Zugeordnet (wer ist verantwortlich / bearbeitet)
|
||
- Querverbindungen zu anderen Anforderungen
|
||
- Ggf. zusätzliche Dokumente oder Bemerkungen
|
||
- Stabilität der Anforderung (Änderungswkt.)
|
||
- Kritikalität der Anforderung: Schäden bei Fehlern?
|
||
- Entwicklungsrisiko: Erfolgsaussichten der Umsetzung
|
||
- Abnahmekriterien / Erfüllungsnachweis durch?
|
||
- Anforderungstyp: Funktional, nicht funktional ,...
|
||
- Anforderungssicht: Dynamik, Statik, Logik, Struktur, Funktion
|
||
- Mögliche Konflikte
|
||
- Autor
|
||
- Quelle: Wer möchte die Anforderung umgesetzt haben?
|
||
- Status der Beschreibung: Idee, grober Inhalt, detailliert
|
||
- Anforderungsversion
|
||
- Anforderungen priorisieren
|
||
- MuSCoW-Priorisierung
|
||
- Muss-, Kann-, Optional, Nicht (Abgrenzungskriterien) (must, should, could, won‘t)
|
||
- Ad-hoc: Stakeholder priorisiert Anforderungen
|
||
- Priorisierungsmatrix / Kosten-Wert-Analyse
|
||
- Eigenschaften bewerten (Punkte vergeben)
|
||
- Werte gewichten
|
||
- Priorität berechnen $Prioritäten = \frac{Nutzen - Nachteil}{Kosten + Risiko}$
|
||
- Kano-Klassifikation
|
||
- Basiseigenschaften: Werden vorausgesetzt (fehlen stört, wenig zusätzliche Zufriedenheit)
|
||
- Leistungseigenschaften: Sonderwünsche
|
||
- Begeisterungseigenschaften: Wird nicht erwartet
|
||
- Abfragen per Fragenkatalog
|
||
- Reihenfolge festlegen
|
||
|
||
|
||
|
||
|
||
|
||
## Objektorientierte Analyse und Systemmodellierung
|
||
- Übersicht
|
||
- Aufgabe: Systemmodell erstellen, funktionale Spezifikation
|
||
- Beschreibung der Systembenutzung und des Verhaltens
|
||
- Was, nicht wie – Implementierungsaspekte ausklammern
|
||
- Nicht: Datenhaltung, Verteilung, Technologien, Architektur, ..
|
||
- Zusammenhang mit Anforderungsspezifikation
|
||
- OO: Modell des Anwendungsbereichs
|
||
- Analysemodell
|
||
- Korrekt, vollständig, konsistent und nachprüfbar
|
||
- Struktur und Verhalten
|
||
- Verschiedene Sichten (OO, Strukturiert, ...)
|
||
- Eingangsdokumente
|
||
- Lastenheft, Anforderungsspezifikation
|
||
- Typische Ergebnisse
|
||
- Funktionales Modell
|
||
- Geschäftsprozesse und Anwendungsfälle
|
||
- Objektmodell
|
||
- Dynamisches Modell – Systemverhalten
|
||
- Zustands- und Sequenzdiagramme
|
||
- Vor- und Nachbedingungen von Systemoperationen
|
||
- Prototyp / Spezifikation Benutzungsschnittstelle
|
||
- Pflichtenheft
|
||
- Objektorientierte Analyse nach [Brügge / Dutoit]
|
||
- Verdeutlicht iterativen Ablauf
|
||
- Unterteilung des Analysemodells in:
|
||
- Funktionales Modell (Anwendungsfälle)
|
||
- Objektmodell (Klassen und Objektdiagramme)
|
||
- Dynamisches Modell (Zustands- und Sequenzdiagramme)
|
||
- Unterscheidung der Objekttypen
|
||
|
||
|
||
|
||
|
||
- Heuristik Sprache $\rightarrow$ OO-Modell
|
||
- Objektarten im Systemmodell
|
||
- Entitätsobjekte – vom System verwaltete Informationen
|
||
- Grenzobjekte – Interaktion zwischen System und Akteuren
|
||
- Steuerungsobjekte – Durchführung der Anwendungsfälle
|
||
- Identifizierung von Entitätsobjekten
|
||
- Begriffe, die klargestellt werden müssen
|
||
- Wiederkehrende Substantive in Anwendungsfällen
|
||
- Heuristiken
|
||
- Reale Objekte, die das System kennen muss
|
||
- Reale Prozesse, die das System verfolgen muss
|
||
- Anwendungsfälle
|
||
- Datenquellen und -senken
|
||
- Artefakte, mit denen der Nutzer interagiert
|
||
- Identifizierung von Grenzobjekten
|
||
- Elemente der Benutzungsschnittstelle
|
||
- Formulare für Eingaben
|
||
- Nachrichten, Rückmeldungen
|
||
- Endgeräte
|
||
- In der Begriffswelt des Anwenders bleiben!
|
||
- Schnittstellen grafisch skizzieren bzw. Prototyp!
|
||
- Identifizierung von Steuerungsobjekten
|
||
- Koordination von Grenz- und Entitätsobjekten
|
||
- Abarbeitung von Anwendungsfällen
|
||
- Reihenfolge von Schritten
|
||
- Informationen übernehmen und weiterleiten
|
||
- Oft ein Steuerungsobjekt pro Anwendungsfall
|
||
- Beispiel: Simulationsszenario
|
||
- Verhaltensmodell sinnvoll! Im folgenden: dynamische Modelle
|
||
|
||
- Abläufe der Anwendungsfälle modellieren
|
||
- Ziel - Objekte finden
|
||
- Klassen identifizieren
|
||
- Verhalten / Operationen finden
|
||
- Use Case durch Interaktion verfeinern
|
||
- einfacher kurzer Ablauf: textuelle Beschreibung, Aktivitätsdiagramm
|
||
- Ablauf mit Verzweigungen, Parallelitäten: Aktivitätsdiagramm (Kontrollflussmodellierung)
|
||
- datengetriebener Ablauf: Aktivitätsdiagramm (Objektflussmodellierung)
|
||
- Interaktion zwischen den Objekten wichtig: Kommunikationsdiagramm, Aktivitätsdiagramm (Aktivitätsbereiche), Sequenzdiagramm
|
||
- zeitliche Abfolge steht im Mittelpunkt: Sequenzdiagramm
|
||
- Zustandswechsel / zeitliche Abfolge von Zuständen: Zustandsdiagramm / Timing-Diagramm
|
||
- komplexe Abläufe mit Verzweigungen und Parallelitäten: Interaktionsübersichtsdiagramm
|
||
- komplexe Abläufe ohne Verzweigungen und Parallelitäten: weitere Verfeinerung durch Use-Case-Diagramm
|
||
- komplexer strukturierter Ablauf: Kollaboration aus dem Kompositionsstrukturdiagramm
|
||
|
||
- Dynamische UML-Modelle
|
||
- Abläufe
|
||
- Aktivitätsdiagramm (activity diagram)
|
||
- Kommunikationsdiagramm (communication diagram)
|
||
- Sequenzdiagram (sequence diagram)
|
||
- Zeitdiagramm (timing diagram)
|
||
- Zustandsabhängiges Verhalten von Objekten
|
||
- Zustandsautomat (state chart diagram)
|
||
|
||
- Aktivitätsdiagramm
|
||
- Aktion – einzelner Schritt
|
||
- Aktivität
|
||
- Beschreibt einen Ablauf / repräsentiert ein Verhalten
|
||
- Beinhaltet eine Folge Aktionen, Kontroll- oder Objektknoten
|
||
- Schachtelung von Aktivitäten und Aktionen
|
||
- Aktionen in Aktivitäten enthalten
|
||
- Aktionen durch Aktivitäten verfeinerbar
|
||
- Aktivitäten beschreiben / verfeinern
|
||
- Aktionen, Use Cases, Interaktionen, Operationen ...
|
||
- Ein- und Ausgabeparameter in Form von Objekten
|
||
- Parameterknoten entsprechend Pins der aufrufenden Aktion
|
||
- Alternativ: Parameterangabe mit Name und Typ
|
||
- Angabe von Vor- und Nachbedingungen möglich
|
||
- Optional: Parameter unter Aktivitätsnamen
|
||
|
||
- Verfeinerung der Aktionen durch Aktivitäten
|
||
- Aktion durch Interaktionen verfeinern
|
||
- Detaillierte Diagramme
|
||
- Meist entwurfsnah
|
||
- Verfeinerung der Aktionen durch StateChart
|
||
- Objekte zusammenstellen und klassifizieren
|
||
- Toolunterstützung (Möglichkeiten stark toolabhängig)
|
||
- Objekte Ergebnis der Verhaltensmodellierung
|
||
- Ergebnis Verhaltensdiagramm: Operationen der Klassen
|
||
- Klassen generalisieren / spezialisieren $\rightarrow$ Klassenhierarchie
|
||
- Übergang zum Entwurf
|
||
- Klassenstruktur festlegen
|
||
- Spezifikation von Benutzungsschnittstellen
|
||
- Skizzieren, Prototyp generieren, Spezialwerkzeuge
|
||
- Klassen und Operationen in Funktionen
|
||
- Gestaltung MMI, style guides, Standards
|
||
|
||
## Dokumentation von Anforderungen
|
||
- Lastenheft
|
||
- Gesamtheit der Forderungen eines Auftraggebers (AG) an die Lieferungen und Leistungen eines Auftragnehmers (AN), manchmal Vertragsbasis
|
||
- Muss-Kriterien, Kann-Kriterien, Abgrenzungskriterien
|
||
- Pflichtenheft
|
||
- Entwurf aus AN-Sicht, Umsetzung des Lastenhefts
|
||
- Meist Vertragsbasis
|
||
- Inhalt Anforderungsspezifikation
|
||
- Zielsetzung
|
||
- Allgemeine Beschreibung
|
||
- Umgebung, generelle Funktion, Restriktionen, Benutzer
|
||
- Spezifische funktionale Anforderungen
|
||
- möglichst quantitativ (z.B. Tabellenform)
|
||
- eindeutig identifizierbar (Nummern)
|
||
- Spezifische nicht-funktionale Anforderungen
|
||
- z.B. Antwortzeit, Speicherbedarf, HW/SW-Plattform
|
||
- Entwicklungs- und Produkt-Standards
|
||
- Qualitäts-Zielbestimmung
|
||
- Zu erwartende Evolution des Systems, Versionen
|
||
- Abkürzungsverzeichnis, Glossar, Index, Referenzen
|
||
|
||
|
||
Pflichtenheft (Beispiel)
|
||
1. Einleitung, Zielbestimmung
|
||
2. Übersicht
|
||
- Einsatzbereich, Zielgruppen
|
||
- Produkt-Umgebung
|
||
- Produkt-Funktionen
|
||
- Restriktionen
|
||
- Annahmen und Abhängigkeiten
|
||
- Vorhandenes System (ggf.)
|
||
3. Vorgeschlagenes System
|
||
- Übersicht
|
||
- Funktionale Anforderungen
|
||
- Benutzungsschnittstelle
|
||
- Nichtfunktionale Anforderungen
|
||
- Systembeschreibung
|
||
- Szenarien
|
||
- Anwendungsfälle
|
||
4. Glossar
|
||
|
||
|
||
# Grobentwurf
|
||
|
||
|
||
# Feinentwurf
|
||
# Implementierung
|
||
# Vorgehensweise
|
||
# Projektmanagement |