गोल मॉडलिंग: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
एक गोल मॉडल आवश्यकताओं इंजीनियरिंग का एक तत्व है जिसका उपयोग [[व्यावसायिक विश्लेषण]] में भी अधिक व्यापक रूप से किया जा सकता है। संबंधित तत्वों में [[हितधारक विश्लेषण]], [[संदर्भ विश्लेषण]] और [[परिदृश्य (कंप्यूटिंग)]] शामिल हैं।<ref>Alexander and Beus-Dukic, 2009. Pages 17-18</ref> अन्य व्यावसायिक और तकनीकी क्षेत्रों के बीच।
एक '''गोल मॉडल''' रेक्विरेमेंट इंजीनियरिंग का अवयव है जिसका उपयोग [[व्यावसायिक विश्लेषण|बिज़नेस एनालिसिस]] में भी अधिक व्यापक रूप से किया जा सकता है। संबंधित एलेमेन्ट में अन्य व्यावसायिक और तकनीकी क्षेत्रों के अतिरिक्त [[हितधारक विश्लेषण|स्टेकहोल्डर एनालिसिस]] , [[संदर्भ विश्लेषण|कॉन्टेक्स्ट एनालिसिस]] और [[परिदृश्य (कंप्यूटिंग)|सिनेरियो (कंप्यूटिंग)]] सम्मिलित हैं।<ref>Alexander and Beus-Dukic, 2009. Pages 17-18</ref>  


