vorlesung softwaretechnik - definitionsphase, funktionale...

Institut für InformatikBetriebliche Informationssysteme

Vorlesung Softwaretechnikg- Definitionsphase, funktionale und

objektorientierte Sicht -

Prof. Dr.-Ing. habil. Klaus-Peter Fähnrich

Wintersemester 2009/2010

Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 1

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeSoftwaretechnik

Einführung und ÜberblickLE 1

V Unternehmensmodellierung

1 GrundlagenLE 24

2 ObjektorientierteUnternehmensmodellierung LE 25

2 LELE 24 g LE 25

I SW-Entwicklung

1 Die Planungsphase

III SW-Qualitäts-Management

1 Grundlagen

II SW-Management

1 Grundlagen

2 Die DefinitionsphaseLE 4 - 22

1 Die PlanungsphaseLE 2 - 3

2 Qualitäts-sicherung LE 10

1 GrundlagenLE 9

2 PlanungLE 2

1 GrundlagenLE 1

4 Die Implementationsphase

LE 33

3 Die Entwurfsphase

LE 23 - 32

4 Prozessqualität

LE 12 - 13

3 Manuelle Prüf-methoden LE 11

4 Personal

LE 5

3 Organisation

LE 3 - 4Legende:

=Übergabe von

6 Die Wartungs- & PflegephaseLE 34

5 Die Abnahme- undEinführungsphase LE 34

6 Produktqualität –Syst

5 Produktqualität –Komp.LE 14 - 17

6 Kontrolle

5 Leitung

LE 6 - 7

Teilprodukten

=Informationsaustausch

=Einfluss

33 LELE 34

11 LE

Syst. LE 18 - 198 LE

LE 8

IV Querschnitte und Ausblicke4 Sanierung1 Prinzipien und 3 Wiederver-2 CASE

=Unterstützung

LE =Lehreinheit

Die in dieser Vorlesung


4 LE

4 SanierungLE 23

1 Prinzipien undMethoden LE 20

3 Wiederverwendung LE 22

2 CASELE 21

Die in dieser VorlesungBehandelten Themen

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeLernziele

1. Konzepte beschreiben für Funktionsbaum, Geschäftsprozess und Datenflussdiagramm

2 Hi hi h Gli d F kti d K t kti i 2. Hierarchische Gliederung von Funktionen und Konstruktion eines Funktionsbaumes für eine gegebene Problemstellung

3. Checklisten4. Strukturierung von Geschäftsprozessen5. Ermittlung von Schnittstellen, Funktionen, Speicher und

Informationsfluss für gegebene Problemstellungg g g6. Regeln für die Syntax und Semantik von Datenflussdiagrammen

(DFD)


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeÜberblick

Konzepte und Sichten

häufig v

selten v e

Strukto-gramm(1973)

erwendet

erwendet

Kollabora-tionsdia-gramm

Aktivitäts-diagramm(1997)

ET(Entschei-dungsta-belle)(1957)

PAP(Programm-ablaufplan)(1966)

Sequenz-diagramm(1987)

DataDictionary(1979)

Daten-Flussdia-Gramm(1966)

Funktions-baum

Geschäfts-Prozess(1987)

Klassen-diagramm(1980/90)

ER(Entity Re-Lationship)(1976)

Zustands-Automat(1954)

Regeln

(1957)

Pseudo-code

Petri-Netz(1962)

FunktionaleHierachie

Arbeits-ablauf

Kontroll-strukturen

wenn-dann Strukturen

Endlicher Automat

Neben-läufige Strukturen

Inter-aktions-Strukturen

Informa-tions-fluss

Daten-strkturen

Entitäts-typen & Beziehungen

Klassen-strukturen

F kti l Si ht D t i ti t Si htObjekt- Algorith- Szenario-

Z t d i ti t Si htRegel-

LE5 LE8 LE6-7 LE9 LE9-10 LE11-12 LE7

Funktionale Sicht Datenorientierte SichtObje torientierte Sicht

go tmische Sicht

S e a obasierte Sicht

Zustandsorientierte Sichtege

basierte Sicht


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeFunktionsbaum

• Funktion beschreibt Tätigkeit oder klar umrissene Aufgabe innerhalb eines größeren Zusammenhangs. Transformiert Eingabedaten in Ausgabedaten bzw. ändert die Struktur der Information.

