الإجرائيات الموحدة

بحث متقدم

أ ب ت ث ج ح خ د ذ ر ز س ش ص ض ط ظ ع غ ف ق ك ل م ن هـ و ي

الإجرائيات الموحدة

اجراييات موحده

Unified Prcosses - Processus unifié

الإجرائيات الموحدة

محمد الحجي

سِمات الإجرائية UP الأساسية

دورة الحياة بحسب الإجرائية UP

الأدوات

ظهرت إجرائية التطوير الموحدة The Unified Process “UP” (The Unified Software Development Process) بوصفها واحدة من منهجيات التطوير الغرضية التوجه. وكانت تتويجاً لاتفاق ثلاثة باحثين هم: جيمس رامبو James Rumbaugh وغرادي بوش Grady Booch وإيڤار جاكوبسون Ivar Jacobson الذين دعموها أيضاً بأداة بيانية قوية هي لغة النمذجة الموحدة Unified Modeling Language U M L. أصبحت هذه الأداة في عام 1997 أحد معايير صناعة البرمجيات حيث عدَّتها المجموعة OMG (تجمُّع Object Management Group هو تجمع لبعض كبريات شركات البرمجيات. من أهدافه تطوير معايير في صناعة البرمجيات، وتركيز أكثر على الأنظمة الغرضية التوجه وعلى النمذجة) المعيار الصناعي للنمذجة الغرضية التوجه. كما جرى تطوير بيئة حاسوبية مساعدة، وهي الأداة CASE من شركة Rational التي انضم إليها مطورو الإجرائية الموحدة، وتتالت بعد ذلك الأدوات الحاسوبية الداعمة من شركات مختلفة، وكذلك تابعت UML تطورها حتى ظهرت UML2 في عام 2005. وتجدر الإشارة هنا إلى الخلط الشائع بينUML - - وهي أداة نمذجة بيانية وليست منهجية - وبين الإجرائية UP التي تستخدم الأداة UML.

أما إجرائية راشيونال الموحدة Rational Unified Process (RUP) فبدأت بكونها إحدى طرق تطبيق الإجرائيةUP المدعومة ببيئة Rational الحاسوبية؛ ولما كانت الإجرائيةUP هي الأعم، فإنه يمكن النظر إلى RUP على أنها حالة تطبيقية خاصة مع إضافات وتوسعات وتغيير لبعض المزايا، ويتناول عدد من الكتب شرح مثل هذه الإجرائية RUP. وكلتا الإجرائيتين مصممتان لتكونا قابلتين للتوسيع والتعديل وفق قواعد محددة وذلك لملاءمة حاجات المستعملين المتباينة.

سِمات الإجرائية UP الأساسية

توصف الإجرائية الموحدة بأنها:

-1 تكرارية تزايدية iterative and incremental

-2 مقودة بحالات الاستخدام use case driven

-3 عنايتها الخاصة بالبنيان البرمجي..

تعني السِّمة الأولى أنه يجري تطوير أي نظام على دفعات تُسلم تباعاً بحسب الأولوية، ويعني ذلك المرور بمراحل الإجرائية تكراراً دورة بعد دورة، بحيث تنتهي كل دورة بتزايد جاهز للتسليم. وهذا ما تتّبِعه معظم المنهجيات الحديثة ولا يتسع المجال هنا لذكر فوائد ذلك مقارنة بالتعامل مع النظام كاملاً مرة واحدة.

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

تبين السمة الثالثة العناية الخاصة التي توليها UP لبنيان البرمجية، أي علاقة عناصر تصميم النظام المبني ببعضها ليكون نظاماً مستقراً متيناً حتى عند التعامل مع التغيرات.

دورة الحياة بحسب الإجرائية UP

يجري تطوير النظام المعني عند اتباع الإجرائية UP في دورات تكرارية لأربع مراحل: 1- التعريف inception، 2- الإنضاج elaboration، 3-البناء construction ء4- الانتقال transition .

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

