अर्काडिया (इंजीनियरिंग)
अर्काडिया (आर्किटेक्चर एनालिसिस एंड डिज़ाइन इंटीग्रेटेड अप्रोच) आर्किटेक्चर-केंद्रित और मॉडल-संचालित इंजीनियरिंग गतिविधियों पर आधारित प्रणाली अभियांत्रिकी और सॉफ्टवेयर इंजीनियरिंग आर्किटेक्चर इंजीनियरिंग पद्धति है।
इतिहास
किसी सिस्टम के विकास चक्र में, पूर्व प्रथाओं ने आवश्यकताओं की परिभाषा, सिस्टम घटक के प्रत्येक घटक के लिए उनके आवंटन और संबंधित ट्रैसेबिलिटी पर अधिक ध्यान केंद्रित किया जाता है। वर्तमान दृष्टिकोण कार्यात्मक_डिज़ाइन, सिस्टम डिज़ाइन, आर्किटेक्चर विकल्पों के औचित्य और सत्यापन चरणों पर ध्यान केंद्रित करते हैं। इसके अतिरिक्त, डिज़ाइन न केवल फ़ंक्शन मॉडल के दृष्टिकोण को ध्यान में रखता है, अन्य दृष्टिकोणों को भी ध्यान में रखता है, जो सिस्टम की परिभाषा और टूटने को प्रभावित करते हैं। उदाहरण के लिए, सिस्टम एकीकरण, उत्पाद अस्तर प्रबंधन, सुरक्षा, प्रदर्शन और तार्किक संभावना से संबंधित बाधा (कंप्यूटर-सहायता प्राप्त डिज़ाइन) है। इसलिए सिस्टम इंजीनियरिंग केवल सिस्टम आवश्यकताओं को प्रबंधित करने के बारे में नहीं है, किंतु समष्टि डिज़ाइन गतिविधि है।
इस चुनौती के उत्तर के रूप में, थेल्स समूह द्वारा 2007 में अर्काडिया पद्धति बनाई गई, जिसमें सिस्टम आर्किटेक्चर और सहयोग को सिस्टम इंजीनियरिंग प्रथाओं के केंद्र में रखा गया था।
अर्काडिया का दृष्टिकोण आर्किटेक्चर इंजीनियरिंग, विकास टीमों, विशेषज्ञों, एकीकरण परीक्षण टीमों, ग्राहक और बाहरी भागीदारों सहित विभिन्न इंजीनियरिंग विशेषज्ञताओं के बीच की दीवारों को तोड़ना था।
सामान्यीकरण
अर्काडिया पद्धति को अफ़्नोर प्रायोगिक मानदंड के रूप में मानकीकृत किया जाने वाला है।[1] इसे 7 मार्च 2018 को प्रकाशित किया गया है.
प्रसंग
अर्काडिया विधि समष्टि सिस्टम और जीवन-महत्वपूर्ण प्रणाली सिस्टम के डिजाइन पर प्रयुक्त होती है, और अधिक सामान्यतः आर्किटेक्चर जो सॉफ्टवेयर, इलेक्ट्रॉनिक, इलेक्ट्रिकल आर्किटेक्चर और औद्योगिक प्रक्रियाओं सहित अनेक गैर-कार्यात्मक आवश्यकता होती है | तथा कार्यात्मक और गैर-कार्यात्मक बाधाओं के अधीन होते हैं। यह प्रथाओं के समूह को परिभाषित करता है जो परिचालन आवश्यकता को पूरा करने के लिए विश्लेषण और डिजाइन की आवश्यकता का मार्गदर्शन करता है। साथ ही यह विभिन्न प्रकार के जीवन चक्रों जैसे ऊपर से नीचे और नीचे से ऊपर डिज़ाइन को भी दर्शाता है | जहाँ बॉटम-अप दृष्टिकोण, एप्लिकेशन पुन: उपयोग, वृद्धिशील, पुनरावृत्त और आंशिक विकास से जुड़ी प्रक्रियाओं और बाधाओं के अनुकूल है।
उद्देश्य और क्रिया का अर्थ
अर्काडिया समष्टि प्रणालियों की आर्किटेक्चर की पहचान और जांच करने के लिए संरचित इंजीनियरिंग पद्धति है। यह सिस्टम के अनेक इंजीनियरिंग चरणों के समय सभी हित धारकों के बीच सहयोगात्मक कार्य को बढ़ावा देता है। यह परिभाषा चरण के समय पुनरावृत्तियों की अनुमति देता है जो आर्किटेक्ट्स को सभी पहचानी गई आवश्यकताओं की संतुष्टि की दिशा में जुटने में सहायता करता है।
यदि पाठ्य आवश्यकताओं को ग्राहक की जरूरतों को पूरा करने के समर्थन के रूप में रखा जाता है, अर्काडिया आवश्यकता और समाधान व्यवहार को औपचारिक बनाने के प्रमुख विधियों के रूप में कार्यात्मक विश्लेषण का समर्थन करता है। इसमें परिचालन, कार्यात्मक और गैर-कार्यात्मक पहलुओं के साथ-साथ आर्किटेक्चर की परिणामी परिभाषा भी सम्मिलित है, जो इस कार्यात्मक विश्लेषण पर आधारित है - और इसके विरुद्ध उचित है।
आर्केडिया निम्नलिखित सामान्य सिद्धांतों पर आधारित है:
- सभी इंजीनियरिंग हित धारक ही भाषा, इंजीनियरिंग कलाकृतियों और सूचनाओं का विधि समूह, आवश्यकता का विवरण और उत्पाद को साझा मॉडल के रूप में साझा करते हैं;
- बाधाओं के प्रत्येक समूह (जैसे सुरक्षा, प्रदर्शन, निवेश, द्रव्यमान, आदि) को दृष्टिकोण में औपचारिक रूप दिया गया है जिसके विरुद्ध प्रत्येक उम्मीदवार आर्किटेक्चर की जांच की जाएगी;
- आर्किटेक्चर सत्यापन नियम स्थापित किए जाते हैं और मॉडल को उनके विरुद्ध चुनौती दी जाती है, जिससे कि प्रक्रिया में जितनी जल्दी हो सके यह जांच की जा सके कि आर्किटेक्चर परिभाषा अपेक्षाओं को पूरा करती है;
- इंजीनियरिंग के विभिन्न स्तरों के बीच सह-इंजीनियरिंग को मॉडलों के संयुक्त विकास द्वारा समर्थित किया जाता है। आर्किटेक्चर और व्यापार-संवृत के विभिन्न स्तरों के मॉडल निकाले, मान्य किए गए और/या एक-दूसरे से जुड़े हुए हैं।
अर्काडिया पद्धति को कैपेला (इंजीनियरिंग) के माध्यम से तैयार किया गया है, जो मॉडलिंग टूल है वह परिचालन संदर्भ में पूर्ण पैमाने पर नियती की बाधाओं को पूरा करता है। कैपेला ओपन सोर्स के अनुसार इंजीनियरिंग समुदाय से निःशुल्क उपलब्ध है।
सुविधा सारांश
आर्केडिया विधि:
- ग्राहक परिचालन आवश्यकताओं को पूरा करने से लेकर सिस्टम एकीकरण सत्यापन सत्यापन (आईवीवी) तक सभी संरचित इंजीनियरिंग गतिविधियों को कवर करता है;
- अनेक इंजीनियरिंग स्तरों और उनके प्रभावी सहयोग (सिस्टम, सबसिस्टम, सॉफ्टवेयर, हार्डवेयर, आदि) को ध्यान में रखता है;
- विशेष इंजीनियरिंग (सुरक्षा, सुरक्षा, प्रदर्शन, इंटरफेस, लॉजिस्टिक्स ...) और आईवीवी के साथ सह-इंजीनियरिंग को एकीकृत करता है;
- यह न केवल वर्णनात्मक मॉडल साझा करने की क्षमता प्रदान करता है जब कि परिभाषा और आर्किटेक्चर के गुणों को सहयोगात्मक रूप से मान्य करने की क्षमता भी प्रदान करता है;
- पूर्ण पैमाने पर औद्योगिक अनुप्रयोगों में क्षेत्र-परीक्षण किया गया है, और वर्तमान में थेल्स के अनेक देशों और डिवीजनों में अंकित प्रमुख परियोजनाओं पर नियत किया गया है।
पद्धतिगत दृष्टिकोण
समष्टि प्रणालियों के विकास में अधिकांशतः आने वाली कठिनाइयों में से साझा संसाधनों (जिसमें कंप्यूटिंग संसाधनों तक सीमित नहीं है) का उपयोग करके अनेक आंशिक रूप से स्वतंत्र कार्यात्मक श्रृंखलाओं के सुपरपोजिशन से आती है। अर्काडिया पद्धति और अंतर्निहित उपकरणों का उपयोग आर्किटेक्चर द्वारा उनके समर्थन के साथ-साथ कार्यात्मक श्रृंखलाओं, उनके अतिव्यापी परिदृश्यों और वांछित प्रदर्शन की पहचान करने के लिए किया जाता है। सिस्टम विश्लेषण के पहले स्तर से प्रारंभ करके, वह पूरी प्रक्रिया परिभाषा में पता लगाने की क्षमता सुनिश्चित करते हैं और अपेक्षित प्रदर्शन और बाधाओं के विरुद्ध प्रत्येक प्रस्तावित आर्किटेक्चर डिजाइन की जांच करते हैं।
सिस्टम समाधान से अपेक्षित गैर-कार्यात्मक गुणों को भी 'दृष्टिकोण' में औपचारिक रूप दिया गया है। प्रत्येक दृष्टिकोण उन बाधाओं को पकड़ता है जिनका सिस्टम को सामना करना चाहिए या पूरा करना चाहिए (भयभीत घटनाएं, सुरक्षा खतरे, विलंबता अपेक्षाएं, उत्पाद लाइन या पुन: उपयोग की बाधाएं, बिजली की खपत या निवेश के मुद्दे, और बहुत कुछ)। फिर आर्किटेक्चर मॉडल का स्वचालित रूप से यह सत्यापित करने के लिए विश्लेषण किया जाता है कि यह इन बाधाओं को पूरा करता है, समर्पित विशेषज्ञ नियमों (प्रदर्शन गणना, संसाधन खपत, सुरक्षा या सुरक्षा बाधाओं आदि) के लिए धन्यवाद। यह विश्लेषण विकास चक्र की प्रारंभ में ही किया जा सकता है, जिससे डिजाइन समस्याओं का जल्द से जल्द पता लगाया जा सकता है (प्रारंभिक सत्यापन)।
सारांश के रूप में, विचारों (या दृष्टिकोण) द्वारा लक्षण वर्णन का दृष्टिकोण क्रॉस-चेक करता है कि प्रस्तावित आर्किटेक्चर प्रदर्शन, सुरक्षा, निर्भरता, द्रव्यमान, स्केले बिलिटी, वातावरण, द्रव्यमान, इंटरफेस इत्यादि के वांछित स्तर के साथ आवश्यक कार्य प्रदान करने में सक्षम है। इंजीनियरिंग निर्णयों की निरंतरता सुनिश्चित करना, क्योंकि सभी इंजीनियरिंग हितधारक समान इंजीनियरिंग जानकारी साझा करते हैं, और उन पर अपने विचार और जांच प्रयुक्त कर सकते हैं, जिससे कि सामान्य परिभाषा को सुरक्षित किया जा सके।
दृष्टिकोण और मुख्य अवधारणाओं की प्रस्तुति
आर्किटेक्चर मॉडल को विस्तृत और साझा करने के लिए उपयोग किए जाने वाले प्रथम स्तर के दृश्य नीचे वर्णित हैं:
- समस्या को परिभाषित करें - ग्राहक परिचालन आवश्यकता विश्लेषण,
पहला कदम सिस्टम/एसडब्ल्यू आवश्यकताओं से परे, ग्राहक की जरूरतों और लक्ष्यों, अपेक्षित मिशनों और गतिविधियों का विश्लेषण करने पर केंद्रित है। इससे इसके वास्तविक परिचालन उपयोग के संबंध में सिस्टम/एसडब्ल्यू परिभाषा की अच्छी पर्याप्तता सुनिश्चित करने और आईवीवीक्यू स्थितियों को परिभाषित करने की उम्मीद है। इस चरण के आउटपुट में मुख्य रूप से परिचालन आर्किटेक्चर सम्मिलित है जो अभिनेताओं/उपयोगकर्ताओं, उनकी परिचालन क्षमताओं और गतिविधियों, आयाम पैरामीटर देने वाले परिचालन उपयोग परिदृश्यों, सुरक्षा, सुरक्षा, जीवनचक्र इत्यादि सहित परिचालन बाधाओं के संदर्भ में इस आवश्यकता का वर्णन और संरचना करती है।
- सिस्टम/एसडब्ल्यू आवश्यकताओं को औपचारिक बनाना - सिस्टम/एसडब्ल्यू को विश्लेषण की आवश्यकता है,
दूसरा चरण अभी सिस्टम/एसडब्ल्यू पर ही केंद्रित है, जिससे कि यह परिभाषित किया जा सके कि यह अपने अपेक्षित व्यवहार और गुणों के साथ पूर्व परिचालन आवश्यकता को कैसे पूरा कर सकता है: सिस्टम/एसडब्ल्यू कार्यों का समर्थन किया जाना है और संबंधित एक्सचेंज, गैर-कार्यात्मक बाधाएं (सुरक्षा, सुरक्षा...), सिस्टम सीमा, भूमिका साझाकरण और सिस्टम और ऑपरेटरों के बीच बातचीत के लिए आवंटित प्रदर्शन। यह ग्राहकों की आवश्यकताओं की व्यवहार्यता (निवेश, अनुसूची और प्रौद्योगिकी तत्परता सहित) की भी जांच करता है, और यदि आवश्यक हो तब उनकी सामग्री पर फिर से बातचीत करने का साधन देता है। ऐसा करने के लिए, सिस्टम/एसडब्ल्यू कार्यात्मक आवश्यकता से पहला प्रारंभिक सिस्टम/एसडब्ल्यू आर्किटेक्चर (आर्किटेक्चर डिजाइन मॉडल) स्केच किया गया है; फिर उनकी निवेश और स्थिरता का मूल्यांकन करने के लिए इस आर्किटेक्चर के विरुद्ध आवश्यकताओं की जांच की जाती है। इस चरण के आउटपुट में मुख्य रूप से सिस्टम/एसडब्ल्यू कार्यात्मक आवश्यकता विवरण, अंतरसंचालनीयता और उपयोगकर्ताओं और बाहरी सिस्टम (फ़ंक्शन, एक्सचेंज प्लस गैर-कार्यात्मक बाधाएं), और सिस्टम/एसडब्ल्यू आवश्यकताएं सम्मिलित हैं।
ध्यान दें कि यह दो चरण, जो आर्किटेक्चर बिल्डिंग के पहले भाग का निर्माण करते हैं, आगे के डिज़ाइन को निर्दिष्ट करते हैं, और इसलिए ग्राहक के साथ अनुमोदित/मान्य होना चाहिए।
- सिस्टम/एसडब्ल्यू आर्किटेक्चर का विकास - लॉजिकल आर्किटेक्चर,
तीसरे चरण का उद्देश्य कार्यान्वयन या तकनीकी/तकनीकी विवादों को छोड़कर, सिस्टम/एसडब्ल्यू भागों (इसके पश्चात् घटक कहा जाता है), उनकी सामग्री, संबंधों और गुणों की पहचान करना है। यह सिस्टम/एसडब्ल्यू तार्किक आर्किटेक्चर का गठन करता है। घटकों में इस टूटने को आगे के चरणों में स्थिर रखने के लिए, सभी प्रमुख [गैर-कार्यात्मक] बाधाओं (सुरक्षा, सुरक्षा, प्रदर्शन, आईवीवी, निवेश, गैर तकनीकी, आदि) को ध्यान में रखा जाता है और दूसरे की तुलना की जाती है जिससे कि उनके बीच सर्वोत्तम समझौता खोजने के लिए। इस विधि को दृष्टिकोण-संचालित के रूप में वर्णित किया गया है, दृष्टिकोण इन बाधाओं के सिस्टम/एसडब्ल्यू आर्किटेक्चर को प्रभावित करने के विधियाँ का औपचारिककरण है। इस चरण के आउटपुट में चयनित तार्किक आर्किटेक्चर सम्मिलित है: घटकों और इंटरफेस की परिभाषा, जिसमें सभी दृष्टिकोणों की औपचारिकता और घटकों के डिजाइन में उन्हें ध्यान में रखने का विधि सम्मिलित है। चूँकि आर्किटेक्चर को आवश्यकता के अनुसार मान्य किया जाना है, आवश्यकताओं और परिचालन परिदृश्यों के साथ लिंक भी तैयार किए जाते हैं।
- सिस्टम/एसडब्ल्यू आर्किटेक्चर का विकास - भौतिक आर्किटेक्चर,
चौथे चरण में तार्किक आर्किटेक्चर निर्माण के समान इरादे हैं, सिवाय इसके कि यह इंजीनियरिंग के इस स्तर पर सिस्टम/एसडब्ल्यू की अंतिम आर्किटेक्चर को परिभाषित करता है, जो विकसित होने के लिए तैयार है (निचले इंजीनियरिंग स्तरों द्वारा)। इसलिए, यह युक्तिकरण, आर्किटेक्चर पैटर्न, नई तकनीकी सेवाओं और घटकों का परिचय देता है, और तार्किक आर्किटेक्चर को कार्यान्वयन, तकनीकी और तकनीकी बाधाओं और विकल्पों (इंजीनियरिंग के इस स्तर पर) के अनुसार विकसित करता है। ध्यान दें कि तार्किक आर्किटेक्चर निर्माण के लिए समान दृष्टिकोण-संचालित विधि का उपयोग भौतिक आर्किटेक्चर परिभाषा के लिए किया जाता है। इस चरण के आउटपुट में चयनित भौतिक आर्किटेक्चर सम्मिलित है: उत्पादित किए जाने वाले घटक, जिनमें सम्मिलित हैंजी सभी दृष्टिकोणों को औपचारिक बनाना और घटकों के डिजाइन में उन्हें किस तरह से ध्यान में रखा जाता है। आवश्यकताओं और परिचालन परिदृश्यों के साथ लिंक भी तैयार किए जाते हैं।
- घटक आवश्यकताओं को औपचारिक बनाएं - विकास और आईवीवीक्यू के लिए अनुबंध,
पांचवां और अंतिम चरण ईपीबीएस (एंड-प्रोडक्ट ब्रेकडाउन स्ट्रक्चर) के निर्माण में योगदान है, पूर्व आर्किटेक्चर कार्य से लाभ लेना, घटकों की आवश्यकताओं की परिभाषा को प्रयुक्त करना और सुरक्षित आईवीवीक्यू तैयार करना है। सिस्टम/एसडब्ल्यू द्वारा चुने गए आर्किटेक्चर से जुड़े सभी विकल्प, और आवश्यकता और बाधाओं को पूरा करने के लिए घटकों और आर्किटेक्चर पर लगाए गए सभी परिकल्पनाओं और बाधाओं को यहां संक्षेप में प्रस्तुत किया गया है और जांचा गया है। इस चरण के आउटपुट मुख्य रूप से घटक एकीकरण अनुबंध हैं जो विकसित किए जाने वाले प्रत्येक घटक के लिए सभी आवश्यक अपेक्षित गुण एकत्र करते हैं।
निम्नलिखित आंकड़ा अनुशंसित तकनीकी प्रक्रिया को सारांशित करने वाला वैश्विक दृश्य दिखाता है, जिसमें इंजीनियरिंग ट्रिप्टिच के तीन तत्वों और परिभाषा और डिजाइन प्रक्रिया के समय उनकी उत्पादन गतिविधियों को दिखाया गया है।
संचार
क्लैरिटी प्रोजेक्ट के भागों के रूप में, अर्काडिया पद्धति पर पुस्तक प्रकाशित की जाएगी। तथा परिचयात्मक दस्तावेज़ वर्तमान में कैपेला वेबसाइट पर डाउनलोड के लिए उपलब्ध है।[2]
अर्काडिया पद्धति को विभिन्न आयोजनों में प्रस्तुत किया गया:
| Conference | Title | Date | Place |
|---|---|---|---|
| मॉडल'16 | आर्केडिया नटसेल में [3] | 02/10/2016 | सैंट मालो |
| असंबद्ध अंतर्राष्ट्रीय संगोष्ठी | एमबीएसई सांस्कृतिक परिवर्तन को क्रियान्वित करना: संगठन, कोचिंग और सीखे गए सबक[4] | 14/07/2015 | सिएटल |
| असंबद्ध अंतर्राष्ट्रीय संगोष्ठी | प्रारंभिक जांच से लेकर एमबीएसई पद्धति और उसके सहायक कार्यक्षेत्र के बड़े पैमाने पर रोलआउट तक: थेल्स अनुभव[5] | 14/07/2015 | सिएटल |
| एक्लिप्सकोन फ़्रांस | अर्काडिया विधि और कैपेला टूल के साथ सिस्टम मॉडलिंग | 24/06/2015 | टाउलुस |
| मॉडल-आधारित सिस्टम इंजीनियरिंग (एमबीएसई) संगोष्ठी | एमबीएसई समाधान नियत करने की चुनौतियाँ[6] | 28/10/2014 | कैनबरा |
| मॉडल-आधारित सिस्टम इंजीनियरिंग (एमबीएसई) संगोष्ठी | मैदान में अर्काडिया और कैपेला[7] | 27/10/2014 | कैनबरा |
| एक्लिप्सकोन फ़्रांस | अर्काडिया / कैपेला, सिस्टम और सॉफ्टवेयर आर्किटेक्चर इंजीनियरिंग के लिए एक क्षेत्र-सिद्ध मॉडलिंग समाधान[8] | 19/06/2014 | टाउलुस |
| एमडीडी4ड्रेस एनस्टा समर स्कूल | सिस्टम इंजीनियरिंग पर फीडबैक - अर्काडिया, आर्किटेक्चर-केंद्रित इंजीनियरिंग के लिए एक मॉडल-आधारित विधि[9] | 01/09/2014 | एबर व्रॅक'एच |
| एक्लिप्सकोन उत्तरी अमेरिका | अर्काडिया / कैपेला, सिस्टम और सॉफ्टवेयर आर्किटेक्चर इंजीनियरिंग के लिए एक क्षेत्र-सिद्ध मॉडलिंग समाधान[10] | 20/03/2015 | सैन फ्रांसिस्को |
| कॉम्प्लेक्स सिस्टम डिज़ाइन एवं प्रबंधन (सीएसडीएम) | अर्काडिया: सिस्टम, सॉफ्टवेयर और हार्डवेयर इंजीनियरिंग के लिए मॉडल-आधारित सहयोग[11] | 04/12/2013 | पैरिस |
| कांग्रेस इंजिनियरी ग्रैंड प्रोग्राम और सिस्टम कॉम्प्लेक्स | थेल्स का आधुनिकीकरण: बड़ी प्रणालियों के कलाकारों के सहयोग से एक बड़ी उपलब्धि का समर्थन[12] | 10/06/2013 | अर्काचोन |
| एमएएसटी | एकीकृत बहु-स्तरीय इंजीनियरिंग की ओर - थेल्स और डीसीएनएस उन्नत अभ्यास[13] | 04/06/2013 | गडेंस्क |
| सीएसडीएम | कार्यात्मक विश्लेषण के लिए मॉडलिंग भाषाओं को वास्तविक जीवन की कसौटी पर कसा जाता है[14] | 2012 | पैरिस |
| आईसीएएस | प्रतिबंधित प्रणालियों की सहयोगी आर्किटेक्चर को सुरक्षित और समर्थन करने की विधि और उपकरण[15] | 2010 | उत्तम |
| सीएसडीएम | प्रतिबंधित प्रणालियों के लिए मॉडल-संचालित आर्किटेक्चरभवन[16] | 2010 | पैरिस |
| असंबद्ध;08 संगोष्ठी | प्रतिबंधित सिस्टम आर्किटेक्चर के लिए विधि और उपकरण[17] | 2008 | यूट्रेक्ट |
यह भी देखें
- मेटामॉडलिंग
- मॉडल-संचालित इंजीनियरिंग
संदर्भ
- ↑ "Norme PR XP Z67-140 | Norm'Info". norminfo.afnor.org (in français). Retrieved 2018-02-01.
- ↑ "आर्केडिया परिचयात्मक दस्तावेज़". Retrieved 2015-10-23.
- ↑ "ARCADIA in a nutshell". Retrieved 2016-10-06.
- ↑ "Implementing the MBSE Cultural Change: Organization, Coaching and Lessons Learned". Archived from the original on 2016-03-03. Retrieved 2015-10-23.
- ↑ "From initial investigations up to large-scale rollout of an MBSE method and its supporting workbench: the Thales experience". Archived from the original on 2016-03-03. Retrieved 2015-10-23.
- ↑ "The Challenges of Deploying MBSE Solutions". Retrieved 2015-10-23.
- ↑ "Arcadia and Capella in the Field". Retrieved 2015-10-23.
- ↑ "Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering". Archived from the original on 2015-10-21. Retrieved 2015-10-23.
- ↑ "Feedbacks on System Engineering – ARCADIA". Retrieved 2015-10-22.
- ↑ "Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering". Archived from the original on 2016-03-03. Retrieved 2015-10-23.
- ↑ "Model-Based Collaboration for System, Software and Hardware Engineering". Retrieved 2015-10-23.
- ↑ "La modélisation chez Thales : un support majeur à la collaboration des acteurs dans l'ingénierie des grands systèmes" (PDF). Archived from the original (PDF) on 2016-03-03. Retrieved 2015-10-23.
- ↑ "Toward integrated multi-level engineering - Thales and DCNS advanced Practices". Retrieved 2015-10-23.
- ↑ Voirin, Jean-Luc (2013). "Modelling Languages for Functional Analysis Put to the Test of Real Life". Complex Systems Design & Management. pp. 139–150. doi:10.1007/978-3-642-34404-6_9. ISBN 978-3-642-34403-9.
- ↑ "Method and tools to secure and support collaborative architecting of constrained systems". Retrieved 2015-10-23.
- ↑ "Model-driven Architecture building for constrained Systems". Archived from the original on 2016-03-03. Retrieved 2015-10-23.
- ↑ Voirin, Jean-Luc (2008). "Method & Tools for constrained System Architecting". INCOSE International Symposium. 18: 981–995. doi:10.1002/j.2334-5837.2008.tb00857.x. S2CID 111113361.
