एफपी में डिजाइन और वास्तुकला। परिचय और भाग १

परिचय

कार्यात्मक प्रोग्रामिंग की दुनिया में, एक बड़ा अंतर है, अर्थात्, बड़े अनुप्रयोगों के उच्च-स्तरीय डिजाइन का विषय लगभग कवर नहीं है। मैंने खुद इस मुद्दे का अध्ययन करने का फैसला किया। क्या एफपी दुनिया में अनुप्रयोग की डिजाइन में कोई महत्वपूर्ण अंतर है जो अनिवार्य दुनिया में है? एक विहित एफपी कोड क्या है? विकास मुहावरे क्या हैं? क्या यह एफपी पर लागू होने पर डिजाइन पैटर्न के बारे में बात करने के लिए समझ में आता है? ये और अन्य महत्वपूर्ण प्रश्न अक्सर यहाँ और वहाँ भड़कते हैं, लेकिन कुछ समय के लिए मुझे गैंग ऑफ़ फोर की किताब के समान एक भी किताब नहीं पता है। किसी ने शायद मेरे शोध को दोहराया है, लेकिन सभी बेहतर: समान परिणाम सही होने की पुष्टि करेंगे, दूसरों को सिद्धांत में एक जगह का संकेत देगा जिसे सुधारने की आवश्यकता है।

सामग्री के बारे में

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

"द अमीबा वर्ल्ड" का कोड यहाँ है । बिग स्पेस प्रलेखन यहाँ है । वैसे, बहुत समय पहले मैं पहले से ही कुछ ऐसा ही कर रहा था। यह हास्केल क्वेस्ट ट्यूटोरियल था , जिसके ढांचे में मैंने, उम, खेल को भी विकसित किया। अगर आप इसे कॉल कर सकते हैं। लेकिन हास्केल भाषा का अध्ययन करने के लिए यह एक बहुत ही सरल निम्न-स्तरीय सामग्री थी, लेकिन यहां हम पूरी तरह से अलग मामलों के बारे में बात करेंगे। तदनुसार, यह माना जाता है कि पाठक एफपी और हास्केल प्रोग्रामिंग भाषा से पर्याप्त रूप से परिचित है।

योजना

कम से कम निम्नलिखित विषयों को आगे संबोधित किया जाना चाहिए:

1. भाग 1 एफपी आवेदन वास्तुकला। एफपी में डाउनस्ट्रीम डिजाइन। लड़ सॉफ्टवेयर जटिलता।
2. भाग २ एफपी में अपस्ट्रीम डिजाइन। आइडिया अच्छे डिजाइन की नींव है। हास्केल में एंटीपार्टर्न।
3. भाग ३ गुण और कानून। परिदृश्य। हास्केल में नियंत्रण का उलटा।
4. भाग 4. एफआरपी

साथ ही, लेखों की इस श्रृंखला को यहां एकल दस्तावेज़ के रूप में पाया जा सकता है ।

एक भाग

एफपी आवेदन वास्तुकला। एफपी में डाउनस्ट्रीम डिजाइन। लड़ सॉफ्टवेयर जटिलता।

सिद्धांत की बिट

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

ऐसा लगता है कि प्रारंभिक चरण - आवश्यकताओं को एकत्र करना और उनका विश्लेषण करना , कार्यक्रम की कार्यक्षमता का निर्धारण करना, व्यावसायिक परिदृश्य लिखना - हमेशा कुछ हद तक या अन्य, जो भी सॉफ़्टवेयर पर चर्चा की जाती है, वह हमेशा मौजूद रहेगा। कल्पना करें कि हम पहले से ही आवश्यकताओं को जानते हैं, और अधिक इंजीनियरिंग वाले लोगों पर ध्यान केंद्रित करते हुए, अभी के लिए पहले चरणों को छोड़ दें।

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

