حالة الاستخدام (هندسة البرمجيات)

في 1986 ايفار جاكبسون، لاحقا مساهما هاما في كل من لغة موحدة للنمذجة والعملية الموحدة لراشيونال IBM، أول من وضع تقنيات النمذجة النصية والهيكلية والبصرية لتحديد حالات الاستخدام. أصبحت تقنية حالات الاستخدام شعبية من خلال كتاب جاكبسون 1992 لهندسة البرمجيات الموجهة – حالة الاستخدام مدفوعة النهج، الذي شارك في تأليفه مانجوس كريسترسون، باتريك جونسون وجانر أوفرجارد. وقد استخدم أصلا مصطلحات سيناريوهات الاستخدام وحالة الاستخدام والتي كانت أصح ترجمة للكلمة السويدية "användningsfall" التي استخدمها ولكنه وجد أن أيا من المصطلحين بدت ط بيعية في اللغة الإنجليزية وأخيرا استقر على استخدام مصطلح حالة الاستخدام.[3] منذ إنشاء جاكبسون لتقنية حالة الاستخدام، ساهم الآخرون في تحسين تلك التقنية بما في ذلك كيرت بيتنر، أيان سبنس، أليستار كوكبيرن، جانر أوفرجارد، كارين بالمكفيست، باتريك جونسون، مانجوس كريسترسون وجيري سكيندر. أثناء التسعينات، أصبحت حالات الاستخدام واحدة من الممارسات الأكثر شيوعا لالتقاط المتطلبات الوظيفية.هذا هو الحال خاصة داخل المجتمع الموجه حيث نشأت ولكن لا يقتصر تطبيقها على الأنظمة الموجهة. مادة أخرى

ان الطريقة المحددة لاستخدام حالات الاستخدام في اطار عملية التطوير سيعتمد على أي من منهجيات التطوير سيتم استخدامها. في منهجيات تطوير محددة، فان بحثا قصيرا في حالة الاستخدام هو كل المطلوب. في منهجيات تطوير أخرى، تتطور حالات الاستخدام في التعقيد والتغيير في الطبيعة حسبما تتقدم عملية التطوير.يمكن أن تكون حالات الاستخدام مصدرا قيما لاستخدام المعلومات وأفكار اختبار الاستخدام.[4] في بعض المنهجيات يمكن أن تبدأ بعمل حالات استخدام موجزة وتتطور إلى نظم حالات استخدام أكثر تفصيلا ومن ثم في نهاية المطاف تتطور إلى حالات اختبار مفصلة للغاية وشاملة.

كل حالة استخدام تركزعلى وصف كيفية تحقيق هدف أو مهمة. بالنسبة إلى معظم مشاريع البرمجيات فذلك يعني أن هناك حاجة إلى الكثير من وربما العشرات من حالات الاستخدام لتحديد هدف النظام الجديد. الدرجة الشكلية لمشاريع برامج معينة ومرحلة المشروع ستؤثر على مستوى التفاصيل المطلوبة في كل حالة استخدام.^{[اقتباس من غير مصدر]} لا ينبغي أن تختلط حالات الاستخدام بملامح النظام. إن واحدا أو أكثر من الملامح (تعرف أيضا باسم «متطلبات النظام») التي تصف الوظيفة اللازمة لتلبية طلب أصحاب الشأن أو حاجة المستخدم (يعرف أيضا باسم«متطلب المستخدم») ويمكن تحليل كل ملمح إلى واحد أو أكثر من حالات الاستخدام التي تفصل الحالات حيث يستخدم الممثل النظام.كل حالة استخدام يجب أن ترد إلى سمتها الأصلية والتي بدورها ينبغي أن ترد إلى أصل طلب صاحب المصلحة/المستخدم.

تعامل حالات الاستخدام النظام ك صندوق أسود والتعامل مع النظام بما في ذلك استجابات النظام ينظر إليها على أنها من خارج النظام. هذه سياسة متعمدة لأنها تدفع المؤلف للتركيز على ما يجب أن يقوم به النظام لا كيفية القيام به والابتعاد عن وضع افتراضات حول الكيفية التي سيتم بها انجاز الوظيفة.

حالة الاستخدام يجب أن:

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

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

اليستر كوكبيرن في كتابة حالات الاستخدام المؤثرة حدد ثلاث مستويات للتفصيل في كتابة حالات الاستخدام:[5]

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

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

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

العملية الموحدة لراشيونال IBM تدعو المطورين إلى كتابة وصفا موجزا لحالة الاستخدام في حالة استخدام الرسم التخطيطي مع وصف عادي كتعليقات ووصف مفصل لتدفق الاحداث في تحليل نصي.ويمكن عادة أن يكون كل هؤلاء مدخلا في أداة حالة الاستخدام (مثل UML Tool, SysML Tool)، أو يمكن كتابتهم منفصلة في محرر النص.

