Software Technik II
Christian Baranowski
HTWG Konstanz
SystementwurfSystementwurf mit UML und Domain Driven Design
Anforderungsanalyse und Spezifikation
Requirement Analysis
Testing
System Design
Coding
Delivery
WasserfallmodellWir sind immer noch in der Phase der Anforderungsanalyse
Anforderungstypen
FunktionaleAnforderungen nicht
FunktionaleAnforderungen
Testbarkeit
Performanz
Sicherheit
Änderbarkeit
Verfügbarkeit
Anwendungsfälle
Geschäftsprozesse
Architekturziele
Bedienbarkeit
QualitätsmerkmaleISO9126
Quelle: Dr. Peter Hruschka & Dr. Gernot Starke - ARC42.de
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
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
Notationselemente
• Akteur
- Steht mir Use Case in Verbindung
- 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
Anwendungsfälle erfassen mit UML
Anwendungsfälle erfassen mit UML
Übungen I
•Anwendungsfälle anhand des Klickpilot oder Wireframes erfassen als UML Diagramm.
Use-Case als zentrales Analyseelement
Use-Case
Testbarkeit
Performanz
Sicherheit
Änderbarkeit
Verfügbarkeit
Bedienbarkeit
Architekturziele
UI Anforderungen
UI Design
Business Regeln
Daten Format
...
Anwendungsfälle spezifizierenoder kurz gesagt Text schreiben
•Tabellen basiere Beschreibung (Template)
•Domain spezifische Sprache zur Spezifikation
•Textuelle Beschreibung
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.
Use-Case Beispiel
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
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
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
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
Geschäftsmodell erfassen und modellieren mit der UML
UML Klassendiagramme Teil 1
Klassendiagramme sind Strukturdiagramm der UML zur grafischen Darstellung von Klassen und deren Beziehungen.
Klassen und Assoziationen
Kardinalitäten
Kardinalitäten
Kardinalitäten
Kardinalitäten
Gerichtet und Bidirektionale Assoziation
Gerichtet und Bidirektionale Assoziation
Aggregation
Komposition
Vererbung
Spezifikation erstellen Gesamtspezifikation / Pflichtenheft
Template GesamtspezifikationAnforderungsanalyse
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
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
•Geschäftsmodell (Klassendiagramm) entwickeln
•Erstellen sie eine kleine Gesamtspezifikation
Übungen II
Systementwurf und Software Architekturen
Requirement Analysis
Testing
System Design
Coding
Delivery
Wasserfallmodell
ArchitektursichtenKontextsichten
Verteilungssichten
Bausteinsicht
Laufzeitsichten
Architekturprinzipien
• Schichten einer ApplikationJede 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
UML für Architekten
Wie kann die UML genutzt werden?
Kommunikation
Detail Design
UML als Programmiersprache
Dokumentation
Model Driven Architecture, DLSs...
UML - Diagramm Typen
UML reicht nicht !!!
!"##$% !&'($'%)$*+",-$'%
!&'($'%.$"/$0-$'%1/*$23&'4%
#5$023$*'%6$&%7($*%
/$"*/$0-$'%
Beispiel Navigation mit Flow Diagramm
UML Klassendiagramme II
Schnittstellen
Schnittstellen Implementieren
Abstraktion in Modellen ...
Abhängigkeiten Beziehungen
UML Klassendiagramme
UML Klassendiagramme
UML Klassendiagramme
Domain Driven Design
ENTITIES
VALUE OBJECT
SERVICES
REPOSITORIES
FACTORIES
Domain Driven Design
Entity
ServiceRepository
Value Object
Domain Driven Design
Domain Driven Design
Domain Driven Design
•Erstellen Sie ein Domain Modell für Ihre Aufgaben-Verwaltung
Übungen III
UML Sequenzdiagramme
UML Nachrichten und Operationen
UML Nachrichten und Rückgabewerte
UML Erstellen und Löschen Participants
UML Schleifen
SequenzdiagrammeAlternative - CRC Cards
!"#$%!$&'()$%*&+,$-%."//%.$&%!$##$&%$0(/1$&2% !$##$&345%
*6/(16-%/7$()8$&-% *6/(16-345%
999% 999%
:#"//%;"<$%
=$/76-(>(#(2?% :6##">6&"16-%
•Erstellen Sie für das Speichern einer Aufgabe ein Sequenzdiagramme.
Übungen III
UML Deployment Diagramme
UML Deployment Diagramme
UML Komponenten Diagramm
UML Komponenten Komposition
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 und T auf 0 ist erlaubt
A – Komponenten
T – Komponenten
R – Komponenten
ArchitektursichtenKontextsichten
Verteilungssichten
Bausteinsicht
Laufzeitsichten
•Erstellen Sie ein Komponenten Diagramm für die Aufgaben-Verwaltung
Übungen IV
•Erstellen Sie einen knappen Systementwurf für die Aufgabenverwaltung
Übungen IV