حالة الاستخدام (هندسة البرمجيات)
حالة الاستخدام (Use Case) في هندسة البرمجيات وهندسة أنظمة هي وصف لخطوات أو اجراءات بين المستخدم ونظام البرمجيات الذي يقود المستخدم إلى شيء مفيد. يمكن أن يكون المستخدم أو الممثل شخصاً أو شيئاً أكثر تجريداً مثل نظام برمجة خارجي أو عملية يدوية.
حالات الاستخدام هي تقنية لغة النمذجة التي تساعد مطوري البرمجيات على تحديد ملامح لتنفيذ وحل الأخطاء بأمان.
في هندسة النظم، تستخدم حالات الاستخدام على مستوى أعلى من هندسة البرمجيات وهو ما يمثل في كثير من الأحيان مهام أو أهداف أصحاب المصلحة. قد يتم إنجاز المتطلبات التفصيلية في مخططات SysML المطلوبة أو ما شابه.
في 1986 ايفار جاكبسون، لاحقا مساهما هاما في كل من لغة موحدة للنمذجة و العملية الموحدة لراشيونال IBM، أول من وضع تقنيات النمذجة النصية والهيكلية والبصرية لتحديد حالات الاستخدام. أصبحت تقنية حالات الاستخدام شعبية من خلال كتاب جاكبسون 1992 لهندسة البرمجيات الموجهة – حالة الاستخدام مدفوعة النهج، الذي شارك في تأليفه مانجوس كريسترسون، باتريك جونسون وجانر أوفرجارد. وقد استخدم أصلا مصطلحات سيناريوهات الاستخدام وحالة الاستخدام والتي كانت أصح ترجمة للكلمة السويدية "användningsfall" التي استخدمها ولكنه وجد أن أيا من المصطلحين بدت ط بيعية في اللغة الإنجليزية وأخيرا استقر على استخدام مصطلح حالة الاستخدام. منذ إنشاء جاكبسون لتقنية حالة الاستخدام، ساهم الآخرون في تحسين تلك التقنية بما في ذلك كيرت بيتنر، أيان سبنس، أليستار كوكبيرن، جانر أوفرجارد، كارين بالمكفيست، باتريك جونسون، مانجوس كريسترسون وجيري سكيندر.
أثناء التسعينات، أصبحت حالات الاستخدام واحدة من الممارسات الأكثر شيوعا لالتقاط المتطلبات الوظيفية.هذا هو الحال خاصة داخل المجتمع الموجه حيث نشأت ولكن لا يقتصر تطبيقها على الأنظمة الموجهة.
مادة أخرى
ان الطريقة المحددة لاستخدام حالات الاستخدام في اطار عملية التطوير سيعتمد على أي من منهجيات التطوير سيتم استخدامها. في منهجيات تطوير محددة، فان بحثا قصيرا في حالة الاستخدام هو كل المطلوب. في منهجيات تطوير أخرى, تتطور حالات الاستخدام في التعقيد والتغيير في الطبيعة حسبما تتقدم عملية التطوير.يمكن أن تكون حالات الاستخدام مصدرا قيما لاستخدام المعلومات وأفكار اختبار الاستخدام . في بعض المنهجيات يمكن أن تبدأ بعمل حالات استخدام موجزة وتتطور إلى نظم حالات استخدام أكثر تفصيلا ومن ثم في نهاية المطاف تتطور إلى حالات اختبار مفصلة للغاية وشاملة.
كل حالة استخدام تركزعلى وصف كيفية تحقيق هدف أو مهمة. بالنسبة إلى معظم مشاريع البرمجيات فذلك يعني أن هناك حاجة إلى الكثير من وربما العشرات من حالات الاستخدام لتحديد هدف النظام الجديد. الدرجة الشكلية لمشاريع برامج معينة ومرحلة المشروع ستؤثر على مستوى التفاصيل المطلوبة في كل حالة استخدام.
لا ينبغي أن تختلط حالات الاستخدام بملامح النظام. إن واحدا أو أكثر من الملامح (تعرف أيضا باسم "متطلبات النظام") التي تصف الوظيفة اللازمة لتلبية طلب أصحاب الشأن أو حاجة المستخدم(يعرف أيضا باسم"متطلب المستخدم") ويمكن تحليل كل ملمح إلى واحد أو أكثر من حالات الاستخدام التي تفصل الحالات حيث يستخدم الممثل النظام.كل حالة استخدام يجب أن ترد إلى سمتها الأصلية والتي بدورها ينبغي أن ترد إلى أصل طلب صاحب المصلحة/المستخدم.
تعامل حالات الاستخدام النظام ك صندوق أسود والتعامل مع النظام بما في ذلك استجابات النظام ينظر إليها على أنها من خارج النظام. هذه سياسة متعمدة لأنها تدفع المؤلف للتركيز على ما يجب أن يقوم به النظام لا كيفية القيام به والابتعاد عن وضع افتراضات حول الكيفية التي سيتم بها انجاز الوظيفة.
حالة الاستخدام يجب أن:
حالات الاستخدام هي في معظمها وثائق نصية ونمذجة حالة الاستخدام هي في المقام الأول فعل كتابة النص وليس رسم المخططات. الرسوم البيانية لحالة الاستخدام ثانوية في عمل حالة الاستخدام.
اليستر كوكبيرن في كتابة حالات الاستخدام المؤثرة حدد ثلاث مستويات للتفصيل في كتابة حالات الاستخدام:
بعض عمليات تطوير البرمجيات لا تتطلب أي شيء أكثر من حالة استخدام بسيطة لتحديد المتطلباتومع ذلك، تتطلب بعض حالات التطوير حالات استخدام مفصلة لتحديد المتطلبات. كلما كبر حجم المشروع وأصبح أكثر تعقيدا كلما زادت فرصة أنه سيكون من الضروي استخدام حالات استخدام مفصلة.
مستوى التفصيل في حالة الاستخدام يختلف في كثير من الأحيان وفقا لتقدم المشروع، حالة الاستخدام المبدئية يمكن أن تكون موجزة، ولكن عندما تتطور عملية التطوير فإن حالات الاستخدام تصبح أكثر تفصيلا. وهذا يعكس المتطلبات المختلفة لحالات الاستخدام، بداية تحتاج لأن تكون موجزة لأنها تستخدم لتلخيص متطلبات العمل من وجهة نظر المستخدمين.ولكن في وقت لاحق في هذه العملية يحتاج مطوري البرمجيات إلى توجيهات أكثر تحديدا وتفصيلا.
العملية الموحدة لراشيونال IBM تدعو المطورين إلى كتابة وصفا موجزا لحالة الاستخدام في حالة استخدام الرسم التخطيطي مع وصف عادي كتعليقات ووصف مفصل لتدفق الاحداث في تحليل نصي.ويمكن عادة أن يكون كل هؤلاء مدخلا في أداة حالة الاستخدام(مثل UML Tool, SysML Tool)، أو يمكن كتابتهم منفصلة في محرر النص.
تحدد حالة الاستخدام التفاعل بين الفاعلين الخارجيين والنظام قيد النظر لانجاز هدف ما.يحدد الفاعل الدور الذي يقوم به شخص أو شيء عندما يتفاعل مع النظام. يمكن تمثيل نفس الشخص الذي يستعمل النظام كمثليين مختلفين لأنهم يلعبون أدوارا مختلفة. على سبيل المثال المستخدم "جو" يمكن أن يلعب دور العميل عندما يستخدم جهاز الصراف الآلي لسحب النقود أويلعب دور صراف البنك عندما يستخدم النظام لإعادة درج النقدية.
أنواع الممثلين
يمكن وصف حالة الاستخدام على المستوى التجريدي (حالة استخدام العمل وتسمى أيضا ضرورة حالة الاستخدام)أو على مستوى النظام(نظام حالة الاستخدام) والاختلاف بين هذين هو المجال.
عملية التعيين للعمل هي طريقة أخرى لمستوى وصف العمل هذا.
في لغة موحدة للنمذجة (UML)، العلاقة بين كل (أو مجموعة من) حالات الاستخدام والممثلين يمكن تمثيلها بالرسم أو الرسوم البيانية وتعتمد أصلا على منهجية تدوين ايفار جاكبسون SysML. UML profile يستخدم نفس التدوين في مستوى نظام الكتلة.
حالات الاستخدام لها قيود: