النمذجة المتعددة الخاصة بالمجال

تُحدد لغة تعريف الكيانات (Entity DSL) بنية البيانات في OFBiz . يُوضح المثال أدناه تعريف كيان "الاستبيان" (Survey)، وهو كائن الأعمال الذي يُمثل مفهوم الاستبيان. الكود في المثال واضح بذاته: يُعرّف كيان "الاستبيان" (Survey) بعشرة حقول. لكل حقل اسم ونوع. يُستخدم الحقل surveyId كمفتاح أساسي . يتم تحميل هذا التعريف بواسطة مُكوّن مركزي في OFBiz يُسمى مُحرك الكيانات (Entity Engine) . يقوم مُحرك الكيانات بإنشاء كائن أعمال مُناسب . يهدف مُحرك الكيانات إلى إدارة خصائص المعاملات لجميع كائنات الأعمال والتفاعل مع آليات التخزين المختلفة، مثل Java Database Connectivity وEnterprise JavaBeans ، أو حتى بعض الأنظمة القديمة .

<entity entity-name= "Survey" ... title= "Survey Entity" > <field name= "surveyId" type= "id-ne" /> <field name= "surveyName" type= "name" /> <field name= "description" type= "description" /> <field name= "comments" type= "comment" /> <field name= "submitCaption" type= "short-varchar" /> <field name= "responseService" type= "long-varchar" /> <field name= "isAnonymous" type= "indicator" ... /> <field name= "allowMultiple" type= "indicator" ... /> <field name= "allowUpdate" type= "indicator" ... /> <field name= "acroFormContentId" type= "id-ne" ... /> <prim-key field= "surveyId" /> </entity>

تحدد لغة وصف الخدمات (Service DSL) واجهة الخدمات في OFBiz . تغلف كل خدمة جزءًا من منطق تطبيق النظام. يهدف استخدام هذه اللغة إلى توفير تجريد موحد لآليات التنفيذ المختلفة. يمكن تنفيذ الخدمات الفردية باستخدام Java، أو لغة برمجة نصية ، أو باستخدام محرك قواعد . يعرض الجدول أدناه واجهة خدمة إنشاء الاستبيان (createSurvey).

إلى جانب الاسم، يُحدد عنصر الخدمة موقع وأمر استدعاء تنفيذ هذه الخدمة. تُشير السمة default-entity-name إلى أن هذه الخدمة تُشير إلى كيان Survey المُعرّف في القائمة السابقة. هذا تداخل بين اللغتين، وتحديدًا ما يُسمى بالمرجع الضمني . يُشير النموذج في لغة Service DSL إلى نموذج في لغة Entity DSL. يُستخدم هذا المرجع في عنصري auto-attributes أدناه، واللذان يُحددان مُدخلات ومُخرجات الخدمة في شكل سمات مُحددة النوع. كمُدخلات، تقبل الخدمة سمات تُطابق جميع حقول غير المفتاح الأساسي (nonpk) لكيان Survey، وهذه السمات اختيارية. كمُخرجات، تُعيد الخدمة سمات تُطابق حقول المفتاح الأساسي (pk) لكيان Survey، أي في هذه الحالة حقل surveyId، وهذه السمات إلزامية. الغرض من المرجع بين اللغتين في هذه الحالة هو تقليل التكرار. تُطابق سمات خدمة createSurvey حقول كيان Survey، وبالتالي يكفي تحديدها مرة واحدة فقط.

<service name= "createSurvey" default-entity-name= "Survey" ... location= "org/ofbiz/content/survey/SurveyServices.xml" invoke= "createSurvey" > ... <permission-service service-name= "contentManagerPermission" main-action= "CREATE" /> <auto-attributes include= "nonpk" mode= "IN" optional= "true" /> <auto-attributes include= "pk" mode= "OUT" optional= "false" /> </service>

