La libro priskribas unu metodon por verki parton de problemo-deklaro, nome la uzkazan metodon.
Kio ĝi estas? Ĉi tio estas priskribo de la uzanta interagado kun la sistemo (aŭ kun la komerco). En ĉi tiu kazo, la sistemo agas kiel nigra skatolo (kaj tio ebligas dividi la kompleksan projektan taskon en dezajnado de interago kaj certigi ĉi tiun interagon). Samtempe oni enkondukas notajn normojn, kiuj certigas facilecon de legado, inkluzive por nepartoprenantoj, kaj ebligas iujn kontrolojn pri kompleteco kaj konformeco al la celoj de la koncernato.
Uzkaza ekzemplo
Kiel aspektas la scenaro, uzante la ekzemplon de rajtigo en la retejo per retpoŝto:
(Sistemo) Ensalutu al la retejo por aliri vian personan konton. ~~ (marnivelo)
Kunteksto: Neaŭtorizita kliento ensalutas al la retejo tiel ke la retejo rekonas lin kaj montras personajn informojn por li: foliumhistorio, aĉethistorio, aktuala nombro da bonus poentoj, ktp., uzante retpoŝton kiel ensaluton.
Nivelo: uzanta celo
Ĉeffiguro: kliento (vizitanto de nia reta butiko)
Amplekso: Klienta interago kun la retbutiko retejo
Koncernatoj kaj interesoj:
- la merkatisto volas, ke la maksimuma nombro da retejvizitantoj estu identigita por pli granda kovrado de personaj dissendoj,
- la sekureca specialisto volas certigi, ke ne ekzistas kazoj de neaŭtorizita aliro al la personaj datumoj de la vizitanto, inkluzive de provoj diveni la pasvorton por unu konto aŭ serĉi konton kun malforta pasvorto,
- la atakanto volas akiri aliron al la gratifikoj de la viktimo,
- konkurantoj volas lasi negativajn recenzojn pri produktoj,
- La botneto volas akiri la klientbazon de la vendejo kaj uzi atakon por igi la retejon nefunkciebla.
Antaŭkondiĉoj: la vizitanto ne devas esti rajtigita.
Minimumaj garantioj: la vizitanto scios ĉu la rajtigo provo estis sukcesa aŭ malsukcesa.
Garantioj de sukceso: la vizitanto estas rajtigita.
Ĉefa scenaro:
- La kliento iniciatas rajtigon.
- La sistemo konfirmas, ke la kliento ne estas rajtigita kaj ne superas la nombron da malsukcesaj rajtigaj provoj de donita sesio (serĉante malfortan pasvorton por pluraj kontoj) laŭ "Sekurec-Regulo No. 23".
- La sistemo pliigas la nombrilon por la nombro da rajtigaj provoj.
- La sistemo montras rajtigan formularon al la kliento.
- La kliento enigas sian retpoŝton kaj pasvorton.
- La sistemo konfirmas la ĉeeston de kliento kun tia retpoŝto en la sistemo kaj ke la pasvorto kongruas kaj la nombro da ensalutprovoj al ĉi tiu konto ne estas superita laŭ "Sekureca Regulo No. 24".
- La sistemo rajtigas la klienton, aldonas la foliumhistorion kaj la korbon de ĉi tiu sesio kun la lasta sesio de ĉi tiu klienta konto.
- La sistemo montras rajtigan sukcesmesaĝon kaj moviĝas al la skripto paŝo de kiu la kliento estis interrompita por rajtigo. En ĉi tiu kazo, la datumoj sur la paĝo estas reŝargitaj konsiderante la personajn kontajn datumojn.
Etendaĵoj:
2.a. La kliento jam estas rajtigita:
2.a.1. La sistemo sciigas la klienton pri la fakto de la antaŭe farita rajtigo kaj proponas aŭ interrompi la skripton aŭ iri al la paŝo 4, kaj se la paŝo 6 estas sukcese finita, tiam la paŝo 7 estas plenumita kun klarigo:
2.a.7. La sistemo deaktorigas la klienton sub la malnova konto, rajtigas la klienton sub la nova konto, dum la foliumhistorio kaj ĉaro de ĉi tiu interaga sesio restas en la malnova konto kaj ne translokiĝas al la nova. Poste, iru al paŝo 8.
2.b La nombro da rajtigaj provoj superis la sojlon laŭ "Sekureca Regulo n-ro 23":
2.b.1 Iru al la ŝtupo 4, kapĉa estas aldone montrata sur la rajtiga formularo
2.b.6 La sistemo konfirmas ĝustan kapĉan eniron
2.b.6.1 Captcha enmetita malĝuste:
2.b.6.1.1. la sistemo pliigas la nombrilon de malsukcesaj rajtigaj provoj ankaŭ por ĉi tiu konto
2.b.6.1.2. la sistemo montras malsukcesan mesaĝon kaj revenas al paŝo 2
6.a. Neniu konto kun ĉi tiu retpoŝto estis trovita:
6.a.1 La sistemo montras mesaĝon pri malsukceso kaj proponas elekton ĉu iri al la paŝo 2 aŭ iri al la scenaro "Registrado de Uzanto" kaj konservi la enigitan retpoŝton,
6.b. La pasvorto por la konto kun ĉi tiu retpoŝto ne kongruas kun tiu enigita:
6.b.1 La sistemo pliigas la nombrilon de malsukcesaj ensalutprovoj al ĉi tiu konto.
6.b.2 La sistemo montras mesaĝon pri malsukceso kaj proponas elekton ĉu iri al la scenaro "Pasvorta Reakiro" aŭ iri al paŝo 2.
6.c: La nombrilo de ensalutprovo por ĉi tiu konto superis la sojlon por "Sekureca Regulo n-ro 24."
6.c.1 La sistemo montras mesaĝon pri konta ensaluto blokado dum X minutoj kaj daŭrigas al paŝo 2.
Kio estas bonega
Kontroloj pri kompleteco kaj plenumo de celoj, tio estas, vi povas doni postulojn al alia analizisto por konfirmo, farante malpli da eraroj en la stadio de formulado de problemo.
Labori kun nigra skatolo sistemo permesas apartigi la disvolviĝon kaj kunordigon kun la kliento de tio, kio estos aŭtomatigita de la efektivigmetodoj.
Ĝi estas parto de la vojo de la analizisto, unu el la ĉefaj partoj de uzebleco. La scenaro de la uzanto difinas la ĉefajn vojojn de sia movado, kio multe reduktas la liberecon de elekto por la dezajnisto kaj la kliento kaj helpas pliigi la rapidecon de dizajno.
Mi tre ĝojas pri la loko en la priskribo, kie estas identigitaj esceptoj al ĉiu interaga paŝo. Kompleta IT-sistemo devas provizi ian esceptan uzadon, iuj permane, iuj aŭtomate (kiel en la supra ekzemplo).
Sperto montras, ke nepripensita esceptotraktado povas facile transformi sistemon en terure maloportunan sistemon. Mi memoras la historion, kiam en sovetia tempo, por ricevi decidon, vi devis ricevi plurajn aprobojn de diversaj servoj, kaj kiel dolorige estas kiam la lasta servo diras - sed via kandidatiĝo estas en malĝusta nomo aŭ iu alia eraro en interpunkcio, refari ĉion kaj re-kunordigi ĉion.
Mi ofte renkontas situaciojn, kie la operacia logiko de sistemo, kiu ne estis elpensita por esceptoj, postulis gravan reverkadon de la sistemo. Pro tio, la plej granda parto de la laboro de la analizisto estas elspezita por escepttraktado.
Tekstonotacio, kontraste al diagramoj, permesas pli da esceptoj esti identigitaj kaj kovritaj.
Aldono al la metodo de praktiko
La uzkazo ne estas sendepende prioritatita parto de la deklaro, male al la uzantrakonto.
En ĉi-supra scenaro, konsideru escepton “6.a. Neniu konto kun ĉi tiu retpoŝto estis trovita." kaj la sekva paŝo "6.a.1 La sistemo montras malsukcesan mesaĝon kaj daŭrigas al paŝo 2." Kio negativaj aferoj restis malantaŭ la scenoj? Por la kliento, ajna reveno egalas al tio, ke la tuta laboro, kiun li faris enigante datumojn, estas ĵetita en rubejon. (Ĝi simple ne videblas en la skripto!) Kion oni povas fari? Rekonstruu la skripton por ke tio ne okazu. Ĉu eblas fari ĉi tion? Vi povas - kiel ekzemplo, rigardi la Guglo-rajtigan skripton.
Optimumigo de scenaro
La libro parolas pri formaligo, sed malmulte diras pri metodoj por optimumigi tiajn scenarojn.
Sed eblas plifortigi la metodon per optimumigado de scenaroj, kaj la uzkaza formaliga metodo permesas tion fari. Specife, vi devas pensi pri ĉiu escepto kiu okazas, determini la kaŭzon kaj rekonstrui la skripton por forigi la escepton aŭ minimumigi la klientan vojaĝon.
Kiam vi faras mendon de reta butiko, vi devas eniri la liverurbon. Povas rezulti, ke la vendejo ne povas liveri varojn al la urbo elektita de la kliento ĉar ĝi ne liveras tie, pro grandeco limigoj, aŭ pro manko de varoj en la responda magazeno.
Se ni simple priskribas la scenaron de interago en la registra stadio, ni povas skribi "informu la klienton, ke livero estas neebla kaj proponi ŝanĝi la urbon aŭ la enhavon de la ĉaro" (kaj multaj novulaj analizistoj ĉesas tie). Sed se ekzistas multaj tiaj kazoj, tiam la scenaro povas esti optimumigita.
La unua afero, kiun vi devas fari, estas lasi vin elekti nur la urbon, kie ni povas liveri. Kiam fari ĉi tion? Antaŭ elekti produkton en la retejo (aŭtomata detekto de la urbo per IP kun klarigo).
Due, ni devas doni elekton nur de la varoj, kiujn ni povas liveri al la kliento. Kiam fari ĉi tion? En la momento de elekto - sur la produkta kahelo kaj produkta karto.
Ĉi tiuj du ŝanĝoj multe iras por forigi ĉi tiun escepton.
Postuloj por mezuradoj kaj metrikoj
Konsiderante la taskon minimumigi escepttraktadon, vi povas agordi raportan taskon (uzokazo ne estas priskribita). Kiom da esceptoj estis, en kiuj kazoj ili okazis, kaj kiom da envenantaj scenaroj sukcese pasis.
Sed ve. Sperto montris, ke raportaj postuloj por scenaroj en ĉi tiu formo ne sufiĉas; necesas konsideri raportajn postulojn por procezoj, kiuj estas priskribitaj ĉefe ne en la formo de uzkazo.
Aliro al Uzebleco
En nia praktiko, ni vastigis la uzkazan priskriban formularon kun priskribo de specifaj atributoj de estaĵoj kaj datumoj por ke la kliento prenu decidon, kio plibonigas postan uzeblecon.
Por uzebleco-dezajno, ni aldonis enigsekcion - montri datumojn.
En scenaro kun rajtigo, ĉi tio estas la fakto, ke la kliento estas rajtigita en la sistemo. Se la kliento estas antaŭrajtigita, tiam montru averton pri ŝanĝado de la navigada historio kaj ĉaro al la nova konto post sukcesa rajtigo.
Ĝenerale, ĉi tio estas montrado de la necesaj informoj por la kliento, por ke li povu fari decidon pri siaj pluaj agoj laŭ la scenaro (vi povas demandi ĉu ĉi tiuj datumoj sufiĉas por la kliento, kio alia necesas, kiaj informoj faras? la kliento bezonas fari decidojn).
Ankaŭ indas dividi la enigitajn informojn en enigkampojn, se ili estas prilaboritaj aparte kaj kun la formado de malsamaj esceptoj.
En la ekzemplo kun klienta rajtigo, se vi disigas la enigitajn informojn en ensaluton kaj pasvorton, tiam indas ŝanĝi la rajtigan skripton por reliefigi la etapojn de enigo de aparta ensaluto kaj aparta pasvorto (kaj ĉi tio estas farita en Yandex, Google, sed ne farita en la plej multaj retaj butikoj).
Atingante la postulatajn datumajn transformojn
Vi ankaŭ povas ĉerpi postulojn por datumkonvertaj algoritmoj el la skripto.
ekzemploj:
- Por preni decidon aĉeti produkton en reta butiko, la kliento devas scii sur la produktkarto la eblecon, koston, livertempon de ĉi tiu produkto al sia urbo (kiuj estas kalkulitaj per la algoritmo bazita sur la havebleco de la produkto en stokejoj kaj provizoĉenparametroj).
- Enmetante frazon en la serĉlinion, al la kliento montriĝas serĉsugestoj laŭ la algoritmo (kiuj estas generitaj de la algoritmo...).
Tuta
Ĝenerale, post legi la libron, bedaŭrinde ne estas klare kiel iri la tutan vojon de analizisto al komercaj problemoj ĝis formaligita teknika specifo por programisto. La libro rakontas nur parton de la procezo, kun la enigpaŝoj neklaraj kaj la sekvaj paŝoj neklaraj. La uzokazo mem plej ofte ne estas kompleta deklaro por la programisto.
Tamen, ĉi tio estas tre bona maniero por formaligi kaj prilabori scenarojn de interago inter objekto kaj subjekto, kiam la interago kaŭzas ŝanĝon en io en la subjekto. Ĝi estas unu el la malmultaj skribmetodoj, kiuj permesas kontroleblajn postulojn kun eksplicitaj esceptaj serĉpunktoj.
La libro estas nepre legita por analizistoj por komenci verki testeblajn teatraĵojn.
fonto: www.habr.com