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

Analyse

• Modelle auf Vollständigkeit, Eindeutigkeit, Konsistenz überprüfen
~ vollständig, wenn Beschreibung der Modellelemente die Spezifikationsrichtlinien befolgt
~ eindeutig, wenn nur auf eine Art und Weise interpretierbar
~ konsistent, wenn alle Querbezüge auf existierende & richtige Modellelemente verweisen
& wenn keine redundanten oder widersprüchlichen Spezifikationen vorkommen

• Anwendungsfallmodell:
~ Existieren die von include-Beziehungen referenzierten Anwendungsfälle?
~ Existieren die in extend-Beziehungen angegebenen Erweiterungspunkte?
~ Sind die textuell angegebenen Beziehungen in den Anwendungsfalldiagrammen eingezeichnet?

• Klassenmodell:
~ Sind alle Assoziationsenden mit Multiplizitäten versehen?
~ Existieren keine ableitbaren Attribute?
~ Sind in Unterklassen keine redundanten Features?
~ Sind alle Blätter einer Generalisierungshierarchie reguläre Klassen?

• Interaktionsdiagramme:
~ Ist jeder Pfeil mit einem Operationsnamen beschriftet?
~ Wird jedes nicht ganz oben im Diagramm angeordnete Objekt explizit erzeugt?
~ Kollaborationsdiagramme: Sind neu erzeugte, transiente, zerstörte Objekte als solche gekennzeichnet?

• Zustandsdiagramme prüfen

Analyse

• Modelle gegeneinander abgleichen

1 Analyse-Klassenmodell - Anwendungsfallmodell
~ Konsistenz: Aktionen in den Szenarien - Operationen im Klassenmodell
⋅ Gibt es zu jeder Aktion in einem Szenario eine Operation im Klassenmodell und umgekehrt?
⋅ Für jedes Szenario gilt: Vorbedingung des Anwendungsfalls erfüllt → Vorbedingung der Operation für erste Aktion erfüllt
⋅ alle Operationen ausgeführt → Nachbedingung des Anwendungsfalls erfüllt

2 Analyse-Klassenmodell - Zustandsdiagramme
~ Konsistenz: Operationen im Klassenmodell - Aktionen im Zustandsdiagramm
⋅ Existiert für jede Aktion eines Zustandsübergangs eine Operation im Klassenmodell?
⋅ Erfüllt Ausgangszustand eines Zustandsübergangs die Vorbedingung der entspr Operation?
⋅ Passt die Nachbedingung der Operation zum Folgezustand des Zustandsübergangs?

3 Analyse-Klassenmodell - Interaktionsdiagramme
~ Existiert für jeden Operationsaufruf eine entsprechende Operation im Klassenmodell?
~ Entsprechen die Verbindungen den Assoziationen im Klassenmodell?
~ Passen Objekterzeugung & -zerstörung zur Semantik der betroffenen Aggregations- & Kompositionsbeziehungen?

4 Evtl Zustandsdiagramme - Interaktionsdiagramme

Architekturentwurf

• Ziel: Zerlegung in grosse Teilsysteme oder Komponenten
+ Komplexitätsbeherrschung
+ Arbeit auf mehrere Schultern verteilen & evtl Spezialisten übertragen

• Ergebnis: (Software-)Architektur
~ grundsätzliches Strukturierungsschema der Software
~ Rahmen für den Entwurf
~ dokumentiert in Architekturspezifikation

• Grundstein für Erfüllung der nichtfunktionalen Anforderungen
~ Qualitätsanforderungen: welche Qualitätsmerkmale in welchem Umfang
zB Verfügbarkeit (zB 24h/Tag)
zB Perfomanz (zB Antwortzeit unter 2 Sekunden)
zB Wartbarkeit
~ techn Vorgaben
zB Entwicklungsumgebung
zB Zielplattform
zB Implementierungstechnologie (zB Enterprise Java Beans)

• gute Architektur zeichnet sich aus durch:
~ Verwendung von Standards
~ möglichst grosse Unabhängigkeit vom Anwendungsbereich
~ Wiederverwendung bestehender Entwürfe, Entwurf wiederverwendbarer Module

Architekturentwurf

