شرح مادة عال 342 (CSC 342) هندسة البرمجيات - جامعة الملك سعود

مادة عال 342 (CSC 342)، هندسة البرمجيات (Software Engineering)، هي اللحظة اللي تتحول فيها من طالب يحل تمارين برمجية الى مهندس برمجيات يفكر في النظام كامل. الفرق في الزاوية: قبل عال 342 السؤال كان “كيف اكتب كود يحل المسالة؟”، بعدها يصير “كيف ابني نظام يخدم 50 الف مستخدم، يشتغل عليه فريق من 8 مطورين، ويستمر 5 سنوات بدون ما ينهار؟”.

هذي الزاوية بالذات يبحث عنها سوق العمل السعودي. اول سؤال في المقابلة الفنية في Saudi Aramco Digital او STC او شركة ناشئة مثل Tabby هو “احكي لنا عن مشروع اشتغلت فيه ضمن فريق” — وعال 342 هي اللي تعطيك هذا الجواب.

ليش عال 342 تستحق وقتك ومجهودك

في خطة قسم علوم الحاسب بجامعة الملك سعود، عال 342 تحدد مسارك المهني اكثر من اي مادة ثانية:

• تميزك عن مجرد “كاتب كود”: كثير من الخريجين يعرفون يكتبون كود، قليل منهم يعرف يصمم نظام. الفرق في الراتب بين المهندسين والمبرمجين فقط واضح في سوق الرياض وجدة
• بوابتك لمشروع التخرج: كل وثيقة تكتبها هنا (SRS، Class Diagrams، خطة الاختبار) راح تكتبها مرة ثانية في عال 496. لو اتقنتها هنا، المشروع يصير ترجمة مو اختراع
• اللغة المشتركة بين المطورين: UML و Agile و SOLID مصطلحات تسمعها يوميا في اي شركة تقنية، وتطبق على عال 212 في صورة Class Diagrams حقيقية

نظرة عامة على محتوى عال 342

الاسابيع	الموضوع	المخرجات المتوقعة
1	مقدمة: ما هي هندسة البرمجيات؟	فهم الفرق بين البرمجة والهندسة، انواع الانظمة
2	دورة حياة تطوير البرمجيات (SDLC)	استيعاب المراحل الست واهداف كل مرحلة
3-4	نماذج العمليات (Process Models)	المقارنة بين Waterfall، V-Model، Iterative، Spiral، Agile
5-6	تحليل المتطلبات	كتابة متطلبات وظيفية وغير وظيفية، هيكل وثيقة SRS
7-8	مخططات UML (الجزء الاول)	Use Case Diagram، Class Diagram
9	اختبار نصفي	يغطي الاسابيع 1-8
10	UML (الجزء الثاني)	Sequence Diagram، Activity Diagram
11	تصميم البرمجيات	Modularity، Cohesion، Coupling، مبادئ SOLID
12	انماط التصميم (Design Patterns)	Singleton، Factory، Observer، Strategy
13	اختبار البرمجيات	Unit، Integration، System، Acceptance، TDD
14	الجودة والصيانة	Refactoring، Technical Debt، Code Smells
15	تسليم المشروع ومراجعة شاملة	عرض المشروع امام الدكتور

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

SDLC هي الخريطة الكبرى لاي مشروع برمجي. الفرق بين النماذج هو كيف ينظمها ومتى يكرر منها وايها يدمج.

المراحل الست لاي SDLC

1. التخطيط (Planning): تحديد نطاق المشروع، الميزانية، الفريق، والجدول الزمني. هذي المرحلة تجاوب على “هل المشروع جدوي؟”
2. تحليل المتطلبات (Requirements Analysis): فهم ايش يحتاجه العميل والمستخدمون. مخرجها وثيقة SRS
3. التصميم (Design): تحويل المتطلبات الى تصميم تقني. مخرجاتها مخططات UML ووثيقة التصميم المعمارية
4. التنفيذ (Implementation): كتابة الكود الفعلي حسب التصميم
5. الاختبار (Testing): التحقق من ان النظام يعمل صح ويلبي المتطلبات
6. النشر والصيانة (Deployment & Maintenance): تسليم النظام واصلاح الاخطاء واضافة ميزات بعد الاطلاق

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

