സിസ്റ്റങ്ങളുടെ പ്രവർത്തനപരമായ ആവശ്യകതകൾ വിവരിക്കുന്നതിനുള്ള ആധുനിക രീതികൾ. അലിസ്റ്റർ കോബേൺ. പുസ്തകത്തിന്റെ അവലോകനവും കൂട്ടിച്ചേർക്കലുകളും

ഒരു പ്രശ്ന പ്രസ്താവനയുടെ ഭാഗം എഴുതുന്നതിനുള്ള ഒരു രീതി പുസ്തകം വിവരിക്കുന്നു, അതായത് ഉപയോഗ കേസ് രീതി.

അത് എന്താണ്? ഇത് സിസ്റ്റവുമായുള്ള (അല്ലെങ്കിൽ ബിസിനസ്സുമായുള്ള) ഉപയോക്തൃ ഇടപെടലിന്റെ ഒരു വിവരണമാണ്. ഈ സാഹചര്യത്തിൽ, സിസ്റ്റം ഒരു ബ്ലാക്ക് ബോക്സായി പ്രവർത്തിക്കുന്നു (സങ്കീർണ്ണമായ ഡിസൈൻ ടാസ്ക്കിനെ ഇന്ററാക്ഷൻ രൂപകൽപ്പന ചെയ്യുന്നതിനും ഈ ഇടപെടൽ ഉറപ്പാക്കുന്നതിനും ഇത് സാധ്യമാക്കുന്നു). അതേ സമയം, നൊട്ടേഷൻ സ്റ്റാൻഡേർഡുകൾ അവതരിപ്പിക്കപ്പെടുന്നു, ഇത് പങ്കാളികളല്ലാത്തവർ ഉൾപ്പെടെയുള്ള വായനയുടെ അനായാസത ഉറപ്പാക്കുന്നു, കൂടാതെ പങ്കാളിയുടെ ലക്ഷ്യങ്ങളുമായി പൂർണ്ണതയ്ക്കും അനുസരണത്തിനും ചില പരിശോധനകൾ അനുവദിക്കുന്നു.

കേസ് ഉദാഹരണം ഉപയോഗിക്കുക

ഇമെയിൽ വഴി സൈറ്റിലെ അംഗീകാരത്തിന്റെ ഉദാഹരണം ഉപയോഗിച്ച്, സാഹചര്യം എങ്ങനെയിരിക്കും:

(സിസ്റ്റം) നിങ്ങളുടെ സ്വകാര്യ അക്കൗണ്ട് ആക്‌സസ് ചെയ്യാൻ വെബ്‌സൈറ്റിൽ ലോഗിൻ ചെയ്യുക. ~~ (സമുദ്രനിരപ്പ്)

സന്ദർഭം: ഒരു അനധികൃത ക്ലയന്റ് സൈറ്റിലേക്ക് ലോഗിൻ ചെയ്യുന്നു, അതുവഴി സൈറ്റ് അവനെ തിരിച്ചറിയുകയും അവനുവേണ്ടിയുള്ള വ്യക്തിഗത വിവരങ്ങൾ കാണിക്കുകയും ചെയ്യുന്നു: ബ്രൗസിംഗ് ചരിത്രം, വാങ്ങൽ ചരിത്രം, നിലവിലെ ബോണസ് പോയിന്റുകളുടെ എണ്ണം മുതലായവ., ഇമെയിൽ ഒരു ലോഗിൻ ആയി ഉപയോഗിക്കുന്നു. 
ലെവൽ: ഉപയോക്തൃ ലക്ഷ്യം
പ്രധാന കഥാപാത്രം: ക്ലയന്റ് (ഞങ്ങളുടെ ഓൺലൈൻ സ്റ്റോറിന്റെ സന്ദർശകൻ)
ഭാവിയുളള: ഓൺലൈൻ സ്റ്റോർ വെബ്‌സൈറ്റുമായുള്ള ക്ലയന്റ് ഇടപെടൽ
പങ്കാളികളും താൽപ്പര്യങ്ങളും:

• വ്യക്തിഗത മെയിലിംഗുകളുടെ കൂടുതൽ കവറേജിനായി പരമാവധി സൈറ്റ് സന്ദർശകരെ തിരിച്ചറിയണമെന്ന് മാർക്കറ്റർ ആഗ്രഹിക്കുന്നു,
• ഒരു അക്കൗണ്ടിന്റെ പാസ്‌വേഡ് ഊഹിക്കാനോ ദുർബലമായ പാസ്‌വേഡ് ഉള്ള അക്കൗണ്ടിനായി തിരയാനോ ഉള്ള ശ്രമങ്ങൾ ഉൾപ്പെടെ, സന്ദർശകന്റെ സ്വകാര്യ ഡാറ്റയിലേക്ക് അനധികൃത ആക്‌സസ് കേസുകൾ ഇല്ലെന്ന് ഉറപ്പാക്കാൻ സുരക്ഷാ വിദഗ്ധൻ ആഗ്രഹിക്കുന്നു.
• ആക്രമണകാരി ഇരയുടെ ബോണസുകളിലേക്ക് പ്രവേശനം നേടാൻ ആഗ്രഹിക്കുന്നു,
• ഉൽപ്പന്നങ്ങളിൽ നെഗറ്റീവ് അവലോകനങ്ങൾ നൽകാൻ എതിരാളികൾ ആഗ്രഹിക്കുന്നു,
• സ്റ്റോറിന്റെ ഉപഭോക്തൃ അടിത്തറ നേടാനും സൈറ്റ് പ്രവർത്തനരഹിതമാക്കാൻ ഒരു ആക്രമണം ഉപയോഗിക്കാനും ബോട്ട്നെറ്റ് ആഗ്രഹിക്കുന്നു.

മുൻവ്യവസ്ഥകൾ: സന്ദർശകന് അനുമതി നൽകരുത്.
കുറഞ്ഞ ഗ്യാരന്റി: അംഗീകാര ശ്രമം വിജയിച്ചോ പരാജയപ്പെട്ടോ എന്ന് സന്ദർശകന് അറിയാനാകും.
വിജയത്തിന്റെ ഉറപ്പുകൾ: സന്ദർശകന് അധികാരമുണ്ട്.

പ്രധാന രംഗം:

1. ക്ലയന്റ് അംഗീകാരം ആരംഭിക്കുന്നു.
2. "സെക്യൂരിറ്റി റൂൾ നമ്പർ 23" അനുസരിച്ച് ക്ലയന്റ് അംഗീകൃതമല്ലെന്നും തന്നിരിക്കുന്ന സെഷനിൽ (ഒന്നിലധികം അക്കൗണ്ടുകൾക്കുള്ള ദുർബലമായ പാസ്‌വേഡിനായി തിരയുന്നത്) പരാജയപ്പെട്ട അംഗീകാര ശ്രമങ്ങളുടെ എണ്ണം കവിയുന്നില്ലെന്നും സിസ്റ്റം സ്ഥിരീകരിക്കുന്നു.
3. സിസ്റ്റം അംഗീകാര ശ്രമങ്ങളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നു.
4. സിസ്റ്റം ക്ലയന്റിന് ഒരു അംഗീകാര ഫോം പ്രദർശിപ്പിക്കുന്നു.
5. ക്ലയന്റ് അവന്റെ ഇമെയിലും പാസ്‌വേഡും നൽകുന്നു.
6. സിസ്റ്റത്തിൽ അത്തരമൊരു ഇമെയിൽ ഉള്ള ഒരു ക്ലയന്റ് സാന്നിദ്ധ്യം സിസ്റ്റം സ്ഥിരീകരിക്കുന്നു, കൂടാതെ പാസ്‌വേഡ് പൊരുത്തപ്പെടുന്നതായും ഈ അക്കൗണ്ടിലേക്കുള്ള ലോഗിൻ ശ്രമങ്ങളുടെ എണ്ണം "സെക്യൂരിറ്റി റൂൾ നമ്പർ 24" അനുസരിച്ച് കവിയുന്നില്ലെന്നും സ്ഥിരീകരിക്കുന്നു.
7. ഈ ക്ലയന്റ് അക്കൗണ്ടിന്റെ അവസാന സെഷനിൽ ഈ സെഷന്റെ ബ്രൗസിംഗ് ചരിത്രവും ബാസ്‌ക്കറ്റും ചേർക്കുകയും ക്ലയന്റിനെ സിസ്റ്റം അംഗീകരിക്കുകയും ചെയ്യുന്നു.
8. സിസ്റ്റം ഒരു അംഗീകാര വിജയ സന്ദേശം പ്രദർശിപ്പിക്കുകയും ക്ലയന്റ് അംഗീകാരത്തിനായി തടസ്സപ്പെട്ട സ്ക്രിപ്റ്റ് ഘട്ടത്തിലേക്ക് നീങ്ങുകയും ചെയ്യുന്നു. ഈ സാഹചര്യത്തിൽ, വ്യക്തിഗത അക്കൗണ്ട് ഡാറ്റ കണക്കിലെടുത്ത് പേജിലെ ഡാറ്റ വീണ്ടും ലോഡുചെയ്യുന്നു.

