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

جدول التنقل

1. ترقيم الرسائل
2. مخططات التعاون: مثال عملي
3. بعض الإرشادات لمخططات التعاون
4. ملخص

ترقيم الرسائل

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

مخططات التعاون: مثال عملي

لنجمع كل هذه المفاهيم مع بعضها ونرى كيف تعمل هذه الترميزات بصورة عملية. لنبني واقعة الاستخدام “place bet” (وضع رهان) باستخدام مخطط التعاون.

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

راجع الفصل السابق و وصف واقعة استخدام بعد اكتمالها ل“Place Bet” (وضع رهان).

لبناء هذا المخطط، نحتاج لبعض الكائنات. من أين نأتي بهذه الكائنات؟ حسنا، سوف يكون علينا بالتأكيد اختراع بعض الكائنات الجديدة كلما تقدمنا/ لكن معظم الكائنات المرشحة يجب أن تأتي مباشرة من صديقنا القديم، النموذج المفاهيمي conceptual الذي قمنا ببنائه في طور التفصيل. هاهنا النموذج المفاهيمي لنظام المراهنة:

شكل 47: النموذج المفاهيمي لنظام/منظومة المراهنة

أين هي الروابط associations، مثل “is placed on” (يوضع على)، سنقوم على الأغلب باستخدام هذه الروابط لتمرير الرسائل على مخطط التعاون. قد يمكننا تقرير أننا نحتاج (كمثال) لتمرير رسالة بين “account” (حساب) و “race” (سباق). هذا أمر ممكن، لكن طالما أن الرابط لم يتم اكتشافه في المرحلة المفاهيمية، فمن المحتمل أن نخلّ ببعض متطلبات الزبون. إذا حدث هذا، فلابد من مراجعة الزبون!.

بمساعدة وصف وقائع الاستخدام و مع أخذنا في الاعتبار النموذج المفاهيمي، لنقم ببناء التعاون ل “Place Bet” (وضع رهان).

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

2.    الآن، و بناء على وصف واقعة الاستخدام، عندما يقوم الزبون باختيار “place bet” وضع الرهان، يتم عرض قائمة بالسباقات. إذا نحتاج لكائن يحتوي على قائمة كاملة بالسباقات ليوم معين، إذا سنقوم بخلق كائن يدعى “Race List” (قائمة سباق). هذا كائن جديد لم يظهر في النموذج المفاهيمي. هذا يسمى design class صنفية تصميم، أي أنها صنفية ظهر الحاجة إليها وقت التصميم.

3.    إذاً فإن، اللاعب سيبعث برسالة إلى كائن جديد من صنفية“Race List” (قائمة سباق)، الرسالة اسمها “getRaceList” (جلب قائمة سباق). الآن، المهمة التالية مسؤولة عنها قائمة السباق حتى تقوم بتجميع نفسها. و تقوم بهذا من خلال المرور على كل كائنات Race (سباق)، و سؤالهم عن أسمائهم.

كائن Race (سباق) تم أخذه من النموذج المفاهيمي.

4.    بعدها، نفترض أن قائمة السباقات قد تم تحويلها الآن إلى الزبون. الكرة الآن في ملعب الزبون، و حسب ما جاء في مواصفات واقعة الاستخدام (صفحة 72 واقعة الاستخدام بعد اكتمالها)، يقوم المستخدم=اللاعب الآن  باختيار السباق من القائمة.
يمكننا الافتراض الآن أن السباق تم اختياره. نحتاج الآن إلى قائمة بالمتسابقين على نفس هذا السباق، و من أجل هذا قررنا أن جعل كائن race (سباق) مسؤولا عن الاحتفاظ بقائمة المتسابقين فيه. سوف نرى في الفصول التالية لماذا و كيف أتخذنا مثل هذا القرار.



إذا، الرسالة رقم 3 يتم إرسالها للسباق الذي تم اختياره، الرسالة تطلب من السباق تزويده بقائمة من المتسابقين في هذا السباق.

