गोल मॉडलिंग
एक लक्ष्य मॉडल आवश्यकताओं इंजीनियरिंग का एक तत्व है जिसका उपयोग व्यावसायिक विश्लेषण में भी अधिक व्यापक रूप से किया जा सकता है। संबंधित तत्वों में हितधारक विश्लेषण, संदर्भ विश्लेषण और परिदृश्य (कंप्यूटिंग) शामिल हैं।[1] अन्य व्यावसायिक और तकनीकी क्षेत्रों के बीच।
सिद्धांत
लक्ष्य वे उद्देश्य हैं जिन्हें एक प्रणाली को इच्छित सॉफ़्टवेयर और पर्यावरण में अभिनेताओं के सहयोग के माध्यम से प्राप्त करना चाहिए।[2] लक्ष्य मॉडलिंग किसी परियोजना के शुरुआती चरणों में विशेष रूप से उपयोगी है। परियोजनाएं इस बात पर विचार कर सकती हैं कि इच्छित प्रणाली संगठनात्मक लक्ष्यों को कैसे पूरा करती है (यह भी देखें)। [3]), इस प्रणाली की आवश्यकता क्यों है और हितधारकों के हितों को कैसे संबोधित किया जा सकता है।[4] एक लक्ष्य मॉडल:
- एक सिस्टम और उसके पर्यावरण के बीच संबंधों को व्यक्त करता है (अर्थात न केवल सिस्टम को क्या करना चाहिए, बल्कि क्यों करना चाहिए)। किसी सिस्टम की आवश्यकता क्यों है, इसके संदर्भ में यह जो समझ मिलती है, वह उपयोगी है क्योंकि सिस्टम का उपयोग लंबे समय से स्थापित प्रथाओं को स्वचालित करने के बजाय व्यावसायिक प्रक्रियाओं को मौलिक रूप से बदलने के लिए किया जा रहा है।[5][6]
- आवश्यकताओं को स्पष्ट करता है: लक्ष्य निर्दिष्ट करने से यह पूछा जाता है कि क्यों, कैसे और कैसे।[5]इस प्रक्रिया में हितधारकों की आवश्यकताएं अक्सर सामने आ जाती हैं, जिससे या तो आवश्यकताएं गायब होने या अति-निर्दिष्टीकरण (उन चीजों की मांग करना जिनकी जरूरत नहीं है) का जोखिम कम होता है।
- बड़े लक्ष्यों को छोटे, प्राप्य लक्ष्यों में विश्लेषित करने की अनुमति देता है:
- संघर्षों से निपटता है: लक्ष्य मॉडलिंग लागत, प्रदर्शन, लचीलेपन, सुरक्षा और अन्य लक्ष्यों के बीच ट्रेडऑफ़ को पहचानने और हल करने में मदद कर सकता है। यह हितधारकों के बीच भिन्न हितों को प्रकट कर सकता है। यह संघर्षों की पहचान कर सकता है क्योंकि एक लक्ष्य को पूरा करना अन्य लक्ष्यों को पूरा करने में हस्तक्षेप कर सकता है।[5]* आवश्यकता पूर्णता को मापने में सक्षम बनाता है: यदि लक्ष्य मॉडल में सभी लक्ष्यों को पूरा किया जाता है तो आवश्यकताओं को पूर्ण माना जा सकता है।
- आवश्यकताओं को डिजाइन से जोड़ता है: उदाहरण के लिए, i* गैर-कार्यात्मक आवश्यकताएं (एनएफआर) ढांचा डिजाइन प्रक्रिया को निर्देशित करने के लिए लक्ष्यों का उपयोग करता है।
नोटेशन
सॉफ़्टवेयर विकास में लक्ष्य मॉडल के लिए कई नोटेशन उपयोग में हैं, जिनमें शामिल हैं:
- i* (उच्चारण आई-स्टार) और एक भिन्न, लक्ष्य-उन्मुख आवश्यकताएँ भाषा[7]
- केएओएस (सॉफ्टवेयर डेवलपमेंट)[8]
- एकीकृत मॉडलिंग भाषा उपयोग केस आरेख[9]
शोधकर्ताओं द्वारा अन्य संकेतन प्रस्तावित किए गए हैं,[10] जबकि लक्ष्य संरचना संकेतन (जीएसएन) और जीआरएल का उपयोग कभी-कभी सुरक्षा से संबंधित उद्योगों में नियामक को संतुष्ट करने के लिए सुरक्षा मामले बनाने के लिए किया जाता है।[11][12]
===i*=== में लक्ष्य मॉडलिंग
I* लक्ष्य मॉडलिंग नोटेशन दो प्रकार के आरेख प्रदान करता है:[13]
- रणनीतिक निर्भरता (एसडी), विशिष्ट लक्ष्यों के संदर्भ में भूमिकाओं के बीच संबंधों को परिभाषित करना जो एक भूमिका प्रदान करने के लिए दूसरी भूमिका पर निर्भर करती है।
- रणनीतिक तर्क (एसआर), एसडी मॉडल पर पहचाने गए लक्ष्यों का सहायक लक्ष्यों और कार्यों में विश्लेषण करना।
i* प्रत्येक भूमिका (एक अभिनेता, एजेंट या पद) को एक बड़े वृत्त के रूप में दिखाता है जिसमें उस भूमिका के लक्ष्य, कार्य और संसाधन शामिल होते हैं। i* में स्वामित्व का अर्थ है कि भूमिका अपने लक्ष्यों की संतुष्टि चाहती है, या तो अपने लाभ के लिए या किसी अन्य भूमिका के लाभ के लिए। लक्ष्यों के साथ-साथ बाधाएँ (नकारात्मक लक्ष्य) भी पार करनी पड़ सकती हैं। गैर-कार्यात्मक लक्ष्यों को i* में नरम लक्ष्यों के रूप में तैयार किया जा सकता है: उन्हें बादलों या इंडेंटेड अंडाकार के रूप में चित्रित किया जाता है।
KAOS में लक्ष्य मॉडलिंग
केएओएस लक्ष्य मॉडलिंग नोटेशन लक्ष्यों और बाधाओं को परिभाषित करने का एक तरीका प्रदान करता है, जो विश्लेषण की औपचारिक (गणितीय) पद्धति पर आधारित है।[8]
यूएमएल में लक्ष्य मॉडलिंग
यूएमएल का उपयोग केस आरेख एक सरल लक्ष्य मॉडलिंग संकेतन प्रदान करता है। बुलबुले नाम कार्यात्मक लक्ष्य,[14] इसलिए उपयोग केस आरेख एक सरल कार्य-केवल लक्ष्य मॉडल बनाता है: जैसा कि कॉकबर्न लिखते हैं, उपयोग के मामले केवल व्यवहार संबंधी आवश्यकताओं को कवर करते हैं।[15] भूमिकाओं को अभिनेताओं (आरेख पर स्टिकमैन) के रूप में दिखाया गया है, जो उन उपयोग मामलों से जुड़े हुए हैं जिनमें वे भाग लेते हैं। उपयोग के मामलों को अण्डाकार बुलबुले के रूप में तैयार किया गया है, जो वांछित व्यवहार लक्ष्यों का प्रतिनिधित्व करते हैं।[16] दुरुपयोग के मामलों को जोड़ने के साथ, नोटेशन वांछित लक्ष्यों और सक्रिय खतरों दोनों को मॉडल कर सकता है। दुरुपयोग मामले का नोटेशन दुरुपयोग के मामलों के लिए प्राथमिक अभिनेताओं के रूप में नकारात्मक (संभवतः शत्रुतापूर्ण) हितधारकों को दिखाता है; इन्हें आरेख के दाईं ओर समूहीकृत किया जा सकता है। यह नोटेशन सहायक उपयोग के मामलों के रूप में दिखाए गए उपयुक्त शमन या निवारक लक्ष्यों की खोज में सहायता कर सकता है। इनका उद्देश्य अक्सर सुरक्षा, सुरक्षा या विश्वसनीयता में सुधार करना होता है, जो गैर-कार्यात्मक लक्ष्य हैं। नकारात्मक लक्ष्यों को परिभाषित करने के लिए दुरुपयोग के मामलों का उपयोग करके गैर-कार्यात्मक आवश्यकताओं को कुछ हद तक उपयोग केस शैली में वर्णित किया जा सकता है; लेकिन इस प्रकार खोजे गए (सकारात्मक) लक्ष्य अक्सर कार्यात्मक होते हैं। उदाहरण के लिए, यदि चोरी सुरक्षा के लिए खतरा है, तो ताले लगाना एक शमन है; लेकिन एक दरवाज़ा बंद किया जा सकता है यह एक कार्यात्मक आवश्यकता है।[17] प्रतिवाद यह है कि उपयोग के मामले संज्ञानात्मक विज्ञान की जड़ों से नहीं हैं, जबकि i* और KAOS हैं। दरअसल, उपयोग के मामलों के पीछे के साहित्य में लक्ष्य इरादे, लक्ष्य शोधन, अंत-साधन पर चर्चा शामिल नहीं है, रासमुसेन वगैरह का जिक्र नहीं है। संज्ञानात्मक विज्ञान के अनुसार लक्ष्य शोधन के शब्दार्थ के बजाय लक्ष्यों के दृश्य रूपक के कारण उपयोग के मामलों को लक्ष्यों से जोड़ने की प्रवृत्ति हो सकती है।
ग्रन्थसूची
- Alexander, Ian and Beus-Dukic, Ljerka. Discovering Requirements: How to Specify Products and Services. Wiley, 2009.
- Alexander, Ian F. and Maiden, Neil. Scenarios, Stories, Use Cases. Wiley, 2004.
- Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
- Fowler, Martin. UML Distilled. 3rd Edition. Addison-Wesley, 2004.
- van Lamsweerde, Axel. Requirements Engineering: from system goals to UML models to software specifications. Wiley, 2009.
- Yu, Eric, Paolo Giorgini, Neil Maiden and John Mylopoulos. (editors) Social Modeling for Requirements Engineering. MIT Press, 2011.
यह भी देखें
संदर्भ
- ↑ Alexander and Beus-Dukic, 2009. Pages 17-18
- ↑ 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.
- ↑ 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.
- ↑ E. Yu, "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering", 1997 IEEE
- ↑ 5.0 5.1 5.2 Eric Yu and John Mylopoulos. "लक्ष्य-उन्मुख आवश्यकताएँ इंजीनियरिंग क्यों". University of Toronto.
- ↑ 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.
- ↑ Yu et al, 2011.
- ↑ 8.0 8.1 van Lamsweerde, 2009.
- ↑ Fowler, 2004. Pages 99-105
- ↑ Rolland, Colette; Prakash, Naveen; Benjamen, Adolphe (1999). "प्रक्रिया मॉडलिंग का एक बहु-मॉडल दृश्य" (PDF). Requirements Engineering. 4 (4): 169–187. doi:10.1007/s007660050018. S2CID 6988662.
- ↑ GSN Community Standard
- ↑ 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.
- ↑ Yu, Eric (September 6, 2011). "मैं*". i*: an agent- and goal-oriented modelling framework. University of Toronto. Retrieved December 17, 2011.
- ↑ Alexander and Beus-Dukic, 2009. Page 121
- ↑ Cockburn, 2001. Page 62
- ↑ Cockburn, 2001. Page 221
- ↑ Alexander and Maiden, 2004. Chapter 7. Pages 119-139.
बाहरी संबंध
- i* Official Website, with tutorial and bibliography - "an agent- and goal-oriented modelling framework"
- i* wiki with guidelines and examples
- KAOS tutorial
- Using EEML for Combined Goal and Process Oriented Modeling: A Case Study - John Krogstie