• unterschiedliche Aufgabenarten auf möglichst unabhängige Schichten mit getrennten Verantwortlichkeiten aufteilen
• Objekte rufen nur Objekte derselben oder einer tieferen Schicht auf
• 3-Schichten-Architektur
~ externe Schnittstelle
→ Interaktion Anwendungssystem - Akteure
⋅ Benutzungsschnittstelle
⋅ Zugriff externe Systeme
~ Anwendungskern
→ Gegenstände & Sachverhalte der Domäne
⋅ fachliche Funktionalität
⋅ fachliche Anwendungsobjekte & ihre Verbindungen
⋅ Einhaltung der Geschäftsregeln
~ Datenhaltung
→ persistente Speicherung
⋅ damit Objekte & Verbindungen das Programmende überleben
⋅ bei grossem Datenvolumen Objekte auf Sekundärspeicher auslagern

Entwurf

• Module (va Klassen) verkapseln Funktionalitäten, die von anderen Modulen benutzt werden können, ohne dass die Realisierung bekannt ist
→ Dienstnutzer kennt nur Schnittstelle des Dienstleisters

+ erzwingt korrekte Benutzung von Dienstleistern
+ reduziert Fehlerwahrscheinlichkeit
+ unterstützt arbeitsteilige Entwicklung
+ Änderungen bleiben lokal, ohne Auswirkungen auf andere Module

• realisiert durch Sichtbarkeit von Attributen & Operationen
R1 Attribute im Entwurf immer "privat"
⋅ Darstellung: -Attr
⋅ wenn implizite Standardoperationen setzeAtt(), gibAtt() → keine Sichtbarkeit angeben
~ Zugriff von Unterklassen mit #Standardoperation
⋅ Darstellung: #Attr
~ Operationen -privat, #protected oder +public

Entwurf

Kopplung:
• Beziehungskomplexität
~ Assoziation
~ Parametertyp
~ Erzeugung
~ Generalisierung
~ Interface-Implementierung
• möglichst schwach

Kohäsion:
• log Zusammenhang der von einer Klasse realisierten Aufgaben
• möglichst stark

schwache Kopplung & starke Kohäsion konkurrieren
• schwache Kopplung → schwache Kohäsion
~ zu wenige Klassen → Klassen gross & unübersichtlich
• starke Kohäsion → starke Kopplung
~ zu viele Klassen → Beziehungsgeflecht aufgebläht, geheime Details über Schnittstellen exponiert

• Kopplung abschwächen
H2 bis 3 Klassen stark gekoppelt? → zu 1 Klasse zusammenfassen
H3 >3 Klassen stark gekoppelt? → Vermittlerklasse
H4 starke Kopplung wegen einer Funktionalität? → F in andere Klasse verschieben
H5 starke Kopplung wegen mehreren Standardoperationen der Oberklasse? → komplexere Operation in der Oberklasse aufrufen
R6 Keine Teile-Klasse kennt ihre Ganzes-Klasse
R7 Teile-Klassen derselben Ganzes-Klasse benutzen sich nicht gegenseitig
H8 K.o() hat nur Zugang zu
⋅ K
⋅ Parametertypen von o()
⋅ mit K assoziierte Klassen
⋅ von o() instantiierte Klassen

• Kohäsion verstärken
H9 Attribute & Operationen einer Klasse disjunkt aufteilbar? → Klasse aufteilen
H10 Operation mit mehr als 1 eng umrissener Funktionalität? → auf mehrere Operationen aufteilen

Entwurf

Substituierbarkeitsprinzip:
• Unterklasseninstanzen können die Instanzen ihrer Oberklasse vertreten
• erfordert, dass die Spezifikation der Unterklasse zur Spezifikation der Oberklasse konform ist

konform:
• Wenn vor der Ausführung die Vorbedingung erfüllt war, muss nach der Ausführung die Nachbedingung erfüllt sein
~ Klasseninvariante: Bestandteil der Vor- & Nachbedingung jeder öffentlichen Operation
• Unterklasse konform zur Oberklasse → Generalisierung
~ sonst → bloss Vererbung
+ Vertragsentwurf direkt auf Unterklassen des Dienstleisters übertragbar
+ Operationen brauchen nicht zusätzlich mit konformen Klassen der Parametertypen getestet zu werden

H11 Unterklasse nicht konform, weil Oberklasse Eigenschaften hat, die für Unterklasse nicht zutreffen? → neue gemeinsame Oberklasse
H12 Klassen für Unterklassenbildung offen, für unkontrollierte Zugriffe geschlossen (Open-Closed-Principle)
~ Operationen die von potentiellen Unterklassen benutzt werden als protected kennzeichnen

Entwurf

Techniken:
• Spezifikation der Schnittstelle mit Vor-, Nachbedingungen, Klasseninvarianten

• klar geregelte Verantwortlichkeiten von Dienstnutzer & -leister
~ Dienstnutzer erfüllt Vorbedingung, Dienstleister garantiert Nachbedingung
~ beide erfüllen die Invariante ihrer Klasse
~ Vor- & Nachbedingungen werden nicht in Operation geprüft
~ Vertragsverletzung → Programmfehler

