منذ بضع اعوامتحميل جميع نسخ دلفي - Download All Delphi Versions

جدول التنقل

1. إيجاد المفاهيم
2. استخلاص المفاهيم من المتطلبات
3. النموذج المفاهيمي في UML
4. إيجاد السمات
5. إرشادات لإيجاد السمات
6. الروابط Associations
7. الإلزاميات المحتملة
8. ملخص

نمذجة المفاهيم

نمذجة المفاهيم Conceptual Modeling  (أحيانا تدعى : نمذجة النطاق العام Domain Modeling ) هو النشاط الذي يهتم بإيجاد المفاهيم ذات الأهمية في نظامنا. هذه العملية تساعدنا على فهم المشكلة أكثر، و تدعم إدراكنا لمجال عمل الزبون الذي نخدمه.

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

شكل 30: مخطط صنفيات في UML

بناء مخطط الصنفيات هو المفتاح لأية عملية تصميم بالمنحى للكائن object oriented design . سيوضح مخطط الصنفيات بشكل أساسي الهيكل العام للتوليف code النهائي الذي سننتجه.

عموما، في هذه المرحلة، لا يهمنا كثيرا تصميم النظام (ما زلنا نقوم بالتحليل)، لذا فإن مخطط الصنفيات الذي سنقوم بإعداده في هذه المرحلة سيكون أقرب لتخطيط مبدئي، و لن يحوي على أي تصميم نهائي.

مثلا، لن نقوم بإضافة صنفية لقائمة مرتبطة "LinkList" في هذه المرحلة، لأن هذا سيجرنا إلى اتخاذ حل معين في فترة مبكرة جدا.

في النموذج المفاهيمي، نهدف إلى رصد كل المفاهيم و الأفكار بطريقة يمكن للزبون أن يتعرف عليها. فيما يلي بعض الأمثلة الجيدة لمثل هذه المفاهيم:

·        مصعد في نظام مراقبة الصعود

·        طلبية في نظام التسوق المنزلي

·        لاعب كرة القدم في نظام تحويل كرة القدم (أو لعبة كرة قدم في جهاز "بلاي ستيشن"!)

·        حذاء رياضي في نظام إدارة المخزون لمحل أحذية

·        غرفة في نظام حجز الغرف

بعض الأمثلة السيئة جدا للمفاهيم هي:

·        معالج_تطهير_الطلبيات العملية التي تقوم دوريا بإزالة الطلبيات القديمة من النظام

·        صمام_حدث العملية الخاصة التي تنتظر 5 دقائق ثم تقوم بإيقاظ النظام ليفعل شيء ما

·        نموذج_بيانات_زبون الشاشة التي يتم فيها تعبئة بيانات زبون جديد في نظام محل تسوّق

·        جدول_أرشفة  جدول قاعدة بيانات تحوي قائمة بكل الطلبيات القديمة

أفضل قاعدة هنا هي:

إذا كان المفهوم غير واضح بالنسبة للزبون، فمن المحتمل أنه ليس بمفهوم!

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

إيجاد المفاهيم

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

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

استخلاص المفاهيم من المتطلبات

تعد وثيقة المتطلبات مصدر جيد لبناء المفاهيم. يقترح كريك لارمان Craig Larman  (المصدر[2]) ترشيح المفاهيم التالية من المتطلبات:

·        الكائنات المادية و المحسوسة

·        الأماكن

·        الحركات/ المعاملات

·        أدوار الأفراد (الزبون، موظف المبيعات)

·        الحاويات لمفاهيم أخرى

·        الأنظمة الخارجية الأخرى (مثل قواعد البيانات النائية)

·        الأسماء المجردة (مثل عطش)

·        التقسيمات التنظيمية

·        الأحداث (مثل: الحالات الطارئة)

·        القواعد/ اللوائح والسياسات

·        التسجيلات / ملفات رصد الحركة

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

