المقـــدمـــة =-=-=-=
إن موضوع التحليل والتصميم بالكائنات من أهم المواضيع الني ينبغي لأي مبرمج أو مطور يستخدم لغه كائنيه أن يجيده ، حيث على المبرمج أن يقوم بتحليل البرنامج أولا ويعرف ما هي المشكله التي يريد أن يحلها Analysis ومن ثم يبدأ هذا المبرمج بطرح الحلول وكيف يمكن أن تتفاعل هذه الكائنات مع بعضها البعض design ، ومن ثم يقوم بعمليه الCoding ويقوم بتطبيق التصميم الذي طرحه في المرحله السابقه ، وأخيرا يقوم باجراء الTesting للبرنامج والتأكد من مطابقته لمتطلبات الزبون Customer Requirement .
العمليات السابقه التي ذكرتها (Analysis,Design,Coding,Testing) تعرف بدوره حياه المشروع Software Development Life Cycle . وبالطبع أي مشروع يجب أن يمر على جميع هذه المراحل بترتيب معين حيث أن عمليه التطوير يجب تكون على منهجيه معينه وباتباع طريقه ما Methodology والا ستعم الفوضي ولن تستطيع حتى كتابه سطر واحد صحيح من البرنامج .
باتباع هذه المنهجيات سوف تضمن أن عمليه تطويرك للبرنامج تسير في المنحنى الصحيح ، كما أنها توفر لك كل ما تحتاجه من وقت البدء في تحليل المشروع الى وقت التسليم والصيانه للمشروع ، اضافه الى توضيح نوعيه الوثائق والمخططات التي ستنتجها كل مرحله Activities & Artifacts هذا فقط فهناك منهجيات توفر لك نصائح وارشادات في عمليه جدوله المشروع واداره الفريق وما الى ذلك من العمليات الإداريه Management Task .
قديما كانت تجري هذه العمليات SDLC بالترتيب وبشكل متنازل وهو ما يعرف بنموذج الشلال Waterfall Model .. حيث يقوم أولا المحلل بتحليل البرنامج بالكامل وكتابه جميع الوثائق المطلوبه ومن ثم يمرر هذه الوثائق للمصمم الذي يقوم بتصميم النظام ووضع حلوله أيضا ، ومن ثم تمر بالمبرمج الذي يقوم بكتابه الكود وعندما ينتهي تجرى الأختبارات على هذا البرنامج وأخيرا يسلم الى الزبون ..
ولكن للأسف هذا النموذج لا يصلح بتاتا الا في المشاريع الصغيره والتي لا يوجد فيها خطوره ما (مثلا فريق تطوير قد قام بمشروع مشابه للمشروع الحالى ، حينها يمكن أن يستخدم هذا النموذج) .. مشكله أخرى وهي عدم وجود وثائق موحده تمر علي جميع فريق التطوير فالمحلل لديه اساليب خاصه فيه والمصمم كذلك وكل منهم بحاجه الى مزيد من الوقت لكي يفهم ماذا كان يقصد الشخص الذي كتب هذه الوثائق ..
ليس هذا فقط فعند الدخول في المشاريع الكبيره تبدأ المشاكل الأكبر بالظهور، فنموذج الشلال لا يسمح يتغيير المتطلبات ، حيث يجب على المحللين في البدايه أن يقوموا بتحليل النظام بشكل كااامل ومن ثم تبدأ مرحله التصميم وهكذا لجميع المراحل حيث لا عوده للخلف بتاتا .. السؤال هنا ماذا لو تغيرت متطلبات هذا الزبون بعد مرور 3 أشهر من التحليل والتصميم وبالبدء بالكود ، كارثه !! وحتى ولو لم تتغير المتطلبات ففي حال استخدم نموذج الشلال في مشروع كبير فهذا يعني تحليله بالكامل ثم تصميمه بالكامل وبرمجته بالكامل وهذا غير منطقى خصوصا في البرامج الكبيره حيث يجب أن تقسم لأجزاء صغيره يتم العمل على كل منها على حده . الصوره التاليه تشبه عمليه تطوير مشروع ضخم باستخدام نموذج الشلال بعمليه أكل فيل من غير تقسيم [IMG]file:///C:/DOCUME~1/musab/LOCALS~1/Temp/msohtml1/01/clip_image003.gif[/IMG] :
ناهيك عن الوقت المستغرق في كل مرحله ، حيث لأنها يجب أن تكون كامله وشامله يبدأ الخوف لدي المحللين فيأخذوا وقت أكثر من المفترض أن يكون به ويبدأ في ذكر "يبدوا أن هناك شيء ناقص ، سنعيد تحليل هذه النقطه" ، "يجب أن نراجع التحليل مره أخرى ، حيث اذا حدثت مشكله الأن سوف تبقى على اكتافنا" وهكذا يصاب المحلل ب Analysis Paralysis ، بنفس الأمر عند المصمم والمبرمج والشخص الذي يقوم بالأختبار كل منهم يصاب بهذه العقده خاصه ان كان قد فشل في مشروع سابق [IMG]file:///C:/DOCUME~1/musab/LOCALS~1/Temp/msohtml1/01/clip_image003.gif[/IMG].
مع وجود كل هذه العيوب في هذا النموذج الا أنه يقدم تسلسل منطقى في عمليه تطوير (تحليل ثم تصميم ثم برمجه ثم اختبار) وبالتالي يمكن أن يستفاد من هذه التسلسل في منهجيات أخرى أكثر مرونه في الشلال وهذا ما حصل بالفعل .
النموذج الحلزوني Spiral كان من أول المحاولات في تطوير الشلال ، حيث يمكن أن نطور المشروع في أكثر من دوره (بمعنى أكثر من نموذح شلال في اَن واحد) .. وبنفس المراحل الموجوده في الشلال .. وبالتالى كان يمكن لفريق التطوير أن يقوموا بأخذ متطلبات غير كامله ويبدؤا بتحليلها وتصميمها وبرمجتها ، وهكذا تنتهي الدوره الأولى .. وتبدأ الدوره الثانيه وهكذا الى أن ينتهي تطوير المشروع بالكامل .
Resized to 93% (was 697 x 277) - Click image to enlarge[IMG]file:///C:/DOCUME~1/musab/LOCALS~1/Temp/msohtml1/01/clip_image007.jpg[/IMG]
النموذج الحلزوني قلل من المشاكل بشكل كبير ، ولكن يمكن أن تظهر نفس المشكله في التي كانت تظهر في الشلال ، حيث في حال أكتشف المبرمج أن هناك خطأ أو نقص في التصميم لا يمكن العوده للخلف ويجب الانتظار حتى البدء في الدوره الثانيه .. النموذج جيد ولكن نريد أن نسمح بالعوده للخلف ..
النموذج المتكرر Iterative Methodology كان هو الحل لهذه المشكله ، حيث يمكن في هذا النموذج أن نعود خطوه للوراء ونصلح ذلك الخلل ونكمل السير في هذه الدوره
بالتالى أصبحت عمليه التطوير هي عباره عن عده دورات ، كل منها تستطيع التحرك خطوه للأمام أو الخلف على حسب ما تريده .. ولكن ما زالت المشاكل بالظهور فما زلت تقوم بأكل الفيل من مره واحده ،، جيث الدورات السابقه كانت لاصلاح خلل وغالبا ما تكون 4 دورات .. نحن نريد تقسيم المشروع لأكثر من دوره وفي كل مره نقوم بتطوير جزئيه معينه وهذا هو النموذج المتصاعد ، الصوره التاليه تبين تطوير الاصدارات مع تقدم الزمن ..
Resized to 97% (was 670 x 154) - Click image to enlarge[IMG]file:///C:/DOCUME~1/musab/LOCALS~1/Temp/msohtml1/01/clip_image011.jpg[/IMG]
في حال أنك لاحظت أن جميع هذه الطرق (الشلال ، الحلزوني ، المتصاعد ، المتكرر) كل منها توجد فيه خاصيه مفيده في عمليه التطوير ، وبالتالى يمكن أن نجمع جميع هذه الطرق مع بعضها البعض وبالتالى نستفيد من جميع المزايا في كل واحده من الطرق
بعد جمع هذه الطرق جميعها ، مازال ينقص شيء مهم جدا ، وهو توضيح مالذي يجب أن نفعله في مرحله التحليل ، ما هي نوعيه الوثائق التي يجب أن تنتج ؟ ما هو شكل الأختبارات التي يجب أن تكون ؟ ما هي المخططات التي يجب أن تستخدم في مرحله التصميم ؟ نعم نحن بحاجه الى لغه موحده للرسومات ومنهجيه معينه في التطوير تسمح لي باتباع خطواتها للوصول للمشروع الناجح ان شاء الله ..
من هذه النقطه ظهرت العديد المنهجيات التي توضح كيفيه تطوير المشاريع مثل RUPو Ripple و Agile ، بالاضافه الى العديد من الطرق المستخدمه في وصف ورسم العلاقات والطرق المستخدمه وكانت أشهرها وأفضلها وأصبحت الأن هي المقياس هي Unified Modeling Language .
RUP وUML كانت نتيجه مجهودات الأصدقاء الثلاثه Grady Booch و Ivar Jacobson و James Rumbaugh حيث كان لكل منهم لغه نمذجه خاصه فيه اضافه الى منهجيه معينه للتطوير ، فاجتعموا على تطوير لغه نمذجه موحوده ومن هنا كانت بدايه لUML ، وبعدها أصحبت معيار رسمي وسجلت لدى OMG .. أما RUP فتعتبر من أشهر المنهجيات للتطوير ومن أصعبها أيضا على المبتدئين ..
Agile methodology هي مجموعه من المنهجيات الجيده و التي ترحب بتغييرات المتطلبات في أي لحظه في دوره حياه المشروع ، كما أنها تتسم بالسرعه والخفه .. أحد أشهر هذه المنهجيات هي eXtreme Programmingوهي تعمل بمبدأ test-driven development و pair programming بمعنى ان المبرمج سيقوم قبل كتابه الكود بكتابه أختبار سيجريه على الكود الذي سيكتبه وعند الأنتهاء يختبر الكود فاذا نجح فينتقل للخطوه التاليه (كود الأختبار قبل الكود) .. أما pair programming فتعني أنه يجب أن يكتب الكود من قبل مبرمجين اثنين يكونوا أما الشاشه في نفس اللحظه .. أحدهم يراقب الكود والأخر يستلم عجله القياده (الكيبورد) [IMG]file:///C:/DOCUME~1/musab/LOCALS~1/Temp/msohtml1/01/clip_image003.gif[/IMG] .. فاذا تعب يتم التبديل وهكذا ... مناصروا الXP يروا أن استخدام هذه الطريقه يزيد من كفائه المبرمجين وخاصه في حال جلس مبرمج مبتدأ مع أخر خبير بالمجال..
أما Ripple فهي أيضا أحد المنهجيات والتي هي عباره عن نسخه مبسطه من الRUP ، الصوره التاليه تبين لك المخرجات الناتجه في كل مرحله من مراحل التطوير باستخدام Ripple ..
لاحظ أن جميع هذه المنهجيات أصبحت تستخدم UML كلغه موحوده في جميع المشاريع ، وبالتالى على المبرمج أن يكون على بهذه المخططات البسيطه ( هي 13 مخطط فقط) .. ملاحظه اخرى وهى أن هذه المخططات في النهايه هي عباره عن مخططات فقط !! فهي لن ترشدك في عمليه التطوير ولن تريك ما الذي يمكن أن تفعله في هذه المرحله فهي من مسؤوليه المنهجيه .. بالتالى على المبرمج أن يتعلم هذه المنهجيات ويعرف الفرق فيما بينهم وما هي المنهجيه التي ستفيده في مشروعه الحالى ..
بالطبع تعلم منهجيه ثقيله RUP أو حتى ripple بالنسبه للمبتدئين أمر غير جيد حيث سيصعب على المبتدئ التعلم من خلال هذه المنهجيات ، لذلك كانت هناك منهجيات خفيفه lightweight process يمكن أن تستخدم كمثال عملي على التطوير باستخدام منهجيه ما . وهناك الكثير من المنهجيات الخفيفه بل ربما يمكنك أن تنشئ منهجيتك الخاصه في التطوير ..
ضوابط المشاركة
رد مع اقتباس
المفضلات