هندسة الرحلة ذهابًا وإيابًا

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

ملخص

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

الأنواع

تصف كتب مختلفة نوعين من RTE: [ 2 ] : 459

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

المزامنة التلقائية

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

النهج التكراري

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

برمجة

تدعم العديد من الأدوات التجارية والنماذج الأولية البحثية هذا الشكل من هندسة البرمجيات في الوقت الحقيقي؛ ويذكر كتاب صدر عام 2007 أن Rational Rose و Together و ESS-Model و BlueJ و Fujaba من بين الأدوات القادرة على ذلك، مع الإشارة إلى أن Fujaba قادرة أيضًا على تحديد أنماط التصميم . [ 3 ]

القيود

يشير كتاب صدر عام ٢٠٠٥ عن برنامج Visual Studio ، على سبيل المثال، إلى أن إحدى المشكلات الشائعة في أدوات محرر النصوص المنسقة (RTE) هي أن النموذج المعكوس لا يكون مطابقًا للنموذج الأصلي، ما لم تُساعد هذه الأدوات بإضافة تعليقات توضيحية مُرهقة في شفرة المصدر. [ ٤ ] وتُشكّل الأجزاء السلوكية من لغة النمذجة الموحدة (UML) تحدياتٍ إضافيةً لمحرر النصوص المنسقة.

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

يُطبَّق شكلٌ أكثر سهولةً من هندسة الرحلة ذهابًا وإيابًا في سياق واجهات برمجة تطبيقات الأطر البرمجية (APIs)، حيث تتم مزامنة نموذج يصف استخدام واجهة برمجة تطبيقات الإطار البرمجي من قِبَل تطبيقٍ ما مع كود ذلك التطبيق. في هذا السياق، تُحدِّد واجهة برمجة التطبيقات جميع الطرق الصحيحة لاستخدام الإطار البرمجي في التطبيقات، مما يسمح بالكشف الدقيق والكامل عن استخدامات واجهة برمجة التطبيقات في الكود، بالإضافة إلى إنشاء كود مفيد يُنفِّذ استخدامات واجهة برمجة التطبيقات الصحيحة. ومن أبرز تطبيقات هندسة الرحلة ذهابًا وإيابًا في هذه الفئة لغات النمذجة الخاصة بالأطر البرمجية و Spring Roo (Java).

تُعدّ هندسة الرحلات المتبادلة (RIDE) أساسيةً للحفاظ على التناسق بين النماذج المتعددة، وبين النماذج والبرمجيات في بنية البرمجيات الموجهة بالنماذج (MDA) التابعة لمجموعة إدارة الكائنات (OMG) . وقد اقترحت OMG معيار QVT (الاستعلام/العرض/التحويل) للتعامل مع تحويلات النماذج المطلوبة لـ MDA. وحتى الآن ، تم تطوير عدد قليل من تطبيقات هذا المعيار. (يلزم عرض تجارب عملية مع MDA فيما يتعلق بهندسة الرحلات المتبادلة).

الجدل

جدل حول توليد الشفرة

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

تعرضت مواصفات مخططات UML (في حال استخدامها في MDA) لانتقادات بسبب افتقارها إلى التفاصيل اللازمة لاحتواء نفس المعلومات التي يغطيها مصدر البرنامج. بل إن بعض المطورين يزعمون أن "البرنامج هو التصميم". [ 5 ] [ 6 ]

العيوب

هناك خطر جدي يتمثل في أن الكود المُولّد سيختلف بسرعة عن النموذج، أو أن النموذج المُعاد هندسته سيفقد انعكاسه على الكود، أو مزيج من هاتين المشكلتين نتيجة لجهود إعادة الهندسة المتكررة. [ 7 ]

فيما يتعلق بالجزء السلوكي/الديناميكي من لغة النمذجة الموحدة (UML) لميزات مثل مخطط الحالة، لا يوجد ما يكافئها في لغات البرمجة. ستؤدي ترجمتها أثناء توليد الكود إلى if,switch,enumفقدان أو سوء تفسير عبارات البرمجة الشائعة (مثل .eg). وإذا تم تعديلها وإعادة استيرادها، فقد ينتج عنها نموذج مختلف أو غير مكتمل. [ 8 ] [ 9 ] وينطبق الأمر نفسه على مقتطفات الكود المستخدمة في مرحلة توليد الكود لتنفيذ النمط والمنطق الخاص بالمستخدم: فعند مزجها، قد يصعب عكس هندستها. [ 8 ] [ 9 ]

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

أمثلة في هندسة البرمجيات

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

تتطلب هندسة الرحلات ذهابًا وإيابًا القائمة على لغة النمذجة الموحدة (UML) ثلاث أدوات أساسية لتطوير البرمجيات:

  • محرر شفرة المصدر؛
  • محرر UML للسمات والأساليب؛
  • تصور بنية UML

مراجع

  1. جنتل، آن (2012). المحادثة والمجتمع: الشبكة الاجتماعية للتوثيق (  الطبعة الثانية). دار نشر XML. رقم ISBN 978-1937434106.
  2. صبح، طارق م. (2008). التطورات في علوم وهندسة الحاسوب والمعلومات . المؤتمر الدولي حول الأنظمة وعلوم الحوسبة وهندسة البرمجيات. نيويورك: سبرينغر. ISBN 978-1-4020-8741-7.
  3. ستيفان ديل (2007). تصوير البرمجيات: تصوير بنية البرمجيات وسلوكها وتطورها . سبرينغر ساينس آند بيزنس ميديا. ص 63. ISBN  978-3-540-46505-8.
  4. أندرو فيليف؛ توني لوتون؛ كيفن ماكنيش؛ بن شولمان؛ جون سلاتر؛ تشاور جي. وو (2005). UML الاحترافي باستخدام Visual Studio .Net . جون وايلي وأولاده. ص 181. ISBN  978-0-7645-5875-7.
  5. http://www.developerdotstar.com/mag/articles/reeves_design_main.html بقلم جاك دبليو. ريفز
  6. ريفز، جاك دبليو. (1992). "ما هي هندسة البرمجيات؟" . www.bleading-edge.com . مجلة سي++ . تاريخ الاسترجاع: 25 يوليو 2023 .
  7. "مساعدة -" . www.modeliosoft.com . تم الاطلاع عليه بتاريخ 25-07-2023 .
  8. 1 2 سيجل، دانيال. "لماذا لا تنجح هندسة الرحلة ذهابًا وإيابًا | خبير نمذجة ليبر ليبر" . تم الاسترجاع في 25-07-2023 .
  9. 1 2 3 "8 أسباب لفشل المناهج القائمة على النماذج" . InfoQ . تم الاطلاع عليه بتاريخ 29-07-2023 .