ثانيا، الكثير من المتمرسين يقترحون أن يتم استخلاص عبارات الأسماء من الوثيقة. هذه الطريقة شاع استخدامها لما يقرب من 20 عاما، و بالرغم من أنه لا يوجد ما يعيبها في حد ذاتها، إلا أنه ليس صحيحا الإيحاء بأن البحث الآلي عن هذه الأسماء سينتج عنه قائمة جيدة من المفاهيم، و التصنيفات classes. للأسف، اللغة العادية فيها الكثير من الغموض و الالتباس الذي يمنع مثل هذه الطريقة الآلية. سوف نكرر ثانية – مشاركة الزبون أمر أساسي!

النموذج المفاهيمي في UML

الآن، و بعد أن رأينا كيف نقوم باستكشاف المفاهيم، نحتاج لمعرفة كيفية رصد هذه المفاهيم في UML. سوف نستخدم الملامح الرئيسية لمخطط الصنفيات class diagram.

نقوم بتمثيل المفهوم الذي لدينا  بمربع بسيط، رفق عنوان= اسم المفهوم (بأحرف كبيرة عادة) في أعلى المربع.

شكل 31: مفهوم "سباق" Race بحسب UML (من أجل منظومة لسباق الخيل)

لاحظ أن داخل المربع الكبير يوجد مربعين خاليين أصغر حجما. المربع الأوسط سوف يستعمل قريبا لرصد سمات attributes المفهوم – سيتم شرحه بعد لحظات. المربع السفلي يستخدم لرصد سلوك behavior المفهوم – بعبارة أخرى ، ماذا يمكن للمفهوم فعله. تقرير سلوك المفهوم أو ماهية تصرفاته خطوة معقدة، و  سوف نقوم بتأجيل هذه الخطوة حتى نصل إلى مرحلة التصميم للبناء. لذلك ليس هناك ما يدعو للقلق حول السلوك الآن.

شكل 32: رصد سمات و سلوك المفهوم في UML

في المثال أعلاه، قررنا أن كل متسابق runner لديه اثنين من السمات "الاسم" و "العمر". و قد تركنا المنطقة السفلى خالية لوقت لاحق عندما نقرر ماذا  يمكن ل"متسابق" أن يفعله.

إيجاد السمات

نحتاج إلى أن نقرر ما هي السمات الخاصة بكل مفهوم – و مرة أخرى، فإن جلسة عصف ذهني مع ذوي العلاقة ستكون في الأغلب أفضل وسيلة لتحقيق ذلك.

غالبا، ما تثار مجادلات حول ما إذا كان السمة في حد ذاتها هي مفهوم آخر أم لا. مثلا، لنقل أننا بصدد منظومة لإدارة العاملين وقررنا أن أحد المفاهيم فيها هو "المدير". ثم اقترحنا سمة له و هي"مرتب"، كالتالي: 

شكل 33: مفهوم مدير مع سمة "مرتب"

هذا يبدو جيدا، لكن أحدهم قد يجادل بأن "مرتب" هي أيضا مفهوم. لذلك هل علينا ترقيتها من سمة إلى مفهوم؟

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

شكل 34: مدير و مرتب، مفهومين منفصلين

إرشادات لإيجاد السمات

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

·        الجمل strings و الأرقام ذات القيمة المفردة عادة ما تكون سمات.

·        إذا وجدت خاصية property لمفهوم لا يمكنها فعل أي شيء، فقد تكون سمة – مثلا في مفهوم "مدير"، يبدو واضحا أن خاصية "اسم" تبدو كسمة. "سيارة شركة" تبدو مثل مفهوم، لأننا نحتاج لتخزين معلومات عن كل سيارة مثل رقم التسجيل و لونها.

الروابط Associations

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

شكل 35: اثنان من المفاهيم مدير و سيارة شركة

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

يمكننا التعبير عن هذه العلاقة في UML من خلال وصل هذين المفهومين بعضهما بخط مفرد (يسمى رابط association)، كالتالي:

شكل 36: "مدير" و "سيارة شركة" موصولان برابط

