King Saud University
  Help (new window)
Search


Guidelines_English_Final
تحميل الدليل التدريبي

أسئلة شائعة


 

 

تقــــــــــــــرير عن النمذجة الموحدة

 

 

إشـــــــــــــــراف دأ/

محمد سعيد المهدي

 

 

 

 

 

 

 

 

 


ماهو ال UML ؟

لغة النمذجة الموحّدة Unified Modelling Language ، أو UML ، هي لغة نمذجة رسومية تقدم لنا صيغة لوصف العناصر الرئيسية للنظم البرمجية. (هذه العناصر تسمّى artifacts مشغولات في UML). في هذه الفصول سوف نستكشف النواحي الرئيسية في UML ، و نصف كيف يمكن تطبيق UML في مشروعات تطوير البرمجيات.

بطبيعتها تتّجه UML نحو بناء البرمجيات كائنية المنحى object oriented ، لذلك سوف نستكشف بعض أهم مبادئ المنحى الكائني.

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

لغة مشتركة

الصناعات الأخرى لديها لغات و رموز خاصة بها، و يفهمها كل من له علاقة في حقل اختصاص معين.


شكل 1 ـ معادلة رياضية للتكامل

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

لمدة، كان مهندسوا البرمجيات يفتقرون لمثل هذه الرموز. بين عامي 1989 و 1994، و هي الفترة التي يشار إليها بـ "حروب المناهج"، كان يوجد ما يزيد عن 50 لغة نمذجة برمجية قيد الاستعمال - كل منها تملك رموزها الخاصة!  كل لغة تحتوي على قواعد تميزها، بينما في نفس الوقت، كل لغة لديها عناصر تتشابه مع تلك التي في اللغات الأخرى.

و لمزيد من الفوضى، لا توجد لغة متكاملة، بحيث نادرا ما يجد مسؤولوا البرمجيات ما يرضي كامل حاجتهم في لغة واحدة!

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

  •  بوش Booch كانت ممتازة فيما يخص التصميم و التنفيذ. لقد عمل "قرادي بوش" Grady Booch بكثافة على لغة آدا Ada، و كان له دور رئيسي في تطوير تقنيات المنحى الكائني object oriented للغة. و بالرغم من قوة منهجية بوش إلا أن الرموز فيها لم تأخذ القبول الحسن (الكثير من الأشكال السحابية تغزو نماذجه - ليست بالجميلة!)
     
  • OMT (تقنية النمذجة الكائنية Object Modelling Technique) كانت الأفضل في التحليل و في أنظمة المعلومات ذات البيانات الكثيفة.
     
  • OOSE (هندسة البرمجيات كائنية المنحى Object Oriented Software Engineering) و تتميز بنموذج يسمى Use Cases حالات الاستخدام. تعد حالات الإستخدام أسلوب قوي من أجل فهم سلوك كامل النظام (و هو المجال الذي كان فيه المنحى الكائني ضعيفا).

 في عام 1994، قام جيم رامبخ Jim Rumbaugh، مؤسس OMT، بمفاجأة عالم البرمجيات حين ترك العمل بشركة جنرال الكتريك General Electric و انضمّ مع قرادي بوش للعمل في مؤسسة راشيونال Rational Corp. الغرض من المشاركة كانت من أجل دمج أفكارهما و صبّها في منهجية موحدة (و كان بالطبع عنوان العمل لهذه المنهجية هي "المنهجية الموحدة" Unified Method).

مع عام 1995، انضم أيضا مبدع OOSE ايفار جاكوبسون Ivar Jacobson، إلى راشيونال، و تم ضم افكاره (خاصة مفهوم "قضايا الاستخدام" Use Cases) في المنهجية الموحدة - الآن تدعى لغة النمذجة الموحدة Unified Modelling Language.* وعُرف الفريق الذي يتكون من رامبخ و بوش و جاكوبسون بـ "الأصدقاء الثلاثة" Three Amigos.

بغض النظر عن بعض الحروب و المشاحنات البسيطة، بدأت المنهجية الجديدة تجد استحبابا لدى أوساط صناعة البرمجيات، فتم تكوين لجنة مشتركة consortium خاصة بـ UML، شاركت فيها عدد من المؤسسات ثقيلة الوزن مثل هيولت-باكارد Hewlett-Packard و ميكروسوفت Microsoft و أوراكل Oracle.

