एलिस्टेयर कोबर्न की पुस्तक में दी गई UseCase पद्धति को मजबूत करना

"मॉडर्न मेथड्स फॉर डिस्क्राइबिंग फॉर द फंक्शनल रिक्वायरमेंट्स फ़ॉर सिस्टम" पुस्तक में, एलिस्टेयर कोबर्न ने समस्या कथन के एक भाग को लिखने के लिए एक विधि का वर्णन किया, जिसका उपयोग उपयोग विधि है।

यह क्या है यह एक सिस्टम (या व्यवसाय) के साथ उपयोगकर्ता इंटरैक्शन परिदृश्य का वर्णन है। एक ही समय में सिस्टम एक ब्लैक बॉक्स के रूप में कार्य करता है (और यह जटिल डिज़ाइन कार्य को सहभागिता को डिज़ाइन करने और इस इंटरैक्शन को सुनिश्चित करने के लिए संभव बनाता है)। उसी समय, अंकन मानकों को पेश किया जाता है, जो पढ़ने में आसानी सुनिश्चित करता है, जिसमें गैर-प्रतिभागियों के लिए भी शामिल है, और आपको हितधारक के लक्ष्यों के साथ पूर्णता और अनुपालन के लिए कुछ जांच करने की अनुमति देता है।

उदाहरण का उपयोग करें

परिदृश्य कैसा दिखता है, ईमेल के माध्यम से साइट पर प्राधिकरण के उदाहरण का उपयोग करना:

(सिस्टम) अपने व्यक्तिगत खाते तक पहुंचने के लिए साइट पर लॉग इन करें। ~~ (समुद्र तल)

संदर्भ: एक अनधिकृत ग्राहक को साइट पर अधिकृत किया जाता है ताकि साइट इसे पहचान ले और इसके लिए व्यक्तिगत जानकारी प्रदर्शित करे: एक लॉगिन के रूप में ईमेल का उपयोग करके ब्राउज़िंग इतिहास, खरीदारी, बोनस अंक की वर्तमान संख्या आदि।
स्तर: उपयोगकर्ता लक्ष्य
मुख्य अभिनेता: ग्राहक (हमारे ऑनलाइन स्टोर के आगंतुक)
स्कोप: ऑनलाइन स्टोर की वेबसाइट के साथ ग्राहक बातचीत
इच्छुक पक्ष और हित:

• मार्केटर चाहता है कि व्यक्तिगत न्यूज़लेटर्स तक बेहतर पहुंच के लिए अधिक से अधिक साइट विज़िटर की पहचान की जाए,
• एक सुरक्षा विशेषज्ञ आगंतुक के व्यक्तिगत डेटा की अनधिकृत पहुंच को रोकना चाहता है, जिसमें एक खाते के लिए एक पासवर्ड चुनने या कमजोर पासवर्ड वाले खाते की खोज करने के प्रयास शामिल हैं,
• एक हमलावर पीड़ित बोनस तक पहुँच प्राप्त करना चाहता है,
• प्रतियोगी उत्पादों पर नकारात्मक प्रतिक्रिया छोड़ना चाहते हैं,
• बॉटनेट स्टोर के ग्राहक आधार को प्राप्त करना चाहता है और साइट को निष्क्रिय बनाने के लिए हमले का उपयोग करता है।

पूर्वधारणाएँ: आगंतुक को लॉग इन नहीं होना चाहिए।
न्यूनतम गारंटी: आगंतुक एक सफल या असफल लॉगिन प्रयास के तथ्य का पता लगाएगा।
सफलता की गारंटी: आगंतुक अधिकृत है।

मुख्य परिदृश्य:

1. ग्राहक प्राधिकरण शुरू करता है।
2. सिस्टम पुष्टि करता है कि ग्राहक अधिकृत नहीं है और "सुरक्षा नियम संख्या 23" के अनुसार इस सत्र से असफल प्राधिकरण प्रयासों की संख्या (कई खातों के लिए एक कमजोर पासवर्ड की खोज) से अधिक नहीं है।
3. सिस्टम प्राधिकरण प्रयासों की संख्या के काउंटर को बढ़ाता है।
4. सिस्टम क्लाइंट के लिए एक प्राधिकरण फ़ॉर्म प्रदर्शित करता है।
5. क्लाइंट ईमेल और पासवर्ड दर्ज करता है।
6. सिस्टम सिस्टम में ऐसे ईमेल के साथ एक क्लाइंट की उपस्थिति की पुष्टि करता है और पासवर्ड मेल खाता है और सुरक्षा नियम संख्या 24 के अनुसार इस खाते में प्रवेश करने के प्रयासों की संख्या से अधिक नहीं है।
7. सिस्टम क्लाइंट को अधिकृत करता है, इस क्लाइंट खाते के अंतिम सत्र के साथ इस सत्र का ब्राउज़िंग इतिहास और टोकरी जोड़ता है।
8. सिस्टम एक प्राधिकरण सफलता संदेश प्रदर्शित करता है और उस स्क्रिप्ट के चरण पर आगे बढ़ता है जिससे ग्राहक प्राधिकरण के लिए बाधित होता है। इस स्थिति में, पृष्ठ के डेटा को खाते के व्यक्तिगत डेटा को ध्यान में रखते हुए ओवरलोड किया जाता है।

एक्सटेंशन:
2.a. ग्राहक पहले से अधिकृत है:
2.A.1। सिस्टम पहले किए गए प्राधिकरण के तथ्य के ग्राहक को सूचित करता है और स्क्रिप्ट को निरस्त करने या चरण 4 पर आगे बढ़ने का सुझाव देता है, जबकि यदि चरण 6 सफलतापूर्वक पूरा हो गया था, तो चरण 7 स्पष्टीकरण के साथ किया जाता है:
2.a.7। सिस्टम पुराने खाते के तहत ग्राहक को निष्क्रिय करता है, नए खाते के तहत ग्राहक को अधिकृत करता है, जबकि इस बातचीत सत्र का ब्राउज़िंग इतिहास और टोकरी पुराने खाते में रहता है, नए में नहीं जाता है। अगला, चरण 8 पर जाएं।
2. बी प्राधिकरण के प्रयासों की संख्या "सुरक्षा नियम संख्या 23" के तहत सीमा से अधिक है:
2.b.1 चरण 4 पर जाएँ, कैप्चा को अतिरिक्त रूप से प्राधिकरण प्रपत्र पर प्रदर्शित किया जाता है
2.b.6 सिस्टम कैप्चा की सही प्रविष्टि की पुष्टि करता है
2.b.6.1 कैप्चा गलत दर्ज किया गया:
2.b.6.1.1। सिस्टम इस खाते के लिए असफल लॉगिन प्रयासों के काउंटर को भी बढ़ाता है
2.b.6.1.2। सिस्टम एक विफलता संदेश प्रदर्शित करता है और चरण 2 पर लौटता है
6.A. इस ईमेल का कोई खाता नहीं मिला:
6.a.1 सिस्टम विफलता के बारे में एक संदेश प्रदर्शित करता है और चरण 2 को बचाने के लिए या तो चरण 2 में संक्रमण या "उपयोगकर्ता पंजीकरण" स्क्रिप्ट में संक्रमण का विकल्प प्रदान करता है।
6.b. इस ईमेल से खाते का पासवर्ड दर्ज किए गए से मेल नहीं खाता:
6.b.1 प्रणाली इस खाते में प्रवेश करने के असफल प्रयासों के काउंटर को बढ़ाती है।
6. बी। 2 सिस्टम विफलता संदेश प्रदर्शित करता है और "पासवर्ड रिकवरी" परिदृश्य में संक्रमण या चरण 2 में संक्रमण का चयन करने की पेशकश करता है।
6. सी: इस खाते में प्रवेश करने के प्रयासों का काउंटर "सुरक्षा नियम संख्या 24" के तहत सीमा से अधिक है।
6.v.1 प्रणाली एक्स मिनट के लिए खाते के प्रवेश द्वार को अवरुद्ध करने के बारे में एक संदेश प्रदर्शित करती है और चरण 2 पर आगे बढ़ती है।