تحدد حالة الاستخدام التفاعل بين الفاعلين الخارجيين والنظام قيد النظر لانجاز هدف ما.يحدد الفاعل الدور الذي يقوم به شخص أو شيء عندما يتفاعل مع النظام.[6] يمكن تمثيل نفس الشخص الذي يستعمل النظام كمثليين مختلفين لأنهم يلعبون أدوارا مختلفة. على سبيل المثال المستخدم «جو» يمكن أن يلعب دور العميل عندما يستخدم جهاز الصراف الآلي لسحب النقود أويلعب دور صراف البنك عندما يستخدم النظام لإعادة درج النقدية.

أنواع الممثلين [7]

• الممثل الابتدائي- يفي بأهداف المستخدم باستخدام خدمات SuD (نظام قيد المناقشة) مثل «الصراف» في نظام عملية البيع.
• الممثل الثانوي- يقدم خدمة SuD مثل خدمة الإذن بالدفع الآلي.
• ممثل خارج المسرح- له مصلحة في سلوك النظام ولكنه ليس ابتدائيا ولا ثانويا مثل

يمكن وصف حالة الاستخدام على المستوى التجريدي (حالة استخدام العمل وتسمى أيضا ضرورة حالة الاستخدام)أو على مستوى النظام (نظام حالة الاستخدام) والاختلاف بين هذين هو المجال.

