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

جدول التنقل

1. مخطط واقعة استخدام The Use Case Diagram
2. مخطط الصنفيات The Class Diagram
3. مخططات التعاون  The Collaboration Diagrams
4. مخطط التتابع  Sequence Diagram
5. مخططات الحالة State Diagrams
6. مخططات التحزيم  Package Diagrams
7.  مخططات المكونات Component Diagrams
8. مخططات التجهيز Deployment Diagrams
9. ملخص

نبذة عامة عن UML

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

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

·        المحلّلون

·        المصمّمون

·        المبرمجون

·        القائمون بالاختبار

·        مراقبو الجودة

·        المستفيدون

·        الكتّاب التقنيون

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

مخطط واقعة استخدام The Use Case Diagram

شكل 13: مخطّط واقعة استخدام

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

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

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

مخطط الصنفيات The Class Diagram

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ملخص

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

·        وقائع الاستخدامUse Cases - "كيف سيتفاعل نظامنا مع العالم الخارجي؟"

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

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

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

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

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

·        مخطط المكونات Component Diagram - "كيف سترتبط مكونات برنامجنا؟"

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

قد يعجبك ايضا

تعديل المقال