. نموذج التطوير المتزامن

. نموذج التطوير المتزامن
وصف [DAV94] Davis & Sitaram نموذج التطوير المتزامن (concurrent development model), الذي يسمى أحياناً الهندسة المتزامنة, بالصيغة التالية:
عندما يتابع مدراء المشاريع حالة المشروع من خلال المراحل الرئيسة فقط – من دورة الحياة التقليدية – فإنهم لا يملكون أية فكرة عن أوضاع مشاريعهم هذه الحالة مثال على محاولة متابعة مجموعات معقدة جداً من النشاطات باستخدام نماذج بسيطة جداً. لاحظ مثلاً أنه حتى عندما يكون مشروع (كبير) في مرحلة التشفير, يوجد أشخاص في المشروع مشغولون بنشاطات مترافقة في آن معاً مع عدة مراحل تطويرية أخرى. فمثلاً, يكتب هؤلاء الاشخاص المتطلبات, ويصممون, ويشفرون, ويختبرون, ويجرون اختبارات التكامل (جميعها في آن معاً). وقد بينت نماذج عملية هندسة البرمجيات التي اقترحها [KEL89, HUM89] Humphrey , Kellner التزامن الموجود بين نشاطان تحدث خلال أي مرحلة من المراحل. وتستخدم أحدث أعمال [KEL91] Kellner مخططات حالة تدوين يمثل حالات عملية البرمجة لتمثيل علاقة التزامن الموجودة بين نشاطات مترافقة مع حدث محدد (مثلاً, تغيير المتطلبات في آخر مراحل التطوير), ولكنها أخفقت في توضيح غنى التزامن الموجود في جميع نشاطات تطوير البرمجيات وإدارتها في مشروع ما. إن معظم نماذج عمليات برمجة تطوير البرمجيات يسيرها الزمن, فكلما تقدم الزمن كان عليك التقدم في عملية التطوير. وبالمقابل يفاد (نموذج عملية البرمجة المتزامنة) باحتياجات المستخدم والقرارات الإدارية ونتائج المراجعة.
يمكن تمثيل نموذج عملية البرمجة المتزامنة تخطيطاً على شكل سلسلة من نشاطات تقنية رئيسية, ومهام وأعمال هندسة برمجيات مرافقة لها. فمثلاُ, يتحقق نشاط الهندسة المعرف للنموذج الحلزوني بتطبيق المهام التالية: النمذجة الأولية و/أو نمذجة التحليل, وتوصيف المتطلبات, والتصميم( )
[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]
يقدم الشكل أدناه تمثيلاً تخطيطياً لنشاط واحد ضمن عملية البرمجة المتزامنة. ويمكن أن يكون النشاط – التحليل – في أي من الحالات( ) المدونة في أي وقت معطى. وهكذا يمكن تمثيل نشاطات أخرى (كالتصميم أو الاتصال بالزبون) بطريقة مشابهة.تتواجد جميع النشاطات في زمن واحد, ولكنها تكون في حالات مختلفة. فمثلاً , في وقت مبكر من المشروع , وأنهى نشاط الاتصال بالزبون (غير مبين في الشكل ) دورته (iteration) الأولى ويتواجد في حلة انتظار التغييرات يقوم نشاط التحليل (الذي يوجد في حالة اللاشيء أثناء اكتمال اتصال الزبون) بالانتقال إلى حالة قيد التطوير إلى حالة انتظار التغييرات .





















يعرف نموذج عملية البرمجة المتزامنة سلسلة من الأحداث التي تسبب الانتقال من حالة إلى أخرى لكل من نشاطات هندسة البرنامج فمثلاً, يجري الكشف عن تضارب في نموذج التحليل خلال المراحل الأولى من التصميم, وهذا يولد حالة تصحيح نموذج التحليل التي تسبب انتقال نشاط التحليل من حالة الانتهاء إلى حالة انتظار التغييرات .
عادة يستخدم نموذج عملية البرمجة المتزامنة نموذجاً لتطوير تطبيقات العميل/الملقم( )(client/server). ويتألف نظام العميل/الملقم من مجموعة من المكونات الوظائفية. وعند تطبيق نموذج عملية البرمجة المتزامنة على نظام العميل/الملقم, فانه يعرف نشاطات في بعدين [SHE94] (dimensions) بعد النظام وبعد المكون وتعالج موضوعات مستوى النظام باستخدام ثلاثة نشاطات: التصميم والتجميع والاستخدام ويعالج بعد المكون بفعاليتين: التصميم والتحقيق (realization) ويتحقق التزامن بطريقتين:
1. تحدث نشاطات النظام والمكون في آن معاً , ويمكن نمذجتها باستخدام الأسلوب الحالي التوجه (state-oriented approach) الموصوف سابقاً.
2. ينجز تطبيق عادي للعميل/ملقم بمكونات عديدة, يمكن تصميم وتحقيق كل منها على نحو متزامن.

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

