وهذا النظرة الثالثة للقراءة العامة
------------------------------------
النظرة الثالثة نظرة على التفاعل أو التصرف
هذه النظرة على النظام تكمل لنا الجزء الباقي من النظام وهو بعدما عرفنا
تركيب معلومات النظام و ماذا يعمل النظام بقي لنا أن نعرف كيف تتصرف أجزاء
النظام مع بعضها البعض وكيف ينتقل من حالة إلى أخرى.
لكل نظام حالات يكون عليها ويتغير فيها من حالة إلى أخرى حسب نوع التحفيز
الذي يؤثر عليه من عناصر خارجية. لنأخذ مثالا واضحا وهو نظام جهاز بيع
المشروبات. هذا النظام يكون دائما في وضع الاستعداد ويتحفز بوضع قطع معدنية
داخله حتى يصل لمرحلة الاكتفاء و من ثم يحفز بضغط المستخدم على زر اختيار
المشروب المراد ومن ثم يقوم الجهاز بإخراج المشروب والعودة إلى وضع
الاستعداد مرة أخرى. تعرف هذه العملية بجهاز الحالات النهائي أو Machine
State Final.
توفر UML نموذجا يشرح فيه هذه التصرفات للنظام والتي تقوم على مبدأ تحفيز
المستخدم للجهاز و تفاعل النظام مع هذا التحفيز. هذا النموذج يدعى نموذج
الحالات الانتقالية أو"(STD)State Transition Diagram". يتكون النموذج من
شيئين رئيسيين الحالة والانتقال. تمثل الحالة على شكل مستطيل مستدير
الجوانب و يمثل الانتقال على شكل خط يصل بين حالة وأخرى. يكتب على كل خط
الفعل الذي يفعله المؤثر الخارجي وردة فعل النظام. ولتوضيح ما ذكرت نأخذ
مثالا مثل العادة يفصل ما شرحنا.
Figure 5 مكونات State Transition Diagram
لاحظ طريقة كتابة الحالة وكيفية الانتقال من حالة إلى أخرى وكيفية وضع شروط
على الانتقال وبيان نتيجة الانتقال.و تستطيع أن ترى أن هناك بعض الحالات
نضع لها صفات ونستطيع أن نضع لها مواصفات تتصرف على أساسها وبقي لنا أن
نعرف أن لكل نموذج بداية إجبارية ونهاية اختيارية. لأن هناك بعض الأنظمة لا
تتوقف أبدا مثل نظام جهاز المشروبات الذي تكلمنا عنه.أيضا نستطيع أن نضع
نموذج داخل حالة من الحالات مثل الحالة رقم 3. ولو أمعنت في الرسمة لوجدت
أن المستخدم لا يخرج إلا إذا حفز النظام على الخروج بالضغط على زر الخروج.
بالإضافة إلى ذلك لو أراد المستخدم الخروج وهو في الحالة 1 فلا يستطيع ذلك
لأن ليس هناك انتقال معرف بذلك ولكن المستخدم يستطيع الخروج لو كان في
الحالة رقم 4 لأن انتقال الخروج معرف للحالة الأم رقم 3.
المثال القادم هو المثال الذي استخدمناه في أول المقال، نظام البريد. و
أريد أن يلاحظ القارئ الكريم أن كل حالة في نظامنا تقريبا تمثل شاشة حقيقية
عند تطبيق النظام. وقد وجدنا أن للنظام حالات يتغير بينها حسب تحفيز
المستخدم له (حالة الدخول، حالة الدخول الخاطئ،حالة الإرسال ومنها العادي
والسريع ، حالة استقبال البريد و حالة عرض العنوان).
Figure 6 مثال على البريد STD
الآن هذا المثال قد يكون طويلا بعض الشيء ، ولكنه مفيد جدا حيث أنه يمثل
نظاما كاملا تقريبا من حيث التصرف. ينبغي على قارئ المثال أن ينتبه إلى
الحالات التي ينتقل بينها النظام وكيف يؤثر تحفز المستخدم له. فمثلا إذا
بدأ النظام فهو يكون في حالة "تسجيل الدخول" وهي معرفة لدى الجميع. فإذا
ضغط المستخدم على "إرسال" بعدما وفر المعلومات المطلوبة – اسم المستخدم
وكلمة المرور- وكانت هذه المعلومات صحيحة ، فينتقل النظام من الحالة الأولى
إلى حالة الإرسال.
لن أطيل في شرح النموذج لأن يجب أن يكون لدى القارئ في هذه المرحلة القدرة
على قراءة نماذج UML ، لكني سأبين بعض الأشياء التي قد تحتاج إلى توضيح.
لاحظ أي انتقال بين حالة وأخرى تتحدد بتحفز المستخدم ويكتب فوق خط الانتقال
هذا التحفيز (فعل المستخدم). فإذا كان للانتقال من حالة إلى أخرى شرط فيجب
وضع هذا الشرط بين [قوسين] كما في حالة الانتقال من "تسجيل الدخول" إلى
"إرسال" اشترطنا أن تكون عملية الدخول صحيحة. طبعا كلمة "صحيح" التي كتبت
تعني وجود متغير ثنائي القيمة Boolean ليكون قيمة ما بين القوسين إلى "صح
True" عندها ينتقل النظام من هذه الحالة للثانية. فإذا كان للنظام خارجا أو
عملا يؤديه مع الانتقال فيكتب بعد هذه العلامة"/". مثل حالة الانتقال من
"الوارد" إلى "تسجيل الدخول" بعدما أٌمرَ النظام بالخروج عندها يصدر النظام
رسالة "شكرا لك" وينتقل إلى حالة "تسجيل الدخول".
بقي شيء واحد في المثال وهو ما يكون داخل الحالة ، وعادة يكون بعض
الصفاتAttribute و الأهم من ذلك عمل الحالة. فلو نظرنا إلى مثالنا لوجدنا
حالة "البريد الوارد" تعمل عند الدخول "On Entry" باستعادة كل ما في صندوق
الوارد للمستخدم. توجد عدة خيارات أخرى مثل "On Exit" وهي ما يعمل به عند
الخروج من الحالة. يوجد خيارات أخرى تجدها في وثائق UML قد لا تحتاج إليها
الآن.
قبل أنهي النظرة الثالثة على النظام أحب أن أقول أنك قد لا تجد بعض الكتب
تنمذج الحالات بهذه الطريقة ولكني اخترتها لأنها أكثر عملية ، فبعض كتاب
UML لا يضع للحالات صفات. ولكن في الحياة العملية يستخدمونها أكثر على
الرغم أنها ليست في كتب بل طورت مع الخبرة. وبذلك أكون الآن قد أنهيت
النظرة الثالثة وبالتالي الخطوة الأولى في صناعة النظام وهي خطوات
المتطلبات. طبعا يجب علي أن أنوه مرة أخرى أن UML هي أداة لتساعدنا في
هندسة البرمجيات ، وبالتالي إذا لم تعرف ما هي هندسة البرمجيات وكيف تجمع
المتطلبات عندها كل نمذجتك تعتبرها مضيعة للوقت. لذا على أي شخص يتعلم أن
يعرف الثلاثة أشياء التي تكلمنا عنها في موضع غير هذا وهي "ماذا نريد؟" و
"لماذا نريد؟" ومن ثم "كيف نعملها؟".