2. نماذج العمليات (Process Models)

النماذج تختلف في كيفية ترتيب وتكرار مراحل SDLC. كل نموذج له بيئته المناسبة.

الشلال (Waterfall)

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

مناسب لـ: انظمة الطيران، الاجهزة الطبية، الانظمة الحكومية ذات المتطلبات الثابتة.

غير مناسب لـ: اي مشروع متطلباته ممكن تتغير، وهذا تقريبا 90% من مشاريع اليوم.

V-Model (نموذج V)

تطوير لـ Waterfall بحيث كل مرحلة تطوير لها مرحلة اختبار مقابلة لها. المتطلبات تقابلها Acceptance Tests، التصميم العالي يقابله System Tests، التصميم التفصيلي يقابله Integration Tests، والكود يقابله Unit Tests.

الميزة: الاختبار مخطط له من البداية، مش شي بنسواه في الاخر.

Iterative (التكراري)

تبني النظام على دفعات (iterations). كل دفعة تضيف ميزات جديدة لنسخة شغالة. مفيد لما المتطلبات الكاملة غير واضحة من البداية.

Spiral (الحلزوني)

يدمج Iterative مع تحليل المخاطر. كل دورة تبدا بـ: تحديد الاهداف، تحليل المخاطر، تطوير، ثم تخطيط الدورة التالية. مناسب للمشاريع الكبيرة عالية المخاطر.

Agile / Scrum

عقلية مختلفة كليا. بدل ما تخطط للمشروع كامل، تشتغل على دورات قصيرة (Sprints) مدتها 1-4 اسابيع. كل Sprint تنتج جزء شغال، تعرضه على العميل، تاخذ ملاحظات، وتدخلها في Sprint التالي.

ادوار Scrum: Product Owner (يحدد الاولويات)، Scrum Master (يزيل العوائق)، Development Team (ينفذ).

الاجتماعات الاساسية: Daily Standup (15 دقيقة يوميا)، Sprint Planning (بداية كل Sprint)، Sprint Review (عرض المنجز)، و Sprint Retrospective (مراجعة كيف يحسن الفريق نفسه).

جدول مقارنة شامل

المعيار	Waterfall	V-Model	Iterative	Spiral	Agile
الترتيب	خطي صارم	خطي مع اختبار مقابل	تكراري	تكراري + مخاطر	تكراري سريع
المتطلبات	ثابتة	ثابتة	تتطور	تتطور	متغيرة باستمرار
التوثيق	مفصل جدا	مفصل	متوسط	متوسط	خفيف وعملي
تفاعل العميل	بداية ونهاية	بداية ونهاية	كل تكرار	كل دورة	مستمر
ادارة المخاطر	ضعيفة	متوسطة	جيدة	ممتازة	جيدة
المناسب لـ	انظمة حرجة	انظمة فيها testing مكثف	متطلبات تتطور	مشاريع كبيرة معقدة	تطبيقات حديثة
السرعة	بطيء	بطيء	متوسط	بطيء	سريع

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

اخطر مرحلة في اي مشروع. دراسات Sommerville تقول ان اخطاء المتطلبات اللي تكتشف بعد الاطلاق تكلف 100 ضعف ما تكلفه لو اكتشفت في مرحلة التحليل. هذا الرقم وحده يكفي عشان تاخذ هذي المرحلة بجدية.

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

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

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

• يجب ان يتمكن موظف الاستقبال من تسجيل مريض جديد بادخال الاسم والهوية ورقم الجوال
• يجب ان يتمكن الطبيب من عرض السجل الطبي للمريض شامل الزيارات السابقة والادوية الموصوفة
• يجب ان يولد النظام رقم ملف فريد لكل مريض جديد
• يجب ان يبعث النظام رسالة SMS تذكير للمريض قبل موعد الزيارة بـ 24 ساعة

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

تصف كيف يعمل النظام. خصائص الجودة بدلا من الوظائف.

التصنيفات الاساسية:

الفئة	امثلة
الاداء (Performance)	يستجيب النظام لطلب البحث في اقل من ثانيتين
الامان (Security)	تشفر كلمات المرور باستخدام bcrypt
التوفر (Availability)	يعمل النظام 99.5% من الوقت سنويا
قابلية التوسع (Scalability)	يدعم حتى 5000 مستخدم متزامن
سهولة الاستخدام (Usability)	يكمل المستخدم الجديد التسجيل في اقل من دقيقتين

تقنيات استخراج المتطلبات

ابرز اربع تقنيات تطلع في الاختبار:

• المقابلات (Interviews): جلسة مع اصحاب المصلحة لفهم العمليات والنوايا الحقيقية
• الاستبيانات (Questionnaires): لما تحتاج راي عدد كبير من المستخدمين بسرعة
• الملاحظة (Observation): تراقب المستخدمين وهم يستخدمون النظام الحالي وتكتشف متطلبات ما قالوها
• النماذج الاولية (Prototyping): ترسم نسخة بسيطة من الواجهة وتعدلها بحسب ردود فعل المستخدمين

هيكل وثيقة SRS

وثيقة Software Requirements Specification هي العقد بين الفريق التقني والعميل. هيكلها القياسي حسب IEEE 830:

1. مقدمة (Introduction): الغرض، النطاق، المصطلحات، المراجع، نظرة عامة
2. الوصف العام (Overall Description): سياق المنتج، وظائفه الرئيسية، خصائص المستخدمين، القيود
3. المتطلبات المحددة (Specific Requirements): المتطلبات الوظيفية مرقمة، المتطلبات غير الوظيفية، متطلبات الواجهات
4. الملاحق (Appendices): المخططات، النماذج الاولية، قواميس البيانات

لو تبي شرح اعمق لكتابة وثيقة SRS احترافية لمشروعك، راجع دليل كتابة وثيقة SRS لمشروع التخرج.

4. مخططات UML (Unified Modeling Language)

UML لغة بصرية معيارية لنمذجة الانظمة. فيها 14 نوع مخطط، عال 342 تركز على اربعة منهم بشكل اساسي.

Use Case Diagram

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

Class Diagram

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

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

• Aggregation: “يحتوي” ضعيف، الجزء يعيش بدون الكل (قسم يحتوي اساتذة)
• Composition: “يحتوي” قوي، الجزء يموت لو الكل مات (جامعة تحتوي اقسام)
• Inheritance: “هو نوع من” (سهم مفتوح ابيض)
• Dependency: يستخدم مؤقتا (خط منقط)
• Multiplicity: الارقام على الخط (1، 0..1، 1..*، *)

رموز الوصول: + للـ public، - للـ private، # للـ protected. متى تستخدمه: في مرحلة التصميم لتوثيق بنية النظام قبل الكود.

Sequence Diagram

يوضح ترتيب التفاعلات بين الكائنات في سيناريو واحد محدد. زمني، يقرا من فوق لتحت. عناصره الرئيسية: Lifelines (خطوط راسية للكائنات)، Activation Bars (نشاط الكائن)، Synchronous Messages (اسهم مملوءة تنتظر الرد)، و Return Messages (منقطة).

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

Activity Diagram

يشبه Flowchart لكن اقوى منه. يوضح تدفق الانشطة والقرارات. عناصره: Initial Node (دائرة سوداء = بداية)، Activity (مستطيل بزوايا دائرية)، Decision (معين = شرط)، Fork/Join (تشعب وتجميع متوازي)، Final Node (دائرة داخل دائرة = نهاية)، و Swimlanes (لتقسيم المسؤوليات).

متى تستخدمه: لنمذجة عمليات الاعمال المعقدة، خصوصا لما فيه خطوات متوازية او قرارات متعددة.

لو تبي تتعمق في رسم مخططات UML بالتفصيل مع امثلة كاملة، اقرا دليل مخططات UML لمشروع التخرج.

5. تصميم البرمجيات: المبادئ الاساسية

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

Modularity, Cohesion, Coupling

ثلاث مفاهيم متشابكة:

• Modularity (الوحدوية): تقسيم النظام الى وحدات صغيرة، كل واحدة مسؤولة عن مهمة محددة وقابلة للاستبدال
• Cohesion (التماسك): كل وحدة تسوي شي واحد بس وتسويه زين. كلاس User ما يفترض يحتوي على sendEmail او calculateTax
• Coupling (الترابط): درجة اعتماد الكلاسات على بعض. كلاس مرتبط بشدة بـ 10 كلاسات ثانية يتكسر بسرعة

