1. SoftwareTechnik II
Christian Baranowski
HTWG Konstanz
Systementwurf
Systementwurf mit UML und Domain Driven Design

2. Anforderungsanalyse und
Spezifikation

3. Requirement Analysis
Testing
System Design
Coding
Delivery
Wasserfallmodell
Wir sind immer noch
in der Phase der
Anforderungsanalyse

4. Anforderungstypen
Funktionale
Anforderungen nicht
Funktionale
Anforderungen
Testbarkeit
Performanz
Sicherheit
Änderbarkeit
Verfügbarkeit
Anwendungsfälle
Geschäftsprozesse
Architekturziele
Bedienbarkeit
Qualitätsmerkmale
ISO9126
Quelle: Dr. Peter Hruschka & Dr. Gernot Starke - ARC42.de

5. Prozess zur Anforderungserfassung
1. Oberfläche skizzieren z.B. Methode Wireframes in einem
Workshop mit dem Kunden
2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und
JavaScript
3. Fachliche Komponenten aus dem Klick-Modell identifizieren
4. Use-Cases und Geschäftsmodell aus dem Klick-Modell
ableiten für die einzelnen fachlichen Komponenten
5. Spezifikation erstellen

6. Prozess zur Anforderungserfassung
1. Oberfläche skizzieren z.B. Methode Wireframes in einem
Workshop mit dem Kunden
2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und
JavaScript
3. Fachliche Komponenten aus dem Klick-Modell identifizieren
4. Use-Cases und Geschäftsmodell aus dem Klick-Modell
ableiten für die einzelnen fachlichen Komponenten
5. Spezifikation erstellen

7. Notationselemente
• Akteur
- Steht mir Use Case inVerbindung
- Hat immer einen Name
- Darstellung: z.B. als Strichmännchen
• Use Case
- Beschreibt nach außen sichtbares
Verhalten des Systems
- Von Akteur ausgelöst
- Hat Ergebnis, kein internes
Verhalten
- Darstellung: Ellipse
• Assoziationen
- Können gerichtet sein
- Nur binäre Assoziationen
- Darstellung: Linie
• System
- Beschreibt die System grenzen
- Darstellung: Rechteck

8. Anwendungsfälle erfassen mit
UML

9. Anwendungsfälle erfassen mit
UML

10. Übungen I
•Anwendungsfälle anhand des Klickpilot oder
Wireframes erfassen als UML Diagramm.

11. Use-Case als zentrales Analyseelement
Use-Case
Testbarkeit
Performanz
Sicherheit
Änderbarkeit
Verfügbarkeit
Bedienbarkeit
Architekturziele
UI Anforderungen
UI Design
Business Regeln
Daten Format
...

12. Anwendungsfälle spezifizieren
oder kurz gesagtText schreiben
•Tabellen basiere Beschreibung (Template)
•Domain spezifische Sprache zur Spezifikation
•Textuelle Beschreibung

13. Aufbau eines Anwendungsfalls
• Name und Nummer (z.B. Kunden verwalten / UC-2.01)
• Beschreibung
• Kurze Beschreibung, was im Anwendungsfall passiert.
• Beteiligte Akteure
• Akteure sind beteiligte Personen oder Systeme
• Verwendete Anwendungsfälle
• Aufzählung der verwendeten Anwendungsfälle
• Auslöser
• Vorbedingungen
• Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt
werden kann.
• Nachbedingung / Ergebnis
• Der Zustand, der nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet
wird.

14. Use-Case Beispiel

15. Nicht-funktionale Anforderungen I
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
1. Technische Anforderungen
1. 1. Design/Lösungen
1. 1. 1. Programmiersprache
1. 1. 2. Client / Arbeitsstation
1. 1. 3. Server
1. 1. 4. Netzwerk
1. 1. 5. Datenaustausch
1. 1. 6. Software
1. 1. 7. Hardware
1. 1. 8. Architektur
1. 1. 9. Einzusetzende Materialien
1. 1.10. Physikalische Aspekte
1. 2. Betriebliche Anforderungen
1. 2. 1. Physikalisches Umfeld
1. 2. 2. Technologisches Umfeld
1. 2. 3. Arbeitsplatz-Umgebung
1. 2. 4. Mengengerüst
1. 3. Neue Probleme
1. 3. 1. Auswirkungen bestehendes Umfeld
1. 3. 2. Auswirkungen auf die Benutzer
1. 3. 4. Kulturelle Aspekte
2. Anforderungen an die Benutzerschnittstelle
2. 1. Gestaltung und Beschriftung
2. 2. Konformität zu bestehenden Systemen
2. 3. Dialogführung
2. 4. Personalisierung und Internationalisierung
2. 5. Zugänglichkeit
2. 6. Verschiedenes