كما تم تبنّي UML من قبل مجموعة OMG ** في 1979، و من حينها امتلكت OMG اللغة و دأبت على صيانتها. لذلك عمليا اصبحت لغة UML عامة وليست ملكية خاصة.

 

ملخص

UML هي لغة رسومية للتعبير عن منتجات artifacts التطوير البرمجي.

تقدم لنا اللغة رموزا ننتج بها النماذج.

تلقى UML تبنيا واسعا في الوسط الصناعي كلغة موحدة.

في الأصل تم تصميم لغة UML من قبل الأصدقاء الثلاثة في مؤسسة راشيونال.

اللغة غنيّة جدا، و تحمل في طيّاتها العديد من جوانب أفضل الممارسات في هندسة البرمجيات.

 

 

 

 

 

 

 

 

 

 

 

 

 

UMLداخل عملية التطوير

 

UML كترميز

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

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

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

النموذج الإنحداري Waterfall Model


شكل 2: النموذج "الانحداري" التقليدي.

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

هذه العملية المبسطة (و التي يسهل ادارتها) تبدأ بالتداعي بمجرد أن يزداد تعقيد و حجم المشروع. أهم مشاكلها هي:

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

 


شكل 3: في النموذج الانحداري، تتزايد المخاطر وتكلفة تصحيح الأخطاء مع مرور الزمن.

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

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

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

النموذج اللولبي

الاسلوب البديل هو النموذج اللولبي، حيث نقوم بالتصدّي للمشروع عن طريق تقسيمة إلى سلسلة من الدورات الحياتية lifecycles القصيرة ، كل دورة تنتهي باصدار لبرنامج قابل للتنفيذ.


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

مع هذا الاسلوب:

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

عيوب العملية اللولبية هي:

  • عادة ما ترتبط هذه العملية بما يعرف بالتنشئة السريعة للتطبيقات Rapid Application Development ، و التي تعتبر من قبل كثيرين مجرد hacker's charter.
  • العملية أكثر صعوبة في إدارتها. في النموذج الانحداري يمكن الاستعانة بالتقنيات التقليدية لإدارة المشروعات مثل مخططات كانط Gantt، لكن العمليات اللولبية تتطلب أساليب مختلفة.

من أجل تدارك عيوب العملية اللولبية، لنلقي نظرة على أسلوب مشابه لكن أكثر تقنينا و يدعى اطار العمل التكراري التزايدي Itrative, Incremental Framework.

 

اطار العمل التكراري التزايدي

اطار العمل التكراري التزايدي Itreative, Incremental Framework هو امتداد منطقي للنموذج اللولبي، لكنه أكثر تقنينا و صرامة. سوف نقوم بتبنّي اطار العمل التكراري التزايدي خلال بقية هذه الدروس.

ينقسم اطار العمل الى أربعة أطوار رئيسية: الاستهلال Inception، التفصيل Elaboration، البناء Construction و التنقل Transition. يتم انجاز هذه الأطوار على التوالي، لكن يجب أن لا نخلط بين هذه الأطوار و المراحل في الدورة الحياتية للنموذج الانحداري. في هذا القسم سوف نشرح هذه الأطوار و نستعرض النشاطات التي يتم أداؤها في كل طور.


شكل 5: الأطوار الأربعة لإطار العمل التكراري التزايدي

الاستهلال

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

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

سوف نناقش طور الاستهلال بشيء من التفصيل عندما نتعرض لدراسة حالة case study في الفصل الرابع.

التفصيل

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

نموذجان من UML يكون لهما قيمة كبيرة في هذه المرحلة. نموذج حالة الاستخدام Use Case سيساعدنا في متطلبات المستفيد= الزبون ، و مخطط الطبقة Class Diagram و الذي ايضا يمكن استخدامه لاستكشاف المفاهيم العامة التي يتصورها المستفيد. المزيد حول هذا الموضوع قريبا.

 

البناء

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


شكل 6: طور البناء و يحتوي على سلسلة من الانحدارات المصغرة.

مع نهاية أكبر عدد من من التكرارات سوف نطمح في الحصول على منظومة تعمل (مبدئيا بالطبع، ستكون منظومة محدودة جدا في المراحل المبكرة). هذه التكرارات تسمّى تزايدات Increments، ومن هنا أتت تسمية اطار العمل هذا!

التحوّل (الانتقال) Transition