• Funktionshierarchie entsteht wenn eine allgemeine Funktion in spezielle Teilfunktionen gegliedert wird.Es entsteht ein Funktionsbaum.

Basis der HierarchieBasis der Hierarchie• Besteht-aus (meist in der Definitionsphase):

A besteht aus B und C• Ruft-auf (meist in der Entwurfsphase):A ruft B und C auf.

Funktions-name

Grafische Darstellung

A ruft B und C auf.

Erstellungsregeln:• Unter einer gemeinsamen Vaterfunktion sollen nur

Funktionen (Kindfunktionen) angeordnet sein die Funktionen (Kindfunktionen) angeordnet sein, die fachlich eng zusammengehörende Tätigkeiten beschreiben

• Was eng zusammengehört kann nur mit Fachwissen hi d d

A

Hierarchie

entschieden werden• Auf einer Hierarchieebene sollen Funktionen

angeordnet sein, die sich auf gleichem Abstraktions-niveau befinden

B C


• Funktionsname ist i. d. R. Verb + Objekt oder Substantiv + Verb

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeFunktionsbaum-Beispiel: Seminarverwaltung

v e r w a l t eSe m i n a r eu n d K u n d e n

v e r w a lt eK u n d e n

v e r w a l t eFi r m a

b e a n t w o r t eA n f r a g e n / F 9 0 /

v e r w a l t e K u n d e n -d a t e n/ F1 0 / , / D 1 0 /

b u c h e V e r a n s t a l -t u n g/ F2 0 /

v e r w a l t e Fi r m e n -d a t e n/ F 2 3 / , / D 2 0 /

e r s t e l l eF i r m e n b u c h u n g/ F2 3 /

e r f a s seN e u k u n d e n/ F1 0 /

e r f a ss eA n m e l d u n g/ F2 0 /

e r f a s seA b m e l d u n g/ F2 1 /

b e a r b e i t eSt o r n i e r u n g/ F2 2 /

a k t u a li s i e r eK u n d e n d a t e n

e r s t e l le A n m e ld e -b e s t ä t ig u n g

e r s t e l l e A b m e l d e -b e s t ä t i g u n g

e r s t e l le St o r n i e -r u n g s m i t t e i lu n g/ F2 2 // F1 0 / / F1 0 / / F2 1 / / F2 2 /

lö sc h eK u n d e n

e r s t e l le R e c h n u n g/ F1 0 /

e r s t e l l eG u t sc h r i f t/ F2 1 /

e r s t e l leG u t sc h r i f t/ F2 2 /

e r s t e l l e e r s t e l le e r s t e l le G u t s c h r i f t s -A d r e s s a u f k l e b e r/ F1 0 /

R e c h n u n g s k o p i e/ F1 0 /

k o p i e/ F2 2 /

t r a g e Z a h l u n g s -v e r z ü g e e in/ F2 0 / , / D 2 1 /

e r s t e l leM i t t e i l u n g/ F1 0 /


L e g e n d e : / … / B e z ü g e z u m Pf l i c h t e n h e f t

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeGeschäftsprozesse

Geschäftsprozesse im Großen• Ablauforganisation eines Unternehmensg• Unternehmensprozess (business process)

o Besteht aus einer Anzahl von unternehmensinternen Aktivitäten, die durchgeführt werden, um die Wünsche eines Kunden zu befriedigen

G häft i Kl iGeschäftsprozesse im Kleinen• Funktionalität eines Produkts• Definiert einen Arbeitsablauf, der mit Hilfe von Software durchgeführt wird, aber

manuelle und organisatorische Anteile besitzen kanng• use case

o Teil eines Geschäftsprozesses, der die Benutzerkommunikation mit dem Software-System beschreibt

G häft ( ) (A b it bl f)• Geschäftsprozess (use case) (Arbeitsablauf)o besteht aus mehreren zusammenhängenden Aufgaben, die von einem Akteur

durchgeführt werden, um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen.

Akteure• Rollen von Menschen oder Systeme, insbesondere Computersysteme, die als

externe Beteiligte mit einem Unternehmen (Kunden) oder einem Software-Produkt (Benutzer) kommunizieren und Daten austauschen; stets außerhalb des Systems