• حالة استخدام العمل : توصف في المصطلحات التكنولوجية الحرة التي تعامل النظام كصندوق أسود وتصف عملية إجراء الأعمال التي تستخدم من قبل ممثليها (الناس أو النظم الخارجة عن العملية) لانجاز أهدافهم (مثل دليل عمليات الدفع وتكاليف تقرير الموافقة وإدارة الشركات العقارية. ان حالة استخدام العمل ستصف العملية التي تعطي القيمة لممثل العمل وتصف ما تقوم به العملية.

عملية التعيين للعمل هي طريقة أخرى لمستوى وصف العمل هذا.

• وهناك نظام حالة استخدام يصف النظام الذي يجعل حالة استخدام العمل أو العملية أوتوماتيكية.وتوصف عادة على مستوى وظيفة النظام (مثل إنشاء قسيمة) وتحدد الوظيفة أو الخدمة التي يقدمها النظام للممثل. تفصل حالة استخدام النظام ما سيفعله النظام استجابة لاجراء الممثل. لهذا السبب فانه ينصح بأن يبدأ تحديد حالة استخدام النظام بالفعل (مثل قم بإنشاء قسيمة، اختر المدفوعات، استبعد السداد وألغ الإيصال). يمكن أن يكون الفاعل إنسان مستخدم أو نظام/ فرع من النظام يتفاعل مع النظام قيد التعريف.

في لغة موحدة للنمذجة (UML)، العلاقة بين كل (أو مجموعة من) حالات الاستخدام والممثلين يمكن تمثيلها بالرسم أو الرسوم البيانية وتعتمد أصلا على منهجية تدوين ايفار جاكبسون SysML. UML profile يستخدم نفس التدوين في مستوى نظام الكتلة.

حالات الاستخدام لها قيود:

• تدفق حالات الاستخدام لا يناسب تماما لالتقاط المتطلبات غير تفاعلية التي تعتمد على نظام (مثل الخوارزمية أو المتطلبات الرياضية) أو المتطلبات غير الوظيفية (مثل البرنامج والأداء والتوقيت أو جوانب الأمان الحرج). من الأفضل توضيح هؤلاء في مكان آخر.
• جوانب حالة الاستخدام لا تضمن تلقائيا الوضوح. الوضوح يعتمد على مهارة الكاتب (الكتاب).
• منحنى التعلم متضمن في تفسير حالات الاستخدام بشكل صحيح بالنسبة للمستخدمين والمطورين على حد سواء، حيث لم تعد هناك تعريفات موحدة تماما لحالات الاستخدام، كل مجموعة يجب أن تطور تدريجيا تفسيرها الخاص. بعض العلاقات مثل يشمل غامضة في تفسيرها ويمكن أن تكون صعبة الفهم على أصحاب المصلحة.
• يعتبر أنصار البرمجة المتطرفة حالات الاستخدام محور وثيقة عديم الفائدة مفضلين استخدام دراسة أبسط لقصة المستخدم.
• مطورو حالة الاستخدام غالبا ما يجدوا صعوبة في تحديد مستوى اعتماد واجهة المستخدم (UI) لإدراجها في حالات الاستخدام. في حين أن نظرية الاستخدام تشير إلى أن (UI) لا تنعكس في حالات الاستخدام. فانه يمكن أن يكون من الصعب تجريد هذا المجال من التصميم حيث تجعل تصور حالات الاستخدام صعبا. في هندسة البرمجيات تحل هذه الصعوبة بتطبيق متطلبات التتبع عن طريق استخدام مصفوفة متابعة.
• يمكن أن تكون حالات الاستخدام مبالغ في تأكيدها. في برامج البناء الموجه (الطبعة الثانية)، برتراند ماير يناقش قضايا مثل قيادة نظام التصميم حرفيا بصورة شديدة من حالات الاستخدام واستخدام حالات الاستخدام لاستبعاد تقنيات تحليل المتطلبات الأخرى المحتملة.
• لاقت حالات الاستخدام بعض الاهتمام كنقطة انطلاق لاختبار التصميم.[8] بعض مؤلفات حالات الاستخدام تنص على أن شروط قبل وبعد حالات الاستخدام يجب أن تطبق على جميع سيناريوهات حالة الاستخدام (أي على جميع السبل الممكنة لاستخدام حالات الاستخدام) الذي يحد من وجهة نظر اختبار التصميم. إذا كانت الشروط المؤخرة لحالات الاستخدام عامة بحيث تكون صالحة لجميع سيناريوهات حالات الاستخدام الممكنة فمن المرجح ألا تكون مفيدة كأساس لتحديد السلوك المتوقع في اختبار التصميم.على سبيل المثال النواتج والحالة النهائية لمحاولة فاشلة لسحب النقود من أجهزة الصراف الآلي ليست كمحاولة سحب ناجحة، إذا عكست الظروف المؤخرة ذلك سيختلف الاثنين تماما، لو لم تعكس الظروف المؤخرة ذلك فلا يمكن استخدامها بعد ذلك لتحديد السلوك المتوقع للاختبارات.وجهة نظر بديلة في شروط قبل وبعد حالة الاستخدام أنها أكثر ملاءمة لاختبار التصميم الذي يعتمد على نموذج تحديد تتم مناقشتها.[9]
• توصف بعض الأنظمة أفضل في دراسة تعتمد على المعلومات/البيانات من الدراسة التي تعتمد على الوظائف في حالة الاستخدام.وخير مثال على هذا النوع من النظم هو نظم استخراج البيانات المستخدمة في ذكاء الأعمال.إذا كنت ستصف هذا النوع من الأنظمة فإنه سيكون صغيرا جدا ورتيبا (لا توجد وظائف مختلفة هنا) ولكن مجموعة البيانات التي يعالجها النظام قد تكون مع ذلك كيرة وغنية بالتفاصيل.

• Jacobson I., Christerson M., Jonsson P., Övergaard G., Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley, 1992.
• Alexander I., Maiden N. Scenarios, Stories, Use Cases. Wiley 2004. ISBN 0-470-86194-0.
• Aurum A. Cox, K. and Jeffery. An experiment in inspecting the quality of usecase descriptions. Journal of Research and Practice in Information Technology, 36(4):211–229, 2004.
• Phalp K. Cox, K. and M. Shepperd. Comparing use-case writing guidelines. roc. Workshop on Requirements Engineering: Foundation of Software Quality (REFSQ’01), pages 101–112, 2001.
• Colom J.M. Ezpeleta, J. and J. Martinez. Comparing use-case writing guidelines. A Petri net based deadlock prevention policy for flexible manufacturing systems, 11(2):173–184, 1995.
• E. B. Fernandez and J. C. Hawkins. Determining role rights from use cases. In RBAC ’97: Proceedings of the second ACM workshop on Role-based access control, pages 121–125, New York, NY, USA, 1997. ACM Press.
• R. Hurlbut. A survey of approaches for describing and formalizing use-cases. Technical Report 97– 03, Department of Computer Science, Illinois Institute of Technology, USA., 1997.
• Woo Jin Lee, Sung Deok Cha, and Yong Rae Kwon. Integration and analysis of use cases using modular petri nets in requirements engineering. IEEE Trans. Softw. Eng., 24(12):1115–1130, 1998.
• F. Torner, M. Ivarsson, F. Pettersson, and P. Ohman. Defects in automotive use cases. In ISESE ’06: Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering, pages 115–123, New York, NY, USA, 2006. ACM Presss.

• Use Cases (Usability.gov)
• Basic Use Case Template by Alistair Cockburn
• "An Academic Survey on the Role of Use Cases in the UML"

• بوابة علم الحاسوب
• بوابة تقانة المعلومات
• بوابة عقد 1980
• بوابة برمجة الحاسوب