الطور النهائي يتعلق بنقل المنتج النهائي الى الزبائن. النشاطات المعتادة في هذا الطور تتضمن:

  • الاصدارات المبدئية لأغراض الاختيار من قبل بيئة المستخدم.
  • الاختبارات في الموقع، أو تشغيل المنتج بالتوازي مع النظام القديم الذي سيستبدل.
  • تجهيز البيانات (مل تحويل قواعد البيانات و صبّها في قوالبها الجديدة، توريد البيانات ، الخ..)
  • تدريب المستخدمين الجدد.
  • التسويق والتوزيع و المبيعات.

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

كم عدد هذه التكرارات؟ و كم يجب ان تطول؟

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

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

فيما يلي بعض العوامل التي يجب أن توثر في طول مدّة النكرار:

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

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

القيد الزمني Time Boxing

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

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

احدى النصائح لكيفية تطبيق القيد الزمني، أن يكون المطورون هم المسؤولون (أو على الأقل الكلمة العليا) عن تحديد ما هي المتطلبات التي يتم تغطيتها في كل تكرار ، باعتبارهم الذين سوف يلتزمون بهذه الآجال.

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

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

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

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

التوقيتات النمطية للمشروع

كم يجب ان يستغرق كل طور من الأطوار الأربعة؟ هذا يتباين من مشروع لآخر، و لكن كمؤشّر عام 10% للإستهلال، 30% للتفصيل، 50% للبناء و 10% للإنتقال.

شكل9: التوقيتات المحتملة لكل طور. هذا المثال يوضح طول كل طور لمشروع يستغرق سنتين.

العملية الموّحدة من راشيونال

The Rational Unified Process

العملية الموحّدة من راشيونال (the RUP)  هي المثال الأكثر شهرة للدورة الحياتية التكرارية قيد الاستعمال حاليا. تم تطوير RUP من قبل نفس "الاصدقاء الثلاثة" الذين قاموا بتطوير UML ، و لذلك فان RUP متكاملة جدا مع UML.

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

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

و قد اصدرت مؤسسة راشيونال منتوجا لمساعدة المشاريع التي تتبنى RUP و يمكن ايجاد المزيد من التفاصيل في www.rational.com . المنتوج بالأساس عبارة عن دليل على شبكة الانترنت يضم جميع ملامح RUP. و تقدم الشركة امكانية استعمالة على سبيل التجربة لمدة 30 يوما.

vcb

 

شكل 8: لقطة من RUP 2000 (مؤسسة راشيونال).

تفصيل مزايا و عيوب RUP خارج نطاق درسنا هذا، و لكن بصفة عامة فان أساس RUP هي الدورة الحياتية التكرارية التزايدية و التي سيتم تبنّيها خلال دروسنا هذه,

موجز

اطار العمل التكراري التزايدي يقدم العديد من الفوائد مقارنة بالعمليات التقليدية.

اطار العمل هذا ينقسم الى أربعة أطوار الاستهلال، النفصيل، البناء، الانتقال.

التطوير التصاعدي يعني استهداف الحصول على توليف قابل للتشغيل في نهاية كل تكرار (بأكبر عدد ممكن منها).

التكرارات يمكن تقييدها زمنيا كأسلوب صارم لجدولة و مراجعة التكرارات.

بقية هذه الدروس سوف تركز على اطار العمل Framework ، و كيف تقوم UML بدعم مخرجات كل طور في اطار العمل.

 

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

 

 البرمجة المهيكلة

أولا، لنختبر بصورة سريعة كيف يتم تصميم الأنظمة البرمجية باستخدام الاتجاه المهيكل (احيانا يُسمّى وظائفي Functional).

في البرمجة المهيكلة Structured Programming، الطريقة المتّبعة عامة هي النظر الى المسألة، ثم تصميم مجموعة من الوظيفيات functions التي يمكنها انجاز المهام المطلوبة لحلها. اذا تضخّمت هذه الوظيفيات ، يتم تجزئتها حتى تصير صغيرة بالحدّ الذي يتيسّر فيه مناولتها و فهمها. هذه العملية تدعى التفكيك الوظائفي functional decomposition.

معظم الوظيفيات ستحتاج الى بيانات من نوع ما لتعمل عليها. البيانات في الأنظمة الوظائفية عادة ما يحتفظ بها في قاعدة بيانات من نوع ما (أو قد يحتفظ بها في الذاكرة كمتغيّرات شاملة global variables) .

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