==सिद्धांत==
==सिद्धांत==
गोल वे उद्देश्य हैं जिन्हें एक प्रणाली को इच्छित सॉफ़्टवेयर और पर्यावरण में अभिनेताओं के सहयोग के माध्यम से प्राप्त करना चाहिए।<ref>{{cite web |author=Lin Liu and Eric Yu |title=Designing information systems in social context: a goal and scenario modelling approach |url=http://www.cs.toronto.edu/~liu/publications/ISj03.pdf |publisher=University of Toronto |date=2003 |archiveurl=https://web.archive.org/web/20050205073259/http://www.cs.toronto.edu/~liu/publications/ISj03.pdf |archivedate=February 5, 2005}}</ref> गोल मॉडलिंग किसी परियोजना के शुरुआती चरणों में विशेष रूप से उपयोगी है। परियोजनाएं इस बात पर विचार कर सकती हैं कि इच्छित प्रणाली संगठनात्मक लक्ष्यों को कैसे पूरा करती है (यह भी देखें)। <ref>{{cite journal |last=Ellis-Braithwaite |first=R.|author2=Lock, R. |author3=Dawson, R. |author4= Haque B. |title=परिमाणित लक्ष्य ग्राफ़ का उपयोग करके सॉफ़्टवेयर आवश्यकताओं के रणनीतिक संरेखण का विश्लेषण करने के लिए एक दृष्टिकोण की ओर|journal=International Journal on Advances in Software |year=2013 |volume=6 |pages=119–130 |arxiv=1307.2580|bibcode=2013arXiv1307.2580E}}</ref>), इस प्रणाली की आवश्यकता क्यों है और हितधारकों के हितों को कैसे संबोधित किया जा सकता है।<ref>E. Yu, "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering", 1997 IEEE</ref>
गोल वे उद्देश्य हैं जिन्हें प्रणाली को इच्छित सॉफ़्टवेयर और पर्यावरण में एक्टर के सहयोग के माध्यम से प्राप्त करना चाहिए।<ref>{{cite web |author=Lin Liu and Eric Yu |title=Designing information systems in social context: a goal and scenario modelling approach |url=http://www.cs.toronto.edu/~liu/publications/ISj03.pdf |publisher=University of Toronto |date=2003 |archiveurl=https://web.archive.org/web/20050205073259/http://www.cs.toronto.edu/~liu/publications/ISj03.pdf |archivedate=February 5, 2005}}</ref> गोल मॉडलिंग किसी परियोजना के प्रारंभिक चरणों में विशेष रूप से उपयोगी है। परियोजनाएं इस बात पर विचार कर सकती हैं कि इच्छित प्रणाली संगठनात्मक गोल को कैसे पूरा करती है (यह भी देखें)। <ref>{{cite journal |last=Ellis-Braithwaite |first=R.|author2=Lock, R. |author3=Dawson, R. |author4= Haque B. |title=परिमाणित लक्ष्य ग्राफ़ का उपयोग करके सॉफ़्टवेयर आवश्यकताओं के रणनीतिक संरेखण का विश्लेषण करने के लिए एक दृष्टिकोण की ओर|journal=International Journal on Advances in Software |year=2013 |volume=6 |pages=119–130 |arxiv=1307.2580|bibcode=2013arXiv1307.2580E}}</ref>), इस प्रणाली की आवश्यकता क्यों है और स्टेकहोल्डर को कैसे संबोधित किया जा सकता है।<ref>E. Yu, "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering", 1997 IEEE</ref>
एक गोल मॉडल:
 
* एक सिस्टम और उसके पर्यावरण के बीच संबंधों को व्यक्त करता है (अर्थात न केवल सिस्टम को क्या करना चाहिए, बल्कि क्यों करना चाहिए)। किसी सिस्टम की आवश्यकता क्यों है, इसके संदर्भ में यह जो समझ मिलती है, वह उपयोगी है क्योंकि सिस्टम का उपयोग लंबे समय से स्थापित प्रथाओं को स्वचालित करने के बजाय व्यावसायिक प्रक्रियाओं को मौलिक रूप से बदलने के लिए किया जा रहा है।<ref name=ericyu>{{cite web |author=Eric Yu and John Mylopoulos |title=लक्ष्य-उन्मुख आवश्यकताएँ इंजीनियरिंग क्यों|url=http://www.cs.toronto.edu/pub/eric/REFSQ98.html |publisher=University of Toronto}}</ref><ref>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.</ref>
एक गोल मॉडल:
* आवश्यकताओं को स्पष्ट करता है: गोल निर्दिष्ट करने से यह पूछा जाता है कि क्यों, कैसे और कैसे।<ref name=ericyu/>इस प्रक्रिया में हितधारकों की आवश्यकताएं अक्सर सामने आ जाती हैं, जिससे या तो आवश्यकताएं गायब होने या अति-निर्दिष्टीकरण (उन चीजों की मांग करना जिनकी जरूरत नहीं है) का जोखिम कम होता है।
* एक सिस्टम और उसके पर्यावरण के बीच संबंधों को व्यक्त करता है (अर्थात न केवल सिस्टम को क्या करना चाहिए, किन्तु क्यों करना चाहिए)। किसी सिस्टम की आवश्यकता क्यों है, इसके संदर्भ में यह जो समझ मिलती है, वह उपयोगी है क्योंकि सिस्टम का उपयोग लंबे समय से स्थापित प्रथाओं को स्वचालित करने के अतिरिक्त व्यावसायिक प्रक्रियाओं को मौलिक रूप से बदलने के लिए किया जा रहा है।<ref name="ericyu">{{cite web |author=Eric Yu and John Mylopoulos |title=लक्ष्य-उन्मुख आवश्यकताएँ इंजीनियरिंग क्यों|url=http://www.cs.toronto.edu/pub/eric/REFSQ98.html |publisher=University of Toronto}}</ref><ref>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.</ref>
* बड़े लक्ष्यों को छोटे, प्राप्य लक्ष्यों में विश्लेषित करने की अनुमति देता है:
* आवश्यकताओं को स्पष्ट करता है: गोल निर्दिष्ट करने से यह पूछा जाता है कि क्यों, कैसे और कैसे<ref name="ericyu" /> इस प्रक्रिया में स्टेकहोल्डर की आवश्यकताएं अधिकांशतः सामने आ जाती हैं, जिससे या तो आवश्यकताएं अदृश्य होने या अति-निर्दिष्टीकरण (उन चीजों की मांग करना जिनकी जरूरत नहीं है) का ख़तरा कम होता है।
* संघर्षों से निपटता है: गोल मॉडलिंग लागत, प्रदर्शन, लचीलेपन, सुरक्षा और अन्य लक्ष्यों के बीच ट्रेडऑफ़ को पहचानने और हल करने में मदद कर सकता है। यह हितधारकों के बीच भिन्न हितों को प्रकट कर सकता है। यह संघर्षों की पहचान कर सकता है क्योंकि एक  गोल को पूरा करना अन्य लक्ष्यों को पूरा करने में हस्तक्षेप कर सकता है।<ref name=ericyu/>* आवश्यकता पूर्णता को मापने में सक्षम बनाता है: यदि गोल मॉडल में सभी लक्ष्यों को पूरा किया जाता है तो आवश्यकताओं को पूर्ण माना जा सकता है।
* बड़े गोल को छोटे, प्राप्य गोल में विश्लेषित करने की अनुमति देता है:
* आवश्यकताओं को डिजाइन से जोड़ता है: उदाहरण के लिए, i* गैर-कार्यात्मक आवश्यकताएं (एनएफआर) ढांचा डिजाइन प्रक्रिया को निर्देशित करने के लिए लक्ष्यों का उपयोग करता है।
* संघर्षों से निपटता है: गोल मॉडलिंग निवेश, प्रदर्शन, लचीलेपन, सुरक्षा और अन्य गोल के बीच ट्रेडऑफ़ को पहचानने और हल करने में सहायता कर सकता है। यह स्टेकहोल्डर के बीच भिन्न रुचियाँ को प्रकट कर सकता है। यह संघर्षों की पहचान कर सकता है क्योंकि गोल को पूरा करना अन्य गोल को पूरा करने में हस्तक्षेप कर सकता है।<ref name="ericyu" />
*आवश्यकता पूर्णता को मापने में सक्षम बनाता है: यदि गोल मॉडल में सभी गोल को पूरा किया जाता है तो आवश्यकताओं को पूर्ण माना जा सकता है।
* आवश्यकताओं को डिजाइन से जोड़ता है: उदाहरण के लिए, i* नॉन-फंक्शनल रेक्विरेमेंट (एनएफआर) फ्रेम वर्क डिजाइन प्रक्रिया को निर्देशित करने के लिए गोल का उपयोग करता है।


==नोटेशन==
==नोटेशन==


सॉफ़्टवेयर विकास में गोल मॉडल के लिए कई नोटेशन उपयोग में हैं, जिनमें शामिल हैं:
सॉफ़्टवेयर विकास में गोल मॉडल के लिए कई नोटेशन उपयोग में हैं, जिनमें सम्मिलित हैं:
* [[i*]] (उच्चारण आई-स्टार) और एक भिन्न, [[लक्ष्य-उन्मुख आवश्यकताएँ भाषा]]<ref>Yu et al, 2011.</ref>
* [[i*]] (उच्चारण आई-स्टार) और भिन्न, [[लक्ष्य-उन्मुख आवश्यकताएँ भाषा|गोल-ओरिएंटेड रेक्विरेमेंट लैंग्वेज]]<ref>Yu et al, 2011.</ref>
* केएओएस (सॉफ्टवेयर डेवलपमेंट)<ref name= "AvL 2009">[[Axel van Lamsweerde|van Lamsweerde]], 2009.</ref>
* केएओएस (सॉफ्टवेयर डेवलपमेंट)<ref name= "AvL 2009">[[Axel van Lamsweerde|van Lamsweerde]], 2009.</ref>
* [[एकीकृत मॉडलिंग भाषा]] उपयोग केस आरेख<ref>Fowler, 2004. Pages 99-105</ref>
* [[एकीकृत मॉडलिंग भाषा|एकीकृत मॉडलिंग लैंग्वेज]] उपयोग केस आरेख<ref>Fowler, 2004. Pages 99-105</ref>
शोधकर्ताओं द्वारा अन्य संकेतन प्रस्तावित किए गए हैं,<ref>{{cite journal |author=Rolland, Colette | author-link=Colette Rolland |author2=Prakash, Naveen |author3=Benjamen, Adolphe | title=प्रक्रिया मॉडलिंग का एक बहु-मॉडल दृश्य| journal=Requirements Engineering | year=1999 | volume=4 | issue=4 | pages=169–187 | url=http://hal.archives-ouvertes.fr/docs/00/70/75/68/PDF/A_multi_model_view_REJ.pdf| doi=10.1007/s007660050018 | s2cid=6988662 }}</ref> जबकि गोल संरचना संकेतन (जीएसएन) और जीआरएल का उपयोग कभी-कभी सुरक्षा से संबंधित उद्योगों में नियामक को संतुष्ट करने के लिए सुरक्षा मामले बनाने के लिए किया जाता है।<ref>[http://www.goalstructuringnotation.info GSN Community Standard]</ref><ref>{{Cite book |last=Feodoroff |first=R. |title=2016 Annual IEEE Systems Conference (SysCon) |chapter=Intentional enterprise architecture |date=2016 |pages=1–8 |doi=10.1109/SYSCON.2016.7490555|isbn=978-1-4673-9519-9 |s2cid=206586399 }}</ref>
शोधकर्ताओं द्वारा अन्य संकेतन प्रस्तावित किए गए हैं,<ref>{{cite journal |author=Rolland, Colette | author-link=Colette Rolland |author2=Prakash, Naveen |author3=Benjamen, Adolphe | title=प्रक्रिया मॉडलिंग का एक बहु-मॉडल दृश्य| journal=Requirements Engineering | year=1999 | volume=4 | issue=4 | pages=169–187 | url=http://hal.archives-ouvertes.fr/docs/00/70/75/68/PDF/A_multi_model_view_REJ.pdf| doi=10.1007/s007660050018 | s2cid=6988662 }}</ref> जबकि गोल संरचना संकेतन (जीएसएन) और जीआरएल का उपयोग कभी-कभी सुरक्षा से संबंधित उद्योगों में नियामक को संतुष्ट करने के लिए सुरक्षित स्थिति बनाने के लिए किया जाता है।<ref>[http://www.goalstructuringnotation.info GSN Community Standard]</ref><ref>{{Cite book |last=Feodoroff |first=R. |title=2016 Annual IEEE Systems Conference (SysCon) |chapter=Intentional enterprise architecture |date=2016 |pages=1–8 |doi=10.1109/SYSCON.2016.7490555|isbn=978-1-4673-9519-9 |s2cid=206586399 }}</ref>
 


===i*=== में  गोल  मॉडलिंग
==== i* में गोल मॉडलिंग ====
{{main article|i*}}
{{main article|i*}}


I* गोल मॉडलिंग नोटेशन दो प्रकार के आरेख प्रदान करता है:<ref name="i*">{{cite web | url=http://www.cs.toronto.edu/km/istar/ | title=मैं*| publisher=University of Toronto | work=i*: an agent- and goal-oriented modelling framework | date=September 6, 2011 | accessdate=December 17, 2011 | author=Yu, Eric}}</ref>
I* गोल मॉडलिंग नोटेशन दो प्रकार के आरेख प्रदान करता है:<ref name="i*">{{cite web | url=http://www.cs.toronto.edu/km/istar/ | title=मैं*| publisher=University of Toronto | work=i*: an agent- and goal-oriented modelling framework | date=September 6, 2011 | accessdate=December 17, 2011 | author=Yu, Eric}}</ref>
* रणनीतिक निर्भरता (एसडी), विशिष्ट लक्ष्यों के संदर्भ में भूमिकाओं के बीच संबंधों को परिभाषित करना जो एक भूमिका प्रदान करने के लिए दूसरी भूमिका पर निर्भर करती है।
* रणनीतिक निर्भरता (एसडी), विशिष्ट गोल के संदर्भ में भूमिकाओं के बीच संबंधों को परिभाषित करना जो भूमिका प्रदान करने के लिए दूसरी भूमिका पर निर्भर करती है।
* रणनीतिक तर्क (एसआर), एसडी मॉडल पर पहचाने गए लक्ष्यों का सहायक लक्ष्यों और कार्यों में विश्लेषण करना।
* रणनीतिक तर्क (एसआर), एसडी मॉडल पर पहचाने गए गोल का सहायक गोल और कार्यों में एनालिसिस करना है।


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


===KAOS में गोल मॉडलिंग===
===केएओएस में गोल मॉडलिंग===
{{main article|केएओएस (सॉफ्टवेयर विकास)}}
{{main article|केएओएस (सॉफ्टवेयर विकास)}}


केएओएस गोल मॉडलिंग नोटेशन लक्ष्यों और बाधाओं को परिभाषित करने का एक तरीका प्रदान करता है, जो विश्लेषण की औपचारिक (गणितीय) पद्धति पर आधारित है।<ref name= "AvL 2009"/>
केएओएस गोल मॉडलिंग नोटेशन गोल और बाधाओं को परिभाषित करने का विधि प्रदान करता है, जो एनालिसिस की औपचारिक (गणितीय) पद्धति पर आधारित है।<ref name= "AvL 2009"/>
===यूएमएल में गोल मॉडलिंग===
{{main article|केस आरेख का प्रयोग करें}}


यूएमएल का उपयोग केस आरेख सरल गोल मॉडलिंग संकेतन प्रदान करता है। बबल नाम के कार्यात्मक लक्ष्य,<ref>Alexander and Beus-Dukic, 2009. Page 121</ref> इसलिए उपयोग केस आरेख सरल कार्य-केवल गोल मॉडल बनाता है: जैसा कि कॉकबर्न लिखते हैं, जो कि उपयोग के स्थिति में केवल व्यवहार संबंधी आवश्यकताओं को आवरण करते हैं।<ref>Cockburn, 2001. Page 62</ref> भूमिकाओं को एक्टर्स (आरेख पर स्टिकमैन) के रूप में दिखाया गया है, जो उन उपयोग स्थितियों से जुड़े हुए हैं जिनमें वे भाग लेते हैं। उपयोग के स्थितियों को ओवल बबल के रूप में तैयार किया गया है, जो वांछित व्यवहार गोल का प्रतिनिधित्व करते हैं।<ref>Cockburn, 2001. Page 221</ref> दुरुपयोग के स्थितियों को जोड़ने के साथ, नोटेशन वांछित गोल और सक्रिय खतरों दोनों को मॉडल कर सकता है। दुरुपयोग स्थिति का नोटेशन दुरुपयोग के स्थितियों के लिए प्राथमिक एक्टर्स के रूप में ऋणात्मक (संभवतः शत्रुतापूर्ण) स्टेकहोल्डर को दिखाता है; इन्हें आरेख के दाईं ओर समूहीकृत किया जा सकता है। यह नोटेशन सहायक उपयोग के स्थितियों के रूप में दिखाए गए उपयुक्त शमन या निवारक गोल की खोज में सहायता कर सकता है। इनका उद्देश्य अधिकांशतः [[सुरक्षा]], या विश्वसनीयता में सुधार करना होता है, जो गैर-कार्यात्मक गोल हैं। ऋणात्मक गोल को परिभाषित करने के लिए दुरुपयोग के स्थितियों का उपयोग करके [[गैर-कार्यात्मक आवश्यकता]]ओं को कुछ सीमा तक उपयोग केस शैली में वर्णित किया जा सकता है; किन्तु इस प्रकार खोजे गए (धनात्मक) गोल अधिकांशतः कार्यात्मक होते हैं। उदाहरण के लिए, यदि चोरी से सुरक्षा के लिए खतरा है, तो ताले लगाना न्यूनीकरण है; किन्तु दरवाज़ा संवर्त किया जा सकता है यह कार्यात्मक आवश्यकता है।<ref name=MisuseCase>Alexander and Maiden, 2004. Chapter 7. Pages 119-139.</ref>


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


यूएमएल का उपयोग केस आरेख एक सरल  गोल  मॉडलिंग संकेतन प्रदान करता है। बुलबुले नाम कार्यात्मक लक्ष्य,<ref>Alexander and Beus-Dukic, 2009. Page 121</ref> इसलिए उपयोग केस आरेख एक सरल कार्य-केवल  गोल  मॉडल बनाता है: जैसा कि कॉकबर्न लिखते हैं, उपयोग के मामले केवल व्यवहार संबंधी आवश्यकताओं को कवर करते हैं।<ref>Cockburn, 2001. Page 62</ref> भूमिकाओं को अभिनेताओं (आरेख पर स्टिकमैन) के रूप में दिखाया गया है, जो उन उपयोग मामलों से जुड़े हुए हैं जिनमें वे भाग लेते हैं। उपयोग के मामलों को अण्डाकार बुलबुले के रूप में तैयार किया गया है, जो वांछित व्यवहार लक्ष्यों का प्रतिनिधित्व करते हैं।<ref>Cockburn, 2001. Page 221</ref>
==बिबलियोग्राफी ==
दुरुपयोग के मामलों को जोड़ने के साथ, नोटेशन वांछित लक्ष्यों और सक्रिय खतरों दोनों को मॉडल कर सकता है। दुरुपयोग मामले का नोटेशन दुरुपयोग के मामलों के लिए प्राथमिक अभिनेताओं के रूप में नकारात्मक (संभवतः शत्रुतापूर्ण) हितधारकों को दिखाता है; इन्हें आरेख के दाईं ओर समूहीकृत किया जा सकता है। यह नोटेशन सहायक उपयोग के मामलों के रूप में दिखाए गए उपयुक्त शमन या निवारक लक्ष्यों की खोज में सहायता कर सकता है। इनका उद्देश्य अक्सर [[सुरक्षा]], सुरक्षा या विश्वसनीयता में सुधार करना होता है, जो गैर-कार्यात्मक  गोल  हैं। नकारात्मक लक्ष्यों को परिभाषित करने के लिए दुरुपयोग के मामलों का उपयोग करके [[गैर-कार्यात्मक आवश्यकता]]ओं को कुछ हद तक उपयोग केस शैली में वर्णित किया जा सकता है; लेकिन इस प्रकार खोजे गए (सकारात्मक)  गोल  अक्सर कार्यात्मक होते हैं। उदाहरण के लिए, यदि चोरी सुरक्षा के लिए खतरा है, तो ताले लगाना एक शमन है; लेकिन एक दरवाज़ा बंद किया जा सकता है यह एक कार्यात्मक आवश्यकता है।<ref name=MisuseCase>Alexander and Maiden, 2004. Chapter 7. Pages 119-139.</ref>
* अलेक्जेंडर, इयान और ब्यूस-डुकिक, लेजेर्का आवश्यकताओं की खोज: उत्पादों और सेवाओं को कैसे निर्दिष्ट करें विली, 2009.
प्रतिवाद यह है कि उपयोग के मामले संज्ञानात्मक विज्ञान की जड़ों से नहीं हैं, जबकि i* और KAOS हैं। दरअसल, उपयोग के मामलों के पीछे के साहित्य में  गोल  इरादे,  गोल  शोधन, अंत-साधन पर चर्चा शामिल नहीं है, रासमुसेन वगैरह का जिक्र नहीं है। संज्ञानात्मक विज्ञान के अनुसार  गोल  शोधन के शब्दार्थ के बजाय लक्ष्यों के दृश्य रूपक के कारण उपयोग के मामलों को लक्ष्यों से जोड़ने की प्रवृत्ति हो सकती है।
* अलेक्जेंडर, इयान एफ. और मेडेन, नील परिदृश्य, कहानियाँ, उपयोग के स्थिति विली, 2004.
 
* कॉकबर्न, एलिस्टेयर प्रभावी उपयोग के स्थिति लिखना एडिसन-वेस्ले, 2001.
==ग्रन्थसूची==
* फाउलर, मार्टिन यूएमएल आसुत. तीसरा संस्करण. एडिसन-वेस्ले, 2004.
* Alexander, Ian and Beus-Dukic, Ljerka. ''Discovering Requirements: How to Specify Products and Services''. Wiley, 2009.
* वैन लैम्सवेर्डे, एक्सल आवश्यकताएँ इंजीनियरिंग: सिस्टम गोल से लेकर यूएमएल मॉडल से लेकर सॉफ्टवेयर विनिर्देशों तक। विली, 2009.
* Alexander, Ian F. and Maiden, Neil. ''Scenarios, Stories, Use Cases''. Wiley, 2004.
* यू, एरिक, पाओलो जियोर्जिनी, नील मेडेन और जॉन मायलोपोलोस (संपादक) रिक्वायरमेंट्स इंजीनियरिंग के लिए सोशल मॉडलिंग एमआईटी प्रेस, 2011।
* [[Cockburn, Alistair]]. ''Writing Effective Use Cases''. Addison-Wesley, 2001.  
* [[Martin Fowler (software engineer)|Fowler, Martin]]. ''UML Distilled''. 3rd Edition. Addison-Wesley, 2004.
* [[Axel van Lamsweerde|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.




==यह भी देखें==
==यह भी देखें==
*[[लाभ निर्भरता नेटवर्क]]
*[[लाभ निर्भरता नेटवर्क|बेनिफिट डिपेंडेंसी नेटवर्क]]


==संदर्भ==
==संदर्भ==
Line 58: Line 57:


==बाहरी संबंध==
==बाहरी संबंध==
* [http://www.cs.toronto.edu/km/istar/ i* Official Website, with tutorial and bibliography] - "an agent- and goal-oriented modelling framework"
* [http://www.cs.toronto.edu/km/istar/ i* Official Website, with tutorial and bibliography] - "an agent- and goal-oriented modelling framework"
* [https://sites.google.com/site/istarlanguage/home i* wiki with guidelines and examples]
* [https://sites.google.com/site/istarlanguage/home i* wiki with guidelines and examples]
* [http://www.objectiver.com/fileadmin/download/documents/KaosTutorial.pdf KAOS tutorial]
* [http://www.objectiver.com/fileadmin/download/documents/KaosTutorial.pdf KAOS tutorial]
* [http://ceur-ws.org/Vol-337/paper9.pdf Using EEML for Combined Goal and Process Oriented Modeling: A Case Study] - John Krogstie
* [http://ceur-ws.org/Vol-337/paper9.pdf Using EEML for Combined Goal and Process Oriented Modeling: A Case Study] - John Krogstie
[[Category: उद्यम मॉडलिंग]] [[Category: सॉफ़्टवेयर आवश्यकताएं]] [[Category: लक्ष्य]]


[[Category: Machine Translated Page]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:Created On 25/07/2023]]
[[Category:Created On 25/07/2023]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:उद्यम मॉडलिंग]]
[[Category:लक्ष्य]]
[[Category:सॉफ़्टवेयर आवश्यकताएं]]

Latest revision as of 14:35, 11 August 2023

एक गोल मॉडल रेक्विरेमेंट इंजीनियरिंग का अवयव है जिसका उपयोग बिज़नेस एनालिसिस में भी अधिक व्यापक रूप से किया जा सकता है। संबंधित एलेमेन्ट में अन्य व्यावसायिक और तकनीकी क्षेत्रों के अतिरिक्त स्टेकहोल्डर एनालिसिस , कॉन्टेक्स्ट एनालिसिस और सिनेरियो (कंप्यूटिंग) सम्मिलित हैं।[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.


बाहरी संबंध