software engineering 3. analyse
Post on 03-Jul-2022
1 Views
Preview:
TRANSCRIPT
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.
top related