Transcript مروری بر روشهای رسمی تولید برنامه در مقایسه با روش های متداول سیامک صادقیانفر بهار 1384

‫مروری بر روشهای رسمی تولید برنامه‬
‫در مقایسه با روش های متداول‬
‫سیامک صادقیانفر‬
‫بهار ‪1384‬‬
‫فهرست‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫مقدمه‬
‫معرفی روش های رسمی‬
‫چگونگی بهبود تولید نرم افزار‬
‫اسطوره هایی درباره روش های رسمی‬
‫علل عدم اقبال‬
‫نتیجه گیری‬
‫فهرست منابع‬
‫مقدمه‬
‫•‬
‫•‬
‫•‬
‫•‬
‫نرخ باالی خطا در سامانه ها‬
‫هزینه باالی آزمایش‬
‫مشاهده درستی در مقابل اثبات‬
‫هزینه غیر قابل جبران خطا درسامانه های بحرانی‬
‫– فضاپیمای ‪ ،Ariane5‬اتالف ‪ 10‬سال و ‪ 7‬میلیارد دالر‬
‫– ‪ ،Therac-25‬مرگ ‪ 6‬انسان‬
‫• نیاز به اطمینان‬
‫معرفی روش های رسمی‬
‫•‬
‫•‬
‫•‬
‫•‬
‫بر پایه مدل تحلیل ریاضی‬
‫استفاده از ریاضیات برای توصیف برنامه ها‬
‫بیان نیازمندی ها به جای راه حل‬
‫زبان های متداول‬
‫–‬
‫–‬
‫–‬
‫–‬
‫–‬
‫‪Z‬‬
‫‪CSP‬‬
‫‪B‬‬
‫‪VSM‬‬
‫‪Larch‬‬
‫معرفی روش های رسمی‬
‫گام های روش های رسمی‬
‫وارسی‬
‫پاالیش‬
‫اثبات‬
‫توصیف‬
‫معرفی روش های رسمی‬
‫قسمتی از توصیف نرم افزار ثبت نام دانشجویان به زبان ‪Z‬‬
‫معرفی روش های رسمی‬
‫• محاسن‬
‫– کاهش نرخ خطا‬
‫– افزایش اطمینان به سامانه‬
‫– کاهش هزینه در نگاه کلی نگر‬
‫– استفاده مجدد در حد توصیف‬
‫• معایب‬
‫– افزایش هزینه اولیه‬
‫– زمان بیشتر برای یادگیری‬
‫– عدم درک توسط افراد غیر فنی‬
‫چگونگی بهبود تولید نرم افزار‬
‫• روش های متداول تولید نرم افزار‬
‫– روش ساخت یافته‬
‫– روش شیءگرا)‪(OO‬‬
‫– روش توسعه سریع نرم افزار (‪)RAD‬‬
‫– روش منظرگرا (‪)AO‬‬
‫• نقش حیاتی توصیف در طراحی‪ ،‬پیاده سازی و آزمایش‬
‫• استفاده از ‪ UML‬به همراه زبان طبیعی‬
‫• فراگیری قابلیت فهم در برابر ابهام و درک متفاوت‬
‫چگونگی بهبود تولید نرم افزار‬
‫•‬
‫•‬
‫•‬
‫•‬
‫خطا‪ ،‬رفتار غیرمنتظره سامانه‬
‫خطا در مراحل ابتدایی‪ ،‬هزینه بیشتر‬
‫آزمایش‪ ،‬روش کشف خطا‬
‫محدودیت های آزمایش‬
‫– عدم امکان انجام قبل از پیاده سازی‬
‫– هزینه باالی رفع خطای توصیف‬
‫– آشکار کردن خطاها‪ ،‬نه تضمین عدم وجود‬
‫– عدم برخورداری از دقت در صورت ابهام در سند نیازمندیها‬
‫چگونگی بهبود تولید نرم افزار‬
‫• هزینه بیشتر در مراحل اولیه‬
‫• کاهش هزینه پیاده سازی و وارسی‬
‫اسطوره هایی درباره روش های رسمی‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫ایجاد تاخیر در مراحل تولید نرم افزار‬
‫عدم پشتیبانی توسط ابزارها‬
‫به معنی ترک روش های غیر رسمی طراحی‬
‫مختص ریاضیدانان!‬
‫استفاده در کلیه زمینه های تولید‬
‫علل عدم اقبال‬
‫•‬
‫•‬
‫•‬
‫•‬
‫وجود اسطوره ها‬
‫عدم احساس نیاز به دلیل کیفیت قابل قبول روش های دیگر‬
‫اهمیت زمان رسیدن به بازار در مقابل نرخ پایین خطا‬
‫عدم وجود ابزارهای کافی‬
‫نتیجه گیری‬
‫استفاده از روش های رسمی درکنار روش های غیر‬
‫رسمی برای تولید نرم افزارهای‬
‫با پیچیدگی زیاد و قابلیت اطمینان باال‬
‫فهرست منابع‬
• Quentin Charatan and Aaron Kans, “Formal Software Development,
From VDM to Java”, Palgrave Macmillan, 2004
• Jim Woodcock and Jim Davies, ”Using Z, Specification, Refinement
and Proof”, Prentice Hall, 1996
• Ian Sommerville, ”Software Engineering )7th Edition(”, Addison
Wesley, 2004
• D. Bégay and A. Rauzy, “A Realistic Involvement of Formal
Methods”, Software-Practice and Experience, Vol. 31, Issue 2, 2001
• Seyyed Hasan Mirian, “Enrollment Case Study”, May 2004
• Jonathan P.Bowen and Michael G.Hinchey, “Seven More Myths of
Formal Methods: Dispelling Industrial Prejudices”, December 1996
‫پایان‬