st.inf.tu-dresden.dest.inf.tu-dresden.de/Lehre/WS08-09/sew/slides/sew-02f1-erd-sa... ·...

Prof. Dr. Liskowsky; Vorlesung Software-Entwicklungswerkzeuge; WS 07/08

Folie 2 -1

2. Werkzeugfunktionen in den Basistechniken


Folie 2 -2

2.1 Begriffsbestimmung


Folie 2 -3

Begriffserläuterung Prinzipien: Prinzipien sind Grundsätze, die man seinem Handeln zugrunde

legt. Solche Grundsätze sind i.a. nicht nur für ein bestimmtes Teilgebiet, sondern für das gesamte Fachgebiet oder zumindest wesentliche Teile davon gültig, womöglich auch über das wissen-schaftlich-technische Fachgebiet hinaus.

Methode: Methoden sind planmäßig angewandte, begründete Hand-lungsanweisungen bzw. Regeln zur Erreichung von festgeleg-ten Zielen (i.a. im Rahmen festgelegter Prinzipien). Zu Methoden gehören eine Notation, systematische Schrittfolgen und die Über-prüfung der Ergebnisse.

Vorgehensweise: Vorgehensweisen enthalten den Weg zu etwas hin, d.h. sie ma-chen Prinzipien und Methoden anwendbar.Es wird nicht herum- probiert, sondern eine konkrete Wegleitung bewusst angewandt.

Aktivitäten: Eine Aktivität ist die konkrete Durchführung von defi nierten Aktionen innerhalb eines Software-Entwicklungsprozesses.

Basistechniken: unterstützen Arbeitsschritte im Entwicklungsprozess, die gekap-selt in unterschiedlichen Methoden angewandt werden. Sie unterstützen die Entwickler, haben eine Notation und dienen zur Darstellung der Ergebnisse.

Quellen: [3, S. 36], [31, S. 81], [24, S. 41], Arbeitskreis GI-Fachgruppe 5.11 „Begriffe und Konzepte der Vorgehensmodellierung“; http://www.tfh-berlin.de/~giak/arbeitskreise/softwaretechnik/themenbereiche/grundbgr.html


Folie 2 -4

Basistechniken und Methodenim Zusammenhang

Methoden

Vorgehensmodell

A k t i v i t ä t e n

BasistechnikenQuelle: Raasch [31]

... benutzen isoliert ...

... defi nieren Kette vonAktivitäten im ...

... beschreibt Reihenfolgen bzw. Regeln zur Abarbeitung von ...


Folie 2 -5

Basistechniken der SE

OO-Diagramme

Datenfl uß-diagramm

Funktions-baum

Programm-ablauf-

plan (PAP)

Strukto-gramme

Pseudo-code

Entsch.-Netzwerke

Entschei-dungs-

Tabellen

Petri-netze

Zustands-graphen

(automat)

JacksonDia-

gramme

Entity-Relation-

ship-Diagramme

objektorientierteSicht (oo Paradigma)

datenorientierteSicht

funktionaleSicht

steuerfl uß-orientierte

Sicht

zustandsorientierte bzw. regelbasierte Sicht

DataDictionary

Quelle: objektorientiert geordnet angelehnt an [1, S.41]


Folie 2 -6

2.2 Entity-Relationship-Diagramme


Folie 2 -7

Paradigma der Datenmodellierung

Datenmodellierung– betrachtet ein System als Datenstruktur– beschreibt die Zerlegung von Datenstrukturen in Komponenten– orientiert sich an der Technik von Datenbanken

Darstellungsmittel:– Entity-Relationship-Diagramm (ER-Diagramm)– Erweiterungen des ER-Diagramms

Quelle: Hußmann, H.: Vorlesungsskript "Softwaretechnologie II"; WS97/98, Fak. Informatik der TU Dresden


Folie 2 -8

Entity-Relationship-Modellierung

Beziehungstyperelationship type

Beziehungsinstanzrelationship instance

EntitytypeObjekttyp

entity type

EntityObjektinstanzentity instance

