هيا للننمذج
تمهيد
كما وسبق أن وعدت بتقديم مثال متكامل للنمذجة بلغة UML، فأنا أقدم بين يدي القارئ الكريم هذه المحاولة المتواضعة مني. عسى أن يجعلها ربنا سبحانه وتعالى ذات فائدة.
مقدمة
تبدأ هذه الورقة بشرح متطلبات المشروع (المثال) المراد شرحه ومن ثم تبين مراحل النمذجة ابتداء من المتطلبات حتى كتابة الكود (الشفرة) بأي لغة كانت (في هذا المثال سنتبع طريقة java أو #C) .
المتطلبات
لنفترض أن زبوننا أراد برنامجا لتنظيم البريد في مكتب الخدمات البريدية. وبعد إجراء اللازم من طرق جمع المتطلبات من مقابلة وقراءة للوثائق وغيرها من الطرق المعروفة لدينا.
ولنفترض أن مجموعة المتطلبات هي كالاتي:
- يستطيع المشترك أن يعمل ثلاث أشياء:
o الإرسال
o الاستقبال
o يغير عنوانه
- يتكون الارسال من أشياء معينة
o ارسال سريع
o ارسال عادي
هذا يكفي وإذا احتجنا متطلبات إضافية ، سوف نقوم بسؤال الزبون عنها.
الخطوة الأولى
الآن نحن في مرحلة جمع المتطلبات وتحليلها. لذا علينا أن ننمذج ما فهمنا حتى الآن من النظام لكي يتبين لنا مدى مقدار فهمنا للنظام الصغير. سنحتاج هنا إلى تطوير ثلاث نظرات للنظام وهي نظرة على العمليات و نظرة على التصرف ونظرة على التركيب. قد يتبادر لذهن القارئ في هذه اللحظة أني أتكلم عن شيء غريب جدا ولكن مع نهاية الورقة سيتبين هذه النظرات ويستطيع التفريق بينها.
إن النمذجة تحتاج الى هذه الثلاث نظرات لتشمل جميع الجوانب الممكنة للبرنامج. أيضا نحتاج الى طريقة للتأكد من أن هذه النظرات متجانسة وتتكلم عن نفس الشيء.
النظرة الأولى نظرة على العمليات
إن UML تقدم نوع من الرسم يدعى Case Use Diagram أو رسمة إستخدام الحالة وأنا أفضل أن أستخدم هنا المصطلح الإنجليزي لأن الترجمة الحرفية للرسمة قد لا تكون دقيقة ولا تؤدي المعنى.
إن Use Case تتكون من ثلاث أشياء رئيسية هي:
1- Use Case وهو عبارة عن مجموعة من العمليات تنفذ عن طريق المستخدم تخدم في النهاية عمل واحد فقط. وتمثل في الرسم بشكل بيضاوي يكتب فيه اسم العملية التي تنفذها الـUse Case.
2- الممثل أو Actor وهو أي شيء يتعامل مع النظام من الخارج قد يكون المستخدم المباشر أو شخص متأثر بالنظام أو حتى نظام آخر يتعامل مع النظام. ويرمز للمثل في هذه الرسمة بشكل رسمة الرجل الاسود.
3- العلاقة أو Acociation or Relation. وهي ما يربط بين "اليوس كيس" وبين الممثل ويرمز لها بخط وله أنواع تجدها في وثائق UML.
مثال على المكونات:
مثال تطبيقي على النظام المعطى:
النظرة الثانية نظرة على التركيب
هنا تقدم UML طريقة رسومية في غاية الأهمية تدعى نموذج الصف المعنوي أو قل onceptualC Class Model. وهنا تأتي خبرة الشخص في الكائنية المنحى ، حيث يتكون النموذج من شيئين مهمين هما الصف Class و الرابط Association.
ويتكون الصف من صفات و تصرفات. وتكون فائدة الصفات في شرح صفات هذا الصف بيد أن التصرفات تشرح أعمال ومسؤليات الصف. يجب أن يكون الصف مترابطا عالي الجانس أي يجب أن يصف ويتكلم عن نفسه فقط ويصف شيئا واحدا فقط.
ليتبين لنا كيف نستخدم هذا النموذج لننظر الى المثال التالي:
نلاحظ هنا أن هناك صفان كرتبطان مع بعضهما بعلاقة معينة تقرأ كالتالي: لـClass2 على الأقل صفر و على الأغلب علاقة واحدة مع Class1. أيضا لـ 1Class على الأقل صفر و على الأغلب عدة علاقات مع 2Class.
ماهي الخيارات المتاحة؟
ان لكل طرف في الرابط عدد يستخدمه ليصف عدد العلاقة مع الطرف الآخر. لذا فمن الممكن أن يكون الطرف (*) ويعني عديد أو (0) ويعني احتمالية عدم وجود العلاقة أو (1) وتسمى أيضا ( ) بدون أي رقم ويعني أن العلاقة من طرف واحد. أيضا لو وضعنا رقمين متجاورين فأحدهما يعني الحد الأقصى والآخر الحد الأعلى.
نستطيع أن نحدد شكل العلاقة هنا بأحد الأنواع التالية:
- علاقة "هو" وتعني علاقة الوراثة المعروفة لدى الكائنية المنحى وهي أن الابن هو الأب بالوراثة.
- علاقة "جزء من" وتعني أن الصف الأول هو "جزء من" الصف الثاني. أي أن الصف الأول هو في الأساس صفة موجودة في الصف الثاني.
هذا مثال آخر يوضح كل شيء:
نلاحظ هنا أن الشخص يحمل الصفات التالية ( الاسم من نوع حرف و هوية من نوع رقم و تاريخ ميلاد من نوع حرف) لاحظ أن لكل صفة إسم ونوع. هذه الأنواع معروفة في لغات البرمجة مثل (الحرف ، الأعداد ، بوليان "صح أم خطأ"). طبعا الصفان "أب" و "إبن" يأخذان تلك الصفات بالوراثة بالإضافة إلى الصفات المعينة لكل من هما. وقد تم رسم علاقة الوراثة بالسهم المفرغ كما هو مبين في الرسمة. وتقرأ علاقة الوراثة كالتالي: (الأب هو شخص) و (الإبن هو شخص).
هناك شيء آخر وهو علاقة "التجزء" أو سمها علاقة "البعض من كل". في الحقيقة للصف "شخص" يوجد 4 صفات ذكرت 3 منها سابقا أما الرابعة هي صفة "العنوان". ولأنها صفة معقدة – أي تكون صفا بذاته- لذا استخدمنا علاقة "الجزئية" و تقرأ كما سبق وشرحنا هكذا: ("العنوان" جزء من "الشخص" أو "الشخص" يحوي "عنوان"). أيضا لو نلاحظ أن "الهاتف" جزء من "العنوان" و "بريد_إلكتروني" جزء من "العنوان".
توضيح مهم: ما هو الفرق بين علاقة "العنوان" مع "شخص" وبين علاقة "الهاتف" مع "العنوان"? إن علاقة "الجزئية" الملونة باللون الأسود- أو مصمتة إذا أردت الدقة- تسمى علاقة "الجزئية القوية Composition " و الأخرى تسمى علاقة "الجزئية العادية Aggregation". وتسمى علاقة "الجزئية القوية" بهذا الاسم لأن طرفي العلاقة لا يتغنيان عن بعض و يتطلب وجود أحدهما الآخر. مثل أننا لا نستطيع في النظام الموصوف لدينا في الرسمة أن نسجل شخصا بدون عنوان. أو بمعنى آخر لا نستطيع أن يكون لدينا عنوان ما بدون شخص مرتبط به.
الآن وقد وضحت صورة الرسمة ، ما بقي سهل جدا وسنقرئه سريعا. العنوان يتكون من الآتي : قد لا يحوي بريدا إليكترونيا وقد يحوي العديد منه للشخص الواحد. أيضا إن العنوان قد لا يحوي هاتفا وقد يحوي إلى ثلاثة هواتف للشخص الواحد.
وفي النهاية نقرأ العلاقة بين الأب والإبن. إن الأب والإبن هما في النهاية شخص. و قد يكون لكل أب إبن يربيه. ولكن لكل ابن أب وحد فقط.
لكل أنهي هذا الفصل أو الرؤية الثانية للنظام أحب أن أنبه على أن المتعلم للـUML يجب أن يقرأ وثائق UML ليعرف باقي التفاصيل. لأن هناك أشياء كثيرة لم أذكرها مثل أنواع الصفوف "الكلاسات" و طرق بناء العلاقات. وقد اعتقدت أن ما تم تبيانه هنا كاف للبدء للنمذجة. وشيء آخر هو أن ما كتبته كان باللغة العربية وهذا مخالف لما يجب أن يكون عليه نموذج UML.
تصحيح
" أو قل onceptualC Class Model"
والصحيح
"Conceptual Class Model"
لا تقلقوا عندما اصدر الملف النهائي سيكون بدون أخطاء
ولكني هنا اعرضه لكي يصحح لي المختصين
هذا الجزء الأول كاملا
لكم حرية التصرف فيه
أعطيكموه على شكل ملف وورد
و أي تعديل أو سؤال
أخبروني به و أنا جاهز
وإن شاء الله سأبدأ في الجزء الثاني غدا
مرفق ملف أكروبات و ورد أيضا
للقراءة ولأي تعديل حتى الأكروبات بدون حماية (h)
ملف مرفق(ملفات)
هيا للننمذج.doc (81.5كيلو )
وهذا أكروبات
ملف مرفق(ملفات)
هيا للننمذج.pdf (353.85كيلو )