التصميم الوظائفي المحتمل سيتضمّن كتابة الوظيفيات functions التالية:

 

اضافة طالب

add_student

دخول امتحان

enter_for_exam

فحص علامات امتحان

check_exam_marks

اصدار شهادة

issue_certificate

طرد طالب

expel_student

 

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

الآن بدأ واضحا أن الوظيفيات functions التي حدّدناها سابقا سوف تعتمد على هذه المصفوفة من البيانات. مثلا، وظيفة "add_student" (اضافة طالب) ستقوم بتغيير محتويات  "Students" (طلبة)، و وظيفة "issue_certificate" (اصدار شهادة) تحتاج الى الوصول الى بيانات طالب Student (لمعرفة تفاصيل الطالب الذي يحتاج للشهادة) و ستحتاج الوظيفة ايضا الي بيانات الامتحانات Exam .

المخطط diagram التالي عبارة عن رسم لكل الوظيفيات، مجتمعة رفق البيانات، و رسمت الخطوط فيها حيثما وجدت اعتمادية dependency .


خريطة الوظائف، و البيانات و الاعتماديات.

المشكلة مع هذه المقاربة أن المسألة التي نتعامل معها اذا ما تعقدت أكثر ستزداد صعوبة المحافظة على المنظومة و صيانتها. فلو اخذنا المثال أعلاه، ماذا سيحدث لو تغيّرت المتطلبات requirement  بطريقة تؤدّي الى تغيير اسلوب مناولة بيانات الطالب Student.

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

المشكلة الجدية لهذا التغيير تنبع من أنه قد يسبّب في ظهور اثار جانبية غير متوقعة. فبيانات جدول الامتحانات Exam و جدول الدورات Courses و جدول المدرّبين Tutors كلها (بطريقة أو باخرى) تعتمد على بيانات جدول الطالب Students، لذا قد نتسبب في كسر بعض العمليات بتغييرنا البسيط هذا، و اعاقة  وظيفيات add_student و enter_for_exams و issue_certificate و expel_student ، فوظيفة add_student لن تعمل بالتأكيد لأنها تتوقع ان تكون المعلومة الخاصة بسنة الميلاد على شكل رقم بخانتين بدلا من أربع.

 اذا، لدينا معدل كبير من المشاكل المحتملة، و الأسوأ اننا لن نستطيع بسهولة تعيين اماكن الاعتمادية في التوليف code التي ستتأثر بهذا التغيير.

 

 

الممثل Actor

هو عبارة عن شيء أو شخص يقوم بالتعامل مع النظام الذي نهدف إلى تصميمه النظام حتى

يقوم النظام بإعطائنا النتاج التي نتوقعها , يمكن أن نتخيل مكان الـ Actor على الحدود

الخارجية للنظام , الـ Actor يقوم بتقسيم القوانين التي يقوم المستخدمون الحقيقيون بإستخدامها

في النظام و ذلك لأهداف مختلفة , منها التميز بين العمليات ونوعيتها و كيفية الوصول إليها

والتحكم في البيانات, فيتم التخاطب مع النظام بأفضل صورة. وذلك مثل الأنظمة الطرفية مثل

الطابعة اللتي تقوم بإستقبال مدخلاتها من النظام الرئيسي مثل الخادم الرئيسي للشركة.


النظام ممكن أن يحتوي على ممثلActor أو أكثر من ممثل. المستخدم الطبيعي الذي يحمل أكثر

من قاعدة للإستخدام ممكن أن يقسم إلى أكثر من ممثل واحد.


الفئات Classes تعتبر التمثيل التنفيذي للـActor , ويمكن لأي ممثلActor أن يحمل

خصائص attributes مثل أي فئة إعتيادية .


الشكل 1 يمثل التدوين الرسومي في لغة UML للـActor المكون من رجل العصاه

stick-person
الذي يمثل المستخدم الحقيقي للنظام. وهنا يتم إستخدام تمثيل يشبه الفئة

Class
حتي يمثل المستخدمين غير الحقيقين. كل ممثلActor تم إعطائه إسم حتى

يعكس دور الممثل في النظام.


الشكل 1 التدويل للـ Actor في لغة UML


أنظر إلى الشكل 2 الذي يعرض ثلاثة ممثلين Actors : الوسيط Broker , الشاري Buyer ,

البائع Seller . في نظام بيع وشراء الممتلكات real estate system .


