شرح مادة CPCS 351 هندسة البرمجيات 1 - جامعة الملك عبدالعزيز

مادة CPCS 351، هندسة البرمجيات 1 (Software Engineering I). هذي المادة نقطة تحوّل حقيقية في مسارك الأكاديمي. بعد ثلاث سنوات من البرمجة الفردية، فجأة يُطلب منك تشتغل ضمن فريق، تكتب وثائق، ترسم مخططات UML، وتخطط لمشروع كامل قبل ما تكتب سطر كود واحد.

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

ليش مادة CPCS 351 مختلفة عن كل ما درسته قبلها؟

في مواد البرمجة السابقة، النجاح كان يعتمد عليك وحدك. تكتب كود، يشتغل، تاخذ الدرجة. في CPCS 351 الموضوع مختلف كليا:

• العمل الجماعي إلزامي: معظم مشاريع المادة تنفذ بفريق من 3 إلى 5 طلاب. لو الفريق ما ينسّق، المشروع يفشل
• التوثيق بنفس أهمية الكود: مستندات المتطلبات ومخططات UML جزء من تقييمك مثل الكود تماما
• التفكير قبل البرمجة: المادة تعلّمك إنك لازم تفهم المشكلة كاملا وتصممها قبل ما تكتب أي شيء
• ارتباطها بمشروع التخرج: كل شيء تتعلمه في CPCS 351 ستحتاجه في CPCS 498/499

للاطلاع على المفاهيم العامة لهندسة البرمجيات كمجال، اقرأ دليلنا لأساسيات هندسة البرمجيات.

نظرة عامة على المادة، الجدول الأسبوعي

المادة تمتد على 15 أسبوعا وتغطي المحاور التالية بالترتيب:

الأسابيع	الموضوع	المحتوى الرئيسي
1-2	مقدمة في هندسة البرمجيات	SDLC، أهمية المجال، أنواع الأنظمة
3-4	نماذج تطوير البرمجيات	Waterfall، Incremental، Spiral، Agile
5-6	هندسة المتطلبات	المتطلبات الوظيفية وغير الوظيفية، SRS، Use Cases
7-8	مخططات UML (الجزء الأول)	Use Case Diagram، Class Diagram
9-10	مخططات UML (الجزء الثاني)	Sequence Diagram، Activity Diagram
11	منهجية Agile وScrum	Sprints، Product Backlog، Scrum Roles
12	تصميم البرمجيات	أنماط التصميم، Design Patterns
13-14	اختبار البرمجيات	Unit Testing، Integration، System Testing
15	إدارة المشاريع + مراجعة	Project Planning، Risk Management، مراجعة

1. دورة حياة تطوير البرمجيات، SDLC

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

المراحل الأساسية لأي SDLC

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

الفرق بين نماذج التطوير هو في كيفية تنظيم هذه المراحل وترتيبها وتكرارها.

2. نماذج تطوير البرمجيات، مقارنة بين النماذج

هذا الموضوع من أكثر ما يخرج في الاختبارات. لازم تعرف كل نموذج وتقدر تقارن بينها.

النموذج	طبيعة التطوير	متى تستخدمه	أكبر ميزة	أكبر عيب
Waterfall	خطي (مرحلة بعد مرحلة)	متطلبات ثابتة وواضحة من البداية	بسيط وسهل التخطيط	لا يتحمل تغيير المتطلبات
Incremental	يبني النظام على دفعات	لما تريد تسليم أجزاء مبكرا	المستخدم يرى نتائج مبكرة	قد يصعب دمج الأجزاء لاحقا
Spiral	يدمج التكرار مع تحليل المخاطر	مشاريع كبيرة وعالية المخاطر	يعالج المخاطر بشكل منهجي	معقد وتكلفته عالية
Agile	تكراري مرن وسريع	متطلبات تتغير أو غير مكتملة	مرونة عالية وتسليم متكرر	يحتاج فريق منظم ومتواصل

نموذج الشلال، Waterfall

الشلال هو أبسط النماذج وأقدمها. كل مرحلة تكتمل قبل ما تبدأ التالية. مثل بناء بيت: ما تبني الجدران قبل ما تنتهي من الأساس.

متى يكون Waterfall منطقيا؟

• لما المتطلبات واضحة ومحددة ولن تتغير (مثل أنظمة الدفاع أو أنظمة حكومية بمواصفات صارمة)
• لما الفريق يشتغل عن بعد ويحتاج وثائق كاملة للتنسيق
• لما العقد يلزمك تسليم مواصفات واضحة في كل مرحلة