क्या महान है?

लक्ष्यों के साथ पूर्णता और अनुपालन के लिए चेक, यानी आप किसी अन्य विश्लेषक को सत्यापन की आवश्यकताएं दे सकते हैं, जिससे कार्य को निर्धारित करने के चरण में कम त्रुटियों की अनुमति मिलती है।

एक प्रणाली के साथ काम करना जैसे कि ब्लैक बॉक्स आपको कार्यान्वयन के तरीकों से स्वचालित होने के ग्राहक के साथ विकास और समन्वय को साझा करने की अनुमति देता है।

यह विश्लेषक के पथ का हिस्सा है, जो प्रयोज्य के मुख्य भागों में से एक है। उपयोगकर्ता की स्क्रिप्ट उसके आंदोलन के लिए मुख्य मार्ग निर्धारित करती है, जो डिजाइनर और ग्राहक के लिए पसंद की स्वतंत्रता को कम करती है और डिजाइन विकास की गति को बढ़ाने में मदद करती है।

यह उस स्थान के विवरण में बहुत ही मनभावन है जहां प्रत्येक अंतःक्रियात्मक कदम के अपवादों का पता चलता है। एक समग्र आईटी प्रणाली को एक या एक अन्य अपवाद हैंडलिंग, मैनुअल मोड में भाग, स्वचालित में भाग (ऊपर उदाहरण में) के लिए प्रदान करना चाहिए।

अनुभव से पता चला है कि खराब सोचा अपवाद अपवाद आसानी से एक प्रणाली को बहुत असुविधाजनक प्रणाली में बदल सकता है। मुझे एक कहानी याद है जब सोवियत समय में एक निर्णय लेने के लिए विभिन्न सेवाओं से कई अनुमोदन प्राप्त हुए थे, और यह दुख होता है जब अंतिम सेवा कहती है - और आपके पास एक गलत नाम या विराम चिह्न में कुछ और गलती है, सब कुछ फिर से करें और सब कुछ समेट लें।

अक्सर मैं उन स्थितियों में आता हूं जहां एक सिस्टम लॉजिक जिसे अपवादों के लिए नहीं सोचा गया था, को इस प्रणाली के एक महत्वपूर्ण परिवर्तन की आवश्यकता थी। इस वजह से, विश्लेषक के काम के शेर का हिस्सा अपवादों को संभालने पर खर्च किया जाता है।

पाठ संकेतन, आरेखों के विपरीत, आपको अधिक अपवादों को पहचानने और कवर करने की अनुमति देता है।

अभ्यास विधि को जोड़ना

उपयोग मामला उपयोगकर्ता की कहानी के विपरीत, उत्पादन का स्वतंत्र रूप से प्राथमिकता वाला हिस्सा नहीं है।

इस परिदृश्य में, अपवाद पर विचार करें "6.a। इस ईमेल के साथ कोई खाता नहीं मिला। " और अगला चरण "6.a.1। सिस्टम विफलता संदेश प्रदर्शित करता है और चरण 2 में आगे बढ़ता है"। पर्दे के पीछे क्या नकारात्मक रहता है? क्लाइंट के लिए, कोई भी रिटर्न इस तथ्य के बराबर है कि उसने जो भी डेटा दर्ज करने का काम किया है, उसे लैंडफिल में डाल दिया गया है। (यह केवल स्क्रिप्ट में दिखाई नहीं देता है!) क्या किया जा सकता है? स्क्रिप्ट को फिर से बनाएँ ताकि ऐसा न हो। क्या यह किया जा सकता है? आप कर सकते हैं - एक उदाहरण के रूप में, Google में प्राधिकरण स्क्रिप्ट देखें।

