घटना विभाजन: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 27: Line 27:


=== अभिनेता → घटना → पता लगाएँ → प्रतिक्रिया दें ===
=== अभिनेता → घटना → पता लगाएँ → प्रतिक्रिया दें ===


इस विधि में निम्नलिखित चरण होते हैं।
इस विधि में निम्नलिखित चरण होते हैं।

Revision as of 23:34, 18 May 2023

File:ContextDiagram LastResortHotel.png
एक काल्पनिक होटल के लिए सिस्टम संदर्भ निरूपण आरेख। (रूढ़िवाद के अनुसार, जब किसी संवाद को बाह्यतः प्रारंभ किया जाता है, तो दोनों ओर सीधी बाणों के साथ दिखाए जाने वाले दोनों संवाद होते हैं। उदाहरण के लिए, "बुकिंग संवाद" में "बुकिंग अनुरोध" श्रृंखला सम्मलित है, जो प्रारंभिक प्रेरक है; "बुकिंग पुष्टि", परिणाम, वापस भेजा जाता है।)

इवेंट पार्टीशनिंग एक आसानी से लागू किया जाने वाला सिस्टम विश्लेषण तकनीक है जो सिस्टम विश्लेषण को बड़े सिस्टम के लिए आवश्यकताओं को एक संग्रह के रूप में संगठित करने में सहायता करती है। इसके द्वारा संशोधित आवश्यकताएं छोटे, सरल, न्यूनतम संपर्कित, समझने में सरल "मिनी सिस्टम" / यूज केस में व्यवस्थित की जाती हैं।

सिंहावलोकन

स्टीफन एम. मैकमेनामिन और जॉन एफ. पाल्मर द्वाराआवश्यक प्रणाली विश्लेषण में इवेंट-पार्टीशनिंग दृष्टिकोण की व्याख्या की गई है।[1] इस दृष्टिकोण का संक्षेपिक संस्करण डेटा फ्लो डायग्राम (DFD) पर लेख में वर्णित किया गया है। एडवर्ड योरडन की "बस अधिक संरचित विश्लेषण" में एक अधिक पूर्ण चर्चा दी गई है।[2] र्णन इस तकनीक का उपयोग डेटा फ्लो डायग्राम बनाने के लिए करने पर केंद्रित है, किन्तु यह यूज केस्स की पहचान के लिए भी उपयोग किया जा सकता है।

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

घटना विभाजन विषय

अभिनेता → घटना → पता लगाएँ → प्रतिक्रिया दें

इस विधि में निम्नलिखित चरण होते हैं।

  • 1. बाह्य सिस्टमों की पहचान करें: "अभिनेता" (बाह्य सिस्टम) की एक सूची तैयार करें जिसमें बाह्य घटनाओं के स्रोत सम्मलित होते हैं। यदि आपको किसी ग्राफिक की सहायता आवश्यक महसूस होती है, तो उसमें संदर्भ आरेख बनाएं जिसमें अध्ययन के अनुसार सिस्टम के बाहर अभिनेता और उनके बीच फ्लो/संकेत हों।
  • 2. "अभिनेता" के जूते में खुद को रखकर (या अभिनेता प्रतिनिधियों के साथ काम करके), सिस्टम को योजनित प्रतिक्रिया होने के लिए अभिनेता की इच्छित "बाह्य घटनाओं" / "ट्रिगर्स" की एक सूची ब्रेनस्टोर्म करें। (ध्यान दें कि सिस्टम बाह्य घटनाएं प्रारंभ नहीं कर सकता है; केवल अभिनेता कर सकता है।)
  • 3. पहचानें कि बाहरी घटनाओं का पता लगाने के लिए सिस्टम को क्या सक्षम करेगा:
    • एक या अधिक डेटा के आगमन (संदेश के रूप में संभव)
    • एक या अधिक समय बिंदुओं के आगमन (म्‍यूएल द्वारा "कालिक" घटनाओं के रूप में कहा गया है, और इसे उन्होंने बाह्य घटनाओं से अलग तय किया है)।
  • 4. नियोजित प्रतिक्रिया (प्रतिक्रियाओं) की पहचान करें जो कि घटनाओं के होने पर सिस्टम कर सकता है। यह प्रतिक्रिया (ओं)/उपयोग के स्थितियों हैं जो सिस्टम को अपने लक्ष्यों को प्राप्त करने में सक्षम बनाती हैं।

