شرح مادة CS 385 هندسة البرمجيات - جامعة الاميرة نورة

مادة CS 385، هندسة البرمجيات (Software Engineering) بجامعة الاميرة نورة بنت عبدالرحمن هي المادة اللي تنقلك من مرحلة “ابرمج لحالي” الى مرحلة “ابني برنامج مع فريق كامل”. في المواد السابقة تعلمتي تكتبين كود يشتغل، وهذا ممتاز. لكن في الحياة العملية ما فيه مشروع حقيقي تبنيه طالبة لحالها. كل تطبيق تستخدمينه يوميا، سواء انستقرام او نظام التسجيل في الجامعة او تطبيق البنك، بناه فريق مكون من عشرات او مئات المطورين. السؤال هو: كيف يشتغلون مع بعض بدون ما يصير فوضى؟ هذا بالضبط اللي تجاوبك عليه CS 385.

كثير من الطالبات يشوفون ان هندسة البرمجيات مادة “نظرية” ويحسبونها حفظ وبس. هذا التصور غلط. المادة فيها جزء نظري لازم تفهمينه عشان تقدرين تطبقينه، لكن الجوهر هو التطبيق العملي: تصميم نظام حقيقي، رسم مخططات UML، تقسيم المهام، اختبار الكود، والتعامل مع ادوات مثل Git. لو فهمتي المادة صح، مشروع التخرج راح يصير اسهل بمراحل.

ليش هندسة البرمجيات مهمة لكل طالبة حاسب

في CS 110 و CS 111 تعلمتي تكتبين كود يحل مشكلة. في CS 212 تعلمتي تنظمين البيانات بطريقة ذكية. لكن كل هذا كان عبارة عن تمارين فردية: انتي والكود ومشكلة محددة. الحياة العملية مختلفة تماما.

تخيلي انك تبنين بيت. معرفتك بالمواد (الطوب والاسمنت والحديد) ضرورية، لكنها مو كافية. تحتاجين مخطط هندسي، جدول زمني، فريق عمل، ورقابة جودة. هندسة البرمجيات هي المخطط الهندسي للبرامج.

ليش تحتاجينها:

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

1. نماذج دورة حياة البرمجيات (SDLC)

دورة حياة تطوير البرمجيات (Software Development Life Cycle) هي المراحل اللي يمر فيها اي مشروع برمجي من اول فكرة الى اخر تحديث. فيه نماذج مختلفة لتنظيم هذي المراحل، وكل نموذج له استخداماته.

نموذج الشلال (Waterfall)

هذا اقدم نموذج واكثرها وضوحا. المراحل تمشي بترتيب ثابت، كل مرحلة لازم تخلص قبل ما تبدين اللي بعدها:

1. تحليل المتطلبات (Requirements): ايش النظام المطلوب؟
2. التصميم (Design): كيف نبني النظام؟
3. التنفيذ (Implementation): كتابة الكود
4. الاختبار (Testing): التاكد ان كل شيء يشتغل صح
5. النشر (Deployment): تشغيل النظام للمستخدمين
6. الصيانة (Maintenance): اصلاح الاخطاء واضافة تحسينات

مميزاته: واضح وبسيط، التوثيق مفصل، مناسب للمشاريع اللي متطلباتها ثابتة ومعروفة من البداية (مثل الانظمة الحكومية او الطبية).

عيوبه: ما يتحمل التغييرات. لو العميل غير رايه بعد ما وصلتي مرحلة التنفيذ، لازم ترجعين للبداية. هذا مكلف ويستهلك وقت.

منهجية Agile

Agile جاءت عشان تحل مشكلة الشلال مع التغييرات. بدل ما تبنين كل شيء دفعة وحدة، تبنين المشروع على دفعات صغيرة (iterations). كل دفعة تنتجين فيها جزء شغال من النظام، تعرضينه على العميل، وتاخذين ملاحظاته قبل ما تكملين.

مبادئ Agile الاساسية:

• الافراد والتفاعل اهم من العمليات والادوات
• برنامج شغال اهم من توثيق شامل
• التعاون مع العميل اهم من التفاوض على العقد
• الاستجابة للتغيير اهم من اتباع خطة ثابتة

جدول مقارنة Waterfall و Agile

المعيار	Waterfall	Agile
المراحل	متتابعة وثابتة	دورات متكررة
التغييرات	صعبة ومكلفة	مرحب فيها
تسليم المنتج	في النهاية فقط	تسليم مستمر
مشاركة العميل	في البداية والنهاية	طول المشروع
التوثيق	مفصل ويغطي كل شيء	خفيف وعملي
المناسب لـ	متطلبات ثابتة	متطلبات متغيرة
المخاطر	تتكشف متاخر	تتكشف بدري

