متدولوژی های اولیه مهندسی نرم افزار :

 

در سال 1962 دایجسترا (Edsger Dijkstra) نظریه ای مبنی بر اینکه یک تکه کد اساساً ریشه در عبارات ریاضی دارد را مطرح نمود . بنابر این عقیده ، او فرض نمود که باید بتوان یک برنامه اختیاری را به دلخواه انتخاب نموده و با برهان و دلایل ریاضی درستی یا نادرستی کارکرد آنرا اثبات نمود .اگرچه ، در آن زمان تلاشهای وی در این زمینه موفقیت زیادی در پی نداشت .اما کمی بعد در سال 1965 دایجسترا و دیگران یکی از مشکلات اساسی ، که امروزه عبارات نا آشنای Go To [ناآشنا به دلیل عدم استفاده از آن] یا پرش های غیر شرطی می باشند ، را هشدار دادند .

در سال 1968 دایجسترا با برهان و استدلال این موضوع که پرش های غیر شرطی مشکلی اساسی به شمار می آیند را اثبات نموده و مقاله ای با عنوان "عبارت Go To یک ضرر قابل توجه "را منتشر ساخت . البته تلاش های دایجسترا تنها محدود به عبارات Go To نشد .کمی بعد در سال 1968 وی نتیجه فعالیت ها و کارهای موفقیت آمیز خود را در راه توسعه یک سیستم عامل منتشر نمود . این مقاله خواندنی در مورد دیدگاه لایه های انتزاعی بحث می نماید ؛ موضوعی که امروزه استفاده از آن رایج می باشد ولی ما کمتر به آن فکر کرده ایم .

در برنامه نویسی ساخت یافته ، دایجسترا نه تنها اصطلاح Structured Programming را وضع و ایجاد کرد بلکه وی بر اهمیت موضوعاتی چون جلوگیری از خطا و مقابله با رخ دادن خطا بجای رفع خطا بعد از وقوع آن تاکید نمود .در مقاله اشاره شده فوق ؛ او این سوال را مطرح ساخت که :

" سوال اصلی این است که آیا می توان قابلیت و قدرت برنامه نویسی را بواسطه اندازه و تکنیک هایی (تکنیک های ذهنی ، سازمانی یا مکانیکی) که بتوانند در فرآیند ترکیب برنامه بکار بسته شوند ؛ بالا برد ؟ "

این سوال هنوز هم برای ما بدون جواب باقی است .

در سال 1966 بوهم (Bohm) و ژاکوپینی (Jacopiny) مقاله خود را به زبان انگلیسی ترجمه و به ACM ارائه دادند .در سال 1967 اصطلاح مهندسی نرم افزار (Software Engineering) برای عنوان سمینار سال 1968 سازمان پیمان آتلانتیک شمالی یا ناتو (NATO) انتخاب شد .که هدف آن ، در میان سایر موارد ، کمک به شناساندن و معرفی مهندسی نرم افزار و دامنه عمل آن بود .

سال 1971 ایده توسعه نرم افزار بوسیله پالایش مرحله ای یا Stepwise Refinement توسط نیکلاس ورث ارائه شد .پالایش مرحله ای کارها و فعالیت های گذشته دایجسترا ، بوهم و ژاکوپینی را روشن و مبرهن ساخت .یک سال بعد دیوید پارناس مقاله خود تحت عنوان "مخفی سازی اطلاعات" را منتشر نمود .دسامبر سال 1973 نشریه Datamation یک شماره از مجله خود را به برنامه سازی ساخت یافته اختصاص داد و تعدادی از برنامه های کاربردی موفق که با این تکنیک ساخته شده بودند را معرفی نمود .

تقریبا اواخر دهه 1960 توسعه دهندگان و سازندگان نرم افزار پی بردند که برنامه نویسی ساخت یافته (و یا در دامنه ای وسیع تر ، کد نویسی ساخت یافته) به تنهایی کارساز و کارگشا نمی باشد .

هالان میلس (Halan D. Mills) فعالیت های خود را بر روی "بهینه سازی برنامه ساز" در پروژه ابر برنامه ساز (SuperProgrammer) متمرکز نمود .که نتایج این کار به مجله نیویورک تایمز هم کشیده شد. درک این موضوع که این پروژه های بزرگ و کارهای دیگران (نظیر فعالیت های لابراتوار SKYLab) ، در راستای اثبات نمودن و نشان دادن ناکافی بودن برنامه سازی ساخت یافته بوده است ، و نیز مفاهیمی همچون "تیم ارشد برنامه ساز" و ویرایش های جدید طراحی ساخت یافته ؛ حائز اهمیت می باشند .

