أهداف التعلم
"رؤية النظام من منظور المستخدم عبر رسوم Use Case"
بنهاية هذه الوحدة سيكون الطالب قادرًا على:
- التعرف على **لغة النمذجة الموحدة (UML)** ودورها في تطوير الأنظمة.
- فهم مفهوم **رسوم Use Case** كأداة لتوضيح وظائف النظام.
- التمييز بين **الأدوار (Actors)** و**السيناريوهات (Scenarios)**.
- القدرة على رسم **مخطط Use Case** يوضح التفاعل بين المستخدم والنظام.
- إدراك أهمية هذه الرسوم في تحديد نطاق النظام وتحسين التواصل مع أصحاب المصلحة.
1. مقدمة في UML
بعد أن تعلمنا في الوحدات السابقة كيفية تحليل تدفق البيانات باستخدام DFDs وجمع المتطلبات، سننتقل الآن إلى أداة نمذجة أخرى قوية ومتكاملة تُستخدم على نطاق واسع في هندسة البرمجيات وتصميم الأنظمة: **لغة النمذجة الموحدة (Unified Modeling Language - UML)**.
ما هي UML؟
**UML** هي لغة رسومية موحدة تُستخدم **لنمذجة، وتحديد، وتصميم، وتوثيق** الأنظمة البرمجية. إنها ليست لغة برمجة، بل هي مجموعة من الرموز والمخططات القياسية التي تساعد محللي النظم والمطورين على تصور وتوثيق بنية وسلوك النظام بطريقة مفهومة للجميع.
أهمية UML
تُقدم UML فوائد عظيمة في دورة حياة تطوير النظام (SDLC):
- **توثيق شامل:** توفر طريقة موحدة لتوثيق جميع جوانب النظام، من متطلبات المستخدم إلى تصميم الكود الداخلي.
- **تحليل دقيق:** تساعد في تحليل الأنظمة المعقدة من خلال تقسيمها إلى نماذج بصرية أبسط.
- **تصميم منهجي:** تُمكن من تصميم هيكل النظام وسلوكه قبل البدء في البرمجة الفعلية.
- **تواصل فعال:** توفر لغة بصرية مشتركة تٌقلل من سوء الفهم بين أصحاب المصلحة (العملاء، المحللين، المبرمجين، المختبرين).
أنواع الرسوم في UML
تتكون UML من أنواع متعددة من المخططات (Diagrams)، كل منها يركز على جانب معين من النظام. تشمل هذه المخططات على سبيل المثال لا الحصر:
- **مخططات حالات الاستخدام (Use Case Diagrams):** تُظهر وظائف النظام من منظور المستخدم.
- **مخططات الفئات (Class Diagrams):** تُظهر بنية النظام من حيث الفئات والعلاقات بينها.
- **مخططات التسلسل (Sequence Diagrams):** تُظهر ترتيب الرسائل المتبادلة بين الكائنات.
- **مخططات الأنشطة (Activity Diagrams):** تُظهر تدفق العمليات والأنشطة.
ملاحظة:
في هذه الوحدة، سنركز بشكل خاص على **مخططات حالات الاستخدام (Use Case Diagrams)** لأنها تُعد نقطة البداية لفهم متطلبات النظام من منظور المستخدم.
2. رسوم Use Case
تُعد **مخططات حالات الاستخدام (Use Case Diagrams)** واحدة من أبسط وأقوى مخططات UML. هدفها الرئيسي هو **توضيح وظائف النظام من منظور المستخدمين (Actors)** وماذا يمكنهم فعله بالنظام. إنها تقدم نظرة "سلوكية" أو "خارجية" للنظام، بمعنى أنها تُركز على الوظائف التي يقدمها النظام للمستخدمين وليس كيفية تنفيذ هذه الوظائف داخليًا.
تعريف مخطط Use Case
هو تمثيل رسومي يُظهر العلاقة بين **المستخدمين الخارجيين (Actors)** و**وظائف النظام (Use Cases)** التي يستخدمونها. كل Use Case يمثل وظيفة أو خدمة معينة يقدمها النظام لتحقيق هدف معين للمستخدم.
مكوناته الأساسية
يتكون مخطط Use Case من ثلاثة مكونات رئيسية:
- **الأدوار (Actors):** يمثلون الأشخاص أو الأنظمة الأخرى التي تتفاعل مع النظام.
- **حالات الاستخدام (Use Cases):** تمثل وظيفة محددة أو خدمة يقدمها النظام.
- **العلاقات (Relationships):** توضح كيفية تفاعل الأدوار مع حالات الاستخدام والعلاقات بين حالات الاستخدام نفسها.
3. الأدوار (Actors)
في مخططات Use Case، **الدور (Actor)** هو كيان (شخص، نظام آخر، جهاز) يتفاعل مع النظام الذي نقوم بتحليله أو تصميمه. يمثل الدور **فئة** من المستخدمين أو الأنظمة ذات سلوك متشابه تجاه النظام، وليس فردًا معينًا.
- **التمثيل:** يُرسم الدور عادةً على شكل "شخص عصا" (Stick figure).
- **التسمية:** يُعطى اسماً يعبر عن الدور الذي يؤديه (مثال: "طالب"، "مدير"، "نظام الدفع").
أنواع الأدوار
يمكن تصنيف الأدوار إلى نوعين رئيسيين:
- **أدوار رئيسية (Primary Actors):**
- هم المستخدمون الذين يبدأون (Initiate) حالة الاستخدام لتحقيق هدف معين.
- هم المستفيدون الرئيسيون من وظيفة النظام.
- مثال: **الطالب** في نظام تسجيل الطلاب (يبدأ عملية التسجيل).
- **أدوار ثانوية (Secondary Actors):**
- هم الكيانات التي تدعم (Support) النظام أو تُقدم له خدمة.
- لا يبدأون حالة الاستخدام بشكل مباشر، ولكن النظام يتفاعل معهم لإكمال وظيفة معينة.
- مثال: **نظام الدفع الإلكتروني** في نظام التجارة الإلكترونية (يُقدم خدمة الدفع للنظام).
مثال: الأدوار في نظام مكتبة جامعية
- **Actor رئيسي:** **الطالب** (يريد استعارة كتاب، البحث عن كتاب).
- **Actor رئيسي:** **أمين المكتبة** (يدير الكتب، يسجل الاستعارات).
- **Actor ثانوي:** **نظام الدفع الإلكتروني** (يستقبل المدفوعات من الطلاب على الغرامات).
- **Actor ثانوي:** **نظام الجامعة المركزي** (يوفر معلومات الطلاب للتأكد من هويتهم).
4. سيناريوهات التفاعل (Scenarios)
بينما تُظهر مخططات Use Case الوظائف (Use Cases) والأدوار (Actors) وعلاقاتها بصريًا، فإنها لا تُقدم التفاصيل الدقيقة لكيفية حدوث التفاعل. هنا يأتي دور **السيناريوهات (Scenarios)**.
تعريف السيناريو
السيناريو هو **وصف نصي مفصل لخطوات التفاعل** التي تحدث بين الدور والنظام لتحقيق هدف حالة استخدام معينة. بعبارة أخرى، هو "قصة" تُروى خطوة بخطوة لما يحدث عندما يقوم دور ما باستخدام وظيفة معينة في النظام.
كتابة السيناريوهات تُساعد على فهم المتطلبات بشكل أعمق، وتحديد جميع الخطوات الممكنة، وتوقع المشاكل المحتملة.
أنواع السيناريوهات
عادة ما يتم تقسيم السيناريوهات إلى نوعين رئيسيين:
- **السيناريو الأساسي (Main Flow / Happy Path):**
- يصف المسار الطبيعي والناجح للتفاعل بين الدور والنظام.
- هو السيناريو الذي يحدث في معظم الحالات دون وجود أي أخطاء أو شروط استثنائية.
- مثال: المسافر يقوم بحجز تذكرة (جميع الخطوات تسير بسلاسة ويتم الحجز بنجاح).
- **السيناريو البديل (Alternative Flow):**
- يصف مسارًا بديلاً يحدث عند وجود خطأ، أو شرط استثنائي، أو خيار مختلف.
- يمكن أن يؤدي إلى نجاح حالة الاستخدام بطريقة مختلفة، أو إلى فشلها.
- مثال: في حالة حجز التذكرة، إذا لم تتوفر مقاعد في الرحلة المطلوبة، يتم اقتراح رحلات بديلة.
مثال: سيناريو "حجز تذكرة طيران"
السيناريو الأساسي:
- المسافر يدخل معلومات الرحلة المطلوبة (وجهة، تاريخ، عدد المسافرين).
- النظام يعرض الرحلات المتاحة بناءً على المدخلات.
- المسافر يختار رحلة معينة ومقاعد.
- المسافر يدخل بيانات الدفع.
- النظام يتحقق من الدفع ويؤكد الحجز.
- النظام يرسل تأكيد الحجز وتفاصيل التذكرة إلى المسافر.
السيناريو البديل (عدم توفر مقاعد):
- (الخطوة 3 من السيناريو الأساسي): المسافر يختار رحلة ومقاعد.
- النظام يكتشف عدم توفر عدد المقاعد المطلوب في هذه الرحلة.
- النظام يعرض رسالة "المقاعد غير متوفرة" ويقترح رحلات بديلة في نفس اليوم أو أيام أخرى قريبة.
- المسافر يختار رحلة بديلة (أو يقرر إلغاء العملية).
- (العودة إلى الخطوة 4 من السيناريو الأساسي).
5. أهمية رسوم Use Case
تُقدم مخططات Use Case فوائد متعددة في مراحل تحليل وتصميم الأنظمة، مما يجعلها أداة محورية لمحللي النظم والمطورين:
- **تحديد نطاق النظام (System Scope):** تُساعد في تحديد الوظائف الأساسية التي يجب أن يقدمها النظام بوضوح، وما هو خارج نطاقه. هذا يمنع "زحف المتطلبات" (Scope Creep).
- **تحسين التواصل:** لأنها بسيطة ومرئية، يمكن لأصحاب المصلحة غير التقنيين (مثل العملاء والمديرين) فهمها بسهولة، مما يسهل المناقشات والتأكد من أن النظام يلبي احتياجاتهم الحقيقية.
- **تسهيل التطوير:** توفر أساسًا واضحًا للمراحل اللاحقة مثل التصميم (مثلاً، يمكن تحويل Use Cases إلى فئات Classes أو مكونات Components)، والتنفيذ.
- **تقليل المخاطر:** الكشف المبكر عن أي تعارضات في المتطلبات، أو وظائف مفقودة، أو سوء فهم بين الأطراف المختلفة، مما يقلل من تكلفة التعديلات لاحقًا.
- **دعم الاختبارات:** كل حالة استخدام (Use Case) يمكن أن تُعد أساسًا لتصميم حالات اختبار (Test Cases) وظيفية، مما يضمن اختبار جميع وظائف النظام.
6. مثال تطبيقي: نظام حجز تذاكر طيران
لنُطبق ما تعلمناه برسم مخطط Use Case بسيط لنظام حجز تذاكر الطيران.
الأدوار (Actors):
- **المسافر:** (Primary Actor) هو الشخص الذي يقوم بحجز التذاكر، إلغائها، أو طباعتها.
- **موظف الحجز:** (Primary Actor) قد يكون موظفًا في شركة الطيران يساعد المسافرين أو يدير الحجوزات.
- **نظام الدفع الإلكتروني:** (Secondary Actor) نظام خارجي يتعامل مع عمليات الدفع.
- **قاعدة بيانات الرحلات:** (Secondary Actor) قد تكون نظامًا أو مخزن بيانات خارجي يوفر معلومات الرحلات المتاحة.
حالات الاستخدام (Use Cases):
- **حجز تذكرة:** (Booking a Ticket) يقوم بها المسافر أو موظف الحجز.
- **إلغاء حجز:** (Cancelling a Booking) يقوم بها المسافر أو موظف الحجز.
- **طباعة التذكرة:** (Printing Ticket) يقوم بها المسافر أو موظف الحجز.
- **إجراء الدفع:** (Making Payment) جزء من عملية حجز التذكرة، ويتفاعل مع نظام الدفع الإلكتروني. (يمكن أن يكون Use Case منفصلاً أو متضمنًا).
- **البحث عن رحلات:** (Searching for Flights) يقوم بها المسافر أو موظف الحجز.
- **تعديل الحجز:** (Modifying Booking) يقوم بها المسافر أو موظف الحجز.
العلاقات (Relationships):
- **المسافر:** يرتبط بـ (حجز تذكرة، إلغاء حجز، طباعة التذكرة، البحث عن رحلات، تعديل الحجز).
- **موظف الحجز:** يرتبط بـ (حجز تذكرة، إلغاء حجز، طباعة التذكرة، البحث عن رحلات، تعديل الحجز).
- **حجز تذكرة** <include>> **إجراء الدفع:** (عملية الدفع متضمنة دائمًا في الحجز).
- **البحث عن رحلات:** <extend>> **حجز تذكرة** (يمكن البحث عن رحلات بشكل مستقل أو كجزء من عملية الحجز).
- **إجراء الدفع:** يتفاعل مع **نظام الدفع الإلكتروني**.
- **حجز تذكرة / البحث عن رحلات:** تتفاعل مع **قاعدة بيانات الرحلات**.
الأنشطة التعليمية
لترسيخ فهمك لمخططات Use Case، إليك بعض الأنشطة المقترحة:
- **ورشة عمل: رسم Use Case Diagram لنظام تسجيل جامعي**
- قسّموا أنفسكم إلى مجموعات (4-5 طلاب).
- قوموا بتحديد الأدوار (Actors) وحالات الاستخدام (Use Cases) لنظام تسجيل طلاب جامعيين (يتضمن تسجيل المقررات، دفع الرسوم، عرض الجداول).
- استخدموا أداة رسم مجانية مثل Draw.io أو Lucidchart لرسم مخطط Use Case Diagram لهذا النظام.
- **تمرين فردي: كتابة سيناريو نصي**
- اختاروا حالة استخدام واحدة من نظام طلب قرض بنكي (مثلاً: "تقديم طلب قرض جديد").
- اكتبوا السيناريو الأساسي (Main Flow) بالتفصيل خطوة بخطوة.
- اكتبوا سيناريو بديل واحد على الأقل (Alternative Flow) (مثلاً: "رفض طلب القرض بسبب نقص المستندات").
- **نشاط جماعي: تحديد Actors و Use Cases لنظام تجارة إلكترونية**
- بالتعاون مع زملاء المجموعة، قوموا بتحديد أكبر عدد ممكن من الأدوار (Actors) وحالات الاستخدام (Use Cases) التي تتوقعونها في نظام تجارة إلكترونية متكاملة (تشمل العميل، البائع، المدير، نظام الدفع، نظام الشحن، إلخ).
- لا ترسموا المخطط، فقط أعدوا قائمة منظمة.
المراجع البصرية المقترحة
لتعزيز فهمك البصري للمفاهيم، يمكنك البحث عن المخططات التالية:
- **رسم يوضح الفرق بين Actor وUse Case:** يوضح بشكل مرئي كيف يتم تمثيل كل منهما وعلاقتهما.
- **مثال Use Case Diagram مبسط (مثل ATM أو مكتبة جامعية):** يوفر نماذج جاهزة لكيفية بناء المخططات.
- **جداول تربط السيناريو النصي بالمخطط الرسومي:** توضح كيفية ترجمة الخطوات النصية إلى مكونات رسومية.
ملخص الوحدة
لقد أكملتَ هذه الوحدة الشيقة في مقرر "تحليل وتصميم النظم"، حيث تعلمتَ كيف ترى النظام من زاوية المستخدم وتُنمذجه بصريًا.
- تعرفتَ على **لغة النمذجة الموحدة (UML)** كأداة قياسية لنمذجة وتوثيق الأنظمة.
- فهمتَ جوهر **مخططات حالات الاستخدام (Use Case Diagrams)**، وكيف تُظهر الوظائف التي يقدمها النظام للمستخدمين.
- ميزتَ بوضوح بين **الأدوار (Actors)** بأنواعها المختلفة (رئيسية وثانوية) و**حالات الاستخدام (Use Cases)**.
- تعلمتَ كيفية وصف **سيناريوهات التفاعل** تفصيليًا، بما في ذلك المسار الأساسي والمسارات البديلة.
- أدركتَ الأهمية القصوى لرسوم Use Case في تحديد نطاق المشروع، وتحسين التواصل، وتقليل المخاطر، ودعم مراحل التطوير والاختبار.
تُعد مخططات Use Case نقطة انطلاق ممتازة لأي مشروع نظام، حيث تساعد على ضمان أن النظام سيُلبي الاحتياجات الحقيقية للمستخدمين. في الوحدة القادمة، سنتعمق في جانب آخر مهم من تصميم الأنظمة وهو **تحليل وتصميم البيانات باستخدام مخططات ERD**، حيث ستتعلم كيفية نمذجة بنية البيانات وعلاقاتها.