internes Kontextdiagramm - externes Kontextdiagramm

Transkript

1 ereignisorientierter Ansatz 4. Erfassung der Benutzungsfälle internes Kontextdiagramm - externes Kontextdiagramm Kontextdiagramme können auf Anwenderebene und auf Benutzerebene des Systems definiert werden. ( Anwender: der die Resultate des Systems benutzt. Benutzer: der mit dem System direkt interagiert, Endbenutzer) um den Sinn (Essenz) der Systemfunktionen zu verstehen/zu dokumentieren, muss man auf Anwenderebene modellieren: das externe Kontextdiagramm, mit den Anwendern als Akteure Beispiel: der Kunde im CompService (ist kein Endbenutzer des DV-Systems) um die eigentlichen Grenzen des DV-Systems zu modellieren, muss man auf Benutzerebene modellieren: das interne Kontextdiagramm, mit den Endbenutzern als Akteure Beispiel: Sachbearbeiter Bestellungserfassung im CompService 69

2 ereignisorientierter Ansatz 4. Erfassung der Benutzungsfälle das interne Kontextdiagramm Sachbearbeiter Bestellungserfassung Deckungsmeldung bearbeiten Bestellung stornieren Bestellung erfassen «system» COMP- SERVICE 70

3 ereignisorientierter Ansatz 4. Erfassung der Benutzungsfälle Kunde (K) Kunden- Stornierung Sachbearbeiter Bestellungserfassung Kundenbestellung externe Systemgrenze Bestellung stornieren interne Systemgrenze <<actor>> Kreditinstitut (I) Deckungsmeldung Deckungsmeldung bearbeiten Bestellung erfassen «system» COMP- SERVICE Endbenutzer sind im externen Kontextdiagramm Teil des Systems. Man kann sie als Schnittstellenakteure betrachten. interne Kontextdiagramme sind weniger essentiell als externe: sie legen eine bestimmte Arbeitsorganisation innerhalb des Systems fest, und lenken die Aufmerksamkeit auf Dialog-/Interfacetechnologie es ist ratsam, beide Kontextdiagramme zu modellieren 71

4 ereignisorientierter Ansatz 4. Erfassung der Benutzungsfälle was ist der "richtige" Detaillierungsgrad von Ereignissen? Regel 1: Ereignisse sollen nicht in Dialog/GUI-Sicht beschreiben werden: Bsp.1: falsch: "drücke OK-Button" oder "öffne Drucken-Dialog" Regel 2: Ereignisse können verallgemeinert werde (Generalisierung!) Bsp.2: "gib neues Produkt ein" "gib neues Spezialprodukt (nicht gelagert) ein" Regel 3: Ereignisse nicht "überabstrahieren" datenorientierte Analyse: untersuche für Spezialfälle, ob sie wesentlich verschiedene Informationen in ihren Ereignisnachrichten tragen. Wenn ja: Überabstraktion! Bsp.3: Ereignis: Kunde führt Transaktion durch Kunde Transaktion -Saldo anzeigen: nichts -abheben: Betrag: Notenstückelung -Kontoauszug drucken: Zeitraum «system» Bancomat 72

5 ereignisorientierter Ansatz 4. Erfassung der Benutzungsfälle Erei.Nr Ereignisse und Usecases ein ereignisorientiertes Modell liefert die systematische Basis für das Auffinden von Usecases jedes Ereignis der Ereignistabelle liefert in der Regel einen Use Case die Unterscheidungen bei den Bedingungen geben Anlass zu einer weiteren Strukturierung: Erweiterungen (Extensions) in den UseCases Ereignisse externer Kontextdiagramme können aber manchmal aus arbeitsorganisatorischen Gründen zu mehreren UseCases im internen Kontextdiagramm werden Nachrichtenbezeichnung 2 Deckungsmeldung bearbeiten Sen der I getragene Informatio Deckungsmeldung auslösendes Ereignis Kreditinstitut meldet Deckung Bedingung Deckung nicht o.k. Deckung o.k. Deckung o.k. und Produkte alle oder teilweise am Lager Deckung o.k. und ein Produkt nicht am Lager erwartete Rückgabe Kundenantwort Vorauszahlung Ku_Lieferungsauftrag (interne Reakt.) Antwort Empfänger K B LV besonderer UseCase: erzeuge Lieferaufträge (am Abend: Zeitereignis) Ziel Kunden Lieferung 73

6 ereignisorientierter Ansatz ereignisorientierter Ansatz und UseCases keine Sicht ins Systeminnere Interaktionen nur als Anfang (Ereignis) und Ende (Antwort) erste Sicht ins Systeminnere: detailliertere Interaktion zwischen Akteur und System, aber keine innere Systemstruktur erste innere Struktur des Systems: organisatorische Komponenten Einkauf Verkauf... Beispiel: Subsysteme Marketing CompService 4. Erfassung der Benutzungsfälle «system» black box 1. Schritt: identifiziere und beschreibe den Systemkontext: Akteure + Ereignisse + Anworten 2. Schritt: identifiziere u. beschreibe UseCases 3. Schritt: bilde Subsysteme (optional) 74

