Vorlesung Softwaretechnik - Definitionsphase, funktionale...
Transcript of 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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 2
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)
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 3
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 4
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 5
• 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 /
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 6
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 7
(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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 8
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 9
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
Geschäfts-prozess 3
Geschäfts-prozess 2
Akteur 3
Akteur 2
prozess 3prozess 2
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 10
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 11
SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeStruktur von Geschäftsprozessen
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.
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 12
SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeStruktur von Geschäftsprozessen
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 13
SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeBeispiel für ein Geschäftsprozessdiagramm
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 14
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?
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 15
SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeCheckliste Geschäftsprozesse
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 16
o Aufbauend auf Standardfunktionalität mit extend die Sonderfälle formulieren, d.h. erweiterte Geschäftsprozesse beschreiben.
SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeCheckliste Geschäftsprozesse
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 17
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: -
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 18
• 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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 19
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 20
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 21
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:
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 22
• 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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 23
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 24
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.
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 25
SWT – funktionale und objektorientierte SichtInstitut für InformatikBetriebliche InformationssystemeÜberblick LE 6
LE 5: Funktionale Sicht
LE 6: OO-Sicht
• Lernziele• Objektorientierte Konzepte• Zusammenfassung
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 26
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 27
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 28
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.
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 29
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()
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 30
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 31
Ä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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 32
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 33
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
Prof. K.-P. Fähnrich (nach Balzert) Vorlesung: 5 Seite 34
1999, http://www.rational.com