Software Engineering

3. Analyse

Prof. Dr. Klaus Dorer

III-2

Übersicht

◼ Analyse

▪ Modellierung

▪ Modellierung mit UML

▪ Use Case Diagramm

▪ Klassendiagramm

▪ Objektdiagramm

▪ Aktivitätsdiagramm

▪ Zustandsdiagramm

▪ Sequenzdiagramm

◼ Ziele

▪ Anhand von Anforderungen ein Analysemodell mit statischen und dynamischen

Aspekten erstellen können

▪ Besprochene Diagramme und Sichten der UML, kennen, lesen und erstellen können

▪ Den Unterschied zwischen einem Analysemodell und einem Design Modell verstehen

III-3

Modellierung

◼ Was ist ein Modell?

◼ Architektur

▪ Beispiel Neubau D-Gebäude

▪ Vorteile eines Modells?

III-4

Übersicht

Problem space Solution space

Ab

stra

ct le

ve

lC

on

cre

te le

ve

l

Concrete

problem

Analysis

modelDesign

Model

Implemented

system

analysis

transformation

implementation

III-5

Modellierung

◼ Softwaretechnik

▪ Beschreibung der Anforderungen an ein Softwaresystem

▪ Beschreibung der Architektur und des Designs von Softwaresystemen

Realität

DispatcherKundenkontakt

Auftrag erfassen

Auftrag disponieren

Mitarbeiter

Kundenkontakt Dispatcher

Auftrag

ModellAbstraktion Konkretisierung

Softwaresystem

Benutzersicht

Entwicklersicht

Dynamische Sicht

Statische Sicht

Dispositionszentrale

aus Sicht Süd-West

III-6

Analysemodell

◼ Ergebnis der Analyse ist ein fachliches Modell der Anforderungen an das

Softwaresystem

▪ Was soll gemacht werden

▪ Konsistent, vollständig, eindeutig

◼ Berücksichtigt keine technischen Aspekte wie

▪ Verteilung der Anwendung auf mehrere Rechner

▪ Begrenzter Speicherplatz

▪ Genaue Form der Datenspeicherung

◼ UML als Modellierungssprache

III-7

UML

◼ 1997 von Booch, Jacobsen und Rumbaugh

vorgestellt

◼ www.uml.org

Grady

Booch

Ivar

Jacobsen

James

Rumbaugh

Quelle: Wikipedia

Quelle: Winter

III-8

UML

◼ Standard Modellierungssprache in der Informatik

▪ Für Objektorientierte Modellierung

▪ Programmiersprachenunabhängig

▪ aktuelle Version 2.5.1 (Dezember 2017)

◼ Definiert

▪ Bezeichner für modellierungsrelevante Begriffe

▪ Beziehungen zwischen den Begriffen

▪ Grafische Notation

◼ Werkzeuge

▪ Frei

▪ Visual Paradigm, Dia, Fujaba, StarUML, Umbrello, TOPCASED

▪ Kommerziell

▪ Visual Paradigm, Rational Rose, Enterprise Architect, Together, …

III-9

UML

◼ Diagramme

Diagramm

Strukturdiagramm

Klassendiagramm

Objektdiagramm

Kompositionsstrukturdiagramm

Komponentendiagramm

Verteilungsdiagramm

Paketdiagramm

Interaktionsübersichtsdiagramm

Timing-Diagramm

Kommunikationsdiagramm

Sequenzdiagramm

Interaktionsdiagramm

Zustandsdiagramm

Aktivitätsdiagramm

Anwendungsfalldiagramm

Verhaltensdiagramm

III-10

UML

◼ UML ist eine grafische Sprache

▪ Symbole haben Bedeutung

▪ ist anders als ist anders als

▪ ist anders als ist anders als

▪ ist anders als ist anders als

▪ Bedeutung hängt vom Kontext ab

▪ Aktion in einem Aktivitätsdiagramm, Zustand in einem Zustandsdiagramm

▪ Kommentar

▪ Diagrammrahmen

