العودة   منتديات طلاب الجامعة العربية المفتوحة > منتديات المشرفين والمنتديات المساعدة > أرشيف المواد والمواضيع القديمة > أرشيف الملخصات لمناهج تم تغييرها > M301

إضافة رد
 
أدوات الموضوع انواع عرض الموضوع

قديم 09-03-2010, 11:43 PM   #1
البلسم البلسم غير متصل
طالب فضي
 
الصورة الرمزية البلسم
تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]



هذا شرح مبسط ., لـ UML مترجم للغة العربية .,~



......




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

UML ترميز

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

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

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



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

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

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

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

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

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




أيضا، حيث أن مرحلة التحليل تنجز في مخاض قصير مع تدشين المشروع، سنواجه مخاطرة جدية تتمثل في القصور في فهم متطلبات الزبون. حتى لو التزمنا باجراءات صارمة لادارة المتطلبات و قمنا بصياغتها تعاقديا مع الزبون. هناك دائما احتمال بأنه مع استكمال التوليف 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

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

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


يتــــابع <<<



البلسم غير متصل   رد مع اقتباس
قديم 09-03-2010, 11:47 PM   #2
البلسم البلسم غير متصل
طالب فضي
 
الصورة الرمزية البلسم
افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]







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

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

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

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

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

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

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





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

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

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

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

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

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

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



______________


وللحديث بقيه ان شــاء الله سنكمل الموضوع في وقت اخر <<<

اتمنى لكمـ استفاده ممتعه .,

البلسمــ



البلسم غير متصل   رد مع اقتباس
قديم 10-03-2010, 05:59 AM   #3
موجة بحر موجة بحر غير متصل
طالب مميز
 
الصورة الرمزية موجة بحر
افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


صباح الخير البلسم

تسلم يمينك يا عسل على المعلومات القيمة
موجة بحر غير متصل   رد مع اقتباس
قديم 10-03-2010, 08:14 AM   #4
انا الحساوي انا الحساوي غير متصل
طالب فعال
 
الصورة الرمزية انا الحساوي

 











افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


سلمت يداك والله لا يحرمنا من عطاياك الجميله


بارك الله فيك


مشكوره على هذا الجهد الأكثر من رائع


والافضل الاشاره الى المصدر حتى تعم الفائدة للجميع بشكل أكبر

واسف على تجاسري على موضوعك


ارجو قبول ملاحظتي برحابة صدر

التعديل الأخير تم بواسطة انا الحساوي ; 10-03-2010 الساعة 08:32 AM
انا الحساوي غير متصل   رد مع اقتباس
قديم 10-03-2010, 11:08 AM   #5
البلسم البلسم غير متصل
طالب فضي
 
الصورة الرمزية البلسم
إضاءة يتــابع الموضوع <<






المنحى للكائن

في هذا الفصل سوف نلقي نظرة على مفهوم المنحى للكائن Object Orientation 4 (OO) . لقد تمّ تصميم لغة النمذجة الموحّدة UML بحيث تدعم المنحى للكائن ، لذلك سنقوم بتعريف مفاهيمه قبل التعمق في لغة UML ، و استكشاف المزايا التي قد يوفرّها.
البرمجة المهيكلة

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

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

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

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

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

add_student 5
دخول امتحان

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

check_exam_marks
اصدار شهادة

issue_certificate
طرد طالب

expel_student

سوف نحتاج ايضا الى نموذج بيانات data model ليمثّل هذه الوظيفيات. نحتاج لتخزين معلومات عن الطلبة ، و المدربين و الامتحانات و الدورات، لذا يجب علينا تصميم مخطط قاعدة بيانات database schema للاحتفاظ بهذه البيانات. 6



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

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

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



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

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

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

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

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

كم من مرّة قمت بتعديل سطر في التوليف و بكل براءة دون أن تعي انك سبّبت عن غير قصد في كسر عمليات اخرى قد تبدو لا علاقة لها في الظاهر؟

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

المنحى للكائن "OO" يحاول التقليل من تأثير هذه المشكلة و ببساطة عن طريق الجمع بين البيانات data و الوظيفيات functions ذات العلاقة في قالب module واحد.



شكل 11: البيانات و الوظيفيات المرتبطة موضوعة في قوالب.


بعض النقاط الجديرة بالملاحظة حول نظام القولبة الجديد في البرمجة:

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

* القوالب يمكنها "التخاطب" مع قوالب اخرى عن طريق استدعاء وظيفياتها.

التغليف
Encapsulation

الأمر الأساسي هنا، أنه لا يتم السماح بقراءة أو تغيير أي عنصر في البيانات إلا من للتمثل الذي تتبعها . فمثلا، التمثل الخاص بقالب المدرّب Tutor لا يمكنه تحديث او قراءة بيانات "age" العمر داخل قالب Student الطالب.

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

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

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

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

يمكننا تمثيل هذه المعلومات بنفس اسلوب القوالب الببرمجية السابقة:

بالنظر الى الشكل 10 أعلاه، يبدو واضحا وجود علاقة بين البيانات و الوظيفيات؛ فمثلا و ظيفتي: add_student و expel_student مرتبطتان بقوة ببيانات Student الطالب.



شكل 12: بيانات و سلوك جهاز التلفاز

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

لهذا السبب، نسمّي هذه القوالب بالكائنات Objects و منها جاء مصطلح البرمجة / التصميم بالمنحى للكائن Object Oriented Design/Programming.

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

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

البيانات data الخاصة بالكائن object تسمّى عادة بخصائص أو سمات Attributes الكائن. التصرّفات المختلفة التي يقوم بها الكائن تسمّى مسالك أو نهجيات Methods الكائن. المسالك هي مرادف لما يعرف في لغات البرمجة بالوظيفيات functions او الاجرائيات procedures .

المصطلح الآخر المشهور في هذا السياق هو Class الصنف . الصنف هو ببساطة أرضية (template) يقوم عليها الكائن. يتم في الصنف وصف السمات attributes و المسالك methods التي ستكون حاضرة لكل تجسّدات الصنف. في منظومة المعهد التي تكلّمنا عنها في هذا الفصل، كان لدينا صنفا يسمّى Student.

سمات attributes صنف الطالب Student Class كانت الاسم و العمر و ما الى ذلك، أما المسلكيات methods فكانت add و expel. في التوليف code سنحتاج لتحديد هذا الصنف لمرة واحدة فقط. و حالما يتم تشغيل التوليف ، يمكننا انشاء create تجسّدات instances هذا الصنف أو بعبارة أخرى: انشاء كائنات objects الصنف.

كل كائن منها سيمثل طالبا، و كل منها ايضا سيحوي ما يخصّه من قيم البيانات.
استراتجية المنحى للكائن

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

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

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


موجز


* المنحى للكائن طريقة تفكير تختلف عن الاتجاه المهيكل.

* نقوم بالجمع بين البيانات و التصرفات ذات العلاقة داخل أصناف.

* ثم يقوم برنامجنا بانشاء تجسّدات للصّنف، بشكل كائنات.

* الكائنات يمكنها التعاون مع بعضها البعض، من خلال مخاطبة مسلكياتها.

* البيانات في الكائن مغلّفة و لا يقوم بتعديلها إلا الكائن نفسه.


.,


وللموضوع بقية ., وسأذكر المصدر في اخر الموضوع ., والشكر موضول للجميع .,,


.


البلسم غير متصل   رد مع اقتباس
قديم 12-03-2010, 05:11 PM   #6
البلسم البلسم غير متصل
طالب فضي
 
الصورة الرمزية البلسم
يتااابع الموضوع + المصــــدر


.,




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

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

* المحلّلون
* المصمّمون
* المبرمجون
* القائمون بالاختبار
* مراقبو الجوة
* المستفيدون
* الكتّاب التقنيون


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

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


مخطط حالة الاستخدام



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

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

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

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

مخطط الأصناف




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

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



مخططات التعاون



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

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

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




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


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

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



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



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



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



.,


ويهذا الموضوع اكون انهيت جزء سلسله من الشرح البسيط جدا عسى الله ينفع به ,.

والله يوفقنا ويوفقكمـ .,

والمصدر ., هذا الرابط .,
.,




شكرا لكم جميعا .,


تحيـــاتي ., البلسمـ ,.




البلسم غير متصل   رد مع اقتباس
قديم 12-03-2010, 06:12 PM   #7
دلــــــــــع دلــــــــــع غير متصل
طالب جديد
 
الصورة الرمزية دلــــــــــع

 










افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


يعطيك الف عافيه ع هالشرح الروعه


ماننحرمش ياعسل
دلــــــــــع غير متصل   رد مع اقتباس
قديم 13-03-2010, 09:57 AM   #8
البلسم البلسم غير متصل
طالب فضي
 
الصورة الرمزية البلسم
افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]




الله يعافيك .,

وتسلمين ع ردك واتمنى لك التوفيق .,


البلسم غير متصل   رد مع اقتباس
قديم 13-03-2010, 10:20 AM   #9
the emerald the emerald غير متصل
طالب نشيط
 
الصورة الرمزية the emerald

 











افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


ماشاء الله ,,, مجهود رائع اختي البلسم

وين الاشراف يحط ختم موضوع مميز

مشكورة خيتو ,, بارك الله فيكي
the emerald غير متصل   رد مع اقتباس
قديم 13-03-2010, 02:24 PM   #10
Hamss Hamss غير متصل
طالب نشيط

 











افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


ماشاء الله شرح رائع جدا


لله يعطيك العافية
Hamss غير متصل   رد مع اقتباس
قديم 10-03-2011, 06:37 AM   #11
الفسفوري الفسفوري غير متصل
طالب جديد

 









افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


