remem.me

Überblick

Ziel:
• Software hoher Qualität
• kostengünstig innerhalb eines festen Budgetrahmens
• zum geplanten Zeitpunkt
… zu produzieren

Softwareentwicklung:
• Gesamtheit aller Aktivitäten, die zu einem lauffähigen Softwaresystem führen

Software Engineering:
• Aktivitäten identifizieren
• beschreiben
• Ergebnisse festlegen
• in einem Vorgehensmodell anordnen

Aktivitäten:
• produktbezogen (eher technisch)
~ Ergebnisse gehen direkt in das Produkt ein
zB bei Anforderungsermittlung, Implementation
• prozessbezogen (eher nicht-technisch)
~ Organisations- und Managementrahmen
zB Projektplanung, Leitung & Kontrolle bei Durchführung, Qualitätsmanagement

Überblick

grundsätzliche Merkmale:
• nicht sinnlich wahrnembar
→ Verständnis nur durch Texte & fertiges Produkt
• Text
→ leicht veränderbar
• digital
→ formale Behandlung durch Logik & diskrete Mth (statt kontinuierliche Ingenieurmth)

grosse Software:
• komplex
~ mehrere Realitätsbereiche
~ miteinander interagierende Anwendungsfälle
~ miteinander verknüpfte Module
• besteht aus umfangreichen Artefakten
zB Spezifikationen, Programme, Dokumentation
~ Konsistenz, Vollständigkeit nicht überprüfbar
~ keine verbindliche Semantik
• lange Lebensdauer
~ muss kontinuierlich an sich ändernde Anforderungen angepasst werden
→ Versionen
• verfestigt Sichtweisen
~ Verständnis der Beteiligten → Modell des Anwendungsbereichs
~ verwendete Software → Rahmenbedinungen für Arbeitsabläufe

Überblick

Workflow:
• Unterstützung/Automatisierung eines Geschäftsprozesses durch ein Computerssystem

Workflow-Modell spezifiziert Aspekte:
• organisatorisch: WER etwas ausführt
• funktional: WAS
• operational: WIE
• ablaufbezogen: WANN (Reihenfolge, Kontrollfluss)
• informationsbezogen: WOMIT (Daten)
• kausal: WARUM (Intra-Workflow-Abhängigkeiten)

Workflow Management System:
• System, mit dem man Geschäftsprozesse als Workflow-Modell spezifizieren & ausführen kann
• koordiniert Ausführung verschiedener Anwendungssysteme

Überblick

● Produktqualität
~ unabhängig von Einsatzkontext
~ innere Qualitätsmerkmale
zB Änderbarkeit, Verständlichkeit

● Gebrauchsqualität
~ Erfüllung der Anforderungen im Einsatzkontext
~ äussere Qualitätsmerkmale
zB Effizienz, Aufgabenangemessenheit

Merkmale nach DIN ISO 9126 mit Beispielkriterien
● Funktionalität
~ Übereinstimmung der Funktionen mit den Anforderungen
zB Angemessenheit

● Zuverlässigkeit
~ Fähigkeit des Systems, Leistungsniveau über festgelegten Zeitraum zu bewahren
zB Wiederherstellbarkeit

● Effizienz
~ Verhältnis Leinstungsniveau - eingesetzte Betriebsmittel
zB Zeitverhalten

● Änderbarkeit
~ Aufwand für Änderungen (Korrekturen, Verbesserungen, Anpassungen)
zB Analysierbarkeit

● Benutzbarkeit
~ Aufwand zur Benutzung
zB Verständlichkeit (des Systems)

● Portabilität
~ Übertragbarkeit in andere Umgebung
zB Anpassbarkeit

Überblick

• die spezifischen Anforderungen an das Anwendungssystem ermitteln
• Ergebnis: Anforderungsspezifikation (= Pflichtenheft)
~ Was die Software leisten soll (≠ wie)
~ objektorientierte Anforderungsermittlung: Anforderungsspezifikation enthält
⋅ Anwendungsfallmodell
⋅ Klassenmodell
⋅ Verhaltensmodelle

• Stakeholder
~ u.a. Auftraggeber, Benutzer, Projektleiter, Analytiker, Entwickler, Tester
~ haben unterschiedlichen Erfahrungshintergrund
~ soziale Kompetenz

• funktionale Anforderungen
~ Funktionen, Eigenschaften (Operationsfolgen, Ausnahmebehandlungen, Geschäftsregeln… )
~ externe Schnittstellen (Benutzungsschnittstelle, Ein-/Ausgabeformate, externe Systeme…)
• nichtfunktionale Anforderungen
~ technische Anforderungen (Zielplattform, Entwicklungsumgebung, Implementierungstechnologie…)
~ Qualitätsanforderungen (Performanz, Verfügbarkeit, Wartbarkeit…)

Tätigkeiten:

• Extrahieren
~ Anforderungen explizit machen
~ für alle verständlich

• Verhandeln
~ Anforderungen gewichten
~ welche Anforderungen bis wann (Produkt-Version)?
~ Übereinstimmung aller Stakeholder

• Spezifizieren
~ möglichst präzises Dokument erstellen
= Basis für Abnahmetest durch Auftraggeber
~ Modelle mit unterschiedlichen Darstellungen & Abstraktionsebenen

• Validieren
~ Spezifikation vollständig? (building the right product)
~ trifft die Erwartungen von Auftraggeber und Benutzern?
~ enge Zusammenarbeit zwischen den Stakeholdern

• Verifizieren
~ Einzelspezifikationen korrekt & untereinander konsistent? (building the product right)
~ technisch & formal
~ Analytiker & spezialisierte Tester

Bedeutung:
• intensiv validierte & verifizierte Anforderungsspezifikation = zentrale Entwicklungsbasis
• Kosten für Anforderungsfehler, die erst bei Abnahme bzw nach Auslieferung entdeckt werden, bis 50 bzw 200 mal grösser

Überblick

• Anforderungsermittlung
• Entwurf
• Implementation
• Tests
• Systemeinführung

Überblick

Ziel:
• innere Struktur der Software festlegen
• Komplexität bewältigen
• Software schrittweise in kleinere, besser beherrschbare Module zerlegen (Klassen, Komponenten, Pakete, Teilsysteme)

zweistufiges Vorgehen:
• Grobentwurf
~ Analyseklassen in die vorgesehene Architektur abbilden
• Feinentwurf
~ Zielsprache berücksichtigen für nahtlosen Übergang in Implementation

Ergebnis:
• Entwurfsspezifikation
~ Spezifikation der Module, ihrer Beziehungen, ihres Zusammenwirkens
~ Hauptbestandteil: Klassenmodell des Entwurfs
~ ergänzt mit Interaktions- & Zustandsdiagrammen