लेकिन अगर आप "लागू" आरेखों को करीब से देखते हैं, तो आप इस निष्कर्ष पर पहुंच सकते हैं कि वे कोड के उच्च-स्तरीय डिजाइन (जो वास्तुकला डिजाइन के नीचे स्थित है) में ज्यादा मदद नहीं करेंगे, या यहां तक ​​कि वे अपूर्ण सोच को नुकसान पहुंचा सकते हैं। उदाहरण के लिए, घटक वास्तुकला के बारे में सोचकर, हम नियंत्रण के व्युत्क्रम को याद करते हैं। आईओसी सॉफ्टवेयर विकास की मुख्य समस्याओं में से एक को हल करता है - यह अमूर्तता को उजागर करके जटिलता से निपटने में मदद करता है। लेकिन अगर आप इसे सेवा में लेते हैं तो क्या होगा? और यहां हम याद करते हैं कि इसे लागू करने का एक तरीका है - निर्भरता इंजेक्शन । यह संभवतः हमारी आवश्यकताओं के लिए अनुकूलित किया जा सकता है - निम्नलिखित भागों में हम कई अलग-अलग समाधानों पर गौर करेंगे, जैसे: अस्तित्वगत प्रकार, मॉड्यूल-स्तर के अमूर्त, मोनडिक अमूर्त और मोनैडिक राज्य इंजेक्शन। लेकिन वास्तव में, प्रथम श्रेणी के कार्यों के बाद, हम पूरी तरह से DI के बारे में भूल सकते हैं, क्योंकि यह एक गैर-मुहावरेदार दृष्टिकोण है , क्योंकि यह FP प्रोग्राम में एक राज्य की ओर (स्पष्ट या निहित रूप से) जाता है। और यह हमेशा अच्छा नहीं होता है। हालांकि, निष्पक्षता में, मुझे यह स्वीकार करना चाहिए कि IoC FI में भी मौजूद है।

और क्या, अगर IoC नहीं है, तो सॉफ्टवेयर डिजाइन जटिलता के खिलाफ लड़ाई में मदद करता है? SICP से, हम जानते हैं कि तीन महत्वपूर्ण तकनीकें हैं:

1. कार्यान्वयन विवरण ("ब्लैक बॉक्स") को छिपाने के लिए सार;
2. स्वतंत्र प्रणालियों के बीच बातचीत के सार्वजनिक इंटरफेस;
3. डोमेन-विशिष्ट भाषाएँ (DSL, डोमेन विशिष्ट भाषाएँ )।

हम मान सकते हैं कि पहले दो तरीके हमें ज्ञात हैं। इंटरफेस, अमूर्तता, विवरण को छिपाना सभी एक बात है, और IoC एक उदाहरण है। ओओपी भाषाओं के वर्चस्व के कारण, हमने मजबूत सहयोगी संबंध "अमूर्त" => "वंशानुक्रम" और "इंटरफ़ेस" => "ओओपी इंटरफ़ेस" विकसित किए हैं। वास्तव में, यह सच्चाई का केवल एक हिस्सा है। हम ओओपी अवधारणाओं के लिए "इंटरफ़ेस" और "अमूर्त" शब्दों को संकीर्ण करते हैं और इस तरह "अनुचित" प्रतिमानों को काट देते हैं। हालांकि, पहले दो तरीकों से जुड़े विचार अधिक सामान्य हैं, वे सभी दुनिया के लिए मान्य हैं, और अन्य तरीकों का ज्ञान किसी भी तरह से कमजोर नहीं हो सकता है।

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

हालांकि, इसे मान्यता दी जानी चाहिए: वास्तविक जीवन में विशेष भाषाओं को बहुत कम आंका जाता है। एक मिथक है कि समर्थन करना मुश्किल, कठिन और महंगा है। इसका कारण यह है कि एक आवश्यक प्रोग्रामर को अपने कम्फर्ट ज़ोन से बाहर निकलने और एक अलग सिंटैक्स, शब्दार्थ, और शायद एक बाहरी प्रतिमान बनाने के लिए एक अलग प्रतिमान की कल्पना करने की आवश्यकता होती है। यह जाने बिना, वह केवल अपने ढांचे के भीतर डीएसएल के साथ आने में सक्षम होगा, जो स्वचालित रूप से उसे वर्तमान कोड तक ले जाएगा, और फिर सवाल "क्यों फिर डीएसएल?"। लेकिन यह सब नहीं है। DSL कैसे लागू करें? प्रमुख ओओपी भाषाएँ (दुर्लभ अपवादों के साथ) कार्यात्मक लोगों की तुलना में एक सुरुचिपूर्ण समाधान प्रदान नहीं करती हैं; वास्तव में, पारंपरिक दृष्टिकोण को काफी प्रयास करने की आवश्यकता होती है ताकि बाहरी DSL जोखिमों में वृद्धि न करें। जोखिमों को दूर करने के लिए, आपको अन्य प्रतिमानों का अध्ययन करने और सिद्धांत को खींचने की आवश्यकता है; नतीजतन, एक परिचित भाषा में एक बाहरी DSL को लागू करने की जटिलता, DSL के विचार को वहन करती है। किसी कारण से, इस त्रुटि के खिलाफ एक मजबूत तर्क माना जाता है ... और यह इस तथ्य से आसानी से टूट जाता है कि बाहरी डीएसएल के अलावा, आंतरिक भी हैं (अंतर्निहित, एम्बेडेड डीएसएल, ईडीएसएल)। बाहरी डीएसएल के लिए, वर्तमान भाषा के व्याकरण के साथ अक्षम, कम से कम एक पार्सर और अनुवादक की आवश्यकता होती है, जो एक अतिरिक्त सेवारत कोड की ओर जाता है। लेकिन आंतरिक DSL वर्तमान भाषा के व्याकरण के भीतर है, जिसका अर्थ है कि किसी भी पार्सर या अनुवादक की आवश्यकता नहीं है। हालाँकि, आपको अभी भी एक अलग कोड संगठन के साथ आने की आवश्यकता है; और फिर हम इस निष्कर्ष पर पहुंचे कि हम एक व्यापक प्रोग्रामिंग क्षितिज के बिना नहीं कर सकते। और यह एक आधुनिक प्रोग्रामर के लिए एक प्राकृतिक आवश्यकता है। खैर, मार्टिन फाउलर हमारी मदद करने के लिए।