السلام عليكم ورحمه الله وبركاته

يعطيكم العافيه

معلومات الكتاب:
العنوان: التحليل والتصميم باستخدام UML

عن الكتاب:
كتاب كبير يشرح لغة الUML.
وهو مترجم من اللغه الانجليزيه

ترجمه وإعداد: خالد عياد الشقروني

رابط التحميل من هنا
http://www.kutub.info/library/book/433

التعديل الأخير تم بواسطة الفسفوري ; 10-03-2011 الساعة 06:39 AM
الفسفوري غير متصل   رد مع اقتباس
قديم 06-12-2012, 01:38 PM   #12
اميرة القلوب1 اميرة القلوب1 غير متصل
طالب جديد

 










افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


مضمون المشروع:
A)
1. كتابة ملخص للحالة الدراسية.
2. كتابة الاهداف.
3. تصميم قاموس بيانات واحد (يختارة الطالب ).
4. تحديد نوع المعمارية المستخدمة في النظام .
5. تحديد اسماء الملفات المستخدمة وانواعها.
6. تحديد التقارير المستخدمة في النظام مع رسم قاموس بيانات لتقرير واحد فقط .
7. تحديد شاشات الادخال المستخدمة في النظام مع تصميم شاشة واحدة باستخدام برمجيات قواعد البيانات.
B) تستخدم برمجية Rational Rose في رسم المخططات :
1. تحديد حالات الاستخدام (Uses Case) والمتفاعلون ( Actors ) للحالة الدراسية.
2. رسم مخطط حالات الاستخدام Use Cases Diagram .
3. رسم مخطط الاصناف Classes Diagram.
4. رسم مخطط تسلسلي تشاؤمي (ادخال خاطئ) يبين أدخال اسم المستخدم وكلمة المرور .
5. رسم مخطط النشاط (Activity Diagram) يبين عملية استعلام معينة في النظام .
6. رسم مخطط الحالة (State Chart Diagram) يبين مراحل عملية معينة في النظام .
اميرة القلوب1 غير متصل   رد مع اقتباس
قديم 06-12-2012, 01:41 PM   #13
اميرة القلوب1 اميرة القلوب1 غير متصل
طالب جديد

 










افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


ارجو منكم المساعده في هذا المشروع للضرورة القصوى



مضمون المشروع:
A)
1. كتابة ملخص للحالة الدراسية.
2. كتابة الاهداف.
3. تصميم قاموس بيانات واحد (يختارة الطالب ).
4. تحديد نوع المعمارية المستخدمة في النظام .
5. تحديد اسماء الملفات المستخدمة وانواعها.
6. تحديد التقارير المستخدمة في النظام مع رسم قاموس بيانات لتقرير واحد فقط .
7. تحديد شاشات الادخال المستخدمة في النظام مع تصميم شاشة واحدة باستخدام برمجيات قواعد البيانات.
B) تستخدم برمجية Rational Rose في رسم المخططات :
1. تحديد حالات الاستخدام (Uses Case) والمتفاعلون ( Actors ) للحالة الدراسية.
2. رسم مخطط حالات الاستخدام Use Cases Diagram .
3. رسم مخطط الاصناف Classes Diagram.
4. رسم مخطط تسلسلي تشاؤمي (ادخال خاطئ) يبين أدخال اسم المستخدم وكلمة المرور .
5. رسم مخطط النشاط (Activity Diagram) يبين عملية استعلام معينة في النظام .
6. رسم مخطط الحالة (State Chart Diagram) يبين مراحل عملية معينة في النظام .
اميرة القلوب1 غير متصل   رد مع اقتباس
قديم 14-05-2013, 02:00 AM   #14
Ezio Ezio غير متصل
طالب جديد

 










افتراضي رد: تفضــلوا شـــرح الـ uml مترجم للغة العربية .,,]]


يا شباب لو سمحتم انا بدرس Computer Science و بدرس Object Orianted وفيها ال UML وانا مش فاهم اى حاجه في ياريت لو حد يقدر يساعدني عندي امتحان الاسبوع اللى جاي .................. من فضلكم وجزاكم الله خيرا
Ezio غير متصل   رد مع اقتباس
إضافة رد

مواقع النشر (المفضلة)

أدوات الموضوع
انواع عرض الموضوع

تعليمات المشاركة
لا تستطيع إضافة مواضيع جديدة
لا تستطيع الرد على المواضيع
لا تستطيع إرفاق ملفات
لا تستطيع تعديل مشاركاتك

BB code is متاحة
كود [IMG] متاحة
كود HTML معطلة

الانتقال السريع


الساعة الآن 06:46 PM.


Powered by vBulletin® Version 3.8.1, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd. TranZ By Almuhajir
جميع المواضيع والمشاركات تعبر عن وجهة نظر أصحابها
ولا تعبر باي شكل من الاشكال عن وجهة نظر منتديات AOUA
تصميم وتطوير : التكنولوجيا الماسية