(Benutzer) kommunizieren und Daten austauschen; stets außerhalb des Systems

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeSchablone für Geschäftsprozesse

Geschäftsprozess: Name (was wird getan?)• Ziel: Globale Zielsetzung bei erfolgreicher Ausführung des Geschäftsprozesses• Kategorie: primär sekundär oder optional• Kategorie: primär, sekundär oder optional• Vorbedingung: Erwarteter Zustand, bevor der Geschäftsprozess beginnt• Nachbedingung Erfolg: Erwarteter Zustand nach erfolgreicher Ausführung des

Geschäftsprozesses• Nachbedingung Fehlschlag: Erwarteter Zustand, wenn das Ziel nicht erreicht

werden kann• Akteure: Rollen von Personen oder andere Systeme, die den Geschäftsprozess

auslösen oder daran beteiligt sindauslösen oder daran beteiligt sind.• Auslösendes Ereignis: Wenn dieses Ereignis eintritt, dann wird der

Geschäftsprozess initiiert• Beschreibung:

1 Erste Aktion2 Zweite Aktion

• Erweiterungen: o 1a Erweiterung des Funktionsumfangs der ersten Aktiono 1a Erweiterung des Funktionsumfangs der ersten Aktion

• Alternativen: o 1a Alternative Ausführung der ersten Aktiono 1b Weitere Alternative zur ersten Aktion


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeSchablone für Geschäftsprozesse - Beispiel

Geschäftsprozess: Buchen: Von Anmeldung bis Buchung• Ziel: Anmeldebestätigung und Rechnung an Kunden geschickt• Kategorie: primär• Kategorie: primär• Vorbedingung: -• Nachbedingung Erfolg: Kunde ist angemeldet• Nachbedingung Fehlschlag: Mitteilung an Kunden, dass Veranstaltung ac ed gu g e sc ag u g a u d , dass a s a u g

ausgebucht, ausfällt oder nicht existiert• Akteure: Kundensachbearbeiter• Auslösendes Ereignis: Anmeldung des Kunden liegt vor

B h ib • Beschreibung: o 1 Kundendaten prüfeno 2 Veranstaltung prüfeno 3 Anmeldebestätigung und Rechnung erstelleno 3 Anmeldebestätigung und Rechnung erstellen

• Erweiterungen: o 1a Kundendaten aktualisiereno 1b Wenn Kunde Mitarbeiter einer Firma ist, dann Firmendaten erfassen

• Alternativen: o 1a Neukunden erfasseno 2a auf alternative Veranstaltung hinweisen, wenn ausgebucht


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeGeschäftsprozessdiagramm

Geschäftsprozessdiagramm (use case diagram) :• Beschreibt das Zusammenspiel mehrerer Geschäftsprozesse untereinander und p p

mit den Akteuren• Überblick über Produkt und Umgebung auf hohem Abstraktionsniveau• In UML gibt es drei Möglichkeiten, Geschäftsprozesse zu strukturieren: die

extend Beziehung die include Beziehung und die Generalisierungsbeziehungextend-Beziehung, die include-Beziehung und die Generalisierungsbeziehung

System

Geschäfts-prozess 1

Akteur 1



Akteur 3

Akteur 2

prozess 3prozess 2


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeStruktur von Geschäftsprozessen

extend-Beziehung

BasisgeschäftsprozessErweiterung des

InformierenExtension point Adressaufkleber

«extend»Der Kunde wünschtInfo-Material

Basisgeschäftsprozess Geschäftsprozesses

pNach Kundendaten

abrufenerstellen

Kunden-sachbearbeiter

• vom Basisprozess wird in den Unterprozess verzweigt, wenn bestimmte Bedingungen erfüllt sindBedingungen erfüllt sind

• Komplexitätsreduktion des Basis-Geschäftsprozesses



include-Beziehung

Buchen

Z hl l

Firmen-buchung

«include»«include»

Zahlungsmoralüberprüfen

Mache Prozesse besitzen die gleichen Unterprozesse. Um diese nicht doppelt zu beschreiben werden sie als selbständiger Prozess modelliert Mehrere Prozesse können beschreiben werden sie als selbständiger Prozess modelliert. Mehrere Prozesse können den Unterprozess dann verwenden. Unterprozesse stehen nie für sich allein. (Analogie zu Unterprogramme in Programmiersprachen)

