Händelseuppdelning

Systemkontextdiagram för ett fiktivt hotell. (I enlighet med konventionen används dubbelriktade flöden, med pilar i båda ändar, ofta när en dialog initieras externt. Till exempel innehåller "bokningsdialog" flödet "bokningsförfrågan", som är den första triggern; "bokningsbekräftelse", den resultat, skickas tillbaka.)

Händelsepartitionering är en lättanvänd systemanalysteknik som hjälper analytikern att organisera krav för stora system i en samling av mindre, enklare, minimalt anslutna, lättare att förstå "minisystem"/ användningsfall .

Översikt

Tillvägagångssättet för händelseuppdelning förklaras av Stephen M. McMenamin och John F. Palmer i Essential Systems Analysis . En kort version av tillvägagångssättet beskrivs i artikeln om Data Flow Diagrams (DFDs). En mer fullständig diskussion finns i Edward Yourdons Just Enough Structured Analysis . Beskrivningen fokuserar på att använda tekniken för att skapa dataflödesdiagram, men den kan också användas för att identifiera användningsfall .

Utgångspunkten för händelseuppdelning är att system finns för att reagera på externa händelser: identifiera vad som händer i affärsmiljön som kräver planerade reaktioner, definiera och bygg sedan system för att svara enligt verksamhetens regler. I synnerhet finns ett affärssystem för att betjäna kundernas önskemål. En kund, i jargongen för Unified Modeling Language (UML), är en " skådespelare ".

Ämnen för händelsepartitionering

Skådespelare → Händelse → Upptäck → Svara

Metoden har följande steg.

1. Identifiera de externa systemen genom att brainstorma en lista över de " aktörer " (externa system), som är källorna till externa händelser. Om du tycker att en grafik är till hjälp, skapa ett kontextdiagram som visar aktörerna utanför det studerade systemet och flöden/signaler mellan dem.
2. Att sätta sig i en "skådespelares" skor (eller arbeta med skådespelarrepresentanter), brainstorma en lista över de " externa händelser " / "triggers" som de vill att systemet ska ha en planerad respons på. (Observera att systemet inte kan skapa externa händelser; endast en aktör kan.)
3. Identifiera vad som gör det möjligt för systemet att upptäcka externa händelser:
- ankomsten av en eller flera data (eventuellt i form av ett meddelande)
- ankomsten av en eller flera tidpunkter ( kallas "temporala" händelser av M&P, och särskiljs av dem från externa händelser)
4. Identifiera de planerade svaren som systemet kan utföra när händelserna inträffar. Det är svaren/användningsfallen som gör det möjligt för systemet att uppnå sina mål.

Tekniken utökades med "icke-event"-evenemang av Paul T. Ward och Stephen J. Mellor i Structured Development for Real-Time Systems: Essential Modeling Techniques .

"Eftersom terminatorerna [aktörerna] per definition ligger utanför gränserna för den systembyggande ansträngning som representeras av modellen, kan implementörerna inte modifiera terminator-tekniken [aktör] för att förbättra dess tillförlitlighet. Istället måste de bygga svar till terminator [ aktörsproblem i systemets väsentliga modell. Ett användbart tillvägagångssätt för att modellera svar på problem med terminator [aktör] är att skapa en lista över "normala" händelser och sedan fråga, för varje händelse: "Behöver systemet svara om denna händelse inte inträffar som förväntat?' " [min kursivering]

Data ordbok notation

Yourdon/DeMarco-stil av dataordboknotation kan användas för att beskriva datasammansättningen och strukturen.

Symbol	Menande
=	"innehåller", "är" eller "består av"
+	"och", "liksom" eller "tillsammans med" ( inte aritmetiskt "plus")
[ x ; y ; z ]	"välj bara en av antingen x eller y eller z ". Antingen ett semikolon (;) eller ett vertikalt streck (\|) kan användas för att separera objekt i listan.
m { x } n eller m:n { x } eller ${}_{m}^{n}\{x\}$	"från m till n iterationer av x ". Om m eller n inte anges är den nedre eller övre gränsen helt enkelt "okänd" eller "ospecificerad". Flerdimensionella arrayer kan specificeras genom kapsling, t.ex. 10 { 10 { x } 10 } 10 definierar en tvådimensionell matris med 10 rader med 10 kolumner.
( x )	"valfritt x ". Detta motsvarar 0{ x }1 eller 0:1{ x } eller ${}_{0}^{1}\{x\}$ .
@	prefix för en identifierare inom en iteration. Till exempel i {@i+@j+x} är i och j identifierare.
* ... *	Allt mellan enstaka asterisker betraktas som en kommentar. På dataelementnivå kan en kommentar innehålla typtaggar som "intervall :", "gränser :", "precision :", "enhet :" eller "värden :".

Datastrukturelementen kan mappas till strukturerad programmerings kontrollstrukturer :

"+" kan mappas till en "sekvens" av uttalanden (även om det inte nödvändigtvis är så)
"[|]" kan mappas till "selektion" ( villkor , switch-satser )
"{}", "()" kan mappas till "iteration" ( räkningsslinga , pre-test loop , mitten-test loop, post-test loop och oändlig loop )

OBS! De artiklar som definieras kan vara "material" (t.ex. rumsnyckel) såväl som "data" (t.ex. ankomstdatum-tid).