الشكل (1) مراحل دورة الحياة بحسب الإجرائية UP
ويظهر التظليل مقدار العمل المبذول نسبياً بحسب المرحلة.

الشكل (2) مخطط حالات الاستخدام لنظام صراف آلي

ولما كانت الإجرائية UP تزايدية، فإنه يجري إصدار تزايد في نهاية كل دورة (أي بنهاية الانتقال) Transition، ولكن خلال المرور بهذه المراحل ينجز فريق التطوير عدة منتجات artifacts هي نموذج متطلبات requirement model النظام، ثم نموذج التحليل analysis model، ونموذج التصميم design model، ثم نموذج التنجيز implementation model والاختبارات tests، وهذه النماذج هي المنتجات الفعلية لعمل فريق التطوير. يبين الشكل (1) العلاقة بين المراحل الأربع والعمل على هذه النماذج.

1- المتطلبات: تقوم نمذجة المتطلبات على مخططات حالات الاستخدام، ومحورها الأساس هو مفهوم حالة الاستخدام والذي يعني حالة من حالات استعمال النظام ينتج منها خدمة ذات مغزى لبعض المتفاعلين مع النظام. وعندما يتم تعرف كل حالات استخدام النظام تتم تغطية جميع وظائف النظام. تجدر الإشارة هنا إلى أن حالات الاستخدام تنمذج بوجه أساسي المتطلبات الوظيفية functional requirements. أما المتطلبات غير الوظيفية non-functional فيُستخدم غالباً الأسلوب النصي للتعبير عنها.

يعتمد مخطط حالات الاستخدام على عنصرين: أحدهما المؤدي actor (أي له دور ضمن سيناريو معين). وثانيهما حالة الاستخدام إضافة إلى مجموعة من العلاقات. يعبر المؤدي عن دور شخص أو عنصر ما في سلسلة من التفاعلات مع النظام عند إنجاز حالة استخدام. وكل حالة استخدام تعبر عن سلسلة من التفاعلات بين النظام المنشود وبعض المؤدين بحيث ينتج منها خدمة ذات مغزى. تسمى هذه السلسلة من أفعال المؤدين وردود فعل النظام سيناريو scenario أو مجرى أحداث flow of events، ولكل حالة استخدام سيناريو رئيسي main flow of events وسيناريوهات بديلة alternative flows of events. السيناريو الرئيسي هو عموماً عندما تجري الأحداث بما يؤدي إلى حصول الخدمة المتوقعة، أما البدائل فتُعَرِّف ما يحصل عندما تأخذ بعض خطوات التفاعل بدائل مختلفة مثل إدخال المؤدي كلمة سر خطأً بدل كلمة سر صحيحة. يمكن أن يشترك أكثر من مؤدٍ في سيناريو معين، أي أن يرتبط أكثر من مؤدٍ بحالة الاستخدام المعنية.

إذا أخذنا مثالاً عن تطوير نظام مبسط لصراف آلي (الشكل 2) يمكن وصف ثلاث حالات استخدام «سحب مبلغ» و «دفع فاتورة» PayBill و«تصريف عملة» Exchange. يوجد مؤدٍ وحيد في هذا المثال المبسط هو زبون المصرف.

لا مجال هنا لكتابة كامل التوصيف، ولكن يمكن على سبيل المثال كتابة جزء مبسّط من السيناريو الرئيسي لحالة الاستخدام «سحب».

يُدخل زبون المصرف البطاقة.

يتحقق النظام من صلاحية البطاقة.

إذا كانت البطاقة صالحة يطلب النظام الرقم السري.

يدُخل الزبون الرقم السري.

يتحقق النظام من الرقم السري . . . الخ.

تتعلق السيناريوهات البديلة في هذا المثال بما سيحدث في حالات مثل عدم صلاحية البطاقة، أو إدخال رقم سري خاطئ، أو عدم توفر المبلغ، أو عدم السماح به. مثلاً إذا كانت البطاقة غير صالحة يُخرج النظام البطاقة؛ يُظهر النظام الرسائل المناسبة.

