تذكير بمساهمة فاتح الموضوع :هذا شرح مبسط ., لـ UML مترجم للغة العربية .,~
......
داخل عملية التطوير
UML ترميز
عند تطويرهم لUML ، اتخذ الأصدقاء الثلاثة قرارا واضحا جدا بعدم تضمين اللغة أية قضايا تتعلق بالعمليات process. ذلك لأن العمليات تثير الكثير من الجدل - فما يسري على شركة ما قد يشكل كارثة بالنسبة لشركة أخرى. فشركة مختصة بمجالات الدفاع تتطلب عمليات توثيق و جودة و اختبارات أعقد بكثير من شركة مختصة بالتجارة الإلكترونية. لذلك فإن لغة UML عمومية، لغة عامة تسمح بالتقاط المفاهيم الأساسية لتطوير البرمجيات و وضعها على "ورقة".
بعبارة أخرى، UML هي ببساطة لغة أو أداة ترميز أو قواعد نحوية ، سمّها ما شئت. المهم، أنها لن ترشدك الى كيف يتم تطوير البرمجيات.
لكي تتعلم كيفية استخدام UML بكفاءة، سوف نتعامل مع عملية process مبسّطة خلال الدروس القادمة، و نحاول فهم كيف تساعدنا UML في كل مرحلة. و كبداية، لنلقى نظرة أولا على بعض العمليات البرمجية الشائعة.
النموذج الإنحداري Waterfall Model
شكل 2: النموذج "الانحداري" التقليدي.
بحسب النموذج الانحداري كل مرحلة يجب إنهائها قبل الشروع في المرحلة التي تليها.
هذه العملية المبسطة (و التي يسهل ادارتها) تبدأ بالتداعي بمجرد أن
يزداد تعقيد و حجم المشروع. أهم مشاكلها هي:
* حتى الأنظمة الضخمة يجب أن تكون مفهومة و سبق تحليلها بالكامل قبل مباشرة مرحلة التصميم. فيزداد بهذا التعقيد و يصبح عبئا على المطوّرين.
* المخاطر Risk تتجمع لاحقا. المشاكل عادة ما تظهر في المراحل الأخيرة من العملية - خاصة خلال التحام النظام. و للأسف، تزداد تكلفة تصحيح الأخطاء بصورة مضاعفة مع مرور الزمن.
* في المشاريع الكبيرة، كل مرحلة تستغرق فترات طويلة مبالغ فيها. مرحلة اختبار بطول سنتين ليست بالتأكيد وصفة جيدة لشحن ذاكرة فريق العمل!
أيضا، حيث أن مرحلة التحليل تنجز في مخاض قصير مع تدشين المشروع، سنواجه مخاطرة جدية تتمثل في القصور في فهم متطلبات الزبون. حتى لو التزمنا باجراءات صارمة لادارة المتطلبات و قمنا بصياغتها تعاقديا مع الزبون. هناك دائما احتمال بأنه مع استكمال التوليف coding و الدمج integration و الاختبار لن يكون المنتج النهائي بالضرورة هو ما يتوقعه الزبون.
برغم كل ما ذكرنا، لا يوجد عيب في النموذج الانحداري، بشرط أن يكون المشروع صغيرا بما يكفي. صحيح ان تعريف "صغير بما يكفي" قابل للنقاش، و لكنه أساسي، فإذا أمكن لمشروع أن يتصدى له فريق صغير من الأفراد، كل فرد على دراية بجميع جوانب المشروع، و إذا كانت فترة المشروع قصيرة (بضعة أشهر)، عندها يكون النموذج الانحداري عملية لها قيمتها. فهو أفضل بكثير من الخبط العشوائي!
بايجاز، النموذج الانحداري سهل الفهم و بسيط في ادارته. لكن مميزات هذا النموذج تبدأ في التداعي بمجرد أن يزداد تعقيد المشروع.
النموذج اللولبي
الاسلوب البديل هو النموذج اللولبي، حيث نقوم بالتصدّي للمشروع عن طريق تقسيمة إلى سلسلة من الدورات الحياتية lifecycles القصيرة ، كل دورة تنتهي باصدار لبرنامج قابل للتنفيذ.
شكل 4: العملية اللولبية، هنا يتم تقسيم المشروع إلى خمسة أطوار، كل طور يُبنى فوق سابقه، و كل طور ينتهي بانتاج اصدارة لبرنامج جاهز للتشغيل.
مع هذا الاسلوب :
* يستطيع فريق العمل أن يشتغل على كامل الدورة الحياتية (تحليل، تصميم، توليف Code، اختبار) بدلا من صرف سنوات على نشاط واحد.
* يمكننا الحصول على ملاحظات وتقييم الزبون مبكرا و بصورة منتظمة، ورصد الصعوبات المحتملة قبل التمادي بعيدا في عمليات التطوير.
* يمكننا التصدّي لنقاط المخاطرة مقدما، بالأخص التكرارات ذات المجازفة العالية (مثلا: التكرار الذي يتطلب تنفيذ بعض التقنيات الجديدة غير المجرّبة) يمكن تطويرها أولا.
* يمكن اكتشاف مدى حجم و تعقيد العمل مبكرا.
* الاصدار المنتظم للبرنامج يعزّز من الثقة.
* الوضع الحالي للمشروع (مثل: مقدار ماتم انجازه) يمكن تحديده بدقة أكبر.
عيوب العملية اللولبية هي :
* عادة ما ترتبط هذه العملية بما يعرف بالتنشئة السريعة للتطبيقات Rapid Application Development ، و التي تعتبر من قبل كثيرين مجرد hacker's charter.
* العملية أكثر صعوبة في إدارتها. في النموذج الانحداري يمكن الاستعانة بالتقنيات التقليدية لإدارة المشروعات مثل مخططات كانط Gantt، لكن العمليات اللولبية تتطلب أساليب مختلفة.
من أجل تدارك عيوب العملية اللولبية، لنلقي نظرة على أسلوب مشابه لكن أكثر تقنينا و يدعى اطار العمل التكراري التزايدي Itrative, Incremental Framework.
اطار العمل التكراري التزايدي
اطار العمل التكراري التزايدي Itreative, Incremental Framework هو امتداد منطقي للنموذج اللولبي، لكنه أكثر تقنينا و صرامة. سوف نقوم بتبنّي اطار العمل التكراري التزايدي خلال بقية هذه الدروس.
ينقسم اطار العمل الى أربعة أطوار رئيسية: الاستهلال Inception، التفصيل Elaboration، البناء Construction و التنقل Transition. يتم انجاز هذه الأطوار على التوالي، لكن يجب أن لا نخلط بين هذه الأطوار و المراحل في الدورة الحياتية للنموذج الانحداري. في هذا القسم سوف نشرح هذه الأطوار و نستعرض النشاطات التي يتم أداؤها في كل طور
شكل 5: الأطوار الأربعة لإطار العمل التكراري التزايدي
الاستهلال
يتعلق طور الاستهلال بوضع نطاق المشروع و تحديد التصوّر العام له. بالنسبة للمشاريع الصغيرة يمكن لهذا الطور أن يكون مجرد دردشة بسيطة على فنجان قهوة يعقبها اتفاق على البدء في المشروع. في المشاريع الكبيرة يتطلب الأمر المزيد من التحرّي. المخرجات deliverables المحتملة من هذا الطور هي:
* وثيقة التصوّر.
* استكشاف مبدئي لإحتياجات الزبون.
* التحديد الابتدائي لمفردات glossary المشروع (المزيد حول هذا لاحقا).
* دراسة جدوى (تتضمن مححدات النجاح، التنبؤات المالية، تقديرات العائد على الاستثمار، الخ).
* التحديد المبدئي لنقاط المخاطرة.
* خطة المشروع.
سوف نناقش طور الاستهلال بشيء من التفصيل عندما نتعرض لدراسة حالة case study في الفصل الرابع.
التفصيل
الغرض من التفصيل هو تحليل المشكلة ، و المضي خطوة ابعد في اعداد خطة المشروع، و استبعاد المناطق الأكثر مخاطرة فيه. مع نهاية طور التفصيل نأمل في الحصول على فهم عام لكامل المشروع، و لكن ليس بالضرورة فهما متعمقا (لاحقا سيتم التصدي له بصورة أجزاء صغيرة يسهل مناولتها).
نموذجان من UML يكون لهما قيمة كبيرة في هذه المرحلة. نموذج حالة الاستخدام Use Case سيساعدنا في متطلبات المستفيد= الزبون ، و مخطط الطبقة Class Diagram و الذي ايضا يمكن استخدامه لاستكشاف المفاهيم العامة التي يتصورها المستفيد. المزيد حول هذا الموضوع قريبا.
البناء
في طور البناء، نقوم ببناء المنتج. هذا الطور لن يتحقق بأسلوب خطي Linear ؛ بل يتم بناؤه بنفس أسلوب النموذج اللولبي، من خلال سلسلة من التكرارات. كل تكرار هو نفسه الاسلوب القديم: نموذج انحداري(3) بسيط. و من خلال الحرص على أن يكون كل تكرار أقصر ما يمكن، نأمل أن نتجنب المشاكل المزعجة التي ترافق الانحداريات
شكل 6: طور البناء و يحتوي على سلسلة من الانحدارات المصغرة.
مع نهاية أكبر عدد من من التكرارات سوف نطمح في الحصول على منظومة تعمل (مبدئيا بالطبع، ستكون منظومة محدودة جدا في المراحل المبكرة). هذه التكرارات تسمّى تزايدات Increments، ومن هنا أتت تسمية اطار العمل هذا!
التحوّل (الانتقال) Transition
الطور النهائي يتعلق بنقل المنتج النهائي الى الزبائن. النشاطات المعتادة في هذا الطور تتضمن:
* الاصدارات المبدئية لأغراض الاختيار من قبل بيئة المستخدم.
* الاختبارات في الموقع، أو تشغيل المنتج بالتوازي مع النظام القديم الذي سيستبدل.
* تجهيز البيانات (مل تحويل قواعد البيانات و صبّها في قوالبها الجديدة، توريد البيانات ، الخ..)
* تدريب المستخدمين الجدد.
* التسويق والتوزيع و المبيعات.
يتــــابع <<<