Уг номонд асуудлын мэдэгдлийн хэсгийг бичих нэг аргыг, тухайлбал, хэрэглээний тохиолдлын аргыг тайлбарласан болно.
Энэ юу вэ? Энэ нь системтэй (эсвэл бизнестэй) хэрэглэгчийн харилцан үйлчлэлийн хувилбарын тайлбар юм. Энэ тохиолдолд систем нь хар хайрцагны үүрэг гүйцэтгэдэг (мөн энэ нь нарийн төвөгтэй дизайны ажлыг харилцан үйлчлэлийг зохион бүтээх, харилцан үйлчлэлийг хангахад хуваах боломжийг олгодог). Үүний зэрэгцээ тэмдэглэгээний стандартыг нэвтрүүлсэн бөгөөд энэ нь уншихад хялбар, үүнд оролцогч бус хүмүүст ч мөн адил, оролцогч талуудын зорилгод нийцэж байгаа эсэхийг шалгах боломжийг олгодог.
Кейсийн жишээг ашигла
Сайт дээрх зөвшөөрлийн жишээг ашиглан цахим шуудангаар ямар хувилбар харагдаж байна:
(Систем) Хувийн бүртгэлдээ хандахын тулд вэб сайтад нэвтэрнэ үү. ~~ (далайн түвшин)
Контекст: Зөвшөөрөлгүй үйлчлүүлэгч сайт руу нэвтэрч, сайт нь түүнийг таньж, түүнд зориулсан хувийн мэдээллийг харуулдаг: хайлтын түүх, худалдан авалтын түүх, одоогийн урамшууллын оноо гэх мэт, цахим шуудангаар нэвтрэх.
Түвшин: хэрэглэгчийн зорилго
Гол дүр: үйлчлүүлэгч (манай онлайн дэлгүүрийн зочин)
Хамрах хүрээ: Онлайн дэлгүүрийн вэбсайттай үйлчлүүлэгчтэй харилцах
Оролцогч талууд ба ашиг сонирхол:
- Маркетер нь хувийн шуудангаар илүү их мэдээлэл авахын тулд сайтад зочлогчдын хамгийн их тоог тодорхойлохыг хүсч байна.
- Аюулгүй байдлын мэргэжилтэн нь зочны хувийн мэдээлэлд зөвшөөрөлгүй нэвтрэх, тухайлбал нэг дансны нууц үгийг таах оролдлого, эсвэл сул нууц үгтэй данс хайх тохиолдол гарахгүй байхыг хүсч байна.
- халдагч хохирогчийн урамшуулалд нэвтрэхийг хүсч байгаа;
- өрсөлдөгчид бүтээгдэхүүний талаар сөрөг сэтгэгдэл үлдээхийг хүсдэг;
- Ботнет нь дэлгүүрийн үйлчлүүлэгчдийн баазыг олж авахыг хүсч, сайтыг ажиллахгүй болгохын тулд халдлага хийх болно.
Урьдчилсан нөхцөл: зочин зөвшөөрөлгүй байх ёстой.
Хамгийн бага баталгаа: зочин зөвшөөрлийн оролдлого амжилттай эсвэл амжилтгүй болсон эсэхийг мэдэх болно.
Амжилтын баталгаа: зочин зөвшөөрөлтэй.
Үндсэн хувилбар:
- Үйлчлүүлэгч зөвшөөрлийг эхлүүлнэ.
- Систем нь үйлчлүүлэгчийг зөвшөөрөлгүй гэдгийг баталж, "Аюулгүй байдлын дүрэм №23"-ын дагуу тухайн сессээс (олон дансны сул нууц үг хайх) амжилтгүй зөвшөөрлийн оролдлогын тооноос хэтрээгүй болно.
- Систем нь зөвшөөрлийн оролдлогын тоог нэмэгдүүлдэг.
- Систем нь зөвшөөрлийн маягтыг үйлчлүүлэгчид харуулдаг.
- Үйлчлүүлэгч имэйл болон нууц үгээ оруулна.
- Системд ийм цахим шуудантай үйлчлүүлэгч байгаа бөгөөд нууц үг таарч байгаа бөгөөд "Аюулгүй байдлын дүрэм 24"-ийн дагуу энэ данс руу нэвтрэх оролдлогын тоо хэтрээгүй болохыг систем баталж байна.
- Систем нь үйлчлүүлэгчийг зөвшөөрч, хайлтын түүх болон энэ сессийн сагсыг энэ хэрэглэгчийн дансны сүүлчийн сесстэй хамт нэмнэ.
- Систем нь зөвшөөрлийн амжилтын мессежийг харуулах ба үйлчлүүлэгчийн зөвшөөрөл авахаар тасалдсан скриптийн алхам руу шилжинэ. Энэ тохиолдолд хуудасны өгөгдлийг хувийн дансны өгөгдлийг харгалзан дахин ачаална.
Өргөтгөлүүд:
2.а. Үйлчлүүлэгч аль хэдийн зөвшөөрөл авсан байна:
2.a.1. Систем нь өмнө нь гүйцэтгэсэн зөвшөөрлийн талаар үйлчлүүлэгчид мэдэгдэж, скриптийг тасалдуулах эсвэл 4-р алхам руу шилжихийг санал болгодог бөгөөд хэрэв 6-р алхам амжилттай дууссан бол 7-р алхамыг тодруулж гүйцэтгэнэ.
2.а.7. Систем нь үйлчлүүлэгчийг хуучин дансны данснаас салгаж, шинэ дансаар үйлчлүүлэгчийг зөвшөөрч, энэ харилцан үйлчлэлийн сессийн хайлтын түүх, тэрэг нь хуучин дансанд үлдэж, шинэ данс руу шилжихгүй. Дараа нь 8-р алхам руу очно уу.
2.b “Аюулгүй байдлын дүрэм №23”-ын дагуу зөвшөөрөл олгох оролдлогын тоо босго хэмжээнээс хэтэрсэн:
2.b.1 4-р алхам руу оч, зөвшөөрлийн маягт дээр captcha нэмэлтээр гарч ирнэ
2.b.6 Систем нь зөв captcha оруулсныг баталгаажуулдаг
2.b.6.1 Captcha буруу оруулсан:
2.b.6.1.1. систем нь энэ дансны зөвшөөрлийн амжилтгүй оролдлогын тоологчийг мөн нэмэгдүүлдэг
2.b.6.1.2. систем нь бүтэлгүйтлийн мессежийг харуулж, 2-р алхам руу буцна
6.а. Энэ имэйлтэй бүртгэл олдсонгүй:
6.a.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 дээр хийдэг, гэхдээ ихэнх онлайн дэлгүүрт хийдэггүй).
Шаардлагатай өгөгдлийн хувиргалтанд хүрч байна
Та мөн өгөгдлийг хөрвүүлэх алгоритмд тавигдах шаардлагыг скриптээс гаргаж авах боломжтой.
жишээ нь:
- Онлайн дэлгүүрээс бүтээгдэхүүн худалдаж авах шийдвэр гаргахын тулд үйлчлүүлэгч нь бүтээгдэхүүний карт дээр энэ бүтээгдэхүүнийг өөрийн хотод хүргэх боломж, өртөг, хүргэх хугацааг мэдэх шаардлагатай (үүнийг тухайн бүтээгдэхүүний бэлэн байдалд үндэслэн алгоритмаар тооцдог). агуулах ба нийлүүлэлтийн сүлжээний параметрүүд).
- Хайлтын мөрөнд хэллэг оруулах үед үйлчлүүлэгчид алгоритмын дагуу хайлтын зөвлөмжийг харуулдаг (алгоритмоор үүсгэгддэг...).
Нийт
Ерөнхийдөө, номыг уншсаны дараа харамсалтай нь шинжээчээс бизнесийн асуудал, хөгжүүлэгчийн албан ёсны техникийн тодорхойлолт хүртэл яаж явах нь тодорхойгүй байна. Энэ номонд оруулах алхамууд нь тодорхойгүй, дараагийн алхмууд нь тодорхойгүй байгаа үйл явцын зөвхөн нэг хэсгийг л өгүүлдэг. Хэрэглээний тохиолдол нь ихэвчлэн хөгжүүлэгчийн хувьд бүрэн мэдэгдэл биш юм.
Гэсэн хэдий ч энэ нь харилцан үйлчлэл нь тухайн субьектэд ямар нэгэн өөрчлөлт гарахад объект ба субьект хоорондын харилцан үйлчлэлийн хувилбаруудыг боловсруулах, боловсруулах маш сайн арга юм. Энэ нь тодорхой үл хамаарах хайлтын цэгүүдээр баталгаажуулах шаардлагыг зөвшөөрдөг цөөн тооны бичих аргуудын нэг юм.
Энэ номыг шинжээчид туршиж үзэх боломжтой жүжиг бичиж эхлэхийн тулд заавал унших ёстой.
Эх сурвалж: www.habr.com