الـ Class Diagram ده واحد من أهم وأشهر أنواع الرسوم التخطيطية في عالم الـ Software Engineering، وهو جزء أساسي من الـ UML (Unified Modeling Language). ببساطة، هو أداة بصرية بنستخدمها عشان نوصف ونوضح الـ structure (الهيكل أو البنية) بتاعة أي software system.

فالغالب بنستخدمها لو احنا شغالين Code-first

إيه هو الـ Class Diagram بالظبط؟

تخيله زي خريطة أو رسم هندسي للبرنامج بتاعك. الخريطة دي بتبين لنا:

  • الـ Classes: الوحدات الأساسية اللي بيتكون منها السيستم.
  • الـ Attributes: الخصائص أو البيانات اللي كل Class بيشيلها.
  • الـ Methods: الوظايف أو الأفعال اللي كل Class يقدر يعملها.
  • العلاقات (Relationships): إزاي الـ Classes دي مرتبطة ببعضها وبتتفاعل مع بعض.

الهدف الأساسي منه هو مساعدة كل اللي شغالين في المشروع (زي الـ developers والـ designers) إنهم يفهموا السيستم ده متركب إزاي والمكونات بتاعته بتتعامل مع بعضها إزاي. هو بيقدم رؤية عالية المستوى (high-level overview) للتصميم، وبيساعد جدًا في التواصل وتوثيق شكل البرنامج.

طيب، يعني إيه Class أصلًا؟

في عالم الـ Object-Oriented Programming (OOP)، الـ Class ده عبارة عن blueprint أو template (زي تصميم أو قالب) بنستخدمه عشان نعمل منه objects (كائنات).

  • الـ Object هو نسخة (instance) من الـ Class.
  • الـ Class بيحدد حاجتين أساسيتين للـ objects اللي هتتعمل منه:
    • الـ Attributes (Properties / Fields): دي الخصائص أو البيانات اللي الـ object هيعرفها عن نفسه (زي اسم الموظف، سن الطالب، سعر المنتج).
    • الـ Methods (Functions / Operations): دي الأفعال أو السلوكيات اللي الـ object يقدر يعملها (زي calculateSalary(), enrollInCourse(), addProductToCart()).

الـ Notation: شكل الـ Class في الـ Diagram

في الـ UML، الـ Class بيترسم بطريقة قياسية متعارف عليها عشان الكل يفهمها:

بيكون عبارة عن مستطيل متقسم 3 أجزاء فوق بعض:

  1. الجزء العلوي (Top Compartment): اسم الـ Class
    • بيتكتب اسم الـ Class هنا، عادة بيكون bold وفي النص.
  2. الجزء الأوسط (Middle Compartment): الـ Attributes
    • بنكتب هنا قايمة بالـ Attributes (الخصائص) بتاعة الـ Class.
    • كل Attribute بيتكتب في سطر لوحده، وغالبًا بيكون بالشكل ده: Visibility Name : DataType [= DefaultValue]
      • الـ Visibility: بتحدد مين يقدر يوصل للـ attribute ده (+, -, #, ~).
      • الـ Name: اسم الـ attribute.
      • الـ DataType: نوع البيانات (زي string, int, bool, Date, أو حتى اسم Class تاني).
      • الـ DefaultValue (اختياري): القيمة الافتراضية لو فيه.
  3. الجزء السفلي (Bottom Compartment): الـ Methods
    • بنكتب هنا قايمة بالـ Methods (الوظايف) بتاعة الـ Class.
    • كل Method بيتكتب في سطر لوحده، وغالبًا بيكون بالشكل ده: Visibility Name(ParameterList) : ReturnType
      • الـ Visibility: بتحدد مين يقدر ينادي الـ method دي.
      • الـ Name: اسم الـ method.
      • الـ ParameterList (اختياري): الـ parameters اللي الـ method بتاخدها (زي paramName : paramType).
      • الـ ReturnType: نوع القيمة اللي الـ method بترجعها (زي int, string, void لو مش بترجع حاجة).

الـ Visibility Notation (مُحدِّدات الرؤية)

دي الرموز اللي بنحطها قبل اسم الـ Attribute أو الـ Method عشان نحدد مستوى الوصول ليه:

  • الـ + (Public): أي حد يقدر يوصله من أي مكان (أي class تاني).
  • الـ - (Private): محدش يقدر يوصله غير من جوه نفس الـ Class ده بس.
  • الـ # (Protected): ممكن الوصول ليه من جوه نفس الـ Class أو من الـ Classes اللي بتورث منه (Subclasses).
  • الـ ~ (Package / Default / Internal): ممكن الوصول ليه من أي Class جوه نفس الـ Package أو الـ Assembly (أشهر في Java/C# عن UML القياسية).

اتجاه الـ Parameters (Parameter Directionality)

دي معلومة إضافية ممكن نحطها في الـ Methods عشان نوضح اتجاه سريان الداتا في الـ parameters:

  • الـ in (Input): الـ parameter ده جاي من بره للـ method (الـ caller بيبعته للـ method). ده بيكون الافتراضي لو محددتش حاجة. (السهم داخل على الكلاس).
  • الـ out (Output): الـ method هي اللي هتملى قيمة الـ parameter ده وترجعها للـ caller. (السهم طالع من الكلاس).
  • الـ inout (Input & Output): الـ parameter ده جاي بقيمة من بره، والـ method ممكن تعدل القيمة دي وترجعها للـ caller. (السهم رايح جاي).

دي بتساعد نفهم الداتا بتتحرك إزاي بين الـ objects لما بينادوا الـ methods بتاعة بعض.

العلاقات بين الـ Classes (Relationships)

الـ Classes مش بتعيش في جزر منعزلة، هي دايمًا مرتبطة ببعضها. الـ Class Diagram بيستخدم خطوط وأشكال مختلفة عشان يوضح أنواع العلاقات دي:

1. الـ Association (الارتباط)

  • دي إيه؟ أشهر وأعم علاقة. معناها إن فيه صلة أو ارتباط بين Class والتاني. الـ instances بتاعة الـ Class ده ممكن تكون مرتبطة بالـ instances بتاعة الـ Class التاني.
  • شكلها: خط مستقيم بيوصل بين الـ Classes.
  • ممكن نضيف عليها تفاصيل:
    • اسم للعلاقة: ممكن نكتب كلمة فوق الخط توضح طبيعة العلاقة (زي Works for, Manages).
    • اتجاه (Navigability): سهم على طرف الخط بيقول مين يعرف يوصل لمين. لو مفيش سهم، ممكن نفترض إن الاتنين يعرفوا يوصلوا لبعض أو الاتجاه مش مهم.
    • الـ Multiplicity (التعددية): أهم معلومة بنحطها على الـ Association (هنشرحها بالتفصيل تحت).
  • مثال (Library & Book): المكتبة (Library) فيها كتب (Book). فيه علاقة Association بينهم.

2. الـ Directed Association (ارتباط موجه)

  • دي إيه؟ هي نفسها الـ Association العادية، بس بنحط سهم صريح عشان نوضح اتجاه العلاقة. السهم بيشير من الـ Class اللي “بيعرف” أو “بيستخدم” الـ Class التاني.
  • مثال (Teacher & Course): الـ Teacher بيدرس Course معين. ممكن نحط سهم من Teacher لـ Course عشان نقول إن الـ Teacher هو اللي مرتبط بالـ Course (في سياق التدريس).

* هنا الـ Teacher هو الـ source والـ Course هو الـ target.

3. الـ Aggregation (التجميع)

  • دي إيه؟ نوع خاص من الـ Association بيمثل علاقة “جزء من كل” (Whole-Part) أو “يحتوي على” (Has-a). بس دي علاقة ضعيفة.
  • يعني إيه ضعيفة؟ يعني الـ “جزء” (Part) ممكن يعيش أو يكون موجود حتى لو الـ “كل” (Whole) مش موجود. الـ lifecycle بتاعتهم مش مرتبطة ببعض 100%.
  • شكلها: خط مستقيم، بس بيكون فيه شكل معين فاضي (hollow diamond) عند طرف الـ Class اللي بيمثل الـ “كل” (Whole).
  • مثال (Company & Employee): الشركة (Company) بتتكون من موظفين (Employee). الموظف جزء من الشركة، لكن لو الشركة قفلت (لا قدر الله)، الموظف هيفضل موجود كشخص وممكن يروح يشتغل في شركة تانية.

4. الـ Composition (التكوين)

  • دي إيه؟ برضه علاقة “جزء من كل” (Whole-Part / Has-a)، بس دي علاقة قوية جدًا.
  • يعني إيه قوية؟ يعني الـ “جزء” (Part) مقدرش يعيش أو يكون له معنى من غير الـ “كل” (Whole). لو الـ “كل” اتدمر، الـ “جزء” بيتدمر معاه بالضرورة. الـ lifecycle بتاعتهم مرتبطة ببعض بشكل كامل.
  • شكلها: خط مستقيم، بس بيكون فيه شكل معين مليان أو أسود (filled diamond) عند طرف الـ Class اللي بيمثل الـ “كل” (Whole).
  • مثال (Contact Book & Contact Entry): دفتر العناوين الرقمي (Contact Book) بيتكون من إدخالات العناوين (Contact Entry). الإدخال ده جزء من الدفتر، ولو مسحت الدفتر، الإدخالات اللي جواه بتتمسح معاه ومبقاش ليها وجود مستقل.

5. الـ Generalization / Inheritance (الوراثة / التعميم)

  • دي إيه؟ دي بتمثل علاقة “هو نوع من” (Is-a relationship). بيكون عندك Class عام (Superclass / Parent) و Class تاني متخصص أكتر بيورث منه (Subclass / Child). الـ Subclass بياخد كل خصائص ووظايف الـ Superclass (الـ Public والـ Protected) وممكن يضيف عليها حاجات خاصة بيه أو يعدل (override) فيها.
  • شكلها: خط مستقيم طالع من الـ Subclass ورايح للـ Superclass، وبيكون فيه سهم على شكل مثلث فاضي وكبير شوية (hollow triangle arrowhead) عند طرف الـ Superclass.
  • مثال (Bank Account): عندنا BankAccount (ده الـ Superclass). ممكن يكون فيه أنواع متخصصة بتورث منه زي CurrentAccount, SavingsAccount, CreditAccount (دول الـ Subclasses). كل واحد فيهم is a BankAccount.

6. الـ Realization / Implementation (تحقيق الواجهة)

  • دي إيه؟ دي علاقة بتقول إن فيه Class معين بيطبق أو بينفذ المواصفات اللي متحددة في Interface. الـ Interface ده بيكون زي “عقد” بيحدد إيه الـ Methods اللي الـ Class لازم يوفر لها implementation (كود فعلي).
  • شكلها: خط متقطع (dashed line) طالع من الـ Class اللي بيعمل implement ورايح للـ Interface، وبيكون فيه سهم على شكل مثلث فاضي (hollow triangle arrowhead) عند طرف الـ Interface (زي الـ Inheritance بس الخط متقطع).
  • مثال (Owner Interface): لو عندنا Interface اسمه Owner فيه methods زي acquireProperty() و disposeProperty(). ممكن الـ Class اللي اسمه Person والـ Class اللي اسمه Corporation الاتنين يعملوا implement للـ Owner interface ده، وكل واحد فيهم يكتب الكود الخاص بيه إزاي بيتملك أو بيتخلص من الممتلكات.

* الـ Interface نفسه بيترسم زي الـ Class بس بنكتب فوقه <<interface>>.

7. الـ Dependency (الاعتمادية)

  • دي إيه؟ دي علاقة بتقول إن فيه Class (الـ Client) بيعتمد على Class تاني (الـ Supplier) عشان يقدر يشتغل، بس الاعتماد ده بيكون مؤقت أو غير مباشر، مش زي الـ Association القوية. غالبًا الـ Client بيستخدم الـ Supplier كـ parameter في method أو كـ local variable جوه method، أو بينادي static method فيه.
  • شكلها: خط متقطع (dashed line) مع سهم عادي مفتوح (open arrowhead) بيشير من الـ Client (اللي بيعتمد) إلى الـ Supplier (اللي بيعتمد عليه).
  • مثال (Person & Book): الـ Person بيقرأ Book. الـ Person بيعتمد على وجود الـ Book عشان يقدر يقراه (ممكن ياخد Book كـ parameter في method اسمها read()). لكن الـ Person مش شرط يكون مرتبط بالـ Book ده بشكل دائم.

8. الـ Usage (استخدام - نوع من الـ Dependency)

  • دي إيه؟ هي تعتبر حالة خاصة من الـ Dependency. بتوضح إن Class (الـ Client) بيستخدم خدمات أو وظايف بيقدمها Class تاني (الـ Supplier)، من غير ما يكون فيه علاقة association قوية بينهم (يعني الـ Client مش بيحتفظ بـ reference للـ Supplier كـ attribute دايم).
  • شكلها: زي الـ Dependency بالظبط (خط متقطع بسهم مفتوح). أحيانًا بيضيفوا كلمة <<use>> على الخط (كـ stereotype).
  • مثال (Car & FuelTank): العربية (Car) بتستخدم خزان الوقود (FuelTank) عشان تعرف مستوى البنزين أو تعبي بنزين. الـ Car بتعتمد على الخدمات اللي بيقدمها الـ FuelTank.

الـ Multiplicity (التعددية) - تاني عشان مهمة

دي بتتكتب على أطراف خطوط العلاقات (خصوصًا Association, Aggregation, Composition) عشان تقول كم instance من الـ Class ده ممكن يرتبط بـ instance واحد من الـ Class التاني.

  • 1: واحد بالظبط.
  • 0..1: صفر أو واحد (اختياري).
  • * أو 0..*: صفر أو أكتر (أي عدد).
  • 1..*: واحد أو أكتر (واحد على الأقل).
  • الـ n: عدد n محدد.
  • الـ n..m: بين n و m.

الغرض من الـ Class Diagrams (ليه بنستخدمها؟)

  1. الوحيدة اللي بتوصف OOP صح: هي أكتر رسمة في الـ UML بتقدر توصف مفاهيم الـ Object-Oriented Programming بشكل كويس.
  2. تصميم وتحليل أسرع: بتساعد في تصميم وتحليل الأبلكيشن بشكل أسرع وأكثر كفاءة.
  3. أساس لرسومات تانية: بتعتبر أساس للـ Deployment Diagram والـ Component Diagram.
  4. هندسة أمامية وعكسية (Forward & Reverse Engineering): ممكن نستخدمها عشان نصمم الكود قبل ما نكتبه (Forward)، وممكن نستخدم أدوات تعمل generate للـ diagram ده من كود موجود فعلًا (Reverse).

فوايد الـ Class Diagrams (إيه الميزات؟)

  • بتوضح الـ Architecture: بتبين هيكل السيستم (classes, attributes, methods, relationships) بشكل واضح.
  • بتفهمنا العلاقات: بتوضح إزاي المكونات مرتبطة ببعض (associations, inheritance, etc.).
  • بتحسن التواصل: أداة بصرية ممتازة للتواصل بين أعضاء الفريق والـ stakeholders، بتقرب وجهات النظر بين الناس التكنيكال واللي مش تكنيكال.
  • دليل للـ Developers: بتوجه المبرمجين وهم بيكتبوا الكود وبتضمن إن التصميم بيتنفذ صح.
  • توليد الكود (Code Generation): أدوات كتير بتقدر تولد “هيكل” الكود (code skeletons) من الـ Class Diagram، وده بيوفر وقت ويقلل الأخطاء اليدوية.

إزاي ترسم Class Diagram؟ (الخطوات)

  1. حدد الـ Classes: أول حاجة، فكر إيه هي الـ Classes الأساسية في السيستم بتاعك.
  2. اكتب الـ Attributes والـ Methods: لكل Class حددته، اكتب قايمة بالبيانات اللي بيشيلها (Attributes) والوظايف اللي بيعملها (Methods). متنساش تحدد الـ Data Types والـ Visibility.
  3. اكتشف العلاقات: فكر إزاي الـ Classes دي مرتبطة ببعض. هل فيه Association؟ Inheritance؟ Composition؟ وحدد الـ Multiplicity بتاعت كل علاقة.
  4. ارسم الـ Class Boxes: ارسم مستطيل لكل Class واكتب اسمه فوق، وجهز مكان الـ Attributes والـ Methods.
  5. ضيف الـ Attributes والـ Methods: املى الأجزاء بتاعة الـ Attributes والـ Methods في كل مستطيل، وحط علامات الـ Visibility صح.
  6. ارسم العلاقات: وصل بين الـ Classes بالخطوط المناسبة لنوع العلاقة (مستقيم، متقطع) وحط الأسهم والأشكال الصح (مثلث فاضي، معين فاضي/مليان).
  7. حط تفاصيل العلاقات: اكتب الـ Multiplicity على أطراف الخطوط، وممكن تكتب اسم للعلاقة لو هيوضح المعنى.
  8. راجع وحسّن: بص على الـ Diagram كله وتأكد إنه منطقي وبيعبر عن السيستم صح. خد رأي فريقك وحسّن فيه لو محتاج.

استخدامات الـ Class Diagrams (بنستخدمها فين؟)

  • وصف الهيكل الثابت (Static Structure): هي بتوصف شكل السيستم وهو “ثابت”، يعني إيه مكوناته وإزاي متربطة ببعض، بغض النظر عن إزاي بتشتغل مع الوقت.
  • تنظيم وتصور المكونات: بتساعدك تشوف الصورة الكبيرة وتنظم أفكارك عن مكونات السيستم.
  • أساس للتنفيذ (Blueprint): زي ما قلنا، هي زي الرسم الهندسي اللي المبرمجين بيمشوا عليه.
  • تسهيل النقاش والتفاهم: ممتازة عشان تناقش التصميم مع فريقك وتوصلوا لفهم مشترك.
  • توليد الكود: بتستخدم كـ input لأدوات الـ code generation.

باختصار، الـ Class Diagram أداة لا غنى عنها لأي حد شغال في مجال الـ Software، بتخلي عملية التصميم والتوثيق والتواصل أسهل وأوضح بكتير.