6 . نموذج تجميع المكونات:
تقدم التكنولوجيات الغرضية هيكلا تقنيا لنموذج عملية برمجة يعتمد على المكونات لهندسة البرمجيات، يهتم النموذج ألغرضي التوجه بإنشاء أصناف تغلف كلا من البيانات والخوارزميات المستخدمة لتناول البيانات، وتكون هذه الأصناف الغرضية التوجه قابلة للاستخدام أكثر من مرة في تطبيقات وبنى أنظمة مبنية على كمبيوترات مختلفة، وذلك إذا صممت ونفذت بشكل مناسب.
يستخدم نموذج تجميع المكونات (Component assembly model) (الشكل التالي) كثيراً من خصائص النموذج الحلزوني فهو تطوري بطبيعته (NE92) ويتطلب طريقة تكرارية لإنشاء البرمجيات وعلى كل حال, يجمّع نموذج تجميع المكونات التطبيقات من مكونات برمجية جاهزة مسبقاً (prepackaged, تسمى أحياناً اصناف, Classes).
تبدأ الفعالية الهندسية بعملية تمييز الأصناف المرشحة للاستخدام ويتحقق ذلك باختبار البيانات المطلوب أن يعالجها هذا التطبيق, والخوارزميات التي ستستعمل لتحقيق هذه المعالجة( ) . وتوضع الخوارزميات والبيانات الموافقة في صنف ما.
تحفظ الأصناف التي أنشئت في مشاريع هندسة برمجية ماضية في مكتبة أصناف (Class library) أو في مخزن (Repository), وحالما تميز أصناف مرشحة, يجري البحث في مكتبة الأصناف ليُعلم: هل هذه الفئات موجودة سابقاً؟ وتستخلص من المكتبة, تجري هندستها باستخدام الطرق الغرضية التوجه. يشكل بعدئذ التزايد الأول من التطبيق المطلوب بناءه باستخدام الأصناف مستخلصة من المكتبة, وأي فئات جديدة مبنية لتحقيق المتطلبات الخاصة بالتطبيق. يعود بعدئذ تدفق عملية البرمجة إلى الحلزون, ويعود أخيراً للدخول إلى تزايدات تجميع المكونات خلال الدورات التالية عبر نشاط الهندسة.











يقود نموذج تجميع المكونات إلى عادة استخدام البرمجيات, وتزود إعادة الاستخدام مهندس البرمجيات بعدد من الفوائد القابلة للقياس, فقد أفادت شركة QSM Associates اعتماداً على دراسات الاستخدام أن تجمع المكونات يقود إلى تقليل زمن دور التطوير بنسبة 70% وتخفيض كلفة المشروع بنسبة 84%, ومؤشر إنتاجية قيمته 26.2 بالمقارنة بمقياس الصناعة البالغ 16.9 (YOU94). ومع إن هذه النتائج تابعة لقوة ومتانة مكتبة المكونات, فلا يوجد أدنى شك في أن نموذج تجميع المكونات يقدم ميزات هامة لهندسة البرمجيات.
7. نموذج الطرق الصورية
يشمل نموذج الطرق الصورية (formal methods model) مجموعة من النشاطات التي تقود إلى مواصفات رياضية لبرمجيات الكمبيوتر. وتمكن الطرق الصورية مهندس البرمجيات من وصف نظام معتمد على الكمبيوتر وتطويره والتحقق من صحة عمله بتطبيق تدوين رياضي دقيق. حالياً يطبق بعض مؤسسات تطوير البرمجيات نسخة معدلة عن هذه الطريقة تسمى برمجيات الغرفة النظيفة (Clean Room software engineering) [MIL89,DYE92] .
تقدم الطرق الصورية عند استخدامها خلال التطوير آلية لإزالة العديد من المشاكل التي يصعب حلها باستخدام بقية نماذج هندسة البرمجيات. ويمكن اكتشاف حالات الغموض وعدم الاكتمال وعدم الانسجام (التضارب) وتصحيحها بسهولة أكثر , وليس باستخدام مراجعة مناسبة وإنما تطبيق التحليل الرياضي عندما نستخدم الطرق الصورية خلال التصميم فإنها تفيد كأساس للتحقق من صحة البرنامج ولهذا فهي تسمح لمهندس البرمجيات باكتشاف وتصحيح الأخطاء التي يمكن أن تبقى غير مكتشفة.
رغم إن نموذج الطرق الصورية لم يصبح بعد طريقة سائدة, إلا انه يعطي برمجيات خالية من العيوب ومع ذلك فهناك مخاوف حول قابلية تطبيقه في بيئة الأعمال منها ما يلي:
1. تطوير النماذج الصورية حالياً مكلفا ويستغرق وقتاً طويلاً.
2. هناك حاجة ماسة إلى التدريب, لأنه قلة فقط من مطوري البرمجيات قادرين على تطبيق هذه الطرق الصورية.
3. يصعب استخدام هذه الطرق كآليات للتواصل مع زبون غير متطور تقنياً.
إذا جرى دحض هذه الاتهامات , فمن الممكن أن يكسب نموذج الطرق الصورية موالين من مطوري البرمجيات, وخاصة المطالبين منهم ببناء برمجيات تهتم كثيراً بالأمان (safety , كمطوري الكترونيات الطيران للطائرات ومطوري برمجيات المعدات الطبية) والمطورين الذين سيعانون ضائقة مالية إذا حدث خطأ في البرمجيات.


[ندعوك للتسجيل في المنتدى أو التعريف بنفسك لمعاينة هذا الرابط]