Qualitätskriterien:
• starke Kohäsion: Jedes Modul behandelt logisch zusammenhängendes Teilproblem
• schwache Kopplung: Abhängikeit von anderen Modulen möglichst klein
• Geheimnisprinzip: Funktionalität sichtbar, ihre Realisierung nicht

unterstützende Organisationsformen:
• Programmbibliothek
~ Sammlung von selbständigen Programmelementen
~ unabhängig vom Anwendungskontext
~ Anwendungssystem bestimmt Kontrollfluss

• Rahmenwerk (framework)
~ Konstellation kooperierender Klassen
→ Grundstruktur & Kontrollfluss für eine bestimmte Problemstellung

• Entwurfsmuster
~ Konstellation von Entwurfselementen zur Lösung einer wiederkehrenden Problemstellung
→ Sammlungen von Musterbeschreibungen
zB Model-View-Controller-Muster (erstmals im Smalltalk-System)

• Komponente
~ in sich abgeschlossener Softwarebaustein
~ kann zu grösseren Einheiten zusammengesetzt werden
~ wird in Komponenten-Rahmenwerk konfiguriert, installiert & ausgeführt
zB Enterprise Java Beans
~ Web-Service: Komponente, die über das Web benutzt wird

Überblick

• Modulinterna ausprogrammieren aufgrund der Entwurfsspezifikation
• Methoden des Programmierens im Kleinen (zB Wohlstrukturiertheit, Programmierstil)
• Ergebnis: Ansammlung von Quelltexten der verschiedenen Module (≠funktionsfähiges Programm)

Überblick

• Überprüfen, ob Gegenstand seinen Spezifikation erfüllt
• Modultest → Integrationstest (sukzessive) → Systemtest → Abnahmetest (Auftraggeber)

Überblick

• Software aus der Entwicklungs- in die Einsatzumgebung übertragen
• organisatorische Massnahmen beim Anwender
• Umstellung der Arbeitsprozesse sorgfältig planen und begleiten
zB Schulung, Beta Tests, Hotline

Überblick

Phasen:
1. Anforderungsermittlung
2. Entwurf
3. Implementierung
4. Test
5. Einführung & Wartung

+ klare Aufgabentrennung:
~ Spätere Phasen setzen auf den wohldefinierten Ergebnissen der vorangehenden Phase auf.
~ Die einzelnen Phasen wirken qualitativ und quantitativ abgeschlossen.
+ Phase "Einführung & Wartung" betont Qualitätskriterium Wartbarkeit (nach Systemeinführung).

Probleme:
- geht von vollständigen, fehlerfreien vorausgehenden Phasen aus
↔ Ergebnisse enthalten Fehler oder sind unvollständig
- Anwender nur in der ersten Phase beteiligt
↔ Einige Anforderungen werden erst mit der Entwicklung klar
- erste lauffähige Version erst am Ende der Entwicklung
→ Fehler, Missverständnisse werden erst spät entdeckt
- Überschreiten der Projektdauer führt zu Abkürzungen in der Testphase
- Testaktivitäten zu sehr als Phase gedacht:
~ Qualitätssicherung ist phasenübergreifende Grundaufgabe

Weiterentwicklung:
• Wasserfallmodell mit Iterationen
~ Wiederholungen von vorangegangenen Aktivitäten sind die Regel

Überblick

● Rapid Prototyping
~ Wegwerfprototyp wird so lange revidiert bis die Anforderungen feststehen
~ meist genügt Benutzungsoberfläche
+ Nähe zum Auftraggbeber/Benutzer: Teilergebnisse abstimmen → Akzeptanz
- Auftraggeber meint, System sei fast fertig

● evolutionäres Prototyping
~ Serie von Prototypen, die in die Produktionsversion konvergiert

● inkrementelles Vorgehen
~ nacheinander Teilaspekte der SW realisieren
~ hardest things first
+ frühzeitig ausführbare Systemteile beurteilen
+ Lernprozess aller Beteiligten berücksichtigt
+ gleichmässigere Auslastung der Spezialisten

● horizontaler Prototyp
~ realisiert nur bestimmte technische Facette des Systems
zB Benutzungsoberfläche

● vertikaler Prototyp
~ System für Teilausschnitt des Funktionsumfangs
~ inkl. Benutzungsschnittstelle, fachliche Logik, Datenhaltung
zB Stammdatenverwaltung

Überblick

● statische Struktur: Core Process Workflows (Aktivitätsarten)
~ Geschäftsprozessmodellierung -> Use Cases
~ Anforderungen
~ Analyse & Entwurf
~ Implementierung
~ Test
~ Inbetriebnahme
& Core Supporting Workflows:
~ Projektmanagement
~ Konfigurationsverwaltung
~ Umgebung (Hardware & Software)

● zeitliche Struktur: Zyklen in Phasen
~ evolutionär: ein Zyklus → eine Systemversion
~ Iterationen auch innerhalb einer Phase
~ In jeder Phase, Iteration kommen praktisch alle Aktivitätsarten vor.
~ Phasen schliessen mit Meilenstein ab

1. Konzeptphase (Inception phase)
~ fachliche Anforderungen, Umfang, Geschäftsvorfälle (Use Cases) def.

2. Ausarbeitung (Elaboration phase)
~ grobe Systemarchitektur erarbeiten
~ ausführbarer Prototyp der Architektur zu den wichtigsten Geschäftsvorfällen

3. Konstruktion (Construction phase)
~ noch ausstehende Komponenten und fachl. Funktionalitäten parallel implementieren
~ Beta-Version des Systems

4. Übergang in den Betrieb (Transition phase)
~ Beta-Test mit ausgewählter Nutzergruppe
~ Benutzerdokumentation, Schulung

Überblick

● Praktiken
~ kleine Releases: 1-3m/Release, 1-3w/Iteration, 1-3d/Arbeitspaket
→ Kunde kann sehr früh Abweichungen von seinen Anforderungen erkennen
~ Planspiel: Planung der einzelnen Releases mittels User Storys
~ Tests: festgelegte Testfälle, automat. Testen nach jeder Änderung
~ Systemmetapher zum gemeinsamen Verständnis für die Zusammenhänge
~ einfacher Entwurf; Bemühen um Wiederverwendbarkeit sinnlos
~ Refaktorisierung: Vereinfachung unter Beibehaltung der Semantik
~ Programmieren in Zweierteams: A programmiert, B überprüft & entwickelt Strategien für weitere Implementierungen
~ gemeinsames Code-Eigentum: Jedes Paar kann jederzeit überall ändern
~ feste Programmierrichtlinien → einheitlicher Code
~ kontinuierliche Code-Integration
~ Dokumentation: Programmcode selbsterklärend
~ geregelte Arbeitszeiten
~ Kundenvertreter im Team: zukünftiger Anwender, für Testfälle verantw.

