Kapitel 4 - Prozess der Analyse

Wozu gibt es die Risikoanalyse und wie wird sie durchgeführt?

• Gibt es Konkurrenz?
• Welche Technologien verwenden? (web, DMBS, Languages)
• Welche Markteinflüsse beeinflussen das Projekt?
• Anzahl zu erwartender Benutzer
• Zukunftstrends einbeziehen
• Wurde das Problem vom Kunden verstanden?
• Problemdimensionierung (Transactions per time, angenommen Laufzeit für verschiedene Funktionen)
• Welche Altsysteme müssen angebunden werden?

Wie identifiziert man Systemgrenzen und Akteure?

1. Wer benutzt das System (Mensch oder System)?
2. Wer wartet es?
3. Wer fährt es herunter?
4. Wer bekommt Infos aus dem System?
5. Wer füttert es mit Daten?
6. Was passiert automatisch im System?

Wie identifiziert man Anwendungsfälle? (Use Cases)

Modellierungshilfen

Was ist ein Szenario?

• Ist ein Spezieller Pfad durch die Use-Cases aus sicht des Users
• Primäre (Basic Path) und sekundäre Pfade (anderer nebenläufige Pfade)
• Kombiniert man alle Pfade erhält man einen Kompletten Use Case

Was ist der Umfang eines Projektes und warum ist er so wichtig?

Modellierung in UML- grundlegende Fragen

• data-centered Methoden wie ERD, Data-Flow-Diagramme, Statusdiagramme
• strukturelle Methoden
• scenario basierte Methoden (Verhaltensanalyse)
• UML (Objektmodelle aus den Use Cases)
• UMD - Use Case Diagramm zeigt Akteure, Use Cases und die Beziehungen
• Strukurdiagramme für Klassen und Pakete (Gruppen von Klassen)
• Verhaltensdiagramme für dynamisches Verhalten und Systemaktivitäten
• Implementationsdiagramm mit Komponentendiagramm (relationen zwischen Programmeinheiten) und Deploymentdiagramm (Kommunikation zwischen Komponenten)

1. Wer sind die User des Systems? = Akteure
2. Welche sind die Hauptobjekte?
3. Welche Objekte werden für welchen Use Case gebraucht?

Was beschreibt man alles in einem Klassendiagramm?

• liefern die Statische Sicht der Software - Problem, da OO-Komplexität von Zusammenspiel der Methoden abhängt
• Domain Class Modellierung
• Business Modell (definiere die wichtigsten Einheiten des Systems und ihre Relationen)
• Statische Semantik (Klassenhierarchie beschreibt technische Struktur der Problemdomäne) kann auf Business Modell basieren
• Ein Klassendiagramm enthält alle Klassen und Beziehungen (Generalisierung, Assoziierung, Aggregation, Komposition) und stellt somit auch die Hierarchie dar

Wie modelliert man ein GUI (Graphical User Interface)?

• Erst wird Handbuch geschrieben, dann der Code
• Dabei werden parallel GUI's entworfen, die bei Use-Cases verwendet werden können
• Window Navigation Diagramme zeigen Relationen zwischen Fenstern

Wozu gibt es die Robustness-Analyse?

1. Boundary Objects (Akteure welche mit System kommunizieren)
2. Entity Objects (Objekte des Domänenmodells-Hauptentities)
3. Control Objects (Verbinden Boundary und Entity Objekte)

• Das Robustness-Diagramm ist die Schnittstelle zwischen dynamischem und Statischem Teil eines Projektes
• Dabei gehört zum dynamischen Teil die Use Cases und Sequenzdiagramme und zum statischen das Domain Modell und das Klassendiagramm
• Durch das Robustness-Diagramm wird es einfacher den Überblick zu halten

Warum und wie konstruiert man Sequenzdiagramme?

Was modellieren die Kollaborations- und Zustandsdiagramme?

• Kollaborationsdiagramme zeigen wie einzelnen Teile zusammenarbeiten (Struktur)
• Zustandsdiagramme (Finite State Maschine) beschreiben den Lebenszyklus eines Objektes
• Zustandsdiagramme sind dann sinnvoll, wenn sich Verhalten eines Objektes signifikant ändert
• Dabei gibt es Startzustand, Transition (Übergang) und Zielzustand im Zustandsdiagramm

Spezifikatioen

Welche Rolle spielen Spezifikationen in der Software-Entwicklung?

• Ist eine Referenz bei der Implementation
• Ein Produkt ist nur gelungen, wenn es sich an der Spezifikation hält
• Oft Art Vertrag zwischen Kunden und Entwickler

Welche Eigenschaften sollte eine Spezifikation haben?

• Enthält eine Beschreibung von dem, was die Implementation enthalten muss
• Spezifikation, Anforderungsspezifikation, Design Spezifikation und Modulspezifikation
• Spezifikation ist Referenzpunkt wärend der Produktwartung

1. Konsistenz (keine Widersprüche)
2. Komplettheit (alle benötigten Anforderungen)
3. Klar und deutlich (alle benutzten Wörter erklären und definieren)
4. eindeutig und verständlich

Wie unterscheidet sich eine operationelle von einer deskriptiven Spezifikation?

• Operationelle Spezifikationen beschreiben die erwünschten Verhaltensweisen
• Deskriptive Spezifikationen beschreiben die erwünschten Eigenschaften (beschreibt also das Was aber nicht das Wie)

Wie formal werden Spezifikationen formuliert?

Was ist die Verifikation einer Spezifikation?

• Funktionalität, Komplettheit und Konsistenz einer Spezifikation sind zu prüfen
• Überwachung des dynamischen Verhaltens des spezifizierten Systems
• Analyse der Eigenschaften des Systems

ER-Modell

Logische Spezifikation

• = FOT (first-order-theory bzw. prädikatenlogische Theorie erster Stufe)
• Beschreiben in Form von Formeln und Logischen Ausdrücken (Logik 1. Ordnung)
• Variablen, Konstanten, Funktionsprädikate,Quantifizierungen u.s.w.
• Immer Boolsches Ergebnis
• Pre- und Postconditions
• Vorteil ist, wenn Logische Spezifikation korrekt sind auch alle Ableitungen davon korrekt

Logisches Prototyping - Methoden, Probleme

• Interpreter für Operationale Spezifikation
• Damit aber nur das Verhalten prüfbar und nicht die Eigenschaften
• Besser logische Sprache wie Prolog umd FOT zu approximieren

Algebraische Spezifikation - wie beschreibt man die Syntax?

Algebraische Spezifikation - wie beschreibt man die Semantik?

Algebraische Spezifikation - Probleme