هذا المخطط (Solution)
يقدم أفكاراً متقدمة واحترافية جداً في هندسة قواعد البيانات!
لقد نقل التصميم من مستوى "أساسي" إلى مستوى "قابل للتوسع المؤسسي"
إليك تحليلي المعماري لهذا المخطط، مبرزاً نقاط القوة ونقطة واحدة تستحق النقاش:
1. الضربة القاضية
(الوراثة - Supertype/Subtype)
الميزة الأقوى والأكثر ذكاءً في هذا المخطط هي إنشاء جدول Persons.
الفكرة:
بدلاً من تكرار الحقول المشتركة مثل الاسم Name ، وتاريخ الميلاد DateOfBirth ، والجنس Gender ، ورقم الهاتف PhoneNumber ، والبريد Email ، والعنوان Address في كل من جدولي المرضى Patients والأطباء Doctors ، قام بجمعها في "جدول أب" Persons.
الربط: ثم قام بإنشاء جدولي المرضى والأطباء وربطهما بالجدول الأب عبر المفتاح الأجنبي PersonID.
لماذا هذا رائع؟
1. يمنع التكرار نهائياً
(DRY Principle):
قاعدة البيانات أصبحت أنظف.
2. قابلية التوسع (Scalability):
إذا أردت غداً إضافة موظفي استقبال أو ممرضين، لن تضطر لإنشاء جداول ببيانات مكررة، بل ستنشئ جدول Nurses وتربطه بـ Persons.
3. يحل حالات نادرة
(Edge Cases):
ماذا لو مرض الطبيب وأصبح مريضاً في نفس العيادة؟ بهذا التصميم، سيكون له سجل واحد فقط في Persons ، ونربطه بجدول المرضى والأطباء معاً!
2. تحليل العلاقات المعكوسة (نقطة للنقاش)
هناك قرار تصميمي مثير للاهتمام في جدول المواعيد Appointments:
وضع المصمم المفاتيح الأجنبية MedicalRecordID و PaymentID داخل جدول المواعيد Appointments.
رأيي كمهندس نظم:
هذا تصميم صالح برمجياً لتمثيل علاقة (1:1 أو 1:0..1)،
ولكنه يعني أن هذه الحقول ستكون فارغة (NULL)
عند حجز الموعد لأول مرة،
ولن تُملأ إلا بعد إتمام الزيارة والدفع.
التصميم البديل
(الذي ناقشناه سابقاً):
وضع AppointmentID داخل جدول السجلات الطبية والمدفوعات هو الطريقة الأكثر شيوعاً؛ لأن السجل الطبي والدفع هما "كيانات تابعة" (Dependent Entities) للموعد، وتُنشأ بسببه.
كلا الحلين يعمل، لكن وضع المفتاح في الكيان التابع يقلل من حقول الـ NULL في قاعدة البيانات.
3. إدارة الحالات (Status)
لاحظ أنه استخدم نوع البيانات tinyint
لحقل AppointmentStatus.
الميزة: هذا يوفر مساحة كبيرة في قاعدة البيانات وتكون الاستعلامات فيه أسرع.
التطبيق البرمجي:
هذا يعني أنه سيعتمد على الباك اند (Backend) لترجمة هذه الأرقام
مثلاً:
1 = Pending،
2 = Confirmed
باستخدام (Enum Classes)، متخلياً عن فكرة جدول الـ
(Lookup Table)
المنفصل في قاعدة البيانات.
وهو أسلوب متبع جداً ومفضل لدى الكثير من المطورين لتسريع النظام.
بشكل عام، المخطط ممتاز للتدريب ويمثل خطوة متقدمة جداً في التفكير المعماري.
يقدم أفكاراً متقدمة واحترافية جداً في هندسة قواعد البيانات!
لقد نقل التصميم من مستوى "أساسي" إلى مستوى "قابل للتوسع المؤسسي"
إليك تحليلي المعماري لهذا المخطط، مبرزاً نقاط القوة ونقطة واحدة تستحق النقاش:
1. الضربة القاضية
(الوراثة - Supertype/Subtype)
الميزة الأقوى والأكثر ذكاءً في هذا المخطط هي إنشاء جدول Persons.
الفكرة:
بدلاً من تكرار الحقول المشتركة مثل الاسم Name ، وتاريخ الميلاد DateOfBirth ، والجنس Gender ، ورقم الهاتف PhoneNumber ، والبريد Email ، والعنوان Address في كل من جدولي المرضى Patients والأطباء Doctors ، قام بجمعها في "جدول أب" Persons.
الربط: ثم قام بإنشاء جدولي المرضى والأطباء وربطهما بالجدول الأب عبر المفتاح الأجنبي PersonID.
لماذا هذا رائع؟
1. يمنع التكرار نهائياً
(DRY Principle):
قاعدة البيانات أصبحت أنظف.
2. قابلية التوسع (Scalability):
إذا أردت غداً إضافة موظفي استقبال أو ممرضين، لن تضطر لإنشاء جداول ببيانات مكررة، بل ستنشئ جدول Nurses وتربطه بـ Persons.
3. يحل حالات نادرة
(Edge Cases):
ماذا لو مرض الطبيب وأصبح مريضاً في نفس العيادة؟ بهذا التصميم، سيكون له سجل واحد فقط في Persons ، ونربطه بجدول المرضى والأطباء معاً!
2. تحليل العلاقات المعكوسة (نقطة للنقاش)
هناك قرار تصميمي مثير للاهتمام في جدول المواعيد Appointments:
وضع المصمم المفاتيح الأجنبية MedicalRecordID و PaymentID داخل جدول المواعيد Appointments.
رأيي كمهندس نظم:
هذا تصميم صالح برمجياً لتمثيل علاقة (1:1 أو 1:0..1)،
ولكنه يعني أن هذه الحقول ستكون فارغة (NULL)
عند حجز الموعد لأول مرة،
ولن تُملأ إلا بعد إتمام الزيارة والدفع.
التصميم البديل
(الذي ناقشناه سابقاً):
وضع AppointmentID داخل جدول السجلات الطبية والمدفوعات هو الطريقة الأكثر شيوعاً؛ لأن السجل الطبي والدفع هما "كيانات تابعة" (Dependent Entities) للموعد، وتُنشأ بسببه.
كلا الحلين يعمل، لكن وضع المفتاح في الكيان التابع يقلل من حقول الـ NULL في قاعدة البيانات.
3. إدارة الحالات (Status)
لاحظ أنه استخدم نوع البيانات tinyint
لحقل AppointmentStatus.
الميزة: هذا يوفر مساحة كبيرة في قاعدة البيانات وتكون الاستعلامات فيه أسرع.
التطبيق البرمجي:
هذا يعني أنه سيعتمد على الباك اند (Backend) لترجمة هذه الأرقام
مثلاً:
1 = Pending،
2 = Confirmed
باستخدام (Enum Classes)، متخلياً عن فكرة جدول الـ
(Lookup Table)
المنفصل في قاعدة البيانات.
وهو أسلوب متبع جداً ومفضل لدى الكثير من المطورين لتسريع النظام.
بشكل عام، المخطط ممتاز للتدريب ويمثل خطوة متقدمة جداً في التفكير المعماري.
أولاً: الكيانات والخصائص
(Entities & Attributes)
1. جدول الأشخاص (Persons)
PersonID (int):
مفتاح أساسي (PK)
Name (nvarchar(100)): الاسم
DateOfBirth (date):
تاريخ الميلاد
Gender (nvarchar(1)): الجنس
PhoneNumber (nvarchar(20)): رقم الهاتف
Email (nvarchar(100)): البريد الإلكتروني
Address (nvarchar(200)): العنوان
2. جدول المرضى (Patients)
PatientID (int): مفتاح أساسي (PK)
PersonID (int): مفتاح أجنبي (FK)
3. جدول الأطباء (Doctors)
DoctorID (int):
مفتاح أساسي (PK)
PersonID (int): مفتاح أجنبي (FK)
Specialization (nvarchar(100)): التخصص
4. جدول المواعيد (Appointments)
AppointmentID (int):
مفتاح أساسي (PK)
PatientID (int):
مفتاح أجنبي (FK)
DoctorID (int):
مفتاح أجنبي (FK)
AppointmentDateTime (datetime):
تاريخ ووقت الموعد
AppointmentStatus (tinyint):
حالة الموعد
MedicalRecordID (int): مفتاح أجنبي (FK)
PaymentID (int):
مفتاح أجنبي (FK)
5. جدول السجلات الطبية (MedicalRecords)
MedicalRecordID (int): مفتاح أساسي (PK)
VisitDescription (nvarchar(200)):
وصف الزيارة
Diagnosis (nvarchar(200)):
التشخيص
AdditionalNotes (nvarchar(200)):
ملاحظات إضافية
6. جدول الوصفات الطبية (Prescriptions)
PrescriptionID (int):
مفتاح أساسي (PK)
MedicalRecordID (int): مفتاح أجنبي (FK)
MedicationName (nvarchar(100)):
اسم الدواء
Dosage (nvarchar(50)): الجرعة
Frequency (nvarchar(50)):
التكرار
StartDate (date):
تاريخ البدء
EndDate (date):
تاريخ الانتهاء
SpecialInstructions (nvarchar(200)):
تعليمات خاصة
7. جدول المدفوعات (Payments)
PaymentID (int):
مفتاح أساسي (PK)
PaymentDate (date):
تاريخ الدفع
PaymentMethod (nvarchar(50)):
طريقة الدفع
AmountPaid (decimal): المبلغ المدفوع
AdditionalNotes (nvarchar(200)):
ملاحظات إضافية
🔗 ثانياً: العلاقات (Relationships)
بناءً على المفاتيح الأجنبية (Foreign Keys)، يتم ربط الجداول كما يلي:
1. علاقة الأشخاص بالمرضى والأطباء
(Supertype / Subtype)
جدول Persons يمثل الكيان العام (Supertype).
جدول Patients و Doctors يمثلان كيانات فرعية (Subtypes).
الربط يتم عبر:
PersonID → Patients
PersonID → Doctors
كل مريض أو طبيب هو في الأصل "شخص".
2. علاقة المواعيد بالمرضى
جدول Appointments يرتبط بجدول Patients عبر:
PatientID (FK)
العلاقة:
Patient (1) → (M) Appointments
3. علاقة المواعيد بالأطباء
جدول Appointments يرتبط بجدول Doctors عبر:
DoctorID (FK)
العلاقة:
Doctor (1) → (M) Appointments
4. علاقة المواعيد بالسجلات الطبية
جدول Appointments يرتبط بجدول MedicalRecords عبر:
MedicalRecordID (FK)
العلاقة:
Appointment (1) → (1) MedicalRecord (غالبًا)
5. علاقة المواعيد بالمدفوعات
جدول Appointments يرتبط بجدول Payments عبر:
PaymentID (FK)
العلاقة:
Appointment (1) → (1) Payment
6. علاقة الوصفات الطبية بالسجلات الطبية
جدول Prescriptions يرتبط بجدول MedicalRecords عبر:
MedicalRecordID (FK)
العلاقة:
MedicalRecord (1) → (M) Prescriptions
التصميم يطبق Normalization
بشكل ممتاز (تقليل التكرار).
استخدام
Supertype/Subtype
(Persons →
Patients/Doctors).
النظام قابل للتوسعة
(مثلاً إضافة Nurse أو Admin بسهولة)
(Entities & Attributes)
1. جدول الأشخاص (Persons)
PersonID (int):
مفتاح أساسي (PK)
Name (nvarchar(100)): الاسم
DateOfBirth (date):
تاريخ الميلاد
Gender (nvarchar(1)): الجنس
PhoneNumber (nvarchar(20)): رقم الهاتف
Email (nvarchar(100)): البريد الإلكتروني
Address (nvarchar(200)): العنوان
2. جدول المرضى (Patients)
PatientID (int): مفتاح أساسي (PK)
PersonID (int): مفتاح أجنبي (FK)
3. جدول الأطباء (Doctors)
DoctorID (int):
مفتاح أساسي (PK)
PersonID (int): مفتاح أجنبي (FK)
Specialization (nvarchar(100)): التخصص
4. جدول المواعيد (Appointments)
AppointmentID (int):
مفتاح أساسي (PK)
PatientID (int):
مفتاح أجنبي (FK)
DoctorID (int):
مفتاح أجنبي (FK)
AppointmentDateTime (datetime):
تاريخ ووقت الموعد
AppointmentStatus (tinyint):
حالة الموعد
MedicalRecordID (int): مفتاح أجنبي (FK)
PaymentID (int):
مفتاح أجنبي (FK)
5. جدول السجلات الطبية (MedicalRecords)
MedicalRecordID (int): مفتاح أساسي (PK)
VisitDescription (nvarchar(200)):
وصف الزيارة
Diagnosis (nvarchar(200)):
التشخيص
AdditionalNotes (nvarchar(200)):
ملاحظات إضافية
6. جدول الوصفات الطبية (Prescriptions)
PrescriptionID (int):
مفتاح أساسي (PK)
MedicalRecordID (int): مفتاح أجنبي (FK)
MedicationName (nvarchar(100)):
اسم الدواء
Dosage (nvarchar(50)): الجرعة
Frequency (nvarchar(50)):
التكرار
StartDate (date):
تاريخ البدء
EndDate (date):
تاريخ الانتهاء
SpecialInstructions (nvarchar(200)):
تعليمات خاصة
7. جدول المدفوعات (Payments)
PaymentID (int):
مفتاح أساسي (PK)
PaymentDate (date):
تاريخ الدفع
PaymentMethod (nvarchar(50)):
طريقة الدفع
AmountPaid (decimal): المبلغ المدفوع
AdditionalNotes (nvarchar(200)):
ملاحظات إضافية
🔗 ثانياً: العلاقات (Relationships)
بناءً على المفاتيح الأجنبية (Foreign Keys)، يتم ربط الجداول كما يلي:
1. علاقة الأشخاص بالمرضى والأطباء
(Supertype / Subtype)
جدول Persons يمثل الكيان العام (Supertype).
جدول Patients و Doctors يمثلان كيانات فرعية (Subtypes).
الربط يتم عبر:
PersonID → Patients
PersonID → Doctors
كل مريض أو طبيب هو في الأصل "شخص".
2. علاقة المواعيد بالمرضى
جدول Appointments يرتبط بجدول Patients عبر:
PatientID (FK)
العلاقة:
Patient (1) → (M) Appointments
3. علاقة المواعيد بالأطباء
جدول Appointments يرتبط بجدول Doctors عبر:
DoctorID (FK)
العلاقة:
Doctor (1) → (M) Appointments
4. علاقة المواعيد بالسجلات الطبية
جدول Appointments يرتبط بجدول MedicalRecords عبر:
MedicalRecordID (FK)
العلاقة:
Appointment (1) → (1) MedicalRecord (غالبًا)
5. علاقة المواعيد بالمدفوعات
جدول Appointments يرتبط بجدول Payments عبر:
PaymentID (FK)
العلاقة:
Appointment (1) → (1) Payment
6. علاقة الوصفات الطبية بالسجلات الطبية
جدول Prescriptions يرتبط بجدول MedicalRecords عبر:
MedicalRecordID (FK)
العلاقة:
MedicalRecord (1) → (M) Prescriptions
التصميم يطبق Normalization
بشكل ممتاز (تقليل التكرار).
استخدام
Supertype/Subtype
(Persons →
Patients/Doctors).
النظام قابل للتوسعة
(مثلاً إضافة Nurse أو Admin بسهولة)
بِسْمِ اللَّهِ الرَّحْمَنِ الرَّحِيم
الحمدُ للهِ القائل:
﴿يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ﴾
لقد ختمنا رحلةً امتدت لأربع سنوات من الجهد، والسهر، والطموح، لنقف على أعتاب مرحلة جديدة نحمل فيها ثمرة ما تعلمناه، وتجسيداً عملياً لمسيرة علمية وتقنية
لم تكن هذه السنوات مجرد دراسة أكاديمية عابرة، بل كانت رحلة بناء حقيقي؛ بدأنا فيها من أساسيات البرمجة والمنطق الخوارزمي، مروراً بفهم عميق لتحليل الأنظمة، وقواعد البيانات، والشبكات، وهندسة البرمجيات، ودمج خدمات الذكاء الاصطناعي وصولاً إلى القدرة على تصميم أنظمة متكاملة قادرة على التوسع والصيانة والعمل في بيئات واقعية مستضافة بالسحابة.
ومع تطورنا، تطورت التحديات؛ من كتابة برامج بسيطة، إلى بناء أنظمة متعددة الطبقات، وإدارة البيانات بكفاءة، وتأمين الأنظمة، وتحسين الأداء، والعمل ضمن فريق حقيقي يعتمد على التخطيط، وتوزيع المهام، وإدارة الوقت.
وهنا بدأ التحول الحقيقي من مجرد “مطورين” إلى “مهندسين” يفكرون بمنهجية شمولية في تصميم الأنظمة.
ومع دخولنا مرحلة مشروع التخرج، لم يكن الهدف تنفيذ فكرة فقط، او التخلص من عبئ مشروع التخرج ، بل بناء نظام متكامل يعالج مشكلة واقعية، بدءاً من تحليل احتياجات المستخدمين، مروراً بالتصميم المعماري (System Architecture)، وانتهاءً بربط جميع المكونات في بيئة واحدة تعمل بتناغم واحترافية.
هنا مشروعنا بعنوان:
“وكيلك الذكي للتسوق”
وهو نظام تقني متكامل بمستوى متعدد الصلاحيات والمتاجر يهدف إلى تطوير تجربة التسوق، وربط العملاء بالمتاجر المحلية بطريقة ذكية وسهلة.
يتكون المشروع من ٤ منظومات رئيسية:
لوحة تحكم إدارية لإدارة النظام ومتابعة الأداء..الخ
لوحة تحكم للتجار لإدارة المنتجات والعروض والتخفيضات..الخ
تطبيق موبايل للمستخدم لتجربة تسوق سلسة واحترافية.
واجهات خلفية بمعمارية متعددة الطبقات (Multi-tier Architecture)
ليكون منصة (SaaS) متكاملة وقابلة للتوسع
تتواصل واجهات النظام المختلفة (تطبيق الموبايل الخاص بالعملاء، ولوحات تحكم الويب الخاصة بالتجار والإدارة) مع خادم مركزي عبر واجهة برمجة التطبيقات (API)
لم يكن المشروع تقليدياً، بل تميز بدمج حقيقي لتقنيات الذكاء الاصطناعي كجزء أساسي من النظام، ومن أبرز هذه المزايا:
١- وكيل ذكي (AI Agent) يساعد المستخدم وينفذ المهام داخل النظام ، مدمج بنظام محادثة ذكي (Chatbot)
٢- البحث عن المنتجات باستخدام الصور
٣- توليد وصف تسويقي ذكي للمنتجات
٤- نظام توصيات يعتمد على سلوك المستخدم
هذا التكامل بين هندسة البرمجيات والذكاء الاصطناعي يعكس حجم التحول المعرفي الذي مررنا به خلال هذه السنوات.
ورغم التحديات التي واجهتنا من الفكرة الى التخطيط الى التحليل الى تصميم قواعد البيانات و الواجهات ، إلى إدارة التكامل بين الأنظمة المختلفة بتقنيات مختلفة والربط عن طريق APIs، واختيار المعمارية المناسبة إلا أن كل تحدٍ كان خطوة نحو بناء فهم أعمق وخبرة أقوى.
وفي هذه اللحظة، لا يسعنا إلا أن نحمد الله حمداً كثيراً طيباً مباركاً فيه، فبفضله وتوفيقه وصلنا إلى ما نحن عليه اليوم.
كما نتقدم بجزيل الشكر والعرفان إلى أهلنا الكرام، الذين كانوا السند والدعم والدعاء طوال هذه الرحلة.
ونعبر عن خالص تقديرنا لأساتذتنا الكرام، الذين أناروا لنا طريق العلم، وأسهموا في تشكيل هذا المستوى الذي وصلنا إليه.
كما نشكر لجنة المناقشة على ملاحظاتهم القيّمة التي أثرت مشروعنا، ومشرفينا الذين كان لهم الدور الأكبر في توجيهنا ومتابعتنا.
ولا ننسى فخرنا الكبير بفريق العمل، الذي جمعنا معه التعب، والأمل، والعمل الجماعي الحقيقي، فكنا مثالاً للتعاون والالتزام والتطوير الذاتي والبحث والإطلاع والتوسع وعدم الإكتفاء.
المهندسين :
م. ايمن قمحان
م. حازم العمري
م ضياء الحضرمي
م. طارق العمري
م. علي القواس
ختاماً…
مشروع التخرج ليس مجرد إسقاط واجب علينا، بل هو خلاصة أربع سنوات من التعلم، والتجربة، والفشل، والتحسين، والعمل الجماعي.
وما تحقق اليوم ليس نهاية الطريق، بل بداية حقيقية لمسار مهني في عالم البرمجيات والتقنية.
اللهم بارك لنا في هذا الإنجاز، واجعل القادم أجمل.
#DemoSoft
الحمدُ للهِ القائل:
﴿يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ﴾
لقد ختمنا رحلةً امتدت لأربع سنوات من الجهد، والسهر، والطموح، لنقف على أعتاب مرحلة جديدة نحمل فيها ثمرة ما تعلمناه، وتجسيداً عملياً لمسيرة علمية وتقنية
لم تكن هذه السنوات مجرد دراسة أكاديمية عابرة، بل كانت رحلة بناء حقيقي؛ بدأنا فيها من أساسيات البرمجة والمنطق الخوارزمي، مروراً بفهم عميق لتحليل الأنظمة، وقواعد البيانات، والشبكات، وهندسة البرمجيات، ودمج خدمات الذكاء الاصطناعي وصولاً إلى القدرة على تصميم أنظمة متكاملة قادرة على التوسع والصيانة والعمل في بيئات واقعية مستضافة بالسحابة.
ومع تطورنا، تطورت التحديات؛ من كتابة برامج بسيطة، إلى بناء أنظمة متعددة الطبقات، وإدارة البيانات بكفاءة، وتأمين الأنظمة، وتحسين الأداء، والعمل ضمن فريق حقيقي يعتمد على التخطيط، وتوزيع المهام، وإدارة الوقت.
وهنا بدأ التحول الحقيقي من مجرد “مطورين” إلى “مهندسين” يفكرون بمنهجية شمولية في تصميم الأنظمة.
ومع دخولنا مرحلة مشروع التخرج، لم يكن الهدف تنفيذ فكرة فقط، او التخلص من عبئ مشروع التخرج ، بل بناء نظام متكامل يعالج مشكلة واقعية، بدءاً من تحليل احتياجات المستخدمين، مروراً بالتصميم المعماري (System Architecture)، وانتهاءً بربط جميع المكونات في بيئة واحدة تعمل بتناغم واحترافية.
هنا مشروعنا بعنوان:
“وكيلك الذكي للتسوق”
وهو نظام تقني متكامل بمستوى متعدد الصلاحيات والمتاجر يهدف إلى تطوير تجربة التسوق، وربط العملاء بالمتاجر المحلية بطريقة ذكية وسهلة.
يتكون المشروع من ٤ منظومات رئيسية:
لوحة تحكم إدارية لإدارة النظام ومتابعة الأداء..الخ
لوحة تحكم للتجار لإدارة المنتجات والعروض والتخفيضات..الخ
تطبيق موبايل للمستخدم لتجربة تسوق سلسة واحترافية.
واجهات خلفية بمعمارية متعددة الطبقات (Multi-tier Architecture)
ليكون منصة (SaaS) متكاملة وقابلة للتوسع
تتواصل واجهات النظام المختلفة (تطبيق الموبايل الخاص بالعملاء، ولوحات تحكم الويب الخاصة بالتجار والإدارة) مع خادم مركزي عبر واجهة برمجة التطبيقات (API)
لم يكن المشروع تقليدياً، بل تميز بدمج حقيقي لتقنيات الذكاء الاصطناعي كجزء أساسي من النظام، ومن أبرز هذه المزايا:
١- وكيل ذكي (AI Agent) يساعد المستخدم وينفذ المهام داخل النظام ، مدمج بنظام محادثة ذكي (Chatbot)
٢- البحث عن المنتجات باستخدام الصور
٣- توليد وصف تسويقي ذكي للمنتجات
٤- نظام توصيات يعتمد على سلوك المستخدم
هذا التكامل بين هندسة البرمجيات والذكاء الاصطناعي يعكس حجم التحول المعرفي الذي مررنا به خلال هذه السنوات.
ورغم التحديات التي واجهتنا من الفكرة الى التخطيط الى التحليل الى تصميم قواعد البيانات و الواجهات ، إلى إدارة التكامل بين الأنظمة المختلفة بتقنيات مختلفة والربط عن طريق APIs، واختيار المعمارية المناسبة إلا أن كل تحدٍ كان خطوة نحو بناء فهم أعمق وخبرة أقوى.
وفي هذه اللحظة، لا يسعنا إلا أن نحمد الله حمداً كثيراً طيباً مباركاً فيه، فبفضله وتوفيقه وصلنا إلى ما نحن عليه اليوم.
كما نتقدم بجزيل الشكر والعرفان إلى أهلنا الكرام، الذين كانوا السند والدعم والدعاء طوال هذه الرحلة.
ونعبر عن خالص تقديرنا لأساتذتنا الكرام، الذين أناروا لنا طريق العلم، وأسهموا في تشكيل هذا المستوى الذي وصلنا إليه.
كما نشكر لجنة المناقشة على ملاحظاتهم القيّمة التي أثرت مشروعنا، ومشرفينا الذين كان لهم الدور الأكبر في توجيهنا ومتابعتنا.
ولا ننسى فخرنا الكبير بفريق العمل، الذي جمعنا معه التعب، والأمل، والعمل الجماعي الحقيقي، فكنا مثالاً للتعاون والالتزام والتطوير الذاتي والبحث والإطلاع والتوسع وعدم الإكتفاء.
المهندسين :
م. ايمن قمحان
م. حازم العمري
م ضياء الحضرمي
م. طارق العمري
م. علي القواس
ختاماً…
مشروع التخرج ليس مجرد إسقاط واجب علينا، بل هو خلاصة أربع سنوات من التعلم، والتجربة، والفشل، والتحسين، والعمل الجماعي.
وما تحقق اليوم ليس نهاية الطريق، بل بداية حقيقية لمسار مهني في عالم البرمجيات والتقنية.
اللهم بارك لنا في هذا الإنجاز، واجعل القادم أجمل.
#DemoSoft
❤3
"يُنهكنا السهر ويأكل الإرهاق أرواحنا، لكنه احتراقٌ مُقدس يترك وراءه أثراً.... فالعمرُ سيمضي بنا في كل حال.. فليكن ضياؤه في وهجِ له معنى، لا انطفاءً في عتمة الهامش..
💙
💙
❤5👍1💯1
الحمد لله، من خلال رحلتنا في التعلم والتطبيق في خارطة الطريق للمهندس محمد أبو هدهود Mohammed Abu Hadhoud ، استطعنا الانتقال من مرحلة الفهم النظري إلى التطبيق العملي الحقيقي، وذلك عبر بناء نظام متكامل لإدارة عيادة طبية بتقنيات مختلفة تماماً عن المقرر
لم يكن الهدف مجرد تنفيذ مشروع، بل كان السعي لتجسيد مفهوم الهندسة البرمجية الواقعية، حيث يتحول التحليل والتصميم إلى نظام حي يخدم المستخدمين.
فكرة النظام
قمنا بتصميم وتطوير نظام متكامل يتكون من:
لوحة تحكم أدمن (Admin Dashboard)
لوحة تحكم لإدارة العيادة
تطبيق مخصص للمرضى
يهدف النظام إلى تسهيل إدارة العيادات وتحسين تجربة المرضى بشكل جذري.
مميزات التطبيق
من خلال التطبيق، أصبح بإمكان المريض:
حجز موعد مع أي طبيب وفي أي تخصص بسهولة
طلب استشارة طبية عن بُعد
الدفع الإلكتروني والحجز بدل الانتظار الطويل
استقبال تنبيهات دقيقة لمواعيد تناول الأدوية
متابعة الخطة العلاجية الخاصة به
هذا التحول الرقمي يختصر الوقت والجهد، ويعكس مفهوم الرعاية الصحية الذكية.
بداية التصميم: الكيانات والعلاقات
كانت البداية من أهم خطوة في أي نظام:
تحليل البيانات
وتصميم قاعدة البيانات (Database Design)
أولاً: الكيانات (Entities)
تم تصميم الكيانات الأساسية كالتالي:
Persons: الكيان العام الذي يمثلأي شخص في النظام
Patients: المرضى
Doctors: الأطباء
Appointments: المواعيد
MedicalRecords: السجلات الطبية
Prescriptions: الوصفات
Payments: المدفوعات
ثانياً: العلاقات (Relationships)
تم بناء العلاقات بشكل احترافي يعكس الواقع:
كل شخص يمكن أن يكون مريض أو طبيب
(Supertype/Subtype)
المريض يمكن أن يمتلك عدة مواعيد
الطبيب يمكن أن يشرف على عدة مواعيد
كل موعد مرتبط بسجل طبي ودفع
السجل الطبي يمكن أن يحتوي على عدة وصفات
قوة التصميم
ما يميز هذا النظام:
1. استخدام Normalization
تم تقليل التكرار في البيانات بشكل احترافي، مما يحسن الأداء ويمنع التعارض.
2. تطبيق مفهوم Supertype / Subtype
ربط الكيان العام (Persons) بالكيانات الفرعية (Patients / Doctors)
وهو من أفضل الممارسات في تصميم قواعد البيانات.
3. قابلية التوسع (Scalability)
يمكن بسهولة إضافة:
ممرضين (Nurses)
موظفين إداريين (Admins)
أقسام جديدة
دون الحاجة لإعادة بناء النظام.
ما تعلمته من التجربة
هذه التجربة لم تكن مجرد مشروع، بل كانت نقلة نوعية في الفهم:
كيف أحول الفكرة الى متطلبات ثم مخطط إلى نظام حقيقي
كيف أبني قاعدة بيانات قوية وقابلة للتوسع
كيف أربط بين التحليل + التصميم + البرمجة
كيف أفكر كمهندس برمجيات وليس كمبرمج فقط
التقنيات المستخدمة:
React + React Native+ Node.js +
Express+ mongodb+ Twilind
الخلاصة
هذا النظام هو ثمرة جهد وتعلم وتطبيق عملي، يمثل خطوة قوية في رحلتنا في هندسة البرمجيات.
والأجمل من ذلك، أنه قابل للتطوير ليصبح منتجًا حقيقيًا يخدم المجتمع، ويُحدث فرقًا في مجال الرعاية الصحية.
#يوميات_مهندس
لم يكن الهدف مجرد تنفيذ مشروع، بل كان السعي لتجسيد مفهوم الهندسة البرمجية الواقعية، حيث يتحول التحليل والتصميم إلى نظام حي يخدم المستخدمين.
فكرة النظام
قمنا بتصميم وتطوير نظام متكامل يتكون من:
لوحة تحكم أدمن (Admin Dashboard)
لوحة تحكم لإدارة العيادة
تطبيق مخصص للمرضى
يهدف النظام إلى تسهيل إدارة العيادات وتحسين تجربة المرضى بشكل جذري.
مميزات التطبيق
من خلال التطبيق، أصبح بإمكان المريض:
حجز موعد مع أي طبيب وفي أي تخصص بسهولة
طلب استشارة طبية عن بُعد
الدفع الإلكتروني والحجز بدل الانتظار الطويل
استقبال تنبيهات دقيقة لمواعيد تناول الأدوية
متابعة الخطة العلاجية الخاصة به
هذا التحول الرقمي يختصر الوقت والجهد، ويعكس مفهوم الرعاية الصحية الذكية.
بداية التصميم: الكيانات والعلاقات
كانت البداية من أهم خطوة في أي نظام:
تحليل البيانات
وتصميم قاعدة البيانات (Database Design)
أولاً: الكيانات (Entities)
تم تصميم الكيانات الأساسية كالتالي:
Persons: الكيان العام الذي يمثلأي شخص في النظام
Patients: المرضى
Doctors: الأطباء
Appointments: المواعيد
MedicalRecords: السجلات الطبية
Prescriptions: الوصفات
Payments: المدفوعات
ثانياً: العلاقات (Relationships)
تم بناء العلاقات بشكل احترافي يعكس الواقع:
كل شخص يمكن أن يكون مريض أو طبيب
(Supertype/Subtype)
المريض يمكن أن يمتلك عدة مواعيد
الطبيب يمكن أن يشرف على عدة مواعيد
كل موعد مرتبط بسجل طبي ودفع
السجل الطبي يمكن أن يحتوي على عدة وصفات
قوة التصميم
ما يميز هذا النظام:
1. استخدام Normalization
تم تقليل التكرار في البيانات بشكل احترافي، مما يحسن الأداء ويمنع التعارض.
2. تطبيق مفهوم Supertype / Subtype
ربط الكيان العام (Persons) بالكيانات الفرعية (Patients / Doctors)
وهو من أفضل الممارسات في تصميم قواعد البيانات.
3. قابلية التوسع (Scalability)
يمكن بسهولة إضافة:
ممرضين (Nurses)
موظفين إداريين (Admins)
أقسام جديدة
دون الحاجة لإعادة بناء النظام.
ما تعلمته من التجربة
هذه التجربة لم تكن مجرد مشروع، بل كانت نقلة نوعية في الفهم:
كيف أحول الفكرة الى متطلبات ثم مخطط إلى نظام حقيقي
كيف أبني قاعدة بيانات قوية وقابلة للتوسع
كيف أربط بين التحليل + التصميم + البرمجة
كيف أفكر كمهندس برمجيات وليس كمبرمج فقط
التقنيات المستخدمة:
React + React Native+ Node.js +
Express+ mongodb+ Twilind
الخلاصة
هذا النظام هو ثمرة جهد وتعلم وتطبيق عملي، يمثل خطوة قوية في رحلتنا في هندسة البرمجيات.
والأجمل من ذلك، أنه قابل للتطوير ليصبح منتجًا حقيقيًا يخدم المجتمع، ويُحدث فرقًا في مجال الرعاية الصحية.
#يوميات_مهندس
👍4
🚀 لو وصلت لمرحلة إنك تمتلك أساس في اللغة الإنجليزية… فهنا تبدأ القفزة الحقيقية
إذا كنت تريد:
🔥 تطوير مهاراتك بشكل احترافي
🔥 التعلم بأساليب ممتعة من مدرسين أجانب
🔥 تحسين الاستماع والتحدث بطريقة طبيعية
فهذه من أفضل المصادر اللي ممكن تعتمد عليها 👇
🎥 قناة يوتيوب:
https://youtube.com/@engvidjade?si=ZP7OUuZbu1DOHGpl
🌐 الموقع الرسمي:
https://www.engvid.com/
💡 المميز فيها:
- شروحات من معلمين ناطقين باللغة
- دروس تغطي القواعد، المحادثة، والمفردات وطرق احترافية
- أسلوب بسيط وعميق بنفس الوقت
ملاحظة:
هذه المصادر مناسبة لك إذا كان عندك أساس مسبق
(درست معهد أو تعرف الأساسيات)، لأنها بتاخذك لمستوى أعلى بإذن الله.
ابدأ اليوم… وخلّك مختلف 💪🔥
طبعا الموقع مفهرس ومنظم افضل
إذا كنت تريد:
🔥 تطوير مهاراتك بشكل احترافي
🔥 التعلم بأساليب ممتعة من مدرسين أجانب
🔥 تحسين الاستماع والتحدث بطريقة طبيعية
فهذه من أفضل المصادر اللي ممكن تعتمد عليها 👇
🎥 قناة يوتيوب:
https://youtube.com/@engvidjade?si=ZP7OUuZbu1DOHGpl
🌐 الموقع الرسمي:
https://www.engvid.com/
💡 المميز فيها:
- شروحات من معلمين ناطقين باللغة
- دروس تغطي القواعد، المحادثة، والمفردات وطرق احترافية
- أسلوب بسيط وعميق بنفس الوقت
ملاحظة:
هذه المصادر مناسبة لك إذا كان عندك أساس مسبق
(درست معهد أو تعرف الأساسيات)، لأنها بتاخذك لمستوى أعلى بإذن الله.
ابدأ اليوم… وخلّك مختلف 💪🔥
طبعا الموقع مفهرس ومنظم افضل
engVid
engVid · Learn English for Free
Learn English for free with hundreds of video lessons by experienced native-speaker teachers. English grammar, vocabulary, pronunciation, IELTS, TOEFL, writing, and more.
سؤال :
كيف استغل قدرات الذكاء الاصطناعي في تخصصي في جانب آخر غير كتابة الكود ؟
يمكن تستفيد منه في تحليل النظم
ممكن تشوف مثال في
دورة حياة الشخص منذ دخوله المستشفى الى خروجه
نتمنى لكم قراءة ممتعة
https://chatgpt.com/share/69e6bdad-6780-8327-9d69-ef584c5ff9f7
كيف استغل قدرات الذكاء الاصطناعي في تخصصي في جانب آخر غير كتابة الكود ؟
يمكن تستفيد منه في تحليل النظم
ممكن تشوف مثال في
دورة حياة الشخص منذ دخوله المستشفى الى خروجه
نتمنى لكم قراءة ممتعة
https://chatgpt.com/share/69e6bdad-6780-8327-9d69-ef584c5ff9f7
ChatGPT
ChatGPT - دورة حياة المريض
ChatGPT helps you get answers, find inspiration, and be more productive.
تخيلوا معي أن هذه المواضيع في صلب تخصصنا ولا نفقه منها شئ سوى القشور 😑🔥
تخصصنا بحر عميق لا مرسئ له ولا نهاية
كل يوم تكتشف موضوع جديد وتشعر بأنك جاهل في تخصصك مهما درست ومهما تعلمت 🤔
فهرس متكامل تم البحث عن هذه المواضيع في ٤٤ مصدر في الانترنت
من خلال NotebookLM
القي نظرة
https://notebooklm.google.com/notebook/308e7523-4338-4d53-8b02-98c501de1e7a
تخصصنا بحر عميق لا مرسئ له ولا نهاية
كل يوم تكتشف موضوع جديد وتشعر بأنك جاهل في تخصصك مهما درست ومهما تعلمت 🤔
فهرس متكامل تم البحث عن هذه المواضيع في ٤٤ مصدر في الانترنت
من خلال NotebookLM
القي نظرة
https://notebooklm.google.com/notebook/308e7523-4338-4d53-8b02-98c501de1e7a
Google
Google NotebookLM | Your research and thinking partner, grounded in the information you trust
Use the power of AI for quick summarization and note taking, NotebookLM is your powerful virtual research assistant rooted in information you can trust.