2. اطار عمل Scrum بالتفصيل

Scrum هو اشهر اطار عمل يطبق منهجية Agile. اغلب شركات التقنية تستخدمه، فلما تتخرجين وتدخلين سوق العمل، غالبا راح تشتغلين بـ Scrum.

مفاهيم Scrum الاساسية

Sprint (السبرنت): فترة زمنية ثابتة (عادة 2-4 اسابيع) تشتغلين فيها على مجموعة محددة من المهام. كل سبرنت لازم ينتج جزء شغال من المنتج.

Product Backlog (قائمة المنتج): قائمة بكل الميزات والمتطلبات المطلوبة في المشروع، مرتبة حسب الاولوية. هذي القائمة تتغير وتتحدث طول المشروع.

Sprint Backlog (قائمة السبرنت): المهام المحددة اللي الفريق قرر ينفذها في هذا السبرنت. تنسحب من Product Backlog.

Daily Standup (الاجتماع اليومي): اجتماع قصير (15 دقيقة) كل يوم، كل وحدة في الفريق تجاوب على ثلاث اسئلة:

1. ايش سويتي امس؟
2. ايش بتسوين اليوم؟
3. فيه عوائق تواجهك؟

Sprint Review (مراجعة السبرنت): في نهاية كل سبرنت، الفريق يعرض اللي انجزه على العميل او المشرف ويسمع ملاحظاتهم.

Sprint Retrospective (استعراض السبرنت): الفريق يجلس مع بعض ويناقش: ايش مشى زين؟ ايش نحسنه؟ هذا الاجتماع للتحسين المستمر.

ادوار Scrum

• Product Owner (مالك المنتج): يحدد ايش المطلوب ويرتب الاولويات. هو الجسر بين العميل والفريق
• Scrum Master: يتاكد ان الفريق يتبع Scrum صح ويزيل العوائق. مو مدير، بل مساعد
• Development Team (فريق التطوير): اللي يسوون الشغل الفعلي. عادة 5-9 اشخاص

3. هندسة المتطلبات (Requirements Engineering)

هندسة المتطلبات هي عملية جمع وتحليل وتوثيق ايش النظام المطلوب يسوي. هذي المرحلة هي اهم مرحلة في اي مشروع، لان لو فهمتي المتطلبات غلط، كل اللي بعدها غلط.

المتطلبات الوظيفية (Functional Requirements)

هذي تصف ايش النظام يسوي. امثلة:

• النظام يسمح للطالبة بالتسجيل في المواد
• النظام يحسب المعدل التراكمي تلقائيا
• النظام يرسل اشعار لما تنفتح مادة جديدة
• النظام يسمح للادمن باضافة وحذف المواد

المتطلبات غير الوظيفية (Non-Functional Requirements)

هذي تصف كيف النظام يشتغل. مو عن الوظائف، بل عن الجودة:

• الاداء: النظام يستجيب خلال ثانيتين
• الامان: كلمات المرور تتشفر
• قابلية التوسع: النظام يتحمل 10,000 مستخدم في نفس الوقت
• سهولة الاستخدام: الطالبة تقدر تسجل في مادة بثلاث نقرات بالكثير
• التوفر: النظام يشتغل 99.9% من الوقت

تقنيات جمع المتطلبات

• المقابلات: تجلسين مع العميل وتسالينه مباشرة
• الاستبانات: تسوين استبيان وتوزعينه على المستخدمين المحتملين
• ملاحظة المستخدمين: تراقبين كيف المستخدمين يتعاملون مع النظام الحالي
• تحليل الوثائق: تدرسين الانظمة والمستندات الموجودة
• قصص المستخدم (User Stories): تكتبين المتطلبات من وجهة نظر المستخدم: “كطالبة، ابي اقدر اشوف جدولي الدراسي عشان انظم وقتي”

4. مخططات UML

UML (Unified Modeling Language) هي لغة رسومية موحدة تستخدمينها لتوثيق وتصميم الانظمة البرمجية. بدل ما تشرحين النظام بالكلام، ترسمين مخطط يوضح كل شيء. في CS 385 راح تتعلمين ثلاث مخططات اساسية.

مخطط حالات الاستخدام (Use Case Diagram)

يوضح من يستخدم النظام و ايش يقدر يسوي فيه. اسهل مخطط وغالبا اول واحد ترسمينه لاي مشروع.

العناصر:

• Actor (الممثل): الشخص او النظام اللي يتعامل مع نظامك. يترسم على شكل شخص
• Use Case (حالة الاستخدام): الوظيفة اللي يسويها. تترسم على شكل بيضاوي
• System Boundary (حدود النظام): مستطيل يحدد ايش داخل النظام وايش برا

مثال: نظام تسجيل المواد في جامعة الاميرة نورة

الممثلون: طالبة، مشرفة اكاديمية، ادمن النظام

حالات الاستخدام:
- طالبة ← تسجيل مادة
- طالبة ← سحب مادة
- طالبة ← عرض الجدول
- مشرفة ← الموافقة على التسجيل
- ادمن ← اضافة مواد جديدة
- ادمن ← اضافة اوقات المحاضرات

مخطط الكلاسات (Class Diagram)

يوضح الكلاسات في النظام وعلاقاتها ببعض. كل كلاس يحتوي على الخصائص (attributes) والدوال (methods).

+------------------+
|     Student      |
+------------------+
| - name: String   |
| - id: int        |
| - gpa: double    |
+------------------+
| + register()     |
| + dropCourse()   |
| + viewSchedule() |
+------------------+
        |
        | 1    *
        |
+------------------+
|     Course       |
+------------------+
| - code: String   |
| - title: String  |
| - credits: int   |
+------------------+
| + addStudent()   |
| + getCapacity()  |
+------------------+

انواع العلاقات:

• Association (ربط): خط عادي. الطالبة مرتبطة بالمادة
• Aggregation (تجميع): معين فارغ. القسم يحتوي على اساتذة، لكن الاستاذة تقدر تكون موجودة بدون القسم
• Composition (تكوين): معين مليان. الجامعة تحتوي على اقسام، لو الجامعة انحذفت الاقسام تنحذف معها
• Inheritance (وراثة): مثلث فارغ. طالبة ماجستير ترث من كلاس طالبة
• Multiplicity (التعددية): الارقام على الخط (1..* يعني واحد او اكثر، 0..1 يعني صفر او واحد)

مخطط التتابع (Sequence Diagram)

يوضح ترتيب التفاعل بين العناصر مع مرور الوقت. مفيد جدا لتوضيح سيناريو معين خطوة بخطوة.

مثال: سيناريو تسجيل طالبة في مادة

طالبة          واجهة النظام         نظام التسجيل         قاعدة البيانات
  |                 |                      |                     |
  |-- تختار مادة -->|                      |                     |
  |                 |-- تحقق الشروط ----->|                     |
  |                 |                      |-- تحقق المقاعد --->|
  |                 |                      |<-- مقاعد متاحة ----|
  |                 |                      |-- سجل الطالبة ---->|
  |                 |                      |<-- تم التسجيل -----|
  |                 |<-- تم بنجاح ---------|                     |
  |<-- رسالة تاكيد--|                      |                     |

5. تصميم البرمجيات وانماط التصميم

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

مبادئ التصميم الجيد

• Low Coupling (ارتباط ضعيف): كل جزء من النظام يكون مستقل قدر الامكان. لو غيرتي جزء، ما تتاثر باقي الاجزاء
• High Cohesion (تماسك عالي): كل كلاس يسوي شيء واحد بس ويسويه زين. مو كلاس واحد يسوي كل شيء
• Separation of Concerns (فصل الاهتمامات): كل طبقة في النظام مسؤولة عن شيء محدد

نمط MVC

MVC (Model-View-Controller) من اشهر انماط التصميم وتستخدمه اغلب التطبيقات الحديثة. الفكرة بسيطة: تفصلين البيانات عن الواجهة عن المنطق.

• Model (النموذج): البيانات ومنطق التعامل معها. مثلا كلاس Student اللي يتعامل مع قاعدة البيانات
• View (العرض): الواجهة اللي يشوفها المستخدم. الصفحات والازرار والنماذج
• Controller (المتحكم): الوسيط بين Model و View. يستقبل طلبات المستخدم ويمررها للنموذج ويعيد النتيجة للعرض

مثال عملي: طالبة تفتح صفحة جدولها الدراسي

1. الطالبة تضغط “عرض الجدول” ← View ترسل الطلب
2. Controller يستقبل الطلب ويطلب البيانات من Model
3. Model يجيب الجدول من قاعدة البيانات
4. Controller يرسل البيانات لـ View
5. View تعرض الجدول للطالبة بشكل مرتب

انماط تصميم اخرى (Design Patterns)

في CS 385 غالبا تتعرفين على بعض الانماط الكلاسيكية:

• Singleton: كلاس ينشئ نسخة واحدة فقط. مفيد لاشياء مثل اتصال قاعدة البيانات
• Observer: عناصر تراقب عنصر ثاني وتتفاعل لما يتغير. مثل الاشعارات
• Factory: بدل ما تنشئين كائنات مباشرة بـ new، تستخدمين دالة تنشئها لك. مفيد لما يكون عندك انواع مختلفة

قاعدة عملية: لما تصممين نظام، اسالي نفسك “لو احتجت اغير شيء بعد سنة، كم جزء من الكود لازم اعدل؟” لو الجواب “اجزاء كثيرة”، تصميمك فيه مشكلة. التصميم الجيد يخليك تغيرين جزء واحد بدون ما تلمسين الباقي.

6. الاختبار (Software Testing)

الاختبار مو مجرد “تشغلين البرنامج وتشوفين اذا يشتغل”. في هندسة البرمجيات، الاختبار عملية منهجية بمستويات مختلفة وتقنيات محددة. لو قرأتي اساسيات هندسة البرمجيات راح تلاقين ملخص جيد عن هذا الموضوع.

مستويات الاختبار

1. اختبار الوحدة (Unit Testing): تختبرين كل دالة او كلاس لحاله. اصغر وحدة ممكنة. لو عندك دالة تحسب المعدل، تجربينها بقيم مختلفة وتتاكدين ان النتيجة صحيحة.

// مثال اختبار وحدة
public void testCalculateGPA() {
    Student s = new Student("نورة", 441001234);
    s.addGrade("CS385", 4.0);
    s.addGrade("CS212", 3.5);

    double expected = 3.75;
    double actual = s.calculateGPA();

    assert expected == actual : "المعدل المتوقع 3.75 لكن النتيجة " + actual;
}

2. اختبار التكامل (Integration Testing): تختبرين كيف الوحدات تشتغل مع بعض. مثلا: هل نظام التسجيل يتواصل صح مع قاعدة البيانات؟ ممكن كل وحدة تشتغل لحالها زين، لكن لما تشتغل مع غيرها تطلع مشاكل.

3. اختبار النظام (System Testing): تختبرين النظام كامل كوحدة واحدة. تشوفين هل كل الاجزاء مع بعض تحقق المتطلبات المطلوبة.

4. اختبار القبول (Acceptance Testing): العميل او المستخدم يختبر النظام ويقرر هل يلبي احتياجاته ولا لا. هذا اخر اختبار قبل التسليم.

انواع اخرى مهمة

• Black Box Testing: تختبرين بدون ما تشوفين الكود الداخلي. تركزين على المدخلات والمخرجات بس
• White Box Testing: تختبرين وانتي شايفة الكود. تتاكدين ان كل مسار (path) في الكود متغطي
• Regression Testing: بعد ما تعدلين شيء في الكود، تعيدين كل الاختبارات السابقة تتاكدين ان التعديل ما كسر شيء ثاني

تذكري قاعدة مهمة: كل ما اكتشفتي الخطا بدري، كل ما كان اصلاحه ارخص واسهل. خطا تكتشفينه في مرحلة المتطلبات يكلف دقائق لاصلاحه. نفس الخطا لو اكتشفتيه بعد ما النظام اشتغل عند المستخدمين ممكن يكلف اسابيع عمل. عشان كذا الاختبار يبدا من اول المشروع مو في النهاية بس.

7. ادارة المشاريع والتحكم بالاصدارات

اخر موضوع رئيسي في CS 385 وهو من اهمها عمليا. كيف تديرين مشروع برمجي مع فريق بدون ما تضيعون.

التحكم بالاصدارات (Version Control) مع Git

Git هي الاداة الاساسية اللي يستخدمها كل مطور في العالم للتحكم بالاصدارات. لو ما تعرفين Git، راجعي دليل Git الشامل عندنا.

ليش Git ضروري؟

• تحفظين نسخة من الكود في كل مرحلة. لو صار شيء غلط، ترجعين لنسخة سابقة
• كل وحدة في الفريق تشتغل على نسختها (branch) بدون ما تتعارض مع الباقيات
• تقدرين تشوفين مين عدلت ايش ومتى
• الشركات كلها تستخدمه. لو ما تعرفينه، ما راح تعدين المقابلة الوظيفية

اوامر Git الاساسية:

git init                  # تبدين مشروع جديد
git add .                 # تضيفين الملفات للتتبع
git commit -m "رسالة"     # تحفظين التعديلات
git branch feature-login  # تنشئين فرع جديد
git checkout feature-login # تنتقلين للفرع
git merge feature-login   # تدمجين الفرع مع الرئيسي
git push                  # ترفعين التعديلات على السيرفر
git pull                  # تنزلين اخر التعديلات من السيرفر