● Voraussetzungen
~ Alle Entwickler brauchen gute & breite Qualifikation
~ Kunde muss qualifizierten MA für Projektteam abstellen
~ für kleine Projekte mit 10-15 Entwicklern
~ Umfeld mit sich rasch ändernden Anforderungen
~ Kommunikation zentral → Entwickler an 1 Ort
~ Tests müssen gesamte Funktionalität abdecken ↔ nicht umfangreich/laufzeitintensiv

- evolutionäres Vorgehen: unvorhergesehene Anforderungen machen Grossteil der bisherigen Arbeit zunichte

Überblick

● zerlegen den Entwicklungsprozess in Phasen Phase umfasst Aktivitäten schliesst mit Meilenstein ab ● beschreiben Aktivitäten Worauf baut die Aktivität auf? (Voraussetzungen) Was soll bei der Aktivität untersucht/entwickelt werden? Wie soll das geschehen? (Methode/Technik) Welche Ergebnisse sind zu erarbeiten? ● legen die Ablauforganisation fest ~ Vorgaben zu Aufwand, Termine, Verfahren etc. ● Ziel: Arbeitsablauf vereinheitlichen ● langfristig möglichst stabil → verlässliche Arbeitsgrundlage ● unternehmensweite Geltung

Überblick

Probleme:
• Teilprodukte immateriell
→ Entwicklunsfortschritt kaum zu ermitteln
• hoher Spezialisierungsgrad
→ Entwickler schlecht ersetzbar
• Grosse Softwarprojekte unterscheiden sich grundsätzlich von früheren Entwicklungen.
→ Erfahrungen nur von begrenztem Wert
• Grosse Software erfordert iteratives Vorgehen
→ Hälfte der Arbeit zur Überarbeitung bereits erstellter Teilprodukte

Aufgaben:
• Voruntersuchung
~ Aufwandsschätzung (COCOMO, Function-Point)
~ Machbarkeitsstudie
~ Zeitbedarfsschätzung
~ Kosten/Nutzen-Analyse
→ Entscheidung über Durchführung

• Planung
~ Ablauf- & Terminplanung
⋅ Vorgänge & ihre Abhängigkeiten
⋅ Meilensteine
⋅ Netzplan (Vorgänge ohne Pufferzeit → kritischer Pfad)
~ Ressourcenplanung
⋅ v.a. Personal (Qualifikation, zeitliche Verfügbarkeit)
→ termintreue ↔ kapazitätstreue Einsatzplanung
~ Kostenplanung
→ Projektfinanzplan

• Projektcontrolling
~ Fortschrittskontrolle durch Meilensteine
~ Terminkontrolle
~ Kostenkontrolle
→ unmittelbare Massnahmen gegen Symptome
→ mittelbare Massnahmen gegen Ursachen

• Änderungsmanagement
~ Versionsmanagementsystem
~ Konfigurationsmanagementsystem

• Risikomanagement
• Teams bilden und führen
• Projektabschluss
~ gute & schlechte Vorkommnisse analysieren & dokumentieren

Integrierter Entwicklungsprozess:
• Entwicklung, Management, Qualitätssicherung sind vollständig in das Vorgehensmodell integriert
zB Spiralmodell: generischer Rahmen für integrierte Entwicklungsprozesse
zB V-Modell: öffentliche Verwaltung, Industrie

Überblick

Definition:
• Summe aller Massnahmen, die garantieren, dass ein Produkt die spezifizierten Anforderungen erfüllt.

konstruktive QS:
• Qualität wird nicht in ein Produkt "hineingeprüft"
→ Qualitätsmängel möglichst nicht entstehen lassen

analytische QS:
• statische Prüfungen
~ führen Gegenstand nicht aus
~ auf alle Entwicklungsprodukte anwendbar
~ Quantifizierung von Eigenschaften mit Metriken
zB Anzahl der Methoden & Attribute
~ Automatische Analysatoren
zB Kontrollflussgraphen
~ Reviews
⋅ Inspektion
→ Standards, in sich schlüssig?
→ Produkt richtig entwickelt?
⋅ Walk-Through
→ vollständig, angemessen?
→ das richtige Produkt entwickelt?

• dynamische Prüfungen
~ ausführbare Prüfgegenstände
~ funktional (black box)
⋅ alle charakteristischen Kombinationen von Eingabedaten
~ strukturell (white box)
⋅ alle Anweisungen ausführen
~ Modultest (funktional & strukturell)
~ Integrationstest (strukturell, top-down oder bottom-up)
~ Systemtest (funktional, inkl. Performanz-, Last-, Stresstest)
~ Abnahmetest (funktional, unter echten Einsatzbedingungen)

prozessbezogene QS:
• Capability Maturity Model
~ 5 Reifegrade eines Prozesses: initial, repeatable, defined, managed, optimized
• ISO 9000 Normen
~ 9001: Modell zur Darlegung der QS in Design, Entwicklung, Produktion, Montage, Kundendienst
~ 9000-3: Anwendung von 9001 auf Entwicklung, Lieferung, Wartung von Software

Überblick

• Werkzeug nimmt dem Entwickler zeitaufwendige, mechanische Tätigkeiten ab
zB Wird ein Name geändert, müssen alle Querbezüge & Referenzen auf das geänderte Element aktualisiert werden

• automatisiert sich häufig wiederholende Arbeitsgänge
→ Produktivität steigt

• erzeugt standardisierte Daten & Dokumente
→ erleichtern Kommunikation parallel arbeitender Entwickler
→ verbessern Einheitlichkeit & Konsistenz des Produkts

• unterstützt korrekte Anwendung der zugrundegelegten Methode
→ verbessert Qualität von Entwicklungsprozess & Produkt

Überblick

Definition:
• Sammlung von Hard- & Softwarewerkzeugen, welche die Entwicklung von Softwareprodukten in einem konkreten Anwendungsbereich unterstützen.

Gruppen:
• Programmierumgebungen (integrated development environment, IDE)
~ unterstützen Programmieren, Testen, Debuggen
• Computer Aided Software Engineering Werkzeuge (CASE-Tools)
~ unterstützen Spezifikation & Entwurf
~ Diagramme in der graphischen Notation einer Entwurfsmethode interaktiv erstellen
∞ Generatoren → Programmfragmente
- eignen sich nicht für kontinuierliche Entwicklung grosser Softwaresysteme
↔ Single-Source-Prinzip
• Software Engineering-Umgebungen
~ für umfangreiche, langwierige Softwareprojekte
~ unterstützen alle Aktivitäten der Entwicklung und Wartung