الوسيط أو السمسار Broker عبارة عن Actor يمثل المالك للنظام , وبإمكانه أن يستخدم النظام

في عمل تحديثات لبينات الممتلكات estate property في النظام.


الشاري والبائع Buyer & Seller عبارة عن Actors يستطيعوا إستخدام النظام من خلال

التصفح في قائمة الممتلكات المتاحة للبيع أو قائمة الأماكن المعروضة للبيع

,
أو طلبات البيع . مع الملاحظة هنا أن الوسيط والبائع والشاري ممكن أن يكونوا عبارة عن

وظائف يقوم بها شخص واحد هو المالك للنظام بيع وشراء الممتلكات.


أيضا يمكن أن يكون نفس الـActor يمثل أكثر من مستخدم حقيقي لنظام بيع وشراء ممتلكات على

شبكة الإنترنت . حيث يقوم البائع والشاري بالتخاطب من خلال الموقع ,من خلال سرد البائع

لمجموعة العقارات التي يريد أن يبيعها من خلال التسجيل ودفع مبلغ معين حتى يتم عمل إعلان

له في الموقع . ويقوم الشاري بالتصفح في الموقع ثم يختار العقار المراد. بعد ذلك يتم التخاطب

إما بالبريد الإلكتروني أو الهاتف أو من خلال تحديد موعد معين.


الشكل 2 Actors في نظام بيع وشراء الممتلكات



الشكل 3 يظهر ثلاثة ممثلين Actors : موظف مستودعات Warehouse Employee ,

الزبون Customer والبائع Vendor في نظام برمجي للمستودعات في شركة إعادة بيع

البضائع reseller company .


حيث يقوم نظام المستودعات بشراء البضائع من البائع Vendor حسب الطلب وتخزينها في

المخازن , ثم يتم عرض البضائع على الزبائن Customers ليشتروها .


موظف المستودع Warehouse Employee هو المستخدم الفعلي المباشر Active user للنظام .

وهو اللذى يقوم بعمل تعديل على البيانات في قاعدة بيانات المخزن .


البائع Vendor عبارة عن ممثل غير مباشر passive actor حيث يقوم بإستلام طلب من ممثل

الزبون Customer Actor من خلال نظام المستودعات, ويتم الإجابة على هذه الطلبات إذا تم

تفعيلها من قبل موظف المستودعات.


الشكل 3 الممثلين في شركة إعادة بيع البضائع reseller company


فآت الممثل Actor categories


بشكل عام , يحوي الممثل Actor فأتين مختلفتين هما :

ممثل مباشر Active Actor , الذي يقوم يعمل بدء نشاط معين في النظام , ويمكن إعتباره أي شخص أو آلة أو شيء

يستخدم النظام ليقوم بعمل مهمة معينة مباشرة مع أدوات التحاور المباشرة مع النظام, مثل شاشات الحوار , وشاشات

إدخال وتعديل البيانات أو الإعدادات.


النوع الآخر هو ممثل غير مباشر passive Actor , هو الممثل الذي يقوم بإستلام طلب من النظام و يتم تفعيله من

خلال ممثل آخر, فهو لا يقوم بالبدء بنشاط معين في النظام من نفسه بل يستلم أوامر بالبدء بالنشاط.



مثال على ذلك ,ممثل موظف المستودعات Warehouse Employee Actor من الشكل 3 فهو عبارة عن ممثل

مباشر Active Actor لأنه يقوم بتعين مهمات وطلبات للنظام مباشرة , البائع Vendor عبارة عن ممثل غير

مباشر Passive Actor لأنه يستجيب للطلبات من النظام عندما يتم عمل طلبات من

خلال ممثل موظف المستودعات Warehouse Employee Actor.


الشكل 4 يظهر ممثلين مباشرين Active Actors و ممثل غير مباشر Passive Actor : موظف Employee ,

الزبون Customer , و نظام

محاسبة Accounting system في برنامج تأجير سيارات.


النظام يسمح للمستخدمين بأن يقوموا بعمل حجز لإسأجار السيارات ,ويقوم نظام تثمين الأجرة بحساب القيمة من

خلال نظام الحسابات المراد بنائه.


كلا الموظف Employee والزبون customer من نوع ممثل غير مباشر Active Actors الموظف

عبارة عن ممثلActor مسئول عن نظام الحجز, اما الزبون customer عبارة عن ممثلActor يستخدم النظام

