गोल मॉडलिंग: Difference between revisions
From Vigyanwiki
(Created page with "एक लक्ष्य मॉडल आवश्यकताओं इंजीनियरिंग का एक तत्व है जिसका उपयोग व...") |
No edit summary |
||
| Line 1: | Line 1: | ||
एक | एक गोल मॉडल आवश्यकताओं इंजीनियरिंग का एक तत्व है जिसका उपयोग [[व्यावसायिक विश्लेषण]] में भी अधिक व्यापक रूप से किया जा सकता है। संबंधित तत्वों में [[हितधारक विश्लेषण]], [[संदर्भ विश्लेषण]] और [[परिदृश्य (कंप्यूटिंग)]] शामिल हैं।<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 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>{{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* गैर-कार्यात्मक आवश्यकताएं (एनएफआर) ढांचा डिजाइन प्रक्रिया को निर्देशित करने के लिए लक्ष्यों का उपयोग करता है। | * आवश्यकताओं को डिजाइन से जोड़ता है: उदाहरण के लिए, 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>{{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* | 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> | ||
* रणनीतिक निर्भरता (एसडी), विशिष्ट लक्ष्यों के संदर्भ में भूमिकाओं के बीच संबंधों को परिभाषित करना जो एक भूमिका प्रदान करने के लिए दूसरी भूमिका पर निर्भर करती है। | * रणनीतिक निर्भरता (एसडी), विशिष्ट लक्ष्यों के संदर्भ में भूमिकाओं के बीच संबंधों को परिभाषित करना जो एक भूमिका प्रदान करने के लिए दूसरी भूमिका पर निर्भर करती है। | ||
* रणनीतिक तर्क (एसआर), एसडी मॉडल पर पहचाने गए लक्ष्यों का सहायक लक्ष्यों और कार्यों में विश्लेषण करना। | * रणनीतिक तर्क (एसआर), एसडी मॉडल पर पहचाने गए लक्ष्यों का सहायक लक्ष्यों और कार्यों में विश्लेषण करना। | ||
| Line 28: | Line 28: | ||
i* प्रत्येक भूमिका (एक अभिनेता, एजेंट या पद) को एक बड़े वृत्त के रूप में दिखाता है जिसमें उस भूमिका के लक्ष्य, कार्य और संसाधन शामिल होते हैं। i* में स्वामित्व का अर्थ है कि भूमिका अपने लक्ष्यों की संतुष्टि चाहती है, या तो अपने लाभ के लिए या किसी अन्य भूमिका के लाभ के लिए। लक्ष्यों के साथ-साथ बाधाएँ (नकारात्मक लक्ष्य) भी पार करनी पड़ सकती हैं। गैर-कार्यात्मक लक्ष्यों को i* में नरम लक्ष्यों के रूप में तैयार किया जा सकता है: उन्हें बादलों या इंडेंटेड अंडाकार के रूप में चित्रित किया जाता है। | i* प्रत्येक भूमिका (एक अभिनेता, एजेंट या पद) को एक बड़े वृत्त के रूप में दिखाता है जिसमें उस भूमिका के लक्ष्य, कार्य और संसाधन शामिल होते हैं। i* में स्वामित्व का अर्थ है कि भूमिका अपने लक्ष्यों की संतुष्टि चाहती है, या तो अपने लाभ के लिए या किसी अन्य भूमिका के लाभ के लिए। लक्ष्यों के साथ-साथ बाधाएँ (नकारात्मक लक्ष्य) भी पार करनी पड़ सकती हैं। गैर-कार्यात्मक लक्ष्यों को i* में नरम लक्ष्यों के रूप में तैयार किया जा सकता है: उन्हें बादलों या इंडेंटेड अंडाकार के रूप में चित्रित किया जाता है। | ||
===KAOS में | ===KAOS में गोल मॉडलिंग=== | ||
{{main article| | {{main article|केएओएस (सॉफ्टवेयर विकास)}} | ||
केएओएस | केएओएस गोल मॉडलिंग नोटेशन लक्ष्यों और बाधाओं को परिभाषित करने का एक तरीका प्रदान करता है, जो विश्लेषण की औपचारिक (गणितीय) पद्धति पर आधारित है।<ref name= "AvL 2009"/> | ||
===यूएमएल में | ===यूएमएल में गोल मॉडलिंग=== | ||
{{main article| | {{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* और KAOS हैं। दरअसल, उपयोग के मामलों के पीछे के साहित्य में | प्रतिवाद यह है कि उपयोग के मामले संज्ञानात्मक विज्ञान की जड़ों से नहीं हैं, जबकि i* और KAOS हैं। दरअसल, उपयोग के मामलों के पीछे के साहित्य में गोल इरादे, गोल शोधन, अंत-साधन पर चर्चा शामिल नहीं है, रासमुसेन वगैरह का जिक्र नहीं है। संज्ञानात्मक विज्ञान के अनुसार गोल शोधन के शब्दार्थ के बजाय लक्ष्यों के दृश्य रूपक के कारण उपयोग के मामलों को लक्ष्यों से जोड़ने की प्रवृत्ति हो सकती है। | ||
==ग्रन्थसूची== | ==ग्रन्थसूची== | ||
Revision as of 21:11, 4 August 2023
एक गोल मॉडल आवश्यकताओं इंजीनियरिंग का एक तत्व है जिसका उपयोग व्यावसायिक विश्लेषण में भी अधिक व्यापक रूप से किया जा सकता है। संबंधित तत्वों में हितधारक विश्लेषण, संदर्भ विश्लेषण और परिदृश्य (कंप्यूटिंग) शामिल हैं।[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
