عند تطوير أي نظام معلومات، نمرّ بثلاث مراحل رئيسية:

1. التحليل (Analysis): نفهم المشكلة، المتطلبات، وسلوك النظام.

2. التصميم (Design): نحوّل المعرفة من التحليل إلى مخططات أكثر قربًا من التنفيذ.

3. البرمجة (Implementation): نحول التصميم إلى كود فعلي.

هذا الفصل يركّز على مرحلة التصميم الكينوني (Object-Oriented Design)، باستخدام Class Diagrams التي تمثّل العمود الفقري لبناء الأنظمة البرمجية الحديثة.

---

1. التصميم كنشاط نمذجة

التصميم ليس كتابة كود، بل هو عملية بناء نماذج توضّح:

• ما هي مكوّنات النظام (Classes)؟

• ما علاقة هذه المكونات ببعضها؟

• ما الخصائص والوظائف الموجودة داخل كل مكوّن؟

• كيف يتفاعل النظام داخليًا لتنفيذ الـ Use Cases؟

ويمكن اعتبار التصميم "مخطط البناء" Blueprint الذي يسبق البرمجة.

---

2. الفرق بين Domain Class Diagram و Design Class Diagram

2.1. Domain Class Diagram – مخطط التحليل

يهدف إلى فهم العالم الحقيقي المرتبط بالمشكلة.
يتكوّن من:

• Classes تمثل كيانات النظام (Student, Customer, Product…).

• Attributes (البيانات الأساسية).

• Relationships بين الكيانات.

ولا يحتوي على:

• وظائف (Methods)

• أنواع بيانات مفصلة

• تفاصيل برمجية

هو مخطط مفاهيمي فقط.

---

2.2. Design Class Diagram – مخطط التصميم

يقترب أكثر من البرمجة ويحتوي على:

✔ Attributes
✔ Methods
✔ Visibility
✔ Data Types
✔ Relationships
✔ Stereotypes (entity, boundary, controller…)
✔ Class-level members
✔ Abstract / Concrete classes

هذا المخطط هو الذي سيُحوَّل لاحقًا إلى كود في Java، Python، C#… إلخ.

---

3. مكوّنات الـ Class في التصميم

يتكون كل كلاس في UML من ثلاثة أقسام:

1. اسم الكلاس

2. الخصائص (Attributes)

3. الوظائف (Methods)

3.1. كتابة الـ Attributes

الصيغة النموذجية:

أمثلة:

معاني الرموز:

• + public

• - private

• {key} يعني أنه معرّف فريد

---

3.2. كتابة الـ Methods

الصيغة:

أمثلة:

3.3. الفرق بين Concrete و Abstract

Abstract Class

---

4. العلاقات بين الكائنات (Associations)

4.1. Association

هي علاقة ببساطة بين Class وآخر.
يتم تحديد الـ Multiplicity (العدد المتوقع) لكل طرف:

أمثلة:

• 1 → علاقة إلزامية

• 0..* → صفر أو أكثر

• 1..* → واحد أو أكثر

• 0..1 → اختياري

مثال واقعي:

• Customer places Orders

  • الزبون يمكن أن يملك عدة طلبات (0..*)

  • الطلب يخص زبون واحد فقط (1)

---

5. Association Class

عندما تكون العلاقة Many-to-Many ونحتاج حفظ بيانات عن العلاقة نفسها، ننشئ Association Class.

مثال:

Student ↔ Course
ولكن نريد حفظ:

• Grade

• Enrollment Date

• Status

فيظهر كلاس جديد:

CourseEnrollment
- grade : Double
- enrollDate : Date
- status : String

ويمثّل معلومات الربط بين الطرفين وليس معلومات الطالب أو المادة.

---

6. Generalization / Specialization (الوراثة)

هي علاقة "أب – ابن" بين الصفوف.

6.1. Superclass و Subclass

• Superclass → الكلاس العام

• Subclass → الكلاس المتخصص

يرث الـ Subclass:

• الخصائص Attributes

• الوظائف Methods

• العلاقات Associations

مثال:

Account
 ↳ SavingsAccount
 ↳ CheckingAccount

6.2. لماذا نستخدم الوراثة؟

• تقليل التكرار

• تسهيل الصيانة

• إضافة أنواع جديدة بسهولة

• دعم الـ Polymorphism في البرمجة

---

7. Whole–Part Relationships

هي العلاقات التي تربط كيانًا كاملاً بكيانات أجزاء.

7.1. Aggregation (تجميع)

• الجزء يستطيع العيش بدون الكل.

• تمثّل بماسة فارغة.

مثال:

• Car — Wheel

• Computer — DiskDrive

العجلات والمنفذ يمكن نزعها وإعادة استخدامها.

---

7.2. Composition (تركيب)

• الجزء لا يمكن أن يعيش بدون الكل.

• تمثّل بماسة معبّأة.

مثال:

• Order — OrderItem

• Book — Chapter

إذا حذفنا الكتاب، تُحذف فصوله تلقائيًا.

---

8. أنواع الـ Classes في التصميم (Stereotypes)

نستخدمها لتقسيم أدوار الكائنات داخل النظام:

1. Entity Class

يمثل البيانات المخزنة — يتوافق غالبًا مع جدول قاعدة بيانات.
مثل: Customer، Order، Product.

2. Boundary / UI Class

يمثّل واجهة المستخدم.
مثل: LoginPage، PaymentScreen.

3. Controller Class

المسؤول عن تنفيذ منطق الـ Use Case، والتنسيق بين UI و Entity.

4. Data Access Class

مسؤول عن عمليات CRUD مع قاعدة البيانات.
مثل: CustomerDAO، OrderRepository.

هذا التقسيم يجعل النظام أوضح وأسهل في التطوير والصيانة.

---

9. Navigation Visibility (اتجاه الرؤية)

يُعبّر عن:

أي كلاس يستطيع الوصول إلى الآخر واستدعاء وظائفه؟

نحدد ذلك بوضع سهم على العلاقة:

مثال:

إذا كان السهم من Customer إلى Order فهذا يعني:

• Customer يمتلك مرجعًا إلى Order

• ويمكنه استدعاء وظائفه

وجود السهم يساعد المبرمج على معرفة الاتجاه الصحيح للاتصال بين الكائنات.

---

10. لماذا تعتبر Class Diagrams مهمة في التصميم؟

• تمنحك رؤية شاملة لبنية النظام.

• تسهّل عملية البرمجة لأنها تحدّد كل شيء مسبقًا.

• تقلّل من الأخطاء البرمجية.

• تجعل النظام قابلًا للتطوير والصيانة.

• تُستخدم كوثيقة رسمية داخل الفريق.