ترتيب وقائع الاستخدام
لدينا الكثير من العمل
أمامنا – كيف يمكننا تقسيم العمل لتكرارات iterations بسيطة و سهلة القياد حسب ما وصفناها في بدايات هذه الدروس؟
الإجابة هي بالتركيز على
وقائع الاستخدام لدينا. في كل تكرار=معاودة، نقوم بتصميم و توليف و اختبار القليل
فقط من وقائع الاستخدام. إذا و بصورة فعالة، نحن قد قمنا فعلا بتحديد كيفية تقسيم
العمل إلى تكرارات أو معاودات – الشيء الوحيد الذي لم نقم به هو تحديد ما هو
الترتيب الذي به نتصدى لهذه الوقائع.
لتخطيط هذا الترتيب، نقوم
بإعطاء كل واقعة استخدام رتبة rank. الرتبة هي ببساطة رقم يشير إلى التكرار الذي
سيتم فيه تطوير واقعة الاستخدام. أية أداة Case (التصميم بمساندة الحاسوب) جيدة سوف تتيح رصد الرتب كجزء من
النموذج.
لا توجد قواعد ثابتة و
سريعة لكيفية تخصيص الرتب. الخبرة و المعرفة في مجال تنشئة البرمجيات تلعب دورا
كبيرا في تحديد هذه الرتب. هذه بعض الإرشادات عن أي من وقائع الاستخدام يجب
إعطاؤها رتبة أعلى ( بمعنى، أن يتم تطويرها مبكرا):
·
وقائع
الاستخدام ذات المخاطرة العالية
·
وقائع
الاستخدام التي تعد أساسية للمعمار
·
وقائع
الاستخدام التي تتضمن مساحات واسعة من وظائفية النظام
·
وقائع الاستخدام التي
تتطلب بحثا مكثفا، أو تقنية جديدة
·
"المكاسب السريعة"
·
ذات
العائد الكبير للمستخدم
بعض وقائع الاستخدام تحتاج
في سبيل تطويرها إلى عدة تكرارات. قد يكون السبب في هذا كبر حجم واقعة الاستخدام
عند التصميم و التوليف والاختبار فلا يسعها تكرار واحد. أو بسبب أن واقعة
الاستخدام تعتمد على استكمال مجموعة وقائع استخدام أخرى ("بدء التشغيل"
مثال تقليدي على ذلك).
يفترض في هذا أن لا يسبب
مشاكل – ببساطة يتم تقسيم واقعة الاستخدام إلى بضعة نسخ. مثلا، لدينا واقعة
الاستخدام الضخمة التالية، و التي سيتم تطويرها عبر ثلاثة تكرارات. في نهاية كل
تكرار، لا تزال واقعة الاستخدام تؤدي مهمة
مفيدة، و لكن بدرجة محدودة.
واقعة استخدام "إطلاق
طوربيد":
·
نسخة
1أ السماح للمستخدم بتحديد الهدف (رتبة : 2)
·
نسخة
1ب السماح للمستخدم بتجهيز السلاح (رتبة : 3)
·
نسخة
1ج السماح للمستخدم بإطلاق السلاح (رتبة : 5)
ملخص
وقائع الاستخدام تسمح لنا
بجدولة عملنا عبر تكرارات متعددة.
نعطي رتبة لكل وقائع
الاستخدام لتحديد أولوياتها في التصدي لها.
ترتيب وقائع الاستخدام
مبنية على معرفتنا وخبرتنا الخاصة.
بعض الإرشادات المجربة سوف
تساعد في الأيام الأولى.
بعض وقائع الاستخدام سوف
تمتد لأكثر من تكرار.
طور البناء
في هذا الفصل القصير، سوف
نراجع ما قمنا بعمله، و ما المطلوب فعله لاحقا.
في طور التفصيل Elaboration Phase ، احتجنا لفهم المسألة بأوسع قدر ممكن، من
غير الدخول في تفاصيل كثيرة. قمنا ببناء نموذج وقائع استخدام Use Case Model، و أنشأنا أكثر ما يمكن من وقائع استخدام.
لم نقم بملء كامل تفاصيل وقائع الاستخدام، بل قدمنا وصفا موجزا لكل واقعة.
الخطوة التالية كانت بناء
النموذج المفاهيمي conceptual model، حيث قمنا برصد المفاهيم التي ستحكم عملنا في التطوير. هذا
النموذج المفاهيمي سيقدم لنا الأساسات التي سيرتكز عليها التصميم.
بعد ذلك قمنا بإعطاء رتبة
لكل واقعة استخدام، وخلال ذلك، وضعنا مخططا لأولويات ترتيب تطوير واقعة الاستخدام.
بهذا يكتمل طور التفصيل. من
المفترض إجراء مراجعة شاملة لهذا الطور، واتخاذ قرار بشأن ما إذا سيتم الاستمرار
في المشروع أم لا. فبعد كل هذا قد نكتشف خلال طور التفصيل أننا لا نستطيع في
الواقع تقديم حل مناسب لزبوننا – من الأفضل أن نكتشف ذلك الآن من أن نكتشفه في
نهاية التوليف!
البناء
الآن و نحن في طور البناء،
نحتاج لبناء المنتوج، و أخذ النظام لمرحلة يمكن فيها توريده لبيئة الزبون.
لنتذكر أن خطتنا العامة
للتصدي للعمل هو أن نتبع سلسلة من التدفقات=الشلالات القصيرة waterfalls ، مع عدد صغير من وقائع الاستخدام يتم
تطويرها في كل تكرار. في نهاية كل تكرار، سوف نراجع تقدم العمل، و يفضل تحديد الإطار
الزمني للتكرار.
في الحالة المثلى، سنطمح
لانجاز منظومة تعمل (ولو، طبعا، بصورة محدودة) مع نهاية كل تكرار.
كل مرحلة من التدفق ستنتج
مجموعة من الوثائق أو بعبارة أخرى نماذج UML.
·
عند
التحليل، سنقوم بإعداد بعض وقائع الاستخدام بأكثر توسع (أو كاملة)
·
عند
التصميم، سنقوم بإعداد مخططات الصنفيات Class
Diagrams ، و نماذج التفاعل Interaction Models ، و مخططات الحالة State Diagrams
·
عند
التوليف Code ، سنقوم بإنتاج توليف يعمل و قد تم اختبار وحداته
ثم يتم اختبار التكرار (كل
وقائع الاستخدام يجب أن تكون شغالة بطريقة يمكن استعراضها)، بعد ذلك نصل إلى
المراجعة.
ملخص
قمنا باستكمال التفصيل Elaboration ، و الآن نحن جاهزين لبدء البناء. سوف ننظر
في كل نموذج على حدة ونرى كيف يفيدنا في عمليات البناء.
الفصل 11: طور البناء: التحليل
المرحلة الأولى في طور
البناء هو التحليل. سنحتاج إلى زيارة ثانية لوقائع الاستخدام التي سنبنيها في هذا
التكرار، و نقوم بتحسين و توسيع هذه الوقائع. إننا بالتركيز على التفاصيل الكاملة
لعدد صغير فقط من وقائع الاستخدام للتكرار الواحد، سنقلص من مقدار التعقيد الذي
علينا مناولته في وقت واحد.
شكل 41: مرحة التحليل عند البناء
لنتذكر، رغم إننا في طور
البناء، فنحن لا زلنا في مرحلة التحليل – ولو أن هذه المرة بتحليل أكثر تفصيلا من
ذلك التحليل التي قمنا به في طور التفصيل. لذلك، يجب أن نأخذ في اعتبارنا أننا فقط
مهتمون بالمشكلة أو المسألة، و ليس بالحل. إذن نحن ننظر في ما يجب أن يقوم به
النظام، دون القلق بشأن كيف سيقوم به.
عودة لوقائع الاستخدام
خلال التفصيل Elaboration ، قمنا بإنتاج وقائع استخدام قصيرة و قررنا
تأجيل الخوض في التفاصيل (مثل التدفق الأساسي، التدفق البديل، الشروط المسبقة و
اللاحقة) حتى يأتي دور طور البناء. الآن حان الوقت لاستكمال كافة التفاصيل (لكن
فقط لوقائع الاستخدام التي سنتعامل معها في هذا التكرار).
واقعة الاستخدام:
|
وضع الرهان
|
وصف موجز:
|
يقوم المستخدم بالمراهنة على فرس معين بعد اختيار
السباق
|
اللاعبون:
|
المراهن
|
المتطلبات:
|
R2.3; R7.1
|
شروط مسبقة:
|
|
شروط لاحقة:
|
|
التدفق الرئيسي:
|
|
تدفقات بديلة:
|
|
تدفقات استثنائية:
|
شكل 42: واقعة استخدام موجزة، وضع الرهان
الشكل أعلاه هو مثال لواقعة
استخدام موجزة، و كل قسم معنون فيها يجب تعبئته. أفضل وسيلة لتوضيح عملية تعبئتها
هو استخدام مثال محدد، لذا دعونا ننظر في واقعة استخدام وضع رهان:
شروط مسبقة
يصف هذا القسم شروط النظام
التي يجب استيفاؤها قبل أن تأخذ واقعة الاستخدام مكانها في الواقع. في مثال وضع
رهان، قد يكون جيدا تحديد الشرط المسبق التالي:
"المستخدم
قد قام بتسجيل نفسه بنجاح".
واضح، أن نظام المراهنة يجب
أن يتحقق من صلاحية الزبائن قبل أن يباشروا عملية المراهنة. عموما، عملية التحقق
من المستخدم ليست جزءا من واقعة الاستخدام، لذلك يجب أن نضمن بأن الشرط قد تم
تحقيقه قبل أن تبدأ عملية المراهنة.
شروط لاحقة
تصف الشروط اللاحقة الحالة
التي يكون عليها النظام بعد انتهاء واقعة الاستخدام. جرى العرف أن يتم كتابة الشرط
اللاحق بصيغة الماضي. على ذلك في مثالنا لوضع الرهان، سيكون الشرط اللاحق كالتالي:
"المستخدم
وضع رهانه، و تم تسجيل الرهان من قبل النظام"
قد يوجد أكثر من شرط لاحق،
بحسب مخرجات واقعة الاستخدام. هذه الشروط اللاحقة المختلفة يتم وصفها باستخدام لغة
"إذا كان- إذاً"“if then” . مثال:
"إذا كان المستخدم
جديدا، إذاً، يتم إنشاء حساب للمستخدم".
"إذا كان المستخدم مسجلا، إذاً، يتم تحديث بيانات المستخدم".
"إذا كان المستخدم مسجلا، إذاً، يتم تحديث بيانات المستخدم".
التدفق الرئيسي
يصف قسم التدفق الرئيسي
مجريات الأحداث المنتظر أو الغالب وقوعها أثناء واقعة الاستخدام. ومن المتوقع،
في واقعة استخدام "وضع الرهان"،
أن تجري بعض الأمور بطريقة خاطئة. ربما يقوم المستخدم بإلغاء الحركة. قد لا يملك
المستخدم الرصيد الكافي لوضع الرهان. كل هذه الأحداث يجب أخذها في الاعتبار، لكن
في الغالب، التدفق الأكثر احتمالا خلال واقعة الاستخدام هذه هي أن المستخدم سيضع
رهانه بنجاح.
في التدفق الرئيسي، يجب
تفصيل التفاعلات بين اللاعب و النظام. فيما يلي التدفق الرئيسي لواقعة "وضع
رهان":
(1) عند استهلال وضع الرهان
من قبل المراهن، يتم طلب قائمة بسباقات اليوم من النظام، و (2) عرضها على الشاشة
(3) يختار المراهن السباق
الذي سيراهن عليه [A1] ،
و (4) يظهر النظام قائمة بالمتسابقين في
هذا السباق
(5) يختار المراهن الفرس
المتسابق ليراهن عليه [A1] و يدخل مبلغ الرهان [E1]
(6) يقوم المستخدم=المراهن
بتأكيد العملية و (7) و يعرض النظام رسالة تأكيد
لاحظ
أن كل تفاعل بين اللاعب و النظام قد تم تجزئته إلى خطوات. في هذه الحالة، يوجد لدينا
سبع خطوات في التدفق الرئيسي لواقعة الاستخدام. العلامات[A1] و [E1]سيتم
توضيحها بعد قليل، عند النظر إلى التدفقات البديلة و التدفقات الاستثنائية.
التدفقات البديلة
التدفقات البديلة Alternate flows أو المجريات البديلة هي التدفقات الأقل حدوثا (لكن
محتملة) خلال واقعة الاستخدام. التدفق البديل عادة ما يتشارك في الكثير من خطواته
مع التدفق الرئيسي، لذلك يمكننا التنويه للنقطة التي منها ينطلق التدفق البديل. لقد
قمنا بذلك في الخطوة (3) من التدفق الرئيسي أعلاه، من خلال التنويه[A1]. هذا بسبب أن المستخدم عند اختياره للسباق الذي سيراهن عليه، قد
يقوم بإلغاء العملية. يمكنه أيضا إلغاء العملية عند الخطوة 5، عندما يكون عليه
إدخال قيمة مبلغ الرهان.
" يقوم المستخدم
بإلغاء العملية
شرط لاحق -< لا يتم وضع أي رهان"
في هذه الحالة، نتج عن
التدفق البديل تغيير في الشرط اللاحق – لا يتم وضع أي رهان.
التدفقات الاستثنائية
أخيرا، الحالات الاستثنائية
يتم وصفها في التدفقات الاستثنائية. بعبارة أخرى، التدفق الذي يجب أن يتم عندما
يحدث خطأ، أو عند وقوع حدث لا يمكن بطريقة أخرى التنبؤ به.
في مثال "وضع
رهان"، قد يكون لدينا الاستثناء التالي:
"(E1) رصيد
المستخدم لا يكفي لتغطية الرهان. يتم تنبيه المستخدم و تنتهي واقعة الاستخدام"
عندما ننتقل إلى برمجة
التوليف. يجب مقاربة البنود التي تحت التدفق الاستثنائي مع الاستثناءات في
البرنامج – إذا كانت اللغة المستخدمة تدعم الاستثناءات exceptions، العديد من اللغات الحديثة تدعمها – مثل جافا و سي++ و
دلفي و آدا.
واقعة
الاستخدام بعد اكتمالها
واقعة الاستخدام:
|
وضع الرهان
|
وصف موجز:
|
يقوم المستخدم بالمراهنة على فرس معين بعد اختيار
السباق
|
اللاعبون:
|
المراهن
|
المتطلبات:
|
R2.3; R7.1
|
شروط مسبقة:
|
قام المستخدم بتسجيل
الدخول بنجاح
|
شروط لاحقة:
|
تم وضع الرهان و تسجيله
من قبل النظام
|
التدفق الرئيسي:
|
(1) عند استهلال وضع
الرهان من قبل المراهن، يتم طلب قائمة بسباقات اليوم من النظام، و (2) عرضها على
الشاشة
(3) يختار المراهن السباق
الذي سيراهن عليه [A1] و (4) يظهر النظام قائمة
بالمتسابقين في هذا السباق
(5) يختار المراهن الفرس
المتسابق ليراهن عليه [A1] و
يدخل مبلغ الرهان [E1]
(6) يقوم
المستخدم=المراهن بتأكيد العملية و (7) و يعرض النظام رسالة تأكيد
|
تدفقات بديلة:
|
(A1)
يقوم المستخدم بإلغاء العملية.
شروط لاحقة -> لا يتم
وضع أي رهان
|
تدفقات استثنائية:
|
(E1) رصيد المستخدم لا يكفي لتغطية الرهان. يتم تنبيه المستخدم و
تنتهي واقعة الاستخدام
|
شكل 43: وصف لواقعة استخدام كاملة
قد يعجبك ايضا