diff --git a/Softwaretechnik.md b/Softwaretechnik.md new file mode 100644 index 0000000..e351043 --- /dev/null +++ b/Softwaretechnik.md @@ -0,0 +1,779 @@ +--- +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 \ No newline at end of file