الإشكالية الحقيقية في Waterfall: العميل كثيرا ما يكتشف متطلبات جديدة بعد رؤية النظام الكامل. في Waterfall، التعديل بعد مرحلة التصميم مكلف جدا.

منهجية Agile وScrum

Agile مش نموذج واحد، هو فلسفة تقوم على مبادئ أربعة معلنة في “البيان الأجايل” (Agile Manifesto):

1. الأفراد والتفاعل أهم من العمليات والأدوات
2. البرنامج العامل أهم من التوثيق الشامل
3. التعاون مع العميل أهم من التفاوض على العقد
4. الاستجابة للتغيير أهم من التمسك بالخطة

Scrum هو أشهر إطار عمل يطبّق مبادئ Agile. يعمل على دورات قصيرة تسمى Sprint (عادة أسبوعان إلى أربعة أسابيع). في كل Sprint يختار الفريق مجموعة من المهام من قائمة المنتج (Product Backlog) وينجزها.

أدوار Scrum الثلاثة:

• Product Owner: يمثل العميل، يحدد الأولويات، يمتلك Product Backlog
• Scrum Master: يتأكد الفريق يطبّق Scrum صح، يزيل العوائق
• Development Team: الفريق اللي ينفّذ العمل فعليا

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

هندسة المتطلبات هي عملية اكتشاف وتوثيق ما يحتاجه النظام. هذا الجزء من أهم ما يُختبر في الكورس ومن أهم ما ستحتاجه في مشروع التخرج.

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

تصف ماذا يفعل النظام. كل متطلب وظيفي يصف وظيفة أو سلوك محدد من النظام.

أمثلة في نظام متجر إلكتروني:

• يجب أن يتمكن المستخدم من تصفح الكتالوج وتصفيته حسب الفئة والسعر
• يجب أن يتمكن المستخدم من إضافة منتجات إلى سلة التسوق
• يجب أن يتمكن المشرف من إضافة منتجات جديدة وتعديل أسعارها
• يجب أن يولّد النظام فاتورة تلقائية عند إتمام الطلب

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

تصف كيف يعمل النظام، أي جودة أداءه. هي قيود وخصائص تحكم طريقة عمل النظام لا وظائفه.

أمثلة:

• الأداء (Performance): يجب أن يستجيب النظام لكل طلب في أقل من ثلاث ثوان
• الأمان (Security): يجب تشفير بيانات المستخدمين ببروتوكول TLS
• التوافر (Availability): يجب أن يعمل النظام 99.9% من الوقت
• قابلية التوسع (Scalability): يجب أن يدعم النظام حتى 10,000 مستخدم متزامن

وثيقة مواصفات متطلبات النظام، SRS

وثيقة SRS (Software Requirements Specification) هي الوثيقة الرسمية اللي تجمع كل المتطلبات. تتضمن عادة:

• وصف عام للنظام وهدفه
• قائمة المتطلبات الوظيفية مرقّمة
• قائمة المتطلبات غير الوظيفية
• حالات الاستخدام (Use Cases)
• القيود والافتراضات والتبعيات

4. مخططات UML، لغة النمذجة الموحدة

UML (Unified Modeling Language) هي لغة بصرية لنمذجة الأنظمة. تتضمن أكثر من 14 نوع مخطط، لكن في CPCS 351 ستركز على أربعة رئيسية.

المخطط	ما يصفه	متى تستخدمه
Use Case Diagram	تفاعل المستخدمين مع النظام	في مرحلة المتطلبات لفهم الوظائف
Class Diagram	بنية الكلاسات وعلاقاتها	في مرحلة التصميم الهيكلي
Sequence Diagram	تسلسل الرسائل بين الكائنات في سيناريو معين	لتوضيح كيفية تنفيذ عملية معينة
Activity Diagram	تدفق العمليات والقرارات	لوصف الخوارزميات والعمليات التجارية

Use Case Diagram

مخطط حالات الاستخدام يوضّح من يستخدم النظام وبـماذا يتفاعل معه.

العناصر الأساسية:

• Actor (الممثل): شخص أو نظام خارجي يتفاعل مع النظامك. يُرسم كشكل إنسان صغير
• Use Case (حالة الاستخدام): وظيفة يؤديها النظام. تُرسم كبيضاوي
• System Boundary (حدود النظام): مستطيل يحيط بكل حالات الاستخدام ويوضح ما هو داخل النظام
• Association: خط يصل الممثل بحالة الاستخدام
• Include: علاقة تعني إن حالة استخدام تتضمن حالة أخرى دائما
• Extend: علاقة تعني إن حالة استخدام قد تُضاف لحالة أخرى في ظروف معينة

