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