شيئان مهمان يجدر ملاحظتهما في هذا الرابط. قبل كل شيء، الربط لديه اسم دال – في هذه الحالة، "يقود" drives. ثانيا، هناك أرقام في طرفي الرابط. هذه الأرقام تصف الإلزامية cardinality لهذا الرابط، و تخبرنا العدد المسموح به لتمثلات instances  كل مفهوم.

في هذا المثال، نحن نقول بأن "كل مدير يقود سيارة شركة واحدة"، و (في الاتجاه المعاكس) "كل سيارة شركة يقودها مدير واحد"

شكل 37: مثال آخر لرابط

في المثال أعلاه، نجد أن "كل مدير يدير 1 أو أكثر من العاملين"؛ و (بالجهة المقابلة)، "كل عامل يُدار من قبل مدير واحد".

كل رابط يجب أن يكون بهذا الشكل- عندما يتم قراءة الرابط باللغة العادية، يجب أن تكون بجملة مفيدة (خاصة للزبون). أيضا، عند تحديد عناوين للروابط، لنتجنب العناوين الضعيفة مثل "لديه" أو "هو مرتبط بـ" – استخدام لغة ضعيفة كهذه يمكنها بسهولة إخفاء مشاكل أو أخطاء كان يمكن الكشف عنها لو كان للروابط أسماء أكثر دلالة.

الإلزاميات المحتملة

بالأساس، لا توجد أية قيود على الإلزاميات Cardinalities التي يمكنك تحديدها. يستعرض المخطط التالي قائمة ببعض الأمثلة،  برغم أنها ليست شاملة لكل الحالات. علامة * تشير إلى "عديد" many. لاحظ الفرق البسيط بين "*" و "1..*". الأول يشير بشكل غامض إلى "عديد"، فقد يعنى السماح بأي عدد من تجسدات المفهوم، أو ربما لم نتخذ قرارا بعد. الأخير أكثر تحديدا، ويعني ضمنيا السماح لعدد واحد أو أكثر.

شكل 38: أمثلة على الإلزاميات

 بناء النموذج بالكامل

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

شكل 39: مجموعة من المفاهيم لإدارة العاملين

أفضل وسيلة لعمل ذلك هي "تثبيت" أحد المفاهيم، و ليكن "مدير" و مراجعة كل مفهوم آخر مقابله. نسأل أنفسنا "هل توجد علاقة بين هذين المفهومين ؟" إذا كان كذلك، نشرع فورا في تسمية الرابطة بينهما، و نوع الإلزامية..

”

هل للمدير علاقة  بالفرد العامل ؟ نعم، كل مدير يدير1 أو أكثر من العمال. المدير و سيارة الشركة؟ نعم، كل مدير يقود سيارة واحدة. المدير و حساب تأمين تقاعدي ؟ نعم، كل مدير يتشارك في حساب تقاعد واحد.

“

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

شكل 40: نموذج مفاهيمي بسيط، و كامل

من المهم أن نتذكر عند بناء النموذج أن الروابط أقل أهمية من السمات. أي رابط مفقود سيكون من السهل استرجاعه عند التصميم، لكنه من الصعب تدارك سمات تم إغفالها. 

أمر آخر، قد يكون من المغري التمادي في إضفاء المزيد من الروابط  "للاحتياط"، و تكون النتيجة بعدها مخططا معقدا و أكثر إرباكا. لذلك فإن القاعدة الجيدة هنا هو أن نركز على المفاهيم و السمات، و محاولة تثبيت الروابط الأكثر وضوحا.

عند نهاية النمذجة، يجب أن يكون المخطط ذو معنى للزبون عند "إعادة قراءة" النموذج باللغة العادية.

ملخص

النموذج المفاهيمي وسيلة فعالة من أجل تحليل أعمق للمسألة.

لاحقا،  سنقوم بتوسعة النموذج نحو نواحي التصميم.

سيكون هذا النموذج في النهاية أحد أهم المعطيات عند بناء التوليف code.

لبناء النموذج، استخدم تقنيات ورش العمل كما في وقائع الاستخدام. 

قد يعجبك ايضا

تعديل المقال