--- 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 (<>) - 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) ![Analysebaum von Sommerville](Assets/Softwaretechnik_%20Analyseformen1.png) ![Analysebaum von Sommerville](Assets/Softwaretechnik_%20Analyseformen2.png) 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 ![Anforderungsentwicklung von Balzert](Assets/Softwaretechnik_Anforderungsentwicklung.png) | | 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 ![Kano Klassifikation von Balzert](Assets/Softwaretechnik_Kano1.png) ![Kano Klassifikation von Balzert](Assets/Softwaretechnik_Kano2.png) ## 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 ![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik_Bruegge1.png) ![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik_Bruegge2.png) - 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