Bestandteile:
• Datenbankmanagement System (DBMS) oder Objekt Management System (OMS)
• High-Level Programmiersprache
• Werkzeuge für Anforderungsermittlungs- & Entwurfsaktivitäten
• UI-Builder
• komfortable Test- & Debugginghilfen
• Werkzeuge zum Projekt-, Dokumentations-, Konfigurationsmanagement

integriertes Werkzeug:
• durch wohldefinierte Schnittstelle mit SEU verbunden
→ Änderungen werden automatisch in den Modellen & Dokumenten der übrigen Werkzeuge sichtbar

offene SEU:
• wohldefinierte Schnittstelle zur Einbindung weiterer Werkzeuge

Vorteile:
+ einheitliches Datenmodell (in OMS bzw DBMS definiert)
~ Ausgabe eines anderen integrierten Werkzeugs als Eingabe
→ Auswirkungen von Änderungen werden automatisch in den vorausgegangenen bzw nachfolgenden Entwicklungsstufen sichtbar
+ Beziehungen zw den einzelnen Dokumenten des Entwicklungsprozesses verwalten
~ Weg einer Anforderung bis zur Implementierung verfolgen
→ von Änderung betroffene Stellen automatisch aufzeigen
+ Projektmanagement-Werkzeuge zur Dokumentation von Projektstatus & -verlauf
→ stets aktuelle Projektinformationen

Überblick

• Ziel: sämtliche Aspekte aller denkbaren Realweltsituationen & Softwaresysteme mit dedizierten Konstrukten modellieren können
• riesiges Arsenal von Modellierungselementen
• etliche unklar definierte, zT widersprüchliche Elemente
• de facto Standard für objektorientierte Modellierung
• auf den eigenen Anwendungsbereich zuschneiden
• legt nur Notation fest (≠ Vorgehensmethodik)

Strukturelle Modellierung

Abstraktion:
• vereinfachte Beschreibung oder Spezifikation eines Objekts der Realwelt
• Prinzip des geringsten Erstaunens: genau die im Kontext benötigten Eigenschaften
• Jede Aktivitätsart der SE erfordert eigene Abstraktionsebene

Darstellung:
• Rechteck
• Bezeichnung unterstrichen

Zustand:
• ergibt sich aus der konkreten Wertebelegung seiner Attribute
• unterhalb des Objektnamens: attributname = attributwert
• einfacher Attributwert: zB Geldbetrag
• nicht-einfacher Attributwert: zB Bezeichner eines Objekts

Operationen:
• Modifikatoren verändern den Zustand des Objekts
• Selektoren liefern Attributwerte zurück (Geheimnisprinzip)
• Verhalten gibt an, in welchem Zustand welche Operationen mit welchem Resultat ausgeführt werden dürfen

Strukturelle Modellierung

• Dienstleister (supplier): Objekt, das anderen Objekten Operationen zur Verfügung stellt
• Dienstnutzer (client): Objekt, das Operationen in Anspruch nimmt
• Operationsausführung veranlassen = Nachricht senden
• Voraussetzung: Dienstnutzer kennt Dienstleister (unidirektionale Verbindung)
• bidirektionale Verbindung: wechselnde Abhängigkeiten
→ zyklische Abhängigkeiten, komplexer
• Rolle: Teilmenge der angebotenen Operationen

Darstellung:
• durchgezogene Verbindungskante (link)
• unterstrichener Name ist optional
• uni-/bidirektional: Pfeil mit offener Spitze
• Rolle: kleines substantiv am Verbindungsende

Strukturelle Modellierung

• Name eines Objekts: Teilmenge seiner Attributwerte (≠ Identität)
• indirekter Name: Referenz
• anonymes Objekt: O mit nur indirekten Namen
• Aliase: mehrere indirekte Namen für dasselbe Objekt
• Zustands-/Wertegleichheit: dieselben Attribute & Attributwerte
• referentielle Gleichheit/gleiche Identität: Namen (Aliase) beziehen sich auf dasselbe Objekt

Strukturelle Modellierung

Klassenmodell: statischer "struktureller" Rahmen für die Objekte
Klasse: Menge von Objekten mit denselben Attributen & Verhalten
Instanz einer Klasse: von dieser Klasse beschriebenes Objekt
Attributspezifikation: Attributnamen & zulässige Werte (Typ)
~ Typen: elementar (int, boolean…) | Aufzählung | Klasse | Interface
⋅ evtl mit initialer Wertebelegung, einschränkender Zusicherung
~ weitere Eigenschaften, zB unbeschränkt änderbar (changeable), konstant (frozen)
Operationen: Name, Sichtbarkeit, Parameter
~ optional Übergabeart der Parameter
⋅ in: nicht modifizierbare Eingabe
⋅ inout: modifizierbare Eingabe
⋅ out: nur für Rückgabe
~ Signatur: Operationsname + Wertebereiche + Rückgabewert
Standardoperationen
~ für den Zugriff auf Attribute & Assoziationen
~ oft nicht explizit in den Diagrammen
Stereotyp: Satz spezieller, textuell spezifizierter Charakteristika | Zusicherungen

Darstellung:
Klasse: Rechteck mit Name AnfangGross
Instanz: unterstrichen, vor Klassenname immer ":"
Attribute: unterhalb Klassenname, Name anfangKlein
~ Sichtbarkeit, initale Wertebelegung, einschränkende Zusicherung
zB public menge : Integer = 0 {changeable}
~ Sichbarkeit: +öffentlich, -privat, #geschützt (nur Unterklassen)
Operation: Signatur
~ Selektoren: {isQuery}
zB public monatsumsatz(in aktMonat : Monat) : Geld {isQuery}
abgeleitete Attribute & Assoziationen: / vor dem Namen
Standardoperationen für Attribut
~ gibAtt() : T
~ setzeAtt(in wert : T)
Standardoperationen von A für Assoziation A-B
~ verbindeAss(in einB : B)
~ gibAss() : B
~ loeseAss(in einB : B)
~ zerstoere()
~ erzeuge() : B (Klassenoperation, unterstrichen)
Stereotyp: «Bezeichner» | grafisches Symbol

Strukturelle Modellierung

