الفصل 4
نبذة عامة عن UML

<H2 align=right></H2>قبل أن نخوض في نظرية UML ، سنقوم بجولة مختصرة للإطلاع على بعض المفاهيم الأساسية ل UML.

أوّل ما يتم ملاحظته عن UML هو أنه يوجد العديد من المخطّطات المختلفة (نماذج) و التي يجب التعوّد عليها. السبب في هذا التنوّع يعود ألى ان المنظومة يُحتمل أن يُنظر اليها من زوايا مختلفة بحسب المشاركين فيها . تطوير البرمجيات يشترك فيه عدد من الأفراد، و كل واحد له دور - مثلا:

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

فيما يلي نظرة سريعة لبعض أهم هذه المخططات. بالطبع، سوف نتعرّض لها بمزيد من التفاصيل مع تقدّم هذه الدروس:




<H2>مخطط حالة الاستخدام
The Use Case Diagram</H2>
مصغرة بنسبة : 86% من الحجم الأصلي [ 295 x 378 ] - إضغط هنا لعرض الحجم الأصلي


شكل 13: مخطّط حالة استخدام



حالة الاستخدام Use Case هي وصف لسلوك النظام من وجهة نظر المستخدم. فهي ذات فائدة خلال مراحل التحليل و التطوير، و تساعد في فهم المتطلبات.

يكون المخطط سهلا للاستيعاب. مما يمكّن كلا من المطوّرين (محلّلون، مصمّمون، مبرمجون، مختبرون) و المستفيدون (الزبون) من الاشتغال عليه.

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


مخطط الأصناف
The Class Diagram


مصغرة بنسبة : 46% من الحجم الأصلي [ 555 x 390 ] - إضغط هنا لعرض الحجم الأصلي


شكل 14: مخطط الأصناف

رسم مخططات الأصناف جانب أساسي لأي منهج للتصميم بالمنحى للكائن، لذلك ليس بالغريب أن تقدّم لنا UML الصيغة المناسبة له. سوف نرى أنه بامكاننا استخدام مخطط الأصناف في مرحلة التحليل و كذلك في مرحلة التصميم - سوف نقوم باستعمال صيغ مخططات الأصناف لرسم خريطة للمفاهيم العامة التي يمكن للمستفيد = الزبون أن يستوعبها (و سوف نسمّيها النموذج المفاهيمي Conceptual Model). وهي بالاضافة الى مخطط حالة الاستخدام، تجعل من النموذج المفاهيمي أداة قوية لتحليل المتطلبات.




مخططات التعاون
The Collaboration Diagrams


مصغرة بنسبة : 54% من الحجم الأصلي [ 470 x 368 ] - إضغط هنا لعرض الحجم الأصلي


شكل 15: مخططات التعاون.

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

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




مخطط التتابع
Sequence Diagram

مصغرة بنسبة : 53% من الحجم الأصلي [ 477 x 362 ] - إضغط هنا لعرض الحجم الأصلي


شكل 16: مخطط التتابع في UML.

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

بعض أدواة نمذجة UML ، مثل برنامح ناشيونال روز Rational Rose، يمكنها توليد مخطط التتبابع آليا من مخطط التعاون، و هذا ما حدث تماما عندما تم رسم المخطط أعلاه - مباشرة من المخطط الذي في الشكل 15.




مخططات الحالة
State Diagrams



شكل 17: مخطط حالة التحوّل.

بعض الكائنات يمكنها في أي وقت محدد أن تكون في حالة ما. مثلا، يمكن للإشارة الضوئية في إحدى الحالات التالية:

مطفأة، حمراء، صفراء، خضراء.

أحيانا، يكون تعاقب التحوّلات بين الحالات معقّد جدا - في المثال أعلاه ، لا يمكننا أن ننتقل من حالة "خضراء" إلى حالة "حمراء" (و إلا تسبّبنا في حادث!).

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

خذ مثلا - فاتورة غاز مرسلة الى مستهلك توفّي منذ أربع سنوات - هذا يحدث في الواقع و سبب ذلك أن المبرمج في نقطة ما لم يأخذ في اعتباره تحوّلات الحالة.

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




مخططات التحزيم
Package Diagrams


مصغرة بنسبة : 65% من الحجم الأصلي [ 390 x 327 ] - إضغط هنا لعرض الحجم الأصلي


شكل 18: مخططات التحزيم في UML.

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




مخططات المكونات
Component Diagrams


مصغرة بنسبة : 57% من الحجم الأصلي [ 447 x 265 ] - إضغط هنا لعرض الحجم الأصلي

شكل 19: مخطط المكونات في UML.

يتشابه مخطط المكونات مع مخطط التحزيم - فهو يسمج لنا يترميز كيفية فصل أو تقسيم نظامنا، و كيف يعتمد كل قالب على آخر فيه. عموما، يركّز مخطط المكونات على المكونات الفعلية للبرنامج (الملفات، الترويسات headers، مكتبات الربط، الملفات التنفيذية، الحزم packages) و ليس بالفصل المنطقي أو الفكري كما في مخطط التحزيم. ثانية، سوف نتعمق في دراسة هذا المخطط في فصل معماريات النظام.




مخططات التجهيز
Deployment Diagrams


مصغرة بنسبة : 51% من الحجم الأصلي [ 500 x 288 ] - إضغط هنا لعرض الحجم الأصلي

شكل 20: مخطط التجهيز في UML.

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




موجز
يوفّر UML عدة نماذج مختلفة لوصف النظام. القائمة التالية تعرضها كلها مع جملة واحدة توجز الغرض من كل نموذج:


Use Cases
وقائع الاستخدام

- "كيف سيتفاعل نظامنا مع العالم الخارجي؟"
Class Diagram
مخطط الأصناف

- "ما هي الكائنات التي نحتاجها؟ و ما علاقتها؟"
Collaboration Diagram
مخطط التعاون

- "كيف تتعامل الكائنات مع بعض؟"
Sequence Diagram
مخطط التتابع

- "كيف تتعامل الكائنات مع بعض؟"
State Diagram
مخطط الحالة

- "ما الحالات التي يجب أن تكون عليها الكائنات؟"
Package Diagram
مخطط التحزيم

- "كيف سنقوم بقولبة عملنا؟"
Component Diagram
مخطط المكونات

- "كيف سترتبط مكونات برنامجنا؟"
Deployment Diagram
مخطط التجهيز

- "كيف سيتم تجهيز البرنامج؟"