एफपी पर लागू वास्तुकला के बारे में और क्या कहा जा सकता है? एक महत्वपूर्ण बिंदु यह है कि वायुसेना में दुष्प्रभाव अवांछनीय हैं। लेकिन किसी भी बड़े कार्यक्रम में बाहरी दुनिया के साथ काम करना आवश्यक है; अर्थात्, दुष्प्रभावों को नियंत्रित करने के लिए कुछ तंत्र होना चाहिए। और वे हैं। कुख्यात हास्केल मोनैड्स एक बढ़िया विकल्प है, लेकिन यह समग्र वास्तुकला के एक तत्व की तुलना में कम डिजाइन उपकरण का अधिक है। तो, बाहरी सर्वर के साथ संचार करने के लिए कोड को IO मोनाड के हिस्से के रूप में लागू किया जा सकता है, जो कि अनिवार्यता से बहुत भिन्न नहीं होगा। दूसरा समाधान - कोड को डीएसएल पर घोषित किया जा सकता है। इस तरह के डीएसएल में साइड इफेक्ट के साथ ईंटें होती हैं, शुद्ध व्यवहार वाली ईंटें होती हैं, लेकिन ये सभी सिर्फ एक घोषणा है, इसलिए, सभी कोड साफ और कम त्रुटि वाले होंगे। संभवतः, यह समझने योग्य, लचीला, दहनशील और प्रबंधनीय होगा, वास्तव में - एक निर्माणकर्ता। इस कोड के निष्पादन को एक मोनोडिक IO कोड की पतली परत पर काम करने वाली राज्य मशीन को सौंपा जा सकता है। और कृपया, हमें एक बहुत अच्छा वास्तु समाधान मिला, जिसकी बदौलत हमने अपनी व्यावसायिक प्रक्रियाओं को औपचारिक बनाने की जटिलता को भी कम किया।

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

सामान्य तौर पर, फंक्शनल प्रोग्रामिंग में कंबाइनटोरियल स्टाइल में कंस्ट्रक्टर की तरह लिखा गया कोड सबसे मुहावरेदार होता है। यह विचार सरल है: एक मनमाने ढंग से बड़ा, स्व-लागू प्रणाली एक ही प्रकार की छोटी ईंटों से बना है। बेहतर निर्माणकर्ता को डिज़ाइन किया गया है, और अधिक शक्तिशाली और कोड को अभिव्यक्त करता है। आमतौर पर कॉम्बीनेटरियल कोड कुछ ईडीएसएल भी होता है, जो विकास की जटिलता को काफी कम कर देता है। कई हास्केल पुस्तकालय इस सिद्धांत का उपयोग करते हैं, उदाहरण के लिए: पारसेक, नेटवायर, एचएक्सएमएल, लेंस ... मोनैडिक पार्सर कॉम्बिनेटरों का विचार इतना सफल था कि पार्सेक हास्केल के बाहर जाना जाता था। इसके पोर्ट F #, एर्लांग, जावा और अन्य भाषाओं में मौजूद हैं। यह उत्सुक है कि पारसेक तीन विचारों के रूप में लागू करता है: कॉम्बिनेटर, डीएसएल और मोनाड्स, और यह सब एक सुसंगत एपीआई में व्यवस्थित रूप से जुड़ा हुआ है।

अब जटिलता से निपटने के लिए एक और बहुत शक्तिशाली तकनीक को बाहर करना आसान है (लेखक का नाम):

4. डोमेन-विशिष्ट कॉम्बिनेटर।