ثمة مجموعة من العلاقات التي قد تربط بين مؤديين أو بين حالتي استخدام تمنح المخططات قدرة أكبر على النمذجة والتعبير عن المطلوب، ويمكن العودة إليها في المراجع المذكورة.

يُنصح هنا أيضاً ببناء نماذج أولية prototypes عن واجهات المستخدمين وكذلك بإعداد مسرد مصطلحات glossary خاص بالنظام المعني.

2 - التحليل: تتباين المراجع في المدلول والمساق الذي يُستعمل هذا المصطلح ضمنه، ربما لأن المعنى اللغوي بالأصل عام، فتربط بعض المراجع التحليل بتحليل المتطلبات وغيرها. ويذهب العديد من المراجع إلى استعمال مصطلح مرحلة التحليل أو النموذج التحليلي للدلالة على الأفكار العامة المجردة لكيفية بناء النظام وإيجاد العناصر الأساسية لهذا البناء، أو بعبارة أخرى بناء نموذج model مفاهيمي conceptual من دون الغوص في التفاصيل، بل الاهتمام بالصورة الشاملة للحل، وهذا المعنى هو المقصود ضمن مسار الإجرائية UP.

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

تتوفر عدة أنواع من العلاقات الممكنة بين الصفوف لا يقع شرحها ضمن مجال هذا البحث، ولكن تقع ضمن الأصناف الرئيسية التالية: التعميم generalization (ومنه مفهوم الوراثة المعروف حيث الصف الأساس أو الأب هو الحالة العامة من الصف الوارث) والارتباط association والاعتمادية dependency.

إذا أُخذت حالة الاستخدام «سحب مبلغ» من المثال المذكور آنفاً، فيمكن اختيار الصفوف التالية: صف «حساب» account وصف «واجهة المستخدم» GUI وصف «مُصدر المال» dispenser، ويمكن إضافة صف مسؤوليته التحكم في العملية كلها ويسمى مثلاً Withdraw Handler. يحمل صف «سحب مبلغ» الواصفات الأساسية لحساب المصرف مثل اسم صاحب الحساب ورقم الحساب ونوعه والرقم السري والرصيد، وكذلك كل العمليات اللازمة للوصول إلى هذه الواصفات وتعديلها. ويكون صف «واجهة المستخدم» مسؤولاً عن كل عمليات التواصل مع المستخدم مثل إظهار الرسائل وقراءة المدخَلات، أما الصف «مُصدر المال» فيمثل البرمجية المتحكمة بجزء الصراف المسؤول عن إخراج المبلغ.

وإضافة إلى ما سبق يحتاج النموذج إلى علاقات ارتباط بين الصف Withdraw Handler وكل من الصفوف الأخرى. وبعد نمذجة الصفوف والعلاقات يتم الحصول على مخطط صفوف تحليلي analysis class diagram.

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