5.    كيف لكائن السباق أن يعرف المتسابقين المشتركين فيه. مرة أخرى، سنجعله يقوم بهذا باستخدام التوالي loop، سنجعل كائن السباق يقوم بتجميع قائمة بالمتسابقين.
كيفية إنجاز ذلك في النظام الحقيقي ليس بالأمر التافه. واضح، بأننا سنقوم بتخزين المتسابقين في قاعدة للبيانات من نوع ما، لذا فإن جزءا من عملية التصميم الفعلي ستكون إنشاء آلية لاسترجاع تسجيلات الخيل من قاعدة البيانات. بالنسبة للآن عموما، سوف نكتفي بالقول بأن كائن Race (سباق) الذي تم اختياره هو المسؤول عن تجميع قائمة المتسابقين في هذا السباق.

6.    قائمة المتسابقين تردّ الآن إلى الزبون. مرة أخرى الكرة في ملعبه، و حسب كراسة مواصفات واقعة الاستخدام، على الزبون الآن أن يختار متسابقا، ثم مبلغ الرهان عليه.
الآن وقد عرفنا المتسابق و الرهان، يمكننا بعث رسالة إلى المتسابق المختار، و نخبره فيها أن الرهان قد وضع عليه.

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

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

2.    كيف لكائن "Race" (سباق) أن يعرف أي المتسابقين هم جزء من هذا السباق؟ واضح، أن هناك عملية من نوع ما لها علاقة بقاعدة بيانات (أو حتى شبكة) تتم هنا. مرة أخرى، نحن لا نريد أن نقيّد تصميمنا في هذه المرحلة، لذلك سنرجئ هذه التفاصيل لما بعد.

3.    لماذا جعلنا من كائن “runner” (متسابق) مسؤولا عن تتبع أي رهان تم وضعه عليه؟ لماذا لم نخلق صنفية أخرى، ربما نسميها “bet handler” (مناول سباق) أو “betting system” (نظام مراهنة)؟ هذه المسألة سيتم توضيحها في الفصل التالي.

ما فعلناه هو تقرير مسؤوليات كل صنفية. ما بنيناه كان تأسيسا على النموذج المفاهيمي الذي قمنا بإنشائه في مرحلة التفصيل.

بعض الإرشادات لمخططات التعاون

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

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

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

3.    تجنب خلق صنفيات classes تحوي أسمائها على كلمات مثل: “controller”، “handler” ،  “manager”   أو  “driver” (متحكم ، مناول، مدير، مسيّر). أو على الأقل، الحذر إذا وجدنا أنفسنا نتعامل مع مثل هذه الأسماء. لماذا؟ لأن هذه الصنفيات توحي بأن تصميمنا ليس كائني المنحى object oriented. مثلا، في واقعة استخدام “Place Bet” (وضع رهان)، كان يمكن لنا أن نخلق صنفية باسم  “BetHandler” (مناول رهان) تتعامل مع كل الوظائف الخاصة بالمراهنة. و لكن هذا سيكون حلا بالمنحى للفعل أو السلوك و يرتكز على الأفعال بدل أن يكون كائني المنحى. نحن لدينا بالفعل الكائن “Bet” (رهان) في مخطط التعاون، لذا لما لا نستخدمه، و نعطيه المسؤولية لمناولة الرهانات؟

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

ملخص

في هذا الفصل، بدأنا ببناء حل برمجي لما لدينا من وقائع استخدام. مخطط التعاون يجعلنا قادرين على توزيع المسؤوليات على الصنفيات التي استخلصناها  خلال طور التفصيل.

لمسنا بعض القضايا التي يجب مراعاتها عند توزيع المسؤوليات، مع احتياجنا لتعلم المزيد حول هذا الأمر لاحقا. قمنا بدراسة مثال “Place Bet” (وضع رهان.)

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

قد يعجبك ايضا

تعديل المقال