सिस्टमसाठी कार्यात्मक आवश्यकतांचे वर्णन करण्यासाठी आधुनिक पद्धती. अॅलिस्टर कोबर्न. पुस्तकाचे पुनरावलोकन आणि जोड

पुस्तकात समस्या विधानाचा भाग लिहिण्याच्या एका पद्धतीचे वर्णन केले आहे, ते म्हणजे वापर केस पद्धत.

हे काय आहे? हे सिस्टमसह (किंवा व्यवसायासह) वापरकर्त्याच्या परस्परसंवादाच्या परिस्थितीचे वर्णन आहे. या प्रकरणात, सिस्टम ब्लॅक बॉक्स म्हणून कार्य करते (आणि यामुळे जटिल डिझाइन कार्यास परस्परसंवादाची रचना करणे आणि हे परस्परसंवाद सुनिश्चित करणे शक्य होते). त्याच वेळी, नोटेशन मानके सादर केली जातात, जे गैर-सहभागी लोकांसह वाचन सुलभतेची खात्री देतात आणि भागधारकांच्या उद्दिष्टांची पूर्णता आणि अनुपालनासाठी काही तपासणी करण्यास अनुमती देतात.

केस उदाहरण वापरा

ईमेलद्वारे साइटवर अधिकृततेचे उदाहरण वापरून, परिस्थिती कशी दिसते:

(सिस्टम) तुमच्या वैयक्तिक खात्यात प्रवेश करण्यासाठी वेबसाइटवर लॉग इन करा. ~~ (समुद्र पातळी)

संदर्भ: एक अनधिकृत क्लायंट साइटवर लॉग इन करतो जेणेकरून साइट त्याला ओळखते आणि त्याच्यासाठी वैयक्तिक माहिती दर्शवते: लॉगिन म्हणून ईमेल वापरून ब्राउझिंग इतिहास, खरेदी इतिहास, वर्तमान बोनस पॉइंट्स इ. 
पातळी: वापरकर्ता ध्येय
मुख्य पात्र: क्लायंट (आमच्या ऑनलाइन स्टोअरचा अभ्यागत)
व्याप्ती: ऑनलाइन स्टोअर वेबसाइटसह ग्राहक संवाद
भागधारक आणि स्वारस्ये:

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

पूर्व शर्ती: अभ्यागत अधिकृत नसावे.
किमान हमी: अधिकृततेचा प्रयत्न यशस्वी की अयशस्वी झाला हे अभ्यागताला कळेल.
यशाची हमी: अभ्यागत अधिकृत आहे.

मुख्य परिस्थिती:

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 कॅप्चा चुकीचा प्रविष्ट केला:
      2.ब.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 वर जाते.

काय मस्त आहे

पूर्णता आणि उद्दिष्टांचे अनुपालन तपासते, म्हणजे, आपण सत्यापनासाठी दुसर्‍या विश्लेषकाला आवश्यकता देऊ शकता, समस्या तयार करण्याच्या टप्प्यावर कमी चुका करू शकता.

ब्लॅक बॉक्स प्रणालीसह कार्य केल्याने तुम्हाला अंमलबजावणीच्या पद्धतींमधून काय स्वयंचलित केले जाईल याचा विकास आणि ग्राहकांशी समन्वय वेगळे करण्याची परवानगी मिळते.

हे विश्लेषकांच्या मार्गाचा एक भाग आहे, उपयोगिता मुख्य भागांपैकी एक आहे. वापरकर्त्याची परिस्थिती त्याच्या हालचालीचे मुख्य मार्ग परिभाषित करते, जे डिझाइनर आणि ग्राहकांच्या निवडीचे स्वातंत्र्य मोठ्या प्रमाणात कमी करते आणि डिझाइनच्या विकासाची गती वाढविण्यास मदत करते.

मला वर्णनातील स्थानाबद्दल खूप आनंद झाला आहे जिथे प्रत्येक संवाद चरणातील अपवाद ओळखले जातात. संपूर्ण IT प्रणालीने काही प्रकारच्या अपवाद हाताळणीसाठी, काही व्यक्तिचलितपणे, काही स्वयंचलितपणे (वरील उदाहरणाप्रमाणे) प्रदान करणे आवश्यक आहे.

