गोल मॉडलिंग

From Vigyanwiki
Revision as of 14:35, 11 August 2023 by Manidh (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

एक गोल मॉडल रेक्विरेमेंट इंजीनियरिंग का अवयव है जिसका उपयोग बिज़नेस एनालिसिस में भी अधिक व्यापक रूप से किया जा सकता है। संबंधित एलेमेन्ट में अन्य व्यावसायिक और तकनीकी क्षेत्रों के अतिरिक्त स्टेकहोल्डर एनालिसिस , कॉन्टेक्स्ट एनालिसिस और सिनेरियो (कंप्यूटिंग) सम्मिलित हैं।[1]

सिद्धांत

गोल वे उद्देश्य हैं जिन्हें प्रणाली को इच्छित सॉफ़्टवेयर और पर्यावरण में एक्टर के सहयोग के माध्यम से प्राप्त करना चाहिए।[2] गोल मॉडलिंग किसी परियोजना के प्रारंभिक चरणों में विशेष रूप से उपयोगी है। परियोजनाएं इस बात पर विचार कर सकती हैं कि इच्छित प्रणाली संगठनात्मक गोल को कैसे पूरा करती है (यह भी देखें)। [3]), इस प्रणाली की आवश्यकता क्यों है और स्टेकहोल्डर को कैसे संबोधित किया जा सकता है।[4]

एक गोल मॉडल:

  • एक सिस्टम और उसके पर्यावरण के बीच संबंधों को व्यक्त करता है (अर्थात न केवल सिस्टम को क्या करना चाहिए, किन्तु क्यों करना चाहिए)। किसी सिस्टम की आवश्यकता क्यों है, इसके संदर्भ में यह जो समझ मिलती है, वह उपयोगी है क्योंकि सिस्टम का उपयोग लंबे समय से स्थापित प्रथाओं को स्वचालित करने के अतिरिक्त व्यावसायिक प्रक्रियाओं को मौलिक रूप से बदलने के लिए किया जा रहा है।[5][6]
  • आवश्यकताओं को स्पष्ट करता है: गोल निर्दिष्ट करने से यह पूछा जाता है कि क्यों, कैसे और कैसे[5] इस प्रक्रिया में स्टेकहोल्डर की आवश्यकताएं अधिकांशतः सामने आ जाती हैं, जिससे या तो आवश्यकताएं अदृश्य होने या अति-निर्दिष्टीकरण (उन चीजों की मांग करना जिनकी जरूरत नहीं है) का ख़तरा कम होता है।
  • बड़े गोल को छोटे, प्राप्य गोल में विश्लेषित करने की अनुमति देता है:
  • संघर्षों से निपटता है: गोल मॉडलिंग निवेश, प्रदर्शन, लचीलेपन, सुरक्षा और अन्य गोल के बीच ट्रेडऑफ़ को पहचानने और हल करने में सहायता कर सकता है। यह स्टेकहोल्डर के बीच भिन्न रुचियाँ को प्रकट कर सकता है। यह संघर्षों की पहचान कर सकता है क्योंकि गोल को पूरा करना अन्य गोल को पूरा करने में हस्तक्षेप कर सकता है।[5]
  • आवश्यकता पूर्णता को मापने में सक्षम बनाता है: यदि गोल मॉडल में सभी गोल को पूरा किया जाता है तो आवश्यकताओं को पूर्ण माना जा सकता है।
  • आवश्यकताओं को डिजाइन से जोड़ता है: उदाहरण के लिए, i* नॉन-फंक्शनल रेक्विरेमेंट (एनएफआर) फ्रेम वर्क डिजाइन प्रक्रिया को निर्देशित करने के लिए गोल का उपयोग करता है।

नोटेशन

सॉफ़्टवेयर विकास में गोल मॉडल के लिए कई नोटेशन उपयोग में हैं, जिनमें सम्मिलित हैं:

शोधकर्ताओं द्वारा अन्य संकेतन प्रस्तावित किए गए हैं,[10] जबकि गोल संरचना संकेतन (जीएसएन) और जीआरएल का उपयोग कभी-कभी सुरक्षा से संबंधित उद्योगों में नियामक को संतुष्ट करने के लिए सुरक्षित स्थिति बनाने के लिए किया जाता है।[11][12]

