مهندسی نرم افزار و رویکردهای جدید

زندگی در عصر اطلاعات، موجب پیدایش و ذخیره سازی میزان وسیعی از اطلاعات روی رسانه های مختلف در گرداگرد جهان شده است و این در حالیست که ما تازه شروع به درک ابعاد بیکران عالم ناشناخته ها کرده ایم. با در نظر گرفتن آنچه که هنوز از جهان برای ما ناشناخته است، حجم اطلاعات به طور شگفت آوری افزایش خواهد یافت! در واقع حجم اطلاعاتی که با آن سر و کار خواهیم داشت فراتر از تصوراتمان خواهد شد.
در هر شاخه ای از علم هدف اصلی اطلاعات است. و این مهندسی نرم افزار است که با همه اطلاعات در علوم مختلف سر و کار دارد. مهندسی نرم افزار همواره مسئولیت فراهم کردن ابزارهای ضروری برای سازماندهی، ساختاربندی و استفاده موثر از حجم عظیم اطلاعات موجود را داشته است. مسئولیت مهندسی نرم افزار  با افزایش تصاعدی حجم اطلاعات به طور شگفت انگیزی در حال افزایش است. در هر شاخه ای از علم و تکنولوژی، حجم اطلاعات به قدری در حال افزایش است که بدون یک ابزار مهندسی نرم افزار، این همه اطلاعات بلا استفاده خواهد بود. و این قدرت و مسئولیت عظیمی برای مهندسی نرم افزار محسوب میگردد. برای اطمینان از بکارگیری مناسب این نیرو، تحقیقات بیشتری لازم است. در این مقاله، به عنوان گامی کوچک در جهت این تحقیقات، اهمیت رویکردهای صوری و پایه های ریاضی در مهندسی نرم افزار را بررسی میکنیم.
یک نظام مهندسی
بحث داغی که سال ها پیش آغاز شده و هنوز هم ادامه دارد این است که: آیا مهندسی نرم افزار علم است یا یک نظام مهندسی؟ در برخی از دانشگاه های معتبر این بحث جریان دارد که مهندسی نرم افزار متعلق به مدرسه مهندسی است یا دانشکده علوم؟ در واقع مهندسی نرم افزار متشکل از رشته های مختلف علمی است به طوری که برای تحلیل و اثبات صحت سیستم از ریاضیات و برای برآورد ریسک ها ، هزینه ها و رعایت توازن از مهندسی کمک میگیرد؛ همینطور برای مدیریت نیروی انسانی، تسهیلات و پیشرفت کار نیازمند علوم مدیریتی است.
مهندسی نرم افزار به عنوان ابزاری قدرت مند زیرساختار علوم مختلف را فراهم میکند. این قدرت عظیم نیاز به مراقبت افزونی دارد و موجب شده است که مهندسی نرم افزار به خاطر مسئولیت هایش یک نظام مهندسی محسوب شود.
مشکلات
مشکل اصلی مهندسی نرم افزار، ابهام و نادرستی در تشخیص نیازمندی های سیستم است. شکست پرواز 501 آرین 5 به دلیل نقص مهندسی نرم افزار در گردآوری نیازمدی های محیطی/کاربردی آرین 5 بود. پل تنگه وارزانو در شهر نیویورک، بزرگترین پل معلق جهان، در زمان پیش بینی شده و در حد بودجه پیش بینی شده تکمیل شد. پروژه سیستم عامل آی بی ام با بیش از 5000 سال کار انسانی دیرتر از تاریخ مورد نظر به اتمام رسید. مهندسی نرم افزار بسیار پیچیده است و مهندسین نرم افزار به خوبی ورزیده نیستند. به همین دلیل، برنامه ریزی و اتمام آن همانند دیگر پروژه های مهندسی امکانپذیر نیست.به خصوص که مهندسی نرم افزار نظامی نوپاست و متخصصین آن در مقایسه با مهارت های دیگر رشته های مهندسی، هنوز تجربه تاریخی کافی ندارند. نگاهی دقیق تر به رویکردهای صوری در مهندسی نرم افزار به پیدا کردن راه حل کمک میکند.
رویکردهای صوری
تحقیقات انجام شده در زمینه بهبود قابلیت سیستم های نرم افزاری، استفاده از روش های صوری در توصیف رفتار نرم افزار و تصحیح خطاها در طراحی و پیاده سازی را توصیه میکنند. با وجود انتقادهایی نسبت به عملی بودن روش های صوری، واقعیت های انکارناپذیری در این خصوص وجود دارند:
1-    بسیاری از معایب سیستم های نرم اقزاری به فاز تحلیل نیازمندی ها باز میگردد مطالعات Bell labs و IBM نشان میدهدکه 80% از نواقص سیستم های نرم افزاری ریشه در مرحله تحلیل نیازمندی ها دارد.
2-    توصیف صحیح نیازمندی های سیستم های نرم افزاری، کیفیت نرم افزار را بهبود بخشیده و قابلیت اطمینان آن را افزایش میدهد. و اما لازمه صحت تعریف سیستم های نرم افزاری و توصیف نیازمندیها استفاده از روش های صوری است. در واقع، فواید استفاده از روش های مبتنی بر ریاضیات در تمام فازهای مهندسی نرم افزار در حال افزایش است. برای مثال دکتر مانفرد بروی بر فواید استفاده از ریاضیات به عنوان زیربنای علمی در جنبه های مدل سازی، تکنیک های توصیف و روش های توسعه مهندسی نرم افزار تاکید دارد.
3-    بیش از 20 سال بود که آی بی ام در خصوص CICS گزارشاتی از شکست این سیستم دریافت میکرد. CICS که بدون استفاده از روش های صوری توسعه یافته بود سرانجام با استفاده از روش صوری  Z در سال 2000 توصیف شد. هدف اصلی کاهش تعداد خطاهای مشخص شده در چرخه توسعه نرم افزار توسط مشتری و در نتیجه تولید محصولی با کیفیت بهتر بود. این تجربه، سودمندی روش های صوری را ثابت کرد و منبع مهمی در آموزش و بحث در محافل مهندسی نرم افزار شد.
4-    روش های صوری برای سیستم های بزرگ و پیچیده عملی نیستند. تجربه آی بی ام در CICS ثابت کرد که این روش ها مفیدند ولی لزوما کاربردی نیستند. جان گوتاق و همکارانش، بر اساس تجربه پروژه A-7 به این نتیجه رسیدند که یکی از مشکلات روش های صوری اندازه سیستم است. دشواری مدیریت حجم بزرگی از توصفات صوری، استفاده از روش های صوری را برای سیستم های بزرگ غیر عملی کرده است.
5-    استفاده از متدهای صوری دشوار است. بخشی از این دشواری مربوط به نحوه نمایش توصیفات میشود. تولید، خواندن، درک و بازبینی حجم بزرگی از توصیفاتی که روی تعداد زیادی صفحه با استفاده از عبارات ریاضی و منطقی نمایش داده شده اند مشکل است. با اینکه توصیف کنندگان افراد متخصص و فنی در تولید توصیفات صوری هستند ولی کاربران چندان علاقمند به خواندن، درک و بازبینی متن های صوری نیستند. این یکی از عواملی است که صنعت نرم افزار مخاف استفاده از رویکردهای صوری در مهندسی نرم افزار است. به همین دلیل برای ساده سازی نمایش توصیفات صوری، روش های صوری بصری معرفی شدند.
استفاده از روش های صوری بصری استفاده از نمادهای گرافیکی برای  توصیف سیستم های نرم افزاری است. در این صورت توصیفات صحیح اند چون صوری اند و درک آن ها آسان است چون بصری اند. از این رو، استفاده از روش های صوری بصری در مهندسی نیازمندی های نرم افزار رفته رفته رایج تر میشود. نمودارد انتقال حالت ماشین های متناهی که مبتنی بر ریاضی است، بهترین تکنیک صوری برای تعریف سیستم ها و توصیف نیازمندیها است. با این حال با رشد خطی اندازه سیستم، تعداد حالات در این ماشین ها به طور تصاعدی افزایش می یابد. چنین رشدی در سیستم های بزرگ منجر به مشکلی معروف به انفجار در تعداد حالات میشود. با تعریف ماشین های متناهی توسعه یافته، تلاش های موفقیت آمیزی در جهت حل این مشکل صورت گرفته است. عمده این تلاش ها توسط هرل با معرفی Statechart انجام شده است.
Statechart
دیوید هرل Statechart را که توسعه یافته ماشین های متناهی است به عنوان یک روش صوری برای توصیف رفتار سیستم های پیجیده معرفی کرد. همچنین هرل و همکارانش برای توصیف، طراحی، تحلیل و مستند سازی سیستم های بزرگ و پیچیده، مجموعه ابزارهایی به نام statemate را توسعه دادند. Statemate برای توصیف رفتار سیستم از Statechart استفاده میکند. به علاوه نمودار فعالیت و نمودار ماژول را به ترتیب در توصیف ساختاری و عملیاتی سیستم به کار میگیرد.
هرل Statechart را به صورت زیر بیان میکند:

منظور از عمق، خوشه بندی حالت ها به یک حالت مافوق و تشکیل سلسله مراتبی از حالت ها است. حالات موازی، ترکیب دو یا چند حالت به یک حالت مافوق است که این حالت مافوق AND-state نامیده میشود.
اگر سیستمی به AND-state برود، بایستی به تمامی مولفه های AND (یعنی زیرحالتهای فوری) آن وارد شود. به طور مشابه اگر سیستمی از AND-state خارج شود، بایستی از تمامی مولفه های AND آن خارج شود. در مقابل AND-state ها، OR-stateها وجود دارند. اگر سیستمی به OR-state برود، بایستی فقط به یکی از زیرحالت های OR-state وارد شود.

برچسب انتقال در Statechart سه مولفه دارد: رخداد، شرط و عملکرد. برای مثال در شکل 1، فرض کنیم سیستم در حالت s1 باشد و رخداد e اتفاق بیفتد، اگر شرط c صحیح باشد آنگاه سیستم از حالت s1 به حالت s2 میرود و عملکرد a بوجود می آید. عملکردی که در حین انتقالی تولید میشود میتواند به عنوان رخداد در انتقال دیگری استفاده شود. بنابراین عملکرد باید بین مولفه ها منتشر شود. مکانیسم رابطه ای استفاده شده در Statechart، ارتباطات جمعی است. برای مثال زمانیکه در یک Statechart رخدادی روی میدهد یا عملکردی تولید میشود، در سراسر Statechart محسوس است. مشکل Statechart پیچیدگی اندازه سیستم است. همچنانکه قبلا اشاره شد، با رشد خطی اندازه سیستم، تعداد حالات در ماشین های متناهی به طور تصاعدی افزایش می یابد. چنین رشدی در سیست های بزرگ منجر به انفجار در تعداد حالات میشود. دروسینسکی و هرل ثابت کردند که Statechart هااز این نظر بهتر از ماشین های متناهی هستند. این اثبات مبتنی بر مکانیزم همزمانی مشارکتی (یعنی حالات موازی) Statechart است وبرای هر مدلی که از این مکانیزم استفاده میکند مثل شبکه های petri بکار گرفته میشود. با افزایش اندازه سیستم، مولفه های موازی Statechart افزایش می یابد. بنا بر این تعداد حالات در Statechart رابطه خطی با اندازه سیستم دارد. بنا به گفته هرل: Statechart اندازه سیستم را نمایش میدهد. حالات موازی یک ویژگی قوی در Statechart محسوب میشود. با این حال افزایش اندازه سیستم ضرورتا منجر به افزایش مولفه های موازی نمیشود. برای مثال اگر توسعه اندازه سیستم موجب افزایش پیچیدگی مولفه ای موازی موجود شود، آنگاه تعداد حالات به طور تصاعدی افزایش خواهد یافت.
مشکل دیگر Statechart فضای نام عمومی است. هیچ مکانیسم کنترلی مرئی در Statechart وجود ندارد. وقتی رخدادی اتفاق میفتد در طول سیستم محسوس است؛ بنابراین باید نام منحصربفردی داشته باشد. در سیستم های نرم افزاری بزرگ، مدیریت فضای نام ها در محیط عمومی Statechart مشکل است. در حالت کلی، مدیریت نام ها بحثی اساسی در مهندسی نرم افزار است.

ادامه دارد…