परिदृश्य अनुकूलन

पुस्तक औपचारिकता के बारे में बात करती है, लेकिन ऐसे परिदृश्यों के लिए अनुकूलन विधियों के बारे में बहुत कम बात करती है।

लेकिन लिपियों का अनुकूलन करके विधि को मजबूत करना संभव है, और उपयोग मामला औपचारिकता विधि यह अनुमति देता है। विशेष रूप से, होने वाले प्रत्येक अपवाद के लिए, आपको इसके बारे में सोचने, कारण निर्धारित करने और स्क्रिप्ट को फिर से बनाने की आवश्यकता है ताकि अपवाद से छुटकारा मिल सके या ग्राहक के मार्ग को कम से कम किया जा सके।

ऑनलाइन स्टोर को ऑर्डर करने के लिए आपको डिलीवरी के शहर में प्रवेश करना होगा। यह पता चल सकता है कि ग्राहक द्वारा चुने गए शहर के लिए, स्टोर माल वितरित नहीं कर सकता है क्योंकि यह वितरित नहीं करता है, समग्र प्रतिबंधों के कारण या संबंधित गोदाम में माल की कमी के कारण।

यदि आप केवल डिज़ाइन चरण में इंटरैक्शन परिदृश्य का वर्णन करते हैं, तो आप "ग्राहक को वितरण की असंभवता के बारे में सूचित कर सकते हैं और शहर या टोकरी की संरचना को बदलने की पेशकश कर सकते हैं" (और कई नौसिखिए विश्लेषक वहां रुक जाते हैं)। लेकिन अगर ऐसे बहुत सारे मामले हैं, तो आप परिदृश्य को अनुकूलित कर सकते हैं।

पहली बात यह है कि केवल उस शहर को देना है जहां हम डिलीवरी कर सकते हैं। कब करना है? साइट पर उत्पाद चुनने के क्षण से पहले (विनिर्देशन के साथ आईपी के माध्यम से शहर का पता लगाना)।

दूसरा - आपको केवल उस सामान का चुनाव करना होगा, जिसे हम ग्राहक तक पहुंचा सकते हैं। कब करना है? चयन के समय - माल टाइल और उत्पाद कार्ड पर।

ये दो बदलाव इस अपवाद को काफी हद तक खत्म करते हैं।

माप और मीट्रिक आवश्यकताएँ

अपवादों को संभालने के काम को ध्यान में रखते हुए, आप कार्य को रिपोर्टिंग पर डाल सकते हैं (उपयोग मामला वर्णित नहीं है)। कितने अपवाद थे, वे किस स्थिति में हुए, साथ ही आने वाले लोगों से कितने परिदृश्य सफल रहे।

लेकिन अफसोस। अनुभव से पता चला है कि इस रूप में परिदृश्यों के लिए रिपोर्टिंग आवश्यकताएं पर्याप्त नहीं हैं, आपको उन प्रक्रियाओं के लिए रिपोर्टिंग आवश्यकताओं पर विचार करने की आवश्यकता है जो मुख्य रूप से उपयोग किए गए मामले के रूप में वर्णित नहीं हैं।

प्रयोज्य पहुँच

हमारे व्यवहार में, हमने ग्राहक द्वारा निर्णय लेने के लिए संस्थाओं और डेटा की विशिष्ट विशेषताओं के विवरण के साथ उपयोग के मामले के विवरण का विस्तार किया है, जो बाद की उपयोगिता को बढ़ाता है।

प्रयोज्य डिजाइन के लिए, हमने एक इनपुट अनुभाग जोड़ा - प्रदर्शित डेटा।