لری کانستنتین (Larry Constantine) (یکی از کارکنان IBM در خلال دهه های 60 و 70 میلادی) موضوع مکانیسم های مستقل برای جلوگیری از طراحی بد از ابتدای شروع پروژه ، و تشخیص مشکلات بالقوه قبل از شروع مرحله تولید نرم افزار را مطرح ساخت. او به همراه Wayne Stevens و Glen Myers طراحی ترکیبی (Composite Design) را که بعدا به طراحی ساخت یافته تغییر نام داد ، ارائه نمود .

دهه 1970 گسترش متدولوژی ها :

 

از اواسط تا انتهای دهه 1970 تعداد متدولوژی های مهندسی نرم افزار به طور عام و تعداد متدولوژی های توسعه نرم افزار به طور خاص به شدت رو به افزایش نهاد. که تعدادی از آنها عبارت بودند از :

• دیدگاههای تجزیه تابعی مسائل همانند تحلیل و طراحی ساخت یافته .

• دیدگاههای داده گرا و ساختار داده ای .

• دیدگاههای رسمی (ریاضی) همانند : Vienna Development Method یا VDM

که احتما لا از بین موارد اشاره شده ، دیدگاه های ساخت یافته متداول تر از بقیه بوده اند .

در ابتدای دهه 80 میلادی متدولوژی های بسیار زیادی مطرح بوده اند که دنبال نمودن هر یک از آنها به طور جداگانه نیاز به زمان زیادی دارد. که برای اطلاع از آنها می توان به بررسی های انجام گرفته و انتشار یافته در این زمینه مراجعه نمود.

وزارت دفاع ایالات متحده آمریکا تعداد 48 متدولوژی متفاوت را بررسی و در انتها نتیجه تحقیقات خود را بر روی 24 مورد از آنها گزارش نموده است .

همچنین در دهه 1980 اهمیت مفاهیمی چون :

• نمونه سازی اولیه یا Prototyping

• مشکلات سیستم های بلا درنگ یا Real Time

• مهندسی نرم افزار به کمک کامپیوتر یا CASE

افزایش قابل ملاحظه ای یافتند.

 

حتی اگر شما از بسیاری ریشه های سنتی مهندسی نرم افزار شیئ گرا (نظیر کارهای اخیر انجام شده در حیطه هوش مصنوعی) چشم پوشی نمائید ؛ باز هم خواهید دید که تکنیک های شیئ گرا از انتهای دهه 1960 موجود بوده اند(بسیاری از متخصصان به کارهای Nygaard و Dahl روی زبان Simula واقف هستند). گرچه از میانه دهه 80 میلادی بسیاری از کارها و فعالیت ها در عرصه شیئ گرایی بر روی برنامه نویسی شیئ گرا متمرکز شده بود.

اگرچه بخش بزرگی از برنامه نویسی شیئ گرا ؛ واقعا کد نویسی شیئ گرا می باشد ولی باید صادق بود و به این موارد اشاره کرد که :

• متدولوژی ها در صورتی که شما مراحل بسیار زیاد و کوچکی برای اجرا داشته باشید و با موارد کوچک بسیار زیادی سر و کار داشته باشید بسیار مهم اند. اشیا و کلاس ها نوعا در مراحل بالای تجرید یا Abstraction قرار دارند. بنابراین متدولوژی های دقیق یا نیمه دقیق برای پروژه های کوچک وغیر حساس ،برخلاف پروژه های مشابه که برای توسعه آنها از دیدگاهها و ابزارهای سنتی استفاده می شود، لازم نمی باشد.

• اگرچه اکثر بحث های شیئ گرا و مقالات این زمینه به ویژگی سطح بالای زبان های برنامه نویسی می پردازند ولی بیشتر مفاهیم مورد بحث (نظیر ارث بری ، انتزاع داده ها ، استفاده مجدد و بازیابی عوامل) بر موضوعاتی دلالت دارند که فراتر از انتزاع سطح پایین و برنامه های ساده است.

• گرچه (از دهه 1980) تا کنون علاقه به مفاهیم شیئ گرا به شدت افزایش یافته است ؛ ولی سبک های شیئ گرا برای برنامه ها و پروژه های بزرگ و حساس کمتر مورد استفاده قرار گرفته است(دقت کنید که من نمی گویم  اصلا استفاده نشده است). بر این اساس درخواست ها و تقاضاها برای متدولوژی های شیئ گرای قوی تا چندی پیش خیلی کم بوده است .