Attributpropertyattribute

Attributwertproperty valueattribute value

Menge, Typ Element, Instanz

Konkretisierung, Instanzierung

Abstraktion, Mengenbildung

"setzt in Beziehung"

"wird beschrieben durch"

Quelle: Raasch, J.: Systementwicklung mit Strukturierten Methoden; Hanser Verlag (3.Aufl .) München 1993


Folie 2 -9

Beispiel des Entitytyps "Patient"im Relationenmodell

Attribute

Tupel

Kardinalität

@Geburtstag Name Geschlecht K_Schlüssel

40.12.10 Meier m 367

53.11.30 Lehmann w 407

62.02.29 Schmidt m 123

Grad

Relationen-kopf

Relationen-körper

Relation

Primärschlüssel

Menge derzulässigen

Kalendertage

Menge aller

Namen

Menge der

Geschl.-Bez.

Menge der

Krankheits-schlüssel

Wertebereiche


Folie 2 -10

graph. Notation Bedeutung

ERD-Modellnotation nach CHEN

nameEntitytyp: Abstraktion einer Menge gleichartiger

Datenobjekte beschrieben durch (mehrere) Attribute. Jedem Datenobjekt sind eindeutig Attributwerte zugeordnet.

Beziehungstyp: Menge von Beziehungen zwischen Entitytypen, beschrieben durch verknüpfte Aufzählung identifi zierender Schlüssel der Entitytypen.

name

NameAttribut: Beschreibende Eigenschaften von

Entitytypen.Defi niert durch Menge zulässiger Attributwerte.

(selten dargestellt)

1, n0 < n

Kardinalität: Ganze Zahlen an den Verbindungs-linien, die angeben, wieviele Instanzen des anderen Entitytyps mit einer Instanz dieses Entitytyps in Verbindung stehen.


Folie 2 -11

ERD-Beispiele in CHEN-Notation

Eigenschaften der Beziehungstypen:

behandelt

bestellt

enthält Krankheit

Termin

Patient

K_Katalog

Patient

Arzt

Behandlung

Kardinalität

Art(kann-Beziehung)

Merkmale der Verbindung(assoziatives Objekt)

1 n

0<1 0<n

n m

1

"kann""kann"

besteht_aus ER-DiagrammER-Modell1 1<mHierarchisierung

(aus dem Aufgabenkontext "Arztpraxis")


Folie 2 -12

Weitere ERD-Notationsformen

DSA-Notation UML Version 2.0(Class Diagram)Modellelemente

Entitytyp

Beziehungstyp

KardinalitätMultiplizität

Attribut

name

(ohne Symbol)

1:1

1:n

1<n

n:m

class name

class nameattribute

association name

role 2role 1assoziiertes Objekt/Class

0..1

1

1..**

0,1


Folie 2 -13

Multiplizitäten der UML

Quelle: Jeckle, M., Rupp, Ch. u.a. : UML 2 glasklar; Hanser Verlag 2004

Bezeichnet Anzahl von Objekten, die an einer Assoziation (Beziehung, Verbin-dung) zwischen zwei Klassen teilnehmen. Für jede Rolle kann die Vielfachheit, d.h. die Anzahl von Objekten, für die diese Verknüpfung geschaltet werden kann, über die Angabe einer Liste von Bereichen festgelegt werden.

Beispiele:

Straßenkreuzung Straße

1 2...5

Monopoly-Spiel Spieler1 2...6

Kategorien: 1:1 Beziehung 1: n Verknüpfung eines Objekts mit Menge von n Objektenn: m auf beiden Seiten treten Mengen von Objekten auf

optionale Beziehungen werden durch 0...n modelliert,Symbol * bezeichnet eine beliebige Anzahl.

münden

beteiligt


Folie 2 -14

Alternative Kardinalitäten

Produkt TeilStück-liste

Produkt Teil

DSA-Notation:

Schageter/Stucky-Notation (ARIS): Kardinalitätsangaben am Symbol des Beziehungstypes vertauscht

Produkt TeilStück-liste

n 1