16. Nicht-funktionale Anforderungen II
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
3. Qualitätsanforderungen
3. 1. Benutzbarkeit
3. 1. 1. Verständlichkeit
3. 1. 2. Bedienbarkeit
3. 1. 3. Erlernbarkeit
3. 1. 4. Effektivität
3. 1. 5. Einheitlichkeit
3. 2. Effizienz
3. 2. 1. Verbrauchsverhalten
3. 2. 2. Zeitverhalten
3. 3. Produktnutzungszeitraum
3. 3. 1. Wartung
3. 3. 2. Produzierbarkeit
3. 3. 3. Produktentsorgung
3. 3. 4. Langlebigkeit
3. 4. Safety und Security
3. 4. 1. Schutz der Systemumgebung
3. 4. 2. Schutz des Systems
3. 5. Übertragbarkeit
3. 5. 1. Anpassbarkeit
3. 5. 2. Konformität
3. 5. 3. Installierbarkeit
3. 5. 4. Austauschbarkeit
3. 5. 5. Wiederverwendbarkeit
3. 6. Zuverlässigkeit
3. 6. 1. Fehlertoleranz
3. 6. 2. Reife
3. 6. 3. Wiederherstellbarkeit
3. 7. Änderbarkeit
3. 7. 1. Analysierbarkeit
3. 7. 2. Modifizierbarkeit
3. 7. 3. Stabilität
3. 7. 4. Testbarkeit
3. 8. Funktionalität
3. 8. 1. Richtigkeit
3. 8. 2. Ordnungsmäßigkeit
3. 8. 3. Funktionsabdeckung
3. 8. 4. Funktionale Widerspruchsfreiheit
3. 8. 5. Interoperabilität
3. 8. 6. Angemessenheit
3. 8. 7. Verfolgbarkeit
3. 9. Durchführbarkeit

17. Nicht-funktionale Anforderungen III
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
4. Anforderungen an sonstige Lieferbestandteile
4. 1. Software-Dokumentation
4. 1. 1. Requirements Spec./ Pflichtenheft
4. 1. 2. Architektur und Design
4. 1. 3. Interfaces / Schnittstellen
4. 2. Hardware-Dokumentation
4. 3. Testdokumentation
4. 4. Prototypen
4. 5. Wartungshandbuch
4. 6. Installationshandbuch
4. 7. Benutzerdokumentation
4. 7. 1. Hilfs- und Lernprogramme
4. 7. 2. Benutzerhandbuch
4. 7. 3. Administrationshandbuch
4. 8. Schulungen
4. 9. Marketing und Vertrieb
4.10. Hardware
4.11. Projekt Management
4.11. 1. Projektplan und -beschreibung
4.11. 2. Richtlinien
4.12. Support
4.13. Allgemein
5. Anforderungen an durchzuführende Tätigkeiten
5. 1. Produktlebenszyklus
5. 1. 1. Analyse
5. 1. 2. Architektur und Design
5. 1. 3. Implementierung
5. 1. 4. Tests
5. 1. 5. Fertigung
5. 1. 6. Installation
5. 1. 7. Auslieferung
5. 1. 8. Wartung
5. 1. 9. Support
5. 2. Anforderungsmanagement
5. 3. Projekt Management
5. 3. 1. Projekthandbuch
5. 3. 2. Projekt Plan
5. 3. 3. Rollen
5. 3. 4. Kommunikationsrichtlinien
5. 4. Qualitätsmanagement
5. 5. Konfigurationsmanagement
5. 6. Änderungsmanagement
5. 7. Risikomanagement
Fortsetzung

18. Nicht-funktionale Anforderungen IV
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
5. 8. Benutzerdoku. und Schulungen
5. 8. 1. Benutzerhandbuch und Hilfesystem
5. 8. 2. Schulungs- und Lernunterlagen
5. 8. 3. Schulungen
5. 8. 4. Administrationsdokumentation
5. 9. Allgemein
5. 9. 1. Standards
5. 9. 2. Dokumentationsmanagement
6. Rechtlich-vertragliche Anforderungen
6. 1. Vertragliche Anforderungen
6. 2. Anforderungen an den Auftragnehmer
6. 3. Lieferantenmanagement
6. 4. Kosten
6. 4. 1. Financial Budget for the Project
6. 5. Angebot
6.5.1. Formale Aspekte
6.5.2. Inhalt des Angebotes
6. 6. Rechtliche Anforderungen
6. 7. Compliance Requirements
6. 7. 1. Gesetzliche Anforderungen
6. 7. 2. Standards

19. Geschäftsmodell
erfassen und modellieren mit der UML

20. UML KlassendiagrammeTeil 1
Klassendiagramme sind Strukturdiagramm
der UML zur grafischen Darstellung von
Klassen und deren Beziehungen.

21. Klassen und Assoziationen

22. Kardinalitäten

23. Kardinalitäten

24. Kardinalitäten

25. Kardinalitäten

26. Gerichtet und
Bidirektionale Assoziation

27. Gerichtet und
Bidirektionale Assoziation

28. Aggregation

29. Komposition

30. Vererbung

31. Spezifikation erstellen
Gesamtspezifikation / Pflichtenheft

