مخططات UML لمشروع التخرج: اختيار Use Case وSequence وClass

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

ثبت السيناريو قبل الرسم

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

من يتفاعل مع ماذا؟ Use Case

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

Student ──┬── [ Lab Booking System ] ── Admin
          │    (Create booking)        │
          └─── (Cancel own booking)    └── (Manage devices)

ولإنشاء الرسم بأداة PlantUML، يمكن تكييف المصدر الآتي. استُخدمت أسماء إنجليزية قصيرة داخل المخطط لتسهيل تبادل الملف؛ اكتب قاموس المصطلحات العربي في التقرير أو استخدم أسماء عربية عندما تتأكد من دعم الخط والرسم في أداتك.

@startuml
left to right direction
actor Student
actor Admin
rectangle "Lab Booking System" {
  usecase "Create booking" as Create
  usecase "Cancel own booking" as Cancel
  usecase "Manage devices" as Manage
}
Student -- Create
Student -- Cancel
Admin -- Manage
@enduml

تشرح وثائق PlantUML لحالات الاستخدام تعريف الممثل والحالة وحد النظام. لا تستخدم include لإضافة كل خطوة تقنية؛ العلاقة تحتاج معنى وظيفياً صحيحاً. ويمكن الاكتفاء بالمخطط الواضح دون علاقات إضافية إن لم تخدم سؤال التقرير.

كيف تنفذ عملية الحجز؟ Sequence

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

@startuml
actor Student
boundary UI
control BookingService
database DB
Student -> UI: choose(device, period)
UI -> BookingService: createBooking(user, device, period)
BookingService -> BookingService: validate user and period
BookingService -> DB: transaction: check and save
alt conflict
  DB --> BookingService: unavailable
  BookingService --> UI: conflict
else available
  DB --> BookingService: bookingId
  BookingService --> UI: confirmed(bookingId)
end
UI --> Student: show outcome
@enduml

عبارة transaction هنا التزام تصميمي يجب أن يفسر التنفيذ كيف يحققه، وليست تعويذة تمنع التعارض تلقائياً. إذا أصبحت قاعدة الحجز في مكون آخر، حدّث المشاركين والرسائل. يوضح مرجع التسلسل في PlantUML الأسهم والبدائل، لكن صحة السيناريو تأتي من تطابق الرسم مع قواعد مشروعك.

ما البنية التي تحمل هذا السلوك؟ Class

يوضح الرسم التالي أن المستخدم والجهاز يرتبطان بعدة حجوزات، وأن خدمة الحجز تعتمد هذه الكيانات. العلامة 1 في طرف المستخدم تعني أن الحجز الواحد له مستخدم واحد في هذا النموذج. لا تضف تركيباً Composition لمجرد رغبتك في شكل سهم مختلف؛ لهذه العلاقات دلالات تتعلق بالملكية والعمر.

@startuml
class User {
  +id: int
  +displayName: string
}
class Device {
  +id: int
  +name: string
}
class Booking {
  +id: int
  +startsAt: datetime
  +endsAt: datetime
  +status: string
}
class BookingService {
  +createBooking(user, device, period)
}
User "1" -- "0..*" Booking
Device "1" -- "0..*" Booking
BookingService ..> Booking
BookingService ..> Device
@enduml

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

قائمة فحص الاتساق

• هل Create booking في Use Case يقابله سيناريو موثق ومسار منفذ؟
• هل بيانات device وperiod في التسلسل موجودة في عقد الطلب؟
• هل مسؤولية التحقق والحفظ في الرسم توافق موقعها في الكود؟
• هل علاقة المستخدم بالحجز توافق مفاتيح قاعدة البيانات وسياسة الحذف؟
• هل فرع التعارض موجود في الاختبارات، لا في الرسم فقط؟
• هل عُدلت المخططات بعد آخر تغيير جوهري؟

ترافق الرسوم مصادر PlantUML يمكن تعديلها وإعادة تصييرها؛ لم يُختبر مصيّر PlantUML محلياً. احتفظ بهذه المصادر مع التقرير، وراجعها عند تغيير متطلبات النظام. ولمراجعة الرسوم ضمن التوثيق التقني، أرفق نسخة الكود التي يفترض أن تصفها، حتى يمكن مقارنة الأسماء والعلاقات وتسلسل التنفيذ.