7 ereignisorientierter Ansatz 4. Erfassung der Benutzungsfälle nicht für alle Systeme ist der ereignisorientierte Ansatz mit externem Kontextdiagramm ein sinnvolles Vorgehen beim Auffinden von UseCases Vergleich Compservice POS Kassenterminal Kunde Kassierer POS - externer Geschäftsprozess (Ereignisse) sehr einfach, und eher wichtig für Bestimmung der Kassenauslastungen - interner Prozess (einzelner UseCase) kompliziert, betrifft Interaktion POS-Kassierer, nicht den Kunden CompService... SBEinkauf SBVerkauf - externer Geschäftsprozess kompliziert: mehrere Ereignisse hängen voneinander ab - hier ist die externe Sicht wesentlich zum Verständnis der Interaktionen zwischen internen Akteuren und System Lieferant Kunde 75

8 UseCase Strukturierung es gibt im Wesentlichen 3 Strukturierungsmöglichkeiten für UseCase Beschreibungen: Erweiterung: etwas kommt zum normalen Ablauf hinzu Komponente: ein evtl. mehrfach vorkommender, isolierbarer Teilablauf Abweichung: der Fehlerfall, der den Ablauf wesentlich verändert Haupt- Szenario Beispiel: Bestellung Erweiterung Beispiel: Bestellung mit neuem Kunden Spezialfälle Teilaufgaben Komponente Beispiel: Bonitätsprüfung des Kunden Ausnahmen Abweichung Beispiel: Produkt nicht mehr lieferbar 76

9 UseCase Strukturierung in der UML gibt es nur zwei Typen: der Komponenten-UseCase und der Erweiterungs-UseCase, wobei nicht unterschieden wird zwischen nichtfehlerhafter Erweiterung und fehlerhafter Abweichung Geld abheben Geld einzahlen Geld überweisen «uses» «uses» Geld Transfer «uses» Komponente Geld abheben «extends» Überziehung bearbeiten Erweiterung 77

10 UseCase Strukturierung Process Sale Extension Points: Payment VIP Customer Handle Gift Certificate Payment UML notation: 1. The extending use case points to the base use case. «extend» Payment, if Customer 2. The condition and presents a gift certificateextension point can be shown on the line. 78

11 UseCase Strukturierung NextGen POS Process Sale Cashier «include» «include» «include» «actor» Accounting System Customer UML notation: the base use case points to the included use case Handle Check Payment «include» Handle Cash Payment «include» «include» Process Rental Handle Credit Payment «actor» Credit Authorization Service Handle Returns Manage Users... 79

12 Systemsequenzdiagamme es ist üblich, wichtige Szenarien aus den UseCases auch in Sequenz- system as black box diagrammen zu beschreiben, mit den Nachrichtenflüssen zwischen the name could be "NextGenPOS" but "System" keeps it simple dem System und den Akteuren: das SSD primärer Akteur external actor to system : Cashier the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML Process Sale Scenario das System als Black Box :System eine box Box may kann enlose eine an iteration area Iteration einschliessen *[...] ist ein Iterationsmarker mit Bedingung the * [...] is an iteration marker and clause indicating the box is for iteration makenewsale() enteritem(itemid, quantity) description, total * [more items] Rückgabewert return value(s) für die associated vorhergehende with the previous message Nachricht. Eine Rückgabelinie ist optional wenn es keinen Rückgabewert gibt an abstraction that ignores presentation and medium the return line is optional if nothing is returned endsale() total with taxes makepayment(amount) change due, receipt a message with parameters Nachricht mit Parameter it is an abstraction representing the (keine system event Typen, of bloss entering Namen) the payment data by some mechanism 80

13 Systemsequenzdiagamme SSDs modellieren nichts neues bezüglich Benutzungsfällen, sondern geben eine grafische Darstellung der UseCase Texte verknüpft mit Nachrichten aus dem Kontextdiagramm man sollte nur wichtige, häufig benutzte und komplexe Szenarien modellieren Akteur 1 auslösendes auslösendes externes externes Ereignis Ereignis «system» System «actor» Akteur 2 Nachricht / Ereignis Antwort 1 Zeit Antwort 2 aus aus Kontextmodell: Kontextmodell: Ereignistabelle Ereignistabelle 81

14 Systemsequenzdiagamme SSDs enstehen aus UseCases : Cashier :System Simple cash-only Process Salescenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment.... makenewsale() enteritem(itemid, quantity) description, total * [more items] endsale() total with taxes makepayment(amount) change due, receipt 82

15 Systemsequenzdiagamme Simple cash-only Process Salescenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. : Cashier 2. Cashier starts a new sale. makenewsale() :System 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. enteritem(itemid, quantity) description, total * [more items] Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment.... endsale() total with taxes makepayment(amount) change due, receipt 83

16 Systemsequenzdiagamme SSDs modellieren nichts neues bezüglich Benutzungsfällen, sondern geben eine grafische Darstellung der UseCase Texte. Sie stellen eine Vorstufe zu Sequenzdiagrammen mit Objekten innerhalb des Systems dar (wird im Design behandelt) Akteur 1 objekt 1 System objekt n «actor» Akteur 2 Nachricht / Ereignis Nachricht 1 Antwort 1 Nachricht 2 Antwort 2 84

17 Systemsequenzdiagamme ein weiterer sinnvoller Einsatz von SSDs ist die Hintereinandersetzung von Sznarien mehrerer, logisch zusammenhängender UseCases: Kunde kundeeintragen «system» System «actor» Lager bestellungaufnehmen auftragsbestätigung rechnungsstellung rechnungbezahlen lieferauftrag warenausgeliefert Szenario Bestellung Szenario Lieferung Szenario Bezahlung 85