نمذجة وقائع الاستخدام
واقعة الاستخدام هي من أدوات UML القوية، هي ببساطة وصف لمجموعة من التفاعلات بين المستخدم و
النظام. و من خلال بناء مجموعة من وقائع الاستخدام، يمكننا وصف كامل النظام الذي
نخطط لإنشائه، بصورة واضحة و موجزة.
عادة ما يتم وصف وقائع الاستخدام باستعمال توليفات
من (الفعل / الاسم) - على سبيل المثال: "دفع الفواتير" ، "تحديث
المرتبات" أو "إنشاء حساب".
مثلا، إذا كنا نكتب برنامجا لنظام التحكم بالصواريخ،
فإن وقائع الاستخدام المعتادة قد تكون: "إطلاق الصاروخ"، أو "بدء
العدّ التنازلي".
بجانب الاسم الذي سنعطيه لواقعة الاستخدام، سوف نقدم
شرحا نصيا كاملا للتفاعلات التي ستنشأ بين المستخدم و النظام. هذه الشروح النصية
سوف تنتهي في الغالب لتكون أكثر تعقيدا، لكن UML
تقدم لنا ترميزا بسيطا و مدهشا لتمثيل واقعة الاستخدام، كالتالي:
شكل 23: ترميز لواقعة استخدام
اللاعب Actor
واقعة الاستخدام لا يمكنها بدء الأحداث أو التفاعلات
من تلقاء نفسها. اللاعب هو شخص ما الذي يمكنه بدء أو تفعيل واقعة
الاستخدام. مثلا، إذا كنا نقوم بتطوير نظام مصرفي، و كان لدينا واقعة استخدام تسمى
"سحب النقود"، فيمكننا الإقرار بأننا نحتاج لزبائن للتمكن من سحب
هذه النقود، على ذلك سيكون الزبون أحد اللاعبين لدينا. مرة أخرى، الترميز
لهذا اللاعب سيكون بسيطا:
شكل 24: ترميز اللاعب في UML
لو تعمقنا أكثر، فإن اللاعبين يمكن أن يكونوا أكثر
من مجرد أناس. اللاعب قد يكون أي شيء خارج النظام يقوم بتفعيل واقعة الاستخدام،
مثل جهاز حاسوب آخر. أكثر من ذلك قد يكون اللاعب مفهوما أكثر تجريدا مثل الوقت،
أو تاريخا معينا. مثلا، قد يكون لدينا واقعة استخدام اسمها "حذف
الطلبيات القديمة" في منظومة لمناولة الطلبيات، و اللاعب الذي سيقوم بتفعيل
هذه الواقعة قد يكون تاريخ "آخر يوم عمل". كما لاحظنا، اللاعبون مرتبطون
بوقائع الاستخدام، حيث أن اللاعب هو الذي سيقوم بتفعيل أو بدء واقعة استخدام
معينة. يمكننا تمثيل ذلك عل مخطط واقعة استخدام من خلال وصل اللاعب بواقعة الاستخدام:
شكل 25:علاقة لاعب بواقعة استخدام
من الواضح أنه بالنسبة لمعظم الأنظمة، يمكن للاعب
الواحد التفاعل مع مجموعة من وقائع الاستخدام، كما أن واقعة الاستخدام الواحدة
يمكن تفعيلها من قبل أكثر من لاعب مختلف. هذا يقودنا إلى مخطط واقعة استخدام
متكامل، كما هو في المثال التالي:
شكل 26: نظام كامل تم وصفه باستخدام اللاعبين و
وقائع الاستخدام
الغرض من وقائع الاستخدام
إن بساطة تعريف "واقعة الاستخدام" و
"اللاعب"، مع بساطة تخيّل وقائع الاستخدام من خلال نموذج UML، سوف تجعلنا معذورين إذا اعتقدنا أن وقائع الاستخدام أمرها هيّن و
سهل، و أنها أبسط من أن نقلق بشأنها. هذا خطأ. إن وقائع الاستخدام قوية بصورة
كبيرة.
·
وقائع الاستخدام تحدد النطاق العام للنظام. إنها
تمكننا من تصوّر حجم و نطاق عملية التطوير بالكامل.
·
وقائع الاستخدام شبيهة
جدا بالمتطلبات، و لكن بينما المتطلبات تميل لأن تكون مبهمة و مربكة و ملتبسة و
مكتوبة بشكل سيء، نجد أن البناء المحكم لوقائع الاستخدام يجعلها أكثر تركيزا.
·
مجموع وقائع الاستخدام
تشكل النظام بالكامل. مما يعني أن أي شيء لم يتم تغطيته في وقائع الاستخدام هو
خارج حدود النظام المراد تطويره. لذا فإن مخطط وقائع الاستخدام متكامل بدون فجوات.
·
إنها تمكن من التواصل
بين العملاء و المطورين (ما دام المخطط بهذه السهولة، فالكل يستطيع فهمه).
·
وقائع الاستخدام ترشد
فرق التطوير خلال عمليات البناء التطوير- سوف نرى أن وقائع الاستخدام بمثابة
العمود الفقري لعمليات التطوير، و ستكون المرجع لنا في كل ما نصنعه.
·
سوف نرى كيف أن وقائع
الاستخدام تقدم منهجية لتخطيط عملنا في التطوير ، و تسمح لنا بتقدير الوقت اللازم
لانجاز العمل.
·
وقائع الاستخدام تقدم
الأساس لبناء اختبارات النظام .
·
أخيرا، فإن وقائع
الاستخدام تساعد في إعداد أدلة التشغيل!
غالبا ما تصدر ادعاءات بأن وقائع الاستخدام هي
ببساطة أسلوب للتعبير عن متطلبات النظام. واضح أن كل من يقول بهذا قد غاب عنه
الغاية من وقائع الاستخدام!
مدى كثافة واقعة الاستخدام
قد يكون من الصعب تقرير إلى
أي مدى يجب أن تكون عليه كثافة وقائع الاستخدام، مثلا، هل على كل تفاعل بين
النظام و المستخدم أن يكون واقعة استخدام، أو يجب على واقعة الاستخدام الواحدة أن
تحوي كل التفاعلات؟ مثلا، لنأخذ آلة صرف النقود الآليATM، نحتاج لبناء نظام ATM
يسمح للمستخدم أن يسحب النقود. ربما سيكون لدينا المجموعة التالية من التفاعلات
الشائعة في هذا التصور:
·
إدخال البطاقة
·
إدخال الرقم الخاص
·
اختيار المبلغ المطلوب
·
التأكيد على المبلغ
المطلوب
·
تنحية البطاقة
·
أخذ الواصل
هل يجب أن يكون لكل من هذه الخطوات واقعة استخدام
مثل "إدخال الرقم الخاص"؟
شكل 27: مخطط واقعة استخدام مفيد؟
هذا خطأ تقليدي عند بناء وقائع الاستخدام. هنا، قمنا
بتوليد عدد كبير من وقائع الاستخدام الصغيرة، و الغير مهمة في أغلبها. في أي نظام
لا يكون صغيرا، سوف نجد أنفسنا و قد تكوّن لدينا عددا ضخما من وقائع الاستخدام، و
سيكون التعقيد عندها جارفا. لمعالجة التعقيد حتى في الأنظمة الكبيرة جدا، نحتاج
لأن نبقي وقائع الاستخدام على "مستوى أعلى" ما أمكن. أفضل طريقة للتقرب
من واقعة الاستخدام هي أن نبقي القاعدة التالية محفورة في ذهننا:
واقعة الاستخدام يجب أن تحقق هدفا ينشده
اللاعب
بتطبيق هذه القاعدة البسيطة على مثالنا السابق، يمكن
أن نطرح سؤالا: "هل الحصول على الواصل" هو هدف الزبون؟ حسنا، ليس
تماما. سوف لن ينتهي العالم إذا لم يتم إصدار هذا الواصل.
بتطبيق القاعدة على وقائع الاستخدام الأخرى، سوف نجد
أنه في الحقيقة لا أحد منها تصف الهدف الذي ينشده المستخدم. هدف المستخدم هو سحب
النقود، وهذا ما يجب أن تكون عليه واقعة الاستخدام!
شكل 28: واقعة استخدام أكثر تركيزا
هذه المقاربة قد تكون مؤلمة في البداية، حيث أننا قد
تعودنا على "التفكيك الوظائفي"، حيث يتم تحليل و كسر المهام المعقدة و
تحويلها إلى مهام أصغر و أصغر. سوف نرى لاحقا أن وقائع الاستخدام يمكن تفكيكها،
لكننا الآن يجب أن نترك هذه الخطوة إلى الوقت الذي نبدأ فيه بعملية
البناء.
توصيفات وقائع الاستخدام
كل واقعة استخدام تحوي مجموعة كاملة من التفاصيل
النصية عن التفاعلات و التصورات التي تشملها الواقعة.
نلاحظ أنUML
لا تحدد ما يجب أن يكون عليه شكل أو محتويات هذه الوثيقة - هذا يرجع للمشروعات أو
الشركات لتحدده كيفما يناسبها.
بالنسبة لنا سوف تستعمل النموذج التالي:
واقعة الاستخدام
|
اسم واقعة الاستخدام
|
وصف مختصر
|
وصف موجز لواقعة الاستخدام
|
شروط سابقة
|
وصف للشروط التي يجب أن تتوفر قبل تفعيل
واقعة الاستخدام
|
شروط لاحقة
|
وصف لما سيحدث عند انتهاء واقعة الاستخدام
|
المجريات الأساسية
|
قائمة بتفاعلات النظام التي ستأخذ مكانها وفق
أكثر التصورات شيوعا. مثلا، بالنسبة لواقعة "سحب النقود"، ستكون
"إدخال البطاقة"، "إدخال الرقم الخاص"، و هكذا ..
|
مجريات بديلة
|
وصف للتفاعلات البديلة المحتملة.
|
مجريات استثنائية
|
و صف للتصورات المحتملة عندما تقع أحداث غير
متوقعة، أو لا يمكن التنبؤ بها.
|
شكل 29: نموذج لتوصيف واقعة استخدام
وقائع الاستخدام في طور التفصيل
واجبنا الأساسي في طور التفصيل هو تحديد أكبر عدد
ممكن من وقائع الاستخدام الممكنة. مع أخذنا في الاعتبار مبدأ: " عرض ميل و
عمق بوصة"، هدفنا هو تقديم ملامح عامة لأكبر عدد ممكن من وقائع الاستخدام - و
لكن بدون الحاجة لتقديم تفاصيل كاملة لكل واقعة استخدام. هذا سيساعدنا على تجنب
الحمل الثقيل للتعقيدات الزائدة.
في هذه المرحلة، سيكون كافيا، تقديم مخطط واقعة
استخدام (اللاعبون مع وقائع الاستخدام)، إضافة إلى وصف مختصر لكل واقعة استخدام. و
سيكون بمقدورنا مراجعة التفاصيل الدقيقة لوقائع الاستخدام أثناء طور البناء. حالما
ننتهي من تحديد وقائع الاستخدام، يمكننا ربطها بالمتطلبات للتأكد من أننا تتبعنا
كافة هذه المتطلبات.
في هذه المرحلة، إذا قمنا بتشخيص بعض وقائع
الاستخدام ذات المخاطرة العالية، فسيكون من المهم استكشاف تفاصيلها. إن إنتاج
نماذج أولية لها في هذه المرحلة سوف يساعد على تخفيف حدة المخاطر.
البحث عن وقائع الاستخدام
إحدى طرق العثور على وقائع الاستخدام هي من خلال
المقابلات التي يتم إجراؤها مع المستخدمين المحتملين للنظام. هذه مهمة صعبة، لأن
شخصين مختلفين سيعطيان في الأغلب صورتين مختلفتين بالكامل لما يجب أن يكون عليه
النظام (حتى لو كانا يعملان في نفس الشركة)!
بالتأكيد، إن معظم عمليات التطوير سوف تتضمن بدرجة
ما اتصالات مباشرة مع المستخدمين وجها لوجه. لكن حيث أنه من الصعب الحصول منهم على
رؤية موحدة لما يجب على النظام القيام به، فقد وجد أسلوب آخر أصبح أكثر شعبية وهو:
ورشة العمل.
ورش عمل التخطيط المشترك للمتطلبات (JRP)
Joint Requirements Planning
Workshops (JRP)
أسلوب ورشة العمل تجمع جماعة من الأفراد معا ممن لهم
اهتمام أو علاقة بالنظام الجاري تطويره و يسمون مجازا : (بحاملي الأسهم stakeholders) كل فرد في هذه الجماعة مدعو لإعطاء وجهة نظره في ما يجب على
النظام أن يقوم به.
مفتاح النجاح لورش
العمل هذه هم المنسقون. الذين يقودون الجماعة من خلال التأكد من أن النقاشات لا
تخرج عن الموضوع الأساسي، و أن كل المشاركين يتم تشجيعهم لطرح آرائهم ، و أن هذه
الآراء يتم رصدها بالكامل. المنسقون الجيدون لا يقدرون بثمن!
سيكون حاضرا أيضا في ورش العمل هذه مقرر الجلسات،
الذي يتولى مهمة توثيق كافة المناقشات. المقرر قد يقوم بعمله من خلال الورقة و
القلم ، لكن الأسلوب الأفضل هو أن يتم ربط إحدى أدوات CASE (هندسة البرمجيات بمساندة الحاسوب) أو برنامج رسم بآلة عرض و رسم
المخططات مباشرة.
بساطة مخطط وقائع الاستخدام أمر حيوي هنا- كل
المشاركين، حتى من لا دراية له بالحاسوب، يجب أن يكون قادرا على استيعاب مفهوم
المخطط بكل بسهولة.
الطريقة السهلة لتسيير ورش العمل هي:
1.
أن يتم أولا "عصف
ذهني"* لاستعراض كافة اللاعبين المحتملين
2.
بعدها، عصف ذهني آخر
لاستعراض كافة وقائع الاستخدام المحتملة
3.
حال الانتهاء من عملية العصف
الذهني وطرح الأفكار، من قبل المجموعة، يتم تبرير كل واقعة استخدام من خلال
صياغة وصف مبسط في سطر أو فقرة واحدة.
4.
وضعها في أنموذج.
الخطوات 1 و 2 يمكن عكسهما حسب الرغبة.
فيما يلي بعض النصائح النافعة حول ورشة العمل:
·
لا تجهد نفسك كثيرا في
محاولة إيجاد كل واقعة استخدام أو لاعب. إنه من الطبيعي نشوء
المزيد من وقائع الاستخدام لاحقا أثناء عملية التطوير.
·
إذا لم تستطع تبرير
واقعة استخدام في الخطوة 3، فهذا قد يعني أنها ليست واقعة استخدام. لا تتردد في إزالة
أية واقعة استخدام تشعر بأنها غير صحيحة أو مكررة (هذه الوقائع سوف تعود ثانية إذا
وجد حاجة إليها!)
النصائح أعلاه ليست ترخيصا لنكون متساهلين، لنتذكر
أن فائدة العمليات التكرارية iterative
هي أن كل شيء لا يشترط أن يكون صحيحا 100% في كل خطوة!
نصيحة حول العصف الذهني
العصف الذهني ليس أمرا سهلا كما يبدو؛ في الواقع من
النادر أن نجد عملية عصف ذهني تم إعدادها بطريقة جيدة. المفاتيح الأساسية التي
علينا تذكرها عند المشاركة في جلسة عصف ذهني هي:
·
توثيق كل الأفكار، لا
يهم مدى ما تبدو عليه من غرابة أو غباء، الأفكار الغبية قد تتحول إلى أفكار معقولة
جدا بعد فترة
·
أيضا، الأفكار السخيفة
قد تستدعي أفكارا منطقية في ذهن شخص آخر- هذا ما يسمى أفكار الوثب للأمام leapfrogging ideas
·
لا يتم أبدا تقييم أو
نقد الآراء. هذه قاعدة يصعب التقيّد بها - نحن نحاول كسر إحدى طبائع البشر هنا.
"مممم... لا، هذا لن يصلح ، لن نزعج أنفسنا بتوثيق ذلك!"
"مممم... لا، هذا لن يصلح ، لن نزعج أنفسنا بتوثيق ذلك!"
المنسق يجب أن يبقي عينيه على أصابع المشتركين و أن
يحرص على أن كل الآراء قد تم رصدها، و أن كل المجموعة قد قامت بالمشاركة.
في هذا السياق، سيتم القيام بورشة عمل وقائع
الاستخدام رفقة الزبون الذي سنتعامل معه.
ملخص
وقائع الاستخدام أسلوب فعال لنمذجة ما يحتاج النظام لعمله.
قد يعجبك ايضا