Der Pfeil zeigt vom Standard- zum Unterprozess, „Buchen“ ist also z. B. der Hauptprozess, „Zahlungsmoral überprüfen“ der Unterprozess.



Generalisierungs-Beziehung

Einweisung

Krankenhaus-aufnahme

N tf llEinweisungdurch Arzt

Notfall-aufnahme

• übergeordneter Prozess vererbt sein Verhalten an die untergeordneten Prozesse

• abstrakte vs. konkrete Prozesse

UML : siehe Programmierung und Programmiersprachen UML : siehe Programmierung und Programmiersprachen


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeBeispiel für ein Geschäftsprozessdiagramm


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeCheckliste Geschäftsprozesse

Ergebnisse• Geschäftsprozessdiagramm• Geschäftsprozessdiagramm

o Alle Geschäftsprozesse und Akteure sind eingetragen• Beschreibung der Geschäftsprozesse

o Alle Geschäftsprozesse sind umgangssprachlich oder mittels Schablone p g g pbeschrieben.

Konstruktive Schritte1. Akteure ermitteln

o Welche Personen führen diese Aufgaben zur Zeit durch und besitzen o Welche Personen führen diese Aufgaben zur Zeit durch und besitzen daher wichtige Kenntnisse über die durchzuführenden Arbeitsabläufe? Welche Rollen spielen diese Personen?

o Welche Personen werden zukünftig diese Aufgaben durchführen und auf l h k d b fl h bwelche Vorkenntnisse muss die Benutzungsoberfläche abgestimmt

werden? Welche Rollen spielen diese Personen?o Wo befindet sich die Schnittstelle des betrachteten Systems bzw. was

gehört nicht mehr zu dem System?



2. Geschäftsprozesse für die Standardverarbeitung ermittelno Primäre und ggf. sekundäre Geschäftsprozesse betrachteno Welche Standardverarbeitung besitzen sie?a) mittels Akteuren (z. B. Akteur „Veranstaltungsbetreuer“: Prozess

„Veranstaltung betreuen“) Sind die Akteure Personen? Welche Arbeitsabläufe lösen sie aus? Welche Arbeitsabläufe lösen sie aus? An welchen Arbeitsabläufen wirken sie mit?

b) mittels Ereignissen (Akteure sind externe Systeme) (z. B. Ereignis „Anmeldung liegt vor“) Erstellen einer Ereignisliste Für jedes Ereignis einen Geschäftsprozess identifizieren Externe und zeitliche Ereignisse (i. d. R. intern ausgelöst)

unterscheidenunterscheidenc) mittels Aufgabenbeschreibungen

Was sind die Gesamtziele des Systems? Welches sind die zehn wichtigsten Aufgaben? Was ist das Ziel jeder Aufgabe?

3. Geschäftsprozesse für Sonderfälle formuliereno „Erweiterungen und Alternativen“ mittels Schablone erstellen

A fb d f S d df k i li ä i d di S d fäll


o Aufbauend auf Standardfunktionalität mit extend die Sonderfälle formulieren, d.h. erweiterte Geschäftsprozesse beschreiben.


4. Aufteilen komplexer Geschäftsfälleo Komplexe Schritte als eigene Sub-Prozesse spezifizieren (include)o Komplexe Geschäftsprozesse (viele Sonderfälle) in mehrere o Komplexe Geschäftsprozesse (viele Sonderfälle) in mehrere

Geschäftsprozesse zerlegen und Gemeinsamkeiten mit include modellieren

o Umfangreiche Erweiterungen als eigene Geschäftsprozesse spezifizieren d i l d d H bi dund mittels extend an den Hauptprozess anbinden

5. Gemeinsamkeiten von Geschäftsprozessen ermittelno Auf redundanzfreie Beschreibung achten (include).

Analytische Schritte6. »Gute« Beschreibung

o Verständlich für den Auftraggebero Extern wahrnehmbares Verhalteno Fachliche Beschreibung des Arbeitsablaufso Standardfall vollständig und Sonderfälle separat

M i l i S ito Maximal eine Seite7. Fehlerquellen

o Zu kleine und damit zu viele Geschäftsprozesseo Zu frühe Betrachtung von Sonderfällen


o Zu frühe Betrachtung von Sonderfälleno Zu detaillierte Beschreibung

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeBeispiel: Bearbeitung Schadensfall bei Versicherung

Geschäftsprozess: bearbeite Schadensfall• Ziel: Bezahlung des Schadens durch die Versicherung• Kategorie: primär• Kategorie: primär• Vorbedingung: -• Nachbedingung Erfolg: Schaden ganz oder teilweise bezahlt• Nachbedingung Fehlschlag: Forderung abgewiesenac ed gu g e sc ag o d u g abg s• Akteure: Schadenssachbearbeiter• Auslösendes Ereignis: Schadensersatzforderung der versicherten Person• Beschreibung:

o 1 Sachbearbeiter prüft die Forderung auf Vollständigkeito 2 Sachbearbeiter prüft, ob gültige Police vorliegto 3 Sachbearbeiter errechnet und überweist Betrag an Antragsteller

• Erweiterungen: • Erweiterungen: o 1a vom Antragsteller vorliegende Daten sind nicht vollständig,

Sachbearbeiter muss die Daten nachforderno 2a Antragsteller besitzt keine gültige Police, Sachbearbeiter teilt ihm dies mit

und schließt den Fall abo 3a Schaden durch Police unvollständig gedeckt: Sachbearbeiter errechnet

Teilbetrag und überweist diesen• Alternativen: -


• Alternativen:

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeDatenflussdiagramm

Ein DFD (data flow diagram) beschreibt die Wege von Daten bzw. Informationen zwischen Funktionen, Speichern und Schnittstellen und die Transformation der Daten bzw. Informationen durch Funktionen. DFDs stellen also die „Daten-Pipeline“ dar.

Notation nach / DeMarco 79 /

1. DatenflussDatenname

2. Funktion oder ProzessFunktions-

name

3. DatenspeicherSpeichername

4. Schnittstelle zur UmweltSchnittstellen-

name


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeDatenflussdiagramm

Quelle

Grundidee eines DFD besteht darin, dass man sich vorstellt, das zu entwickelnde System läuft bereits. Man macht sich keine Gedanken darüber, wie das System initialisiert und terminiert wird Man System initialisiert und terminiert wird. Man konzentriert sich darauf, welche Informationen von wo nach wo durch das System fließen.

S h S h itt t ll i i U l System hat Schnittstellen mit seiner Umwelt. Schnittstellen können Datenquellen und -senken sein

Umwelt besteht für das System aus Informations-yquellen und Informationssenken.

Speicher sind Hilfsmittel zur Ablage von Informationen Informationen können hineinfließen Informationen. Informationen können hineinfließen oder herausgelesen werden (siehe Pfeilrichtungen).

Funktionen transformieren den ankommenden D t fl i d b h d

Senke


Datenfluss in den abgehenden.

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeDatenflussdiagramm - Beispiel

verwalte BeantworteKunden-

daten /F10/Anfragen

/F90/

Kunde

Kundendatei /D10/ Firmendatei /D20/

Kunden-sach-bearbeiter

verwalteFirma FirmendatenverwalteFirmen-daten /F23/

Mitteilungen


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeDatenflussdiagramm - Syntaktische Regeln

Beim Zeichnen eines DFD sind folgende syntaktische Regeln einzuhalten

• Ein DFD enthält mindestens 1 SchnittstelleEin DFD enthält mindestens 1 Schnittstelle• Jede Schnittstelle ist i. Allg. nur einmal vorhanden

o Ausnahme: Wird das DFD unübersichtlich, dann kann eine Schnittstelle mehrfach gezeichnet werden

Z i h S h i ll ib k i D flü• Zwischen Schnittstellen gibt es keine DatenflüsseFalsch:

• Jeder Datenfluss hat einen Nameno Ausnahme: Datenflüsse, die zu Speichern

führen und keinen Namen haben, beinhalten die gesamten gespeicherten Dateng p

• Zwischen Speichern dürfen keine direkten Datenflüsse gezeichnet werden

Falsch:

• Zwischen Schnittstellen und Speichern dürfen

Falsch:


• Zwischen Schnittstellen und Speichern dürfenkeine direkten Datenflüsse gezeichnet sein

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeDatenflussdiagramm - Semantische Regeln

• Das DFD beschreibt den Datenfluss, nicht den Kontrollfluss, daher enthält es weder Entscheidungen noch SchleifenS h i S h i ll fü i Vi l hl b li bi i l I d i d i • Steht eine Schnittstelle für eine Vielzahl von beliebig vielen Instanzen, dann wird sie als eine Schnittstelle dargestellt, z. B. „Kunde“

• Wird das System durch eine eng begrenzte Anzahl von gleichartigen Schnittstellen begrenzt, die sich aber durch unterschiedliche Datenflüsse auszeichnen, dann ist eine getrennte Darstellung sinnvoll

• Eine Schnittstelle ist so zu wählen, dass sie die ursprüngliche Quelleoder Senke einer Information angibt

• Bei der Wahl einer Schnittstelle wird von der konkreten Ein- oder Ausgabe einer • Bei der Wahl einer Schnittstelle wird von der konkreten Ein oder Ausgabe einer Information in das System vollständig abstrahiert (z. B. Drucker, Tastatur)

• Ein Datenflussname besteht aus einem Substantiv oder einem Adjektiv und einem Substantiv

D t fl th lt i l V b• Datenflussnamen enthalten niemals Verben• Die Datenflussnamen sind so zu wählen, dass sie nicht nur die Daten, die fließen,

beschreiben, sondern etwas darüber aussagen, was über die Daten bekannt ist (z. B. statt „Rechnungsnummer“ „gültige Rechnungsnummer“)

• Ein Funktions- bzw. Prozessname besteht aus einem einzigen Aktions-Verb gefolgt von einem einzigen konkreten Objekt oder einem konkreten Substantiv gefolgt von einem Aktions-Verb (z. B. „Rechnung erstellen“ oder „erstelle Rechnung“)

• Funktionsnamen repräsentieren Aktionen


Funktionsnamen repräsentieren Aktionen

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeÜbersicht Basiskonzepte

A rb eitsab lau fFun kti ona leHie rach ie

Fun ktion sba um Da ten fl ussdia gr amm

B asis -kon zep t

No ta ti on

In fo rm a ti on sflu ss

G esch äftsp ro zess (GP )

N et zBa u m h ier a ch ie»M uster«de rNo ta ti on

E lem e nteFu n kt i o n /

Pr o ze ss Sp e ic h erFu n k t i o n

N e t z ( UM L) M u st er / Sch a b lo n e

Ge sch ä ft sp r o z ess:Z i e l:K at eg o r i e :

G PPr o ze ss

Da te n fl u ss

Be i sp i el :

Sch n i t ts t e ll e

K at eg o r i e :Vo r b e d i n g u n g :N ach b e d in g u n g

Er fo l g :N ach b e d in g u n g

Feh l sch l a g :A k te u r e:A u s lö se n d es Er ei g n i s :B h ib

Syst e m /Pr o d u k t

Ak t e u r Ko m m u n i ka ti o n(A sso zia t i o n )

«in c l u d e »

e sp eBesch re i b u n g :12Er w ei t er u n g en :1 aA l t er n a ti v en :1 a

Bei sp i e l : GP-D iag r a m m

GP 1

GP 2

Ge n er a l i s ie r u n g «ex t e n d »

Me th od ische sVorg eh en

Vo n d e n Sch n it t s te l l ena u sg eh e n d ( ou t s i d e-i n )

to p- do wn Vo n d en A k te u r en au sg e h en d( ou t s i d e-i n )

GP 2

GP 3

«ex t en d »

g

Re geln

g ( )

Nu r D at en fl u ss b e sch r eib en ,k ei n en Ko n tr o ll f l u ssSch n i tt st el le is t Q u el le / Se n kev on In fo r m at io n enNu r Fu n kt io n en / Pr o zesseg r ei fen au f Sch ni t ts te ll enu n d Sp ei ch er zu

Zu e in er Va te r-f k t . n u r fa ch l i che n g z u sam m e n -g e h ö r i g e Fkt .Pro H ier a ch ie-e b en e g lei ch e sA b st r ak t io n s

( )

