استخلاص الفئات من المتطلبات

استخلاص الفئات من المتطلبات

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

الخطوة الأولى — تحليل الأسماء

أبسط نقطة بداية هي لغوية: اقرأ كل متطلب أو قصة مستخدم وضع خطًا تحت كل اسم أو عبارة اسمية. الأسماء تمثل كيانات، والكيانات تصبح فئات مرشحة — أو سمات أو جهات خارجية — وستُصفّيها لاحقًا. تأمّل هذا المقطع من مواصفات نظام حجز عيادة طبية:

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

صفّ القائمة باستخدام أربعة أسئلة معيارية:

1. هل هو ذو صلة بالنطاق؟ — نظام يشير إلى البرنامج ذاته؛ احذفه.
2. هل هو سمة تابعة لكيان آخر؟ — اسم وتاريخ الميلاد وبيانات التواصل خصائص للكيان Patient؛ حوّلها إلى سمات.
3. هل هو مخرج وليس كيانًا مُخزَّنًا؟ — تأكيد إشعار يُرسَل للخارج؛ ليس فئة في الغالب ما لم تُحتفظ بسجل له.
4. هل هو جهة خارجية؟ — الجهات الخارجية تظهر في مخططات حالات الاستخدام لا في مخططات الفئات.

بعد تطبيق هذه المعايير يبقى خمسة مرشحين راسخين: Patient، AppointmentSlot، Doctor، Department، Booking. هذه قائمة فئاتك الأولية.

الخطوة الثانية — بطاقات CRC

بطاقة الفئة-المسؤولية-المتعاون (CRC) هي بطاقة فهرس 3×5 إنش (أو جدول على لوح أبيض) مقسّمة إلى ثلاثة أقسام: اسم الفئة في الأعلى، عمود أيسر للمسؤوليات — ما تعرفه الفئة أو تفعله — وعمود أيمن للمتعاونين — الفئات الأخرى التي تحتاج مساعدتها. ابتكر هذه البطاقات كنت بيك وورد كانينغهام أداةً خفيفة تُشارك فيها خبراء المجال مباشرةً.

في ما يلي بطاقات CRC لنطاق العيادة:

لاحظ كيف يتتبّع عمود المتعاونين في كل بطاقة علاقة ضمنية: Booking تحتاج كلًا من Patient وAppointmentSlot؛ وAppointmentSlot تحتاج Doctor. هذه التعاونات ستصبح ارتباطات تُرسمها كخطوط في مخطط الفئات الكامل.

تطبيق الأسلوبين معًا

في الممارسة الفعلية يُستخدَم تحليل الأسماء وبطاقات CRC بصورة تكرارية:

1. شغّل تحليل الأسماء على وثيقة المتطلبات لاستخلاص قائمة الفئات المرشحة.
2. أنشئ بطاقة CRC لكل مرشح ناجٍ.
3. استعرض السيناريوهات الرئيسية (قصص المستخدمين أو حالات الاستخدام) بالبطاقات، مُوزِّعًا المسؤوليات ومدوِّنًا التعاونات.
4. احذف الفئات التي لا مسؤوليات لها؛ ادمج الفئات المتشابهة جدًا؛ اقسم الفئات التي تمتلك قائمة مسؤوليات طويلة جدًا.

لنأخذ نطاقًا ثانيًا — متجر كتب إلكتروني. سيناريو مختصر: "يتصفح العميل الكتالوج، ويضيف كتبًا إلى سلة التسوق، ويثبت طلبًا، ويستلم فاتورة." يُنتج تحليل الأسماء: Customer، catalogue، Book، ShoppingCart، Order، Invoice. بعد التصفية:

• catalogue — بالأحرف الصغيرة، يشير إلى سلوك استعلام لا فئة مستقلة. حوّله إلى تابع استعلام في Book — أو احتفظ به إن كانت للكتالوج قواعد خاصة به.
• Customer، Book، ShoppingCart، Order، Invoice — جميعها تنجو من التصفية.

ستكشف بطاقات CRC أن ShoppingCart تتعاون مع Book (تحتوي على بنود) ومع Customer (تنتمي لجلسة)، وأن Order تتعاون مع ShoppingCart (تُنشأ منها) ومع Invoice (تُحفّز إنشاءها).

أخطاء شائعة يجب تجنبها

• الإبقاء على أسماء واجهة المستخدم: كلمات مثل شاشة وصفحة وزر وتقرير تصف الواجهة لا النطاق؛ احذفها.
• تحويل كل سمة إلى فئة: عنوان البريد الإلكتروني ورقم الهاتف وISBN قيم مُخزَّنة داخل فئة أخرى — لا فئات قائمة بذاتها — إلا إذا فرض العمل قواعد خاصة بها (كفئة PhoneNumber بتنسيق وتحقق مخصص).
• إغفال الفئات الضمنية: بعض الفئات لا تظهر كأسماء لأن المتطلب يصف أثرها فقط. مثلًا: "يحتفظ النظام بسجل لجميع التغييرات" تستلزم فئة ChangeLog أو AuditEntry لم يُصرَّح باسمها.

ملخص

يحوّل اكتشاف فئات النطاق وثيقة المتطلبات إلى مادة خام للنمذجة. يمنحك تحليل الأسماء أسلوبًا سريعًا وقابلًا للتكرار لاستخلاص الفئات المرشحة من النثر. وتمنحك بطاقات CRC أسلوب ورشة عمل لتوزيع المسؤوليات وكشف التعاونات والتحقق من القائمة مع خبراء النطاق. يُنتج الأسلوبان معًا نقطة انطلاق موثّقة لمخطط الفئات الرسمي الذي ستبنيه في الدروس القادمة.