مثال لنظام إدارة مكتبة:

[Librarian] ---> (Add Book)
[Librarian] ---> (Remove Book)
[Member] ---> (Search Book)
[Member] ---> (Borrow Book)
(Borrow Book) --include--> (Check Availability)
(Return Book) --extend--> (Pay Fine)

Class Diagram

مخطط الكلاسات يوضّح بنية النظام الثابتة: الكلاسات وخصائصها ودوالها وعلاقاتها ببعض.

العلاقات الأساسية في Class Diagram:

• Association (ارتباط): علاقة عامة بين كلاسين (خط مستقيم)
• Aggregation (تجميع): “يحتوي” لكن بشكل مستقل (خط بمعين مفتوح)
• Composition (تركيب): “يحتوي” وجوده مرتبط بالكلاس الأب (خط بمعين مغلق)
• Inheritance (وراثة): “هو نوع من” (خط بسهم مفتوح)
• Dependency (تبعية): يستخدم مؤقتا (خط منقط بسهم)

تدوين خصائص الكلاس في UML:

+ public
- private
# protected

Sequence Diagram

مخطط التسلسل يوضّح كيف تتفاعل الكائنات مع بعضها في سيناريو محدد وبـترتيب زمني.

العناصر:

• Objects (الكائنات): في الأعلى على شكل مستطيلات
• Lifelines (خطوط الحياة): خطوط منقطة رأسية تمتد لأسفل من كل كائن
• Messages (الرسائل): أسهم أفقية بين الكائنات تمثل استدعاءات الدوال
• Activation Bar (شريط التفعيل): مستطيل رفيع على خط الحياة يوضح متى الكائن نشط

مثال: سيناريو “تسجيل الدخول” في نظام:

User -> UI: enterCredentials(username, password)
UI -> AuthService: login(username, password)
AuthService -> Database: findUser(username)
Database --> AuthService: user object
AuthService --> UI: success / failure
UI --> User: show dashboard / show error

Activity Diagram

مخطط النشاط يشبه مخطط التدفق (Flowchart) لكنه أكثر قوة. يُستخدم لوصف تدفق العمليات وقرارات البرنامج أو العملية التجارية.

العناصر:

• Initial Node: دائرة سوداء (نقطة البداية)
• Activity: مستطيل بزوايا دائرية يمثل عمل أو نشاط
• Decision Node: معين (قرار: نعم أو لا)
• Fork/Join: شريط أسود عريض (تشعّب متوازٍ أو دمج)
• Final Node: دائرة سوداء داخل دائرة (نهاية)

5. أنماط التصميم، Design Patterns

أنماط التصميم (Design Patterns) هي حلول جاهزة وموثّقة لمشاكل تصميم تتكرر كثيرا في البرمجيات. مش كود جاهز تنسخه، بل فكرة تطبّقها في سياقك.

قسّمها الكتاب الشهير “Gang of Four” إلى ثلاث فئات:

أنماط الإنشاء، Creational Patterns

تتعامل مع كيفية إنشاء الكائنات.

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

Factory Method: تعريف واجهة لإنشاء الكائنات ولكن تترك قرار أي نوع يُنشأ للكلاسات الفرعية. مثال: نظام إنتاج أشكال هندسية مختلفة (دائرة، مثلث، مربع) دون أن يعرف الكود الرئيسي النوع الدقيق مسبقا.

أنماط البنية، Structural Patterns

هذه الأنماط تنظّم العلاقات بين الكلاسات وتركيبها معا.

Adapter: يسمح لواجهتين غير متوافقتين بالعمل معا. مثل محوّل الكهرباء الذي يجعل قابس أمريكي يعمل في مقبس أوروبي.

Facade: يوفر واجهة مبسطة لنظام معقد. مثال: نظام Home Theatre يضم تليفزيون وساوند سيستم وDVD player، الـ Facade يوفر زر واحد “شغّل فيلم” يتحكم في الكل.

أنماط السلوك، Behavioral Patterns

هنا يتحدد كيف تتواصل الكائنات وتوزّع المسؤوليات فيما بينها.

