Your SlideShare is downloading. ×

Systementwurf mit UML

1,372

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,372
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×