इस तकनीक को पॉल टी. वार्ड और स्टीफन जे. मेलोर द्वारा स्ट्रक्चर्ड डेवलपमेंट फॉर रियल-टाइम सिस्टम्स: एसेंशियल मॉडलिंग टेक्निक्स में इस तकनीक में "गैर-घटना" घटनाओं के साथ विस्‍तार दिया गया था।[3]

"चूंकि टर्मिनेटर (अभिनेता) सिद्धांत के अनुसार, मॉडल द्वारा प्रतिष्ठानित सिस्टम निर्माण प्रयास की सीमा के बाहर होते हैं, इसलिए क्रियान्वयकर्ताओं को टर्मिनेटर (अभिनेता) प्रौद्योगिकी को सुधारने के लिए आज्ञाकारी रूप से संशोधित नहीं कर सकते हैं। बजाय इसके, उन्हें सिस्टम के मूल मॉडल में टर्मिनेटर (अभिनेता) समस्याओं के लिए प्रतिक्रियाएँ बनानी होती हैं। टर्मिनेटर (अभिनेता) समस्याओं के प्रतिक्रियाओं के लिए मॉडलिंग करने के लिए एक उपयोगी दृष्टिकोण है 'साधारण' घटनाओं की एक सूची बनाना और फिर प्रत्येक घटना के लिए पूछना, 'क्या सिस्टम को इस घटना के साथ अपेक्षित रूप से असफल होने पर प्रतिक्रिया की आवश्यकता है?'" [4] [मेरा जोरदारी जोड़ने के लिए]

डेटा डिक्शनरी नोटेशन

डेटा डिक्शनरी नोटेशन का वर्णन करने के लिए योर्डन/डीमार्को शैली का डेटा शब्दकोश नोटेशन उपयोग किया जा सकता है।

चिह्न अर्थ
= "सम्मलित है", "है", या "इससे बना है"
+ "और", "साथ ही", या "साथ में" (अंकगणित "प्लस" नहीं)
[x ; y ; z] "x या y या z में से केवल एक का चयन करें"। सूची में वस्तुओं को अलग करने के लिए या तो अर्धविराम (;) या लंबवत बार (|) का उपयोग किया जा सकता है।
m{x}n or
m:n{x} or
"एम से एक्स के एन पुनरावृत्तियों के लिए"। यदि एम या एन निर्दिष्ट नहीं है, तो निचली या ऊपरी सीमा "अज्ञात" या "अनिर्दिष्ट" है। बहु-आयामी सरणियों को नेस्टिंग द्वारा निर्दिष्ट किया जा सकता है, उदाहरण के लिए, 10 {10 {x} 10} 10 10 कॉलम वाली 10 पंक्तियों के द्वि-आयामी मैट्रिक्स को परिभाषित करता है।
(x) "वैकल्पिक रूप से x"। यह 0{x}1 या 0:1{x} या के समान है .
@ एक पुनरावृत्ति के भीतर एक पहचानकर्ता के लिए उपसर्ग। उदाहरण के लिए, {@i+@j+x} में i और j पहचानकर्ता हैं।
* ... * सिंगल तारक के बीच कुछ भी एक टिप्पणी के रूप में माना जाता है। डेटा तत्व स्तर पर, एक टिप्पणी में "श्रेणी :", "सीमाएं:", "परिशुद्धता :", "इकाई :" या "मान:" जैसे प्रकार के टैग हो सकते हैं।

डेटा संरचना तत्व संरचित प्रोग्रामिंग की संरचित प्रोग्रामिंग # नियंत्रण संरचनाओं को मैप कर सकते हैं:

नोट: परिभाषित आइटम "सामग्री" (उदाहरण के लिए, कमरे की कुंजी) और "डेटा" (उदाहरण के लिए, आगमन तिथि-समय) हो सकते हैं।

आवश्यकताओं की पहचान करना और उनके कारण

घटना-प्रतिक्रिया सूचना एक तालिका में आकलित की जा सकती है। घटना प्रतिक्रिया के लिए "कारण" है, जो प्रतिक्रिया को पर्यावरण से "ट्रेसेबिलिटी" देता है।

1. अभिनेता 2. बाहरी घटना / ट्रिगर 3. द्वारा पता लगाया गया 4. प्रतिक्रिया (ओं) / केस का उपयोग करें
अतिथि अतिथि एक निश्चित प्रकार के कमरे का अनुरोध करता है, एक विशेष आगमन तिथि, प्रस्थान तिथि, एक निश्चित दर आदि के लिए। बुकिंग अनुरोध +

(भुगतान सत्यापन) +