एक प्राधिकरण परिदृश्य में, यह सिस्टम में क्लाइंट प्राधिकरण का एक तथ्य है। यदि क्लाइंट पूर्व-अधिकृत है, तो सफल प्राधिकरण के बाद नेविगेशन इतिहास और टोकरी को नए खाते में स्विच करने के बारे में एक चेतावनी प्रदर्शित करें।

सामान्य स्थिति में, यह क्लाइंट के लिए आवश्यक जानकारी का मानचित्रण है ताकि वह परिदृश्य के अनुसार अपने आगे के कार्यों के बारे में निर्णय ले सके (कोई यह पूछ सकता है कि क्या ग्राहक के पास इस डेटा के लिए पर्याप्त है, और क्या आवश्यक है, ग्राहक को निर्णय लेने के लिए कौन सी जानकारी की आवश्यकता है)।
इनपुट जानकारी को इनपुट क्षेत्रों में विभाजित करने के लायक भी है यदि उनकी प्रसंस्करण अलग-अलग होती है और विभिन्न अपवादों के गठन के साथ होती है।

क्लाइंट प्राधिकरण के साथ उदाहरण में, यदि आप एक उपयोगकर्ता नाम और पासवर्ड के साथ दर्ज की गई जानकारी को उजागर करते हैं, तो आपको एक अलग लॉगिन और पासवर्ड दर्ज करने के लिए अलग-अलग चरणों के साथ प्राधिकरण स्क्रिप्ट को बदलना चाहिए (और यह यैंडेक्स, Google में किया गया है, लेकिन अधिकांश ऑनलाइन स्टोर में नहीं)।

आवश्यक डेटा रूपांतरणों तक पहुंच

डेटा परिवर्तन एल्गोरिदम के लिए आवश्यकताओं को स्क्रिप्ट से बाहर भी निकाला जा सकता है।

उदाहरण:

• ऑनलाइन स्टोर में किसी उत्पाद को खरीदने के बारे में निर्णय लेने के लिए, ग्राहक को अपने शहर में उत्पाद की डिलीवरी की संभावना, लागत, इस उत्पाद की डिलीवरी की शर्तें (जो कि वेयरहाउस में माल की उपलब्धता के तथ्य पर एल्गोरिथ्म द्वारा गणना की जाती हैं) की आवश्यकता होती है।
• जब कोई वाक्यांश खोज स्ट्रिंग में दर्ज किया जाता है, तो क्लाइंट को एल्गोरिथम द्वारा खोज संकेत दिखाया जाता है (जो एल्गोरिथ्म द्वारा निर्मित होता है ...)।

कुल मिलाकर

सामान्य तौर पर, पुस्तक को पढ़ने के बाद, दुर्भाग्यवश, यह स्पष्ट नहीं है कि डेवलपर के लिए टीके को औपचारिक समस्याओं के लिए विश्लेषक से व्यावसायिक समस्याओं तक कैसे पहुंचें। पुस्तक प्रक्रिया का केवल एक हिस्सा बताती है जिसमें अस्पष्ट शब्दों के साथ इनबाउंड और अस्पष्ट रूप से अगले चरणों को दिखाया गया है। अपने आप से, उपयोग का मामला सबसे अधिक बार डेवलपर के लिए एक पूर्ण बयान नहीं है।

फिर भी, यह किसी वस्तु और किसी विषय की बातचीत के परिदृश्य को औपचारिक रूप देने और प्रसंस्करण करने का एक बहुत अच्छा तरीका है, जब बातचीत से विषय में कुछ परिवर्तन होता है। यह कुछ लेखन विधियों में से एक है जो स्पष्ट अपवाद लुकअप पॉइंट्स के साथ सत्यापन योग्य आवश्यकताओं की अनुमति देता है।

पुस्तक को विश्लेषकों द्वारा पढ़ा जाना आवश्यक है ताकि वे सत्यापन योग्य प्रस्तुतियों को लिखना शुरू करें।