i* में गोल मॉडलिंग

I* गोल मॉडलिंग नोटेशन दो प्रकार के आरेख प्रदान करता है:[13]

  • रणनीतिक निर्भरता (एसडी), विशिष्ट गोल के संदर्भ में भूमिकाओं के बीच संबंधों को परिभाषित करना जो भूमिका प्रदान करने के लिए दूसरी भूमिका पर निर्भर करती है।
  • रणनीतिक तर्क (एसआर), एसडी मॉडल पर पहचाने गए गोल का सहायक गोल और कार्यों में एनालिसिस करना है।

i* प्रत्येक भूमिका (एक एक्टर, एजेंट या स्थिति) को बड़े वृत्त के रूप में दिखाता है जिसमें उस भूमिका के लक्ष्य, कार्य और संसाधन सम्मिलित होते हैं। जो कि i* में स्वामित्व का अर्थ है कि भूमिका अपने गोल की संतुष्टि चाहती है, जो कि या तो अपने लाभ के लिए या किसी अन्य भूमिका के लाभ के लिए गोल के साथ-साथ बाधाएँ (ऋणात्मक लक्ष्य) भी पार करनी पड़ सकती हैं। गैर-कार्यात्मक गोल को i* में सॉफ्ट गोल के रूप में तैयार किया जा सकता है: उन्हें बादलों या इंडेंटेड ओवल के रूप में चित्रित किया जाता है।

केएओएस में गोल मॉडलिंग

केएओएस गोल मॉडलिंग नोटेशन गोल और बाधाओं को परिभाषित करने का विधि प्रदान करता है, जो एनालिसिस की औपचारिक (गणितीय) पद्धति पर आधारित है।[8]

यूएमएल में गोल मॉडलिंग

यूएमएल का उपयोग केस आरेख सरल गोल मॉडलिंग संकेतन प्रदान करता है। बबल नाम के कार्यात्मक लक्ष्य,[14] इसलिए उपयोग केस आरेख सरल कार्य-केवल गोल मॉडल बनाता है: जैसा कि कॉकबर्न लिखते हैं, जो कि उपयोग के स्थिति में केवल व्यवहार संबंधी आवश्यकताओं को आवरण करते हैं।[15] भूमिकाओं को एक्टर्स (आरेख पर स्टिकमैन) के रूप में दिखाया गया है, जो उन उपयोग स्थितियों से जुड़े हुए हैं जिनमें वे भाग लेते हैं। उपयोग के स्थितियों को ओवल बबल के रूप में तैयार किया गया है, जो वांछित व्यवहार गोल का प्रतिनिधित्व करते हैं।[16] दुरुपयोग के स्थितियों को जोड़ने के साथ, नोटेशन वांछित गोल और सक्रिय खतरों दोनों को मॉडल कर सकता है। दुरुपयोग स्थिति का नोटेशन दुरुपयोग के स्थितियों के लिए प्राथमिक एक्टर्स के रूप में ऋणात्मक (संभवतः शत्रुतापूर्ण) स्टेकहोल्डर को दिखाता है; इन्हें आरेख के दाईं ओर समूहीकृत किया जा सकता है। यह नोटेशन सहायक उपयोग के स्थितियों के रूप में दिखाए गए उपयुक्त शमन या निवारक गोल की खोज में सहायता कर सकता है। इनका उद्देश्य अधिकांशतः सुरक्षा, या विश्वसनीयता में सुधार करना होता है, जो गैर-कार्यात्मक गोल हैं। ऋणात्मक गोल को परिभाषित करने के लिए दुरुपयोग के स्थितियों का उपयोग करके गैर-कार्यात्मक आवश्यकताओं को कुछ सीमा तक उपयोग केस शैली में वर्णित किया जा सकता है; किन्तु इस प्रकार खोजे गए (धनात्मक) गोल अधिकांशतः कार्यात्मक होते हैं। उदाहरण के लिए, यदि चोरी से सुरक्षा के लिए खतरा है, तो ताले लगाना न्यूनीकरण है; किन्तु दरवाज़ा संवर्त किया जा सकता है यह कार्यात्मक आवश्यकता है।[17]

