Informatik/Softwaretechnik 1.md

title	date	author
Softwaretechnik 1	Wintersemester 20/21	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 (<>)
• 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