تُستخدم لغة وصف النماذج (Form DSL) لوصف تخطيط ومظهر نماذج الإدخال في واجهة المستخدم. تتكون هذه اللغة من مفاهيم المجال مثل النموذج والحقل. يوضح الجدول أدناه تنفيذ نموذج EditSurvey. في هذه الحالة، تتداخل لغة وصف النماذج مع لغة وصف الخدمات (Service DSL). تُحدد السمة target للنموذج وعناصر alt-target أن الإدخال الناتج عن إرسال هذا النموذج يجب توجيهه إما إلى خدمة updateSurvey أو خدمة createSurvey. يُحدد عنصر auto-fields-service أن النموذج يجب أن يتضمن حقلاً يُطابق كل سمة من سمات خدمة updateSurvey (وهي مشابهة لسمات خدمة createSurvey). يُنتج هذا تأثيرًا مشابهًا لاستيراد التعريفات من نموذج آخر كما في حالة عناصر auto-attributes في الجدول السابق. في الأسفل، نرى أنه من الممكن تخصيص مظهر هذه الحقول المستوردة مثل isAnonymous. أخيرًا، تمت إضافة زر إرسال (submitButton) بعنوان مُترجم ليتمكن المستخدم من إرسال بياناته إلى الخدمة المشار إليها.

<form name= "EditSurvey" type= "single" target= "updateSurvey" title= "" default-map-name= "survey" > <alt-target use-when= "survey==null" target= "createSurvey" /> <auto-fields-service service-name= "updateSurvey" /> <field use-when= "survey!=null" name= "surveyId" ... /> ... <field name= "isAnonymous" > <drop-down no-current-selected-key= "N" allow-empty= "false" > <option key= "Y" /><option key= "N" /> </drop-down> </field> ... <field name= "submitButton" title= "${uiLabelMap.CommonUpdate}" widget-style= "smallSubmit" > <submit button-type= "button"> </field> </form>​

يُنفَّذ مثال إنشاء الاستبيان ، كما هو موضح هنا، باستخدام نماذج بثلاث لغات برمجة مختلفة. في الواقع، يتضمن التنفيذ الكامل لغاتٍ أكثر، مثل لغة برمجة خاصة بالشاشة (Screen DSL) لتحديد تخطيط الشاشة التي يُوضع عليها النموذج، ولغة برمجة خاصة بالبيانات (Minilang DSL) تُستخدم لتنفيذ الخدمة. مع ذلك، تُوضِّح هذه اللغات الثلاث الفكرة الأساسية المتمثلة في جعل كل جانب من جوانب العمل ملموسًا. كما يُبيِّن المثال طريقةً بسيطةً لتقليل التكرار من خلال السماح بتداخل بسيط بين اللغات.

تتميز اللغات المتخصصة في مجال معين ، مثل تلك المذكورة أعلاه، بقدرة تعبيرية محدودة. وغالبًا ما يكون من الضروري إضافة أجزاء من التعليمات البرمجية بلغة عامة مثل جافا لتنفيذ وظائف متخصصة تتجاوز نطاق تلك اللغات. تُسمى هذه الطريقة بالتخصيص متعدد المستويات . ^{[ 2 ]} ولأن هذه الطريقة شائعة الاستخدام في بيئات متعددة اللغات، سنوضحها من خلال استكمال المثال. لنُسمِّ هذا المثال " مثال إنشاء ملف PDF" .

لنفترض أننا نريد إنشاء ملف PDF لكل إجابة على الاستبيانات الإلكترونية التي يُنشئها المستخدمون. بما أن إنشاء ملف PDF ليس من ضمن إمكانيات لغات البرمجة التي نستخدمها، فنحن بحاجة إلى كتابة كود جافا يستدعي مكتبة PDF خارجية لتنفيذ هذه الوظيفة المتخصصة. يتطلب ذلك عنصرين:

أولًا، نموذج خدمة إضافي، كما هو موضح أدناه، في لغة وصف الخدمة (Service DSL) يُحدد واجهة الخدمة المحددة بحيث يمكن الوصول إليها على مستوى النمذجة. يصف نموذج الخدمة موقع التنفيذ وخصائص الإدخال والإخراج.

<service name= "buildPdfFromSurveyResponse" engine= "java" location= "org.ofbiz.content.survey.PdfSurveyServices" invoke= "buildPdfFromSurveyResponse" > <attribute name= "surveyResponseId" mode= "IN" optional= "false" ... /> <attribute name= "outByteWrapper" mode= "OUT" optional= "false" ... /> </service>

ثانيًا، نحتاج إلى جزء من التعليمات البرمجية، كما هو موضح أدناه، يحتوي على التنفيذ الفعلي لهذه الخدمة. يمكن أن تحتوي الخدمة على مدخلات ومخرجات متعددة، لذا فإن مدخلات دالة جافا هي عبارة عن خريطة، تُسمى "context"، من أسماء الوسائط إلى قيمها، وتُرجع مخرجات على شكل خريطة أخرى، تُسمى "results".