Observer: لما يتغير كائن (Subject)، يُخطر تلقائيا كل الكائنات التي تراقبه (Observers). مثال: في تطبيق أسهم، كل مراقب (شاشة عرض السعر، إشعار الهاتف) يتحدّث تلقائيا لما يتغير سعر السهم.

Strategy: يسمح باختيار خوارزمية مختلفة وقت التشغيل. مثال: نظام دفع يدعم Visa وMada وApple Pay، كل طريقة دفع هي Strategy منفصلة يمكن اختيارها دون تعديل بقية الكود.

6. اختبار البرمجيات، Software Testing

الاختبار مش مجرد “جرّب وشوف”. هو عملية منهجية للتحقق من أن النظام يعمل كما يجب.

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

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

// مثال على Unit Test بـ JUnit
@Test
public void testCalculateGPA() {
    Student student = new Student("أحمد", 3);
    student.addGrade(90);
    student.addGrade(85);
    student.addGrade(95);
    assertEquals(4.5, student.calculateGPA(), 0.1);
}

اختبار التكامل، Integration Testing: يختبر كيف تعمل الوحدات معا. بعد ما تتأكد كل وحدة تعمل لحالها، تتأكد إنها تعمل مع بعض. مثال: اختبار أن وحدة تسجيل الدخول تتصل صح بقاعدة البيانات.

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

اختبار القبول، Acceptance Testing: يؤديه العميل أو المستخدم للتأكد إن النظام يلبي احتياجاتهم قبل القبول الرسمي.

تقنيات الاختبار

اختبار الصندوق الأبيض، White-Box Testing: المختبر يعرف الكود من الداخل. يصمم حالات اختبار تغطي كل مسارات الكود الممكنة. يعتمد على معرفة بنية البرنامج.

اختبار الصندوق الأسود، Black-Box Testing: المختبر لا يعرف الكود من الداخل. يختبر النظام فقط من خلال مداخله ومخارجه. يعتمد على المتطلبات.

7. إدارة المشاريع البرمجية، Project Management

هذا القسم يربط كل ما سبق بالإطار الإداري.

تخطيط المشروع

Work Breakdown Structure (WBS): تقسيم المشروع إلى مهام أصغر وأصغر حتى تصل لمهام يمكن تقديرها وتنفيذها. مثل شجرة تبدأ بالمشروع الكامل ثم تتفرع لمراحل ثم مهام ثم مهام فرعية.

Gantt Chart: مخطط زمني يوضح المهام على المحور الأفقي والزمن على المحور الآخر. يساعد على رؤية التسلسل والتوازي بين المهام ومتابعة التقدم.

إدارة المخاطر، Risk Management

كل مشروع يواجه مخاطر. إدارة المخاطر تعني:

1. تحديد المخاطر: ماذا قد يسوء؟ (تأخر أحد أعضاء الفريق، تغيير المتطلبات، مشاكل تقنية)
2. تقييم الاحتمالية والأثر: ما احتمال حدوثه؟ ما تأثيره لو حدث؟
3. خطة التعامل: كيف سنتجنبه؟ وإن حدث كيف سنتعامل معه؟

التحكم في الإصدارات، Version Control

Version Control ليس مجرد نسخ احتياطية. هو أساس العمل الجماعي في أي مشروع برمجي حقيقي.

في سياق CPCS 351، الدكتور قد يشترط استخدام Git وGitHub لإدارة كود المشروع. هذا يعني:

• كل عضو في الفريق يعمل على فرع (Branch) منفصل
• التغييرات تُدمج عبر Pull Requests
• تاريخ كل التعديلات محفوظ ويمكن الرجوع له

للتعمق في Git، اقرأ دليلنا لـ Git والتحكم في الإصدارات.

CPCS 351 وارتباطها بمشروع التخرج

هذا الجانب مهم جدا ولازم تفهمه من أول يوم في المادة.

مشروع التخرج CPCS 498/499 هو تطبيق كامل لكل ما تعلمته في CPCS 351. الفرق الوحيد إن النطاق أكبر والوقت أطول. كل وثيقة، كل مخطط، كل منهجية ستُطلب منك في مشروع التخرج.

ما تتعلمه في CPCS 351 وتحتاجه في 498/499:

• SRS: وثيقة المتطلبات لازم تكتبها لمشروع التخرج قبل أي كود
• Use Case Diagram: لتوضيح وظائف النظام لهيئة التحكيم
• Class Diagram: لتوثيق تصميم نظامك
• Sequence Diagrams: لشرح كيف تعمل أهم العمليات
• منهجية التطوير: تحتاج تختار إذا تتبع Waterfall أو Agile وتبرر اختيارك
• خطة الاختبار: تحتاج توثق كيف اختبرت نظامك