Identifiera krav och deras skäl

Händelsesvarsinformationen kan fångas i en tabell. Händelsen är raison d'être för responsen, vilket ger " spårbarhet " från responsen tillbaka till omgivningen.

1. Skådespelare	2. Extern händelse/utlösare	3. Upptäckt av	4. Svar/användningsfall
Gäst	Gäst efterfrågar ett rum av en viss typ, för ett visst ankomstdatum, avresedatum, till ett visst pris, etc.	bokningsbegäran + (betalningsvalidering) + (externt bokningssystem bokningsbekräftelse)	Boka rum (kan inkludera garanterad bokning, alternativ hotellbokning, bokning på väntelista)
Gäst	Gäst ber om att avboka rumsbokning.	begäran om avbokning	Avboka bokning
Gäst	Gäst anländer till hotellet.	ankomstmeddelande = * * = [gästnamn ; bokningsnummer]	Checka in Gäst
Tid / Schemaläggare	Gäst misslyckas med att anlända till hotellet. [Detta är en "icke-händelse".]	23.00 (lokal tid) [En "icke-händelse"-händelse upptäcks genom ankomsten av en tidpunkt, en deadline.]	Skapa gästräkning, uppdatera bokning
Gäst	Gäst ber att få checka ut från hotellet.	utcheckningsförfrågan = * * = [gästens namn ; rumsnummer]	Skapa gästräkning, uppdatera rumsbeläggning
Tid / Schemaläggare	Gästen misslyckas med att checka ut från hotellet. [Detta är en "icke-händelse".]	11:00 (lokal tid) [En "icke-händelse"-händelse upptäcks genom ankomsten av en tidpunkt, en deadline.]	Skapa gästräkning
Gäst	Gäst erbjuder betalning av faktura.	betalningsfordon = * * = [kontanter ; kolla upp ; kreditkort ; betalkort] + (gäst-id)	Acceptera gästbetalning
Tid / Schemaläggare	Dags att förbereda Rumsbeläggningsrapport för föregående natt.	08.00 (lokal tid)	Rapport om lokalbeläggning
Hotell chef	Hotellchefen begär rumsbeläggningsrapport.	begäran om inflyttningsberättelse	Rapport om lokalbeläggning
Rök / CO-larm	Larmet upptäcker rök.	meddelande om brandvarnare	Rapportera brandvarnare
Rök / CO-larm	Larm detekterar CO (kolmonoxid).	CO-larmmeddelande	Rapportera CO-larm

Definiera krav

Enskild process på ett fiktivt hotell med hjälp av dataflödesdiagram .

Engångsfall på ett fiktivt hotell med användningsfallsdiagram .

Detta tillvägagångssätt hjälper analytikern att bryta ner systemet till "mentalt bitsstora" minisystem med hjälp av händelser som kräver ett planerat svar. Detaljnivån för varje svar är på nivån "primära användningsfall ". Varje planerat svar kan modelleras med DFD-notation eller som ett engångsfall med användning av use case-diagramnotation.

Det grundläggande flödet inom en process eller ett användningsfall kan vanligtvis beskrivas i ett relativt litet antal steg, ofta färre än tjugo eller trettio, eventuellt med något som " strukturerad engelska ". Helst skulle alla steg vara synliga på en gång (ofta en sida eller mindre). Avsikten är att minska en av de risker som är förknippade med korttidsminnet , nämligen att glömma det som inte är direkt synligt ("out of sight, out of mind").

Nassi–Shneiderman-diagram" genom att använda notationerna för strukturerade tekniker . I UML kan användningsfallet modelleras med hjälp av ett aktivitetsdiagram , ett sekvensdiagram eller ett kommunikationsdiagram . Detta kan vara problematiskt om det finns många komplexa scenarier för användningsfallet; analytikern kanske vill modellera alla eller de flesta scenarierna.

Komplexitet kontra fragmentering

Om svaret är långt eller komplicerat (dvs. mer än en sida med text) kan en analytiker bryta ner ("faktor ut" eller deduplicera ) till mindre "sekundära användningsfall" för att hålla "förälderns" primära användningsfall mindre och enklare. Dessa sekundära användningsfall kan visa sig vara återanvändbara också. (I ett UML- användningsfallsdiagram skulle de ritas som utökade eller inkluderade användningsfall, som är relaterade till ett eller flera primära användningsfall.)

Medan han beskriver ett användningsfall kan en analytiker också avslöja " affärsregler ". Vissa analytiker föreslår att fånga affärsregler i ett separat dokument med hjälp av Object Constraint Language eller någon annan formell notation . När sedan en affärsregel måste följas i ett användningsfall hänvisar analytikern till den. Detta minimerar upprepning inom en specifikation, men riskerar fragmentering av en specifikation. En teknik som kan minska denna spänning är att använda hyperlänkar i specifikationsdokumentet.

Detta reduktionistiska tillvägagångssätt står något i kontrast till ett systemtänkande som representeras av Peter Checklands mjuka systemmetodik .

Utöver funktionskrav som fångas i en beskrivning av användningsfall, kan en analytiker inkludera sådana icke-funktionella krav som svarstid, inlärningsbarhet, etc.

Se även

externa länkar

Händelsepartitionering Wiki för strukturerad analys