public static Map buildPdfFromSurveyResponse ( DispatchContext dctx , Map context ) { String id = ( String ) context.get ( " surveyResponseId" ); Map results = new HashMap ( ); try { // ...يتم استرجاع الاستجابة من قاعدة البيانات... // ...يتم إنشاء ملف PDF من الاستجابة... // ...يتم تحويل ملف PDF إلى مصفوفة بايت... ByteWrapper outByteWrapper = ...; results.put ( "outByteWrapper" , outByteWrapper ); } catch ( Exception e ) { } return results ; }

تستخدم طريقة التخصيص متعددة المستويات هذه مراجعًا مرنة مشابهة لمثال إنشاء الاستبيان . ويكمن الاختلاف الرئيسي في أن المرجع هنا يكون بين النموذج والبرنامج، وليس بين نموذجين. وتكمن الميزة في هذه الحالة في إمكانية الاستفادة من مكتبة جافا خارجية لإنشاء ملفات PDF. ومن التطبيقات الشائعة الأخرى استخدام مقتطفات من كود جافا لاستدعاء خدمات ويب خارجية واستيراد النتائج بتنسيق مناسب.

أول مشكلة يواجهها المطورون عند بدء تطوير تطبيقات بلغات متعددة هي تداخل اللغات . فتعلم اللغات المختلفة وفهم تفاعلها ضروري لفهم التركيب المعقد للمكونات البرمجية. على سبيل المثال، يحتوي إطار عمل OFBiz على سبع عشرة لغة مختلفة وأكثر من 200 ألف سطر من التعليمات البرمجية الخاصة بكل لغة، لذا قد يكون التعقيد هائلاً! لا توجد حاليًا طريقة مُعتمدة لتصنيف اللغات المختلفة بحيث يتمكن المطورون من الوصول بسرعة إلى فهم عملي. تُعد الأدوات مهمة هنا كآلية مؤقتة للتعلم والاستكشاف، لأن المطورين عادةً ما يستخدمون الأدوات للتعلم من خلال التجربة. وهناك ثلاثة مجالات على وجه الخصوص تُعد فيها أدوات النماذج الخاصة بكل لغة مفيدة:

1. فهم اللغة
2. فهم التفاعلات اللغوية
3. فهم كيفية استخدام اللغات

أولًا، قد يكون فهم اللغة أمرًا صعبًا، وفي حالة لغات المجال المتخصصة القائمة على XML، يُعدّ الاعتراض الشائع والبديهي هو الاعتراض المتعلق بأهمية بناء الجملة . يمكن صياغة هذه الحجة على النحو التالي: "يصعب فهم اللغات المختلفة، ولا تزيد الأمر إلا تعقيدًا نظرًا لأن بناء الجملة القائم على XML مطوّل وغير مفهوم. سيكون استخدام لغة عامة واحدة مثل Java أفضل، لأن المطورين سيتمكنون حينها من الاعتماد على بناء جملة يعرفونه مسبقًا". مع أن هذا الاعتراض مهم بلا شك، إلا أنه يغفل نقطة جوهرية. قد لا يكون XML أو أي تنسيق تمثيل مشابه هو بناء الجملة الذي يتعامل معه المطورون فعليًا. إحدى مزايا استخدام لغات المجال المتخصصة القائمة على XML هي إمكانية توفير محررات خاصة بكل مجال. يوضح الشكل أدناه كيف قد يبدو محرر افتراضي للغة Entity DSL. يعرض هذا المحرر المجال بطريقة بسيطة وجذابة بصريًا، ولكنه قد يستخدم تمثيل XML (وربما إعدادات تخطيط) في الخلفية.

كما قد نعترض على أن لغة XML خيار غير مناسب، يمكننا أيضاً الاعتراض على أن لغة برمجة عامة مثل Java خيار غير ملائم لبعض المهام. علاوة على ذلك، قد يشعر المطورون براحة أكبر عند استخدام محرر النصوص في الشكل مقارنةً بقوائم التعليمات البرمجية في XML أو Java. إذا سلمنا بأهمية بناء الجملة، فإن استخدام لغات مختلفة مع محررات مخصصة يصبح استراتيجية منطقية. فبساطة المحرر تجعل اللغة أسهل فهماً، وبالتالي أسهل استخداماً. بعبارة أخرى، قد يكون الاعتراض على أهمية بناء الجملة هو السبب الرئيسي وراء استكشافنا لمجال لغات البرمجة المتخصصة .

ثانيًا، تكشف تفاعلات اللغات عن العلاقات بينها. ينبغي أن يتمكن المطورون من التنقل بين العناصر ذات الصلة في مختلف البرامج. تُعد سهولة التنقل بين مختلف مكونات البرنامج معيارًا هامًا للأدوات في بيئات التطوير التقليدية. على الرغم من عدم إجراء دراسات تجريبية في هذا المجال، فإننا نفترض أن أدوات التنقل المناسبة تزيد الإنتاجية. يدعم هذا الافتراض ملاحظة أن جميع بيئات التطوير الرئيسية اليوم توفر أدوات تنقل متطورة، مثل متصفح تسلسل الأنواع أو القدرة على تحديد موقع مراجع تعريفات الدوال والانتقال إليها بسرعة. تستطيع بيئات التطوير توفير هذه الأدوات لأنها تحتفظ بنموذج مُحدَّث باستمرار لملفات المصدر على شكل شجرة بناء جملة مجردة .

في بيئة تطوير متعددة اللغات، يصبح التنقل أكثر صعوبة. فالبيئات الحالية غير مهيأة لتحليل وتمثيل نماذج لغات المجال المحددة (DSL) كأشجار بناء جملة مجردة للغات عشوائية، وربما حتى لغات خاصة بتطبيقات معينة، مثل اللغات المذكورة في المثال السابق. علاوة على ذلك، وبدون هذا التمثيل الداخلي، لا تستطيع البيئات الحالية حل المراجع داخل اللغة الواحدة أو بين اللغات المختلفة، وبالتالي لا يمكنها توفير تنقل فعال. هذا يعني أنه يجب على المطورين الحفاظ على نموذج مفاهيمي لكيفية ترابط أجزاء نظامهم. من ناحية أخرى، ستكون الأدوات الجديدة المزودة بإمكانيات تنقل مصممة للغات متعددة مفيدة للغاية في فهم العلاقات بين اللغات. في مثال إنشاء الاستبيان ، ينبغي لهذه الأدوات عرض العلاقات بين اللغات الثلاث باستخدام المراجع المرنة كنقاط تنقل.

ثالثًا، لفهم استخدام اللغة، يجب أن نكون قادرين على التمييز بين عمليات التحرير الصحيحة والخاطئة في بيئة التطوير. لطالما وفرت بيئات التطوير التقليدية إرشادات أثناء كتابة البرنامج. يسمح التجميع التزايدي للبيئة بتقديم اقتراحات تفصيلية للمطور، مثل كيفية إكمال عبارة برمجية. توجد أيضًا أنواع أكثر تدخلاً من الإرشادات، مثل المحررات الموجهة نحو بناء الجملة، حيث لا يُسمح إلا بإدخال البيانات المتوافقة مع قواعد اللغة. وقد وُجدت محررات نصوص عامة قابلة للتخصيص بقواعد اللغة منذ زمن طويل. ^{[ 3 ]}

لا تأخذ المحررات الحالية علاقات التناسق بين اللغات في الحسبان عند تقديم التوجيه. في المثال السابق، ينبغي أن يكون المحرر المثالي قادرًا على اقتراح خدمة "إنشاء استطلاع" كقيمة صالحة عندما يقوم المطور بتعديل السمة المستهدفة في تعريف النموذج. كما أن بيئة قادرة على تحليل العناصر من لغات مختلفة ستساعد المطور على تحديد حالات البرنامج التي يوجد فيها تناسق محلي وليس شامل. قد ينشأ مثل هذا الموقف عندما يكون النموذج سليم البنية ، وبالتالي متناسقًا محليًا، ولكنه في الوقت نفسه ينتهك قيدًا بين اللغات. سيكون التوجيه أو المساعدة الذكية في شكل مقترحات حول كيفية إكمال النموذج مفيدًا في الإعدادات التي تتضمن لغات متعددة وقيود تناسق معقدة. يمكن لعمليات التحرير المقترحة من الأداة أن تسهل على المطور البدء في عملية تعلم كيفية استخدام اللغات.

يتمثل الجانب التقني لمشكلة التنسيق أساسًا في ضمان الاتساق. كيف يمكننا اكتشاف التناقضات بين النماذج من لغات متعددة أثناء عملية النمذجة؟ لفهم تعقيد متطلبات الاتساق لنظام قائم على لغات متعددة فهمًا كاملًا، من المفيد تحسين مفهومنا للاتساق.

يمكن أن يكون الاتساق داخليًا أو بينيًا. يتعلق الاتساق الداخلي باتساق العناصر داخل نموذج واحد. ويشترط هنا أن يتوافق النموذج مع نموذجه الفوقي، أي أن يكون سليمًا من الناحية التركيبية. ففي مثال إنشاء الاستبيان، على سبيل المثال، يجب أن يتوافق نموذج الكيان مع مخطط XSD الخاص بلغة Entity DSL. هذا المخطط هو النموذج الفوقي للغة Entity DSL، وهو يحدد كيفية تكوين العناصر، وما هي، إلى حد ما، النطاقات الصالحة للسمات.

يتحقق التناسق بين النماذج عندما يمكن حلّ المراجع عبر حدود اللغات. وينقسم هذا النوع من التناسق إلى قسمين: (1) تناسق بين النماذج، و(2) تناسق بين النموذج والبرنامج. يتعلق التناسق بين النماذج بسلامة المراجع ، بالإضافة إلى القيود العامة للنظام. في مثال إنشاء الاستبيان ، تشير السمة default-entity-name من قائمة الخدمات إلى السمة name من قائمة الكيانات. إذا غيّرنا إحدى هاتين القيمتين دون تحديث الأخرى، فإننا نفقد المرجع. توجد أيضًا قيود تناسق عامة أخرى بين النماذج المختلفة، كما سيتم توضيحه لاحقًا. قد يتبع المشروع أنماطًا أو اصطلاحات معينة لتسمية عناصر النموذج وربطها. يجب تخصيص بيئات التطوير الحالية للغات محددة باستخدام إضافات مكتوبة يدويًا أو آليات مشابهة لضمان التناسق بين اللغات، كما في المثال السابق.

يُعدّ اتساق النموذج مع الكود شرطًا أساسيًا في التخصيص متعدد المستويات. عند إضافة مقتطفات برمجية إلى النماذج، كما في مثال إنشاء ملف PDF ، من الضروري التحقق من توافق النماذج والكود . يتعلق هذا جزئيًا بالتأكد من سلامة المراجع غير المباشرة بين النماذج والكود، على غرار سلامة المراجع في اتساق النموذج مع النموذج. ولكنه يتعلق أيضًا بالتأكد من أن الكود لا يخالف التوقعات المحددة في النموذج. في مثال إنشاء ملف PDF ، يُحدد النموذج أن outByteWrapper سيكون دائمًا جزءًا من المخرجات، أي أن مفتاح outByteWrapper يُوضع في خريطة النتائج. يُظهر تحليل الكود أن outByteWrapper لن يكون جزءًا من المخرجات إلا إذا لم تُطرح أي استثناءات قبل السطر 10. بعبارة أخرى، قد تُخالف بعض عمليات تنفيذ الكود مواصفات على مستوى النمذجة. بشكل عام، يمكننا القول إن التخصيص متعدد المستويات يفرض قيودًا دقيقة للغاية على النماذج ومقتطفات الكود المستخدمة.

تنشأ مشكلة التنسيق من استخدام لغات برمجة متعددة في نظام واحد. يوضح القسمان الفرعيان السابقان أن لهذه المشكلة جانبًا مفاهيميًا وآخر تقنيًا دقيقًا. التحديات التي وصفناها حقيقية وليست افتراضية. على وجه التحديد، واجهنا هذه التحديات في دراستي حالة عمليتين: نظام تخطيط موارد المؤسسات OFBiz ، ونظام الرعاية الصحية DHIS . كلا النظامين متوسطا الحجم ويُستخدمان فعليًا في القطاع الصناعي. يتمثل حلنا للمشاكل العملية التي واجهناها أثناء عملنا مع هذين النظامين في مجموعة من الإرشادات والنماذج الأولية. فيما يلي، سنقدم إطارًا مفاهيميًا شاملًا يدمج هذه الإرشادات والنماذج الأولية في منهجية متكاملة: منهجية التنسيق .

تهدف خطوة التحديد إلى تحديد نقاط التداخل اللغوي. وكما هو موضح في المثال، يُعرَّف التداخل بأنه منطقة تتقاطع فيها اهتمامات لغتين. ومن أمثلة هذه التداخلات، الإشارات المرجعية من لغة وصف النماذج (Form DSL) إلى لغة وصف الخدمات (Service DSL)، ومن لغة وصف الخدمات إلى لغة وصف الكيانات (Entity DSL) في حالة استخدام إنشاء الاستبيان. مثال آخر هو استخدام جزء برمجي مُخصَّص لتوسيع نموذج. تكثر هذه التداخلات عندما تكون هناك حاجة إلى قدرة لغات البرمجة العامة على التعبير لتنفيذ متطلبات مُخصَّصة تتجاوز نطاق النموذج. يمكن أن تكون خطوة التحديد يدوية أو آلية، وذلك بحسب مدى تعقيد التداخلات. بعد تحديد التداخلات وتوضيحها، تُستخدم هذه المعلومات كمدخل للخطوة الثانية في المنهجية: خطوة التوصيف.

تهدف خطوة تحديد المواصفات إلى إنشاء نموذج تنسيق يحدد كيفية تفاعل اللغات. تشكل المراجع عبر حدود اللغات في النظام نموذج التنسيق الخاص بذلك النظام. ويتم إنشاؤه من خلال ربط عناصر البرمجيات الرئيسية بتمثيل مشترك. كما يمكن ترميز معلومات إضافية، مثل القيود الخاصة بالمجال أو التطبيق، لتوفير تمثيل غني. يعتمد نموذج التنسيق على معلومات عامة، مثل قواعد اللغة وقيودها، بالإضافة إلى معلومات خاصة بالتطبيق، مثل النماذج الملموسة والقيود الخاصة بالتطبيق. هذا يعني أنه على الرغم من استخدام اللغات نفسها في عدة منتجات، فإن لكل منتج مواصفات نموذج تنسيق فريد خاص به. يُستخدم نموذج التنسيق كأساس لأشكال مختلفة من الاستدلال في الخطوة الأخيرة من المنهجية: خطوة التطبيق.

تهدف خطوة التطبيق إلى الاستفادة من نموذج التنسيق. يُمكّن هذا النموذج الأدوات من استخلاص ثلاث طبقات من المعلومات المفيدة. أولًا، يُستخدم نموذج التنسيق لضمان الاتساق بين لغات متعددة، حيث يُحدد علاقات الاتساق، مثل كيفية إشارة العناصر من لغات مختلفة إلى بعضها البعض. وبذلك، تستطيع الأدوات ضمان سلامة البيانات المرجعية وإجراء فحوصات ثابتة للنظام النهائي قبل النشر. ثانيًا، تُستخدم علاقات الاتساق للتنقل بين اللغات المختلفة في بيئة التطوير، وتصورها، ورسم خرائط لها. تُستخدم هذه المعلومات لربط العناصر من لغات مختلفة بسرعة، وتوفير إمكانية التتبع بين النماذج المختلفة. ثالثًا، استنادًا إلى علاقات الاتساق ومعلومات التنقل حول كيفية ارتباط العناصر، تستطيع الأدوات تقديم التوجيه، وتحديدًا إكمال النموذج أو المساعدة. على سبيل المثال، يمكن توفير إكمال النموذج بطريقة عامة عبر الأدوات المتخصصة في مجال معين.

يمكن اعتبار أسلوب التنسيق ^{[ 1 ]} إطارًا مفاهيميًا يحدد سير عمل معينًا عند التعامل مع لغات برمجة متعددة. لا تدعم بيئة التطوير المتكاملة الخطوات الثلاث المتتالية التي يتكون منها هذا السير. ينصب التركيز بدلًا من ذلك على توسيع بيئات المطورين الحالية لإضافة دعم لـ (1) التحديد، (2) المواصفات، و(3) التطبيق. تكمن الميزة الرئيسية لهذا النهج في أن المطورين اختبروا عملنا فعليًا وقدموا لنا ملاحظاتهم. يُعد هذا النوع من تقييم الأسلوب قيّمًا لأنه يقلل من مخاطر حل مشكلة افتراضية بحتة. تُقدم العديد من الأوراق البحثية الخطوات المختلفة لأسلوب التنسيق، وتُقدم تقارير عن هذا التقييم، وتُفصّل الجوانب التقنية لكل تجربة على حدة. بشكل عام، كانت النتائج واعدة: فقد تم اكتشاف عدد كبير من الأخطاء في أنظمة الإنتاج، مما أدى إلى حوار بنّاء مع المطورين حول متطلبات الأدوات المستقبلية. تُشكل عملية التطوير القائمة على هذه الإرشادات والمدعومة بالأدوات محاولة جادة لحل مشكلة التنسيق وجعل النمذجة المتعددة الخاصة بالمجال اقتراحًا عمليًا.