Գիրքը նկարագրում է խնդրի դրույթի մի մասը գրելու մեթոդ, այն է՝ օգտագործման դեպքի մեթոդը:
Ինչ է դա? Սա համակարգի (կամ բիզնեսի հետ) օգտատերերի փոխազդեցության սցենարի նկարագրությունն է: Այս դեպքում համակարգը գործում է որպես սև արկղ (և դա հնարավորություն է տալիս նախագծման բարդ առաջադրանքը բաժանել փոխազդեցության նախագծման և այդ փոխազդեցության ապահովման): Միաժամանակ ներդրվում են նշագրման ստանդարտներ, որոնք ապահովում են ընթերցանության հեշտությունը, այդ թվում՝ չմասնակիցների համար, և թույլ են տալիս որոշակի ստուգումներ կատարել շահագրգիռ կողմի նպատակներին ամբողջականության և համապատասխանության համար:
Օգտագործեք դեպքի օրինակ
Ինչպիսի՞ն է սցենարը, օգտագործելով էլեկտրոնային փոստի միջոցով կայքում թույլտվության օրինակը.
(Համակարգ) Մուտք գործեք կայք՝ ձեր անձնական հաշիվ մուտք գործելու համար: ~~ (ծովի մակարդակ)
Համատեքստ: Չլիազորված հաճախորդը մուտք է գործում կայք, որպեսզի կայքը ճանաչի նրան և ցույց տա նրա անձնական տվյալները՝ զննման պատմություն, գնումների պատմություն, բոնուսային միավորների ընթացիկ քանակը և այլն՝ օգտագործելով էլ.
Level: օգտագործողի նպատակը
Գլխավոր հերոս: հաճախորդ (մեր առցանց խանութի այցելու)
Շրջանակ: Հաճախորդի փոխազդեցություն առցանց խանութի կայքի հետ
Շահագրգիռ կողմեր և շահեր.
- շուկայավարը ցանկանում է, որ հայտնաբերվի կայքի այցելուների առավելագույն թիվը՝ անձնական նամակագրությունների ավելի մեծ լուսաբանման համար,
- անվտանգության մասնագետը ցանկանում է ապահովել, որ այցելուի անձնական տվյալներին չարտոնված մուտքի դեպքեր չլինեն, ներառյալ մեկ հաշվի գաղտնաբառը գուշակելու կամ թույլ գաղտնաբառով հաշիվ որոնելու փորձեր,
- հարձակվողը ցանկանում է օգտվել զոհի բոնուսներից,
- մրցակիցները ցանկանում են բացասական ակնարկներ թողնել ապրանքների վերաբերյալ,
- Բոտնետը ցանկանում է ձեռք բերել խանութի հաճախորդների բազան և օգտագործել հարձակում՝ կայքը անգործունակ դարձնելու համար:
Նախապայմաններ. այցելուն չպետք է լիազորված լինի:
Նվազագույն երաշխիքներ. այցելուն կիմանա՝ արդյոք թույլտվության փորձը հաջող էր, թե անհաջող:
Հաջողության երաշխիքներ. այցելուն լիազորված է:
Հիմնական սցենար.
- Հաճախորդը նախաձեռնում է թույլտվություն:
- Համակարգը հաստատում է, որ հաճախորդը լիազորված չէ և չի գերազանցում տվյալ սեսիայից թույլտվության անհաջող փորձերի քանակը (բազմաթիվ հաշիվների համար թույլ գաղտնաբառի որոնում)՝ համաձայն «Անվտանգության կանոն թիվ 23»:
- Համակարգը մեծացնում է թույլտվության փորձերի քանակի հաշվիչը:
- Համակարգը հաճախորդին ցուցադրում է թույլտվության ձև:
- Հաճախորդը մուտքագրում է իր էլ.փոստը և գաղտնաբառը:
- Համակարգը հաստատում է նման նամակով հաճախորդի առկայությունը համակարգում, և որ գաղտնաբառը համընկնում է, և այս հաշիվ մուտք գործելու փորձերի քանակը չի գերազանցվում «Անվտանգության կանոն թիվ 24»-ի համաձայն:
- Համակարգը լիազորում է հաճախորդին, ավելացնում է զննարկման պատմությունը և այս նստաշրջանի զամբյուղը այս հաճախորդի հաշվի վերջին նստաշրջանի հետ:
- Համակարգը ցուցադրում է թույլտվության հաջողության հաղորդագրություն և տեղափոխվում է սցենարի այն քայլը, որտեղից հաճախորդն ընդհատվել է թույլտվության համար: Այս դեպքում էջի տվյալները վերաբեռնվում են՝ հաշվի առնելով անձնական հաշվի տվյալները։
Ընդլայնումներ:
2.ա. Հաճախորդն արդեն լիազորված է՝
2.ա.1. Համակարգը հաճախորդին ծանուցում է նախկինում կատարված թույլտվության փաստի մասին և առաջարկում կամ ընդհատել սկրիպտը կամ գնալ 4-րդ քայլին, իսկ եթե 6-րդ քայլը հաջողությամբ ավարտված է, ապա 7-րդ քայլը կատարվում է պարզաբանմամբ.
2.ա.7. Համակարգը ապաակտորացնում է հաճախորդին հին հաշվի տակ, լիազորում է հաճախորդին նոր հաշվի ներքո, մինչդեռ այս փոխազդեցության սեսիայի զննարկման պատմությունը և զամբյուղը մնում են հին հաշվում և չեն փոխանցվում նորին: Հաջորդը, անցեք 8-րդ քայլին:
2.բ Թույլտվության փորձերի թիվը գերազանցել է «Անվտանգության կանոն թիվ 23»-ի համաձայն սահմանված շեմը.
2.b.1 Անցեք 4-րդ քայլին, captcha-ն լրացուցիչ ցուցադրվում է թույլտվության ձևաթղթում
2.b.6 Համակարգը հաստատում է captcha-ի ճիշտ մուտքագրումը
2.b.6.1 Captcha-ն սխալ է մուտքագրվել.
2.բ.6.1.1. Համակարգը մեծացնում է նաև այս հաշվի անհաջող թույլտվության փորձերի հաշվիչը
2.բ.6.1.2. համակարգը ցուցադրում է ձախողման հաղորդագրություն և վերադառնում է 2-րդ քայլին
6.ա. Այս էլփոստով հաշիվ չի գտնվել՝
6.ա.1 Համակարգը ցուցադրում է հաղորդագրություն ձախողման մասին և առաջարկում է ընտրություն գնալ կամ գնալ 2-րդ քայլին կամ գնալ «Օգտատիրոջ գրանցում» սցենարին և պահպանել մուտքագրված էլ.
6.բ. Այս էլփոստով հաշվի գաղտնաբառը չի համընկնում մուտքագրվածի հետ.
6.b.1 Համակարգը մեծացնում է այս հաշվի անհաջող մուտքի փորձերի հաշվիչը:
6.b.2 Համակարգը ցուցադրում է հաղորդագրություն ձախողման մասին և առաջարկում է ընտրություն՝ գնալ «Գաղտնաբառի վերականգնում» սցենարին կամ գնալ 2-րդ քայլին:
6.c․ այս հաշվի մուտքի փորձի հաշվիչը գերազանցել է «Անվտանգության կանոն թիվ 24» սահմանաչափը։
6.c.1 Համակարգը ցուցադրում է հաղորդագրություն հաշիվ մուտքի X րոպեով արգելափակման մասին և անցնում է 2-րդ քայլին:
Ինչ հիանալի է
Ստուգումներ ամբողջականության և նպատակներին համապատասխանության համար, այսինքն՝ դուք կարող եք պահանջներ տալ մեկ այլ վերլուծաբանի ստուգման համար՝ ավելի քիչ սխալներ թույլ տալով խնդրի ձևակերպման փուլում:
«Սև արկղ» համակարգի հետ աշխատելը թույլ է տալիս առանձնացնել ավտոմատացվածի մշակումն ու համակարգումը պատվիրատուի հետ իրականացման մեթոդներից:
Դա վերլուծաբանի ուղու մի մասն է, օգտագործելիության հիմնական մասերից մեկը։ Օգտագործողի սցենարը սահմանում է նրա շարժման հիմնական ուղիները, ինչը մեծապես նվազեցնում է դիզայների և հաճախորդի ընտրության ազատությունը և օգնում է բարձրացնել դիզայնի մշակման արագությունը։
Ես շատ գոհ եմ նկարագրության այն տեղից, որտեղ բացառություններ են հայտնաբերվել փոխգործակցության յուրաքանչյուր քայլից: Ամբողջական ՏՏ համակարգը պետք է նախատեսի որոշակի բացառությունների մշակում, որոշները ձեռքով, որոշները՝ ավտոմատ (ինչպես վերը նշված օրինակում):
Փորձը ցույց է տալիս, որ չմտածված բացառությունները հեշտությամբ կարող են համակարգը վերածել սարսափելի անհարմար համակարգի: Հիշում եմ պատմությունը, երբ խորհրդային տարիներին որոշում ստանալու համար պետք է տարբեր ծառայություններից մի քանի հավանություն ստանայիք, և որքան ցավալի է, երբ վերջին ծառայությունն ասում է, բայց ձեր դիմումը սխալ անունով է կամ այլ սխալ. կետադրական նշաններ, ամեն ինչ նորից կրկնիր և ամեն ինչ նորից համակարգիր:
Ես հաճախ հանդիպում եմ իրավիճակների, երբ բացառությունների համար չմտածված համակարգի գործառնական տրամաբանությունը պահանջում էր համակարգի զգալի վերամշակում: Դրա պատճառով վերլուծաբանի աշխատանքի առյուծի բաժինը ծախսվում է բացառությունների բեռնաթափման վրա։
Տեքստի նշումը, ի տարբերություն գծապատկերների, թույլ է տալիս ավելի շատ բացառություններ բացահայտել և լուսաբանել:
Մեթոդի լրացում պրակտիկայից
Օգտագործման դեպքը հայտարարության ինքնուրույն առաջնահերթություն ունեցող մաս չէ, ի տարբերություն օգտվողի պատմության:
Վերոնշյալ սցենարում հաշվի առեք բացառություն «6.a. Այս էլփոստով հաշիվ չի գտնվել»: և հաջորդ քայլը «6.a.1 Համակարգը ցուցադրում է ձախողման հաղորդագրություն և անցնում 2-րդ քայլին»: Ի՞նչ բացասական բաներ են մնացել կուլիսներում։ Հաճախորդի համար ցանկացած վերադարձ հավասարազոր է նրան, որ տվյալներ մուտքագրելու ամբողջ աշխատանքը նետվում է աղբավայր: (Դա պարզապես չի երևում սցենարում:) Ի՞նչ կարելի է անել: Վերակառուցեք սցենարը, որպեսզի դա տեղի չունենա: Հնարավո՞ր է դա անել: Դուք կարող եք, որպես օրինակ, դիտել Google-ի թույլտվության սցենարը:
Սցենարների օպտիմալացում
Գրքում խոսվում է պաշտոնականացման մասին, բայց քիչ բան է ասում նման սցենարների օպտիմալացման մեթոդների մասին:
Բայց հնարավոր է ամրապնդել մեթոդը սցենարների օպտիմալացման միջոցով, և օգտագործման դեպքերի պաշտոնականացման մեթոդը թույլ է տալիս դա անել: Մասնավորապես, դուք պետք է մտածեք յուրաքանչյուր բացառության մասին, որը տեղի է ունենում, որոշեք պատճառը և վերակառուցեք սցենարը, որպեսզի ձերբազատվեք բացառությունից կամ նվազագույնի հասցնեք հաճախորդի ճանապարհորդությունը:
Առցանց խանութից պատվեր կատարելիս պետք է մուտքագրեք առաքման քաղաքը: Կարող է պարզվել, որ խանութը չի կարող ապրանք առաքել հաճախորդի ընտրած քաղաք, քանի որ չի առաքում այնտեղ՝ չափերի սահմանափակման կամ համապատասխան պահեստում ապրանքի բացակայության պատճառով։
Եթե մենք պարզապես նկարագրենք գրանցման փուլում փոխազդեցության սցենարը, կարող ենք գրել «հաճախորդին տեղեկացնել, որ առաքումն անհնար է և առաջարկել փոխել քաղաքը կամ զամբյուղի պարունակությունը» (և շատ սկսնակ վերլուծաբաններ կանգ են առնում այնտեղ): Բայց եթե նման դեպքերը շատ են, ապա սցենարը կարելի է օպտիմալացնել։
Առաջին բանը, որ դուք պետք է անեք, թույլ տվեք ընտրել միայն այն քաղաքը, որտեղ մենք կարող ենք առաքել: Ե՞րբ անել դա: Կայքում ապրանք ընտրելուց առաջ (քաղաքի ինքնորոշում IP-ի միջոցով՝ պարզաբանումներով):
Երկրորդ, մենք պետք է ընտրություն տանք միայն այն ապրանքներից, որոնք մենք կարող ենք առաքել հաճախորդին: Ե՞րբ անել դա: Ընտրության պահին՝ ապրանքի սալիկի և ապրանքի քարտի վրա։
Այս երկու փոփոխությունները մեծ ճանապարհ են կազմում այս բացառությունը վերացնելու համար:
Չափումների և չափումների պահանջներ
Բացառությունների մշակումը նվազագույնի հասցնելու առաջադրանքը դիտարկելիս կարող եք սահմանել հաշվետվության առաջադրանք (օգտագործման դեպքը նկարագրված չէ): Քանի բացառություններ են եղել, ինչ դեպքերում են դրանք եղել, գումարած, թե քանի մուտքային սցենար է անցել հաջողությամբ:
Բայց ավաղ. Փորձը ցույց է տվել, որ այս ձևով սցենարների համար հաշվետվության պահանջները բավարար չեն, անհրաժեշտ է դիտարկել այն գործընթացների հաշվետվությունների պահանջները, որոնք նկարագրված են հիմնականում ոչ օգտագործման դեպքի տեսքով:
Օգտագործելիության հասանելիություն
Մեր պրակտիկայում մենք ընդլայնել ենք օգտագործման դեպքերի նկարագրության ձևը` պատվիրատուի կողմից որոշում կայացնելու համար սուբյեկտների հատուկ ատրիբուտների և տվյալների նկարագրությամբ, ինչը մեծացնում է հետագա օգտագործելիությունը:
Օգտագործելիության նախագծման համար մենք ավելացրել ենք մուտքային բաժին՝ ցուցադրման տվյալները:
Թույլտվություն ունեցող սցենարի դեպքում սա այն փաստն է, որ հաճախորդը լիազորված է համակարգում: Եթե հաճախորդը նախապես լիազորված է, ապա ցուցադրեք նախազգուշացում՝ հաջող թույլտվությունից հետո նավիգացիայի պատմությունը և զամբյուղը նոր հաշվին անցնելու մասին:
Ընդհանուր առմամբ, սա հաճախորդի համար անհրաժեշտ տեղեկատվության ցուցադրումն է, որպեսզի նա կարողանա որոշում կայացնել իր հետագա գործողությունների վերաբերյալ ըստ սցենարի (կարող եք հարցնել, թե արդյոք այս տվյալները բավարար են հաճախորդի համար, էլ ինչ է անհրաժեշտ, ինչ տեղեկատվություն է հաճախորդը պետք է որոշումներ կայացնի):
Արժե նաև մուտքագրված տեղեկատվությունը բաժանել մուտքագրման դաշտերի, եթե դրանք մշակվեն առանձին և տարբեր բացառություններով:
Հաճախորդի թույլտվության օրինակում, եթե մուտքագրված տեղեկատվությունը առանձնացնում եք մուտքի և գաղտնաբառի մեջ, ապա արժե փոխել թույլտվության սցենարը, որպեսզի առանձնացնեք առանձին մուտք և առանձին գաղտնաբառ մուտքագրելու փուլերը (և դա արվում է Yandex-ում, Google-ում, բայց չի արվում առցանց խանութների մեծ մասում):
Պահանջվող տվյալների վերափոխումների հասնելը
Կարող եք նաև սկրիպտից հանել տվյալների փոխակերպման ալգորիթմների պահանջները:
Օրինակներ
- Ինտերնետ խանութում ապրանք գնելու որոշում կայացնելու համար հաճախորդը պետք է ապրանքի քարտի վրա իմանա այս ապրանքի իր քաղաք առաքման հնարավորությունը, արժեքը, ժամանակը (որոնք հաշվարկվում են ալգորիթմի միջոցով՝ հիմնվելով ապրանքի առկայության վրա. պահեստներ և մատակարարման շղթայի պարամետրեր):
- Որոնման տողում արտահայտություն մուտքագրելիս հաճախորդին ցուցադրվում են որոնման առաջարկներ ըստ ալգորիթմի (որոնք ստեղծվում են ալգորիթմի կողմից...):
Ընդհանուր
Ընդհանուր առմամբ, գիրքը կարդալուց հետո, ցավոք, պարզ չէ, թե ինչպես կարելի է հասնել վերլուծաբանից մինչև բիզնես խնդիրներ մինչև ծրագրավորողի համար պաշտոնական տեխնիկական բնութագրում: Գիրքը պատմում է գործընթացի միայն մի մասը՝ մուտքային քայլերն անհասկանալի են, իսկ հաջորդ քայլերը՝ անհասկանալի: Օգտագործման դեպքն ինքնին ամենից հաճախ մշակողի համար ամբողջական հայտարարություն չէ:
Այնուամենայնիվ, սա շատ լավ միջոց է օբյեկտի և սուբյեկտի փոխազդեցության սցենարները պաշտոնականացնելու և մշակելու համար, երբ փոխազդեցությունը առարկայի մեջ ինչ-որ բանի փոփոխություն է առաջացնում: Այն գրելու այն քիչ մեթոդներից մեկն է, որը թույլ է տալիս ստուգելի պահանջներ՝ բացահայտ բացառությունների որոնման կետերով:
Գիրքը պարտադիր ընթերցանություն է, որպեսզի վերլուծաբանները սկսեն գրել ստուգելի պիեսներ:
Source: www.habr.com