• Anwender können ihre Anforderungen im Vorfeld nicht erkennen! (V-Modell XT: Auftraggeber muss alle Anforderungen im Vorfeld formulieren; V-Modell 97 und RUP: Anforderungserfassung ist Aufgabe des Auftragnehmers)
• Durchschnittswerte: Anforderungen ändern sich monatlich um 2%, ausgelieferte Software erfüllt lediglich 61% der Anforderungen, 67% der Kosten eines Projekts beruhen auf falschen Anforderungen
• Anforderungen basieren auf Wünschen → Wünsche basieren auf Anwendungsfällen
• Möglichkeiten, Anforderungen/Anwendungsfälle zu finden, siehe Tabellen S. 70 und 71 (z.B. Brainstorming, Workshop, Interview, Reviews etc.)

Ein Anwendungsfall ist eine **vollständige Systemfunktion aus der Sicht des Anwenders**, vom auslösenden Ereignis bis zum Vorliegen des gewünschten Ergebnisses. Dabei muss das auslösende Ereignis keine Anwenderaktion sein; es kann auch von einem anderen System oder aus der Systemumgebung stammen. Entsprechend kann das erwünschte Ergebnis eine Ausgabe an den Anwender, an ein anderes System oder an die Systemumgebung sein. Interne Ereignisse des Systems werden nicht betrachtet. Für jeden Anwendungsfall wird eine Bezeichnung aus einem Objekt und einem Verb gewählt. Dabei ist es nicht festgelegt, ob der Name aus Sicht des Anwenders oder des Systems formuliert wird; meist ist eine Mischung für die Verständlichkeit sinnvoll, z.B. "Getränk wählen", "Getränk zubereiten".

• Spezifikation von Use Cases (ab S. 74)
  • Ablaufskript
  • Entscheidungstabelle
    • n binäre Bedingungen erfordern 2^n Regeln; dabei muss eine Regel mit jeder enthaltenen Irrelevanz doppelt gezählt werden
  • Aktivitätsdiagramm (ab S. 76)

=

Stakeholder ist jede Person, Gruppe oder Institution, die an dem zu entwickelnden Produkt oder dessen Herstellungsprozess in irgend einer Weise – positiv oder negativ – interessiert ist. (Liste möglicher Stakeholder S. 81)

• Volere-Template und -Klassifizierung S. 81
• nicht-funktionale Anforderungen können die Systemarchitektur stärker beeinflussen als funktionale
• Anforderungen an Anforderungen (S. 83)
  • vollständig
  • eindeutig definiert / abgegrenzt
  • verständlich beschrieben
  • atomar
  • identifizierbar
  • einheitlich dokumentiert
  • notwendig
  • nachprüfbar
  • rück- und vorwärtsverfolgbar
• Verfälschung von Anforderungen
  • Bei der Wahrnehmung der Realität durch den Autor der Anforderung.
  • Bei der Formulierung der wahrgenommenen Realität durch den Autor der Anforderung.
• Mögliche Verfälschungen (S. 85)
  • Tilgung
  • unterspezifizierte Prozessworte
  • Verallgemeinerung
  • Verzerrung
• Template
  • [when][under what conditions] the system (shall | should | will) [be capable of | provide <whom> the ability to] <process> what how

    • Requirements Management
      • Requirements Engineering (Erfassung, Qualitätssicherung und Definition)
      • Requirements Tracing (Sicherstellen, dass im Laufe des Entwicklungsprozesses keine Anforderung verloren geht, und dass alles, was realisiert wird, auf einer Anforderung basiert)
      • Change Management (Umgang mit Anforderungsänderungen, Versionierung)
      • Requirements Documentation (Strukturierte Verwaltung aller Anforderungen mit Abhängigkeiten, Beziehungen, Versionen und Zugriffsrechten).

    Aufwandsermittlung
• Warum Aufwandsermittlung?
  • Angebot auf Ausschreibung. Auftrag wirtschaftlich sinnvoll (Auftraggeber/freier Markt)? Reichen die Ressourcen?
• Einflussgrößen (S. 88): z.B. Programmtyp, Qualität des Programmierers, Programmiersprache, Organisation etc.
• Methoden
  • Analogieschätzung
  • Delphi-Methode
  • Faktorenschätzung
  • COCOMO (S. 89)
  • Function Points (S. 90)
  • Use Case Points

=

Aufgabe jeder Softwareentwicklung ist es, die Lücke zwischen den Anforderungen einerseits und einem von einem Prozessor ausführbaren Code andererseits zu schließen. Die objektorientierte Analyse hat dabei die Teilaufgabe, aus den Erkenntnissen der Anforderungsanalyse ein objektorientiertes System zu modellieren, das in der Lage ist, die Anforderungen zu erfüllen.

• Wesentliche Sichten auf ein System (S. 91)
  • Funktionale Sicht – was soll das System wie tun?
  • Statische Sicht – Bestandteile und Strukturen des Systems
  • Kommunikationsstruktur – wer kommuniziert mit wem mit welchem Inhalt?
  • Kommunikationsablauf – wer kommuniziert mit wem wie in welcher Reihenfolge, um eine Aufgabe zu lösen?
  • Zustandsautomaten – wie verhält sich jedes einzelne Objekt, um seinen Beitrag zur Aufgabenlösung zu leisten?
  • (Das Zeitverhalten eines Systems - wer macht wann was wie lange / bis wann?)
  • (Der physikalische Aufbau eines Systems - welche Komponente sitzt wo?)
  • (Ablaufstrukturen - wie hängen verschiedene Teilabläufe zusammen?)