III-11

Use Case Diagramm

◼ Modellieren die Funktionalität eines Systems auf hohem Abstraktionsniveau

▪ Auch Anwendungsfalldiagramm oder Geschäftsprozessdiagramm genannt

▪ Beschreibt Zusammenhänge von Akteuren und Use Cases

▪ Definiert nicht, wie das System arbeitet

▪ Macht keine Angaben über die Reihenfolge

von Use Cases

uc Übersicht

Restaurant

Gericht bestellen

Gast

VipGast

Persönlichen Kellner

verlangen

Rechnung bezahlen

extension points:

Betragannahme

Kellner

Mit Kreditkarte

bezahlen

Polizei rufen

«actor»Kreditkarten-Gesellschaft

Gericht verspeisen

Kreditkarte prüfen

«include»

«extend»

1

1..*

1 0..*

1 1..*

III-12

Use Case Diagramm

◼ Systemgrenze

▪ Umfasst ein System, das die benötigten Use Cases bereitstellt für die Akteure

▪ Elemente innerhalb sind Bestandteile des Systems

▪ Elemente außerhalb sind Akteure

▪ Name des Systems oben

Restaurant

III-13

Use Case Diagramm

◼ Akteur

▪ Modelliert einen Typ oder eine Rolle eines externen Benutzers oder Systems

▪ Meist nicht eine einzige physische Instanz

▪ Sind immer außerhalb der Systemgrenze

▪ Personen werden meist mit dem Strichmännchensymbol dargestellt

Gast

«actor»Kreditkarten-Gesellschaft

III-14

Use Case Diagramm

◼ Use Case

▪ Auch Anwendungsfall oder Geschäftsprozess genannt

▪ Abgeschlossene Menge von Aktionen, die das System bereit stellt und einen

erkennbaren Nutzen für einen oder mehrere Akteure erbringt

▪ Definieren nicht wie das System die Funktion bereitstellt

▪ Position innerhalb einer Systemgrenze definiert, welches System die Funktionalität zur

Verfügung stellt

▪ Wird meist auch informal durch Text beschrieben

Gericht bestellen

«Use Case»Gericht bestellen

III-15

Use Case Diagramm

◼ Schablone für schriftliche Beschreibung eines Use Case

▪ Name (wie im Diagramm)

▪ Ziel

▪ Priorisierung

▪ Primär, sekundär, optional

▪ 1 - 10

▪ Vorbedingung

▪ Notweniger Zustand, damit Use Case durchgeführt werden kann

▪ Nachbedingung bei Erfolg

▪ Erwarteter Zustand nach erfolgreicher Beendigung

▪ Nachbedingung bei Fehlschlag

▪ Erwarteter Zustand, nach erfolgloser Bearbeitung

▪ Akteure (wie im Diagramm)

▪ Auslösendes Ereignis

III-16

Use Case Diagramm

◼ Use Case

◼ Abstraktionsniveau

▪ Richtig

▪ ‚Bild machen‘ und ‚SD Karte wechseln‘ sind high level

Aktivitäten die ein Fotograf mit einer Kamera durchführt

▪ Falsch

▪ Shutter öffnen ist keine Aktivität, die der Fotograf in einer

Sitzung alleinig ausführt

III-17

Use Case Diagramm

◼ Assoziation

▪ Modelliert eine Beziehung zwischen Akteur und Use Case

▪ Kann Multiplizitäten enthalten

▪ Ein Gast kann mehrfach Gerichte bestellen

▪ Gerichtete Assoziationen definieren Kommunikationsrichtung

▪ Der Kellner kann den Use Case Gericht bestellen nicht initiieren

▪ Alle Akteure, die mit einem Use Case assoziiert sind werden benötigt

▪ Für eine Bestellung werden Gast und Kellner benötigt

Restaurant

Gericht bestellen

Gast Kellner

1 1..*

III-18

Use Case Diagramm

◼ Generalisierung

▪ Definiert eine Beziehung zwischen einem spezifischen und einem allgemeinen Element

