1 Dozenten: Markus Rentschler Andreas Stuckert Version 17.07.2015 Software Engineering I VE 08:...

Version 04/26/23

Software Engineering I VE 08: Analysephase 1

Dozenten:Markus RentschlerAndreas Stuckert

Vorlesung

Software Engineering I

Analysephase

Version 04/26/23



Entwicklungsphasen: Inputs, Outputs

Analyse Design Codierung Test Einführung Wartung

SAS, MODsImplementierung,

Modultests

BugreportsChange Requests (CRQ)

SAS, MODsImplementierung,

Modultests

Systemtestplan (STP),Systemvalidierungsplan

(SVP)

SAS, MODs,Implementierung,

ModultestsKundenanforderungen,

Lastenheft (CRS

Pflichtenheft (SRS)Systemspezifikation (Grob-,Feinentwurf)

BugreportsChange Requests (CRQ)

Systemmodellierung,Pflichtenheft (SRS) Bugreports,

Change Requests (CRQ)

Systemtestreport (STR),Systemvalidierungs-

report (SVR)

MODs,Systemintegrations-

report (SIR)

Architekturspezifikation (SAS),

Modulspezifikationen (MODs)

Version 04/26/23



Analysephase

• Beschreibung des zu lösenden Problems und aller wichtigen Umgebungsbedingungen - möglichst vollständig und eindeutig.

• Ergebnis der Anforderungsermittlung ist das Lastenheft (CRS), welches die Kundenanforderungen enthält (Klärung des WAS)

• Untersuchung der Durchführbarkeit der geplanten Systementwicklung

• Ergebnis der Anforderungsanalyse ist das Pflichtenheft (SRS), welches die aus den Kundenanforderungen abgeleitete Systemanforderungen und ein Systemmodell enthält (Klärung des WIE aus Black-Box-Sicht).

Version 04/26/23



Analyse

Anforderungs-Ermittlung

Anforderungsanalyse, Systemmodellierung

Produkt-Spezifikation(Pflichtenheft)

“Projektstart“

Analysephase Designphase

Anforderungs-Spezifikation(Lastenheft)

Design

Architekturentwurf

Detailentwurf

Architektur-Spezifikation

Modul-/Klassen-Spezifikationen

Version 04/26/23



Die Analysephase

• Ziel der Analysephase ist die– vollständige– konsistente– eindeutige

Definition des zu realisierenden Produkts durch die Spezifizierung eines Produktmodells.

• Das Produktmodell kann bestehen aus: – Pflichtenheft (Vertragsgrundlage!)– Analysemodell– Prototypen

Version 04/26/23



Das Pflichtenheft

• Aufgabe:– Zusammenfassung aller fachlichen Anforderungen

• Adressaten:– Auftraggeber, Auftragnehmer (Projektleiter, Systemanalytiker,

Entwickler, ...)

• Inhalt: – fachlicher Funktions-, Daten- und Leistungsumfang,

Qualitätsanforderungen– Abnahmekriterien (spätestens hier festzulegen)!

Version 04/26/23



Pflichtenheft: Standards

• Ein sehr bekannter Standard zum Requirements Management ist der IEEE 830 (Recommended Practice for Software Requirements Specifications). Er ist ein konkreter praxisnaher Standard für die Beschreibung und die Definition von Softwareanforderungen. Es werden Strukturen vorgeben für den Aufbau der Dokumentation, den Aufbau der einzelnen Anforderungen und sogar zur Formulierung der Anforderungen.

• Eine gute Ergänzung hierzu ist der Standard IEEE 1362 (Guide for Information Technology – System Definition, Definition - Concept of Operations Document), der letztendlich ein Standard für Anforderungsdokumente (Lasten-/Pflichtenhefte) darstellt.

• Eine weitere sinnvolle Ergänzung zu den beiden genannten Standards sind die Spezifikationen aus VDI 2519 – Blatt 1 (Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften). Hier wird definiert was Lasten- und Pflichtenhefte sind, was sie enthalten sollten und wie sie erstellt werden sollten.

Version 04/26/23



Methodik zur Erstellung des Produktmodells

1. (Iterative) Erstellung des Pflichtenheftes

2. Begleitend auf Basis des Pflichtenhefts:– Iterative Erstellung eines Produktmodells unter Einsatz der

gewählten Methoden (z.B. SA/SD, OOAD)– Iterative Konzeption der Benutzungsoberfläche, ggf.

Erstellung eines entsprechenden Prototyps– Erstellung einer ersten Version des Benutzerhandbuches

Version 04/26/23



Modellierungskonzepte

• Modellierungskonzepten werden verwendet zur Anforderungsspezifikation

• Sie beschreiben das System aus verschiedenen Sichten (Statik, Dynamik, Logik)

• Auftraggeber und Auftragnehmer müssen diese Modellierungskonzepte (Notationen) verstehen.

• Heute weitverbreitet: UML-Diagramme

Version 04/26/23



Basiskonzepte zur Modellierung

informal semiformal formal

text

uell

graf

isch

TextNummerierte

Anforderungen

Pseudocode

Entscheidungstabellen

RegelnData

Dictionary Petri-Netz

(textuell)

Kollaborationsdiagramm

Sequenzdiagramm

Struktogramm

Entscheidungs-bäume

Zustands-automat DFDs

ERD

Klassendiagramm

Petri-Netze

Funktionsbaum

Version 04/26/23



Systemanalyse mit UML

UML Design Pattern

Version 04/26/23



UML Design Pattern

Version 04/26/23



UML Design Pattern

Verhaltensorientierte Methodik zur Systemmodellierung mit der UML:

1. Anwendungsfälle ermitteln– Ermitteln aller Aktoren und Uses Cases aus Benutzersicht– Jeden Use Case mit Szenarios (Aktivitätendiagramme, Sequenzdiagramme) beschreiben

2. Systemobjekte und -daten identifizieren– In den Use-Case-Szenarios die Systemobjekte und -daten identifizieren– Für die identifizierten Systemobjekte und –daten Klassendiagramme erstellen

3. Systemarchitektur modellieren– Klassendiagramme in Komponentendiagrammen sinnvoll gruppieren – Schnittstellen entwerfen– Komponenten im Verteilungsdiagramm sinnvoll gruppieren

4. Systemdynamik modellieren– Anhand der Use-Case-Szenarios für die Interaktion der Aktoren und Objekte

Sequenzdiagramme ableiten– Für die Klassendiagramme anhand der Sequenzdiagramme Zustandsdiagramme erstellen

5. Implementierung– Klassen ausprogrammieren

Version 04/26/23



SA/SD

Strukturierte Analyse

Version 04/26/23



Strukturierte Analyse (SA)

• DeMarco, 1975, „Structured Analysis and System Specification“

• Varianten der Strukturierten Analyse:

– Weinberg, 1978: “Structured Analysis”– Gane & Sarson, 1979: “Structured Systems Analysis”– McMenamin & Palmer, 1984: “Modern Structured Analysis”– Yourdon, 1989: “Modern Structured Analysis”

• Hier werden die Erfahrungen der Strukturierten Analyse seit dem Erscheinen von DeMarco’s Methode gebündelt. Es wird keine neue Methode propagiert, jedoch wird die Strukturierte Analyse im gesamten Umfeld des Software-Engineering betrachtet. (http://www.yourdon.com/)

– SA/RT• Ergänzt um Modellierung für Dynamik

http://www.yourdon.com/

http://www.yourdon.com/

Version 04/26/23



SA: Konzepte

Die Strukturierte Analyse fußt im Wesentlichen auf folgenden, miteinander verknüpften Basiskonzepten:

1. Datenflussdiagramm (Data Flow Diagram (DFD))• Strukturierung des Systems• Funktionen und Daten und ihr Zusammenwirken

2. Datenlexikon (Data Dictionary (DD))• Strukturierung der Daten• Detaillierte Datenbeschreibung

3. Primitive Prozessspezifikation (MiniSpec)• Detaillierte Funktionsbeschreibung

4. Funktionsbaum• Strukturierung der Funktionen

Version 04/26/23



DFD: Definitionen• Datenflüsse sind vergleichbar mit Pipelines, durch die Daten transportiert

werden.

• Datenspeicher bilden eine Ablagemöglichkeit für Daten, bei denen sich der Erstellungszeitpunkt vom Gebrauchszeitpunkt unterscheidet.

• Prozesse haben die Aufgabe, Eingabedaten in Ausgabedaten zu verarbeiten und enthalten die hierfür notwendigen Algorithmen.

• Terminatoren (Schnittstellen) stehen für die Beziehungen des Systemes zur Außenwelt. Sie senden oder empfangen Daten, verarbeiten diese jedoch nicht.

Version 04/26/23



DFD: Datenflüsse

Version 04/26/23



DFD: Semantische Regeln

• DFD beschreibt den Datenfluss, nicht den Kontrollfluss

• Schnittstellen sind so zu wählen, dass die ursprüngliche Datenquelle und Senke angegeben werden (Also die Benutzerrolle, nicht bspw. Tastatur und Drucker)

• Datenflussname = <Substantiv> !Typ

• Funktionsname = <Verb><Objekt> !Aktion

Version 04/26/23



DFD: Fehlermöglichkeiten

• Folgendes funktioniert nicht, bzw ist nicht sinnvoll:

Version 04/26/23



Strukturierte Analyse

• Unter Anwendung von Datenflussdiagrammen (DFD) wird eine hierarchische Betrachtung des Systems modelliert.

– Kontextdiagramm (nullte Ebene): Beschreibt die Umwelt des Systemes, es gibt genau einen Prozess.

– Diagramm 0 (erste Ebene): Der Gesamtsystems-Prozess, Prozess 0, wird in Subsysteme zerlegt; Angabe der Daten, welche zwischen den Subsystemen bzw. Teilfunktionen fließen.

– Subdiagramme (n-te Ebene): Prozessverfeinerung, Zerlegung des vorherigen Subsystemes in weitere Subsysteme.

– MiniSpec: Wurde ein Prozess ausreichend verfeinert, wird er abschließend durch eine MiniSpec beschrieben.

• Prozesse, Datenspeicher und Datenflüsse sollen mit einem möglichst prägnanten Namen versehen werden. Zum Beispiel: “prüfe Passwort”, aber nicht: “verarbeite Datei” (Welche Datei? - Wie wird sie verarbeitet?).

Version 04/26/23



SA: Hierarchiekonzept

Version 04/26/23



SA: Kontextdiagramm

• Syntax– enthält nur einen Prozess, dieser erhält die Nummer 0 und stellt

das Gesamtsystem dar– verfügt über mindestens eine Schnittstelle

• Semantik– beschreibt den Anwendungsbereich des modellierten Systemes– zeigt Datenflüsse, welche Systemgrenzen überschreiten– ist die Zusammenfassung von Diagramm 0

Version 04/26/23



SA: Diagramm 0

• Das Diagramm 0 beschreibt die Verfeinerung des Kontextdiagrammes:– Der Prozess 0 aus dem Kontextdiagramm wird in

Teilprozesse zerlegt.– Speicher werden eingefügt.

Version 04/26/23



SA: Prozessverfeinerung

• Jeder Prozess kann wieder zu einem neuen Diagramm verfeinert werden, welches folgende Bedingungen erfüllen muss:

– Der Prozess wird in Teilprozesse zerlegt.– Jeder Prozess wird fortlaufend nummeriert.– Wurde ein Prozess ausreichend verfeinert, wird er abschließend

durch eine MiniSpec beschrieben.– Die Anzahl der Prozesse pro Diagramm sollte sieben nicht

überschreiten.

DFD 1, DFD 2, DFD n ... DFD 1.1, DFD 1.2 ... DFD n.m ...

Version 04/26/23



SA: Mini Specs

• Bei den MiniSpecs handelt es sich um Subsysteme, welche nicht mehr (sinnvoll) durch Datenflussdiagramme aufgeteilt werden können. Sie beschreiben implementierungsunabhängig, wie Eingangsdaten in Ausgangsdaten umgewandelt werden.

• Erscheint eine Verfeinerung für eine Funktion nicht mehr als sinnvoll, so wird zu dieser Funktion eine Mini Spec angegeben. Diese sollte mit einer der folgenden Methoden erstellt werden:

– Pseudo Code– Struktogramm / Programmablaufplan– Entscheidungstabelle / -baum

Version 04/26/23



Das Datenlexikon ist ein Verzeichnis, das Informationen über die Struktur von Daten, ihre Eigenschaften und ihre Verwendung enthält.

Engl.: Data Dictionary (DD)

Zur Beschreibung der Speicherinhalte

Symbol Bedeutung Bsp

------------------------------------------------------------------

-

= ist äquivalent zu A=B

+ Sequenz A=B+C

[ | ] Auswahl (xor) A=[B|C]

{ } Wiederholung A={B}

N{ }M Wiederholung N-M mal A=1{B}5

( ) Option A=B+(C)

* * Kommentar *muss*

Data Dictionary (DD)

http://de.wikipedia.org/wiki/Data_Dictionary

Version 04/26/23



DD: Beispiel

Artikeldaten = Artikel_id + Erstellungsdatum + Titel + Text

Benachrichtigungsschreiben = [Account angelegt | Account gelöscht | Nachricht von anderem Nutzer]

Artikelanfrage = User_id + 1{ Artikel_id }20

Kunde = Kunden_id + Name + AdresseBuch = Buch_id + Autor + Titel + PreisBuchliste = {Buch}Einkauf = {Bestellung + Gesamtbetrag}Kundenliste = {Kunde}Kundenstatus = [“reich” | “arm”]

Zimmerart = [”Einzelzimmer” | “Doppelzimmer”]

* Ein Kommentar ist immer wichtig. *

Version 04/26/23



SA: Integritätsregeln

• In der Strukturierten Analyse sind folgende Integritätsregeln zu beachten:

– Jeder Datenfluß hat einen Namen. Ausnahme: Zugriff auf einen kompletten Speicherinhalt

– Jeder Datenflußname ist im DD beschrieben

– Jeder Speicher hat einen Namen

– Jeder Speichername ist im DD beschrieben

– Alle Datenflüsse in einem untergeordneten DFD müssen im übergeordneten DFD vorkommen oder eine Komponente eines Datenflusses aus dem übergeordneten DD sein.

– Die Komponenteneigenschaft ergibt sich aus dem DD

Version 04/26/23



Strukturierte Analyse - Design Pattern

Methodik zur Systemmodellierung mit der SA:

1. Schnittstellen und Ein/Ausgaben finden2. Funktionen finden3. Speicher finden4. Datenflüsse finden5. Data Dictionary erstellen6. Konsolidieren des Modells7. Iterative Verfeinerung8. Mini-Spezifikationen erstellen

Version 04/26/23



SA: Vor-/Nachteile

• Stärken der Strukturierten Analyse:– leicht verständlich– Kombination bewährter Basiskonzepte– ermöglicht Top-Down-Erarbeitung des Systems– hierarchische Gliederung sorgt für Übersichtlichkeit– Kontextdiagramm ähnlich wie Use Case– Zusammenhang zu ER-Modellen herstellbar (über Speicher)

• Schwächen der Strukturierten Analyse:– Schnittstellen und Speicher können nicht verfeinert werden– Logik, Dynamik und Kontrollfluss können nicht modelliert werden– nur der Datenfluss wird analysiert – keine Lokalität von Daten, daher kaum für OO geeignet

Version 04/26/23



Data

Function

Function

Function

Function

Function

Function

Function

Data

Function

Data

Systemlayout SA/SD vs. OOAD

Version 04/26/23



SA/SD: Funktionsbaum DFD

• SD: Transformation der DFD-Prozesse in hierarchisch strukturierte Funktionen

Version 04/26/23



SD: Transformation Analyse Design

A B D E F G

C H K

Do job

A

B

C G

FED

K

H

Version 04/26/23



Zusammenfassung SA/SD

• Zur Modellierung von Softwaresystemen waren Strukturierte Methoden früher weit verbreitet.

• Strukturierte Analyse (SA) : Erstellung eines logischen Systemmodells, bestehend aus hierarchisch strukturierten DFDs, begleitet von Data Dictionaries, MiniSpecs, etc. Grundsätzlich stellt sich in der strukturierten Analyse folgende Frage: Was soll das geplante Softwaresystem können?

• Strukturiertes Design (SD): beinhaltet Operationsmodell und Modulmodelle. Umsetzung der DFDs aus der SA in Strukturdiagramme. Im strukturierten Design stellt sich dann folgende Frage: Wie sollen die Funktionalitäten des Softwaresystems umgesetzt werden?

• SA/SD ist ein kreativer, nicht formalisierbarer Prozess!

Version 04/26/23



Beispiel Strukturierte Analyse

Seminarverwaltung

Version 04/26/23



Beispiel SA: Kontextdiagramm

Version 04/26/23



Beispiel SA: DFD Ebene 0

Version 04/26/23



Beispiel SA: DFD Ebene 0 mit Speicher

Version 04/26/23



Beispiel SA: DFD Verfeinerung (Ebene 1)

Version 04/26/23



Beispiel SA: DD und DFD (Ausschnitt)

Version 04/26/23



Beispiel SA: MiniSpec

Version 04/26/23



ERD

Entity Relationship Diagramme

Version 04/26/23



Entity-Relationship Modellierung (ERD)

• Ziel ist die Beschreibung von – Gegenständen (Entities, Objekte)– Beziehungen (Relationships)– Eigenschaften (Attribute)

• ER-Modell wird aufgebaut, um– Anwendungsdaten zu strukturieren und zu analysieren– Oft werden daraus Datenbanktabellen aufgebaut

• Modellierung erfolgt über ER-/EER-Diagramme

• Gute Modellierungstools verfügbar– http://de.wikipedia.org/wiki/MySQL_Workbench

Entität

Beziehung

Attribut

Version 04/26/23



ERD: Grundlegende Begriffe

Entität Element derRealität

Franz Mayer

Entitätstyp Gruppe gleich-artiger Entitäten

Mitarbeiter

Attribut Entitätseigenschaft PersonalNummer,Name, Anschrift ...

Schlüsselkandidat Identifikations-attribut (minimal)

#PersNr

Wertebereich ZulässigeAttributwerte

#PersNr String(10)

Kardinalität /Komplexität

Quantifizierungvon Beziehungen

Jede Abteilung hatmehrere Mitarbeiter

Mandatorische /Optionale Bez.

Muss-/KannBeziehungen

Ein Mitarbeiterkann einen Chefhaben

Version 04/26/23



Entity-Relationship Diagramm (ERD)

A B(1,1)(0,n)

R

0 bis n Genau 1„Jedes A hat 0 bis n Beziehungen zu einem B“

! (n,m) legt das Minimum und Maximum der Anzahl Beziehungen desangegebenen Typs fest, die ein Objekt haben kann.

Möglich und üblich sind: (0,1) höchstens 1(1,1) genau eins(n,m) zwischen n und m mit n,m >= 0

(* für unbekannte Obergrenze)

Version 04/26/23



ERD: Beispiel

Kunden

Preis

#PosNr

Menge

bekommt Rechnung

enthält

Rechnungs-positionenkommt

vor in

Name

#KdNr

Adresse

Artikel

Grösse #ArtNrFarbe

interessiertan

(0,*) (1,1)

(1,*)

(1,1)

(1,1)(0,*)

(0,*)

(0,*)

Version 04/26/23



Übungen

Übungen

Version 04/26/23



Übung: PflichtenheftGegeben seien einige Ausschnitte aus einem Pflichtenheft gemäß dem vorgestellten Pflichtenheft-Muster. Untersuchen Sie diese Ausschnitte auf Fehler.

1 Visionen und Ziele/V10/ Das Produkt dient der Kunden- und Mitarbeiterverwaltung eines Unternehmens.

2 Rahmenbedingungen/R10/ kommerzieller Anwendungsbereich/R20/ Zielgruppe Mitarbeiter des Unternehmens, speziell Verwaltungskräfte

3 Kontext und Überblick/K10/ Zielgruppe sind Mitarbeiter des Unternehmens, speziell Verwaltungskräfte/K20/ Einsatz in Büroumgebung

4 Funktionale Anforderungen/F10/ Verwalten der Mitarbeiter mit Adressen und Gehältern/F20/ Verwalten der Kunden (Firmen und Privatkunden) mit Adressen, Umsatzdaten und Bestellverhalten/F30/ Schnittstellen zu gängiger Bürosoftware (Serienbriefe)/F40/ Typische Listenabfragen/F50/ Typische Reportausgaben/D10/ Zu einem Kunden sind folgende Daten zu speichern: Adresse, Kontakte (Telefon, Fax, Email), typische Zahlungsweise: Seminaranfang, Seminarende,

monatlich mehrere Einzelrechungen

5 Qualitätsanforderungen/Q10/ Das Produkt soll qualitativ hochwertig sein./Q20/ Alle gängigen Betriebssysteme müssen unterstützt werden/Q30/ Alle gängigen Rechnerplattformen müssen unterstützt werden/Q40/ Schnittstellen zu gängiger Windows-Software/L10/ Die Bearbeitungszeit aller Funktionen darf nicht über 100ms liegen./L20/ Die Funktion "Ausdrucken" soll möglichst schnell arbeiten./L30/ Die Kundendaten aus /D10/ sollen ohne sichtbaren Zeitverzug gelöscht werden können.

6 Abnahmekriterien/A10/Gültiges Abnahmeszenario: Einen Kunden erfassen, einen Mitarbeiter erfassen,

Version 04/26/23



Übung 1: Datenflussdiagramm

• Zeichnen Sie ein Datenflussdiagramm, das den Seminarverwaltungsteil einer Seminarorganisation beschreibt.

• Berücksichtigen Sie die folgenden funktionalen Anforderungen:– /F10/ Informieren (von Anfrage bis Auskunft)– /F20/ Veranstaltung durchführen– /F30/ Dozenten akquirieren

• Berücksichtigen Sie außerdem die folgenden Daten-Anforderungen:– /D10/ Seminartyp– /D20/ Seminarveranstaltung– /D30/ Dozent

Version 04/26/23




• Zeichnen Sie ein Datenflussdiagramm zur Verwaltung einer Arztpraxis.

– Neue Patienten werden in eine Patientenkartei aufgenommen, an der auch später noch Änderungen vorgenommen werden können.

– Erscheint ein Patient zur Behandlung, so werden dem behandelnden Arzt die Patientendaten und die Daten der letzten Behandlungen zur Verfügung gestellt.

– Nach der Behandlung werden das Datum, die erbrachten Leistungen und die Verordnungen gespeichert

Version 04/26/23




• Zeichnen Sie ein Datenflussdiagramm zur Beschreibung des „Generic Assessment Tool“.

• Berücksichtigen Sie die folgenden funktionalen Anforderungen:– /F10/ Assessment Modelle anlegen und verwalten– /F20/ Audit-Projekte anlegen und verwalten– /F30/ Auditoren anlegen und verwalten– /F40/ Audit-Projekt durchführen und auswerten

• Berücksichtigen Sie die folgenden Daten-Anforderungen:– /D10/ Assessment-Modell– /D20/ Audit-Projekt– /D30/ Auditor– /D40/ Auditiertes System

1 Dozenten: Markus Rentschler Andreas Stuckert Version 17.07.2015 Software Engineering I VE 08:...

Documents

Transcript of 1 Dozenten: Markus Rentschler Andreas Stuckert Version 17.07.2015 Software Engineering I VE 08:...