DSC एक ईडीएसएल है जिसके तत्व कॉम्बीनेटर हैं। सबसे सुविधाजनक DSCs वाक्यविन्यास (फ़ंक्शन परिवर्तनों के संयोजन हैं) के कारण कार्यात्मक भाषाओं में प्राप्त किए जाते हैं, लेकिन सामान्य भाषाओं में यह संभव है। बेशक, एक डीएससी को डिजाइन करना एक साधारण डीएसएल की तुलना में अधिक कठिन है, यही कारण है कि यह दृष्टिकोण संभवतः मुख्यधारा में पूरी तरह से अज्ञात है।

थोड़ा अभ्यास

अमूर्त सोच से अभ्यास की ओर बढ़ते हुए, हम बड़े खेल "बिग स्पेस" की परियोजना की ओर मुड़ते हैं। संक्षेप में, यह पूरी तरह से प्रोग्राम योग्य गेम तत्वों के साथ वास्तविक अनुपात का एक यथार्थवादी स्पेस 3 डी-फ्लायर है और, शायद, समय यात्रा की संभावना के साथ। जिज्ञासु लोग अधिक विस्तृत परिचित के लिए डिज़ाइन दस्तावेज़ और अन्य संबंधित सामग्रियों को देख सकते हैं, लेकिन यह विवरण हमारे लिए खेल की सामान्य वास्तुकला पर विचार करने के लिए पर्याप्त है। लेकिन पहले, एक छोटा विषयांतर।

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


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

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

1. जरूरत का नक्शा। यथासंभव बड़े ब्लॉक शामिल हैं। लिंक वैकल्पिक हैं, विषय पर ब्लॉक रखे गए हैं। नक्शा दिखाता है कि खेल किस पर आधारित है। डिजाइन करते समय, आपको सबसे सामान्य आवश्यकताओं पर विचार करने की आवश्यकता है; उदाहरण के लिए, "विशाल यथार्थवादी स्थान", "3 डी ग्राफिक्स", "क्रॉस-प्लेटफॉर्म", क्लाउड कम्प्यूटिंग, ओपनजीएल और एसडीएल ब्लॉक जैसी आवश्यकताओं के लिए उपस्थित होंगे। यदि आपको तृतीय-पक्ष गेम इंजन की आवश्यकता है, तो आपको इसे यहां निर्दिष्ट करना होगा।
2. नक्शा आइटम। मुक्त रूप में, हम संरचना के बारे में चिंता किए बिना पिछले आरेख को खोलते हैं। निम्नलिखित ब्लॉक तत्व हैं: "सबसिस्टम", "अवधारणा", "डेटा", "लाइब्रेरी", "विषय क्षेत्र की वस्तु"। लिंक सबसे बुनियादी विचार दिखाते हैं कि सिस्टम कैसे काम करता है। आप रिश्ते की प्रकृति को निर्दिष्ट कर सकते हैं, उदाहरण के लिए: "का उपयोग करता है", "औजार" और अन्य। ब्लॉक परतों में विभाजित हैं। आरेख को अधिकांश वैचारिक आवश्यकताओं को ध्यान में रखना चाहिए। यह ठीक है अगर अमूर्त के कई स्तर मिश्रित होते हैं, प्रतिस्पर्धा विकल्प दिखाई देते हैं, या कुछ सबसे अच्छा नहीं दिखता है। आरेख केवल गतिविधि के क्षेत्र को रेखांकित करता है और संभव समाधान प्रदान करता है, लेकिन यह कार्यक्रम की अंतिम वास्तुकला नहीं है।
3. सबसिस्टम मैप। इस आरेख में, विशिष्ट वास्तुकला निर्णय दूसरे चरण में प्रस्तावित लोगों से किए जाते हैं। जानकारी को संरचित और इस तरह से रखा जाता है जैसे कि आवेदन परतों को अलग करना। पुस्तकालय और कार्यान्वयन दृष्टिकोण इंगित किए जाते हैं। आरेख पूरी तरह से उच्च-स्तरीय डिज़ाइन का वर्णन नहीं करेगा, लेकिन यह सबसिस्टम के बीच महत्वपूर्ण निर्भरता दिखाएगा और उन्हें परतों में अलग करने में मदद करेगा।

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

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

निष्कर्ष

इस लेख में प्रस्तुत दृष्टिकोण नीचे की ओर है, अर्थात्, सबसे सामान्य से सबसे विशेष के लिए निर्देशित किया गया है। हमने देखा कि UML एफपी पर कमजोर रूप से लागू है। इसलिए, हमने अपने स्वयं के आरेखों का आविष्कार करके और अपनी स्वयं की कार्यप्रणाली का निर्माण करते हुए, शीर्ष-स्तरीय वास्तुकला का डिजाइन किया। हमने जटिलता से निपटने के तरीकों के बारे में भी सीखा, जिसकी हमें निश्चित रूप से उप-प्रणालियों के डिजाइन में आवश्यकता होगी।