पुस्तक किसी समस्या कथन के भाग को लिखने के लिए एक विधि का वर्णन करती है, अर्थात् उपयोग केस विधि।
यह क्या है? यह सिस्टम (या व्यवसाय के साथ) के साथ उपयोगकर्ता इंटरैक्शन परिदृश्य का विवरण है। इस मामले में, सिस्टम एक ब्लैक बॉक्स के रूप में कार्य करता है (और इससे जटिल डिज़ाइन कार्य को डिज़ाइनिंग इंटरैक्शन में विभाजित करना और इस इंटरैक्शन को सुनिश्चित करना संभव हो जाता है)। साथ ही, अंकन मानकों को पेश किया गया है, जो गैर-प्रतिभागियों सहित पढ़ने में आसानी सुनिश्चित करता है, और हितधारक के लक्ष्यों के साथ पूर्णता और अनुपालन के लिए कुछ जांच की अनुमति देता है।
केस उदाहरण का प्रयोग करें
ईमेल के माध्यम से साइट पर प्राधिकरण के उदाहरण का उपयोग करके परिदृश्य कैसा दिखता है:
(सिस्टम) अपने व्यक्तिगत खाते तक पहुंचने के लिए वेबसाइट पर लॉग इन करें। ~~ (समुद्र तल)
प्रसंग: एक अनधिकृत ग्राहक साइट पर लॉग इन करता है ताकि साइट उसे पहचान ले और उसके लिए व्यक्तिगत जानकारी दिखाए: ब्राउज़िंग इतिहास, खरीद इतिहास, बोनस अंकों की वर्तमान संख्या, आदि, लॉगिन के रूप में ईमेल का उपयोग करके।
का स्तर: उपयोगकर्ता लक्ष्य
मुख्य चरित्र: ग्राहक (हमारे ऑनलाइन स्टोर का आगंतुक)
दायरा: ऑनलाइन स्टोर वेबसाइट के साथ ग्राहक की बातचीत
हितधारक और हित:
- विपणक चाहता है कि व्यक्तिगत मेलिंग के अधिक कवरेज के लिए साइट आगंतुकों की अधिकतम संख्या की पहचान की जाए,
- सुरक्षा विशेषज्ञ यह सुनिश्चित करना चाहता है कि विज़िटर के व्यक्तिगत डेटा तक अनधिकृत पहुंच का कोई मामला न हो, जिसमें एक खाते के लिए पासवर्ड का अनुमान लगाने या कमजोर पासवर्ड वाले खाते की खोज करने का प्रयास शामिल है,
- हमलावर पीड़ित के बोनस तक पहुंच प्राप्त करना चाहता है,
- प्रतिस्पर्धी उत्पादों पर नकारात्मक समीक्षा छोड़ना चाहते हैं,
- बॉटनेट स्टोर का ग्राहक आधार प्राप्त करना चाहता है और साइट को निष्क्रिय करने के लिए हमले का उपयोग करना चाहता है।
पूर्व शर्ते: आगंतुक अधिकृत नहीं होना चाहिए.
न्यूनतम गारंटी: आगंतुक को पता चल जाएगा कि प्राधिकरण का प्रयास सफल था या असफल।
सफलता की गारंटी: आगंतुक अधिकृत है.
मुख्य परिदृश्य:
- ग्राहक प्राधिकरण आरंभ करता है।
- सिस्टम पुष्टि करता है कि ग्राहक अधिकृत नहीं है और "सुरक्षा नियम संख्या 23" के अनुसार किसी दिए गए सत्र (एकाधिक खातों के लिए कमजोर पासवर्ड की खोज) से असफल प्राधिकरण प्रयासों की संख्या से अधिक नहीं है।
- सिस्टम प्राधिकरण प्रयासों की संख्या के लिए काउंटर बढ़ाता है।
- सिस्टम क्लाइंट को एक प्राधिकरण फॉर्म प्रदर्शित करता है।
- ग्राहक अपना ईमेल और पासवर्ड दर्ज करता है।
- सिस्टम सिस्टम में ऐसे ईमेल वाले क्लाइंट की उपस्थिति की पुष्टि करता है और पासवर्ड मेल खाता है और इस खाते में लॉगिन प्रयासों की संख्या "सुरक्षा नियम संख्या 24" के अनुसार अधिक नहीं है।
- सिस्टम क्लाइंट को अधिकृत करता है, इस क्लाइंट खाते के अंतिम सत्र के साथ इस सत्र का ब्राउज़िंग इतिहास और बास्केट जोड़ता है।
- सिस्टम एक प्राधिकरण सफलता संदेश प्रदर्शित करता है और स्क्रिप्ट चरण पर चला जाता है जहां से क्लाइंट को प्राधिकरण के लिए बाधित किया गया था। इस मामले में, व्यक्तिगत खाता डेटा को ध्यान में रखते हुए पृष्ठ पर डेटा पुनः लोड किया जाता है।
एक्सटेंशन:
2.ए. ग्राहक पहले से ही अधिकृत है:
2.अ.1. सिस्टम क्लाइंट को पहले निष्पादित प्राधिकरण के तथ्य के बारे में सूचित करता है और या तो स्क्रिप्ट को बाधित करने या चरण 4 पर जाने की पेशकश करता है, और यदि चरण 6 सफलतापूर्वक पूरा हो जाता है, तो चरण 7 स्पष्टीकरण के साथ किया जाता है:
2.अ.7. सिस्टम पुराने खाते के तहत क्लाइंट को निष्क्रिय कर देता है, नए खाते के तहत क्लाइंट को अधिकृत करता है, जबकि इस इंटरैक्शन सत्र का ब्राउज़िंग इतिहास और कार्ट पुराने खाते में रहता है और नए खाते में स्थानांतरित नहीं होता है। इसके बाद चरण 8 पर जाएं।
2.बी प्राधिकरण प्रयासों की संख्या "सुरक्षा नियम संख्या 23" के अनुसार सीमा से अधिक हो गई है:
2.बी.1 चरण 4 पर जाएं, प्राधिकरण फॉर्म पर एक कैप्चा अतिरिक्त रूप से प्रदर्शित होता है
2.बी.6 सिस्टम सही कैप्चा प्रविष्टि की पुष्टि करता है
2.बी.6.1 कैप्चा गलत दर्ज किया गया:
2.बी.6.1.1. सिस्टम इस खाते के लिए असफल प्राधिकरण प्रयासों का काउंटर भी बढ़ा देता है
2.बी.6.1.2. सिस्टम एक विफलता संदेश प्रदर्शित करता है और चरण 2 पर लौटता है
6.ए. इस ईमेल वाला कोई खाता नहीं मिला:
6.ए.1 सिस्टम विफलता के बारे में एक संदेश प्रदर्शित करता है और या तो चरण 2 पर जाने या "उपयोगकर्ता पंजीकरण" परिदृश्य पर जाने और दर्ज किए गए ईमेल को सहेजने का विकल्प प्रदान करता है,
6.बी. इस ईमेल वाले खाते का पासवर्ड दर्ज किए गए पासवर्ड से मेल नहीं खाता:
6.बी.1 सिस्टम इस खाते में असफल लॉगिन प्रयासों का काउंटर बढ़ा देता है।
6.बी.2 सिस्टम विफलता के बारे में एक संदेश प्रदर्शित करता है और "पासवर्ड पुनर्प्राप्ति" परिदृश्य पर जाने या चरण 2 पर जाने का विकल्प प्रदान करता है।
6.सी: इस खाते के लिए लॉगिन प्रयास काउंटर "सुरक्षा नियम संख्या 24" की सीमा को पार कर गया है।
6.सी.1 सिस्टम एक्स मिनट के लिए खाता लॉगिन ब्लॉक करने के बारे में एक संदेश प्रदर्शित करता है और चरण 2 पर आगे बढ़ता है।
क्या बढ़िया है
लक्ष्यों की पूर्णता और अनुपालन की जाँच करता है, अर्थात, आप सत्यापन के लिए किसी अन्य विश्लेषक को आवश्यकताएँ दे सकते हैं, जिससे समस्या निर्माण के चरण में कम गलतियाँ हो सकती हैं।
ब्लैक बॉक्स सिस्टम के साथ काम करने से आप कार्यान्वयन विधियों से स्वचालित होने वाले विकास और ग्राहक के साथ समन्वय को अलग कर सकते हैं।
यह विश्लेषक के पथ का हिस्सा है, प्रयोज्यता के मुख्य भागों में से एक है। उपयोगकर्ता का परिदृश्य उसके आंदोलन के मुख्य मार्गों को परिभाषित करता है, जो डिजाइनर और ग्राहक के लिए पसंद की स्वतंत्रता को काफी कम कर देता है और डिजाइन विकास की गति को बढ़ाने में मदद करता है।
मैं विवरण में उस स्थान से बहुत प्रसन्न हूं जहां प्रत्येक इंटरैक्शन चरण के अपवादों की पहचान की गई है। एक संपूर्ण आईटी प्रणाली को कुछ प्रकार के अपवाद प्रबंधन की व्यवस्था करनी चाहिए, कुछ मैन्युअल रूप से, कुछ स्वचालित रूप से (जैसा कि ऊपर दिए गए उदाहरण में है)।
अनुभव से पता चलता है कि बिना सोचे-समझे अपवाद प्रबंधन आसानी से एक सिस्टम को बेहद असुविधाजनक सिस्टम में बदल सकता है। मुझे वह कहानी याद है जब सोवियत काल में, निर्णय लेने के लिए, आपको विभिन्न सेवाओं से कई अनुमोदन प्राप्त करने पड़ते थे, और यह कितना दर्दनाक होता है जब अंतिम सेवा कहती है - लेकिन आपका आवेदन गलत नाम पर है या कोई अन्य गलती है विराम चिह्न, सब कुछ फिर से करें और सब कुछ फिर से समन्वयित करें।
मैं अक्सर ऐसी स्थितियों में आता हूं जहां किसी सिस्टम के ऑपरेटिंग लॉजिक, जिसे अपवादों के रूप में नहीं सोचा गया था, को सिस्टम के महत्वपूर्ण पुन: कार्य की आवश्यकता होती है। इस वजह से, विश्लेषक के काम का बड़ा हिस्सा अपवाद प्रबंधन पर खर्च होता है।
आरेखों के विपरीत पाठ संकेतन, अधिक अपवादों को पहचानने और कवर करने की अनुमति देता है।
अभ्यास से विधि का जोड़
उपयोगकर्ता की कहानी के विपरीत, उपयोग का मामला कथन का स्वतंत्र रूप से प्राथमिकता वाला हिस्सा नहीं है।
उपरोक्त परिदृश्य में, अपवाद "6.ए" पर विचार करें। इस ईमेल वाला कोई खाता नहीं मिला।” और अगला चरण "6.ए.1 सिस्टम एक विफलता संदेश प्रदर्शित करता है और चरण 2 पर आगे बढ़ता है।" कौन सी नकारात्मक बातें पर्दे के पीछे रह गईं? ग्राहक के लिए, कोई भी रिटर्न इस तथ्य के समान है कि डेटा दर्ज करने में उसने जो भी काम किया था, उसे लैंडफिल में फेंक दिया गया है। (यह स्क्रिप्ट में दिखाई नहीं दे रहा है!) क्या किया जा सकता है? स्क्रिप्ट का पुनर्निर्माण करें ताकि ऐसा न हो। क्या इसे करना संभव है? उदाहरण के तौर पर आप Google प्राधिकरण स्क्रिप्ट को देख सकते हैं।
परिदृश्य अनुकूलन
पुस्तक औपचारिकता के बारे में बात करती है, लेकिन ऐसे परिदृश्यों को अनुकूलित करने के तरीकों के बारे में बहुत कम कहती है।
लेकिन परिदृश्यों को अनुकूलित करके विधि को मजबूत करना संभव है, और उपयोग केस औपचारिकीकरण विधि ऐसा करने की अनुमति देती है। विशेष रूप से, आपको होने वाले प्रत्येक अपवाद के बारे में सोचने, कारण निर्धारित करने और स्क्रिप्ट को फिर से बनाने की आवश्यकता है ताकि अपवाद से छुटकारा पाया जा सके या ग्राहक यात्रा को कम किया जा सके।
किसी ऑनलाइन स्टोर से ऑर्डर देते समय, आपको डिलीवरी शहर दर्ज करना होगा। ऐसा हो सकता है कि स्टोर ग्राहक द्वारा चुने गए शहर में सामान वितरित नहीं कर सकता क्योंकि वह आकार प्रतिबंधों के कारण, या संबंधित गोदाम में सामान की कमी के कारण वहां सामान वितरित नहीं करता है।
यदि हम केवल पंजीकरण चरण में बातचीत के परिदृश्य का वर्णन करते हैं, तो हम लिख सकते हैं "ग्राहक को सूचित करें कि डिलीवरी असंभव है और शहर या कार्ट की सामग्री को बदलने की पेशकश करें" (और कई नौसिखिए विश्लेषक यहीं रुक जाते हैं)। लेकिन अगर ऐसे बहुत सारे मामले हैं, तो परिदृश्य को अनुकूलित किया जा सकता है।
पहली चीज़ जो आपको करने की ज़रूरत है वह यह है कि आप केवल वही शहर चुनें जहाँ हम डिलीवरी कर सकते हैं। यह कब करना है? वेबसाइट पर किसी उत्पाद का चयन करने से पहले (स्पष्टीकरण के साथ आईपी के माध्यम से शहर का स्वत: पता लगाना)।
दूसरे, हमें केवल उन्हीं सामानों का विकल्प देना होगा जिन्हें हम ग्राहक तक पहुंचा सकते हैं। यह कब करना है? चयन के समय - उत्पाद टाइल और उत्पाद कार्ड पर।
ये दो परिवर्तन इस अपवाद को दूर करने में काफी मदद करते हैं।
माप और मेट्रिक्स के लिए आवश्यकताएँ
अपवाद प्रबंधन को कम करने के कार्य पर विचार करते समय, आप एक रिपोर्टिंग कार्य निर्धारित कर सकते हैं (उपयोग का मामला वर्णित नहीं है)। कितने अपवाद थे, वे किन मामलों में घटित हुए, साथ ही कितने आने वाले परिदृश्य सफलतापूर्वक पारित हुए।
लेकिन अफसोस। अनुभव से पता चला है कि इस फॉर्म में परिदृश्यों के लिए रिपोर्टिंग आवश्यकताएं पर्याप्त नहीं हैं; उन प्रक्रियाओं के लिए रिपोर्टिंग आवश्यकताओं पर विचार करना आवश्यक है जिन्हें मुख्य रूप से उपयोग के मामले के रूप में वर्णित नहीं किया गया है।
प्रयोज्यता तक पहुंच
हमारे अभ्यास में, हमने ग्राहक को निर्णय लेने के लिए संस्थाओं और डेटा की विशिष्ट विशेषताओं के विवरण के साथ उपयोग केस विवरण फॉर्म का विस्तार किया है, जो बाद में प्रयोज्य को बढ़ाता है।
प्रयोज्य डिज़ाइन के लिए, हमने एक इनपुट अनुभाग जोड़ा - डेटा प्रदर्शित करें।
प्राधिकरण वाले परिदृश्य में, यह तथ्य है कि क्लाइंट सिस्टम में अधिकृत है। यदि क्लाइंट पूर्व-अधिकृत है, तो सफल प्राधिकरण के बाद नेविगेशन इतिहास और कार्ट को नए खाते में बदलने के बारे में चेतावनी प्रदर्शित करें।
सामान्य तौर पर, यह ग्राहक के लिए आवश्यक जानकारी का प्रदर्शन है ताकि वह परिदृश्य के अनुसार अपने आगे के कार्यों के बारे में निर्णय ले सके (आप पूछ सकते हैं कि क्या यह डेटा ग्राहक के लिए पर्याप्त है, और क्या चाहिए, कौन सी जानकारी काम आती है) ग्राहक को निर्णय लेने की आवश्यकता है)।
दर्ज की गई जानकारी को इनपुट फ़ील्ड में विभाजित करना भी उचित है यदि उन्हें अलग से संसाधित किया जाता है और विभिन्न अपवादों के गठन के साथ।
क्लाइंट प्राधिकरण के उदाहरण में, यदि आप दर्ज की गई जानकारी को लॉगिन और पासवर्ड में अलग करते हैं, तो एक अलग लॉगिन और एक अलग पासवर्ड दर्ज करने के चरणों को उजागर करने के लिए प्राधिकरण स्क्रिप्ट को बदलना उचित है (और यह यांडेक्स, Google में किया जाता है, लेकिन अधिकांश ऑनलाइन स्टोर में नहीं किया गया)।
आवश्यक डेटा परिवर्तनों तक पहुँचना
आप स्क्रिप्ट से डेटा रूपांतरण एल्गोरिदम के लिए आवश्यकताएँ भी निकाल सकते हैं।
Примеры:
- किसी ऑनलाइन स्टोर में किसी उत्पाद को खरीदने का निर्णय लेने के लिए, ग्राहक को उत्पाद कार्ड पर इस उत्पाद की संभावना, लागत, उसके शहर में डिलीवरी का समय जानना होगा (जो उत्पाद की उपलब्धता के आधार पर एल्गोरिदम द्वारा गणना की जाती है) गोदाम और आपूर्ति श्रृंखला पैरामीटर)।
- खोज पंक्ति में कोई वाक्यांश दर्ज करते समय, क्लाइंट को एल्गोरिदम के अनुसार खोज सुझाव दिखाए जाते हैं (जो एल्गोरिदम द्वारा उत्पन्न होते हैं...)।
कुल मिलाकर
सामान्य तौर पर, पुस्तक को पढ़ने के बाद, दुर्भाग्य से, यह स्पष्ट नहीं है कि एक विश्लेषक से लेकर व्यावसायिक समस्याओं तक एक डेवलपर के लिए औपचारिक तकनीकी विनिर्देश तक कैसे पहुंचा जाए। पुस्तक प्रक्रिया का केवल एक भाग बताती है, जिसमें इनपुट चरण अस्पष्ट हैं और अगले चरण अस्पष्ट हैं। उपयोग का मामला अक्सर डेवलपर के लिए पूर्ण विवरण नहीं होता है।
फिर भी, यह किसी वस्तु और विषय के बीच बातचीत के परिदृश्यों को औपचारिक बनाने और संसाधित करने का एक बहुत अच्छा तरीका है, जब बातचीत विषय में किसी चीज़ में बदलाव का कारण बनती है। यह कुछ लेखन विधियों में से एक है जो स्पष्ट अपवाद खोज बिंदुओं के साथ सत्यापन योग्य आवश्यकताओं की अनुमति देता है।
परीक्षण योग्य नाटक लिखना शुरू करने के लिए विश्लेषकों को यह पुस्तक अवश्य पढ़नी चाहिए।
स्रोत: www.habr.com