هندسة زمن المسار ذهابا وعودة
هندسة زمن المسار ذهابًا وعودة (RTE) هي وظيفة من أدوات تطوير البرمجيات التي تزامن اثنين أو أكثر من القطع الأثرية البرمجية ذات الصلة، مثل، الشيفرة المصدرية، والنماذج، وملفات التكوين، وحتى الوثائق.[1] تنشأ الحاجة إلى هندسة زمن المسار ذهابًا وعودة عند وجود نفس المعلومات في العديد من القطع الأثرية، وبالتالي قد يحدث تضارب إذا لم يتم تحديث جميع القطع الأثرية باستمرار لتعكس تغييرًا معينًا. على سبيل المثال، تمت إضافة أو تغيير جزء من المعلومات في قطعة أثرية واحدة فقط، ونتيجة لذلك، فقد في أو غير متناسق مع القطع الأثرية الأخرى.
ترتبط هندسة زمن المسار ذهابًا وعودة ارتباطًا وثيقًا بتخصصات هندسة البرمجيات التقليدية: الهندسة المتقدمة (إنشاء البرمجيات من المواصفات)، والهندسة العكسية (إنشاء المواصفات من البرمجيات الموجودة)، وإعادة هيكلة الكود (فهم البرمجات الحالية وتعديلها). غالبًا ما يتم تعريف هندسة زمن المسار ذهابًا وعودة بشكل خاطئ على أنها مجرد دعم للهندسة الأمامية والعكسية. في الواقع، السمة الرئيسية لهندسة زمن المسار ذهابًا وعودة التي تميزها عن الهندسة الأمامية والعكسية هي القدرة على مزامنة الآثار الموجودة التي تطورت في وقت واحد بشكل متزايد عن طريق التحديث التدريجي لكل قطعة أثرية لتعكس التغييرات التي تم إجراؤها على القطع الأثرية الأخرى. علاوة على ذلك، يمكن النظر إلى الهندسة الأمامية كمثال خاص لهندسة زمن المسار ذهابًا وعودة حيث توجد المواصفات فقط ويمكن رؤية الهندسة العكسية كمثال خاص لهندسة زمن المسار ذهابا وعودة حيث توجد البرمجيات فقط. يمكن أيضًا فهم العديد من أنشطة إعادة الهندسة على أنها هندسة زمن المسار ذهابًا وعودة عند تحديث البرنامج ليعكس التغييرات التي تم إجراؤها على المواصفات الهندسية العكسية السابقة.
ميزة أخرى لهندسة زمن المسار ذهابًا وعودة هي التحديث التلقائي للقطع الأثرية ردا على التناقضات المكتشفة تلقائيًا. وبهذا المعنى، فإنه يختلف عن الهندسة الأمامية والعكسية التي يمكن أن تكون يدوية (تقليدية) وتلقائية (عبر الإنشاء التلقائي أو تحليل القطع الأثرية). يمكن أن يكون التحديث التلقائي إما لحظية أو عند الطلب. في هندسة زمن المسار ذهابًا وعودة الآنية، يتم تحديث جميع القطع الأثرية ذات الصلة فورًا بعد إجراء كل تغيير على أحدها. في هندسة زمن المسار ذهابًا وعودة عند الطلب، قد يقوم مؤلفو القطع الأثرية في الوقت نفسه بتطوير القطع الأثرية (حتى في بيئة موزعة) ويختارون في مرحلة ما تنفيذ المطابقة لتحديد التناقضات واختيار نشر بعضها والتوفيق بين الصراعات المحتملة.
تدعم هندسة زمن المسار ذهابًا وعودة عملية تطوير تكرارية. بعد مزامنة النموذج الخاص بك مع التعليمات البرمجية المنقحة، لا يزال لديك الحرية في اختيار أفضل طريقة للعمل، قم بإجراء المزيد من التعديلات على التعليمات البرمجية أو إجراء تغييرات على النموذج الخاص بك. يمكنك المزامنة في أي من الاتجاهين في أي وقت ويمكنك تكرار الدورة عدة مرات حسب الضرورة.
أمثلة على هندسة زمن المسار ذهابًا وعودة عدل
ربما يكون الشكل الأكثر شيوعًا لهندسة زمن المسار ذهابًا وعودة هو المزامنة بين نماذج لغة النمذجة الموحدة (UML) وشيفرة المصدر المقابلة. العديد من الأدوات التجارية والنماذج الأولية البحثية تدعم هذا الشكل من هندسة زمن المسار ذهابًا وعودة، يسرد كتاب عام 2007 روز الرشيد وبورلاند معا ونموذج ESS وبلويج وكان من بين أولئك القادرين، حيث يُقال أنه كان قادر أيضًا على تحديد أنماط التصميم.[2] عادة، يتم دعم الرسوم البيانية لفئة لغة النمذجة الموحدة إلى حد ما، ومع ذلك، لا تحتوي بعض مفاهيم لغة النمذجة الموحدة، مثل الارتباطات والاحتواء، على تمثيلات واضحة في العديد من لغات البرمجة مما يحد من قابلية استخدام الكود الذي تم إنشاؤه ودقة تحليل الكود (على سبيل المثال، من الصعب التعرف على الاحتواء في الكود). يشير كتاب عام 2005 حول مايكروسوفت فيجوال ستوديو على سبيل المثال إلى أن المشكلة الشائعة في أدوات هندسة زمن المسار ذهابًا وعودة هي أن النموذج المعكوس ليس هو نفس النموذج الأصلي، ما لم يتم مساعدة الأدوات بواسطة التعليقات التوضيحية الشاقة.[3] تفرض الأجزاء السلوكية من لغة النمذجة الموحدة المزيد من التحديات لهندسة زمن المسار ذهابًا وعودة.
يتم تنفيذ شكل أكثر قابلية للتتبع من هندسة زمن المسار ذهابًا وعودة في سياق واجهة برمجة التطبيقات (APIs)، حيث تتم مزامنة نموذج يصف استخدام واجهة برمجة تطبيقات إطار عمل من قبل تطبيق مع رمز هذا التطبيق. في هذا الإعداد، تصف واجهة برمجة التطبيقات جميع الطرق الصحيحة التي يمكن من خلالها استخدام إطار العمل في التطبيقات، مما يسمح بالكشف الدقيق والكامل عن استخدامات واجهة برمجة التطبيقات في التعليمات البرمجية بالإضافة إلى إنشاء تعليمات برمجية مفيدة تستخدم استخدامات واجهة برمجة التطبيقات الصحيحة. اثنان من تطبيقات هندسة زمن المسار ذهابًا وعودة البارزة في هذه الفئة هما لغات النمذجة الخاصة بالإطار و(Spring Roo).
تعد هندسة زمن المسار ذهابا وعودة أمرًا بالغ الأهمية للحفاظ على الاتساق بين النماذج المتعددة وبين النماذج والشيفرة في البنية التي تعتمد على النموذج لمجموعة إدارة الكائنات. اقترح OMG معيار QVT (الاستعلام / العرض / التحويل) للتعامل مع تحويلات النموذج المطلوبة لـ MDA. حتى الآن، تم إنشاء عدد قليل من تطبيقات المعيار. (الحاجة لتقديم تجارب عملية مع MDA فيما يتعلق هندسة زمن المسار ذهابًا وعودة).
أمثلة في هندسة البرمجيات عدل
تحتاج هندسة زمن المسار ذهابًا وعودة على أساس لغة النمذجة الموحدة (UML) إلى ثلاثة مكونات أساسية لتطوير البرمجيات:
- محرر الشيفرة المصدرية.
- محرر لغة النمذجة الموحدة للسمات والطرق.
- تصور هيكل لغة النمذجة الموحدة.
يمكن الوصول إلى مثال على هندسة زمن المسار ذهابًا وعودة كأداة مفتوحة المصدر قائمة على الويب:
- يسمح جافا سكريبت الخالق الفئة[4] بهندسة زمن المسار ذهابًا وعودة لأصناف جافا سكريبت. يتم إنشاء مخططات لغة النمذجة الموحدة بمكتبة المخططات JointJS.[5] يتم تحرير شيفرة مصدر جافا سكريبت مع المحرر ACE.[6]
مراجع عدل
- ^ Gentle، Anne (2012). Conversation and Community: The Social Web for Documentation (ط. 2nd). XML Press. ISBN:978-1937434106.
- ^ Stephan Diehl (2007). Software Visualization: Visualizing the Structure, Behaviour, and Evolution of Software. Springer Science & Business Media. ص. 63. ISBN:978-3-540-46505-8.
- ^ Andrew Filev؛ Tony Loton؛ Kevin McNeish؛ Ben Schoellmann؛ John Slater؛ Chaur G. Wu (2005). Professional UML Using Visual Studio .Net. John Wiley & Sons. ص. 181. ISBN:978-0-7645-5875-7.
- ^ JavaScript Class Creator, غيت هاب. نسخة محفوظة 2018-06-11 على موقع واي باك مشين.
- ^ JointJS, غيت هاب. نسخة محفوظة 2019-02-22 على موقع واي باك مشين.
- ^ ACE. نسخة محفوظة 2020-07-13 على موقع واي باك مشين.