(*बाहरी आरक्षण प्रणाली* बुकिंग की पुष्टि) [5]

बुक रूम (गारंटीकृत बुकिंग, वैकल्पिक होटल बुकिंग, प्रतीक्षा सूची वाली बुकिंग सम्मलित हो सकती है)
अतिथि अतिथि कमरे की बुकिंग रद्द करने के लिए कहता है। रद्दिकरण अनुरोध [6] बुकिंग रद्द करें
अतिथि अतिथि होटल में आता है। आगमन संदेश = * *
     = [अतिथि नाम; आरक्षण संदर्भ] [7]
चेक इन गेस्ट
समय / अनुसूचक अतिथि होटल में आने में विफल रहता है। [यह एक "गैर-घटना" घटना है।] रात 11 बजे (स्थानीय समय) [एक "गैर-घटना" घटना का पता एक बिंदु के समय, एक समय सीमा के आगमन से चलता है।] अतिथि बिल बनाएं,

बुकिंग अपडेट करें

अतिथि मेहमान होटल से चेक आउट करने के लिए कहता है। चेक-आउट अनुरोध = * *
     =[अतिथि नाम; रूम नंबर] [8]
अतिथि बिल बनाएं,

अद्यतन कक्ष अधिभोग

समय / अनुसूचक अतिथि होटल से चेक आउट करने में विफल रहता है। [यह एक "गैर-घटना" घटना है।] 11 पूर्वाह्न (स्थानीय समय) [एक "गैर-घटना" घटना का पता एक समय सीमा, एक समय सीमा के आगमन से चलता है।] अतिथि विधेयक बनाएँ
अतिथि अतिथि बिल का भुगतान प्रदान करता है। भुगतान वाहन = * *
     =[नकदी ; जाँच करना ; क्रेडिट कार्ड ; डेबिट कार्ड] + (अतिथि आईडी) [9]
अतिथि भुगतान स्वीकार करें
समय / अनुसूचक पिछली रात के लिए कक्ष अधिभोग रिपोर्ट तैयार करने का समय। सुबह 8 बजे (स्थानीय समय) कक्ष अधिभोग पर रिपोर्ट
सराय प्रबंधक होटल मैनेजर रूम ऑक्यूपेंसी रिपोर्ट मांगता है। अधिभोग रिपोर्ट अनुरोध कक्ष अधिभोग पर रिपोर्ट
धुआँ / सीओ अलार्म अलार्म धुएं का पता लगाता है। धूम्रपान अलार्म संदेश स्मोक अलार्म की रिपोर्ट करें
धुआँ / सीओ अलार्म अलार्म सीओ (कार्बन मोनोऑक्साइड) का पता लगाता है। सीओ अलार्म संदेश सीओ अलार्म की रिपोर्ट करें


आवश्यकताओं को परिभाषित करना

File:LastResortHotel BookRoom Process.png
डेटा प्रवाह आरेख संकेतन का उपयोग करते हुए एक काल्पनिक होटल में एकल प्रक्रिया है।
File:LastResortHotel BookRoom UseCase.png
उपयोग केस आरेख संकेतन का उपयोग करते हुए एक काल्पनिक होटल में एकल उपयोग मामला है।

यह तकनीक विश्लेषक को योजनित प्रतिक्रिया की आवश्यकता रखने वाली घटनाओं का उपयोग करके सिस्टम को "मानसिक रूप से बाइट-साइज्ड" मिनी-सिस्टम में विभाजित करने में सहायता करती है। प्रत्येक प्लान की गई प्रतिक्रिया का विस्तार "प्राथमिक यूज केस" के स्तर पर होता है। प्रत्येक योजनित प्रतिक्रिया को DFD नोटेशन का उपयोग करके मॉडल किया जा सकता है या यूज केस डायग्राम नोटेशन का उपयोग करके एकल यूज केस के रूप में मॉडल किया जा सकता है।

प्रक्रिया या यूज केस के भीतर मूल धारा को सामान्यतः कुछ ही स्टेप्स में वर्णित किया जा सकता है, अधिकांशतः बीस या तीस के कम संभवतः संरचित अंग्रेजी का उपयोग करके। आदर्श रूप से, सभी स्टेप्स एक साथ दिखाई देने चाहिए (अधिकांशतः एक पेज या इससे कम)। इसका उद्देश्य, छोटी स्मृति संबंधी एक रिस्क को कम करना है, अर्थात वह भूल जाना जो तुरंत दृश्यमान नहीं होता है ("आँखों से बाहर, मन से बाहर")।

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