(min,max)-Notation: Die Eckwerte min und max bezeichnen Unter- und Obergrenze für eine Beziehung und legen somit den Komplexitätsgrad fest.

(0,*) (1,1)

Vielzahl der Kardinalitätsformen kann verwirren. Entscheidend ist Funktionalität des Werkzeugs.


Folie 2 -15

Beispiel für erweiterte ERD

Bettlägerig Beweglich

liegt_in

erhält Mahlzeit

@Pat-Nr

Name

Medizin

Krankenhaus

Supertyp

Subtypen

n

1

1<nm

Patient_derOrthopädie

Patient

Attribute

schwacherObjekttyp

(nach CHEN aus gleichem ärztlichen Aufgabenkontext)


Folie 2 -16

2.3 Data Dictionary


Folie 2 -17

Paradigma von Datenkatalogen

Datenmodellierung– defi niert Datenstrukturen in ihrer hierarchischen

Zusammensetzung– beschreibt detalliert die Eigenschaften/Attribute von beliebigen

Datenobjekten– orientiert sich an der Verwendung von Datenobjekten bzw.

ihren Komponenten (Attributwerten)

Darstellungsmittel:– vereinfachte Backus-Naur-Form– beschrieben in Tabellenform im Repository– rein verbal als Glossar (Begriffslexikon)


Folie 2 -18

Data Dictionary Syntax

Symbol Bedeutung Beispiel

name Bezeichner (Entitytyp, Bez.typ,Attr.) A = B + C"text" prim. Wert (nicht mehr zerlegbar) B = "W1" + R= besteht aus+ Sequenz (impl. keine Ordnung)

@ Schlüsselkennzeichen P = @Pnr + N + Adr [...|...] Selektion (entweder ... oder) P = [ P1 | P2 ]n { ... } m Iteration von n bis m B = 1 { C } 10 ( ... ) Option (kann vorhanden sein) A = B + (C)

X = X1 + X2 + X3

* ... * Kommentar X = B + C*Kommentar*< a > b Modifi er (komment. Ergänzung) < alt > A

< neu > ASYN Synonym für Name K SYN P

(in vereinfachter Backus-Naur-Form)


Folie 2 -19

Werkzeugunterstützung

BereichsprüfungenJeder Attributwert jedes Attributes jeder Relation darf nur dem Wertebereich entnommen werden, der dem Attribut zugeordnet ist (Der Wertebereich ist in der Regel im Datenkatalog zu beschreiben.).

EindeutigkeitEin (möglicherweise zusammengesetztes) Attribut K einer Relation R heißt Schlüsselkandidat, wenn zu keinem Zeitpunkt verschiedene Tupel von R denselben Wert für K haben.

MinimalitätWenn K zusammengesetzt ist, dann kann keine Komponente von K entfernt werden, ohne die Eindeutigkeitsbedingung zu stören, d. h. jedes Tupel einer Relation muß über einen Primärschlüssel eindeutig identifi zierbar sein. Falls es weitere Schlüsselkandidaten gibt, werden sie als Alternativschlüssel be-zeichnet.

Fremdschlüssel-VerbindungEin Fremdschlüssel ist ein Attribut einer Relation R2, dessen Werte benutzt werden, um eine Verbindung zu einer Relation R1 über deren Primärschlüs- sel aufzubauen.

Referentielle IntegritätDas Datenmodell darf keine ungebundenen Fremdschlüsselwerte enthalten.

(Prüfung der allgemeinen Integritätsregeln für relationale Datenmodelle, ERD und DD)


Folie 2 -20

Prüfung auf strukturierte DarstellungAuftrennen von Zyklen zunächst an der "am wenigsten relevanten Stelle":

Auftrag

Kunde

Angebot

Kunde

Auftrag

Angebot

10<n

1

0<n

erhält

wünscht

löst_aus

10<n

0<n

1

erhält

0<n1

löst_aus

wünscht

1

0<n

Quelle: Raasch, J.: Systementwicklung mit strukturierten Methoden; Hanser Verlag (2. Aufl age) München 1992, S.312