32. Template Gesamtspezifikation
Anforderungsanalyse
1. Einleitung
2. Ausgangssituation und Zielsetzung
3. Funktionale Anforderungen
4. Nicht-funktionale Anforderungen
5. Sicherheitsrelevante Anforderungen, Risikoakzeptanz
und Sicherheitsstufen
6. Lebenszyklusanalyse und Gesamtsystemarchitektur
7. Schnittstellenübersicht

33. Template Anforderungsanalyse
Quelle: http://www.volere.co.uk
PROJECT DRIVERS:
1. The Purpose of the Project
2. Client, Customer, Stakeholders
3. Users of the Product
PROJECT CONSTRAINTS:
4. Mandated Constraints
5. Naming Conventions and Definitions
6. Relevant Facts and Assumptions
FUNCTIONAL REQUIREMENTS:
7. The Scope of the Work
8. The Scope of the Product
9. Functional and Data Requirements
NON-FUNCTIONAL REQUIREMENTS:
10. Look and Feel
11. Usability and Humanity
12. Performance
13. Operational
14. Maintainability and Support
15. Security
16. Cultural and Political
17. Legal
PROJECT ISSUES:
18. Open Issues
19. Off-the-shelf Solutions
20. New Problems
21. Tasks
22. Cutover
23. Risks
24. Costs
25. User Documentation and Training
26. Waiting Room
27. Ideas for Solutions

34. •Geschäftsmodell (Klassendiagramm) entwickeln
•Erstellen sie eine kleine Gesamtspezifikation
Übungen II

35. Systementwurf
und Software Architekturen

36. Requirement Analysis
Testing
System Design
Coding
Delivery
Wasserfallmodell

37. Architektursichten
Kontextsichten
Verteilungssichten
Bausteinsicht
Laufzeitsichten

38. Architekturprinzipien
• Schichten einer Applikation
Jede Schicht (Tier) ist für eine Aufgabe
zuständig. In einer Anwendung fallen
i.d.R. die folgenden Kernaufgaben an:
• Darstellen von Daten
• Verarbeitung der Benutzereingaben
(Interaktionen)
• Verarbeitung Geschäftslogik
• Speichern von Daten

39. UML für Architekten

40. Wie kann die UML genutzt werden?
Kommunikation
Detail Design
UML als Programmiersprache
Dokumentation
Model Driven Architecture, DLSs...

41. UML - DiagrammTypen

42. UML reicht nicht !!!
!"##$% !&'($'%)$*+",-$'%
!&'($'%.$"/$0-$'%1/*$23&'4%
#5$023$*'%
6$&%7($*%
/$"*/$0-$'%
Beispiel Navigation mit Flow Diagramm

43. UML Klassendiagramme II

44. Schnittstellen

45. Schnittstellen Implementieren

46. Abstraktion in Modellen ...

47. Abhängigkeiten Beziehungen

48. UML Klassendiagramme

49. UML Klassendiagramme

50. UML Klassendiagramme

51. Domain Driven Design

52. ENTITIES

53. VALUE OBJECT

54. SERVICES

55. REPOSITORIES

56. FACTORIES

57. Domain Driven Design
Entity
Service
Repository
Value Object

58. Domain
Driven
Design

59. Domain
Driven
Design

60. Domain
Driven
Design

61. •Erstellen Sie ein Domain Modell für Ihre Aufgaben-
Verwaltung
Übungen III

62. UML Sequenzdiagramme

63. UML Nachrichten und
Operationen

64. UML Nachrichten und
Rückgabewerte

65. UML Erstellen und Löschen
Participants

66. UML Schleifen

67. Sequenzdiagramme
Alternative - CRC Cards
!"#$%!$&'()$%
*&+,$-%."//%.$&%!$##$&%$0(/1$&2% !$##$&345%
*6/(16-%/7$()8$&-% *6/(16-345%
999% 999%
:#"//%;"<$%
=$/76-(>(#(2?% :6##">6&"16-%

68. •Erstellen Sie für das Speichern einer Aufgabe ein
Sequenzdiagramme.
Übungen III

69. UML Deployment Diagramme

70. UML Deployment Diagramme

71. UML Komponenten Diagramm

72. UML Komponenten Komposition

73. Trennung fachliche und technischer
Architektur
• T – Komponenten
• Stellen eine technische Schnittstelle bereit.
• A – Komponenten
• Domain Komponenten z.B. Bestellung Service.
• R – Komponenten
• Komponenten für die Präsentation dürfen technische Komponenten nutzen und auf die A
Komponenten zugreifen.
• 0 – Komponenten
• Komponenten die in der gesamten Anwendung genutzt werden dürfen. Z.B. Logger
Komponente.
• R auf A ist erlaubt,T auf A ist nicht erlaubt
• R auf 0,A auf 0 undT auf 0 ist erlaubt

74. A – Komponenten
T – Komponenten
R – Komponenten

75. Architektursichten
Kontextsichten
Verteilungssichten
Bausteinsicht
Laufzeitsichten

76. •Erstellen Sie ein Komponenten Diagramm für die
Aufgaben-Verwaltung
Übungen IV

77. •Erstellen Sie einen knappen Systementwurf für die
Aufgabenverwaltung
Übungen IV