القاعدة الذهبية: High Cohesion + Low Coupling.

مبادئ SOLID

خمسة مبادئ اساسية لتصميم كائني التوجه نظيف:

• S — Single Responsibility: الكلاس له سبب واحد للتغيير. كلاس Invoice يحسب الفاتورة، طباعتها وتخزينها لكلاسات ثانية
• O — Open/Closed: مفتوح للامتداد، مغلق للتعديل. تضيف نوع دفع جديد عبر كلاس جديد، مو بتعديل كلاس Payment الموجود
• L — Liskov Substitution: اي كلاس فرعي يستبدل الاب بدون ما يكسر البرنامج. لو Penguin يرث Bird، الكود اللي يستدعي bird.fly() ينكسر مع البطريق
• I — Interface Segregation: الكلاس ما يجبر على تنفيذ دوال ما يحتاجها. واجهة Printer فيها print و scan و fax تجبر طابعة بسيطة على تنفيذ scan و fax بدون داعي
• D — Dependency Inversion: الكلاسات العليا تعتمد على Abstractions، مو التفاصيل. OrderService يعتمد على واجهة PaymentGateway بدل كلاس MadaPayment محدد، عشان تقدر تبدله بـ ApplePay بدون تعديل

6. انماط التصميم (Design Patterns)

انماط التصميم حلول جاهزة لمشاكل تصميم متكررة. مش كود تنسخه، فكرة تطبقها. كتاب “Gang of Four” قسمها لـ 23 نمط في ثلاث فئات.

Singleton (الفردي)

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

public class DatabaseConnection {
    private static DatabaseConnection instance;
    private Connection conn;

    private DatabaseConnection() {
        // اتصال بقاعدة البيانات
    }

    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }
}

Factory Method (المصنع)

تعريف واجهة لانشاء كائنات، لكن تترك القرار للكلاسات الفرعية ايش نوع الكائن المنشاء.

abstract class PaymentFactory {
    abstract Payment create();
}

class MadaFactory extends PaymentFactory {
    Payment create() {
        return new MadaPayment();
    }
}

class ApplePayFactory extends PaymentFactory {
    Payment create() {
        return new ApplePayPayment();
    }
}

Observer (المراقب)

لما يتغير كائن (Subject)، يخطر تلقائيا كل المراقبين. مفيد لانظمة الاشعارات.

interface Observer {
    void update(String event);
}

class StockMonitor {
    private List<Observer> observers = new ArrayList<>();

    public void subscribe(Observer o) {
        observers.add(o);
    }

    public void priceChanged(String stock) {
        for (Observer o : observers) {
            o.update(stock);
        }
    }
}

Strategy (الاستراتيجية)

اختيار خوارزمية مختلفة وقت التشغيل. مثلا: نفس الكلاس Sorter يبدل بين QuickSort و MergeSort حسب حجم البيانات، عبر واجهة مشتركة SortStrategy. مفيد لخيارات الدفع المتعددة، خوارزميات التشفير، او طرق الترتيب.

7. اختبار البرمجيات (Software Testing)

الاختبار ليس “تشغيل البرنامج وشوفه يشتغل”. هو نظام منهجي للتاكد من جودة النظام.

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

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

@Test
public void testCalculateDiscount() {
    Order order = new Order(1000.0);
    order.applyCoupon("SAVE20");
    assertEquals(800.0, order.getTotal(), 0.01);
}

Integration Testing (اختبار التكامل): يختبر كيف تتعاون الوحدات مع بعض. مثلا: هل خدمة الطلبات تتواصل صح مع خدمة الدفع وقاعدة البيانات؟

System Testing (اختبار النظام): يختبر النظام كاملا في بيئة شبيهة بالانتاج. يتحقق من المتطلبات الوظيفية وغير الوظيفية.

Acceptance Testing (اختبار القبول): يقوم به العميل او المستخدم النهائي. اخر اختبار قبل التسليم الرسمي.

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