GP-N a m e: G er u n d i u m o d er Su b st an t i v -Ver bo d e r A n fa n g -En d eZu e r st Sta n d a rd fa l l, d an n So n d e r fä l leGe m ein sa m es Ver h a lt e n : «in cl u d e »-Bez ieh u n gEr w ei t er t es Ve r h a lt en : «ex t e n d »-Bez i eh u n g


u n d Sp ei ch er zuA b st r ak t io n s-n i v ea u

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeZusammenfassung

Die funktionale Sicht auf ein zu entwickelndes Produkt kann durch die hierarchische Gliederung von Funktionen, angeordnet in einem Funktionsbaum, beschrieben werden.

Durch Geschäftsprozesse können die Arbeitsabläufe von Akteuren mit dem Produkt auf einer hohen Abstraktionsebene beschrieben werden. Die Dokumentation erfolgt in UML durch Geschäftsprozessdiagramme Zur Dokumentation erfolgt in UML durch Geschäftsprozessdiagramme. Zur Spezifikation einzelner Geschäftsprozesse kann eine Geschäftsprozess-Schablone eingesetzt werden.

Durch DFD kann der Informationsfluss zwischen Funktionen, Speicher und Schnittstellen zur Umwelt dargestellt werden.


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeÜberblick LE 6

LE 5: Funktionale Sicht

LE 6: OO-Sicht

• Lernziele• Objektorientierte Konzepte• Zusammenfassung


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeLernziele

1. Begriff „Objektorientierte Software-Entwicklung“ kennen2. Begriffsdefinition an Beispielen: Klasse, Objekt, Attribut,

O tiOperation3. Klassifikation von Operationen4. Aufstellen von UML-Diagrammen für gegebene Problemstellung5. CASE-Werkzeuge einsetzen können


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeÜberblick

Konzepte und Sichten

häufig v

selten v e

Strukto-gramm(1973)

erwendet

erwendet

Kollabora-tionsdia-gramm

Aktivitäts-diagramm(1997)

ET(Entschei-dungsta-belle)(1957)

PAP(Programm-ablaufplan)(1966)

Sequenz-diagramm(1987)

DataDictionary(1979)

Daten-Flussdia-Gramm(1966)

Funktions-baum

Geschäfts-Prozess(1987)

Klassen-diagramm(1980/90)

ER(Entity Re-Lationship)(1976)

Zustands-Automat(1954)

Regeln

(1957)

Pseudo-code

Petri-Netz(1962)

FunktionaleHierachie

Arbeits-ablauf

Kontroll-strukturen

wenn-dann Strukturen

Endlicher Automat

Neben-läufige Strukturen

Inter-aktions-Strukturen

Informa-tions-fluss

Daten-strkturen

Entitäts-typen & Beziehungen

Klassen-strukturen

F kti l Si ht D t i ti t Si htObjekt- Algorith- Szenario-

Z t d i ti t Si htRegel-

LE5 LE8 LE6-7 LE9 LE9-10 LE11-12 LE7

Funktionale Sicht Datenorientierte SichtObje torientierte Sicht

go tmische Sicht

S e a obasierte Sicht

Zustandsorientierte Sichtege

basierte Sicht


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeQuerverweis zu anderen Vorlesungen

Vorlesung Programmierung und Programmiersprachen

Die Vorlesung führt ein in grundlegende Konzepte der objektorientierten Programmierung und Modellierung am Beispiel von Java.

1 G dl d bj kt i ti t S t l 1.Grundlagen der objektorientierten Systemanalyse 2.Java - Grundbegriffe 3.Klassen, Objekte, Methoden 4.Abstraktionen, Generalisierungen, Schnittstellen 4.Abstraktionen, Generalisierungen, Schnittstellen 5.Vererbung und Polymorphie 6.Konzepte der Parallelverarbeitung

Wichtigste OO-Konzepte sind : Objekte, Klassen, Attribute, Operationen, Assoziationen, CRC-Karten, Vererbung, Pakete, Botschaften, Szenarios

Wir behandeln nur CRC-Karten und Pakete da die anderen Konzepte in der oben Wir behandeln nur CRC-Karten und Pakete da die anderen Konzepte in der oben genannten Vorlesung schon ausführlich behandelt wurden.


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeCRC-Karten

