بنية تعتمد على النموذج

يرتبط نموذج MDA بمعايير متعددة، بما في ذلك لغة النمذجة الموحدة (UML)، ومرفق الكائنات الوصفية (MOF)، وتبادل بيانات XML الوصفية (XMI)، وحوسبة الكائنات الموزعة للمؤسسات (EDOC)، ونموذج هندسة عمليات البرمجيات الوصفية (SPEM)، ونموذج المستودعات الوصفية المشتركة (CWM). تجدر الإشارة إلى أن مصطلح "البنية" في هندسة البرمجيات الموجهة بالنماذج لا يشير إلى بنية النظام قيد النمذجة، بل إلى بنية المعايير المختلفة وأشكال النماذج التي تُشكل الأساس التقني لـ MDA.

كان ملف تعريف UML القابل للتنفيذ هو ملف تعريف UML المستخدم عند ظهور هندسة النماذج الهندسية (MDA). أما الآن، فتروج مجموعة إدارة الكائنات (OMG) لملف تعريف fUML بدلاً منه. (لغة العمل الخاصة بـ fUML هي ALF).

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

تركز OMG على هندسة البرمجيات الموجهة بالنماذج (Model Driven Architecture®) من خلال الهندسة الأمامية، أي إنتاج الشفرة البرمجية من مخططات نمذجة مجردة ومفصلة يدويًا (مثل مخططات الفئات) . يقود فريق عمل التحليل والتصميم (ADTF) التابع لـ OMG هذا الجهد. وبشيء من الدعابة، اختار الفريق اسم ADM (اختصارًا لـ MDA معكوسًا) لدراسة الهندسة العكسية. يُشير ADM إلى التحديث الموجه بالهندسة المعمارية. يهدف ADM إلى وضع معايير للهندسة العكسية القائمة على النماذج للأنظمة القديمة. ^{[ 4 ]} يُعد نموذج اكتشاف المعرفة (KDM) الأكثر تقدمًا بين هذه الجهود، ويصف أنظمة المعلومات من حيث الأصول المختلفة (البرامج، والمواصفات، والبيانات، وملفات الاختبار، ومخططات قواعد البيانات، وما إلى ذلك).

مع تطور المفاهيم والتقنيات المستخدمة في تصميم الأنظمة، وكذلك في بناء بنى البرمجيات، بوتيرة متسارعة، يتيح فصلها لمطوري الأنظمة اختيار الأنسب والأكثر ملاءمة لكلا المجالين. يُعنى التصميم بالمتطلبات الوظيفية ( حالات الاستخدام )، بينما توفر بنية البرمجيات البنية التحتية اللازمة لتحقيق المتطلبات غير الوظيفية، مثل قابلية التوسع والموثوقية والأداء. وتتوقع منهجية MDA أن يظل النموذج المستقل عن المنصة (PIM)، الذي يمثل تصميمًا مفاهيميًا يحقق المتطلبات الوظيفية، قادرًا على الصمود أمام تغيرات تقنيات التنفيذ وبنى البرمجيات .

يُعد مفهوم تحويل النموذج ذا أهمية خاصة في هندسة البرمجيات الموجهة بالنموذج . وقد حددت مجموعة إدارة الكائنات (OMG) لغة قياسية محددة لتحويل النموذج تُسمى QVT .

تقدم منظمة OMG مواصفات عامة بدلاً من تطبيقات عملية، غالباً كإجابات على طلبات تقديم العروض . وتوثق OMG العملية برمتها في وثيقة تُسمى دليل MDA.

باختصار، أداة MDA هي أداة تُستخدم لتطوير النماذج أو النماذج الفوقية وتفسيرها ومقارنتها ومواءمتها وقياسها والتحقق منها وتحويلها، وما إلى ذلك. ^{[ 5 ]} في القسم التالي، يُفسَّر مصطلح "النموذج" على أنه أي نوع من النماذج (مثل نموذج UML) أو النماذج الفوقية (مثل نموذج CWM الفوقي). في أي منهجية MDA، لدينا نوعان أساسيان من النماذج: النماذج الأولية التي يُنشئها المستخدمون يدويًا، والنماذج المشتقة التي تُنشأ تلقائيًا بواسطة البرامج. على سبيل المثال، قد يُنشئ محلل نموذج UML أوليًا بناءً على ملاحظته لحالة عمل غير محددة، بينما قد يُشتق نموذج Java تلقائيًا من نموذج UML هذا من خلال عملية تحويل النموذج .

قد تكون أداة MDA أداة تستخدم للتحقق من اكتمال النماذج أو التناقضات أو حالات الخطأ والتحذير.

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

