تحلیل و طراحی شی گرا - مدل سازي سيستم ها

مقدمه
در مهندسي نرم افزار پروژه اي را موفق مي گويند که:
- در زمان مشخص و با هزينه مشخص به اتمام برسد. پروژه اي که در زمان مشخص به اتمام نرسد و يا با هزينه اي بيشتر از برآورد اوليه به اتمام برسد ناموفق ناميده مي شود.
- نياز مشتري و بازار را جواب دهد. اگر پروژه اي تحويل شود که نياز مشتري را به صورت کامل جواب دهد ولي فاقد زيبايي باشد خيلي موفق تر از پروژه اي است که داراي زيبايي باشد ولي نياز مشتري را جواب ندهد . بنابراين ابتدا بايد نياز مشتري در اولويت قرار گيرد و برنامه اي با حداقل امکانات که کليه نيازهاي مشتري را جواب مي دهد توليد گردد و سپس در مراحل بعد به سرعت و راحتي استفاده و زيبايي آن پرداخته شود.
آماري که در سال 2002 و 2003 در مورد پروژه هاي نرم افزاري آمريکا در دست داريم اين است که حدود 9 درصد از پروژه ها موفق بوده اند و بقيه ناموفق بوده اند ( در اصطلاح failشده اند) در اينجا ناموفق بودن به اين معنا است که يا پروژه بعد از زمان تعيين شده تحويل شده است يا بيش از مبلغ تعيين شده هزينه برده است.

تعريف مدل
تعريف مدل : مدل ، ساده شده دنياي واقعي است.
تعريف ديگرمدل : مدل ، يک سري اجزاء و روابط بين اجزاء در دنياي واقعي را عنوان مي کند.

مدل ايده آل :
مدل ايده ال : مدلي است که بتواند تمامي اجزاء يک سيستم و تمامي روابط اجزاء را مشخص کند.
در عمل چنين مدلي نمي توان داشت و اگرمدلي داشته باشيم که بتواند تا 70 درصد روابط بين اجزاء را مشخص کند مدل خوبي خواهد بود ولي 100 درصد امکان پذير نيست.(يا حداقل به سختي مي توان به چنين مدلي دست يافت).

حال ببينيم مدل سازي سيستم نرم افزاري چه کمکي به ما مي کند؟
مدل سازي در نرم افزار مثل يک نقشه راه (Roadmap) عمل مي کند. يعني به ما مي گويد که چگونه از نقطه شروع به سمت نقطه پايان حرکت کنيم که در پايان بتوانيم محصول مورد نظر خود را تحويل دهيم.از نظر مهندسي نرم افزار چيزي که اهميت دارد توليد محصول است. تا کنون خيلي از روشهاي مدلسازي به بازار ارائه شده اند که هر کدام داراي ويژگيهاي خاص خود هستند. ولي همانطور که گفته شد محصول اهميت دارد نه اينکه از کدام يک از اين روشها استفاده مي کنيم.

نتايج (فوايد) مدل سازي

1- ديد روشن و شفاف نسبت به سيستم مي دهد.
باعث مي شود که پيچيدگي ها و زواياي تاريک سيستم از بين برود. مثلا سيستمي مانند حقوق و دستمزد را در نظز بگيريم. در ابتدا سيستمي ساده به نظر مي رسد ولي وقتي وارد اين سيستم مي شويم پيچيدگي هاي خاص خود را دارد. بنابراين با مدلسازي اوليه آن مي توان پيچيدگي هاي آنرا تا حد زيادي از بين برد.

2- معماري و چارچوب سيستم مشخص مي شود.
باعث مي شود که بتوان زمان و نيروي انساني مورد نياز براي پروژه را تخمين زد. مثلا اگر شما معماري .Net را براي پروژه خود انتخاب کنيد پس به متخصصين .Net احتياج داريد.

3- ريسک را مي توان مديريت کرد.
با بررسي موارد 1 و 2 مي توان ريسک هاي سيستم را شناسايي و مديريت کرد.
تعريف ريسک : هر چيزي که از نظر زمان و بودجه پروژه را دچار مشکل کند ريسک مي گويند.
معروفترين ريسک Problem Behind Problem است. اين ريسک زماني است که شما نياز کاربر را(به هر دليلي) اشتباه در نظر گيريد.

4- مستند سازي و رسيدن بهقابليت استفاده مجدد (Reuse) .
مدل سازي شما را وادار مي کند که مستند سازي کنيد. و تمامي اين نتايج براي رسيدن به Reuse است. يعني از دوباره کاري در پروژه ها جلوگيري مي کند.

صول مدل سازي سيستم ها

اصل اول : مدل بايد بهينه باشد
اگر مدل بهينه نباشد تيم به بيراهه مي رود و ممکن است در نهايت محصول مورد نظربا امکانات خواسته شده توليد نشود. مطلب ديگري که در اصل اول نهفته است اينکه مدلسازي کاري گروهي است. يعني افرادي با تخصصهاي مختلف بايد در مدلسازي همکاري کنند. زيرا هر کس از نظر تخصص خودش به مدل نگاه مي کند مثلا طراح با يک ديد و مدير بانک هاي اطلاعاتي با ديد ديگر و ... به مدل نگاه مي کنند و اين باعث مي شود که مدل به سمت بهينه شدن حرکت کند.

اصل دوم : مدل را از زواياي مختلف مشاهده کنيد.
نگاه کردن به مدل از زواياي مختلف پاسخ به دو پرسش پاسخ است . What, How
What: چه کاري بايد انجام گيرد؟
How: چگونه بايد انجام داد؟
يعني مدل بايد به سئوالهاي تحليلگر و طراح و هم برنامه نويس جواب دهد.

اصل سوم : مدل را در دنياي واقعي مشاهده کنيد.
در مدلسازي ايده ال گرا نباشيد و امکانات دنياي واقعي را در نظر بگيريد. ممکن است که تحليلگر مساله را کاملا ايده ال در نظر بگيرد که از نظر طراح نتوان با تکنولوژيهاي موجود آنرا پياده سازي کرد.در اينجا ممکن است بين تحليلگر و طراح شکاف ايجاد گردد که يک ريسک به حساب مي آيد.

تحليلگر : نياز کاربررا مي گيرد به منطق نرم افزاري تبديل مي کند.

طراح : کسي که منطق را با تکنولوژي ترکيب مي کند و خوراک پياده سازي را فراهم مي کند.

اصل چهارم : مدل به تنهايي کافي نمي باشد بلکه بايد به قطعات کوچک قابل پياده سازي و مديريت با کمترين ارتباط شکسته شود.
وقتي مدل به قطعات کوچکتر شکسته مي شود و ارتباط کاهش مي يابد تغيير در يک قسمت باعث تغيير در قسمتهاي ديگر نمي گردد وهزينه تغييرات کاهش مي يابد.
اين اصل ، برنامه نويسي بر اساس Component را ايجاب مي کند . يعني برنامه به تعدادي Component شکسته مي گردد که هر کدام به تنهايي به درستي کار مي کند و با کنار هم قرار گرفتن آنها سيستم به طور کامل کار مي کند.هم اکنون در دنيا برنامه نويسي بر اساس Service جاي برنامه نويسي بر اساس Component را گرفته است و مفهومي تحت عنوان SOA(Service Oriented Approach) مطرح شده است.

تا اينجا به اين نتيجه رسيده ايم که تمام پروژه هاي نرم افزاري بايد مدلسازي شوند.