• Verbindungen von Instanzen werden im Klassenmodell durch Assoziationsbeziehungen ausgedrückt
• reflexive Assoziation: Verbindungen zwischen Instanzen derselben Klasse
• Multiplizität: untere & obere Grenze für Anzahl verbundener Instanzen
~ 1..1 (genau 1 verbundene Instanz), Abk: 1
~ 0.. (beliebig), Abk:
~ 0..1 (höchstens 1)
~ 1..* (mindestens 1)
~ exakte Zahl
~ abgeschlossenes Intervall, zB 2..4
~ diskrete Kombinationen von Zahlen & Intervallen, zB 2,4
• 1:1-Assoziation: beide Seiten höchstens 1
• 1:n-Assoziation: eine Seite höchstens 1, andere Seite mehr als 1 möglich (mehrwertige A)
• n:m-Assoziation: beide Seiten mehr als 1 möglich (mehwertige A)
• (einseitig) navigierbar: Dienstnutzer kennt Dienstleister
• bidirektional navigierbar: gegenseitige Kenntnis
• Assoziationsklasse: Assoziation mit Attributen, Operationen ua

Darstellung:
• durchgezogene Linie, Name in der Mitte
• Multiplizitäten an den Enden
• navigierbar: offene Pfeilspitze
• Rollen an den Assoziationsenden
• Assoziationsklasse wird durch gestrichelte Linie mit Assoziationslinie verbunden

Strukturelle Modellierung

• Aggregation: Teilobjekt
~ kann auch Teil anderer Objekte sein
• Komposition: Teilobjekt
~ darf nur von Operationen der Ganzes-Klasse entfernt werden
~ darf nicht Teil anderer Komposition sein
~ wird automatisch mitzerstört

Darstellung:
• Raute am Ganzes-Ende
~ Aggregation: leer
~ Komposition: ausgefüllt
⋅ alternativ: Teil-Klasse innerhalb der Ganzes-Klasse

Strukturelle Modellierung

• Alles, was für eine Instanz der allg Klasse gilt, gilt auch für eine Instanz der spez Klasse
dh Unterklasse erbt alle Attribute, Operationen, Assoziationen der Oberklasse
• Substituierbarkeitsprinzip
~ Überall Instanz der Unterklasse anstelle einer Instanz der Oberklasse verwendbar
• abstrakte Klasse: mind 1 abstrakte Operation (dh ohne Implementierung)
• Interface
~ kein Attribut
~ keine implementierte Operation
~ keine Kenntnis von Assoziationen
~ Klasse realisiert Interface, indem sie dessen Operationen in ihrer Schnittstelle anbietet

Darstellung:
• Generalisierung: Pfeil mit leerem Dreick zur Oberklasse
• abstrakte Klassen/Operationen: kursiv | Schlüsselwort abstract
• Interface: Klasse mit Stereotyp «interface»
• «realizes»-Abhängigkeit: gestrichelter Pfeil mit leerem Dreieck zum Interface | Lollipop als Interface

Strukturelle Modellierung

• abhängiges Element hat Kenntnis vom unabhängigen Element
• Aenderungen des Anbieters können Konsequenzen für den Klienten haben
• «use»-Abhängigkeit
zB Klasse benötigt ein Interface als Attributtyp

Darstellung:
• gestrichelter Pfeil mit offener Spitze zum unabhängigen Element

Strukturelle Modellierung

Darstellung:
• in geschweiften Klammern am Element, für das sie gilt
• Formulierung frei (Umgangssprache, Pseudocode, Object Constraint Language OCL…)
zB Instanz einer Klasse darf nur Verbindung zu anderen Instanzen bezgl 1 der möglichen Assoziationen besitzen: {oder} an gestrichelter Verbindung zwischen den möglichen Assoziationen
zB mehrwertige Assoziationen sollen nicht als (ungeordnete) Menge aufgefasst werden: {geordnet}
zB Objekt darf mehrfach vorkommen: {Kollektion}
zB Kollektion ist geordnet: {geordneteKollektion}
zB hierarchische Ordnung: {Hierarchie}
zB gerichteter, azyklischer Graph: {DAG}

Strukturelle Modellierung

• Graphische Darstellung reicht oft nicht aus, wenn Klassen präzise spezifiziert werden müssen

Aufbau:
class Klassenname
responsibilites: Verantwortungsbereich der Klasse umschreiben
comment: "ermöglicht, Kommentare aufzuführen"
inv: Gemeinsame Teile aus allen Vor- & Nachbedingungen werden in der Klasseninvariante zusammengenommen
features: (leitet Attributs- & Operationsspezifikationen ein)
attributes: Sichtbarkeit attributName: Typ = Defaultwert {Eigenschaften}
zB public kontakt: String;
operations: Sichtbarkeit operationsName (Parameterliste): Rückgabewert {Eigenschaften}
zB public monatsumsatz (in aktMonat: Monat) Geld {isQuery}
pre bzw post: Vor- bzw Nachbedingung
end Klassenname

Strukturelle Modellierung

• Gruppierung von Modellierungselementen, die selbst wieder Pakete sein können
• definiert einen Namensraum
• bildet Sichtbarkeitsgrenze mit Sichtbarkeitsregeln:
~ öffentlich (public): exportierte Elemente
~ paketweit (package): innerhalb Paket & enthaltene Pakete
~ privat (private): alles andere
~ Default-Sichtbarkeit: nur innerhalb des Paketes
• Import-Abhängigkeit:
~ Namen aller öffentlichen Elemente des importierten Paketes werden in den Namensraum des importierenden Paketes aufgenommen
• Access-Abhängigkeit:
~ Elemente müssen über den vollständigen qualifizierten Namen angesprochen werden
• minimale Abhängigkeit zw Modellelementen in verschiedenen Paketen → mehr Kohäsion, weniger Kopplung

Darstellung:
• Rechteck mit Reiter oben links, der den Paketnamen enthält
• Sichtbarkeit von Paketelementen: + öffentlich, ~ paketweit, - privat
• Import/Access-Abhängigkeiten: gestrichelter «import»/«access»-Pfeil mit offener Spitze zum benutzten Paket
• untergeordnete Pakete werden innerhalb des Pakets gezeichnet

Funktionsmodellierung

• formuliert in sich abgeschlossene Teilfunktionalität
• bringt für mind 1 Akteur ein bestimmtes Ergebnis
• wichtig für Kommunikation Anforderungsermittler - Benutzer
• beschreibt Funktionalität allgemein
• Szenario = konkreter Ablauf eines Anwendungsfalls

Darstellung:
• Anwendungsfalldiagramm
~ Anwendungsfall: Ellipse
~ mehrere Anwendungsfälle optional in einem Rechteck gebündelt
~ Akteur: Strichmännchen ua (für eigene Stereotype, zB maschinelle Benutzer)
• Objektdiagramm
~ Szenario
• Mechanismus
~ partielles Klassendiagramm
~ Klassen, von denen Instanzen in einem Objektdiagramm für den Anwendungsfall vorkommen
~ Anwendungsfall gestrichelt angedeutet, durch gestrichelte Linien mit Klassen verbunden