जटिलता बनाम विखंडन

यदि प्रतिक्रिया लंबी या जटिल है (अर्थात, पाठ के एक पृष्ठ से अधिक), तो एक विश्लेषक मूल प्राथमिक उपयोग के स्थितियों को छोटा और सरल रखने के लिए अपघटन प्रतिमान (फैक्टर आउट या विक्ट:विशेष:खोज/डुप्लीकेशन) छोटे माध्यमिक उपयोग स्थितियों में कर सकता है। ये द्वितीयक उपयोग के स्थितियों पुन: प्रयोज्य भी सिद्ध हो सकते हैं। (यूएमएल यूज केस डायग्राम में, उन्हें यूज केस डायग्राम एक्सटेंड या यूज केस डायग्राम सम्मलित यूज केस के रूप में खींचा जाएगा, जो एक या अधिक प्राथमिक उपयोग के स्थितियों से संबंधित हैं।)

उपयोग के स्थितियों का वर्णन करते समय, एक विश्लेषक व्यावसायिक नियमों को भी प्रकट कर सकता है। कुछ विश्लेषक वस्तु बाधा भाषा या कुछ अन्य व्यावसायिक नियम # औपचारिक विनिर्देश का उपयोग करके एक अलग दस्तावेज़ में व्यावसायिक नियमों को कैप्चर करने का सुझाव देते हैं। फिर जब उपयोग के स्थितियों में व्यापार नियम का पालन किया जाना चाहिए, तो विश्लेषक इसका संदर्भ देता है। यह पुनरावृत्ति को कम करता है [10] एक विनिर्देश के भीतर, किन्तु एक विनिर्देश के विखंडन का जोखिम। इस तनाव को कम करने के लिए एक तकनीक हैपरलिंक का उपयोग करना हो सकता है जो सूचना प्रावधान दस्तावेज़ में किया जा सकता है।

यह न्यूनीकरणवाद दृष्टिकोण प्रणालियों की सोच दृष्टिकोण के विपरीत कुछ हद तक निहित है जैसा कि पीटर चेकलैंड की सॉफ्ट सिस्टम पद्धति द्वारा दर्शाया गया है।

उपयोग के स्थितियों के विवरण में कैप्चर की गई कार्यात्मक आवश्यकताओं के अतिरिक्त, एक विश्लेषक प्रतिक्रिया समय, सीखने की क्षमता आदि जैसी गैर-कार्यात्मक आवश्यकताओं को सम्मलित कर सकता है।

यह भी देखें

संदर्भ

  1. MCME-84: McMenamin, Stephen M.; John F. Palmer (1984). Essential Systems Analysis. Prentice-Hall (Yourdon Press). ISBN 0-13-287905-0. (ISBN 978-0-13-287905-7)
  2. YOUR-89: "yourdon.com - Just Enough Structured Analysis, Chapters 18, 19". 1989. Archived from the original on 2007-02-14. Retrieved 2008-04-24.
  3. WARD-85: Ward, Paul T.; Stephen J. Mellor (1985). Structured Development for Real-Time Systems: Volume 2, Essential Modeling Techniques. Prentice-Hall (Yourdon Press). ISBN 0-13-854787-4. (ISBN 978-0-13-854787-5)
  4. WARD-85, पृष्ठ 38-39.
  5. booking dialogue = * *
         = *input* booking request + *output* booking confirmation
    booking request = * *
         = guest name + room type + (room facilities) +
           arrival date-time + departure date-time
    room type = * type of bedroom *
         = * values : [ single ; double ; family ] *
    room facilities = * booleans that indicate presence or absence of a facility *
         = television + radio + alarm clock + climate control + Internet access +
           telephone + refrigerator + mini-bar + toilet + sink + bath + shower + bidet
    arrival date-time = * *
         = date-time
    departure date-time = * *
         = date-time
    date-time = * ISO 8601 format *
         = year + month + day of month + 'T' + hour + minute >
  6. cancellation dialogue = * *
         = *input* cancellation request + *output* cancellation confirmation
  7. arrival dialogue = * *
         = *input* arrival message + *output* arrival packet
    arrival packet = * *
         = room key + room card + complimentary drink coupon
  8. check-out dialogue = * *
         = *input* check-out request + *output* guest bill
  9. payment dialogue = * *
         = *input* payment vehicle + *output* guest receipt
    guest receipt = * *
         = guest name + guest address + {charge detail} + charge total + (taxes) + amount due + amount paid
  10. see also Don't repeat yourself, also known as "DRY"


बाहरी संबंध