ولی امروزه خیلی چیزها فرق کرده است. تقاضاها برای سبک های شیئ گرا بسیار بسیار زیاد می باشند. وعده و وعیدهای تکنولوژی های شیئ گرا همواره در هر جایی شنیده می شوند. که متدولوژیها نیز همین طور است.

یک زمین بازی را با یک تیم قوی از مهندسین شیئ گرای نرم افزار در وسط زمین تصور نمائید. ما در این زمین دو تیم با دو دیدگاه و رهبری متفاوت از یکدیگر می بینیم :

• یک تیم ، برنامه نویسان شیئ گرا هستند. برای مثال کاربران سیستم ها یا زبانهای برنامه نویسی همچون Smalltalk , C++ , Eiffel. بازیکنان این تیم علیرغم اختلاف نظرهای داخلی شان ، مشکلات بسیار کمی در شناسایی اشیاء و کلاسها دارند. گرچه وقتی از آنان در مورد دیدگاههای واضح و روشن درباره مسائلی مثل طراحی شیئ گرا سوال شود ، آنها پاسخی شبیه : "من می دانم که چگونه کار می کند ولی مطمئن نیستم که بتوانم آنها را برای شما بیان نمایم " ، خواهند داد.

• تیم دیگر نیز گروهی هستند که چمدان های بدون استفاده زیادی به همراه دارند. احتمالا شما حدس خواهید زد که این تیم گروه ساخت یافته می باشند و چمدان های بدون استفاده همراه آنها حاوی نمودارهای جریان داده یا DFD ، نمودارهای موجودیت – ارتباط یا ER و بانک های اطلاعاتی رابطه ای است. وقتی از آنها سوال شود که چرا می خواهند از این موارد برای مهندسی نرم افزار شیئ گرا استفاده نمایند، آنها پاسخ هایی شبیه : " ما می دانیم که چگونه از این ابزارها و موارد استفاده نماییم ولی نمی دانیم که چگونه بدون اینها مشکلاتمان را حل نماییم " و یا " ما مقادیر هنگفتی پول صرف CASE هایی نموده ایم که این موارد را پشتیبانی نمایند و قصد داریم که از آنها استفاده نماییم " ، خواهند داد .

برای هر مشاهده کننده سطحی روشن خواهد بود که چیزی که این دو تیم به آن احتیاج دارند همکاری است. که متاسفانه در جریان کارهای این دو گروه بسیار کم است .

کسانی که به دنبال متدولوژیهای قوی ، خوب و اثبات شده شیئ گرا هستند سه انتخاب زیر را پیش روی دارند :

1. متدولوژی های اولیه شیئ گرایی در میان جامعه برنامه نویسی شیئ گرا. که البته این موارد بیشتر پیشنهادات کمک کننده خواهند بود تا یک متدولوژی.

2. توصیه ها و نظریات کسانی که به تازگی از سبک ساخت یافته به شیئ گرا روی آورده اند. شاید شما تاثیر متفاوتی از کاربرد اصطلاحات شیئ گرا در راهی غیر معمول و برخی اوقات نامناسب توسط این گروه ، دریافت نمائید .

3. آخرین انتخاب جستجو نمودن افرادی است که برای سالها روی متدولوژی های شیئ گرا کار کرده اند ، که از آن جمله می توان به افرادی همچون Grady Booch اشاره کرد. این افراد دو شاخصه و ویژگی اساسی دارند. اول اینکه آنها برای سالهای متمادی روی تکنولوژی شیئ گرا کار کرده اند. و دوم اینکه این افراد دیدگاهی مبتنی بر متدولوژی دارند نه برنامه نویسی .

پی نوشت ها :

انتزاع : Abstraction که آنرا به فارسی معادل عبارات انتزاع یا تجرید قرار داده اند، در برنامه سازی شیئ گرا به فرآیندی اطلاق می شود که در طی آن یک شیئ به اجزا بنیادین خود تجزیه می شود تا تنها عناصر ضروری تعریف شوند. این کار سبب می شود که یک شیئ بر حسب خصوصیات، رفتارها (عملکردها) و رابط (روش برقراری ارتباط با اشیا دیگر) خود تعریف شود.

 

ACM : انجمن ماشینهای محاسباتی واقع در آمریکا، سرنام Association for Computing Machinery

 

بهینه سازی برنامه ساز : Optimizing the Programmer

 

Booch : از دانشمندان سرشناس در حیطه مهندسی نرم افزار شیئ گرا می باشد. وی یکی از سه پایه گذار زبان UML بوده است و هم اکنون به عنوان دانشمند ارشد در شرکت Rational مشغول به کار است.