textuelle Spezifikation:
• "prosaisch", aus Sicht der Akteure
• Anwendungssystem als Black Box
• fortschreitende Präzisierung
• Vorbedingung grenzt Anwendungssituationen ein
• Nachbedingung präzisiert Ergebnis
• alternative Abläufe (alternative flows)
~ erfüllen Nachbedingung des normalen Ablaufs (main flow)
• Ausnahmesituationen (exceptional flows)
~ erfolgreicher Ablauf gefährdet → gesonderte Nachbedingung

Funktionsmodellierung

include:
• Anwendungsfälle mit derselben Teilfunktionalität → eigener Anwendungsfall
+ vermeidet Redundanz
textuell:
• include "Name des Anwendungsfalls"
Anwendungsfalldiagramm:
• gestrichelter Pfeil mit offener Spitze & «include»

extend:
• optionale Erweiterung
+ Flexibilität
textuell:
• im Basis-Anwendungsfall:
~ Erweiterungspunkt (extension point: Bezeichnung)
• in der Spezifikation der extend-Beziehung:
~ Basis-Anwendungsfall (base …)
~ Erweiterungspunkt (extensionPoint …)
~ Erweiterungs-Anwendungsfall (extension …)
~ Bedingung fürs Erweitern (condition …)
Anwendungsfalldiagramm:
• gestrichelter Pfeil mit offener Spitze & «extend» (Erweiterungspunkt) Bedingung

Generalisierung:
• Beziehungen des allg Anwendungsfall werden an die spez Anwendungsfälle vererbt
Anwendungsfalldiagramm:
• Pfeil mit geschlossener, leerer Spitze zum allg Anwendungsfall

Funktionsmodellierung

• modelliert den konkreten Ablauf von Operationen im Klassenmodell unter Einbeziehung der beteiligten Objekte
• Jedes Objekt hat Lebenslinie (gestrichelte vertikale Linie)
• Aufruf einer Operation: Pfeil mit gefüllter Spitze zur Linie des Dienstleisters & Name der aufgerufenen Operation
• Selbstdelegation: Pfeil zur eigenen Lebenslinie
• Kontrollinformation
~ Bedingung in eckigen Klammern
~ Iteration: *Iterationsausdruck Operationsaufruf
• Erzeugung: Pfeil zeigt auf Objektsymbol
• Zerstörung: Lebenslinie wird mit X abgeschlossen
• Interaktion
~ Gesamtheit der Pfeile
~ beschreibt den konkreten Ablauf einer Funktion

Funktionsmodellierung

• synchrone Nachricht
~ Aufrufer wartet auf Ergebnis
~ gefüllter Pfeil
~ Ablaufkontrolle kehrt immer zum Sender zurück
~ Rückkehr implizit oder gestrichelter Pfeil mit offener Spitze
• Aktivierungsbalken
~ Objekt beschäftigt mit Operationsausführung oder Warten
~ Zeitintervall als schmales Rechteck auf Lebenslinie
• asynchrone Nachricht
~ Sender wartet nicht
~ beide Objekte aktiv (fett gezeichnet), haben Ablaufkontrolle
~ Pfeil mit offener Spitze
⋅ Aktivierung eines Objekts: Pfeil zeigt auf Anfang des Aktivierungsbalkens
⋅ Nachricht an aktiviertes Objekt: Pfeil endet innerhalb des Aktivierungsbalkens

Funktionsmodellierung

• Objektdiagramm ∞ ablauforientertes Verhalten
• Nachricht: gefüllter Pfeil
• Nummerierung verdeutlicht Abfolge der Nachrichten
~ Ordinalzahlen
⋅ nur Reihenfolge
~ hierarchische Dezimalnotation
⋅ Dezimalpunkt für zusätzliche Schachtelungstiefe
• Kennung {new}, {destroyed}, {transient}
~ für Objekte, die im Verlauf erzeugt oder/und zerstört werden

- Abfolge nicht so leicht zu erkennen wie im Sequenzdiagramm
+ Objekte beliebig anordnen → Lesbarkeit verbessern

Funktionsmodellierung

• Anwendungsfälle mit Anwendern erarbeitet, für A lesbar → nicht präzise
• Interaktionsdiagramme veranschaulichen Abläufe präzise & trotzdem intuitiv
• Nachrichten zw Akteuren und Anwendungssystem sind asynchron
→ Akteur kann mehrere Anwendungsfälle gleichzeitig bearbeiten

Funktionsmodellierung

• Initialzustand:
~ genau 1 Zustandsübergang führt zum Ausgangszustand des Objekts (ohne Ereignis, Wächterbedingung)
~ Pseudozustand

• Terminalzustand:
~ Zerstörung des Objekts

• zusammengesetzte Zustände:
~ zusammenhängende Teile hierarchisch strukturieren

Darstellung:
• Initialzustand: gefüllter Kreis
• Terminalzustand: gefüllter Doppelkreis
• zusammengesetzter Zustand: grosses abgerundetes Rechteck
~ Zustandsübergang zur Kontur endet im Initialzusstand des enthaltenen Zustandsdiagramms
~ Zustandsübergang von der Kontur verbindet alle Unterzustände mit dem Folgezustand
~ Zustandsübergang von der Kontur zu einem Unterzustand führt von allen Unterzuständen in diesen Unterzustand

Funktionsmodellierung

• Zustand eines Objekts
~ bestimmt durch seine Attributwerte und Verbindungen zu anderen Objekten
~ abstrahiert von konkreten Kombinationen:
⋅ berücksichtigt nur Eigenschaften, die das Verhalten beeinflussen

• Ereignis
~ Eintreten eines bestimmten Sachverhalts zu einem bestimmten Zeitpunkt
~ Aufrufereignis: Empfang einer Nachricht, die eine Operationsausführung veranlasst
~ Änderungsereignis: zB Benutzerinteraktion, Objekt erzeugt
~ Zeitereignis: zB 10 Sekunden abgelaufen
~ unterscheiden sich Ereignisse nur in Details → Ereignisattribute

• Zustandsübergang
~ Reaktion auf Ereignis
~ (Wächter-)Bedingung:
⋅ prädikatenlogischer Ausdruck
⋅ Zustandsübergang nur, wenn Bedingung erfüllt
⋅ Die Bedingungen aller Zustandsübergange, die von demselben Zustand & Ereignis ausgehen, müssen sich gegenseitig ausschliessen
→ Verhalten deterministisch

• Aktion
~ Reaktion auf Ereignis
~ wird während Zustandsübergang durchgeführt
~ kann weitere Ereignisse auslösen
~ mehrere Aktionen werden zu atomarer Aktionsfolge zusammen gefasst
~ interne Transition = A ohne Zustandsübergang
~ Eingangsaktion eines Zustands: wird vor jedem Betreten dieses Z ausgeführt
~ Ausgangsaktion: wird vor jedem Verlassen des Z ausgeführt