Folie 2 -21

Editieren von CASE-Elementen

�) Repository-EbeneEinrichten,Installation, Konfi guration eines Repository für alle Ablagen (mehrere Projekte)

�) Globale EbeneModell- oder Projektebene zeigt alle möglichen Bestandteile eines Modell- oder Projekttyps (z.B. UML-, ER-Modell)

�) DiagrammebeneAufl isten aller möglichen Diagramm-typen, Editieren und Erstellen neuer Diagramme

�) ObjektebeneAngebot der zum gewählten Diagramm-typ gehörenden (graphischen) Objekte,Erstellen und Editieren dieser Objekte

�) Beschriftungoft kontextsensitiv menügesteuert Texteingabe funktionsgesteuert Geometrie meist direkt manipulierbar

�) Verbindung mit anderen Objektenz. B. Hinzufügen neues Objekt, Verbindung kontextsensitiv zwischen 2 Objekten durch Linienzug von einem direkt in zu verbindendes Objekt

�) Verbindung mit anderen Diagrammenüber Data Dictionary, z.B. Entitynamen aus Diagramm direkt übernommen, Aufruf DD-Editor, Eintrag unterschied-licher Objekttypen nach DD-Syntax (wie Entity, Relation, später Datenfl üsse, Speicher(=Entity), Kontollfl üsse)

(am Beispiel des CASE INNOVATOR)


Folie 2 -22

Praktische Vorgehensweise Festlegen der Entitytypen

aus einer pragmatischen Verbindung der Anforderungen des Lastenheftes zu den Objekten der Realität.

Ableitung der Beziehungstypenunter Beachtung der funktionalen Anforderungen und der im Sinne der Auf- gabenstellung notwendigen Verbindungen zwischen den Entitytypen.

Zuordnung der Attributezu den Entitytypen unter dem Gesichtspunkt der natürlichsten Zugehörigkeit, d. h. sie sind "angeborene" Eigenschaften unabhängig von ihrer Nutzung.

Erstellung des ERDzum Dokumentieren und Eintrag ins DD zur Konsistenzprüfung, auch wenn die entstehenden Modelle noch komplex, inkonsistent und unvollständig sind (Detaillierung später Kardinalitäten)

Fremdschlüssel defi nierenfür die Herstellung notwendiger Verbindungen zwischen Entitytypen und Eintrag ins DD.

Fremdschlüssel-Regeln spezifi zierennach Rücksprache mit dem Anwender, um die Verhaltensmuster zur Auf- rechterhaltung der Datenintegrität festzulegen.

Ergebnis: detailliertes und normalisiertes Entity-Relationship-Modell

(entspricht Methodik unter Nutzung von Werkzeugen)


Folie 2 -23

Beispiel “Arztpraxis”Aufgabenstellung als Lastenheft:

“Es sind in einer Arztpraxis(1 Arzt) die organisatorischen Abläufe für das Bestellwesen der Patienten, den Aufruf aus dem Wartezimmer, die Arzt-behandlung und die Abrechnung unter Einsatz von PCs weitgehend zu rationalisieren. Spätere Erweiterungen sollen leicht möglich sein.

Schritt :Patient

ArztTerminWartezimmerK_Katalog(Behandlung)

Schritt ‚:Patient wird behandelt von ArztPatient bestellt TerminPatient ordnet sich ein in WartelisteArzt benutzt K_Katalog


Folie 2 -24

ERD “Arztpraxis”(1)

Patient Arzt

Behandlung

Termin Wartezimmer K-Katalog

wirdbehandelt

bestellt ein-ordnen benutzt

1

n 1

0<1

1<N

m

1 1

N

(Schritt „ )


Folie 2 -25

ERD “Arztpraxis”(2)

PatientArztBehandlung

Termin K-Katalog

bestellt benutzt

1

m 1

0<1

1<N

n1

1

N

erfährtführtdurch

wartetauf

1


Folie 2 -26

2.4 Datenflussdiagramme (DFD)


Folie 2 -27