▪ Kann zwischen Akteuren oder zwischen Anwendungsfällen definiert werden

▪ Ein Akteur erbt alle Assoziationen der Oberklasse

▪ Wird oft zur Modellierung unterschiedlicher Rechte verwendet

▪ Der Use Case „Mit Kreditkarte bezahlen“ spezialisiert den Use Case „Rechnung

bezahlen“ und kann ihn vollständig ersetzen

Restaurant

Rechnung bezahlen

Mit Kreditkarte bezahlen

Persönlichen Kellner

verlangen

Gast

VipGast

III-19

Use Case Diagramm

◼ Include-Beziehung

▪ Modelliert die unbedingte Einbindung der Funktionalität eines Use Cases in einen

anderen

▪ Bei Aufruf des einbindenden Use Cases muss auch der eingebundene aufgerufen

werden

▪ Eingebundene Use Cases können selbst Use Cases einbinden, es dürfen aber keine

Zyklen entstehen

▪ Vermeidung von Redundanz, wenn eingebundener Use Case in mehreren

übergeordneten verwendet wird

▪ Eingebundene Use Cases müssen Use Cases für sich sein

uc Include

Mit Kreditkarte

bezahlen

Kreditkarte prüfen«include»

III-20

Use Case Diagramm

◼ Extend-Beziehung

▪ Modelliert die bedingte Einbindung eines Use Case in einen anderen

▪ Der erweiterte Use Case ist unabhängig und kann auch ohne den erweiternden

ausgeführt werden

▪ Liste der möglichen Erweiterungspunkte (extension points) wird im Use Case unterhalb

eines Trennstrichs angegeben

▪ Anmerkung an der Beziehung kann Bedingung definieren, bei der der erweiternde Use

Case aufgerufen wird

uc Extend

Rechnung bezahlen

extension points:

Betragannahme

Polizei rufen

Condition: {erhaltener

Betrag < Preis}

extension point:

Betragannahme

«extend»

III-21

Häufige Fehler

◼ Zu niedriges Abstraktionsniveau

▪ Use Cases sollen nicht dazu verwendet werden, den Ablauf anderer Use Cases im Detail

zu modellieren

▪ Verwenden sie include und extend sparsam

◼ Miracle Use Case

▪ Nicht durchführbarer Use Case

▪ Ein Use Case, der keine oder nur ausgehende Assoziationen hat, kann nicht aufgerufen

werden und ist somit nutzlos

◼ Assoziation zwischen Use Cases

▪ Nur zwischen Actors und Use Cases erlaubt

◼ Akteur innerhalb des Systems

▪ Ein Akteur muss immer außerhalb des Systems sein

III-22

Gibt es hier Fehler? Welche?

Use Case Diagramm - Übung

III-23

Use Case Diagramm - Monopoly

Erstellen Sie ein Use Case Diagramm für Monopoly

III-25

Anforderungsanalyse

◼ Funktionale und Nicht-Funktionale Anforderungen müssen getestet werden

können

◼ Beispiele

▪ Schlecht: Alte Aufträge sollen aus der Datenbank gelöscht werden

▪ Gut: Aufträge die mehr als 90 Tage als abgeschlossen markiert sind, wechseln in den

Zustand ‚gelöscht‘ und sind damit nur noch für die Archivierungssoftware relevant.

Aufträge, die mehr als 120 Tage im Status ‚gelöscht‘ sind‚ werden physikalisch aus der

Datenbank gelöscht

▪ Schlecht: Die Software soll einfach auf Verarbeitung von Sammelaufträgen erweiterbar

sein

▪ Gut: Die Erweiterung der Software auf Sammelaufträge darf nicht länger als drei Wochen

dauern

III-26

Anforderungsanalyse„Adaptive Cruise Control“ soll den Abstand vorausfahrender Fahrzeuge messen.“Nennen Sie mindestens fünf Gründe, warum diese Teilanforderung schlecht formuliert ist und wie man es besser machen könnte.