Darstellung:
• Zustand: abgerundetes Rechteck
• Ereignis: wie Klasse
• Zustandsübergang: Pfeil mit offener Spitze, beschriftet mit Ereignis
• Wächterbedingung in eckigen Klammern hinter dem Ereignisnamen
• Aktion: Ereignis Wächterbedingung / Aktionsfolge ^ Sendeaktion
• Sendeaktion: Zielausdruck.Nachrichtenname(Argumente)
• interne Transition, Eingangs-/Ausgangsaktion: im unteren Teil des Zustandssymbols
~ Eingangs-/Ausgangsaktion: exit / …

Anforderungsermittlung

Jede Modellierungsaktivität in der Anforderungsermittlung
• orientiert sich ausschliesslich an den Gegebenheiten und Erfordernissen der Problemwelt (Problemadäquatheit)
• darf nicht Selbstzweck werden
• sollte keine Gesichtspunkte der Realisierung vorwegnehmen
• Modellelemente hinterfragen, die kein Pendant in der Problemwelt besitzen

Anforderungsermittlung

• Grundverständnis der Domäne & projektspezifischen Anforderungen erarbeiten
• Studium der Domäne
zB praktische Erfahrungen vor Ort
zB Vergleich mit ähnlichen Systemen
zB Lastenheft aufmerksam lesen
• Einsichten über
~ Gegenstände & Sachverhalte
→ Definitionen in Glossar
~ Arbeitsabläufe
~ Ziele & Aufgaben
~ zu berücksichtigende Systeme & Schnittstellen

Anforderungsermittlung

• Szenario für jede Funktion im Lastenheft
~ Name, der Funktion und Geschäftsvorfall widerspiegelt
~ beteiligte Personen
~ Beschreibung des konkreten Ablaufs
~ Fokus auf konkrete Beispielsituationen erleichtert Diskussion mit Anwendern

• Akteure
~ Benutzer gruppieren und mit Akteuren modellieren
R1 Für jeden menschlichen Akteur muss mindestens eine Person existieren, welche die Rolle des Akteurs spielen kann.
~ Schnittstellen zu externen Systemen mit Akteuren modellieren
⇒ Überblick über Akteure & die von ihnen benutzten Funktionen
⋅ Gemeinsamkeiten → Generalisierungsbeziehungen

• Anwendungsfälle
~ Szenarien zu Anwendungsfällen zusammenfassen, die wesentliche Teilfunktionen abdecken
R2 klar abgegrenzte Aufgabe, relevantes Ergebnis
R3 ohne Akteure suspekt
R4 beschreiben Systembenutzung (≠ System)
R5 von Analytikern geschrieben, für Anwender verständlich
R6 einfach & problemadäquat (≠ elegant)
R7 textuelle Spezifikation mit Vor- & Nachbedingungen ≤ 1 Seite
R8 Beziehungen zw Anwendungsfällen (include, extend, Generalisierung) möglichst spät & sparsam
R9 Beziehungen modellieren funktionale Zerlegungen (≠ Abläufe)

• Pakete
~ in grossen Anforderungsspezifikationen
R10 nach ihrer fachlichen Zusammengehörigkeit bilden
~ minimale Abhängigkeiten zu Anwendungsfällen anderer Pakete
~ ideal: entsprechende Aufteilung der Akteure

Anforderungsermittlung

R1 Jedes Element sollte relevantem Gegenstand oder Sachverhalt der Problemwelt entsprechen.

• Klassen
~ Ausgangspunkt:
⋅ Gegenstände & Sachverhalte in Lastenheft & Glossar
⋅ rudimentäre Klassendiagrammskizzen aus Anwendungsfallmodellierung
R2 Auf jede Klasse muss in mind 1 Anwendungsfall oder Szenario Bezug genommen werden.

• Attribute & Assoziationen
~ ergeben sich unmittelbar aus der Problemwelt & aus Infos, die von Anwendungsfällen benötigt werden
~ nur öffentliche Attribute
~ nur grob & umgangssprachlich beschrieben

• Generalisierungsbeziehungen
~ gemeinsame Attribute oder Assoziationen → Generalisierung
R3 Problemadäquatheit wichtiger als Zusammenfassung gemeinsamer Eigenschaften

• Modellbereinigung
R4 Jede Domänenklasse > 1 Attribut
R5 Ableitbare Attribute & Assoziationen als abgeleitet markieren
R6 Jede Domänenklasse > 1 Objekt in der Problemwelt

• textuelle Spezifikation
~ Attribute & Assoziationen genauer beschreiben
~ änderungsunfreundlich → möglichst spät anfertigen

• Pakete
~ bei umfangreichen Klassendiagrammen
R7 nach ihrer fachlichen Zusammengehörigkeit bilden
~ Kernklassen: oberste Klassen von Aggregationen, Kompositionen, Generalisierungen & unabhängige Klassen
~ Nicht-Kernklassen in Paket mit ihrer Ober-/Ganzesklasse

Anforderungsermittlung

• Benutzungsoberfläche = der nach aussen sichtbare Teil der Benutzungsschnittstelle
• Benutzungsschnittstelle = gesamte Software zur Realisierung der Kommunikationsschnittstelle Mensch - Anwendungssystem
• Alle Aktivitäten der SE müssen Entwicklung der BS systematisch mit einbeziehen
• Anforderungsermittlung: grundsätzliche Eigenschaften der BO
~ wesentliche Fenster skizzieren mit Darstellung & Manipulationsmöglichkeiten der Domänenobjekte & ihrer Verbindungen
~ Navigation zw den Fenstern konzipieren
~ Elemente haben Entsprechung in Problemwelt & sind selbsterklärend
~ pro Anwendungsfall & Akteur normalerweise 1 Fenster
~ Mock-up (rudimentärer Wegwerf-Prototyp) zur Kommunikation mit Anwendern

Anforderungsermittlung

• Aussagekräftige Verhaltensmodelle sind normalerweise zu detailliert für die Anforderungsermittlung

• externe Interaktionen beim Ablauf von Anwendungsfällen modellieren
~ als Sequenzdiagramm
~ Präsentation selektierter Objekte: gestrichelter Rückkehr-Pfeil
~ Attributwerte anzeigen: Aufruf von gib…()-Standardoperationen
~ Attributwerte bearbeiten: modifiziere()- oder setze…()-Standardoperationen

• zustandsorientiertes Verhalten komplexer Objekte modellieren
~ als Zustandsdiagramm
~ Grundlage: Geschäftsregeln, welche die Zustände der bearbeiteten Objekte berücksichtigen
zB "Wenn das Objekt A der Domänenklasse K die Attributwerte x1, …, xn besitzt und ein bestimmtes Ereignis E eintritt, dann führe Y aus."