വിപുലീകരണങ്ങൾ:
2.എ. ക്ലയന്റ് ഇതിനകം അംഗീകൃതമാണ്:
 2.a.1. മുമ്പ് നടപ്പിലാക്കിയ അംഗീകാരത്തിന്റെ വസ്തുതയെക്കുറിച്ച് സിസ്റ്റം ക്ലയന്റിനെ അറിയിക്കുകയും സ്ക്രിപ്റ്റ് തടസ്സപ്പെടുത്തുകയോ അല്ലെങ്കിൽ ഘട്ടം 4-ലേക്ക് പോകുകയോ ചെയ്യാമെന്ന് വാഗ്ദാനം ചെയ്യുന്നു, കൂടാതെ ഘട്ടം 6 വിജയകരമായി പൂർത്തിയാക്കിയാൽ, ഘട്ടം 7 വ്യക്തതയോടെ നടപ്പിലാക്കുന്നു:
 2.a.7. സിസ്റ്റം പഴയ അക്കൗണ്ടിന് കീഴിലുള്ള ക്ലയന്റിനെ ഡീക്റ്ററൈസ് ചെയ്യുന്നു, പുതിയ അക്കൗണ്ടിന് കീഴിലുള്ള ക്ലയന്റിനെ അംഗീകരിക്കുന്നു, അതേസമയം ഈ ഇന്ററാക്ഷൻ സെഷന്റെ ബ്രൗസിംഗ് ചരിത്രവും കാർട്ടും പഴയ അക്കൗണ്ടിൽ തന്നെ തുടരുകയും പുതിയതിലേക്ക് മാറ്റാതിരിക്കുകയും ചെയ്യുന്നു. അടുത്തതായി, ഘട്ടം 8-ലേക്ക് പോകുക.
2.b "സെക്യൂരിറ്റി റൂൾ നമ്പർ 23" അനുസരിച്ച് അംഗീകാര ശ്രമങ്ങളുടെ എണ്ണം പരിധി കവിഞ്ഞു:
 2.b.1 ഘട്ടം 4-ലേക്ക് പോകുക, അംഗീകാര ഫോമിൽ ഒരു ക്യാപ്‌ച അധികമായി പ്രദർശിപ്പിക്കും
 2.b.6 സിസ്റ്റം ശരിയായ ക്യാപ്‌ച എൻട്രി സ്ഥിരീകരിക്കുന്നു
    2.b.6.1 Captcha തെറ്റായി നൽകി:
      2.ബി.6.1.1. ഈ അക്കൌണ്ടിനും പരാജയപ്പെട്ട അംഗീകാര ശ്രമങ്ങളുടെ കൌണ്ടർ സിസ്റ്റം വർദ്ധിപ്പിക്കുന്നു
      2.ബി.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