• systematische Behandlung von Ausnahmefällen
~ Bei erfüllter Vorbedingung müssen alle möglichen Fälle innerhalb der Methode behandelt werden
R13 Vor- bzw Nachbedingungen beinhalten keine vorhersehbaren Ausnahmefälle, die gesondert behandelt werden müssen.
~ Falls Dienstleister Aufgabe nicht erfüllen kann (Ausnahme), zB Hardwarefehler:
1 alternativen Lösungsweg, zB anderes Gerät benützen (Wiederanlauf)
2 Operation abbrechen → Ausnahme für Dienstnutzer

Entwurf

• Von Objekt, das eine Rolle spielt, wird oft nur Teil der Operationen & Attribute benötigt
• Interface definiert eine Menge von öffentlich sichtbaren Operationen (ohne Implementierungen)
• Eine Klasse realisiert ein Interface, indem sie seine Operationen implementiert
Darstellung:
• gestrichelter Generalisierungspfeil
+ Geheimnisprinzip wird besser gewahrt
+ ermöglicht spätere Aufteilung in Klassen, die je eine Rolle implementieren, ohne Auswirkung auf Dienstnutzung
+ Instanzen verschiedener Klassen mit gemeinsamer Eigenschaft einheitlich verwenden

Entwurf

• Dokumentation von Entwurfserfahrungen & Wiederverwendung von Entwürfen durch
~ Rahmenwerke (frameworks)
⋅ ganze Entwürfe wiederverwenden
⋅ teilweise implementiert
⋅ enthalten & instanziieren Entwurfsmuster
~ Entwurfsmuster (design patterns)
⋅ Entwurfserfahrung durch Dokumentation wiederverwendbar machen
⋅ lokal, wenige Klassen, feingranular
⋅ abstrakt, nicht implementiert
→ weniger mächtig, universeller einsetzbar als Rahmenwerke

Definition
• Entwurfsmuster = Beschreibung einer Familie von Lösungen für ein Entwurfsproblem
dient als
• konstruktive Vorlage
• deskriptives Vorbild für die Dokumentation von Entwurfsentscheidungen
• strukturelle Orientierung in einem komplexen Entwurf

Anwendungsbereich
• Klassenmuster:
∼ Beziehungen zw Klassen & Unterklassen, va Generalisierung
• Objektmuster
∼ Verbindungen zw Objekten, va Assoziationen

Auswahl
• Hinweise
~ nicht-funktionale Anforderungen
zB Unterstützung verschiedener grafischer Benutzungsoberflächen → Abstrakte Fabrik
~ Gründe für Überarbeitung des Entwurfs
zB Speicherplatzprobleme → strukturelle Muster
zB Performanzgründe → Verhaltensmuster
ZB mehr Flexibilität, Wartbarkeit
⋅ zu ändernde Aspekte verkapseln
↔ Speicherplatzeffizenz, Perfomanz

Einsatz
• im Entwurf möglichst explizit dokumentieren
~ entwurfsspezifische Interaktionsdiagramme, die die Wirkung von Mustern beschreiben
~ abstraktere Klassendiagramme, in denen Muster mit Mechanismen gekennzeichnet sind
⋅ gestrichelte Ellipse mit gestrichelten Abhängigkeitsbeziehungen zu den beteiligten Klassen
• nur einsetzen, wenn gewünschte Flexibilität auch wirklich benötigt wird
~ Muster bewirken zusätzliche Indirektionen (Operationsaufrufe)

Entwurf

Bedeutung
• abstrahieren den Instanziierungsprozess
• machen Software unabhängig davon, wie ihre Objekte erzeugt & zusammengesetzt werden
• wichtig, wenn Software mehr auf Komposition vieler Objekte aufbaut (als auf wenige Generalisierungshierarchien)

Beispiele
• Abstrakte Fabrik (abstract factory)
~ bietet eine Schnittstelle zum Erzeugen von Objekt-Familien, ohne ihre Klassen zu benennen
~ Klasse Dienstnutzer kennt nur Klassen AbstrakteFabrik, AbstraktesProdukt (blosse Schnittstellen)
~ Um eine bestimmte Produktfamilie zu erzeugen (zB UI-Elemente eines bestimmten Designs) wird eine Instanz der entsprechenden Klasse KonkreteFabrik erzeugt.
+ isoliert Anwendungssoftware von den realisierenden Klassen
+ vereinfacht Austausch ganzer Produktfamilien
+ erzwingt Konsistenz der von der Anwendungssoftware benutzten Produkte
- für jedes neue Produkt muss die betreffende Schnittstelle in KonkreteFabrik & KonkretesProdukt implementiert werden

