मैं कैसे निर्धारित करूं कि मैं अपने उपयोग केस आरेखों में क्या जोड़ूं? प्रत्येक बटन/फॉर्म के लिए 1? क्या चीजें और खोज जैसी चीज़ों को शामिल किया जाना चाहिए? या वे उदाहरण के लिए "सूची आइटम" के अंतर्गत हैं? हालांकि, वस्तुओं की एक सूची समझा जाता है?उपयोग केस की ग्रैन्युलरिटी। सॉर्ट/खोज शामिल होना चाहिए?
उपयोग केस आरेख का उद्देश्य उच्च स्तर के व्यावसायिक कार्यों को परिभाषित करने में मदद करना है, जो कि महत्वपूर्ण हैं, सिस्टम के कार्यों की सूची नहीं। उदाहरण के लिए, ग्राहक सेवा में उपयोग की जाने वाली प्रणाली में किसी को समर्थन कॉल पर किसी की सहायता करने के लिए जानकारी देखने का एक शोध कार्य शामिल हो सकता है।
अधिकांश साहित्य सिस्टम को पूरा करने की आवश्यकता को परिभाषित करने के लिए प्रारंभिक बिंदु के रूप में उपयोग मामलों का वर्णन करता है। प्रलोभन हमेशा जितना संभव हो सके पूरा होना है; उपयोग केस को कार्यात्मक (कोड-वार) स्तर पर परिभाषित करने के लिए और अधिक विवरण जोड़ना। हालांकि आवश्यकताओं की व्यापक समझ रखने के लिए उपयोगी है, उपयोग केस आरेख का उद्देश्य उस दस्तावेज के स्तर को प्रदान करने के लिए नहीं है।
एक चीज जो इस मुद्दे को और भी बदतर बनाती है वह वाक्यविन्यास है जिसे मैंने कभी भी एक कामकाजी परियोजना में उपयोग नहीं किया है। ऐसा नहीं है कि शर्तें उपयोगी नहीं हैं, यह किसी दिए गए उपयोग के मामले के लिए किसी भी शब्द का उपयोग कब करने पर सर्वसम्मति की कमी के कारण है। यूएमएल कलाकृतियां ऐसी प्रक्रिया की अपेक्षा करती हैं जो कार्यान्वयन भाषा की बजाय व्यावसायिक भाषा पर अधिक केंद्रित है - और इसके द्वारा मेरा कंप्यूटर भाषा नहीं है। कुछ लोगों द्वारा प्रवृत्ति कानूनी रूप से झुकाव के साथ आरेखों तक पहुंचने और संबंधित उपयोग मामलों के लिए उपयोग करने के लिए या प्रक्रिया कार्यों की परिभाषित सूची में अपवाद के रूप में त्रुटि-प्रबंधन को व्यक्त करने के बारे में चिंता करने के लिए किया गया है।
यदि आपने कभी भी स्वचालित टेलर मशीन (एटीएम) उदाहरण के माध्यम से काम करने का प्रयास किया है, तो आपको पता चलेगा कि मेरा क्या मतलब है। यूएमएल सीखने की सौर प्रणाली में, एटीएम उदाहरण एक ब्लैक होल है जो आपको विवरण में चूस लेगा। यूएमएल या ऑब्जेक्ट ओरिएंटेड विश्लेषण और डिजाइन को समझने के लिए इसका उपयोग करने से बचें। इसमें कई समस्याएं हैं, जो असली दुनिया के डोमेन के विशिष्ट हैं, जो एक समग्र समझ हासिल करने से विचलित होती हैं, भले ही यह एक अच्छा उन्नत अध्ययन करे।
हां, कोड अंततः यूएमएल कलाकृतियों से उत्पादित किया जाएगा, लेकिन इसका मतलब यह नहीं है कि उन्हें सीनेट में एक संधि की तरह बहस करनी होगी।
OMG UML spec का कहना है:
उपयोग मामलों के लिए एक प्रणाली के लिए आवश्यक उपयोगों निर्दिष्ट करने के लिए एक साधन हैं। आमतौर पर, उनका उपयोग सिस्टम की आवश्यकताओं को कैप्चर करने के लिए किया जाता है, यानी, एक सिस्टम को क्या करना है। उपयोग मामलों से जुड़े महत्वपूर्ण अवधारणाएं अभिनेता हैं, मामलों का उपयोग करती हैं, और विषय। विषय वह प्रणाली है जिसके तहत उपयोग के मामले लागू होते हैं। उपयोगकर्ता और किसी भी अन्य सिस्टम जो विषय के साथ बातचीत कर सकते हैं उन्हें अभिनेताओं के रूप में दर्शाया जाता है। अभिनेता हमेशा सिस्टम के बाहर मौजूद इकाइयों को मॉडल करते हैं।
विषय के आवश्यक व्यवहार को एक या अधिक उपयोग मामलों द्वारा निर्दिष्ट किया गया है, जिन्हें अभिनेताओं की आवश्यकताओं के अनुसार परिभाषित किया गया है। कड़ाई से बोलते हुए, "उपयोग केस" शब्द का उपयोग एक केस केस प्रकार से है। उपयोग मामले का एक उदाहरण उभरते व्यवहार की घटना को संदर्भित करता है जो संबंधित उपयोग केस प्रकार के अनुरूप होता है। इस तरह के उदाहरण अक्सर बातचीत विनिर्देशों द्वारा वर्णित हैं।
एक अभिनेता किसी उपयोगकर्ता या किसी अन्य सिस्टम द्वारा निभाई गई भूमिका निर्दिष्ट करता है जो विषय के साथ बातचीत करता है। (शब्द "भूमिका" अनौपचारिक रूप से यहाँ प्रयोग किया जाता है और जरूरी है कि शब्द इस विवरण में कहीं भी पाई की तकनीकी परिभाषा संकेत नहीं करता है।)
अब ज्यादातर लोगों सहमत होंगे कि व्यापार और उपयोगकर्ता स्तर बातचीत मिठाई हाजिर हैं , लेकिन कोई सीमा नहीं है।उन मुख्य प्रणालियों/प्रणालियों के बाहर होने वाले अभिनेताओं/भूमिकाओं के बारे में सोचें जिन पर आप ध्यान केंद्रित कर रहे हैं। लेकिन एक नजर में एक प्रणाली एक अभिनेता हो सकती है, लेकिन दूसरे उपयोग मामलों के कार्यान्वयनकर्ता में।
उपयोगकेस की सामान्य ग्रॅन्युलरिटी परिदृश्य लक्ष्य चरण नहीं है। –