अनुभव असे दर्शवितो की अविचारी अपवाद हाताळणी प्रणाली सहजपणे एक भयंकर गैरसोयीच्या प्रणालीमध्ये बदलू शकते. मला ती गोष्ट आठवते जेव्हा सोव्हिएत काळात, निर्णय घेण्यासाठी, तुम्हाला वेगवेगळ्या सेवांकडून अनेक मंजूरी घ्याव्या लागल्या, आणि जेव्हा शेवटची सेवा म्हणते तेव्हा ते किती वेदनादायक होते - परंतु तुमचा अर्ज चुकीच्या नावावर आहे किंवा इतर काही चूक आहे. विरामचिन्हे, सर्वकाही पुन्हा करा आणि सर्वकाही पुन्हा समन्वयित करा.

मला अनेकदा अशा परिस्थिती येतात जेव्हा अपवादांसाठी विचारात न घेतलेल्या सिस्टमच्या ऑपरेटिंग लॉजिकला सिस्टीमचे महत्त्वपूर्ण पुनर्रचना आवश्यक असते. यामुळे, विश्लेषकाच्या कामाचा सिंहाचा वाटा अपवाद हाताळणीवर खर्च होतो.

मजकूर नोटेशन, आकृत्यांच्या विरूद्ध, अधिक अपवाद ओळखण्यास आणि कव्हर करण्यास अनुमती देते.

सराव पासून पद्धत जोडणे

वापरकर्ता कथेच्या विपरीत, वापर प्रकरण विधानाचा स्वतंत्रपणे प्राधान्य दिलेला भाग नाही.

वरील परिस्थितीत, अपवाद विचारात घ्या “6.a. या ईमेलसह कोणतेही खाते आढळले नाही.” आणि पुढची पायरी "6.a.1 सिस्टीम अयशस्वी संदेश प्रदर्शित करते आणि चरण 2 वर जाते." पडद्यामागे कोणत्या नकारात्मक गोष्टी राहिल्या? क्लायंटसाठी, कोणताही परतावा या वस्तुस्थितीप्रमाणे आहे की त्याने डेटा प्रविष्ट करताना केलेले सर्व काम लँडफिलमध्ये टाकले जाते. (हे फक्त स्क्रिप्टमध्ये दिसत नाही!) काय करता येईल? स्क्रिप्ट पुन्हा तयार करा जेणेकरून असे होणार नाही. हे करणे शक्य आहे का? तुम्ही - उदाहरण म्हणून, Google अधिकृतता स्क्रिप्ट पाहू शकता.

परिस्थिती ऑप्टिमायझेशन

पुस्तक औपचारिकतेबद्दल बोलते, परंतु अशा परिस्थितींना अनुकूल करण्याच्या पद्धतींबद्दल थोडेसे सांगतात.

परंतु परिस्थिती अनुकूल करून पद्धत मजबूत करणे शक्य आहे आणि वापर केस औपचारिकीकरण पद्धत हे करण्यास अनुमती देते. विशेषत:, तुम्हाला येणाऱ्या प्रत्येक अपवादाचा विचार करणे, कारण निश्चित करणे आणि स्क्रिप्टची पुनर्बांधणी करणे आवश्यक आहे जेणेकरुन अपवादापासून सुटका व्हावी किंवा ग्राहकाचा प्रवास कमी करता येईल.

ऑनलाइन स्टोअरमधून ऑर्डर देताना, आपण वितरण शहर प्रविष्ट करणे आवश्यक आहे. असे होऊ शकते की स्टोअर क्लायंटने निवडलेल्या शहरात वस्तू वितरीत करू शकत नाही कारण ते तेथे वितरित करत नाही, आकाराच्या निर्बंधांमुळे किंवा संबंधित वेअरहाऊसमध्ये माल नसल्यामुळे.

आम्ही नोंदणीच्या टप्प्यावर परस्परसंवादाच्या परिस्थितीचे फक्त वर्णन केल्यास, आम्ही "क्लायंटला कळवू शकतो की वितरण अशक्य आहे आणि शहर किंवा कार्टमधील सामग्री बदलण्याची ऑफर देऊ शकतो" (आणि बरेच नवशिक्या विश्लेषक तेथे थांबतात). परंतु अशी बरीच प्रकरणे असल्यास, परिस्थिती अनुकूल केली जाऊ शकते.

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

दुसरे म्हणजे, आम्हाला फक्त त्या वस्तूंची निवड द्यावी लागेल जी आम्ही क्लायंटला देऊ शकतो. हे कधी करायचे? निवडीच्या क्षणी - उत्पादन टाइल आणि उत्पादन कार्डवर.