Paradigma der Funktionsmodellierung Funktionsmodellierung

– betrachtet ein System unter dem Gesichtpunkt seiner Funktion– beschreibt die hierarchische Zerlegung von Funktionen in

Teilfunktionen– orientiert sich an den Programmiertechniken der "schrittweisen

Verfeinerung" und der "strukturierten Programmierung"– wird meist kombiniert mit einer Datenfl uss- bzw. Datenstruktur-

analyse

Darstellungsmittel:– Funktionsbaum– Datenfl ussdiagramm– Pseudocode– Struktogramm

Quelle: nach Hußmann, H.: Vorlesungsskript "Softwaretechnologie II"; WS97/98, Fak. Informatik der TU Dresden

} (steuerfl ussorientierte Sicht)


Folie 2 -28

Nutzung von Datenfl ussdiagrammenDurch Verwendung einfacher grafi scher Mittel (abgeleitet aus den Grund-

bestandteilen des J. v. Neumann-Rechners) ergeben sich anschauliche "funk-tionale" Modelle des Anwendungsbereiches vergleichbar den Bauzeichnungen eines Architekten.

Anwendbarkeit der DFD für folgende Zerlegungsstrategien:• Funktionsorientierte Zerlegung ausgehend vom System als Ganzes und

schrittweiser top-down-Verfeinerung der Prozesse bis zur elementaren Ebene, die durch Prozeß-oder Minispezifi kationen (MSpec) beschrieben wird. Durch Verfeinerung entstehende Datenelemente werden wenig strukturiert, weshalb ein IM-Datenmodell vorher entworfen werden kann.

Quelle: De Marco, T.: Structured Analysis and System Specifi cation; Yourdon Inc. 1978/1979 • Essentielle Zerlegung geht von einer ereignisorientierten Systemzerlegung

aus, bei der essentielle Aktivitäten und Speicher (Datenelemente fast nor- malisiert) aufgesucht werden, die allein für die Systemantwort nötig sind.

Quelle: McMenamin, S., Palmer, J.: Strukturierte Systemanalyse; Hanser Verlag 1988 [25]

• Objektorientierte Zerlegung als Weiterentwicklung der essentiellen Modellierung, indem funktionale Abläufe, z. B. zur Transformation von Attributwerten oder der Berechnung neuer Objekte aus Eingabeobjekten oder -werten als DFD dargestellt werden.

Quelle: Schader,M.: Objektorientierte Systemanalyse - Eine Einführung; Springer Verlag 1994


Folie 2 -29

DFD- ModellierungGrafi sche Mittel: Datenfl ussdiagramme - DFD

Kontextdiagramm (mit Terminatoren)Parent-DiagrammeChild-Diagramme

hierarchisch gegliedertmit übereinstimmenderProzess-/Diagramm- numerierung

Symbole:

namenr.Prozess(Aktion) Datenfl uss ( )

(auch bidirektional)

(name)

Terminator name Speicher name

Textliche Mittel:

Mini-Spezifi kationen: Dienen der näheren Beschreibung der in Elementarprozessen durchzuführenden (Daten-)Transformationen.

Data Dictionary: Im Datenkatalog ist jeder Speicher und jeder Daten- fl uss in seiner Zusammensetzung zu beschreiben. Es ist identisch mit dem der IM-Modellierung.


Folie 2 -30

DFD-Beispiel "behandeln_Patient"

empfangen_Patient

1.31

aufrufen_Patient

1.32

unter-suchen_Patient

1.33

schreiben_Unterlagen

1.34

TerminePatient

Beschwerden

Rezept

Krankenschein

Warteliste

Bestelldatum

Pat

ient

en-

auf

ruf

Symptone

DiagnoseTherapie

Aufnahme


Folie 2 -31

DFD-Beispiel "behandeln_Patient"

empfangen_Patient

1.31

aufrufen_Patient

1.32

unter-suchen_Patient

1.33

schreiben_Unterlagen

1.34

&Termine&Patient

>Beschwerden

<Rezept

<Krankenschein