• Verantwortlichkeitsprinzip (ein Objekt übernimmt genau eine sinnvoll definierte Aufgabe im System)
  • CRC-Karten (Class-Responsibility-Collaboration, S. 92)
• Klassen finden
  • Beobachtung der realen Welt, lesen von Spezifikationen etc.
  • Textanalyse
    • Substantive → Synonyme/Attribute streichen → Verantwortlichkeit suchen
  • Historische Analyse
  • Jacobson-Verfahren
    • Objekte der realen Welt (Entity Classes)
    • Use Cases (Control Classes)
    • Schnittstellenfunktionen im Use-Case-Diagramm (Boundary Classes)
    • Swimlanes im Aktivitätsdiagramm
  • Outside-In-Analyse (S. 97, Beispiel Tastatur S. 98)
    • Boundary- und Entity-Objekte finden → unterster Layer der Architektur und Presentation Tier
    • Verantwortlichkeitsobjekte aus Aktivitätsdiagramm
    • Teilverantwortungen delegieren → nur noch eine Aufgabe je Objekt
    • Delegation "nach oben"

=

The organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts… Parts that interact through interfaces include classes, components and subsystems. (RUP)

• Sichten der Architektur (S. 94)
  • Design
  • Implementation
  • Process
  • Deployment
  • Use Case
• Architekturmuster (S. 95)

=

• Assoziation, Aggregation, Komposition (S. 99)
  • beidseitig, einseitig, undefiniert navigierbar
• Generalisierung / Spezialisierung (S. 100)
  • disjoint / non-disjoint, complete / incomplete (Default: incomplete/disjoint)

Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung

• Information Hiding
• Prinzip der einfachen Schnittstellen
• provided / required interface

=

• Use Cases
  • http://www.techfak.uni-bielefeld.de/~dstoesse/sopraWS0405/session01.pdf
  • http://www2.fbi.fh-darmstadt.de/~w.weber/SWT/useCaseDiagramm.pdf
• Aufwandsschätzung
  • http://de.wikipedia.org/wiki/Cocomo

• Praktikumsunterlagen anschauen
• Infos zu Extreme Programming
• Infos zu Zustandsautomaten
• UML-Diagrammtypen detaillierter anschauen
  • Use-Case-Diagramm
  • Aktivitätsdiagramm
    • Pins
    • Control / Object Flow
    • Beispiel von Robra (implizites Join oder so)
  • Komponentendiagramm
    • Ports (behavior port)
    • subsystem
  • Kompositions-Strukturdiagramm
  • Verteilungsdiagramm
    • Artefakte
• Eigene Aufzeichnungen zur Vorlesung durchgehen
• Infos zu COCOMO II
• Script farbig ausdrucken
• Informationen zu MVC. Welche Aufgabe hat der Controller?

• Welche Techniken zur Spezifikation von Use Cases kennen Sie?
  • Aktivitätsdiagramm, Entscheidungstabelle, Ablaufskript
• Wann ist eine Anforderung rechtlich irrelevant?
  • Wenn ihre Umsetzung im Produkt nicht zweifelsfrei nachgewiesen werden kann.
• Welche Einflüsse könnten welche Stakeholder auf den Getränkeautomaten haben?
• "Das Bezahlen kann durch Druck auf die Rückgabetaste abgebrochen werden; der Kunde erhält daraufhin sein eingeworfenes Geld zurück." Welche Fehler hat diese Anforderung? Formulieren Sie sie neu (dabei können es mehrere werden)!
  • Tilgung (Wann kann abgebrochen werden?), Verzerrung (Bekommt er tatsächlich sein Geld zurück?)
• TODO: Diagramme zum Übungsprojekt

• Für ein neuartiges Embedded System wurden 200 RFP gezählt. Es soll in C implementiert werden. Mit welchem Entwicklungsaufwand ist zu rechnen, und wie lange dauert die Entwicklung?
• Was ergibt sich mit derselben Anzahl von RFP für eine einfache Datenbankapplikation in SQL?
• Welcher Ihnen aus XP bekannte Begriff taucht oben in der Delphi-Methode auf?
  • System Metaphor (grundsätzlicher Überblick, grobes Verständnis des zu entwickelnden Produktes)

• Was bedeutet MVC?
  • Model View Controller, ein Architekturmuster, das auf drei Schichten basiert
• Welche Elementarmethode des V-Modells '97 hat mit Verantwortlichkeit zu tun?
  • CRC-Karten
• Welche Objekte liefert eine Textanalyse des Satzes "Bei jedem Münzeinwurf wird der Wert der Münze vom Münzprüfer erkannt.", und warum?
  • Münze, Münzprüfer (Wert ist lediglich ein Attribut von Münze, Münzeinwurf ist eine Tätigkeit)
• Was ist der Unterschied zwischen Assoziation, Aggregation und Komposition?
  • Aggregation → Teil-/Ganzes-Beziehung. Komposition → Aggregation mit Existenzabhängigkeit zwischen Teil und Ganzem.
• Was stellt das nebenstehende Bild dar, und was fehlt hier eigentlich?
  • Generalization Sets
• Die UML kennt zur Strukturierung von Modellelementen auch noch das Package. Warum ist es zur Architekturmodellierung nicht geeignet?
  • Packages definieren eher logische Einheiten auf Sourcecode-Ebene.
• Was ist ein Persistence Tier?
  • Die Schicht der Architektur, die die Datenhaltung übernimmt.
• Was kann ein Node enthalten?
  • Weitere Nodes und Artefakte.
• Welche Arten von Interfaces unterscheidet die UML 2?
  • provided und required