हे दोन बदल हा अपवाद दूर करण्याच्या दिशेने खूप पुढे जातात.

मोजमाप आणि मेट्रिक्ससाठी आवश्यकता

अपवाद हाताळणी कमी करण्याच्या कार्याचा विचार करताना, आपण अहवाल कार्य सेट करू शकता (वापर प्रकरण वर्णन केलेले नाही). त्यात किती अपवाद होते, ते कोणत्या प्रकरणांमध्ये झाले, तसेच किती येणारी परिस्थिती यशस्वीरित्या पार झाली.

पण अरेरे. अनुभवाने दर्शविले आहे की या फॉर्ममधील परिस्थितींसाठी अहवाल आवश्यकता पुरेशी नाही; मुख्यतः वापराच्या स्वरूपात नसलेल्या प्रक्रियांसाठी अहवाल आवश्यकता विचारात घेणे आवश्यक आहे.

उपयोगिता प्रवेश

आमच्या प्रॅक्टिसमध्ये, आम्ही क्लायंटला निर्णय घेण्यासाठी विशिष्ट गुणधर्म आणि डेटाच्या वर्णनासह वापर केस वर्णन फॉर्मचा विस्तार केला आहे, ज्यामुळे नंतरची उपयोगिता वाढते.

उपयोगिता डिझाइनसाठी, आम्ही एक इनपुट विभाग जोडला - प्रदर्शन डेटा.

अधिकृततेसह परिस्थितीमध्ये, ही वस्तुस्थिती आहे की क्लायंट सिस्टममध्ये अधिकृत आहे. जर क्लायंट पूर्व-अधिकृत असेल, तर यशस्वी अधिकृततेनंतर नेव्हिगेशन इतिहास आणि कार्ट नवीन खात्यावर स्विच करण्याबद्दल चेतावणी प्रदर्शित करा.

सर्वसाधारणपणे, हे क्लायंटसाठी आवश्यक माहितीचे प्रदर्शन आहे जेणेकरुन तो परिस्थितीनुसार त्याच्या पुढील कृतींबद्दल निर्णय घेऊ शकेल (आपण विचारू शकता की हा डेटा क्लायंटसाठी पुरेसा आहे की नाही, आणखी काय आवश्यक आहे, काय माहिती आहे क्लायंटने निर्णय घेणे आवश्यक आहे).  
प्रविष्ट केलेली माहिती इनपुट फील्डमध्ये विभाजित करणे देखील योग्य आहे जर ती स्वतंत्रपणे प्रक्रिया केली गेली आणि भिन्न अपवाद तयार केली गेली.

क्लायंट ऑथोरायझेशनच्या उदाहरणात, जर तुम्ही प्रविष्ट केलेली माहिती लॉगिन आणि पासवर्डमध्ये विभक्त केली असेल, तर स्वतंत्र लॉगिन आणि स्वतंत्र पासवर्ड प्रविष्ट करण्याच्या टप्प्यावर प्रकाश टाकण्यासाठी अधिकृतता स्क्रिप्ट बदलणे योग्य आहे (आणि हे Yandex, Google मध्ये केले जाते, परंतु बहुतेक ऑनलाइन स्टोअरमध्ये केले जात नाही).

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

तुम्ही स्क्रिप्टमधून डेटा रूपांतरण अल्गोरिदमसाठी आवश्यकता देखील काढू शकता.

उदाहरणे:

• ऑनलाइन स्टोअरमध्ये एखादे उत्पादन खरेदी करण्याचा निर्णय घेण्यासाठी, क्लायंटला उत्पादन कार्डावर या उत्पादनाची शक्यता, किंमत, त्याच्या शहरात वितरणाचा वेळ माहित असणे आवश्यक आहे (जे उत्पादनाच्या उपलब्धतेच्या आधारावर अल्गोरिदमद्वारे मोजले जाते. गोदामे आणि पुरवठा साखळी पॅरामीटर्स).
• शोध ओळीत वाक्यांश प्रविष्ट करताना, क्लायंटला अल्गोरिदमनुसार शोध सूचना दर्शविल्या जातात (ज्या अल्गोरिदमद्वारे व्युत्पन्न केल्या जातात...).

एकूण

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

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

चाचणी करण्यायोग्य नाटके लिहिण्यास सुरुवात करण्यासाठी विश्लेषकांनी हे पुस्तक वाचलेच पाहिजे.

स्त्रोत: www.habr.com