&Warteliste

>Bestelldatum

<Pat

ient

en-

auf

ruf

>Symptone

<Diagnose<Therapie

<Aufnahme

Legende (aus Minispez.):> Input, eingehender Datenfl .< Output, ausgeh. Datenfl uss& Entitätstyp, Speicher@ Schlüsselkandidat *Kommentar*


Folie 2 -32

Regeln der DFD-Erstellung

Semantische Regeln zur Namensgebung:• Prozessnamen: Verb_Substantiv zur aussagekräftigen Beschreibung

einer Aktion (z.B. berechne_Schnittpunkt)• Datenfl ussnamen: [<Modifi er>]Substantiv beschreibt momentanen Zu-

stand des Datenfl usses (z.B. <neue>Anschrift ) • Speichernamen: Substantiv, das den Inhalt des Speichers (identisch

Entity im DD) beschreibt (z.B. Adressen)

Syntaktische Regeln zur graphischen DFD-Darstellung:• Jeder Datenfl uss muß mit mindestens einem Prozess verbunden sein.• Datenfl üsse zwischen Terminatoren und direkt zwischen Speichern sind

nicht erlaubt.• Datenspeicher, die nur einseitig beschrieben (ohne zu lesen) und nur

einseitig gelesen (ohne zu beschreiben) werden, sind nicht erlaubt.• Prozesse, die Daten ausgeben, ohne sie erhalten zu haben oder umge-

kehrt, die Daten erhalten, ohne sie auszugeben oder zu verarbeiten, sind nicht erlaubt.

• Im Kontext darf es keine Speicher geben, in Verfeinerungen keine Ter- minatoren

Jeder Prozess, Speicher und Datenfl uss muss einen Namen haben. Nur in dem Fall, wo der Datenfl uss alle Attribute des Speichers beinhaltet, kann der Daten- fl ussname entfallen.

Weiterführende Literatur: [2, S.437]

(möglichst werkzeugunterstützt prüfen)


Folie 2 -33

Konzept der essentiellen ZerlegungProblem: Finden der Essenz eines Systems, d.h. derjenigen Systembe- standteile, die unabhängig von der Implementierung sind.

Konzept der perfekten Technologie [25]Prozesse ohne Bearbeitungszeit

Speicher stets aktuell mit unendl.Kapazität

Lösung: Analyse des Systems unter den perfekten Voraussetzungen

Bestandteile der Essenz:

Essentielle Aktivitäten Essentielle Speicher

Grundlegende Aktivitäten Verwaltungsaktivitäten

Essenz

Administration

Infrastruktur

Spontane Hülle

Eigentlicher Anwendungs-kern von Implementierungunabhängig

Subjektiver Faktorjedes Prozesses

Aktivitäten zur Prüfung und Fehlerbehandlung

Implementationsabh.Ein- und Ausgabe,Kommunikation mitAußenwelt

Physikalischer Ring


Folie 2 -34

Beispiel “Kurantrag” zur Essenz

annehmen_Wunsch

prüfen_Anfrage Kurunter-

suchung

genehmi-gen_Kur

versenden_Formular

unter-zeichnen_Formular

schreiben_Formular

Essenz

Krankenkasse Patient

Administration

Infrastuktur <fertiges>Kurformular

<unterzeichnetes>Formular

<geschriebenes> Formular

<genehm> Kur

Kurvorschlag<geprüf.>Kurwunsch

<ungeprüfte> Anfrage

<roh>Kurwunsch

Patienten-daten Verwaltungsaktivität

aktualisie-ren_Pat.

1.1


Folie 2 -35

Werkzeugunterstützte Prüfung

Vertikales Balancing zwischen Knoten und Verfeinerungen Alle Komponenten der im Vater referenzierten Flüsse sind zu benutzen.

Horizontales Balancing zwischen DFDs und MSpecs: Jede MSpec muß genau einem (Primitiv-)Knoten zuordenbar sein und umgekehrt