प्रतिवाद यह है कि उपयोग के स्थिति संज्ञानात्मक विज्ञान की जड़ों से नहीं हैं, जबकि i* और केएओएस हैं। वास्तव में उपयोग के स्थितियों के पीछे के साहित्य में गोल उद्देश , गोल अधिशोधन, अंत-साधन पर चर्चा सम्मिलित नहीं है, रासमुसेन वगैरह का जिक्र नहीं है। संज्ञानात्मक विज्ञान के अनुसार गोल शोधन के शब्दार्थ के अतिरिक्त गोल के दृश्य रूपक के कारण उपयोग के स्थितियों को गोल से जोड़ने की प्रवृत्ति हो सकती है।

बिबलियोग्राफी

  • अलेक्जेंडर, इयान और ब्यूस-डुकिक, लेजेर्का आवश्यकताओं की खोज: उत्पादों और सेवाओं को कैसे निर्दिष्ट करें विली, 2009.
  • अलेक्जेंडर, इयान एफ. और मेडेन, नील परिदृश्य, कहानियाँ, उपयोग के स्थिति विली, 2004.
  • कॉकबर्न, एलिस्टेयर प्रभावी उपयोग के स्थिति लिखना एडिसन-वेस्ले, 2001.
  • फाउलर, मार्टिन यूएमएल आसुत. तीसरा संस्करण. एडिसन-वेस्ले, 2004.
  • वैन लैम्सवेर्डे, एक्सल आवश्यकताएँ इंजीनियरिंग: सिस्टम गोल से लेकर यूएमएल मॉडल से लेकर सॉफ्टवेयर विनिर्देशों तक। विली, 2009.
  • यू, एरिक, पाओलो जियोर्जिनी, नील मेडेन और जॉन मायलोपोलोस (संपादक) रिक्वायरमेंट्स इंजीनियरिंग के लिए सोशल मॉडलिंग एमआईटी प्रेस, 2011।


यह भी देखें

संदर्भ

  1. Alexander and Beus-Dukic, 2009. Pages 17-18
  2. Lin Liu and Eric Yu (2003). "Designing information systems in social context: a goal and scenario modelling approach" (PDF). University of Toronto. Archived from the original (PDF) on February 5, 2005.
  3. Ellis-Braithwaite, R.; Lock, R.; Dawson, R.; Haque B. (2013). "परिमाणित लक्ष्य ग्राफ़ का उपयोग करके सॉफ़्टवेयर आवश्यकताओं के रणनीतिक संरेखण का विश्लेषण करने के लिए एक दृष्टिकोण की ओर". International Journal on Advances in Software. 6: 119–130. arXiv:1307.2580. Bibcode:2013arXiv1307.2580E.
  4. E. Yu, "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering", 1997 IEEE
  5. 5.0 5.1 5.2 Eric Yu and John Mylopoulos. "लक्ष्य-उन्मुख आवश्यकताएँ इंजीनियरिंग क्यों". University of Toronto.
  6. K.Pohl and P. Haumer, "Modelling Contextual Information about Scenarios", Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ ’97, Barcelona, Catalonia, Spain, June 1997 pp. 187-204.
  7. Yu et al, 2011.
  8. 8.0 8.1 van Lamsweerde, 2009.
  9. Fowler, 2004. Pages 99-105
  10. Rolland, Colette; Prakash, Naveen; Benjamen, Adolphe (1999). "प्रक्रिया मॉडलिंग का एक बहु-मॉडल दृश्य" (PDF). Requirements Engineering. 4 (4): 169–187. doi:10.1007/s007660050018. S2CID 6988662.
  11. GSN Community Standard
  12. Feodoroff, R. (2016). "Intentional enterprise architecture". 2016 Annual IEEE Systems Conference (SysCon). pp. 1–8. doi:10.1109/SYSCON.2016.7490555. ISBN 978-1-4673-9519-9. S2CID 206586399.
  13. Yu, Eric (September 6, 2011). "मैं*". i*: an agent- and goal-oriented modelling framework. University of Toronto. Retrieved December 17, 2011.
  14. Alexander and Beus-Dukic, 2009. Page 121
  15. Cockburn, 2001. Page 62
  16. Cockburn, 2001. Page 221
  17. Alexander and Maiden, 2004. Chapter 7. Pages 119-139.


बाहरी संबंध