تنسيق العمل الجماعي

لما تشتغلين مع فريق، التنظيم كل شيء:

• توزيع المهام: كل وحدة تعرف بالضبط ايش مسؤوليتها. استخدمي ادوات مثل Trello او Jira
• التواصل اليومي: Daily Standup حتى لو كان على واتساب. كل وحدة تقول ايش سوت وايش بتسوي
• مراجعة الكود (Code Review): قبل ما يندمج اي كود، وحدة ثانية تراجعه. هذا يقلل الاخطاء ويحسن جودة الكود
• الفروع (Branches): كل ميزة جديدة في فرع مستقل. ما احد تشتغل على الفرع الرئيسي مباشرة

مخطط جانت (Gantt Chart)

مخطط جانت يوضح الجدول الزمني للمشروع بصريا. كل مهمة لها بداية ونهاية، وتقدرين تشوفين المهام المتوازية والمهام اللي تعتمد على بعض.

المهمة	الاسبوع 1	الاسبوع 2	الاسبوع 3	الاسبوع 4	الاسبوع 5
جمع المتطلبات	████	████
تصميم النظام		████	████
تنفيذ الواجهة			████	████
تنفيذ قاعدة البيانات			████	████
الاختبار				████	████
التوثيق					████

ضمان الجودة (Quality Assurance)

ضمان الجودة يختلف عن الاختبار. الاختبار يكتشف الاخطاء، لكن ضمان الجودة يمنعها من الاساس:

• معايير الكود (Coding Standards): الفريق كله يتبع نفس الطريقة في كتابة الكود. تسمية المتغيرات، المسافات، التعليقات
• مراجعة الكود (Code Review): قبل ما يندمج اي كود، شخص ثاني يراجعه
• التكامل المستمر (CI/CD): كل ما حد سوت push، الاختبارات تشتغل تلقائيا. لو فيه اختبار فشل، ما يندمج الكود
• التوثيق: كل قرار تصميمي لازم يتوثق. لو سالتك بعد شهر “ليش سويتي كذا؟” لازم يكون عندك اجابة مكتوبة

اخطاء شائعة في CS 385

خطة مذاكرة CS 385

ربط المادة بمشروع التخرج

CS 385 مو مادة تعدينها وتنسينها. هي بالحرف الواحد خارطة الطريق لمشروع التخرج. كل موضوع في المادة له تطبيق مباشر:

• المتطلبات: مشروع التخرج يبدا بتحديد المتطلبات. لو ما تعرفين تكتبين متطلبات واضحة، المشروع يتحول لفوضى
• مخططات UML: المشرفة راح تطلب منك مخططات. Use Case، Class Diagram، وممكن Sequence Diagram. المادة تعلمك ترسمينها صح
• Scrum: قسمي مشروع التخرج لسبرنتات. كل سبرنت سلمي جزء شغال. المشرفة راح تنبهر بالتنظيم
• Git: من اول يوم استخدمي Git في مشروع التخرج. كل تعديل يتسجل. لو صار شيء غلط ترجعين لنسخة سابقة
• الاختبار: ضمني تقرير مشروع التخرج نتائج الاختبارات. هذا يرفع جودة المشروع وتقييمه

لو تحسين انك تحتاجين دعم اضافي في البرمجة او مشروع التخرج، اطلعي على خدمة الدروس الخصوصية في البرمجة اللي نقدمها لطالبات جامعة الاميرة نورة.

خلاصة

مادة CS 385 هندسة البرمجيات بجامعة الاميرة نورة مو مادة حفظ. هي مادة فهم وتطبيق. لو فهمتي المبادئ وطبقتيها على مشاريع حقيقية، المادة تصير ممتعة وتستفيدين منها لسنوات بعد التخرج.

تذكري:

• SDLC هو الاطار العام: كل مشروع يمر بمراحل (تحليل، تصميم، تنفيذ، اختبار، نشر، صيانة)
• Agile و Scrum هم الطريقة المعتمدة اليوم في اغلب الشركات. تعلميهم بالممارسة مو الحفظ
• المتطلبات هي الاساس: لو فهمتيها غلط، كل شيء بعدها غلط
• مخططات UML لغة مشتركة بين المطورين. تمرني على رسمها حتى تصير سهلة
• الاختبار مو خطوة اضافية، هو جزء اساسي من التطوير
• Git ضروري لكل مشروع جماعي ولمشروع التخرج

لو تحسين ان المادة ضاغطتك او عندك مشروع والديدلاين قريب، لا تترددين تطلبين مساعدة. الذكاء انك تطلبين الدعم بدري مو بعد فوات الاوان.