• Einzelstück (singleton)
~ stellt sicher, dass von einer Klasse nur 1 Instanz existiert
~ Dienstnutzer greifen über Klassenoperation Einzelstück.gibEinzigeInstanz() auf die einzige Instanz zu.
+ Zugriff kontrollieren & beschränken
+ flexibler als Realisierung rein mit Klassenoperationen:
⋅ Erweiterung auf mehrere Instanzen möglich
⋅ erlaubt die Änderung der Operationen in Unterklassen
⋅ Einzelstück kann zur Laufzeit durch Instanz einer Unterklasse ersetzt werden

• Erzeuger (builder)
~ trennt Aufbau eines komplexen Objekts von seiner Darstellung
~ mittels desselben Konstruktionsvorgangs können verschiedene Repräsentationen erzeugt werden

• Fabrikmethode (factory method)
~ definiert eine Schnittstelle zur Erzeugung eines Objekts
~ überlässt die Entscheidung, welche Klasse zu instanziieren ist, den Unterklassen

• Prototyp (prototype)
~ spezifiziert die Art der zu erzeugenden Objekt über eine exemplarische Instanz
~ erzeugt neue Objekte durch Kopieren dieser Instanz

Entwurf

Bedeutung:
• beschreiben, wie Klassen bzw ihre Instanzen zu grösseren Strukturen zusammengesetzt werden können

Beispiele:
• Adapter (adapter)
~ wandelt die Schnittstelle dienstleistender Klassen so um, dass dienstnutzende Klassen sie verwenden können

• Brücke (bridge)
~ entkoppelt eine Abstraktion von ihrer Implementierung, damit beide unabhängig voneinander verändert werden können

• Dekorateur (decorator)
~ heftet dynamisch zusätzliche Verantwortlichkeiten (Operationen) an ein Objekt.
~ basiert auf Dienstnutzung
~ flexible Alternative (zur Generalisierung) für Funktionalitätserweiterung

• Fassade (façade)
~ einheitliche Schnittstelle für eine Menge von Schnittstellen
~ Strukturierungsebene oberhalb von Klassen
~ Klasse Fassade weiss, welche Klassen des Clusters für einen bestimmten Dienst zuständig sind
~ Dienstnutzer kommunizieren mit dem Cluster, indem sie Methoden der Fassade aufrufen, welche die Aufrufe an die entsprechenden Objekte weiterleitet
~ Dienstnutzer können vom Fassadenobjekt (oft Einzelstück) Referenzen auf Cluster-Objekte anfordern
~ Cluster kann in Java als Paket realisiert werden
⋅ Fassadenklasse & ausgewählte Klassen ausserhalb Paket sichtbar
⋅ alle anderen Klassen nur innerhalb des Pakets
+ reduziert Kopplung Dienstnutzer - Objekte eines Clusters
+ vereinfacht Benutzung des Clusters
+ verhindert nicht direkte Nutzung der Objekte (voller Funktionsumfang möglich)

• Kompositum (composite)
~ einheitlicher Zugriff auf Elemente hierarchischer Objektstrukturen
~ Schnittstelle, mit der individuelle Objekte (Blätter) und Kompositionen (innere Knoten) gleich behandelt werden können

• Surrogat (proxy)
~ stellt über ein stellvertretendes Objekt eingeschränkte Zugriffe auf das eigentliche Objekt zur Verfügung

Entwurf

Bedeutung:
• V beschreiben, wie eine gegebene Funktionalität auf Verantwortlichkeiten unterschiedlicher Klassen bzw ihrer Instanzen abgebildet werden kann
~ va Nachrichtenaustausch

Beispiele:
• Beobachter (observer)
~ 1-m-Abhängigkeit zw Objekten, damit Zustandsänderungen eines Objekts an andere gemeldet und diese aktualisiert werden können

• Iterator (iterator), Cursor
~ Zugriff auf die einzelnen Elemente einer Struktur, ohne die Implementierung der Struktur offenzulegen
~ Interface Iterator
⋅ Schnittstelle zum sequentiellen Zugriff auf die Elemente eine Behälterobjekts (zB Liste)
~ Klasse KonkreterIterator
⋅ implementiert das Interface
⋅ speichert den aktuellen Zustand des Behälterdurchlaufs
⋅ kann das nächste Objekt des Durchlaufs berechnen
~ Interface Behälter (zB Set)
⋅ definiert Operation iterator() zum Erzeugen eines Iteratorobjekts (& typ Behälteroperationen)
~ Klasse KonkreterBehälter (zB HashSet)
⋅ implementiert iterator()-Operation
+ ermöglicht verschiedene Arten eines Behälterdurchlaufs (Iteratorobjekt austauschen)
+ vereinfacht Schnittstelle von Behältern (keine Durchlaufoperationen)
+ mehrere Durchläufe parallel möglich

• Schablonenmethode (template method)
~ Grundgerüst eine Algorithmus
~ überlässt Unterklassen die Implementierung von Details
~ Klasse AbstrakteKlasse
⋅ definiert elementare Operationen (protected) für einen Algorithmus
⋅ implementiert Schablonenmethode als Gerüst des Algorithmus
~ Klasse KonkreteKlasse implementiert die elementaren Operationen
+ grundlegende Technik zur Codewiederverwendung
⋅ invertierte Kontrollstruktur: Oberklassse ruft Unterklassenoperationen auf (Hollywood-Prinzip)

• Vermittler (mediator)
~ Objekt, welches die Interaktionen mehrere anderer Objekte in sich verkapselt
~ schwächt Kopplung zw den anderen Objekten ab
~ ermöglicht unabhängige Änderung einzelner Interaktionen

• Zustand (state)
~ erlaubt einem Objekt, sein Verhalten abhängig vom Zustand zu verändern, so dass es als Instanz einer anderen Klasse erscheint

Grobentwurf

Ausgangspunkt:
• Analysespezifikation, ergänzt mit Teilen der Anforderungsspezifikation
• Architekturspezifikation

Aufgaben:
• Analyseklassen auf die vorgegebene Architektur abbilden
• Verhaltensmodellierung an Detaillierung des Klassenmodells des Grobentwurfs anpassen

Entwurfsentscheidungen:
• nur auf Kopien von Entitätsobjekten arbeiten
→ Änderungen werden erst nach Prüfung für Originale wirksam
• Prinzip der externen Kontrolle
~ Kontroll- & Entitätsklassen ggü Schnittstellenklassen nur Dienstleister
~ Entitätsklassen ggü Kontrollklassen nur Dienstleister
→ Schnittstellenklassen (verlängerter Arm des Benutzers) steuern das System

⇒ Grobentwurfsspezifikation hoher Stabilität
~ reduziert spätere Korrekturen
~ Verteilung der Arbeit auf verschiedene Teams

"gute" Grobentwurfspezifikation:
~ Gewährleistung aller Qualitätsanforderungen & techn Vorgaben
~ grösstmögliche Stabilität der Zerlegung
~ Berücksichtigen der Merkregeln (35)
~ grösstmögliche Unabhängigkeit von der Implementationssprache

Grobentwurf

• Analyseklassen kanonisch auf die einzelnen Schichten abbilden:
~ Schnittstelleklassen → externe Schnittstelle
~ Kontrollklassen, Entitätsklassen → Anwendungskern
~ (Entitäts-)Klassen als persistent markieren
~ Datenhaltung wird erst im Feinentwurf ausgestaltet

Grobentwurf

• bündelt Interaktion Anwendungssystem - Benutzer bzw externe Systeme
~ Funktionen auswählen & aktivieren
~ Daten ein- & ausgeben

• Schnittstellenklassen
~ Interaktionen von Akteuren in anwendungsinterne Ereignisse übersetzen
~ Anwendungsdaten in eine für die Akteure verwertbare Form überführen

• Benutzungsschnittstelle
~ Zustand bestimmt durch
⋅ sichtbare Fenster
⋅ dargestellte Information
⋅ mögliche Aktionen
~ Haupt-Schnittstellenklasse hinzufügen
⋅ modelliert Hauptfenster bzw Startseite des Systems
⋅ nur 1 Instanz
⋅ AnwendungssystemnameS
⋅ Spitze der Hierarchie der Schnittstellenklassen
⋅ Benutzeranmeldung → erzeugt Instanz der AS-Klasse
~ Sicht-Schnittstellenklassen (erst im Feinentwurf)
⋅ Instanzen von Entitätsklassen darstellen

• externe Systeme
~ können vom Anwendungsentwickler nicht geändert werden
~ wohldefinierte, oft prozedurale, selten standardisierte Schnittstelle
~ erfordern Konvertierung in bestimmte Datenformate
~ präjudizieren so wenig Entwurfsentscheidungen wie möglich
~ gewisse Anforderungen an Systemumgebung üblich (zB Verzeichnisnamen, Umgebungsvariablen, Peripherie)
~ häufig als unabhängiger Server-Prozess implementiert
~ bieten Dienste mehreren Benutzern an