jedem Primitivknoten eine MSpec. Alle Schnittstellen zu Knoten müssen in der MSpec referenziert sein und umgekehrt. Alle Ausgaben jedes Prozesses müssen aus seinen Eingaben erzeugbar sein (korrekte

Nutzung von Speichern!). Balance von DFDs zum Data Dictionary:

Zusammensetzung jedes Datenfl usses und Speichers vollständig im DD beschrieben. Jedes Datenelement im DD muß in anderem DDE oder DFD vorkommen

(Vollständigkeit). Balance von ERD zu DFDs und MSpecs:

Jeder Speicher eines DFDs muß einem Entitytyp des ERD entsprechen. DDE müssen sowohl Speicher der DFDs wie jeweils zugehörige Entitytypen und

Beziehungstypen des ERD beschreiben. Beziehungstypen des ERD sind in den MSpecs fortzuschreiben (in essentiellen

Modellen werden Beziehungstypen i. a. nicht als Speicher dargestellt).

auf Einhaltung von Balance-Regeln (Auszug)


Folie 2 -36

2.5 Minispezifikationen (Pseudocode)


Folie 2 -37

PseudocodeBeschreibung des Algorithmus (Prozessspezifi kation, Operation, Formalisierung der

Funktion) muß in endgültiger Form so erfolgen, dass die Maschine ihn versteht. Auf dem Weg dorthin gibt es unterschiedliche Beschreibungsformen:

Formalisierungsstufen

Ideen Prosa(nat.Sprache)

strukt.Sprache

Pseudo-code

Code

math.Gleichgn.

Tabellen(EVA,ET)

Kommentare

Pseudocode::= formale Elemente (terminale Symbole) für Strukturkomponenten, z. B. seq, endseq, if, then, else, endif, while, endwhile, call, action, stop,... "freisprachl. Text" als Kommentar bzw. sonstige Beschreibungen.

Werkzeugunterstützte Verarbeitung: • Syntaxkontrolle • variable Codeerzeugung (Codegerüst + Kommentare) • Dokumentationserstellung (Einrückdia- gramme, PAP, Struktogramm)


Folie 2 -38

Beispiele für Mini-Spezifi kationen(1)

Beispiel für strukturierte Sprache: empfangen_Patient 1.3.1Fuer &Patient

mit >Bestelldatum = Datum in &Termine und >Beschwerdenwenn Name*des Patienten* in &Patient sonst "aktualisieren_Patient 1.1"

wenn keine >Beschwerden und >Bestelldatum ungueltigdann „vergeben_Termin 1.2“sonst Uebernahme Patientendaten aus &Patient

alle Unterlagen fuer Arzt aufbereiten<Aufnahme Name*des Patienten* in &Wartelistewenn @Bestdat+Zeit = Kalenderdatum + Uhrzeit

dann Terminpatient Platz m+1* vorhergehender Terminpatient m*sonst Platz n+1*n Anzahl aller Patienten im Wartezimmer*

Die in MSpecs vorkommenden Namen sind :• Titel übereinstimmend mit Prozessnamen• Im DD erklärte Datenfl uss- und Attributnamen (Referenzierung)• (reservierte) Pseudocode-Schlüsselwörter• lokale Namen und freisprachlicher Text zur Verbesserung der Lesbarkeit(Folie 2-34)• Makros zur Zusammenfassung mehrerer Worte.


Folie 2 -39

Beispiel für Pseudocode: action empfangen_Patient

while (Patienten oder Praxisoeffnung)seq Eingabe >Bestelldatum, >Beschwerdenif (@Bestdat+Uhrzeit enth. &Termine)then Bestellpatientelse if (@Gebdatum+Name enth. &Patient)

then ziehen Patientenakte else call aktualisieren_Patientendaten

endif if (>Beschwerden <> 0*vorhanden*)

then Unbestellter_Patientelse call vergeben_Termin

endif endif Aufbereiten aller Unterlagen fuer Arzt endseq

if (Bestellpatient)then <Aufnahme Platz m+1 in &Wartelisteelse <Aufnahme Platz n+1 in &Warteliste

endif endwhilestop

