सिस्टम संदर्भ आरेख

From Vigyanwiki
Revision as of 10:34, 15 May 2023 by alpha>Indicwiki (Created page with "{{Use dmy dates|date=November 2014}} File:NDE Context Diagram (vector).svg|thumb|320px|सिस्टम संदर्भ आरेख का उदाहरण।<ref>[h...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

सिस्टम संदर्भ आरेख का उदाहरण।[1]

अभियांत्रिकी में एक प्रणाली संदर्भ आरेख एक आरेख है जो सिस्टम, या सिस्टम के हिस्से और उसके पर्यावरण के बीच की सीमा को परिभाषित करता है, जो इसके साथ बातचीत करने वाली संस्थाओं को दिखाता है।[2] यह आरेख एक प्रणाली का एक उच्च स्तरीय दृश्य है। यह एक ब्लॉक आरेख के समान है।

सिंहावलोकन

सिस्टम संदर्भ आरेख एक प्रणाली को समग्र रूप से और इसके इनपुट/आउटपुट और आउटपुट (कंप्यूटिंग) को/से बाहरी कारकों के रूप में दिखाते हैं। कोसियाकॉफ़ एंड स्वीट (2011) के अनुसार:[3]

System Context Diagrams ... represent all external entities that may interact with a system ... Such a diagram pictures the system at the center, with no details of its interior structure, surrounded by all its interacting systems, environments and activities. The objective of the system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of systems requirements and constraints.

जांच के तहत दायरे पर सहमति प्राप्त करने के लिए सिस्टम संदर्भ आरेखों का उपयोग परियोजना के आरंभ में किया जाता है।[4] संदर्भ आरेख आमतौर पर एक आवश्यकता दस्तावेज़ में शामिल होते हैं। इन रेखाचित्रों को सभी परियोजना हितधारकों द्वारा पढ़ा जाना चाहिए और इस प्रकार सरल भाषा में लिखा जाना चाहिए, ताकि हितधारक दस्तावेज़ के भीतर की वस्तुओं को समझ सकें।

बिल्डिंग ब्लॉक्स

कॉन्टेक्स्ट डायग्राम को दो प्रकार के बिल्डिंग ब्लॉक्स के उपयोग से विकसित किया जा सकता है:

  • संस्थाएँ (अभिनेता): लेबल वाले बॉक्स; केंद्र में एक सिस्टम का प्रतिनिधित्व करता है, और इसके चारों ओर प्रत्येक बाहरी अभिनेता के लिए कई बॉक्स हैं
  • संबंध: संस्थाओं और सिस्टम के बीच लेबल की गई रेखाएँ

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

एक संदर्भ आरेख बाहरी संस्थाओं के वर्गीकरण को सरल श्रेणियों के एक समूह के रूप में भी सूचीबद्ध कर सकता है[5] (उदाहरण:[6]), जो सिस्टम के संबंध में इकाई की भागीदारी के स्तर में स्पष्टता जोड़ता है। इन श्रेणियों में शामिल हैं:

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

विकल्प

सर्वोत्तम सिस्टम संदर्भ आरेखों का उपयोग यह प्रदर्शित करने के लिए किया जाता है कि कैसे एक सिस्टम बहुत उच्च स्तर पर इंटरऑपरेट करता है, या सिस्टम कैसे संचालित होता है और तार्किक रूप से इंटरैक्ट करता है। सिस्टम संदर्भ आरेख सिस्टम और अभिनेताओं के बीच आधारभूत संपर्क विकसित करने में एक आवश्यक उपकरण है; अभिनेताओं और एक प्रणाली या सिस्टम और सिस्टम। सिस्टम संदर्भ आरेख के विकल्प हैं:

आर्किटेक्चर इंटरकनेक्ट आरेख का उदाहरण।[7]

* आर्किटेक्चर इंटरकनेक्ट डायग्राम: यह आंकड़ा आर्किटेक्चर इंटरकनेक्ट डायग्राम का एक उदाहरण देता है: अल्बुकर्क पुलिस विभाग के लिए अल्बुकर्क क्षेत्रीय ITS आर्किटेक्चर इंटरकनेक्ट का एक प्रतिनिधित्व जो टर्बो आर्किटेक्चर टूल का उपयोग करके उत्पन्न किया गया था, चित्र में दिखाया गया है। प्रत्येक ब्लॉक शीर्ष छायांकित भाग में हितधारक के नाम सहित ITS इन्वेंट्री तत्व का प्रतिनिधित्व करता है। तत्वों के बीच की इंटरकनेक्ट लाइनें ठोस या धराशायी हैं, जो मौजूदा या नियोजित कनेक्शन का संकेत देती हैं।[7]* बिज़नेस मॉडल कैनवास, नए विकसित करने या मौजूदा बिजनेस मॉडल का दस्तावेजीकरण करने के लिए एक रणनीतिक प्रबंधन टेम्पलेट। यह एक फर्म के मूल्य प्रस्ताव, बुनियादी ढांचे, ग्राहकों और वित्त का वर्णन करने वाले तत्वों के साथ एक दृश्य चार्ट है। [1] यह फर्मों को संभावित ट्रेड-ऑफ को चित्रित करके उनकी गतिविधियों को संरेखित करने में सहायता करता है।

  • [[उद्यम डेटा मॉडल]]: Simsion (2005) के अनुसार इस प्रकार के डेटा मॉडल में 50 से 200 इकाई वर्ग तक हो सकते हैं, जो मॉडलिंग की दिनांक में विशिष्ट उच्च स्तर के सामान्यीकरण का परिणाम है।[8]
  • IDEF0 टॉप लेवल कॉन्टेक्स्ट डायग्राम: IDEF0 प्रक्रिया विघटित होने वाले प्राइम फंक्शन की पहचान के साथ शुरू होती है। यह फ़ंक्शन एक शीर्ष स्तरीय संदर्भ आरेख पर पहचाना जाता है जो विशेष IDEF0 विश्लेषण के दायरे को परिभाषित करता है।
  • प्रॉब्लम फ्रेम्स एप्रोच # प्रॉब्लम डायग्राम्स | प्रॉब्लम डायग्राम्स (प्रॉब्लम फ्रेम्स): कॉन्टेक्स्ट डायग्राम पर दिखाई जाने वाली चीजों के अलावा, एक प्रॉब्लम डायग्राम रिक्वायरमेंट्स और रिक्वायरमेंट्स रेफरेंस दिखाता है।
  • केस आरेख का उपयोग करें: एकीकृत मॉडलिंग भाषा आरेखों में से एक। वे अमूर्तता के समान स्तर पर परियोजना के दायरे का भी प्रतिनिधित्व करते हैं। - उपयोग के मामले, हालांकि, 'अभिनेताओं' के लक्ष्यों पर अधिक ध्यान केंद्रित करते हैं जो सिस्टम के साथ बातचीत करते हैं, और कोई समाधान निर्दिष्ट नहीं करते हैं। उपयोग केस आरेख उपयोग मामलों के एक सेट का प्रतिनिधित्व करते हैं, जो कि एक अभिनेता उपयोग मामले के लक्ष्य को कैसे प्राप्त करता है, इसका पाठ्य विवरण है। उदाहरण के लिए ग्राहक स्थान आदेश।
  • आर्चीमेट : आर्किमेट एक खुली और स्वतंत्र उद्यम वास्तुकला मॉडलिंग भाषा है जो एक स्पष्ट तरीके से व्यापार डोमेन के भीतर और उसके आसपास वास्तुकला के विवरण, विश्लेषण और दृश्यता का समर्थन करती है।

इनमें से अधिकांश आरेख तब तक अच्छी तरह से काम करते हैं जब तक सीमित संख्या में इंटरकनेक्ट दिखाए जाएंगे। जहां बीस या अधिक इंटरकनेक्ट प्रदर्शित किए जाने चाहिए, आरेख काफी जटिल हो जाते हैं और पढ़ने में मुश्किल हो सकते हैं।[7]


यह भी देखें

संदर्भ

  1. NDE Project Management Archived 7 November 2008 at the Wayback Machine (NPOESS) Data Exploitation web site. 2008.
  2. Manoj Kumar Choubey (2012) IT Infrastructure and Management (For the GBTU and MMTU). p. 53
  3. Alexander Kossiakoff, William N. Sweet (2011). Systems Engineering: Principles and Practices p. 266
  4. Richard Wiener (1998) Journal of Object-oriented Programming. Vol 11. p. 68
  5. Suzanne Robertson, James C. Robertson (2006) Mastering the Requirements Process. Pearson Education, 17 mrt. 2006
  6. System Goal Modelling using the i*: Approach in RESCUE Centre HCI Design, 27 February 2003
  7. 7.0 7.1 7.2 US Department of Transportation, Office of Operations (2006)Regional ITS Architecture Guidance Document. July 2006
  8. Graeme C. Simsion, Graham C. Witt (2005). Data Modeling Essentials. p. 512.


बाहरी संबंध