ساخت نرمافزار
ساخت نرمافزار شاخه ای از مهندسی نرمافزار است. در این شاخه از ترکیبی از کد نویسی، بازبینی، آزمون واحد، آزمون یکپارچگی، و اشکال زدایی بهره برده شده تا نرمافزاری دقیق، معنادار و حاوی جزئیات فراوان خلق شود. ساخت نرمافزار شاخه ای است که به صورت بسیار نزدیکی به دیگر شاخههای مهندسی نرمافزار (همانند طراحی نرمافزار و تست نرمافزار) متصل میباشد.
مبانی ساخت نرمافزار
به حداقل رساندن پیچیدگی
کاهش پیچیدگی نرم فزار به صورت عمده از آن جایی ناشی میشود که اکثریت مردم توانایی به حافظه سپردن جزئیات ساختاری و اطلاعات پیچیده را در حافظه خود ندارند. کاهش پیچیدگی تنها از راه تأکید بر خلق کدهای ساده و خوانا میسر است، و هوشمندانه بودن کدها تنها بر پیچیدگی کد میافزاید. برای خلق کدهای ساده و خوانا، میبایست از یک سری اصول، استانداردها و تکنیکهای برنامهنویسی تبعیت کرد. استفاده از تکنیکهای کیفیت متمرکز بر ساخت نیز برای کا
پیش بینی تغییر
پیشبینی تغییرات این امکان را به مهندسهای نرمافزار میدهد تا برنامههای قابل توسعه ای را بسازند، بدون آنکه نیازی به برهم زدن زیرساختار درونی آن برنامه باشد. تجربه نشان میدهد که هزینه دوباره کاری در یک برنامه میتواند بین ۱۰ تا ۱۰۰ برابر هزینه اولیه در نوشتن برنامه تمام شود. به صورت میانگین، در هر پروژه ای جدود ۲۵ درصد تغییرات آتی انجام میگیرد، بنابراین پیشبینی تغییرات در یک پروژه از اهمیت خاصی برخوردار است.
ساخت مبنایی برای بازبینی
ساختار مبنا برای بازبینی به معنی ساختن نرمافزار به طریقه ای است که بتوان در آن خطاهای سیستمیک را در زمان برنامهنویسی، تستهای مستقل، یا استفاده از نرمافزار، شناسایی و حذف کرد. تکنیکهای ویژه ای که منجر به ایجاد مبنایی برای بازبینی مجدد نرمافزار میشوند بسیار متنوع بوده و میتواند شامل استفاده از استانداردهای کدنویسی بازبینی کد، تستهای واحد، تستهای اتوماتیک، و عدم نوشتن کدهای بسیار پیچیده میباشد.
استفاده مجدد
استفاده مجدد سیستماتیک بهرهوری، کیفیت و بهبود هزینههای را منجر میشود و دارای دو رویهٔ کاملاً نزدیک به هم است:
- ایجاد ساختاری در نرمافزار برای استفاده مجدد در نرمافزار.
- ایجاد نرمافزار با استفاده از استفاده مجدد.
استانداردهای ساخت نرمافزار
اسناتداردها – چه استانداردهای برون سازمانی یا استانداردهای درون سازمانی – میتوانند سبب تأثیر بالقوه ای بر روی نرم افزاها گردند. این استانداردها شامل:
- استاندادرهای ارتباطی (همانند استانداردهای مربوط یه فرمت و محتوای مدارک)
- زبانهای برنامهنویسی
- استانداردهای کد نویسی
- پایگاههای داده
- ابزار (همانند استانداردهای نماد گذاری) است.
مدیریت ساخت نرمافزار
مدلهای ساختاری نرمافزار
مدلهای متعددی برای ایجاد نرمافزار معرفی شدهاند، که از بین آنها برخی مدلها تأکید بیشتری بر ساخت دارند. از دیدگاه سامدلهای Waterfall و Stage-Delivery Life Cycle). این مدلها به ساخت نرمافزار، نگاه و رفتاری همانند فعالیتی دارند که حتماً میبایست پیش از آن تمامی پیش نیازات اساسی برنامه مربوطه برآورده شود. بسیاری از مدلهای دیگر تکرار شوندهاند (همانند مدلهای evolutionary prototyping, Extreme Programming، و Scrum. این مدلها تمایل نسبتاً بیشتری دارند تا با ساخت نرمافزار به صورت فعالیتی همزمان با دیگر فعالیتهای ایجاد نرمافزار رفتار کنند.
برنامهریزی ساخت نرمافزار
انتخاب روش ساخت نرمافزار یکی از وجهههای کلیدی برنامهریزی ساخت نرمافزار میباشد. انتخاب روش ساخت نرمافزار تعیینکننده وسعت پیش نیازهای ساخت، ترتیب آنها و درجه ای از تکمیل آن پیش نیازها قبل از شروع عملیات ساخت است. برنامهریزی ساخت نرمافزار همچنین تعیینکننده ترتیب ساخت و اجتماع اجزا، روند مدیریت کیفیت برنامه، تخصیص عملیات به مهندس واجد صلاحیت و غیره بر اساس نوع مدل انتخابی است.
اندازهگیری ساخت نرمافزار
تعدا بسیار زیادی از فعالیتها و مصنوعات ساخته شده میتوانند اندازهگیری شوند؛ بهطور مثال: کد نوشته شده، کد بهینه شده، کد باز استفاده شده، کد تخریب شده، پیچیدگی کد، آمار بازبینی کد، تعداد خطاهای یافت شده و برطرف شده، و زمانبندی. این اطلاعات از آنجایی مفید هستند که میتوانند ما را در دستیابی به اهدافی همانند مدیریت ساخت، تضمین کیفیت حین ساخت، و ارتقا روند ساخت یاری کنند.
ساخت نرمافزار با تعدادی ملاحظات عملی همراه است و بایستی به این ملاحظات توجه شود:
طراحی ساخت
به منظور جلوگیری از فاصلههای پیش رو در طراحی نرمافزار، بهینهسازیهایی را میبایست حین ساخت نرم فزار در مقیاسهای کوچکتر یا بزرگتری صورت داد، تا بتوان با کمک آن به جزئیات طراحی نرمافزار افزود.
Fan Out پایین یکی از ویژگیهای طراحی ای است که بسیاری از محققان این حوزه آن را بسیار مفید ارزیابی کردهاند. ثابت شدهاست که تکنیک پنهان کردن اطلاعات میتواند تکنیکی بسیار مفید در برنامهنویسیهای با مقیاس بزرگ باشد. این تکنیک توانایی آسان تر کردن برنامهها تا اقلاً ۴ برابر حالتی که بکار گرفته نشود را دارارست.
زبانهای ساخت نرمافزار
زبانهای ساخت شامل تمامی فرمهای ارتباطی ای میباشند که با استفاده از آنها، انسان یک راه حل مسئله قابل اجرا را به کامپیوتر معرفی کند. زبانهای ساخت شامل زبانهای تنظیماتی، زبانهای جعبه ابزار، و زبانهای برنامهنویسی میباشد که در زیر شرح هر یک به صورت مختصر آمده است.
- زبانهای تنظیماتی: این زبانها همان زبانهایی هستند که مهندسین نرمافزار درون آنها از یکسری از اختیارات از پیش تعریف شده برای خلق نصب جدید نرمافزارها بهره میبرند.
- زبانهای جعبه ابزار: مهندسی نرمافزار از این زبانها برای ساخت برنامهها استفاده میکنند و این زبانها پیچیدهتر از زبانهای تنظیماتی هستند.
- زبانهای نوشتاری: این زبانها کدهای نوشتاری را بیشتر پشتیبانی کرده و اغلب به تفسیر نوشتار بجای کامپایل کردن آنها میپردازند.
- زبانهای برنامهنویسی: این زبانها انعطافپذیرترین نوع نرمافزارهای ساخت هستند که معمولاً از سه نوع عمومی نشانه گذاری استفاده میکنند:
- نشانه گذاری زبانی: این نوع نشانه گذاری از کلمات و آرایه ای از کلمات برای نمود ساخت نرمافزارهای پیچیده استفاده میکند. دستورها درونی این نوع نشانه گذاری شبیه به جملات زبانی هستند.
- نشانه گذاری رسمی (ریاضیاتی): این نشانه گذاری از کلمات و محاورات روزمره دور تر بوده و با استفاده از تعریفات ریاضیاتی نوشته میشود.
- نشانه گذاری بصری: این نوع نشانه گذاری، از موجودیتهای بصری برای نمود نرمافزارهای زیر ساخت بهره میبرد.
برنامهنویسهایی که اقلاً سه سال در زمینه یک زبان برنامهنویسی کار کرده باشند، از کارایی حدود ۳۰ درصد بیشتر از برنامه نویسان تازهوارد برخوردار هستند. زبانهای سطح بالا همانند زبانهای ++C، جاوا، Smalltalk، و Visual Basic از ۵ الی ۱۵ درصد افزایش بهرهوری، سادگی، قابل اعتمادی، و قابلیت درک نسبت به زبانهای سطح پایین دارا میباشند. برای نوشتن برنامه ای یکسان، تعداد کد خطهای کمتری در زبانهای برنامهنویسی سطح بالا نیاز است.
کد زنی
در ساخت نرمافزار میبایست به ملاحظات مربوط یه کد زنی که در زیر آمدهاند توجه ویژه داشت:
- از تکنیکهای نوشتار کدهای مرجع قابل فهم، اعم از نامگذاری و ترکیب بندی کد پایه استفاده شود. مطالعات پیشین نشان دادهاند که در صورتی که طول متغیرهای یک کد از ۱۰ تا ۱۶ حرف تجاوز نکند، میتوان آن کد را با کمترین تلاش و پیچیدگی ای خطا زدایی کرد.
- حتماً از کلاس، انواع شمارش، متغیرها، ثابتهای اسمی و دیگر مسائل مشابه استفاده شود و در استفاده از آنها میبایست به نکات زیر توجه داشت:
- مطالعه ای در ناسا (سازمان فضایی آمریکا) انجام گرفت که در آن صریحاً اعلام شده بود که کلاس بندی درست کدها میتواند قابلیت استفاده مجدد از آنها را در قیاس با کدنویسی عملکردی تا دو برابر افزایش دهد.
- نتایج تحقیقات نشان دادهاند که قرار دادن آرایهها متعاقب یکدیگر میتواند تعداد متغیرها و ارجاعات آنها را کاهش دهد.
- استفاده از ساختارهای کنترلی ضروری است و در استفاده از آنها باید ملاحظات زیر در نظر گرفته شوند:
- استفاده از حلقههای با دستور Exit بیش از حلقههای دیگر قابل فهماند.
- هرگز از حلقهها یا شرطهای تو در توی بیش از سه مرحله خودداری شود زیرا فهم آنها برای بسیاری از برنامه نویسان مشکل است.
- در صورت پیچیدگی روند کنترل، کدهای نوشته شده از اعتبار و پایایی کمی برخوردار بوده و خطاهای مستمری را نشان خواهند داد.
- همواره باید سعی شود که خطاهای برنامهریزی شده یا ناگهانی مدیریت شوند (بهطور مثال با ایجاد استثناءها).
- باید از انشعابات تضمینی مراحل کد اجتناب شود.
- بهتر است از قواعد و مکانیزمهای استخراج برای استفاده مجدد از منابع استفاده شود (همانند استفاده از thread و database lock).
- حتماً کدهای پایه میبایست با استفاده از بیانها یا روالها سامان داده شوند؛ که در این مسیر باید به نکات زیر توجه کرد:
- روالهای با پیوستگی بالا کمتر مستعد خطا نسبت به روالهای با پیوستگی پایین هستند. در مطالعات انجام شده نیز این امر ثابت شدهاست بدین صورت که در یک مطالعه ۴۵۰ روال بررسی شده و دیدیه شدهاست که حدود ۵۰ درصد روالها دارای پیوستگی بالایی بوده و تقریباً نسبت به ۱۸ درصد روالها با پیوستگی پایین، عاری از هر گونه خطا بودهاند.
- اگرچه مطالعاتی که تا کنون انجام شدهاند نتوانستهاند رابطه قاطعی را میان سایز کد روال نوشته شده با تعداد خطاهای محتمل در آن بیابند، اما مواردی هم بودهاند که به وضوح بیان کردهاند که تعداد کدهای کمتر از ۱۴۳ خط اقلاً هزینه ای کمتر از نصف کدهای بیشتر از آن تعداد خط در رفع خطاها داشتهاند. مطالعات دیگری نیز نشان دادهاند که اگر سایز روالها بین ۱۰۰ تا ۱۵۰ خط کد باشد، کمترین نیاز ممکنه برای تغییر آنها و ویرایش آنها وجود خواهد داشت.
- فصل مشترک میان کدها مستعد بیشترین خطاهاست که در مطالعات انجام شده حدود ۳۹ درصد از خطاها مربوط به این نواحی هستند.
- پارامترهای بلااستفاده احتمال خطاهای وارده را بیشتر میکنند.
- تعداد پارامترهای یک روتین باید حداکثر ۷ تا باشد؛ این بدان دلیل است که خوانندگان توانایی درنبال کردن بیش از ۷ قطعه اطلاعاتی را ندارند.
- علاوه بر استفاده از روالها و بیانها، میبایست کدهای پایه را به کلاسها، پکیجها، و دیگر ساختارها نیز سامان داد. توجه داشته باشید که تعداد اعضا یک کلاس نباید از ۷+/-۲ عدد تجاوز کند زیرا که این تعداد حداکثر تعداد فعالیتهای گسسته ای است که یک فرد میتواند حین انجام فعالیتهای دیگر در ذهن داشته باشد. زمانی که وراثت را در نظر میگیریم، تعداد مراحل درخت وراثت باید محدود باشند. تعداد توارث بالا به صورت بالقوه ای با تعداد خطاهای برنامهنویسی در ارتباط است. تعداد روتینهای درون یک کلاس باید تا جای ممکن محدود در نظر گرفته شود.
- همواره میبایست به مستندسازی و میزان سازی کدها توجه ویژه داشت.
تست ساخت نرمافزار
هدف از تست نرمافزار کاهش فاصله زمانی آشکار سازی خطاهای کدنویسی است. در بسیاری از مواقع، تست ساخت بلااستفاده پس از نوشتن کد اولیه صورت میپذیرد. در راستای این هدف معمولاً مهندس نرمافزار، از دو روش تست کردن استفاده میکند: تست واحد و تست مجتع.
- تست واحد
- تست مجتمع
استفاده مجدد
استفاده مجدد از یک نرمافزار چیزی فراتر از خلق و استفاده از کتابخانههای آن است. فعالیتهای مربوط به استفاده مجدد از ساخت نرمافزار در خلال کدنویسی و تست آن عبارتند از:
- انتخاب واحدهای قابل استفاده مجدد، پایگاههای داده، روند تست، و داده تست
- ارزیابی کد و تست قابلیت آن جهت استفاده مجدد
- گزارش استفاده مجدد روی کدهای جدید، روندهای تست، و داده تست
کیفیت ساخت
تکنیکهای اولیه اطمینان از کیفیت کد ساخته شده عبارتند از:
- تست واحد و تست مجتمع: در مطالعات پیشین به وضوح بیان شدهاست که میزان آشکارسازی میانگین خطاها در دو روش تست واحد و تست مجتمع به ترتیب ۳۰ و ۳۵ درصد هستند.
- تست اولین توسعه
- استفاده از روشهای برنامهنویسی assertion و defensive
- خطا زدایی
- نظارت: مطالعات نشان دادهاند که میزان میانگین آشکار سازی خطا در نظارتهای رسمی کدها حدود ۶۰ درصد است. در راتباط با هزینه یافتن خطاها، مطالعه ای نشان داده است که خواندن خط به خط کدها بیش از ۸۰ درصد خطا را نسبت به عملیات تست کردن آشکار کردهاست. این روش بسیار بهینه تر از روشهای تست کردن میتواند خطاهای ناشی از طراحی را آشکار کند. به همچنین مطالعات نشان دادهاند که نظارت منجر به کمتر شدن ۲۰ تا ۳۰ درصدی خطاها در یک کد هزار خطی شده و منجر به افزایش بهرهوری ۲۰ درصدی میگردد. نظارتهای رسمی معمولاً بین ۱۰ تا ۱۵ درصد کل بودجه پروژه را شامل میشوند و معمولاً هزینه کلی پروژه را کاهش میدهند. معمولاً حد اکثر تعداد ناظران را ۲ تا ۳ نفر در نظر میگیرند و افزایش تعداد آنان توفیقی در آشکار سازی خطاها نخواهد داشت.
- بازبینی فنی: میزان میانگین آشکار سازی خطاها از طریق بازبینی غیررسمی و چک پشت میز به ترتیب حدود ۲۵ و ۴۰ درصد هستند. جلسات بازبینی خطاها نیز توانایی آشکار سازی حدود ۲۰ تا ۴۰ درصدی خطاها را دارا بوده که در فشار بسیار بالای کاری، هزینه ای بسیار بالا را در برخواهند داشت. بازبینی فنی در سازمان فضایی آمریکا نیز پیاده شد که توانایی آشکارسازی حدود ۳٫۳ خطا در ساعت را دارا بود؛ درحالی که روشهای تست معمولی توانایی آشکار سازی ۱٫۸ خطا را در ساعت داشتند.
- آنالیز آماری
مطالعات نشان دادهاند که ترکیبی از این تکنیکها نیاز مورد استفاده قرار گیرد برای رسیدن به بالا در تشخیص نقص رأی دادن. مطالعات دیگر نشان داد که افراد مختلف تمایل به پیدا کردن مختلف نقص. یک مطالعه نشان داد که شدید برنامهنویسی شیوههای جفت برنامهنویسیبا میز چکهای تست واحدبا ادغام تستو آزمون رگرسیون میتواند دستیابی به ۹۰ درصد نقص نرخ تشخیص است. یک آزمایش شامل برنامه نویسان با تجربه دریافتند که بهطور متوسط آنها قادر به پیدا کردن ۵ خطا (۹ در بهترین حالت) از ۱۵ خطاها توسط تست.
۸۰ درصد از خطاهای یک برنامه در ۲۰ درصد کلاسهای و روالهای آن برنامه متمرکز شدهاند. ۵۰ درصد خطاها در ۵ درصد کلاسهای پروژه وجود دارند. شرکت IBM با تعمیر و نوشتن مجدد حدود ۳۱ کلاس از ۴۲۵ کلاس یک برنامه خود، تعداد خطاهای موجود را یک دهم و هزینه نگهداری را ۴۵ درصد کاهش داده است.
اجتماع
یکی از فعالیتهای بسیار مهم در زمینه ساخت نرمافزار اجتماع کلاسها، روالها، اجزا و زیر سیستمهای برنامه مربوطه است. به علاوه این نیاز بسیار محتمل است که یک سیستم نرمافزاری با دیگر سیستمهای نرمافزاری یا سختافزاری اجتماع یابند. همواره در ارتباط با اجتماع اجزا نگرنیهایی وجود داشته و دارند که برخی از آنها عبارتند از: ترتیب اجتماع اجزا، خلق داربستهایی برای پشتیبانی از نسخههای درونی نرمافزار، تعیین درجه تست و کیفیت کار هر جزء پیش از اجتماع آن، و تعیین نقاطی از پروژه که در آنها نسخههای درونی نرمافزار تست میشوند.
فناوریهای ساخت
مسائل مربوط به زمان اجرا شی گرا
زبانهای شی گرا سری هی مختلفی از مکانیزمهای runtime را پشتیبانی میکنند که استفاده از آنها سبب افزایش انعطافپذیری و تطبیق پذیری برنامهها میگردد (همانند خلاصه سازی داده، وراثت، پلی مورفیسم، بازتاب و …).
خلاصه سازی داده به روندی میگویند که در طی آن دادهها و برنامهها به وسیله بیانی یکسان با معنایشان معرفی میشوند در حالی که جزئیات اجرایی آنان مخفی میگردد. مطالعات آکادمیک نشان دادهاند که خلاصه سازی داده فهم برنامهها را ۳۰ درصد سادهتر از برنامههای عملکردی میکند.
حکمیت، طراحی با تعهد، و برنامهنویسی تدافعی
حکمیت، گزاره ای قابل اجرا درون یک برنامه است که به برنامهنویس اجازه چک در زمان اجرا برنامه را میدهد. طراحی با تعهد به روشی میگویند که در آن پیش شرط و پس شرطهایی مشمول هر روال میشوند. برنامهنویسی تدافعی، روشی است که در آن از شکست یک روال در برابر ورودیهای نامعتبر آن جلوگیری میشود.
مدیریت خطا، مدیریت استثناء، و دامنه خطا
مدیریت خطا به نوعی برنامهنویسی اطلاق میشود که در آن پیشبینیها و کد نویسیهایی برای خطاهای حین اجرا یک برنامه صورت میگیرد. مدیریت استثنا ساختاری در برنامهنویسی است که با کمک آن میتوان در صورت بروز پی در پی خطا (چه یکسان و چه متغیر) برنامه را مجاب کرد تا به روند عادی اجرا خود بپردازد. دامنه خطاها به مجموعه ای از تکنیکها اطلاق میشود که به کمک آنها میتوان خطاهای یک برنامه را آشکار کرده و تمهیدات لازم را برای بازیابی مجدد برنامه فراهم کرد. این مجموعه تکنیک، اعتبار برنامهها را افزایش میدهند.
تکنیکهای برنامهنویسی State-Based و Table-Driven
برنامهنویسی state-based نوعی فناوری برنامهنویسی است که از تعداد محدودی ماشین حالت بهره برده تا رفتارهای یک برنامه را توصیف کند. روش table-driven روشی است که در آن از جعبههایی نمایشی بجای بیانهای منطقی برای نمایش اطلاعات استفاده میشود.
تنظیمات در زمان اجرا و بینالمللی کردن آن
تنظیمات در زمان اجرا، تکنیکی هست که در آن مقادیر متغیرها و تنظیمات برنامهها با یکدیگر باند میشوند. این امر با خوانش همزمان تنظیمات و بروزرسانی آنان انجام میپذیرد. بینالمللی سازی فعالیتی است که در آن یک برنامه (معمولاً یک برنامه تعاملی) برای پشتیبانی چند منطقه آماده میشود. در طی این فعالیت، تمهیداتی چیده میشود که هر برنامه زبان آن منطقه را پشتیبانی کند.
جستارهای وابسته
پانویس
- ↑ SWEBOK Pierre Bourque, Robert Dupuis; executive editors, Alain Abran, James W. Moore, ed. (2004). "Chapter 4: Software Construction". Guide to the Software Engineering Body of Knowledge. IEEE Computer Society. pp. 4–1 – 4–5. ISBN 0-7695-2330-7. Archived from the original on 14 July 2014. Retrieved 10 April 2017.
- ↑ McConnell 2004, Chapter 4.
- ↑ McConnell 2004, Chapter 21.
- ↑ McConnell 2004, Chapter 20.
- ↑ McConnell 2004, Chapter 22.