أما نمذجة السيناريوهات نفسها فتجري باستخدام أحد نوعين من المخططات التفاعلية، يدعى أحدها مخططات التخاطب communication diagrams (وكان يسمى سابقاً مخططات التعاون (collaboration diagrams والثاني مخططات التتابع sequence diagrams وهما تقريباً متكافئان. والنقطة الأساسية في هذه المخططات هي نمذجة تبادل «رسائل» بين أغراض instances من الصفوف المرتبطة بالسيناريو، وأيضاً مع المحيط الخارجي (تبادل منتسخات instances من المؤدين الذين لهم دور ضمن السيناريو). ثمة أنواع مختلفة من هذه الرسائل ولكن أغلبها تعبر عن طلب تنفيذ طريقة method معرّفة في صف المستقبِل للرسالة، أي إن سهم الرسالة يحمل اسم طريقة يطلب المرسل من المستقبل أن ينفذها. يوافق تتالي هذه الرسائل، ومن ثَم تتالي تنفيذ الطرائق المطلوبة خطوات السيناريو المعني.

تبدأ أيضاً في مرحلة التحليل الخطوات الأولى لتقسيم النظام إلى مجتزآت modules.

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

يُبنى النموذج التصميمي بالاعتماد على مخططات الصفوف ومخططات التتابع sequence diagrams كما في النموذج التحليلي ولكن بمفاهيم تصميمية، فالتفاصيل كاملة وبيئة التنجيز والتنفيذ مأخوذة في الحسبان.

تهتم الإجرائية UP في هذه المرحلة كثيراً ببنيان النظام حيث تُدرس الصفوف والعلاقات بينها لإعادة تشكيلها بأفضل ما يمكن بما لا يمس وظيفية النظام. تركز الإجرائية UP أيضاً على تطوير النظام على أساس المركِّبات components واستخدام صفوف التواجه interface classes حيث توفر الأداة UML النمذجة اللازمة لذلك. وتُعدّ صفوف التواجه صفوفاً تعرّف عمليات تحتاج إليها بعض الصفوف ويحقق تنفيذها صفوفاً أخرى، ولهذا يشير إليها بعض الباحثين على أنها «عقد» بين طرفين.

4- التنجيز والاختبارات: قد يسبق التنجيز إنشاء نماذج إضافية وخاصة في الأنظمة المعقدة. يهتم مثلاً بعض هذه النماذج بتوزيع النظام على عناصر البيئة الفيزيائية المختلفة. والتنجيز هو تحويل النظام إلى رماز code، ويوفر الكثير من البيئات الداعمة لمخططات الأداة UML التوليد الآلي لجزء من الرماز انطلاقاً من مخططات التصميم بلغات برمجية مختلفة. إضافة إلى المفاهيم والأساليب العامة المتبعة ضمن مختلف منهجيات التطوير؛ تقدم الإجرائية UP ميزات أخرى للاختبار، منها مثلاً بناء حالات اختبار test cases بالاعتماد على حالات الاستخدام ثم استخدامها في اختبارات مختلفة للنظام.

الأدوات

تتوفر مجموعة من الأدوات الحاسوبية الداعمة للأداة البيانية UML، والحديث منها يدعم الإصدار UML2. ويوفر العديد منها المساعدة للمستخدم لاتّباع الإجرائية الموحدة أو طريقة خاصة في تطبيقها مثل RUP. كذلك تقدم معظم هذه الأدوات إمكان توليد جزء من الرماز النهائي للنظام بلغات برمجة مختلفة.

تعدّ الأداة Rational Rose من أوائل الأدوات الحاسوبية الداعمة للإجرائية الموحدة، وتنوعت الأدوات الداعمة؛ فمنها المجاني ذو الحجم الصغير مثل StarUML وكما هو متوقع تعاني الأدوات المجانية قصوراً في جوانب متعددة. وهناك الأدوات المفتوحة المصدر open source مثل ClassBuilder و MetaUML. وتوفر بعض الأدوات العامة، مثل - Microsoft Visio - دعماً للمخططات UML ولكنه يبقى محدوداً مقارنة بالأدوات المتخصصة. وثمة أدوات متكاملة متخصصة عالية الكفاءة، مثل Enterprise Architect و Visual Paradigm و Rational Software Architect، وهي أدوات تجارية ولكن يصدر بعضها نسخاً تجريبية في مدة زمنية محددة أو نسخاً مجانية بإمكانات محدودة نسبياً. وتجدر الإشارة هنا إلى أن الشركة IBM ابتاعت شركة راشيونال عام 2003 وجعلتها قسماً خاصاً ضمنها. وتمنح الشركة IBM شهادة خاصة بإجرائية راشيونال الموحدة RUP، وصدرت نسخة حديثة من هذه الشهادة عام 2007 تحت اسم IBM Certified Solution Designer - Rational Unified Process 7.0، ويتطلب الحصول عليها اجتياز اختبار خاص عن محتوى إجرائية RUP وعناصر بنية هذه الإجرائية.