• Anbindung an externe Systeme
~ besonders wartungssensibel
⋅ spätere Änderungen nicht kalkulierbar
⋅ Reagieren erst im Nachhinein möglich
~ externe Systeme verkapseln, um Schnittstellenänderungen möglichst lokal zu halten
⋅ AS-Klasse für jedes externe System
⋅ ausschliesslich aus Sicht des Dienstnutzers
→ Entscheidungsgrundlage für externes System oder Eigenentwicklung
⋅ meist als Fassadenklasse

Grobentwurf

• Haupt-Kontrollklasse hinzufügen
~ Pendant zur Haupt-Schnittstellenklasse
~ koordiniert Start des Anwendungssystems & Zugang zu allg verfügbaren Anwendungsfällen
~ nur 1 Instanz
~ von HS-Instanz erzeugt
~ AnwendungssystemnameK

• Entitätsklassen
~ persistente Klassen markieren
~ weitere Standardoperationen
⋅ K.gibAlleNamen()
⋅ K.gibKopie(in name: String): liefert Kopie der E-Instanz
⋅ K.gib(in name: String): liefert E-Instanz
⋅ i.kopiereAttribute(in instanz: E): kopiert alle Attribute von "instanz" in die ausführende E-Instanz

• Kontrollklassen
~ weitere Standardoperationen (für Schnittstellenobjekte)
zB i.gibENamen() : String liefert Liste mit Namen aller E-Instanzen
zB i.erzeugeE() : E erzeugt neue E-Instanz und gibt Kopie zurück

• Schnittstellenklassen
~ weitere Standardoperationen
⋅ i.öffnen() stellt das entsprechende Fenster dar
⋅ i.schliessen() entfernt das Fenster, beendet Anwendungsfall
⋅ i.abbrechen()
⋅ i.ausgeführt() wird bei Beendigung eines benutzten Anwendungsfalls aufgerufen

Grobentwurf

• Interaktionsdiagramme der Analyse für komplexe Anwendungsfälle verfeinern

• Abläufe von in den Anwendungsfällen auftretenden komplexen Operationen modellieren
~ Ausgangsbasis: textuelle Beschreibung der Verantwortlichkeiten der Operation
⋅ Erzeugt oder zerstört die Operation Instanzen oder Verbindungen von Klassen des Entwurfs?
~ Nicht-Standardoperationen nachtragen
~ Ablauf zB als Sequenzdiagramm modellieren

Feinentwurf

• Rahmenwerk für Benutzungsschnittstelle auswählen

• entscheiden, ob/welches Persistenz-Rahmenwerk

• inkrementell vorgehen
1. Benutzungsschnittstelle, Schnittstellen für externe Systeme entwerfen
2. Kontrollklasse des Anwendungsfalls um Operationen für externe Schnittstelle anreichern
~ fachliche Ereignisse behandeln
~ Entitätsinstanzen bereitstellen
~ Operationen & Kontrollklassen mit schwacher Kohäsion zerlegen
3. UML-Modellierungselemente mit Transformationsregeln in zielsprachenkonforme Entwurfskonstrukte überführen
4. grosse Pakete & Klassen zerlegen
~ lokal vorgehen, damit die existierenden Schnittstellen möglichst wenig tangiert werden
5. weitere Entitätsklassen in Persistenz-Rahmenwerk integrieren
~ Datenbankschema entwerfen
6. Klassen im Blick auf Realisierung mit Operationen & Datenstrukturen versehen
~ evtl Teilaspekte in neue, techn Klassen auslagern (↔ fachl Klassen)
~ fachl Klasse mit ihren techn Klassen in Paket kapseln

• immer auf Redundanzfreiheit achten

• Ergebnis: Entwurfsspezifikation
~ Kern: präzise & vollständig spezifiziertes Klassendiagramm
~ Datenbankschema
~ Interaktionsdiagramme für Abläufe
~ Zustandsdiagramme
~ Realisierungshinweise zu komplizierten Algorithmen

Feinentwurf

Charakteristika der BS:
• vom Benutzer bestimmte Dialogführung
→ Probleme mit vielen Dialogzuständen und aufwändigem, sequentiellem Kontrollfluss
• schnelle Reaktion auf Benutzeraktionen
→ Probleme bei kurz aufeinanderfolgenden Benutzeraktionen, die umfangreiche Berechnungen erfordern
• Darstellung komplexer Informationen
→ Probleme mit konsistenter Darstellung bei vielen Abhängigkeiten zwischen den dargestellten Daten

