انواع مدل ها
مدل هاي مختلفي را مي توان ترسيم نمود :
-
1) مدل هاي حوزه مسئله و موارد كاربرد : اين مدل ها ، نيازمندي هاي وظيفه هاي سيستم را نشان مي دهند. با ترسيم اين مدل ها نيازمندي هاي كاربر شناسايي مي گردد.
-
2) مدل هاي تحليلي : كاربرد خاص و تفصيل هر يك از نيازمندي هاي كاربر توسط مدل هاي تحليلي نشان داده مي شود. اين مدل ها هر مورد كاربرد را به صورت مفصل تر نشان مي دهند.
-
3) مدل هاي طراحي : كه ساختار ايستاي سيستم را به صورت زير سيستم ، كلاس ها و واسط ها براي پياده شدن بر اساس زير ساخت هاي كاري نشان مي دهند.
مدل هاي حوزه مسئله حتما قبل از مورد كاربرد ساخته مي شود تا با فرهنگ حوزه مسئله آشنا شويم.
دو روش بر اساس UML مي تواند براي ايجاد مدل هاي حوزه مسئله پيشنهاد شود:
-
-
1) نمودارهاي كلاسي كه از چشم انداز مفهومي ترسيم شده اند و بيشتر واژه ها و مفاهيم خبره هاي حوزه مسئله و نحوه ارتباط مفاهيم با يكديگر را نشان مي دهند. توجه شود كه در الگوي حوزه مسئله بيشتر ، ساختا ر و فرهنگ لغات مسئله مورد توجه است در حالي كه در مورد كاربرد ، بيشتر رفتار و فعاليت هاي حوزه مسئله مورد توجه قرار مي گيرد.
-
2) نمودارهاي فعاليت كه به عنوان تكميل كننده نمودارهاي كلاس ، توصيف كننده جريان كار سيستم هستند.
-
3) نكته مهم نمودارهاي فعاليت اينست كه فرآيندهاي موازي سيستم در آن كشف مي شوند و توالي غير ضروري فرآيندها مشخص مي گردند. برخي افراد به جاي نمودار فعاليت ، نمودار تعالم را مي پسندند.
-
4) بعد از الگوي حوزه مسئله ، نوبت به موارد كاربرد مي رسد. همانطور كه قبلا نيز اشاره شد در مورد كابرد نيازمندي هاي سيستم شناسايي مي گردند سپس همه نمودارها را در قالب يك نمودار حوزه مسئله مي آوريم و با يك يا دو نفر از متخصصين خود حوزه مسئله تبا دل نظر مي كنيم حال يك الگوي حوزه مسئله كه همه نيازمندي ها را نشان مي دهد در دست داريم. سپس به ساخت كلاس ها و ورود به مرحله ساخت مي پردا زيم. حداقل گروه ايجاد كننده مدل حوزه مسئله يك يا دو توسعه دهنده و يك يا دو خبره مسئله و حداكثر 4 نفر براي اين كار مناسبند. ايجاد نمونه اوليه نيز وسيله مناسبي در محقق سازي بهتر اين مرحله است . البته همه اين نكات صرفا يك توصيه است.
ريسك فني
در بررسي فني براي ايجاد نرم افزار ، لازم است تا تبعات به كار گيري تكنولوژي بررسي شود. به عنوان مثال از چه كامپايلري استفاده شود؟ (C++,Delphi,….. ) ؤ موتور پايگاه داده چيست ؟ (Oracle, SQL,…. ) . همچنين اثر متقابل اين انتخاب ها بر يكديگر مهم است. در اين بررسي لازم است تبعات سخت افزاري اين انتخاب بر يكدگير مهم است در اين بررسي لازم است تبعات سخت افزاري اين انتخاب نيز بررسي شود. به هر حال تصميمات طراحي معماري مهم است . در اين ميان تمركز بر نواحي اي كه در آينده به سختي قابل تغيير باشند مهمتر است . براي كشف اين نقاط نيز موارد كاربرد مناسب هستند. همچنين نمودارهاي كلاس و تعامل براي نمايش اينكه اجزاء چگونه با هم مرتبط مي شوند مفيد هستند. نمودارهاي بسته نيز مي توانند تصوير سطح بالايي از اجزا را نشان دهند. همچنين نمودارهاي استقرار مي توانند منظر گاهي را از اينكه چگونه قسمت هاي مختلف سيستم توزيع شده اند به دست دهند. براي كسب اطلاعات بيشتر به فصل هاي مربوطه مراجعه كنيد.
ريسك مهارت
براي كسب مهارت در مبحث شي گرا ، بهترين راه استفاده از مربي است كه در طول پروژه در كنار شما قرار گيرد اگر چنين حالتي امكان نداشته باشد استفاده از مربيان تمام وقت يا پاره وقت نيز براي بازنگري پروژه مفيد است. اگر اين حالت نيز امكان نداشت، هر ماه يا هر دو ماه با دعوت از يك مربي خبره مدل هاي خود را بازنگري كنيد. توصيه مي شود هر ماه يك كتاب تكنيكي بخوانيد حتي بهتر است كه به صورت گروهي مطالعه كنيد و به تبادل نظر بپردازيد .
الگوها نيز ابزا رهاي مناسبي براي آموزش و اعتبار سنجي مدل هاست. بنابراين لازم است از آخرين وضعيت الگوها باطلاع باشيد.
معماري خط پايه
نتايج و خروجي مرحله تفصيل ، معماري خط پايه است اين معماري شامل موارد زيرمي گردد.
-
• فهرست موارد كاربرد كه نيازمندي هاي سيستم را بيان مي كند
-
• مدل حوزه مسئله كه درك شما را از سيستم نشان مي دهد و نقطه شروع كلاس هاي اساسي حوزه مسئله است.
-
• ساختار تكنولوژي انتخاب شده كه تكنولوژي پياده سازي و جفت و جور شدن عناصر آنها را توصيف مي كند.
اين معماري ، پايه اي براي توسعه است . اصطلاحا به اين معماري ، طرح اوليه مراحل بعد گفته ميشود.
چه زماني مرحله تفصيل پايان مي يابد؟
دو رخداد مهم براي نمايش دادن پايان مرحله تفصيل عبارتند از :
-
1) تقريبا با اطمينان بتوان براي آينده پروژه تخمين زد.
-
2) شناسايي همه ريسك ها و آمادگي براي حل هر كدام از آنها انجام شده باشد.
برنامه ريزي
اساس برنامه ريزي تعيين تكرارهاي ساخت و تخصيص مورد كاربرد به هر تكرار است. براي اين منظور قدم هاي زير پيشنهاد مي شود:
قدم اول : طبقه بندي موارد كاربرد : كاربر بايستي سطح اولويت هر يك از موارد كاربرد را مشخص كند. معمول مي توان اين كار را در سه سطح بالا ، متوسط و پايين انجام داد
قدم دوم : در نظر گرفتن ريسك معماري براي هر مورد كاربرد : توسعه دهنده ، اين ريسك را در سه سطح مشخص مي كند . اين ريسك عبارت است از ريسكي كه اگر اين مورد كاربرد در پروژه براي مدتي به تعويق افتد ، تكميل كارهايي كه تاكنون انجام شده اند ، چقدر باعث دوباره كاري مي گردد؟
قدم سوم : در نظر گرفتن ريسك برنامه ريزي براي هر مورد كاربرد : كه عبارت از ميزان اطمينان توسعه دهنده نسبت به تخمين كار مورد نياز براي هر مورد كاربرد است.
طول زماني كه هر مورد كاربرد بر حسب نفر ـ هفته را با فرض انجام تحليل ، طراحي ، كدنويسي ، تست ، مجتمع سازي و مستند سازي به دست آوريد. نكته قابل توجه اينست كه تخمين زدن را بايد كارشناس توسعه انجام دهد نه مدير. اگر برخي از موارد كاربرد داراي ريسك بالا بودند نياز به مرحله تفصيل دوباره ، براي اين موارد كاربرد پيش مي آيد.
قدم چهارم : تعيين طول تكرار براي كل پروژه : لازم است يك طول ثابت زماني براي كليه تكرارها در كل پروژه مشخص گردد. اين طول زماني بايستي باندازه كافي بزرگ باشد تا بتوانيد چند مورد كاربرد را در هر تكرار انجام دهيد. به عنوان مثال براي زبان Smalltalk ميتوانيد دو تا سه هفته و براي c++ شش هفته يا بيشتر باشد. در محاسبات لازم است اين گونه در نظر بگيريد كه از 50 % توان يك كارشناس توسعه استفاده مي شود ، سپس طول تكرار را در نصف تعداد توسعه دهنده ها ضرب كنيد ، نتيجه به دست آمده ، مقدار كار توسعه را براي هر تكرار مشخص مي كند. براي نمونه با 8 توسعه و طول تكرار 3 هفته اي در هر تكرار (12 = 8 * 3 * 1.2 ) نفر – هفته در هر تكرار داريم.
جمع كل زمان موارد كاربرد را بر مقدار مورد نياز در هر تكرار (عدد به دست آمده در مرحله قبل ) تقسيم كنيد و با عدد يك جمع كنيد ، عدد به دست آمده اولين تخمين شما از تعداد تكرارا مورد نياز در پروژهتان است. عدد يك براي اطمينان بيشتر به مقدار فوق افزوده مي شود.
قدم پنجم : تخصيص موارد كاربرد به تكرارها: بر اساس اولويت هايي كه قبلا توضيح داده شد، در هر تكرار ، تعدادي مورد كاربرد قرار دهيد. ابتدا موارد كاربرد با اولويت بالاتر را به تكرارها تخصيص دهيد. براي پيش بيني مقدار زمان مورد نياز در مرحله انتقال معمولا 10 % تا 35 % از مرحله ساخت را به عنوان تخمين مرحله انتقال قرار مي دهند . همچنين 10% تا 20 % از مرحله ساخت را براي پيشامدهاي اتفاقي قرار ميدهند.
برنامه اي كه به روش فوق به دست مي آيد و با تبادل نظر كاربر و كارشناس توسعه ايجاد مي شود به برنامه توصيه اي معروف است .
بنابراين ، موارد كاربرد پايه هاي برنامه ريزي هستند كه UML نيز بر آنها تاكيد زيادي دارد.
مرحله ساخت
در مرحله ساخت ، سيستم در طي يك سري تكرار ايجاد مي شود در هر تكرار نيز تأييد كاربر اخذ مي شود . هدف از اين فرايند كاهش ريسك است .