التقنية	الفكرة	متى تستخدمها
Black-Box	اختبار من خلال المدخلات والمخرجات بدون معرفة الكود	اختبار النظام والقبول
White-Box	اختبار مع معرفة بنية الكود الداخلية	اختبار الوحدة
Gray-Box	معرفة جزئية بالكود	اختبار التكامل
Regression	اعادة الاختبارات بعد تعديل الكود للتاكد ما انكسر شي	بعد كل تعديل

Test-Driven Development (TDD)

اسلوب تطوير تكتب فيه الاختبار قبل الكود. الدورة:

1. Red: اكتب اختبار يفشل (لان الكود ما كتب بعد)
2. Green: اكتب اقل كود ممكن يخلي الاختبار ينجح
3. Refactor: حسن الكود بدون كسر الاختبار

فوائد TDD:

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

مفهوم Code Coverage

نسبة الكود المغطى بالاختبارات. مثلا 80% Coverage تعني 80% من اسطر الكود ينفذها اختبار واحد على الاقل. الهدف عادة 70-90%، 100% غير عملي وغير ضروري.

8. جودة البرمجيات والصيانة

اخر فصل يربط كل ما سبق بالمستقبل: ما الذي يحدث للنظام بعد الاطلاق؟

Refactoring و Code Smells

Refactoring هو تحسين بنية الكود بدون تغيير سلوكه: الكود يصير اوضح واسهل قراءة، لكن المخرجات تبقى نفسها. تعمله لما تشوف Code Smell — اشارات على كود يحتاج اعادة هيكلة:

Smell	الوصف
Long Method	دالة اطول من 20 سطر
Large Class	كلاس فيه 500+ سطر او 30+ دالة
Duplicate Code	نفس الكود مكرر في اكثر من مكان
Long Parameter List	دالة فيها 5+ بارامترات
Magic Numbers	ارقام في الكود بدون تفسير

اشهر تقنيات Refactoring: Extract Method (قسم دالة طويلة)، Rename Variable (اسماء وصفية)، Extract Class (اخراج جزء من كلاس)، و Replace Magic Number بثابت اسمه واضح.

Technical Debt والصيانة

كل حل سريع وغير مثالي تتبناه اليوم تستلفه من المستقبل، وتدفع الفائدة لاحقا في صورة وقت اطول للتعديل واخطاء اكثر. خصص وقت ثابت كل Sprint لتقليل الدين التقني.

انواع الصيانة الاربعة: Corrective (اصلاح اخطاء)، Adaptive (تكييف مع بيئة جديدة)، Perfective (تحسين الاداء او اضافة ميزات)، Preventive (منع مشاكل مستقبلية). دراسة Sommerville تشير ان 60-80% من تكلفة البرنامج تذهب للصيانة، مش للتطوير الاولي. هذا يفسر ليش الجودة من البداية مهمة.

9. اخطاء شائعة في عال 342 ونصائح للاختبار

10. خطة مذاكرة عملية لـ عال 342

11. ربط عال 342 بمسارك الاكاديمي

عال 212 تراكيب البيانات اعطتك الكلاسات والكائنات، وعال 342 تعلمك كيف تنظمها في نظام كامل. بعدها تجي عال 471 (قواعد البيانات المتقدمة)، عال 462 (امن المعلومات)، وعال 478 (الحوسبة السحابية) — كلها تطبق ما درسته هنا.

في مشروع التخرج (عال 496/497) راح تكتب كل وثيقة من جديد بنطاق اوسع. لو اتقنت كتابة SRS و مخططات UML في 342، مشروع التخرج يصير توسعة مو اختراع من جديد. وفي سوق العمل السعودي (Saudi Aramco، STC، SABIC، شركات Vision 2030)، Scrum و Code Review و CI/CD ما تتعلمها اول مرة في الشركة — تعرفها قبلها وتدخل جاهز.

خلاصة

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

اذا اخذت من المادة شي واحد، خل يكون: الجودة تبدا من المتطلبات، مو من الكود. كل خطا في فهم المتطلبات يكلف اضعاف ما يكلف خطا في الكود. افتح Sommerville، اختر مشروع بسيط (تطبيق ادارة مهام مثلا)، واكتب له SRS كامل وارسم له UML قبل ما تكتب اول سطر كود.