Beispiele für Mini-Spezifi kationen(2)


Folie 2 -40

Vorgehen zur essentiellen Zerlegung

Projekt-Ziele

Brainstorming

- Ereignisse erkennen - geplante und sponta-ne Reaktion trennen

Ereignisstabelle

Ereignis Auslöser Antwort

Kontext

zusammengefaßteEbenen

(Vergröberung)

essentielle Ebene

Aktivitäten und Speicher

Detaillierung der essentiellen Aktivitäten

DFDPseudocode

Entity-Relationship-

ModellData

Dictionary

nur essentielle Aktivitätenkommunizieren nur über Speicher

ein Prozess repräsentiert(Gesamt-)System, Spei-cher vollständig gekapselt

zusammengefasste essent.Aktivitäten

Speicher zunehmend ge-kapselt nur über Prozessenutzbar

Fragmente von ess. Aktivi-täten kommunizieren überDatenfl üsse

Vergröberung bedeutet kurz "Bildung abstrakter Datentypen" (Zusammenführen von Datenspeichern und Prozessen)Verfeinerung bedeutet kurz "Faktorisieren" (bzw. zerlegen hier funktional)

Quelle: Raasch, J.: Systementwicklung mit Strukturierten Methoden; Hanser Verlag(2.Aufl .) München 1992)


Folie 2 -41

Vorgehen zur DFD- und Pseudocode-Erzeugung

1 Ziele des neuen Systems festlegen, d. h. klare Aufgabenabgrenzung undBestimmung aller Projektteilziele.

2 Grundlegende Aktivitäten fi nden über Aufstellen der Ereignisse in einer Ereignistabelle, die über Eingabe-Datenfl üsse möglicherweise Ausgabe-Datenfl üsse und damit einen Prozess initiieren.Aus der vollständigen Ereignistabelle ist ein erster Teil der essentiellen Ebenezu erstellen. Nach Erkennen der wahren Terminatoren kann im Falle einerstrukturierten Analyse das Kontextdiagramm entworfen werden.

3 Speicher des Systems fi nden über Analyse der Ein- und Ausgabewerte vonDatenfl üssen, ihrer Spezifi kation im DD und der semantischen Modellierung

4 Verwaltungsaktivitäten fi nden, die zur Erstellung und Pfl ege essentieller Spei-cher (Laden, Änderung, Löschen,...) notwendig sind. Nur solche Ereignisse, die nicht schon grundlegende Aktivitäten auslösen, defi nieren Verwaltungsaktivitäten.

5 Vorläufi ges essentielles Modell erstellen aus allen Ereignissen, die eine geplan-te Systemreaktion durchführen und damit die essentiellen Aktivitäten implizieren.Nach Integration eventueller Teilmodelle kann die Vergröberung zum Kontexterfolgen.

6 Wiederholung und Verfeinerung bis zu den MSpecs, wobei die Vorgehens-weise nicht starr "top-down", sondern "inside-out-yoyo" ist.

von Datenstrukturen

(Methodik der strukturierten Analyse)


Folie 2 -42

Zusammengefasste Methodenschritte

Ziele Anwendergespräche

(Blitzen)Kontextabgrenzung

neue Essenz konzipierenneue Inkarnation konstruieren

Modellqualität optimiereness. Aktivitätenmodelle integrieren (5)

Phys. Ist (teilweise) erhebenexpandierenreduziereness. Fragmente klassifi zierenessent. Aktivitäten ableiten (2)

EreignistabelleEssenz, Kontext (2)Datenkatalog 3...6MSpecs (Für Elementar_ Aktivit.)

Ohne Analyse des Altsystems Mit Analyse des Altsystems

Einfl uss des

(Structured) Design

A B

st.inf.tu-dresden.dest.inf.tu-dresden.de/Lehre/WS08-09/sew/slides/sew-02f1-erd-sa... ·...

Documents

Transcript of st.inf.tu-dresden.dest.inf.tu-dresden.de/Lehre/WS08-09/sew/slides/sew-02f1-erd-sa... ·...