Die boek beskryf een metode om 'n deel van 'n probleemstelling te skryf, naamlik die gebruiksgevalmetode.
Wat dit is? Dit is 'n beskrywing van die gebruikerinteraksie-scenario met die stelsel (of met die besigheid). In hierdie geval tree die stelsel op as 'n swart boks (en dit maak dit moontlik om die komplekse ontwerptaak te verdeel in die ontwerp van interaksie en die versekering van hierdie interaksie). Terselfdertyd word notasiestandaarde ingestel, wat leesgemak verseker, insluitend vir nie-deelnemers, en maak voorsiening vir sekere kontroles vir volledigheid en voldoening aan die doelwitte van die belanghebbende.
Gebruik geval voorbeeld
Hoe die scenario lyk, met die voorbeeld van magtiging op die webwerf per e-pos:
(Stelsel) Meld aan op die webwerf om toegang tot jou persoonlike rekening te kry. ~~ (seevlak)
Konteks: 'n Ongemagtigde kliënt meld by die webwerf aan sodat die webwerf hom herken en persoonlike inligting vir hom wys: blaaigeskiedenis, aankoopgeskiedenis, huidige aantal bonuspunte, ens., deur e-pos as 'n aanmelding te gebruik.
vlak: gebruiker doelwit
Hoofkarakter: kliënt (besoeker van ons aanlyn winkel)
Omvang: Kliëntinteraksie met die aanlynwinkelwebwerf
Belanghebbendes en belange:
- die bemarker wil hê dat die maksimum aantal werfbesoekers geïdentifiseer moet word vir groter dekking van persoonlike posstukke,
- die sekuriteitspesialis wil verseker dat daar geen gevalle van ongemagtigde toegang tot die besoeker se persoonlike data is nie, insluitend pogings om die wagwoord vir een rekening te raai of na 'n rekening met 'n swak wagwoord te soek,
- die aanvaller wil toegang tot die slagoffer se bonusse verkry,
- mededingers wil negatiewe resensies oor produkte gee,
- Die botnet wil die winkel se kliëntebasis bekom en 'n aanval gebruik om die webwerf onwerksaam te maak.
Voorwaardes: die besoeker moet nie gemagtig word nie.
Minimum waarborge: die besoeker sal weet of die magtigingspoging suksesvol of onsuksesvol was.
Waarborge van sukses: die besoeker gemagtig is.
Hoof scenario:
- Die kliënt inisieer magtiging.
- Die stelsel bevestig dat die kliënt nie gemagtig is nie en nie die aantal onsuksesvolle magtigingspogings van 'n gegewe sessie oorskry nie (soek vir 'n swak wagwoord vir veelvuldige rekeninge) volgens "Sekuriteitsreël No. 23".
- Die stelsel verhoog die teller vir die aantal magtigingspogings.
- Die stelsel vertoon 'n magtigingsvorm aan die kliënt.
- Die kliënt voer sy e-posadres en wagwoord in.
- Die stelsel bevestig die teenwoordigheid van 'n kliënt met so 'n e-pos in die stelsel en dat die wagwoord ooreenstem en die aantal aanmeldpogings by hierdie rekening word nie volgens “Sekuriteitsreël No. 24” oorskry nie.
- Die stelsel magtig die kliënt, voeg die blaaigeskiedenis en die mandjie van hierdie sessie by met die laaste sessie van hierdie kliëntrekening.
- Die stelsel vertoon 'n magtigingsuksesboodskap en beweeg na die skrifstap vanwaar die kliënt vir magtiging onderbreek is. In hierdie geval word die data op die bladsy herlaai met inagneming van die persoonlike rekeningdata.
Uitbreidings:
2.a. Die kliënt is reeds gemagtig:
2.a.1. Die stelsel stel die kliënt in kennis van die feit van die voorheen uitgevoer magtiging en bied aan om óf die skrip te onderbreek óf na stap 4 te gaan, en as stap 6 suksesvol voltooi is, word stap 7 uitgevoer met verduideliking:
2.a.7. Die stelsel deaktoriseer die kliënt onder die ou rekening, magtig die kliënt onder die nuwe rekening, terwyl die blaaigeskiedenis en wa van hierdie interaksiesessie in die ou rekening bly en nie na die nuwe een oorplaas nie. Gaan dan na stap 8.
2.b Die aantal magtigingspogings het die drempel volgens “Sekuriteitsreël No. 23” oorskry:
2.b.1 Gaan na stap 4, 'n captcha word addisioneel op die magtigingsvorm vertoon
2.b.6 Die stelsel bevestig korrekte captcha-inskrywing
2.b.6.1 Captcha verkeerd ingevoer:
2.b.6.1.1. die stelsel verhoog ook die teller van onsuksesvolle magtigingspogings vir hierdie rekening
2.b.6.1.2. die stelsel vertoon 'n mislukkingsboodskap en keer terug na stap 2
6.a. Geen rekening met hierdie e-pos is gevind nie:
6.a.1 Die stelsel vertoon 'n boodskap oor mislukking en bied 'n keuse om óf na stap 2 te gaan óf na die “Gebruikersregistrasie”-scenario te gaan en die ingevoerde e-posadres te stoor,
6.b. Die wagwoord vir die rekening met hierdie e-pos stem nie ooreen met die een wat ingevoer is nie:
6.b.1 Die stelsel verhoog die teller van onsuksesvolle aanmeldpogings by hierdie rekening.
6.b.2 Die stelsel vertoon 'n boodskap oor mislukking en bied 'n keuse om óf na die “Wagwoordherstel”-scenario te gaan óf na stap 2 te gaan.
6.c: Die aanmeldpoging-teller vir hierdie rekening het die drempel vir "Sekuriteitsreël No. 24" oorskry.
6.c.1 Die stelsel wys 'n boodskap oor rekeningaanmelding blokkering vir X minute en gaan voort na stap 2.
Wat is wonderlik
Kontroleer vir volledigheid en voldoening aan doelwitte, dit wil sê, jy kan vereistes aan 'n ander ontleder gee vir verifikasie, wat minder foute maak in die stadium van probleemformulering.
Deur met 'n swart boks-stelsel te werk, kan jy die ontwikkeling en koördinering met die kliënt van wat geoutomatiseer word van die implementeringsmetodes skei.
Dit is deel van die ontleder se pad, een van die belangrikste dele van bruikbaarheid. Die gebruiker se scenario definieer die hoofpaaie van sy beweging, wat die vryheid van keuse vir die ontwerper en die kliënt aansienlik verminder en help om die spoed van ontwerpontwikkeling te verhoog.
Ek is baie tevrede met die plek in die beskrywing waar uitsonderings op elke interaksiestap geïdentifiseer word. 'n Volledige IT-stelsel moet voorsiening maak vir 'n soort uitsonderingshantering, sommige met die hand, sommige outomaties (soos in die voorbeeld hierbo).
Ervaring wys dat ondeurdagte uitsonderingshantering maklik 'n stelsel in 'n verskriklike ongerieflike stelsel kan verander. Ek onthou die storie toe jy in die Sowjet-tye, om 'n besluit te kry, verskeie goedkeurings van verskillende dienste moes kry, en hoe pynlik dit is as die laaste diens sê - maar jou aansoek is in die verkeerde naam of 'n ander fout in leestekens, doen alles oor en herkoördineer alles.
Ek kom dikwels teë op situasies waar die bedryfslogika van 'n stelsel wat nie vir uitsonderings uitgedink is nie, aansienlike herbewerking van die stelsel vereis het. As gevolg hiervan word die grootste deel van die ontleder se werk aan uitsonderingshantering bestee.
Teksnotasie, in teenstelling met diagramme, laat meer uitsonderings toe om geïdentifiseer en gedek te word.
Byvoeging tot die metode uit die praktyk
Die gebruiksgeval is nie 'n onafhanklik geprioriteerde deel van die stelling nie, anders as die gebruikersverhaal.
In die bogenoemde scenario, oorweeg uitsondering “6.a. Geen rekening met hierdie e-pos is gevind nie.” en die volgende stap "6.a.1 Die stelsel vertoon 'n mislukkingsboodskap en gaan voort na stap 2." Watter negatiewe dinge is agter die skerms gelaat? Vir die kliënt is enige opbrengs gelykstaande aan die feit dat al die werk wat hy gedoen het om data in te voer, op 'n stortingsterrein gegooi word. (Dit is net nie sigbaar in die draaiboek nie!) Wat kan gedoen word? Herbou die skrif sodat dit nie gebeur nie. Is dit moontlik om dit te doen? Jy kan - as 'n voorbeeld, kyk na die Google magtiging script.
Scenario optimalisering
Die boek praat oor formalisering, maar sê min oor metodes om sulke scenario's te optimaliseer.
Maar dit is moontlik om die metode te versterk deur scenario's te optimaliseer, en die gebruiksgeval-formaliseringsmetode laat dit toe. Spesifiek, jy moet dink oor elke uitsondering wat voorkom, die oorsaak bepaal en die skrif herbou om van die uitsondering ontslae te raak of die klantreis te verminder.
Wanneer u 'n bestelling van 'n aanlynwinkel plaas, moet u die afleweringstad invoer. Dit kan blyk dat die winkel nie goedere by die stad kan aflewer wat deur die kliënt gekies is nie omdat dit nie daar aflewer nie, weens groottebeperkings, of weens die gebrek aan goedere in die ooreenstemmende pakhuis.
As ons bloot die scenario van interaksie by die registrasiestadium beskryf, kan ons skryf "inlig die kliënt dat aflewering onmoontlik is en bied aan om die stad of die inhoud van die wa te verander" (en baie beginner-ontleders stop daar). Maar as daar baie sulke gevalle is, kan die scenario geoptimaliseer word.
Die eerste ding wat jy moet doen is om jou net die stad te laat kies waar ons kan aflewer. Wanneer om dit te doen? Voordat u 'n produk op die webwerf kies (outoopsporing van die stad via IP met verduideliking).
Tweedens moet ons slegs 'n keuse gee van die goedere wat ons aan die kliënt kan lewer. Wanneer om dit te doen? Op die oomblik van seleksie - op die produkteël en produkkaart.
Hierdie twee veranderinge help baie om hierdie uitsondering uit te skakel.
Vereistes vir metings en metrieke
Wanneer u die taak oorweeg om uitsonderingshantering te minimaliseer, kan u 'n verslagdoeningstaak opstel (gebruiksgeval word nie beskryf nie). Hoeveel uitsonderings daar was, in watter gevalle dit voorgekom het, plus hoeveel inkomende scenario's suksesvol geslaag het.
Maar helaas. Ervaring het getoon dat verslagdoeningsvereistes vir scenario's in hierdie vorm nie genoeg is nie; dit is nodig om verslagdoeningsvereistes te oorweeg vir prosesse wat hoofsaaklik beskryf word nie in die vorm van 'n gebruiksgeval nie.
Toegang tot bruikbaarheid
In ons praktyk het ons die gebruiksgevalbeskrywingsvorm uitgebrei met 'n beskrywing van spesifieke eienskappe van entiteite en data vir die kliënt om 'n besluit te neem, wat daaropvolgende bruikbaarheid verbeter.
Vir bruikbaarheidsontwerp het ons 'n invoerafdeling bygevoeg - vertoondata.
In 'n scenario met magtiging is dit die feit dat die kliënt in die stelsel gemagtig is. As die kliënt vooraf gemagtig is, vertoon dan 'n waarskuwing oor die oorskakeling van die navigasiegeskiedenis en kar na die nuwe rekening na suksesvolle magtiging.
Oor die algemeen is dit 'n vertoning van die nodige inligting vir die kliënt sodat hy 'n besluit kan neem oor sy verdere optrede volgens die scenario (jy kan vra of hierdie data genoeg is vir die kliënt, wat nog nodig is, watter inligting die kliënt moet besluite neem).
Dit is ook die moeite werd om die ingevoerde inligting in invoervelde te verdeel as dit afsonderlik en met die vorming van verskillende uitsonderings verwerk word.
In die voorbeeld met kliëntmagtiging, as u die ingevoerde inligting in login en wagwoord skei, is dit die moeite werd om die magtigingskrip te verander om die stadiums van die invoer van 'n aparte aanmelding en 'n aparte wagwoord uit te lig (en dit word gedoen in Yandex, Google, maar nie in die meeste aanlynwinkels gedoen nie).
Bereik die vereiste datatransformasies
U kan ook vereistes vir data-omskakelingsalgoritmes uit die skrif onttrek.
Voorbeelde:
- Om 'n besluit te neem om 'n produk in 'n aanlynwinkel te koop, moet die kliënt op die produkkaart weet wat die moontlikheid, koste, afleweringstyd aan sy stad is van hierdie produk (wat bereken word deur die algoritme gebaseer op die beskikbaarheid van die produk in pakhuise en voorsieningskettingparameters).
- Wanneer 'n frase in die soeklyn ingevoer word, word die kliënt soekvoorstelle gewys volgens die algoritme (wat deur die algoritme gegenereer word ...).
In totaal
Oor die algemeen, na die lees van die boek, is dit ongelukkig nie duidelik hoe om die hele pad van 'n ontleder tot besigheidsprobleme tot 'n geformaliseerde tegniese spesifikasie vir 'n ontwikkelaar te gaan nie. Die boek vertel slegs 'n deel van die proses, met die insetstappe onduidelik en die volgende stappe onduidelik. Die gebruiksgeval self is meestal nie 'n volledige verklaring vir die ontwikkelaar nie.
Dit is nietemin 'n baie goeie manier om scenario's van interaksie tussen 'n objek en 'n subjek te formaliseer en te verwerk, wanneer die interaksie 'n verandering in iets in die subjek veroorsaak. Dit is een van die min skryfmetodes wat verifieerbare vereistes toelaat met eksplisiete uitsonderingssoekpunte.
Die boek is 'n moet-lees vir ontleders om toetsbare toneelstukke te begin skryf.
Bron: will.com