تأتي تطبيقات مواصفات OMG من شركات خاصة أو مجموعات مفتوحة المصدر . وتُعد مؤسسة Eclipse (EF) مصدرًا هامًا لتطبيقات مواصفات OMG . يمكن العثور على العديد من تطبيقات معايير نمذجة OMG في إطار عمل نمذجة Eclipse (EMF) أو إطار عمل النمذجة الرسومية (GMF)، كما تعمل مؤسسة Eclipse على تطوير أدوات أخرى ذات خصائص متنوعة مثل GMT. غالبًا ما يكون التزام Eclipse بمواصفات OMG غير صارم. ينطبق هذا، على سبيل المثال، على معيار EMOF الخاص بـ OMG، والذي يُقاربه EMF من خلال تطبيق Ecore الخاص به. يمكن العثور على المزيد من الأمثلة في مشروع M2M الذي يُطبق معيار QVT أو في مشروع M2T الذي يُطبق معيار MOF2Text.

ينبغي توخي الحذر من الخلط بين قائمة أدوات MDA وقائمة أدوات UML ، فالأولى أوسع نطاقًا. ويمكن تعميم هذا التمييز بتصنيف الأدوات إلى "أدوات النماذج الفوقية المتغيرة" و"أدوات النماذج الفوقية الثابتة". عادةً ما تكون أداة UML CASE "أداة نموذج فوقي ثابت" لأنها مصممة للعمل فقط مع إصدار محدد من نموذج UML الفوقي (مثل UML 2.1). في المقابل، تتمتع أدوات أخرى بقدرات عامة داخلية تسمح لها بالتكيف مع نماذج فوقية عشوائية أو مع نوع معين منها.

عادة ما تركز أدوات MDA على مواصفات البنية الأساسية، على الرغم من أن الأدوات في بعض الحالات تكون مستقلة عن البنية (أو مستقلة عن النظام الأساسي).

تتضمن الأمثلة البسيطة لمواصفات البنية ما يلي:

• اختيار أحد البنى المرجعية المدعومة مثل Java EE أو Microsoft .NET ،
• تحديد البنية على مستوى أدق بما في ذلك اختيار تقنية طبقة العرض، وتقنية طبقة منطق الأعمال، وتقنية الاستمرارية، وتقنية تعيين الاستمرارية (مثل مُعين الكائنات العلائقية).
• البيانات الوصفية: معلومات حول البيانات.

بعض المفاهيم الأساسية التي يقوم عليها منهج MDA (الذي أُطلق عام 2001) تم توضيحها لأول مرة من خلال منهج شلاير-ميلور خلال أواخر ثمانينيات القرن الماضي. في الواقع، تمكن بعض الموردين من تجاوز معيار تقني أساسي غائب عن منهج MDA (وهو صيغة لغة الإجراءات لـ UML القابل للتنفيذ ) عن طريق تكييف لغة إجراءات شلاير-ميلور الأصلية (المعدلة لـ UML) . مع ذلك، لم يحظَ منهج MDA بقبول واسع النطاق في الصناعة خلال هذه الفترة؛ إذ لا تزال مجموعة غارتنر تُصنّف MDA كتقنية "صاعدة" في " دورة الضجيج " لعام 2006، ^{[ 6 ]} بينما أعلنت شركة فورستر للأبحاث أن MDA "ميتة عند بدء التشغيل" في عام 2006. ^{[ 7 ]} تشمل المخاوف المحتملة التي أُثيرت بشأن منهج OMG MDA ما يلي:

• معايير غير مكتملة: يستند منهج MDA إلى مجموعة متنوعة من المعايير التقنية، بعضها لم يُحدد بعد (مثل لغة دلالية للأفعال لـ xtUML )، أو لم يُنفذ بعد بطريقة قياسية (مثل محرك تحويل QVT أو PIM مع بيئة تنفيذ افتراضية). ^{[ 8 ] [ 9 ]}
• التقييد بالمورد: على الرغم من أن منهجية MDA صُممت لتحقيق استقلالية المنصات (التقنية)، إلا أن موردي MDA الحاليين يترددون في تصميم مجموعات أدوات MDA الخاصة بهم لتكون قابلة للتشغيل البيني. قد يؤدي هذا إلى تقييد المستخدمين الذين يتبنون منهجية MDA بالمورد.
• مثالي: يُنظر إلى هندسة النماذج الموجهة (MDA) على أنها منهجية هندسية أمامية، حيث تُحوّل النماذج التي تتضمن برمجة لغة الإجراءات (Action Language) إلى عناصر تنفيذية (مثل الشيفرة التنفيذية، ومخطط قاعدة البيانات) في اتجاه واحد عبر خطوة "توليد" مؤتمتة كليًا أو جزئيًا. يتوافق هذا مع رؤية مجموعة إدارة الكائنات (OMG) بأن هندسة النماذج الموجهة (MDA) يجب أن تسمح بنمذجة التعقيد الكامل لمجال المشكلة في لغة النمذجة الموحدة (UML) (والمعايير ذات الصلة) مع التحويل اللاحق إلى تطبيق كامل (قابل للتنفيذ). ^{[ 10 ]} ومع ذلك، فإن هذا النهج يعني ضمنيًا عدم دعم التغييرات التي تُجرى على العناصر التنفيذية (مثل ضبط مخطط قاعدة البيانات). يُشكل هذا مشكلة في الحالات التي يُعتبر فيها "تكييف" العناصر التنفيذية بعد التحويل ضروريًا. وقد ظهر دليل على أن نهج هندسة النماذج الموجهة (MDA) الكامل قد يكون مثاليًا للغاية بالنسبة لبعض التطبيقات العملية في ظهور ما يُسمى "هندسة النماذج الموجهة (MDA) العملية". ^{[ 11 ]} يمزج MDA العملي بين المعايير الحرفية من MDA الخاصة بـ OMG مع أساليب أكثر تقليدية تعتمد على النموذج مثل هندسة الرحلة ذهابًا وإيابًا والتي توفر الدعم لتكييف عناصر التنفيذ (وإن لم يكن ذلك بدون عيوب كبيرة).
• المهارات المتخصصة: يتطلب العمل في هندسة البرمجيات القائمة على منهجية MDA (كما هو الحال مع أدوات أخرى) مستوى عالٍ من الخبرة في مجالهم. ويُعدّ عدد خبراء MDA الحاليين (الذين يُشار إليهم غالبًا باسم مصممي النماذج/المهندسين المعماريين) قليلًا مقارنةً بتوافر المطورين التقليديين. ^{[ 12 ]}
• سجل إنجازات OMG: قام اتحاد OMG الذي يرعى منهجية MDA (ويملك علامة MDA التجارية) أيضاً بتقديم ودعم معيار CORBA الذي فشل بدوره في أن يصبح معياراً واسع الانتشار. ^{[ 13 ]}
• عرض القيمة غير المؤكد (UVP): كما ذُكر سابقًا، تسمح رؤية MDA بتحديد النظام كنموذج مجرد، يمكن تنفيذه كتطبيق ملموس (برنامج) لمنصة حوسبة معينة (مثل .NET). وبالتالي، يمكن نظريًا نقل تطبيق تم تطويره بنجاح باستخدام منهجية MDA خالصة إلى إصدار أحدث من منصة .NET (أو حتى منصة Java) بطريقة حتمية ، على الرغم من وجود تساؤلات مهمة حول الجوانب العملية أثناء عملية النقل (مثل تنفيذ واجهة المستخدم). يبقى ما إذا كانت هذه الإمكانية تمثل عرض قيمة جوهريًا أمرًا محل نقاش بالنسبة للمستخدمين. على أي حال، ينبغي على مستخدمي MDA الذين يبحثون عن قيمة من خلال "بديل للبرمجة" توخي الحذر الشديد عند تقييم هذا النهج. سيظل تعقيد أي مجال مشكلة قائمًا، ويجب برمجة منطق الأعمال في MDA كما هو الحال مع أي نهج آخر. يكمن الاختلاف في MDA في أن لغة البرمجة المستخدمة (مثل xtUML) أكثر تجريدًا (من Java أو C# مثلًا) وتتداخل مع عناصر UML التقليدية (مثل مخططات الفئات). إن ما إذا كانت البرمجة بلغة أكثر تجريدًا من لغات الجيل الثالث السائدة ستؤدي إلى أنظمة ذات جودة أفضل أو تكلفة أقل أو تسليم أسرع، هو سؤال لم تتم الإجابة عليه بشكل كافٍ حتى الآن.
• اعتُبرت منهجية MDA وسيلةً محتملةً لدمج حلولٍ معياريةٍ مختلفةٍ طُوّرت بشكلٍ مستقل. وبالنسبة لمجتمع المحاكاة، فقد وُصِيَ بها كبديلٍ تجاريٍّ وصناعيٍّ لمعيارٍ آخر مفروضٍ من وزارة الدفاع الأمريكية. ^{[ 14 ]}