Anforderungsermittlung

• Validierung des Anwendungsfallmodells
~ Anwender prüfen in Reviews die textuellen Beschreibungen der Anwendungsfälle
~ Für jeden Anwendungsfall ausgewählte Szenarien in Walk-Throughs durchspielen
~ Skizzen & Mock-ups der Benutzungsoberfläche zu Hilfe nehmen

• Verifikation des Domänen-Klassenmodells
~ Analytiker gleicht Domänen-Klassenmodell mit dem validierten Anwendungsfallmodell ab
⋅ prüft, ob im Domänen-Klassenmodell alle Klassen aufgeführt sind, die am Anwendungsfall beteiligt sind
⋅ Attribute & Assoziationen mit den für den Anwendungsfall notwendigen Informationen

Analyse

• Zwischenschritt zw Anforderungsermittlung und ersten Realisierungsaktivitäten
~ entlastet Anforderungsermittlung von zu feingranularen Aspekten
~ liefert ergänzende, präzisere, verifizierte Dokumente für die nachfolgende Realisierung

• Tätigkeiten
~ Anwendungsfälle in Klassen überführen
⋅ funktionale Anforderungen als Verantworlichkeiten von Klassen formulieren
⋅ zT als Schnittstellen- & Kontrollklassen neu einführen
⋅ zT Dömanen-Klassenmodell beibehalten
⇒ Analyse-Klassenmodell
~ AK mit Operationen auskleiden
~ AK mit Mechanismen & Interaktionsdiagrammen für Ablauf komplexer Anwendungsfälle ergänzen
~ AK mit Heuristiken aufbereiten & bereinigen
~ AK in Pakete aufteilen
~ AK verifizieren
⋅ Konsistenz & Vollständigkeit der einzelnen Modelle in sich überprüfen
⋅ die verschiedenen Modelle gegeneinander abgleichen

• Ergebnis: Analysespezifikation
⋅ Analyse-Klassenmodell
⋅ Interaktions- & Zustandsdiagramme
⋅ Dokumente über Durchführung & Ergebnisse der Verifikation

• Detaillierte Spezifikationen laufen Gefahr, in der Realisierung korrigiert werden zu müssen
⇒ einige wenige Kern-Anwendungsfälle analysieren, entwerfen, implementieren → funktionsfähiger Systemteil
~ übrige Anwendungsfälle nach demselben Muster analysieren, entwerfen, implementieren

Analyse

H1 mehrere Alternativen? → vorläufig irgendeine wählen
• 1-1 Assoziation oder 1 Klasse?
H2 1-1 Assoziation optional (Multiplizität 0..1)? → 2 Klassen
H3 Verbindung zu Instanzen anderer Klassen möglich? → 2 Klassen
H4 Aufteilung auf urspr & neue Klasse? → urspr Assoziation auf urspr Klasse beziehen
• Attribute oder Generalisierung?
H5 Objekte mit denselben Attributen & Verhalten möglich? Ändern sich dynamisch? → mit Attributen modellieren
H6 Objekte mit unterschiedlichen Attributen & Verhalten? → Generalisierung

Analyse

• Analyseklassen sind immer noch abstrakt
~ nichtfunktionale Anforderungen fehlen
~ Navigierbarkeit von Assoziationen fehlt
~ Attribute direkt aus Problembereich
~ Generalisierung nur zur konzeptionellen Strukturierung (≠ Redundanzvermeidung)
~ Verhalten textuell skizziert
~ oft nur Standardoperationen
~ präzise Schnittstellenbeschreibungen nur für komplexe Operationen

Aufteilung in Stereotype:

• «Entitätsklasse»
~ alle Domänenklassen
~ eher systembezogene Klassen
~ Symbol: Kreis mit Bodenhaftung

• «Schnittstellenklasse»
~ bündeln Interaktion Akteure-Anwendungssystem
⋅ Anwendungsfälle auswählen, externe Interaktionen unterstützen
⋅ Daten & Akteur-gesteuerte Modifikation repräsentieren
⋅ Kommunikationsprotokolle umsetzen (techn Akteure)
~ Akteur-Schnittstellenklasse AS
⋅ Akteur kann seine Anwendungsfälle aktivieren
~ Anwendungsfall-Akteur-Schnittstellenklasse AAS
⋅ zur Interaktion des Akteurs mit dem Anwendungsfall
~ Symbol: Kreis mit Griff links
~ Bezeichnung: AnwendungsfallAkteurAAS

• «Kontrollklasse»
~ fachliche Logik eines Anwendungsfalls
~ Symbol: Kreis mit Schwung nach links
~ Bezeichnung: AnwendungsfallK

• Operationen
~ externe Interaktion zerfällt in einzelne Aktionen → je 1 Operation
⇒ Verhalten der Anwendungsfälle wird präzisiert

• Modellbereinigung gemäss Heuristiken

• Aufteilung auf Pakete
~ nach Akteuren und/oder Anwendungsfällen (ausgehen von Paketen des Domänen-Klassenmodells)
~ Bezeichnung zB AkteurP
~ Unterpakete SchnittstelleP, KontrolleP, EntitaetenP
~ Dienstpaket wenn Klasse nicht eindeutig zuzuordnen
zB Klasse für mehrere Akteure relevant

Analyse

1 Analyse-Klassendiagramm: die den Anwendungsfall realisierenden Klassen mit Mechanismus versehen
2 Kollaborationsdiagramme für zugehörige Szenarien, angefertigt mit Instanzen von Klassen aus dem Mechanismus
~ Objektkonstellation, die die Vorbedingung des Anwendungsfalls erfüllt
⋅ meist AAS-Objekt & einige Entitätsobjekte
~ im Verlauf des Szenarios erzeugte Objekte & Verbindungen hinzufügen
⋅ meist Kontrollobjekt & weitere Entitätsobjekte
~ an den Verbindungen die Operationsaufrufe notieren
⋅ Beginn meist mit Operationsaufruf vom Akteur an die AAS-Klasse
~ möglichst Standardoperationen benützen
~ externe Interaktionen über die Schnittstellenklassen kanalisieren
~ interne Aktionen modellieren, zB Zugriffe von Kontrollklassen auf Entitätsklassen
~ neu erzeugte Objekte & Verbindungen mit Zusicherung {new} kennzeichnen, zerstörte mit {destroyed} bzw {transient}
~ Selektion eines Domänenobjekts mit selektiere()-Standardoperation
~ Präsentation selektierter Objekte mit gestrichelten Rückkehr-Pfeilen andeuten