CRC-Karten (Class/Responsibility/Collaboration-Karten) sind Hilfsmittel zur OO-Modellierung in Form von Karteikarten. Oben auf der Karte wird der Name der Karte eingetragen. Restliche Karte wird in zwei Teile geteilt. Auf der einen Hälfte werden dieVerantwortlichkeiten (responsibilities) der Karte notiert und auf der anderen die Kollaborationen (notwendige Klassen)

Responsibilitiesverwaltet ein Sparkontodelegiert Aufgaben an

CollaborationsKontobewegung

Class Sparkonto

g gKontobewegung

SparkontoK t b

1KontonummerHabenzins/ Kontostand

Kontobewegung

BetragDatum

*

eröffnen()einzahlen()abheben()gutschreibenZinsen()


auf lösen()

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemePakete

• Pakete sind Strukturierungsmechanismus und erlauben es, Komponenten zu einer größeren Einheit zusammenzufassen

• in UML zur Strukturierung beliebiger Modellelemente eingesetzt (Paketdiagramm)

Beispiel: Pakete eines Handelssystems

Handelssystem

Einkauf Verkauf

AbhängigkeitLager

Abhängigkeit


Änderung an „Lager“ erfordert evtl. Veränderungen an „Einkauf“ und „Verkauf“

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeMethode zur Paketbildung

Kriterien: Das Paket soll eine logische Einheit bilden, d.h. es soll so strukturiert sein, dass es...

1 d L d h d M d ll füh t1. den Leser durch das Modell führt2. einen Themenbereich enthält, der für sich allein betrachtet und verstanden

werden kann3. Klassen enthält, die logisch zusammengehören, g g

z.B. Artikel, Lieferant und Lager4. für sich entworfen und evtl. implementiert werden kann, wobei eine

wohldefinierte Schnittstelle zur Umgebung vorhanden ist.

Die Schnittstelle soll...• Vererbungsstrukturen nur in vertikaler Richtung schneiden, d.h. zu jeder

Unterklasse sollen alle Oberklassen in dem Paket enthalten sein• keine Aggregation durchtrennen• möglichst wenig Assoziationen enthalten

Di K l i h d Kl i h lb i P k t ll ö li h t ß d Die Kopplung zwischen den Klassen – innerhalb eines Pakets – soll möglichst groß und zwischen Paketen möglichst gering sein

• Jedes potenzielle Paket prüft man auf seine Kopplungseigenschaft. • Verbesserungen durch Verschieben von Elementen zwischen den Paketen möglich


g g

SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeZusammenfassung

Objektorientierte SW-Entwicklung basiert auf einer Reihe von G dk i d hi d i bGrundkonzepten. Hier werden verschiedene Diagrammarten benutzt, um unterschiedliche Aspekte darzustellen. Als grafische Notation wird UML verwendet.

OO-Konzepte sind gut geeignet für Datenkapselung

Für die Wartbarkeit des entstehenden Software Systems ist es Für die Wartbarkeit des entstehenden Software-Systems ist es entscheidend, dass das Konzept der Vererbung sinnvoll eingesetzt wird


SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeLiteratur

• Balzert H., Lehrbuch der Softwaretechnik, 2. Auflage, Spektrum Akademischer Verlag,Heidelberg, 2000.

• Booch G., Rumbaugh J., Jacobson I., The Unified Modeling Language User Guide, Addison-Wesley, 1999

• Booch G., Object-Oriented Analysis and Design with Applications, 2. Auflage, The Benjamin/Cummings Publishing Company, Redwood City, 1994

• DeMarco T., Structured Analysis and System Specification, Yourdon Press, Englewood Cliffs, 1979

• Balzert Heide, Lehrbuch der Objektmodellierung – Analyse und , j g yEntwurf, Spektrum Akademischer Verlag, Heidelberg, 1999

• Jacobson I, Ericson M., Jacobson A., The Object Advantage Buisness Process Reengineering with Object Technology, Buisness Process Reengineering with Object Technology, Addison-Wesley, Workingham, 1994

• OMG Unified Modeling Language Specification, Version 1.3, June 1999 http://www rational com


1999, http://www.rational.com

vorlesung softwaretechnik - definitionsphase, funktionale...

Documents