Elemente:
• Benutzungsoberfläche
~ die für die Benutzer sichtbaren & manipulierbaren Teile der BS
~ problemadäquate, komfortable BO ist wesentlich für Benutzbarkeit (usability) des Systems

• Fenster
~ Jedem Fenster entspricht eine Schnittstellenklasse
~ Steuerung durch den Benutzer:
⋅ Abbruch-Button → Änderungen werden ignoriert
⋅ OK-Button → Änderungen werden gespeichert
~ Unzulässige Eingaben werden von der für das Fenster verantwortlichen Schnittstelleninstanz zurückgewiesen
~ Fachlich anspruchsvollere Eingabefehler werde von der Kontrollklasse zurückgewiesen

• Auswahlmenüs
~ Merkmal von Haupt- & Akteur-Schnittstellenklassen
⋅ Pull Down-Menü ist hierarchisch aufgebaut
⋅ Pop Up-Menü zeigt alle Funktionen, die für das selektierte Objekt im Augenblick möglich sind
~ Einträge auswählen mit Maus oder Tastatur
⋅ bestimmte Taste (zB ALT)→ Vorwahltaste (Menü)→ Durchwahltaste (Operation)
~ Anordnung der Menüeinträge
⋅ Orientierung an Strukturen der Problemwelt
⋅ inhaltliche Gewichtung: wichtige Einträge am Anfang (oder Ende)
⋅ Anwendungshäufigkeit: frequentierteste Einträge am Anfang (oder Ende)
⋅ alphabetisch
~ max 7 Einträge
⋅ Übersichtlichkeit
⋅ Aufnahmekapazität des Kurzzeitgedächtnisses

Feinentwurf

• Haupt- & jede Akteur-Schnittstellenklasse auskleiden
~ so dass sie Fenster mit Auswahlmenüs darstellen kann
~ überladene Fenster in Haupt- & Unterfenster zerlegen
~ Auswahl eines Menüpunktes → Start eines Anwendungsfalls
~ beinhaltet alle drei Komponenten des MVC-Rahmenwerks
← keine eigentliche Funktionalität des Anwendungsystems

• AAS-Klassen aggregieren mehrere Sicht-Schnittstellenklassen (Sicht-Klassen)
~ Jede Sicht-Klasse beschreibt Attribute & Assoziationen einer Entitätsklasse
⋅ können vom Akteur in einem Fenster bearbeitet werden
~ AAS-KlasseEntitätsklasseS
~ sehr ähnliche Sichtklassen zusammenfassen
⋅ Anwendungsfall- oder Akteurname weglassen → EntitätsklasseS
~ view im MVC-Rahmenwerk, model: Entität

javax.swing:
• AS-Klasse, AAS-Klasse: JFrame
• Pull Down-Menü: JMenuBar, JMenu, JMenuItem
• Pop Up-Menü: JPopupMenu
• Auswahlliste: JList
• Sicht-Klasse: JPanel bzw JFrame
• Attribute: JComponent (zB JTextField) bzw JPanel
• Benutzerinteraktion: Beobachtermuster, XyzEvent (zB MenuEvent)

Feinentwurf

• Kontrollklassen mit Operationen anreichern
~ für Zugriff von externer Schnittstelle auf Entitätsobjekte der Datenhaltungsschicht
⋅ shallow copy: gelieferte Kopie einer Instanz enthält nur elementare Attribute, keine Referenzen
→ Schnittstellenklasse kennt Assoziationen zwischen Entitätsklassen nicht
⋅ Kontrollklasse liefert zB Liste mit den Namen der B-Instanzen, die mit der selektierten A-Instanz verbunden sind bzw werden können
~ für fachliche Funktionen

• Entitätsklassen ggf mit Operationen für "klassenlokale" fachliche Funktion anreichern

• systemdeterminiertes Ablaufverhalten von Anwendungsfällen in Kontrollklassen realisieren
~ müssen include- & extend-Beziehungen in eigener Regie realisieren
→ Kontrollobjekt des benutzenden Anwendungsfalls erzeugt Kontrollobjekt des benutzten Anwendungsfalls
~ Kommunikation zw Kontrollobjekten über Rückgabeparameter oder Entwurfsmuster Beobachter

Feinentwurf

Transformationen:
• UML-Modellierungselemente in zielsprachenkonforme Entwurfskonstrukte überführen