للاستعداد لمشروع التخرج من الآن، اقرأ دليلنا لكيفية كتابة خطة مشروع التخرج.

كيف تنجح في مشروع CPCS 351

أنواع أسئلة الاختبارات في CPCS 351

الأدوات العملية للمادة

أدوات رسم UML

• draw.io (diagrams.net): مجاني وسهل، يعمل في المتصفح مباشرة. الخيار الأول للطلاب
• Lucidchart: واجهة أجمل، النسخة المجانية تكفي للمشاريع الجامعية
• StarUML: برنامج متكامل لرسم UML بتفاصيل أعمق
• PlantUML: تكتب UML كنص وهو يرسمه. مفيد لو تحب كتابة الكود

أدوات إدارة المشروع

• GitHub Projects: مدمج مع GitHub، يتيح إنشاء لوحة Kanban لإدارة المهام
• Trello: بسيط وبصري لإدارة المهام بأسلوب Kanban
• Jira: الأكثر استخداما في الشركات، يدعم Scrum كاملا مع Sprints وBacklog

أدوات الاختبار

• JUnit: إطار Unit Testing للجافا. تكاد لا توجد مادة جامعية تستخدم Java دون JUnit
• Postman: لاختبار API إذا كان مشروعك يتضمن خادم
• Selenium: لاختبار واجهات الويب بشكل تلقائي

نصائح لاستيعاب Agile بدون خبرة عملية

أصعب جزء في CPCS 351 على الطلاب هو فهم Agile وScrum بشكل حقيقي، لأن الفكرة مبنية على خبرة في بيئة عمل فعلية.

إليك طرق تجعل Agile ملموسا:

• طبّقه على مشروع المادة: قسّم مشروعك لـ Sprints حتى لو الدكتور ما طلب. كل أسبوعين ضعوا هدفا محددا
• استخدم لوحة Kanban: على Trello أو GitHub Projects، اعمل أعمدة “To Do” و”In Progress” و”Done” وحرّك المهام فيها
• اعقدوا Daily Standup قصير: حتى لو عبر واتساب، كل عضو يكتب يوميا: ما فعلت أمس، ما سأفعل اليوم، ما يعوقني
• شاهد فيديوهات عن فرق Scrum حقيقية: YouTube فيه محتوى كثير يوضح كيف تعمل فرق Scrum في الشركات

ربط المادة بمسارك الكامل

CPCS 351 ليست مادة معزولة. هي الحلقة التي تربط كل البرمجة السابقة بكل ما يأتي بعدها.

قبلها: CPCS 202 (برمجة 1)، CPCS 203 (OOP)، CPCS 204 (هياكل البيانات). كل هذه المواد أعطتك الأدوات. CPCS 351 تعلّمك كيف تنظّم استخدام هذه الأدوات في مشاريع حقيقية.

بعدها: في CPCS 498/499 ستستخدم كل ما تعلمته هنا. كل خطوة في مشروع التخرج لها أساس في هذه المادة. الطالب الذي أتقن CPCS 351 يصل لمشروع التخرج وعنده خارطة طريق واضحة بينما غيره يتخبّط.

في سوق العمل: فهم SDLC ومنهجيات Agile وUML وعملية متطلبات النظام يميّزك عن مبرمج يكتب كود بدون تخطيط. الشركات التقنية الكبرى في السعودية وخارجها تبحث عن مهندسين يفهمون عملية التطوير الكاملة لا فقط الكود.

خلاصة

مادة CPCS 351 هندسة البرمجيات 1 هي من أكثر المواد التي تُعدّك للحياة المهنية الحقيقية. ما الذي يجب أن تخرج به من هذه المادة؟

• فهم SDLC ونماذج التطوير: تعرف متى تستخدم Waterfall ومتى Agile وليش
• كتابة متطلبات واضحة وقابلة للقياس: مهارة تحتاجها في كل مشروع بقية حياتك المهنية
• رسم وقراءة مخططات UML: Use Case وClass وSequence وActivity Diagrams
• التفكير في الاختبار من أول التصميم: الجودة مش تُضاف في الآخر، تُبنى من البداية
• العمل الجماعي المنظم: توزيع مهام واضح، تواصل منتظم، وأدوات مشتركة

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