حتى يأثر على عملية الحجز, الموظف والزبون عبارة عن ممثلين Actors مختلفين لأنهم يلعبان دور مختلف في النظام.


نظام المحاسبة Accounting system عبارة عن ممثل غير مباشر

passive actor
يقوم بإستقبال حجوزات الطلب ,ويقوم بحساب القيمة الفعلية

للإستئجار , ولم يتم تمثيل نظام المحاسبة من خلال شكل رجل العصاه إعتباره

مستخدم غير مباشر, وتم الإستعاضة عنه بتمثيل فئة أو نظام يقوم بتمثيل الممثل الغير حقيقي.



الشكل 4 ممثل في نظام إستئجار سيارات .


التعميم بين الممثلينamong Actors Generalization

الممثل يمكن أن يتصل مع ممثل آخر من خلال علاقات مختلفة مثل علاقة التعميم generalization relationship .

وهنا يمكن تفسير ذلك من خلال أن علاقة التخصيص Specialization عبارة عن عكس العلاقة المقابل لعلاقة

التعميم Generalization و هي تشابه في طبيعتها علاقة التوريث inheritance بين الفئات Classes .


الشكل 5 يمثل الصورة العامة لعلاقة التعميم , وهي ممثلة بالعلاقة بين الممثل Actor A اللذي يحمل علاقة تعميم generalization

مع الممثل Actor B يمكن فهمها من خلال العبارة التالية B inherits A أي B يرث A في أي وقت يمكن اعتبار

العلاقة السابقة أنها تعني B is-a A أي B عبارة عن A وهذه العلاقة تسمح للممثل B بلعب جميع الأدور التي يقوم بها

الممثل A , وعلى العكس ليس شرط أن تكون جميع الأدوار التي يقوم بها A يقوم بها Bأي أن B يستطيع أن يستخدم النظام

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

الشكل 5 الشكل العام لعلاقة Generalization بين الممثلين A & B


علاقة الـ generalization هي علاقة تحويلية من طرف واحد, بناء على ذلك إذا كان

هنالك علاقة تعميم generalization بين ممثل A و ممثل B وفي نفس الوقت هنالك علاقة

تعميم بين الممثل B والممثل C , يكون عندنا علاقة generalization بين الممثل A والممثل C , وبناء على ذلك فإن الممثل C يمكنه

القيام بالمهام التي تم تقسيمها للممثل A .


لنأخذ مثال على ذلك كما في الشكل 6 اللذي يظهر تطبيق على علاقة generalization بين ممثلين Actors الأول هو الزبون Customer

والثاني هو الموظف Employee . فهنا نقوم أن الموظف ممكن أن يكون زبون في وقت معين عندما يريد أن يستأجر سيارة , أما الزبون

ليس شرط أن يكون موظف .

الشكل 6 علاقة Generalization بين الموظف والزبون


لوضع مثال آخر كما يظهر في الشكل 7 لنا علاقة التعميم Generalization بإمكانية أن تتم من خلال أن الممثل يمكن أن

يكون له أكثر من تحدر واحد في الروابط . مثل أن الممثل IT Manager يمكن أن يكون له علاقة مع ممثلين هما مدير

النظام System Manger و مدير الأمن المعلوماتي Information security manger , هنا نجد أن مدير النظام يمكن أن يقوم

بما يقوم به الـ IT Manager , و في نفس الوقت يمكن أن يقوم مدير الأمن بمهام الـ IT manger , لكن هنا ماذا يقوم

الـ IT Manger ؟ يمكن أن نقول أنه يقوم بمهام إدارية غير متخصصة بمهام معقدة , بل المهام الإعتيادية.

الشكل 7 تمثيل لعلاقة التعميم لأكثر من ممثل .


هنا يجب أن نفهم أن الممثل Actor يمكن أن يكون والد لأكثر من ممثل

فيمكن أن يقوم الممثل المورث بكل مهام الممثل الأب .



الخلاصة

في هذا الدرس تم تعريف الممثل Actor والتمثيل الرسومي له و توضيح

كيف تتم ربط العلاقات بما بين الممثلين الآخرين في اللغة , طبعا يوجد هنالك علاقات

أخرى مع أجزاء الأخرى في لغة النمذجة الموحدة.

King   Saud University. All rights reserved, 2007 | Disclaimer | CiteSeerx