Assoziationen
• jeweils Standard-Operationen verbinde() & löse() entsprechend implementieren
• einseitig navigierbare 1:1-Assoziation
∼ A direkt auf neues Attribut der Klasse transformieren
• bidirektional navigierbare 1:1 Assoziation
~ A auf je ein Attribut in jeder der beiden Klassen transformieren
• einseitig navigierbare 1:n-Assoziation mit festem n
~ mit sehr kleinem n: für jede Referenz ein Attribut
~ mit grossem n: Referenzen in Feld (Java: Array)
• einseitig navigierbare 1:n-Assoziation mit variablem n
~ navigierbar zur 1-Klasse hin: wie 1:1-Assoziation
~ navigierbar zur n-Klasse hin: Referenzen in Behälterklasse (Java: Collection, Set, List)
• bidirektional navigierbare 1:n-Assoziation
~ in zwei einseitig navigierbare 1:n-Assoziationen aufspalten
• n:m-Assoziationen
~ Aufspaltung in zwei 1:n-Assoziationen → Verantwortung für Konsistenz verteilt
~ besser: Relationsklasse (1 Instanz), die alle Instanzen einer Paarklasse verwaltet
⋅ Iteratoren zum Zugriff auf die mit einer Instanz verbundenen Instanzen
⋅ nur Relationsinstanz erzeugt Paarinstanzen
• Assoziationsklasse
~ Assoziationsklasse realisiert Paarklasse
~ K.erzeuge() & i.verbinde()-Operationen dürfen nur von Relationsklasse benutzt werden
→ Assoziationsklasse & Relationsklasse im gleichen Paket & Sichtbarkeit "protected"

Feinentwurf

Def: Es gibt keine zu einer echten Ganzes-Klasse navigierbare, nicht-optionale Assoziation (Multiplizität > 0).
~ Es gibt Situationen, in denen ihre Instanzen nicht über Verbindungen von andern Instanzen erreichbar sind.

• Ordner-Klasse (Einzelstück) für jede echte Ganzes-Klasse
~ Ordner-Objekt hält alle Ganzes-Objekte nach (1:n-Assoziation)
~ Iteratoren für entsprechende Zugriffe

Feinentwurf

• Grobentwurf: einseitig navigierbare Assoziation zw den entsprechenden Schnittstellenklassen
• include
~ den benutzten Anwendungsfall über entsprechende Operationsaufrufe aktivieren
• extend
~ oft wie include
~ wo Unabhängigkeit & Flexibilität wichtig: Beobachtermuster
⋅ Schnittstellenklasse des erweiternden Anwendungsfalls meldet sich als Beobachter an
⋅ Scnnittstellenklasse des Basisanwendungsfalls erzeugt Ereignis beim Erreichen eines Erweiterungspunkts

Feinentwurf

Falsch:
• in jeder Operation die zustandsbestimmenden Attribute & Verbindungen abfragen & ändern (Zustandsänderung)
- Realisierung des zustandsorientierten Verhaltens ist in vielen Operationen verstreut
- Zustandsübergänge nur implizit durch Attributänderungen
- inkonsistenter Zustand möglich

Richtig:
• Entwurfsmuster Zustand (state)
~ abstrakte Klasse Zustand mit abstrakter Operation behandleEreignisX(), Teilklasse von Kontext (Komposition)
~ Zustandsabhängigkeit der Aktionsausführung durch unterschiedliche Implementierung der Operation behandleEreignisX() in den Unterklassen von Zustand
~ kontext.behandleEreignisX() ruft behandleEreignisX() ihrer verbundenen Zustandsinstanz auf
~ Zustandsänderung durch kontext.transition(folgezustand: Zustand)

Feinentwurf

• Pakete & Klassen in weniger komplexe, besser beherrschbare (Teil-)Pakete & Klassen zerlegen
~ lokal vorgehen, damit die existierenden Schnittstellen nicht tangiert werden ("einfrieren")
~ grosse Klassen mit schwacher Kohäsion & mehrfach genutzten Teilfunktionen in kleinere, besser wiederverwendbare Klassen zerlegen
~ Klassen aufteilen → Wiederverwendung
⋅ anwendungsspezifische Pakete
⋅ anwendungsunabhängige Pakete
zB Entitätsklassen mit entsprechenden Schnittstellenklassen sowie ggf Kontrollklassen allg Anwendungsfälle wie "Systemanmeldung"
zB Oberklassen & Interfaces, die das Zusammenspiel von Entitätsklassen mit der Benutzungsoberfläche & dem Persistenz-Rahmenwerk verkapseln.
zB (Hilfs-)Klassen aus Transformationen

⇒ in Schichten organisierte Paketaufteilung
4 anwendungsspezifische Module
3 anwendungsunabhängige Module
2 Middleware (zB Persistenz-RW, javax.swing)
1 Systemsoftware (zB MS-Windows, ODBC)