توسعه ماژول های نرم افزاری برای نرم افزار سیستم های کامپیوتری. برنامه کاری تمرین آموزشی برای ماژول حرفه ای "توسعه ماژول های نرم افزاری برای سیستم های کامپیوتری". نام نتایج تمرین

وزارت آموزش و پرورش و علوم

جمهوری خلق دونتسک

ایالت حرفه ای

موسسه تحصیلی

"کالج صنعتی و اقتصادی دونتسک"

برنامه کاری

تمرین آموزشی UP.01

ماژول حرفه ای PM.01 توسعه ماژول های نرم افزاری برای سیستم های کامپیوتری

تخصص 09.02.03 "برنامه نویسی در سیستم های کامپیوتری"

گردآوری شده توسط:

ولکوف ولادیمیر الکساندرویچ، معلم رشته های کامپیوتری رده صلاحیت "متخصص بالاترین رده"، موسسه آموزشی دولتی "کالج صنعتی و اقتصادی دونتسک"

این برنامه توسط: Vovk Pavel Andreevich، مدیر "سرویس فناوری اطلاعات هوشمند" تایید شده است.

1. گذرنامه برنامه تمرین
2. نتایج تمرین
3. ساختار و محتوای تمرین
4. شرایط برای سازماندهی و انجام تمرین
5. نظارت و ارزیابی نتایج تمرین

1 گذرنامه برنامه تمرینی آموزشی بالا. 01

1.1 محل تمرین تمرین UP.01

برنامه تمرین آموزشی UP.01 ماژول حرفه ای PM.01 "توسعه ماژول های نرم افزاری برای سیستم های کامپیوتری" تخصص 09.02.03 "برنامه نویسی در سیستم های کامپیوتری" » گروه بزرگ 09.00.00 "انفورماتیک و مهندسی رایانهاز نظر تسلط بر نوع اصلی فعالیت حرفه ای (VPD):

توسعه ماژول های نرم افزاری نرم افزاری برای سیستم های کامپیوتری و صلاحیت های حرفه ای مرتبط (PC):

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

برنامه تمرین آموزشی UP.01 ماژول حرفه ای PM.01 "توسعه ماژول های نرم افزاری نرم افزار برای سیستم های کامپیوتری" را می توان در آموزش های حرفه ای اضافی و آموزش حرفه ای کارکنان برای تخصص ها استفاده کرد 09.02.03 برنامه نویسی در سیستم های کامپیوتری با درجه دوم ( کامل) آموزش عمومی. سابقه کار الزامی نیست.

1.2 اهداف و مقاصدتمرین آموزشی UP.01

به منظور تسلط بر نوع مشخص شده فعالیت حرفه ای و شایستگی های حرفه ای مربوطه، دانشجو در دوره تمرین آموزشی UP.01 باید:

داشتن تجربه عملی:

توسعه یک الگوریتم برای کار و اجرای آن با ابزار طراحی به کمک کامپیوتر;

توسعه یک کد محصول نرم افزاری بر اساس مشخصات نهایی در سطح ماژول؛

استفاده از ابزارها در مرحله اشکال زدایی یک محصول نرم افزاری؛

تست یک ماژول نرم افزار با توجه به یک سناریوی خاص؛

قادر بودن به:

توسعه کد ماژول برنامه را در زبان های برنامه نویسی مدرن انجام دهید.

ایجاد یک برنامه با توجه به الگوریتم توسعه یافته به عنوان یک ماژول جداگانه.

اشکال زدایی و آزمایش برنامه در سطح ماژول؛

تهیه اسناد نرم افزاری؛

از ابزارهایی برای خودکارسازی تهیه اسناد استفاده کنید.

بدانید:

مراحل اصلی توسعه نرم افزار؛

اصول اولیه فناوری برنامه نویسی ساختاری و شی گرا؛

اصول اولیه اشکال زدایی و تست محصولات نرم افزاری؛

روش ها و ابزارهای توسعه اسناد فنی.

1.3 تعداد هفته(ساعت ها) برای توسعه برنامهتمرین آموزشی UP.01

فقط 1.5 هفته و 54 ساعت.

2 نتایج تمرین

نتیجه تمرین آموزشی UP.01 ماژول حرفه ای PM.01 "توسعه ماژول های نرم افزاری نرم افزاری برای سیستم های کامپیوتری" توسعه صلاحیت های عمومی است (OK):

	نام نتیجه تمرین
	-
OK 2. فعالیت های خود را سازماندهی کنید، روش ها و روش های استاندارد را برای انجام وظایف حرفه ای انتخاب کنید، اثربخشی و کیفیت آنها را ارزیابی کنید.
OK 3. تصمیم گیری در استاندارد و موقعیت های غیر استانداردو مسئولیت آنها را بر عهده بگیرد.
OK 4. جستجو و استفاده از اطلاعات لازم برای اجرای مؤثر وظایف حرفه ای، توسعه حرفه ای و شخصی.
OK 5. استفاده از فناوری اطلاعات و ارتباطات در فعالیت های حرفه ای.
خوب 6. کار در یک تیم و در یک تیم، ارتباط موثر با همکاران، مدیریت، مصرف کنندگان.
OK 7. مسئولیت کار اعضای تیم ( زیردستان ) را در قبال نتیجه تکمیل وظایف به عهده بگیرید.	-
	صلاحیت های
OK 9. در شرایط تغییر مکرر فناوری ها در فعالیت حرفه ای حرکت کنید.

شایستگی های حرفه ای (PC):

نوع فعالیت حرفه ای		نام نتایج تمرین
تسلط بر نوع اصلی فعالیت حرفه ای		استفاده از منابع شبکه های کامپیوتری محلی و جهانی؛ مدیریت فایل های داده در دستگاه های ذخیره سازی محلی، قابل جابجایی و همچنین بر روی دیسک های محلی شبکه کامپیوتریو در اینترنت؛ چاپ، تکثیر و کپی اسناد روی چاپگر و سایر تجهیزات اداری. کنترل جاری در قالب یک گزارش در مورد هر کار عملی. آزمون صلاحیت ماژول
		سواد و دقت کار در برنامه های کاربردی: ویرایشگرهای متن و گرافیک، پایگاه های داده، ویرایشگر ارائه. سرعت جستجوی اطلاعات در محتویات پایگاه های داده
		دقت و سواد تنظیمات ایمیل، سرور و نرم افزار مشتری: سرعت جستجوی اطلاعات با استفاده از فناوری ها و خدمات اینترنت؛ دقت و سواد ورود و انتقال اطلاعات با استفاده از فناوری ها و خدمات اینترنتی.
		سواد در استفاده از روش ها و ابزارهای محافظت از اطلاعات در برابر دسترسی غیرمجاز؛ صحت و صحت پشتیبان گیری و بازیابی اطلاعات؛
		سواد و دقت سیستم های فایل، فرمت های مختلف فایل، برنامه های مدیریت فایل;
		نگهداری گزارشات و مستندات فنی

3 ساختار و محتوای برنامهتمرین UP.01

3.1 طرح موضوعی

کدهای شایستگی های تولید شده	نام ماژول حرفه ای	محدوده زمانی, به تمرین اختصاص داده شده است (در هفته ها, ساعت ها)	تاریخ
PC 1.1 - PC 1.6	PM.01 "توسعه ماژول های نرم افزاری برای سیستم های کامپیوتری"	1.5 هفته 54 ساعت

3.2 تمرین محتوا

فعالیت ها	انواع مشاغل		نام رشته های دانشگاهی, دوره های بین رشته ای که موضوعات را نشان می دهد, اطمینان از انجام انواع کار	تعداد ساعات (هفته)
"تسلط بر نوع اصلی فعالیت حرفه ای »	مبحث 1.مقدمه. الگوریتم های حل مسائل ساختار الگوریتم خطی ساختار الگوریتم چرخه ای الگوریتم یک زیر برنامه (تابع).	دانشی را در مورد اصول ایجاد اشیاء خاص تشکیل داد
	موضوع2 . خراش محیطی (خراش).	دانش تشکیل شده در مورد اصول ابزارهای اتوماسیون فرآیند دانش تشکیل شده در زمینه مبانی افکت های انیمیشن بر روی اشیاء. استفاده از لینک ها و دکمه ها؛ راه اندازی نسخه ی نمایشی؛ ارائه ها در قالب های مختلف ذخیره می شوند.	MDK.01.01 "برنامه نویسی سیستم"
	موضوع 3 . ایجاد یک برنامه آموزشی (درسی از موضوع).	دانشی را در مورد مبانی تجزیه و تحلیل داده ها با استفاده از توابع پردازنده تشکیل داد	MDK.01.02 "برنامه نویسی کاربردی"
	مبحث 4.توسعه برنامه بازی.	دانشی در مورد اصول اولیه محاسبه ویژگی های نهایی شکل گرفت	MDK.01.01 "برنامه نویسی سیستم"
	مبحث 5.زبان برنامه نویسی گرافیکی LabVIEW.	دانشی در مورد اصول اولیه ایجاد یک آزمون پردازنده تشکیل شده است.	MDK.01.02 "برنامه نویسی کاربردی"
	موضوع 6. ساخت اپلیکیشن با استفاده از LabVIEW	دانشی از اصول گفتگوی کاربر با سیستم تشکیل شده است	MDK.01.02 "برنامه نویسی کاربردی"
	موضوع 7 استفاده مجدد از بخشی از برنامه	دانش شکل گرفته از اپراتورها و عملکردهای سیستم.	MDK.01.02 "برنامه نویسی کاربردی"
	موضوع 8 کارگاه آموزشی LabVIEW محافظت از کار هنگام کار با رایانه در محل کار کاربر.	دانش تشکیل شده در مورد محاسبه توابع ابتدایی. دانش در مورد حمایت از کار شکل گرفت.	MDK.01.02 "برنامه نویسی کاربردی". OP.18 "حمایت از کار"
	موضوع 9 نتیجه گیری تدوین گزارش تمرین.	مهارت های تجزیه و تحلیل شکل گرفت فناوری رایانه، مهارت های حل مسئله شکل می گیرد.	MDK.01.01 "برنامه نویسی سیستم" MDK.01.02 "برنامه نویسی کاربردی" MDK.04.01 "نرم افزار آفیس"

4 شرایط سازماندهی و انجام

تمرین آموزشی بالا. 01

4.1 ملزومات مستندسازی, برای تمرین لازم است:

برنامه کاریتمرین آموزشی UP.01 ماژول حرفه ای PM.01. "توسعه ماژول های نرم افزاری برای سیستم های کامپیوتری" بخشی از برنامه آموزشی برای متخصصان سطح متوسط ​​توسط موسسه آموزشی دولتی "دانشگاه صنعتی و اقتصادی دونتسک" مطابق با استاندارد آموزشی دولتی آموزش حرفه ای متوسطه در تخصص 09.02.03 است. "برنامه نویسی در سیستم های کامپیوتری"، بر اساس برنامه درسی در تخصص، برنامه کاری در رشته های MDK.01.01 "برنامه نویسی سیستم"، MDK01.02 "برنامه نویسی کاربردی"، توصیه های روش شناختی برای حمایت آموزشی و روش شناختی برای تمرین دانش آموزانی که تسلط دارند. برنامه های آموزشی دوره متوسطه حرفه ای.

4.2 الزامات حمایت آموزشی و روش شناختی از عمل:

لیست وظایف تایید شده بر اساس نوع کار، دستورالعمل هابرای دانش آموزان در مورد عملکرد کار، توصیه هایی برای اجرای گزارش های عملی.

4.3 الزامات لجستیک:

سازماندهی فعالیت های صنعتی مستلزم وجود کلاس های درس و آزمایشگاه است.

تجهیزات اداری و محل کار:

صندلی ها با توجه به تعداد دانش آموزان (میز، کامپیوتر، صندلی)؛

محل کار معلم (میز، کامپیوتر، صندلی)؛

کابینت برای نگهداری وسایل کمک آموزشی و حامل های اطلاعات؛

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

ادبیات مرجع و روشمند؛

مجموعه ای از سیستم ها، برنامه های کاربردی و برنامه های آموزشی برای رایانه شخصی در رسانه های نوری و الکترونیکی.

مجله آموزش دانشجویان در مورد حمایت از کار؛

مجموعه ای از وسایل کمک آموزشی

وسایل کمک آموزشی فنی:

تابلوی کلاس؛

کامپیوتر شخصی با نرم افزار دارای مجوز؛

پرینتر لیزری؛

• رایانه های شخصی آموزشی;

  مجموعه ای از تجهیزات تعاملی (پروژکتور، صفحه نمایش، بلندگو)؛

  وسیله اطفاء حریق (اطفاء حریق).

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

تمام کامپیوترهای کلاس به هم متصل هستند شبکه محلی، به شبکه ذخیره سازی اطلاعات دسترسی داشته باشند و به اینترنت دسترسی داشته باشند.

تجهیزات ارتباطی:

آداپتورهای شبکه؛

کابل شبکه؛

تجهیزات بی سیم WiFi.

قطعات برای نصب شبکه، تجهیزات برای نصب.

4.4 فهرست نشریات آموزشی, منابع اینترنتی, ادبیات اضافی

منابع اصلی:

اولیفر وی.جی. شبکه سیستم های عامل: کتاب درسی برای دانشگاه ها / V.G. Olifer, N.A. Olifer. - ویرایش دوم - سنت پترزبورگ: پیتر، 2009، 2008. - 668 ص.

E. Tanenbaum. سیستم های عامل. توسعه و اجرا. سن پترزبورگ: پیتر، 2006. - 568 ص.

پوپکوف K.A. تسلط بر سیستم عامل یونیکس / K.A. Pupkov، A.S. Chernikov، N.M. Yakusheva. - مسکو: رادیو و ارتباطات، 1994. - 112 ص.

L. Beck Introduction to System Programming - M.: Mir, 1988.

Grekul V.I.، Denishchenko G.N.، Korovkina N.L. طراحی سیستم های اطلاعاتی / مسکو: بینوم، 2008. - 304 ص.

لیپاف، V.V. مهندسی نرم افزار. مبانی روش شناختی [متن]: Proc. / V. V. Lipaev; دولت. un-t - مدرسه عالی اقتصاد. - M.: TEIS، 2006. - 608 p.

Lavrishcheva E. M.، Petrukhin V. A. روشها و ابزارهای مهندسی نرم افزار. - کتاب درسی

ایان سامرویل مهندسی نرم افزار، ویرایش ششم.: Per. از انگلیسی. - م. : انتشارات ویلیامز، 2002.-624 ص.

Excel 2010: برنامه نویسی حرفه ای در VBA.: Per. از انگلیسی. - M.: LLC "I.D. ویلیامز، 2012. - 944 ص. : بیمار - پارال دختر انگلیسی

فاولر ام. Refactoring: بهبود کد موجود. از انگلیسی. - سنت پترزبورگ: نماد پلاس، 2003. - 432 ص.

منابع اضافی:

Volkov V.A. دستورالعمل های روش شناختی برای اجرای کار عملی در رشته "برنامه نویسی سیستم"، دونتسک: DONPEK، 2015.

Volkov V.A. رهنمودهابه اجرای پروژه دوره، دونتسک: DONPEC، 2015.

اینترنت- منابع:

برنامه نویسی سیستم [منبع الکترونیکی] / حالت دسترسی: http://www.umk3.utmn.ru.

نرم افزار و منابع اینترنتی: http://www.intuit.ru

ادبیات بر اساس رشته - http://www.internet-technologies.ru/books/

کتاب درسی الکترونیک "مقدمه ای بر مهندسی نرم افزار" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

کتاب درسی الکترونیک "تکنولوژی برنامه نویسی" - http://bourabai.kz/alg/pro.htm

4.5 الزامات رهبران عملی از یک موسسه و سازمان آموزشی

الزامات برای رهبران عملی از یک موسسه آموزشی:

کادر مهندسی و آموزشی: فارغ التحصیلان - مدرسان دوره های بین رشته ای و رشته های حرفه ای عمومی. سابقه کار در سازمان های مرتبط با رشته تخصصی الزامی است.

کارشناسی ارشد آموزش صنعتی: در دسترس بودن رده صلاحیت 5-6 با کارآموزی اجباری در سازمان های تخصصی حداقل هر 3 سال یک بار. سابقه کار در سازمان های مرتبط با رشته تخصصی الزامی است.

5 پایش و ارزیابی نتایج

تمرین آموزشی بالا. 01

فرم گزارش در مورد تمرین آموزشی UP.01 - گزارشی در مورد تمرین که مطابق با الزامات توصیه های روش شناختی تهیه شده است.

نتایج (تسلط بر شایستگی های حرفه ای)	ویژگی های اصلی نتیجه آماده سازی	فرم ها و روش ها کنترل
PC 1.1. توسعه مشخصات برای اجزای جداگانه را انجام دهید	توسعه یک الگوریتم برای کار و اجرای آن با استفاده از طراحی به کمک کامپیوتر	مشاهده و ارزیابی کارشناسانه از فعالیت های دانش آموز در فرآیند تسلط برنامه آموزشیدر کلاس های عملی، هنگام انجام کار روی تمرین آموزشی و صنعتی.
PC 1.2. توسعه کد محصول نرم افزار را بر اساس مشخصات آماده در سطح ماژول انجام دهید.	اصول اولیه فناوری برنامه نویسی ساختاری و شی گرا را بدانید. برای انجام توسعه کد ماژول برنامه در زبان های برنامه نویسی مدرن.
PC 1.3. اشکال زدایی ماژول های برنامه را با استفاده از ابزارهای نرم افزاری تخصصی انجام دهید	اشکال زدایی و تست برنامه را در سطح ماژول انجام دهید.
PC 1.4. انجام تست ماژول های نرم افزار.	برنامه ای را طبق الگوریتم توسعه یافته به عنوان یک ماژول جداگانه ایجاد کنید.
PC 1.5. بهینه سازی کد ماژول را انجام دهید	توسعه یک کد محصول نرم افزاری بر اساس مشخصات نهایی در سطح ماژول.
PC 1.6. طراحی و اجزای مستندات فنی را با استفاده از زبان های مشخصات گرافیکی توسعه دهید	روش ها و ابزارهای توسعه اسناد فنی را بشناسید. مستندات نرم افزاری را آماده کنید. از ابزارهایی برای خودکارسازی اسناد استفاده کنید.

فرم‌ها و روش‌های نظارت و ارزیابی نتایج یادگیری باید به دانش‌آموزان اجازه دهد که نه تنها شکل‌گیری شایستگی‌های حرفه‌ای، بلکه رشد شایستگی‌های عمومی و مهارت‌هایی را که آن‌ها را فراهم می‌کند، بررسی کنند.

نتایج (تسلط بر صلاحیت های عمومی)	شاخص های اصلی برای ارزیابی نتیجه	اشکال و روشهای کنترل و ارزیابی
OK 1. جوهر و اهمیت اجتماعی حرفه آینده خود را درک کنید، به آن علاقه ثابت نشان دهید.	نشان دادن علاقه مداوم به حرفه آینده؛ - اعتبار استفاده از صلاحیت های حرفه ای تسلط یافته؛	مشاهده و ارزیابی تخصصی در کلاس های عملی هنگام انجام کار در عمل صنعتی.
OK 2. سازماندهی فعالیت های خود، تعیین روش ها و راه های انجام وظایف حرفه ای، ارزیابی اثربخشی و کیفیت آنها.	توجیه هدف گذاری، انتخاب و بکارگیری روش ها و روش های حل مشکلات حرفه ای. انجام خود تحلیلی و تصحیح نتایج کار خود	ارزشیابی در کلاسهای عملی در انجام کار. مشاهده در حین تمرین؛ درون نگری
OK 3. حل مشکلات، ارزیابی خطرات و تصمیم گیری در موقعیت های غیر استاندارد.	اثربخشی تصمیم گیری وظایف حرفه ای استاندارد و غیر استاندارد در زمان معین. اثربخشی طرح برای بهینه سازی کیفیت کار انجام شده	تفسیر نتایج نظارت بر فعالیت های دانش آموز در فرآیند تکمیل وظایف
OK 4. جستجو، تجزیه و تحلیل و ارزیابی اطلاعات لازم برای تنظیم و حل مشکلات حرفه ای، توسعه حرفه ای و شخصی.	انتخاب و تجزیه و تحلیل اطلاعات لازم برای اجرای واضح و سریع وظایف حرفه ای، توسعه حرفه ای و شخصی	ارزیابی تخصصی در جریان کار؛ خودکنترلی در جریان طرح و حل مشکلات
OK 5. استفاده از فناوری اطلاعات و ارتباطات برای بهبود فعالیت های حرفه ای.	توانایی استفاده از فناوری اطلاعات و ارتباطات برای حل مشکلات حرفه ای	ارزیابی تکالیف
خوب 6. در یک تیم و تیم کار کنید، انسجام آن را تضمین کنید، با همکاران، مدیریت، مصرف کنندگان ارتباط موثر برقرار کنید.	توانایی تعامل با گروه، معلمان، کارشناسی ارشد آموزش صنعتی
OK 7. تعیین اهداف، ایجاد انگیزه در فعالیت های زیردستان، سازماندهی و کنترل کار آنها با به عهده گرفتن مسئولیت برای نتیجه وظایف.	- خود تحلیلی و تصحیح نتایج کار خود و کار تیم	مشاهده پیشرفت کار در گروه در فرآیند عمل تولید
OK 8. به طور مستقل وظایف توسعه حرفه ای و شخصی را تعیین کنید، در آموزش خود شرکت کنید، آگاهانه آموزش های پیشرفته را برنامه ریزی کنید.	سازماندهی کار مستقل برای تشکیل یک تصویر خلاقانه و حرفه ای؛ سازماندهی کار در زمینه خودآموزی و بهبود صلاحیت های	مشاهده و ارزیابی در فرآیند عمل صنعتی؛ تجزیه و تحلیل بازتابی (الگوریتم اقدامات دانش آموز)؛ دفتر خاطرات تمرینی؛ تجزیه و تحلیل نمونه کارها دانش آموزان
OK 9. برای تغییر فن آوری در فعالیت های حرفه ای آماده باشید.	تجزیه و تحلیل نوآوری ها در زمینه فرآیندهای فناوری برای توسعه و ساخت پوشاک	ارزیابی راه حل های مشکلات موقعیتی؛ بازی های تجاری و سازمانی - آموزشی; مشاهده و ارزشیابی در کلاس های عملی، در فرآیند تولید

جی. هیوز، جی. میشتوم. رویکرد ساختاری به برنامه نویسی - م.: میر، 1980. - ص. 29-71.

وی. تورسکی. متدولوژی برنامه نویسی - م.: میر، 1360. - ص 90-164.

E.A. ژوگولف. مبانی فناوری برنامه نویسی مدولار // برنامه نویسی، 1980، شماره 2. - ص 44-49.

آر سی هولت ساختار برنامه های کامپیوتری: یک بررسی // مجموعه مقالات IEEE، 1975، 63(6). - پ. 879-893.

جی. مایرز. قابلیت اطمینان نرم افزار - م.: میر، 1980. - ص. 92-113.

آی پیل. ADA یک زبان سیستم های تعبیه شده است. م.: امور مالی و آمار، 1984. - ص. 67-75.

M. Zelkovets، A. Shaw، J. Gannon. اصول توسعه نرم افزار. - م.: میر، 1361، ص. 65-71.

A.L. Fuksman. جنبه های تکنولوژیکی ایجاد سیستم های نرم افزاری. م.: آمار، 1979. - ص. 79-94.

2. سخنرانی 8. توسعه یک ماژول نرم افزار

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

5. 8.1. روش توسعه یک ماژول نرم افزاری

6. هنگام توسعه یک ماژول نرم افزاری، توصیه می شود از ترتیب زیر پیروی کنید:

   مطالعه و تأیید مشخصات ماژول، انتخاب زبان

   برنامه نويسي؛

   انتخاب الگوریتم و ساختار داده؛

   برنامه نویسی ماژول؛

   صیقل دادن متن ماژول؛

   بررسی ماژول؛

   تدوین ماژول

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

   در مرحله دوم توسعه یک ماژول نرم‌افزاری، لازم است بفهمیم که آیا الگوریتم‌هایی از قبل برای حل مشکل مطرح شده یا نزدیک به آن شناخته شده‌اند یا خیر. و اگر الگوریتم مناسبی وجود دارد، بهتر است از آن استفاده کنید. انتخاب ساختارهای داده مناسبی که در زمانی که ماژول وظایف خود را انجام می دهد، تا حد زیادی منطق و شاخص های کیفیت ماژول در حال توسعه را تعیین می کند، بنابراین باید تصمیم بسیار مهمی در نظر گرفته شود.

   در مرحله سوم، متن ماژول به زبان برنامه نویسی انتخاب شده ساخته می شود. فراوانی انواع جزئیاتی که باید هنگام اجرای توابع مشخص شده در مشخصات ماژول در نظر گرفته شود، می تواند به راحتی منجر به ایجاد یک متن بسیار گیج کننده حاوی خطاها و نادرستی های زیادی شود. یافتن خطاها در چنین ماژولی و ایجاد تغییرات مورد نیاز در آن می تواند کاری بسیار زمان بر باشد. بنابراین، استفاده از یک رشته برنامه نویسی توجیه شده و عملاً اثبات شده برای ساخت متن ماژول بسیار مهم است. برای اولین بار، Dijkstra توجه خود را به این موضوع جلب کرد و اصول اولیه برنامه نویسی ساخت یافته را تدوین و اثبات کرد. بسیاری از رشته های برنامه نویسی که به طور گسترده در عمل مورد استفاده قرار می گیرند بر اساس این اصول هستند. متداول ترین آن، رشته تمرینی است که در بخش های 8.2 و 8.3 به تفصیل مورد بحث قرار گرفته است.

   مرحله بعدی در توسعه ماژول مربوط به رساندن متن ماژول به فرم نهایی مطابق با مشخصات کیفیت PS است. هنگام برنامه نویسی یک ماژول، توسعه دهنده بر اجرای صحیح عملکردهای ماژول تمرکز می کند، نظرات را ناتمام می گذارد و اجازه می دهد برخی از موارد مورد نیاز برای سبک برنامه را نقض کند. هنگام صیقل دادن متن یک ماژول، او باید نظرات را در متن ویرایش کند و احتمالاً نظرات اضافی را برای ارائه کیفیت اولیه مورد نیاز درج کند. برای همین منظور، متن برنامه برای برآوردن نیازهای سبکی ویرایش می شود.

   مرحله تأیید ماژول، بررسی دستی منطق داخلی ماژول قبل از اشکال زدایی (با استفاده از اجرای آن بر روی رایانه) است. اصل کلی، برای فناوری برنامه نویسی مورد بحث، در مورد نیاز به کنترل تصمیمات اتخاذ شده در هر مرحله از توسعه PS فرموله شده است (به سخنرانی 3 مراجعه کنید). روشهای اعتبارسنجی ماژول در بخش 8.4 مورد بحث قرار گرفته است.

   در نهایت، آخرین مرحله از توسعه یک ماژول به معنای تکمیل اعتبارسنجی ماژول (با استفاده از کامپایلر) و حرکت به سمت فرآیند اشکال زدایی ماژول است.

8. 8.2. برنامه ریزی ساختاری

9. هنگام برنامه نویسی یک ماژول، باید در نظر داشت که این برنامه نه تنها برای یک کامپیوتر، بلکه برای یک شخص نیز باید قابل درک باشد: هم توسعه دهنده ماژول و هم افرادی که ماژول را بررسی می کنند و هم نویسندگان متن که تست هایی را برای اشکال زدایی آماده می کنند. ماژول، و نگهدارنده‌های PS که تغییرات لازم را در ماژول ایجاد می‌کنند، باید به طور مکرر منطق ماژول را تجزیه کنند. در زبان های برنامه نویسی مدرن، ابزارهای کافی برای اشتباه گرفتن این منطق وجود دارد، در نتیجه درک ماژول برای شخص دشوار می شود و در نتیجه نگهداری آن غیر قابل اعتماد یا دشوار می شود. بنابراین باید در انتخاب ابزارهای زبانی مناسب و پیروی از یک رشته برنامه نویسی دقت کرد. برای اولین بار، Dijkstra توجه را به این امر جلب کرد و پیشنهاد ساخت برنامه ای را به عنوان ترکیبی از چندین نوع ساختار کنترلی (ساختارها) داد که می تواند درک منطق برنامه را تا حد زیادی افزایش دهد. برنامه نویسی با استفاده از چنین ساختارهایی را برنامه ریزی ساختاری می نامیدند.

   ساختارهای اصلی برنامه نویسی ساخت یافته عبارتند از: دنبال کردن، شاخه و تکرار (شکل 8.1 را ببینید). اجزای این ساختارها عملگرهای تعمیم‌یافته (گره‌های پردازش) S، S1، S2 و یک شرط (گزاره) P هستند. فراخوانی ها)، یا یک قطعه برنامه، که ترکیبی از ساختارهای کنترل اصلی برنامه نویسی ساخت یافته است. ضروری است که هر یک از این ساختارها از نظر کنترل فقط یک ورودی و یک خروجی داشته باشند. بنابراین عملگر تعمیم یافته نیز تنها یک ورودی و یک خروجی دارد.

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

   برنامه نویسی ساختاریافته گاهی اوقات به عنوان "برنامه نویسی بدون GO TO" شناخته می شود. با این حال، نکته در اینجا عبارت GO TO نیست، بلکه استفاده بی رویه از آن است. اغلب، هنگام اجرای برنامه نویسی ساخت یافته در برخی از زبان های برنامه نویسی (به عنوان مثال، در FORTRAN)، عملگر انتقال (GO TO) برای پیاده سازی ساختارهای ساختاری بدون کاهش مزایای اصلی برنامه نویسی ساخت یافته استفاده می شود. این دستورات پرش "غیر ساختاری" هستند که برنامه را گیج می کنند، به خصوص پرش به دستوری که در متن ماژول بالای (قبلتر) دستور پرش در حال اجرا قرار دارد. با این حال، تلاش برای جلوگیری از بیانیه پرش در برخی موارد سادهمی تواند منجر به برنامه های ساختاری شود که بیش از حد دست و پا گیر هستند، که وضوح آنها را بهبود نمی بخشد و خطر ایجاد خطاهای اضافی در متن ماژول را در بر می گیرد. بنابراین، ممکن است توصیه شود تا جایی که امکان دارد از استفاده از دستور jump اجتناب کنید، اما نه به قیمت وضوح برنامه.

   موارد مفید استفاده از عملگر انتقال شامل خروج از یک حلقه یا رویه در یک شرایط خاص است که "اوایل" کار این حلقه یا این رویه را خاتمه می دهد، یعنی. پایان دادن به کار برخی از واحدهای ساختاری (اپراتور تعمیم یافته) و در نتیجه تنها به صورت محلی ساختار برنامه را نقض می کند. مشکلات بزرگ (و پیچیدگی سازه) ناشی از اجرای سازه ای پاسخ به موقعیت های استثنایی (اغلب اشتباه) است، زیرا این امر نه تنها نیاز به خروج زودهنگام از واحد سازه، بلکه نیاز به پردازش (استخراج) لازم از این وضعیت دارد. (مثلاً صدور اطلاعات تشخیصی مناسب). کنترل کننده استثنا را می توان در هر سطحی از ساختار برنامه قرار داد و از سطوح مختلف پایین تر قابل دسترسی است. از دیدگاه تکنولوژیکی، اجرای «غیر ساختاری» زیر پاسخ به موقعیت‌های استثنایی کاملاً قابل قبول است. کنترل کننده های استثنایی در انتهای یک یا آن واحد ساختاری قرار می گیرند و هر یک از این دسته ها به گونه ای برنامه ریزی می شود که پس از اتمام کار خود از واحد سازه ای که در انتهای آن قرار گرفته است خارج شود. چنین کنترل کننده ای توسط عملگر پرش از واحد ساختاری داده شده (شامل هر واحد ساختاری تودرتو) فراخوانی می شود.

11. 8.3. جزئیات گام به گام و مفهوم شبه کد.

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

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

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

    توضیحات سر در شبه کد را می توان طراحی خارجی ماژول در زبان برنامه نویسی پایه دانست که

    ابتدای ماژول در زبان پایه، یعنی. اولین جمله یا عنوان (مشخصات) این ماژول؛

    یک بخش (مجموعه) از توضیحات در زبان پایه و به جای توصیف رویه ها و عملکردها - فقط طراحی خارجی آنها.

    تعیین غیررسمی توالی عبارات بدنه ماژول به عنوان یک عبارت تعمیم یافته (به زیر مراجعه کنید)، و همچنین تعیین غیررسمی دنباله گزاره های بدنه هر رویه یا توصیف تابع به عنوان یک عبارت تعمیم یافته.

    آخرین جمله (پایان) ماژول در زبان پایه.

    طراحی خارجی شرح یک رویه یا عملکرد به روشی مشابه ارائه شده است. با این حال، با پیروی از Dijkstra، بهتر است بخش توضیحات در اینجا نیز با یک نماد غیررسمی ارائه شود و آن را به عنوان یک توضیح جداگانه شرح دهیم.

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

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

13. برنج. 8.2. ساختارهای اساسی برنامه نویسی ساخت یافته در شبه کد.

14. برنج. 8.3. موارد خاص عملگر انتقال به عنوان یک عملگر تعمیم یافته.

    به عنوان یک عملگر تعمیم یافته در شبه کد، می توانید از موارد خاص عملگر انتقال استفاده کنید (شکل 8.3 را ببینید). توالی کنترل کننده های استثنا (استثناها) در انتهای یک توضیح ماژول یا رویه (عملکرد) مشخص می شود. هر یک از این کنترلرها به نظر می رسد:

    EXCEPTION استثنا_نام

    generic_operator

    همه استثنا

    تفاوت بین یک کنترل کننده استثنا و یک رویه بدون پارامتر به شرح زیر است: پس از اجرای رویه، کنترل به دستور پس از فراخوانی آن برمی گردد و پس از اجرای استثنا، کنترل به دستور پس از فراخوانی ماژول برمی گردد. یا رویه (تابع) که در انتهای آن (که) این استثنا قرار می گیرد.

    توصیه می شود در هر مرحله از جزئیات، یک توصیف به اندازه کافی معنادار، اما به راحتی قابل مشاهده (بصری) ایجاد کنید، به طوری که در یک صفحه از متن قرار گیرد. به عنوان یک قاعده، این بدان معنی است که چنین توصیفی باید ترکیبی از پنج یا شش ساختار برنامه نویسی ساخت یافته باشد. همچنین توصیه می شود سازه های تو در تو را با چند موقعیت به سمت راست قرار دهید (شکل 8.4 را ببینید). در نتیجه، می توانید شرحی از منطق کار از نظر دید به دست آورید که کاملاً با نمودارهای جریان رقابتی است، اما دارای یک مزیت قابل توجه است - خطی بودن توضیحات حفظ می شود.

15. حذف در رکوردهای فایل قبل از اول، مناسب برای فیلتر مجموعه: شروع فایل را تنظیم کنید. اگر رکورد دیگری راضی باشد فیلتر کردن به یک رکورد دیگر را از فایل حذف کنید. همه اگر خدا حافظ اگر ورودی حذف نشد پس "سوابق حذف نشده" را تایپ کنید. چاپ "REMOVED n Records". همه اگر

برنج. 8.4. نمونه ای از یک مرحله از جزئیات در شبه کد.

16. ایده جزئیات گام به گام گاهی به Dijkstra نسبت داده می شود. با این حال، Dijkstra روشی اساساً متفاوت برای ساخت متن ماژول پیشنهاد کرد که به نظر ما عمیق‌تر و امیدوارکننده‌تر است. ابتدا، همراه با اصلاح اپراتورها، او پیشنهاد کرد که به تدریج (گام به گام) ساختارهای داده مورد استفاده را اصلاح شود (جزئیات). ثانیاً، در هر مرحله، او ایجاد یک ماشین مجازی خاص را برای جزئیات و به عبارتی جزئیات تمام مفاهیم پالایش شده ای که این ماشین اجازه انجام این کار را برای آنها می دهد، پیشنهاد کرد. بنابراین، Dijkstra در اصل، جزئیات را با لایه های افقی پیشنهاد کرد، که انتقال ایده او از سیستم های لایه ای (به سخنرانی 6) به سطح توسعه ماژول است. این روش توسعه ماژول در حال حاضر توسط بسته های زبان ADA و ابزارهای برنامه نویسی شی گرا پشتیبانی می شود.

18. 8.4. کنترل ماژول نرم افزار.

19. درخواست دادن روش های زیرکنترل ماژول برنامه:

    بررسی استاتیک متن ماژول.

    ردیابی پایان به انتها؛

    اثبات خواص ماژول نرم افزار.

    در حین بررسی استاتیک متن یک ماژول، این متن از ابتدا تا انتها خوانده می شود تا خطاهای موجود در ماژول را پیدا کند. معمولاً علاوه بر توسعه دهنده ماژول، یک برنامه نویس بیشتر یا حتی چند برنامه نویس برای چنین بررسی درگیر هستند. توصیه می شود که خطاهای شناسایی شده در طول چنین بررسی نه بلافاصله، بلکه پس از اتمام خواندن متن ماژول اصلاح شوند.

    ردیابی End-to-End یکی از انواع کنترل پویا ماژول است. همچنین شامل چندین برنامه نویس است که به صورت دستی از طریق اجرای ماژول (گزاره به عبارت در دنباله ای که از منطق ماژول پیروی می کند) روی مجموعه خاصی از تست ها حلقه می زنند.

    سخنرانی بعدی به اثبات خواص برنامه ها اختصاص دارد. در اینجا فقط باید توجه داشت که این روش هنوز بسیار نادر مورد استفاده قرار می گیرد.

21. ادبیات برای سخنرانی 8.

22. 8.2. E. Dijkstra. یادداشت هایی در مورد برنامه ریزی ساختاریافته// W. Dahl, E. Dijkstra, K. Hoor. برنامه ریزی ساختاری - م.: میر، 1975. - س 24-97.

    8.3. N. Wirth. برنامه نویسی سیستماتیک - م.: میر، 1977. - س 94-164.

24. سخنرانی 9

25. مفهوم توجیه برنامه. رسمی سازی ویژگی های برنامه، سه گانه هور. قوانینی برای تنظیم خصوصیات یک عملگر انتساب، عملگر شرطی و عملگر مرکب. قوانینی برای ایجاد ویژگی های یک عملگر حلقه، مفهوم یک حلقه ثابت. خاتمه اجرای برنامه

27. 9.1. توجیهات برنامه رسمی کردن ویژگی های برنامه

28. برای بهبود قابلیت اطمینان نرم افزار، تهیه برنامه هایی با اطلاعات اضافی بسیار مفید است که با استفاده از آنها می توانید سطح کنترل نرم افزار را به میزان قابل توجهی افزایش دهید. چنین اطلاعاتی را می توان در قالب اظهارات غیررسمی یا رسمی که به بخش های مختلف برنامه گره خورده است ارائه کرد. ما چنین ادعاهایی را توجیه برنامه می نامیم. به عنوان مثال، توجیه غیر رسمی برنامه ها می تواند انگیزه های اتخاذ تصمیمات خاص را توضیح دهد که می تواند جستجو و تصحیح خطاها و همچنین مطالعه برنامه ها در طول نگهداری آنها را بسیار تسهیل کند. توجیهات رسمی این امکان را فراهم می کند که برخی از خصوصیات برنامه ها را هم به صورت دستی و هم کنترل (تنظیم) آن ها را به صورت خودکار اثبات کند.

    یکی از مفاهیمی که در حال حاضر از توجیهات رسمی برای برنامه ها استفاده می شود، استفاده از سه گانه های هور است. اجازه دهید S یک عملگر تعمیم یافته در محیط اطلاعات IS، P و Q باشد - برخی از محمولات (گزاره ها) روی این محیط. سپس نماد (P)S(Q) سه گانه Hoor نامیده می شود که در آن گزاره P را پیش شرط می نامند و محمول Q را با توجه به عملگر S شرط پسین می نامند. عملگر (به ویژه برنامه) گفته می شود که S دارای خاصیت (P)S(Q) است، اگر هر زمان که گزاره P قبل از اجرای S درست باشد، گزاره Q بعد از اجرای S صادق است.

    مثال های ساده از ویژگی های برنامه:

    (9.1) (n=0) n:=n+1 (n=1)،

    (9.2) (n

    (9.3) (n

    (9.4) (n>0) p:=1; m:=1;

    WHILE m /= n انجام دهید

29. خدا حافظ

    برای اثبات ویژگی برنامه S، از ویژگی های عملگرهای ساده زبان برنامه نویسی (در اینجا خود را به عملگر خالی و عملگر انتساب محدود می کنیم) و ویژگی های ساختارهای کنترلی (ترکیبات) که برنامه با آنها ساخته شده است، استفاده می کنیم. عملگرهای ساده (ما در اینجا خود را به سه ترکیب اصلی برنامه نویسی ساخت یافته محدود می کنیم، به سخنرانی هشتم مراجعه کنید). این ویژگی ها معمولاً قوانین تأیید برنامه نامیده می شوند.

31. 9.2. ویژگی های عملگرهای ساده

32. برای یک اپراتور خالی،

    قضیه 9.1. فرض کنید P یک محمول در محیط اطلاعات باشد. سپس خاصیت (P)(P) برقرار است.

    اثبات این قضیه بدیهی است: عملگر خالی وضعیت محیط اطلاعات را تغییر نمی‌دهد (مطابق با معنایی آن)، بنابراین پیش‌شرط آن پس از اجرای آن صادق باقی می‌ماند.

    برای اپراتور تخصیص،

    قضیه 9.2. اجازه دهید محیط اطلاعاتی IS از متغیر X و بقیه محیط اطلاعاتی RIS تشکیل شده باشد:

33. سپس ملک

    (Q(F(X، RIS)، RIS)) X:= F(X، RIS) (Q(X، RIS)) ,

    در جایی که F(X، RIS) تابع تک مقداری است، Q یک محمول است.

    اثبات اجازه دهید گزاره Q(F(X0، RIS0)، RIS0) قبل از اجرای عملگر تخصیص درست باشد، که در آن (X0، RIS0) حالت دلخواه محیط اطلاعاتی IS است، سپس پس از اجرای عملگر انتساب، محمول است. Q(X, RIS) درست خواهد بود، بنابراین اینکه X چگونه مقدار F(X0, RIS0) و وضعیت RIS را بدست می‌آورد با دستور انتساب داده شده تغییر نمی‌کند و از این رو پس از اجرای این دستور انتساب در این مورد

    Q(X، RIS)=Q(F(X0، RIS0)، RIS0).

    با توجه به خودسری بودن انتخاب وضعیت محیط اطلاعاتی، قضیه ثابت می شود.

    نمونه ای از ویژگی یک عملگر انتساب، مثال 9.1 است.

35. 9.3. ویژگی های ساختارهای اساسی برنامه ریزی ساختاری.

36. اکنون ویژگی های ساختارهای اصلی برنامه نویسی ساخت یافته را در نظر بگیرید: دنبال کردن، انشعاب و تکرار.

    خواص جانشینی به صورت زیر بیان می شود

    قضیه 9.3. اجازه دهید P، Q و R در محیط اطلاعات محمول باشند، و S1 و S2 عملگرهای تعمیم یافته باشند که به ترتیب دارای خصوصیات هستند.

    (P)S(Q) و (Q)S2(R).

    سپس برای عملگر مرکب

    S1; S2<.blockquote>

    یک ملک وجود دارد

    (P) S1; S2 (R).

    اثبات اجازه دهید گزاره P برای برخی از وضعیت های محیط اطلاعاتی قبل از اجرای عملگر S1 صادق باشد سپس به موجب ویژگی عملگر S1، پس از اجرای آن، با اجرای عملگر S2، گزاره Q صادق خواهد بود. در نتیجه، پس از اجرای عملگر S2، به موجب خاصیت آن، گزاره R درست خواهد بود و از آنجایی که عملگر S2 اجرای دستور مرکب را (مطابق با معنایی آن) کامل می کند، گزاره R پس از آن صادق خواهد بود. اجرای این عبارت مرکب که نیاز به اثبات داشت.

    به عنوان مثال، اگر خواص (9.2) و (9.3) باقی بماند، پس

    مکان و ملک

    (ن

    خاصیت انشعاب به صورت زیر بیان می شود

    قضیه 9.4. اجازه دهید P، Q و R در محیط اطلاعات محمول باشند، و S1 و S2 عملگرهای تعمیم یافته باشند که به ترتیب دارای خصوصیات هستند.

    (P,Q)S1(R) و (`P,Q)S2(R).

    سپس برای عملگر شرطی

    IF P S1 ELSE S2 ALL IF

    یک ملک وجود دارد

    (Q) اگر P سپس S1 ELSE S2 ALL IF (R) .

    اثبات اجازه دهید گزاره Q برای برخی از وضعیت های محیط اطلاعاتی قبل از اجرای عملگر شرطی صادق باشد.اگر گزاره P نیز صادق باشد، اجرای عملگر شرطی مطابق با معنایی آن به اجرای عملگر S1 تقلیل می یابد. . به موجب خاصیت عملگر S1، پس از اجرای آن (و در این مورد، پس از اجرای عملگر شرطی)، محمول R صادق خواهد بود. اما اگر قبل از اجرای عملگر شرطی، محمول P نادرست است (و Q هنوز درست است)، سپس اجرای عملگر شرطی مطابق با معنایی آن به اجرای عملگر S2 کاهش می یابد. با توجه به خاصیت عملگر S2، پس از اجرای آن (و در این مورد، پس از اجرای عملگر شرطی) محمول R صادق خواهد بود.بنابراین قضیه کاملاً ثابت می شود.

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

    قضیه 9.5. اجازه دهید P، Q، P1 و Q1 محمولاتی بر محیط اطلاعاتی باشند که پیامدها برای آن وجود دارد

    P1=>P و Q=>Q1،

    و اجازه دهید ویژگی (P)S(Q) برای عملگر S باشد. سپس خاصیت (P1)S(Q1) برقرار است.

    به این قضیه، قضیه ویژگی تضعیف کننده نیز گفته می شود.

    اثبات اجازه دهید گزاره P1 برای برخی از وضعیت های محیط اطلاعاتی قبل از اجرای عملگر S صادق باشد. سپس محمول P نیز صادق خواهد بود (به دلیل مفهوم P1=>P). در نتیجه، به موجب ویژگی عملگر S، پس از اجرای آن، گزاره Q صادق خواهد بود، و از این رو محمول Q1 (به موجب مفهوم Q=>Q1) صادق خواهد بود. بنابراین قضیه ثابت می شود.

    خاصیت تکرار به صورت زیر بیان می شود

    قضیه 9.6. اجازه دهید I، P، Q و R محمولاتی در محیط اطلاعاتی باشند که پیامدها برای آن وجود دارد

    P=>I و (I,`Q)=>R ,

    و اجازه دهید S یک عملگر تعمیم یافته با ویژگی (I)S(I) باشد.

    سپس برای عملگر حلقه

    خداحافظ Q DO S ALL BYE

    یک ملک وجود دارد

    (P) خداحافظ Q همه چیز خداحافظ (R) .

    محمول I را ثابت عملگر حلقه می نامند.

    اثبات برای اثبات این قضیه به اثبات خاصیت بسنده می شود

    (I) خداحافظ Q همه چیز خداحافظ (I,`Q)

    (توسط قضیه 9.5 بر اساس استلزامات موجود در شرایط این قضیه). اجازه دهید گزاره I برای برخی از وضعیت های محیط اطلاعاتی قبل از اجرای عملگر چرخه درست باشد. اگر در این مورد، گزاره Q نادرست باشد، عملگر چرخه معادل یک عملگر خالی خواهد بود (مطابق با معنایی آن) و به موجب قضیه 9.1، پس از اجرای عملگر چرخه، عبارت (I ,`Q). اگر گزاره Q قبل از اجرای عملگر حلقه درست باشد، عملگر حلقه، مطابق با معنایی آن، می تواند به عنوان یک عملگر مرکب S نمایش داده شود. خداحافظ Q DO S ALL BYE

    به موجب خاصیت عملگر S، پس از اجرای آن، گزاره I صادق خواهد بود و وضعیت اولیه برای اثبات خاصیت عملگر چرخه ایجاد می شود: محمول I قبل از اجرای عملگر چرخه صادق است، اما برای وضعیت متفاوت (تغییر شده) محیط اطلاعاتی (که برای آن محمول Q می تواند درست یا نادرست باشد). اگر اجرای دستور حلقه به پایان برسد، با اعمال روش استقراء ریاضی، در تعداد محدودی از مراحل، به وضعیتی می رسیم که گزاره (I,`Q) قبل از اجرای آن صادق خواهد بود. و در این صورت، همانطور که در بالا ثابت شد، این عبارت حتی پس از اجرای دستور چرخه نیز صادق خواهد بود. قضیه ثابت شده است.

    به عنوان مثال، برای عملگر حلقه از مثال (9.4)، ویژگی انجام می شود

    m:= m+1; p:= p*m

    همه هنوز (p= n.!}

    این از قضیه 9.6 به دست می آید، زیرا ثابت این عملگر حلقه، محمول p=m است! و مفاهیم (n>0، p=1، m=1) => p=m! و (p=m!، m=n) => p=n!

38. 9.4. خاتمه اجرای برنامه

39. یکی از ویژگی های برنامه که ممکن است برای جلوگیری از خطاهای احتمالی در PS به آن علاقه مند باشیم، خاتمه آن است، i.e. عدم وجود دوچرخه سواری در آن برای داده های اولیه خاص. در برنامه های ساختاری که در نظر گرفته ایم، تنها ساختار تکرار می تواند منبع حلقه زدن باشد. بنابراین، برای اثبات خاتمه یک برنامه، کافی است که بتوانیم خاتمه یک عملگر حلقه را اثبات کنیم. موارد زیر برای این کار مفید است.

    قضیه 9.7. فرض کنید F یک تابع عدد صحیح است که به وضعیت محیط اطلاعاتی بستگی دارد و شرایط زیر را برآورده می کند:

    (1) اگر گزاره Q برای وضعیت معینی از محیط اطلاعاتی صادق باشد، ارزش آن مثبت است.

    (2) هنگامی که وضعیت محیط اطلاعات در نتیجه اجرای اپراتور S تغییر می کند، کاهش می یابد.

    سپس دستور حلقه اجرا می شود

    در حالی که Q همه چیز را در حالی که کامل می شود انجام دهید.

    اثبات اجازه دهید حالت محیط اطلاعات قبل از اجرای دستور چرخه باشد و اجازه دهید F(is)=k باشد. اگر گزاره Q(is) نادرست باشد، اجرای دستور حلقه به پایان می رسد. اگر Q(is) درست باشد، با فرض قضیه k>0. در این حالت دستور S یک یا چند بار اجرا می شود. بعد از هر بار اجرای عملگر S با توجه به شرط قضیه مقدار تابع F کاهش می یابد و از آنجایی که قبل از اجرای عملگر S باید گزاره Q درست باشد (طبق معنایی عملگر چرخه) ، مقدار تابع F در این لحظه باید مثبت باشد (طبق شرط قضیه). بنابراین، به دلیل یکپارچگی تابع F، عملگر S در این چرخه می تواند بیش از k بار اجرا شود. قضیه ثابت شده است.

    برای مثال، برای مثال عملگر چرخه در نظر گرفته شده در بالا، شرایط قضیه 9.7 توسط تابع f(n, m)= n-m برآورده می شود. از آنجایی که قبل از اجرای دستور حلقه m=1، بدنه این حلقه بارها (n-1) اجرا می شود، یعنی. این دستور حلقه خاتمه می یابد.

41. 9.5. نمونه ای از اثبات ویژگی های برنامه.

42. بر اساس قوانین اثبات شده برای تأیید برنامه، می توان ویژگی های برنامه های متشکل از دستورهای انتساب و دستورات خالی و با استفاده از سه ترکیب اصلی برنامه نویسی ساخت یافته را اثبات کرد. برای انجام این کار، با تجزیه و تحلیل ساختار برنامه و استفاده از شرایط پیش و پس از آن، لازم است در هر مرحله از تجزیه و تحلیل، یک قانون تأیید مناسب اعمال شود. در مورد ترکیب تکراری، انتخاب یک چرخه ثابت مناسب ضروری خواهد بود.

    به عنوان مثال، اجازه دهید مالکیت را ثابت کنیم (9.4). این اثبات شامل مراحل زیر خواهد بود.

    (مرحله 1). n>0 => (n>0، p - هر، m - هر).

    (گام 2). رخ می دهد

    (n>0، p - هر، m - هر) p:=1 (n>0، p=1، m - هر).

    توسط قضیه 9.2.

    (مرحله 3). رخ می دهد

    (n>0، p=1، m - هر) m:=1 (n>0، p=1، m=1).

    توسط قضیه 9.2.

    (مرحله 4). رخ می دهد

    (n>0، p - هر، m - هر) p:=1; m:=1 (n>0، p=1، m=1).

    توسط قضیه 9.3، با توجه به نتایج مراحل 2 و 3.

    اجازه دهید ثابت کنیم که محمول p=m! یک چرخه ثابت است، یعنی. (p=m m:=m+1; p:=p*m {p=m!}.!}

    (مرحله 5). انجام می شود (p=m m:=m+1 {p=(m-1)!}.!}

    با قضیه 9.2، اگر پیش شرط را به شکل (p=((m+1)-1) نشان دهیم..!}

    (مرحله 6). انجام می شود (p=(m-1) p:=p*m {p=m!}.!}

    با قضیه 9.2، اگر پیش شرط را به شکل (p*m=m) نشان دهیم.!}

    (مرحله 7). یک چرخه ثابت وجود دارد

    (p=m m:=m+1; p:=p*m {p=m!}.!}

    توسط قضیه 9.3، با توجه به نتایج مراحل 5 و 6.

    (مرحله 8). رخ می دهد

    (n>0، p=1، m=1) WHILE m /= n انجام دهید

    m:= m+1; p:= p*m

    همه هنوز (p= n.!}

    با قضیه 9.6، به موجب نتیجه مرحله 7 و با در نظر گرفتن این نکته که (n>0، p=1، m= 1)=>p=m!; (p=m!، m=n)=>p=n!.

    (مرحله 9). رخ می دهد

    (n>0، p - هر، m - هر) p:=1; m:=1;

    WHILE m /= n انجام دهید

    m:= m+1; p:= p*m

    همه هنوز (p= n.!}

    توسط قضیه 9.3، با توجه به نتایج مراحل 3 و 8.

    (مرحله 10). خاصیت (9.4) با قضیه 9.5 به دلیل نتایج مراحل 1 و 9 حفظ می شود.

44. ادبیات برای سخنرانی 9.

45. 9.1. S.A. آبراموف عناصر برنامه نویسی - M.: Nauka، 1982. S. 85-94.

    9.2. M. Zelkovets، A. Shaw، J. Gannon. اصول توسعه نرم افزار. - م.: میر، 1982. س 98-105.

47. سخنرانی 10

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

50. 10.1. مفاهیم اساسی.

51. اشکال زدایی PS فعالیتی است با هدف شناسایی و تصحیح خطاها در PS با استفاده از فرآیندهای اجرای برنامه های آن. تست PS فرآیند اجرای برنامه های آن بر روی یک مجموعه داده خاص است که نتیجه برنامه از قبل مشخص است یا قوانین رفتار این برنامه ها مشخص است. مجموعه داده های مشخص شده را تست یا فقط تست می نامند. بنابراین، اشکال زدایی را می توان به عنوان تکرار مکرر سه فرآیند نشان داد: آزمایش، در نتیجه می توان وجود خطا در PS را مشخص کرد، جستجوی محل خطا در برنامه ها و مستندات PS، و ویرایش برنامه ها و اسناد به منظور حذف خطای شناسایی شده. به عبارت دیگر:

    اشکال زدایی = تست + یافتن خطاها + ویرایش.

    در ادبیات خارجی، اشکال زدایی اغلب تنها به عنوان فرآیندی برای یافتن و تصحیح خطاها (بدون آزمایش) درک می شود که وجود آن در طول آزمایش مشخص می شود. گاهی اوقات تست و اشکال زدایی مترادف در نظر گرفته می شوند. در کشور ما، مفهوم اشکال زدایی معمولاً شامل تست می شود، بنابراین ما از سنت جا افتاده پیروی خواهیم کرد. با این حال، در نظر گرفتن مشترک این فرآیندها در این سخنرانی باعث می شود که اختلاف نشان داده شده چندان قابل توجه نباشد. با این حال، باید توجه داشت که آزمایش نیز به عنوان بخشی از فرآیند صدور گواهینامه PS استفاده می شود (به سخنرانی 14 مراجعه کنید).

52. 10.2. اصول و انواع اشکال زدایی

53. موفقیت اشکال زدایی تا حد زیادی توسط سازماندهی منطقی آزمایش تعیین می شود. در حین اشکال زدایی، عمدتاً آن خطاهایی پیدا و حذف می شوند که وجود آنها در PS در هنگام آزمایش مشخص می شود. همانطور که قبلا ذکر شد، آزمایش نمی تواند صحت PS را ثابت کند، در بهترین حالت می تواند وجود یک خطا را در آن نشان دهد. به عبارت دیگر، نمی توان تضمین کرد که با آزمایش نرم افزار با مجموعه ای از آزمایشات عملی، امکان وجود هر خطای موجود در نرم افزار وجود دارد. بنابراین دو مشکل پیش می آید. ابتدا چنین مجموعه ای از تست ها را تهیه کنید و PS را روی آن ها اعمال کنید تا تا حد امکان خطا در آن شناسایی شود. با این حال، هر چه فرآیند تست (و به طور کلی اشکال زدایی) بیشتر ادامه یابد، هزینه نرم افزار بیشتر می شود. از این رو وظیفه دوم: تعیین لحظه ای که اشکال زدایی PS (یا اجزای جداگانه آن) تکمیل می شود. نشانه ای از احتمال پایان اشکال زدایی، پوشش کامل تست های انجام شده از طریق PS (یعنی تست هایی که PS برای آنها اعمال می شود) بسیاری از موقعیت های مختلف است که در طول اجرای برنامه های PS ایجاد می شود، و تظاهرات نسبتاً نادری از خطاها در PS در آخرین بخش از فرآیند تست. مورد دوم مطابق با درجه مورد نیاز از قابلیت اطمینان PS، مشخص شده در مشخصات کیفیت آن تعیین می شود.

    برای بهینه سازی مجموعه آزمایشی، به عنوان مثال برای تهیه چنین مجموعه ای از تست ها که به تعداد معینی از آنها (یا برای یک بازه زمانی معینی که برای آزمایش اختصاص داده شده است) اجازه می دهد تا تعداد بیشتری از خطاها را شناسایی کند، لازم است اولاً این مجموعه از قبل برنامه ریزی شود و ثانیاً ، برای استفاده از آزمون های استراتژی برنامه ریزی منطقی (طراحی). طراحی تست می تواند بلافاصله پس از اتمام مرحله توصیف خارجی PS شروع شود. رویکردهای متفاوتی برای توسعه یک استراتژی طراحی آزمایشی وجود دارد که می‌توان آن‌ها را به‌طور مشروط به صورت گرافیکی (نگاه کنید به شکل 9.1) بین دو رویکرد شدید زیر قرار داد. رویکرد افراطی چپ این است که تست ها فقط بر اساس مطالعه مشخصات PS (توضیحات خارجی، توضیحات معماری و مشخصات ماژول) طراحی می شوند. ساختار ماژول ها به هیچ وجه در نظر گرفته نمی شود، یعنی. آنها به عنوان جعبه سیاه در نظر گرفته می شوند. در واقع، این رویکرد مستلزم شمارش کامل تمام مجموعه‌های داده ورودی است، زیرا زمانی که تنها بخشی از این مجموعه‌ها به عنوان آزمایش استفاده می‌شود، برخی از بخش‌های برنامه‌های PS ممکن است روی هیچ تستی کار نکنند و بنابراین، خطاهای موجود در آنها نخواهند بود. به نظر می رسد. با این حال، آزمایش PS با مجموعه ای کامل از مجموعه داده های ورودی عملا غیرممکن است. رویکرد افراطی درست این است که تست‌ها بر اساس مطالعه متون برنامه طراحی می‌شوند تا تمام روش‌های اجرای هر برنامه PS را آزمایش کنند. اگر وجود چرخه هایی با تعداد تکرار متغیر در برنامه ها را در نظر بگیریم، ممکن است تعداد بسیار زیادی روش های مختلف برای اجرای برنامه های PS نیز وجود داشته باشد، به طوری که آزمایش آنها نیز عملا غیرممکن خواهد بود.

    استراتژی طراحی آزمون بهینه در فاصله بین این رویکردهای شدید، اما نزدیکتر به سمت چپ قرار دارد. این شامل طراحی بخش قابل توجهی از تست ها بر اساس مشخصات، بر اساس اصول است: برای هر تابع یا ویژگی مورد استفاده - حداقل یک تست، برای هر ناحیه و برای هر مرز تغییر هر مقدار ورودی - حداقل یک تست ، برای هر یک مورد خاصیا برای هر استثنای مشخص شده در مشخصات، حداقل یک تست. اما همچنین مستلزم طراحی برخی از تست ها و متون برنامه ها است، بر اساس این اصل (حداقل): هر دستور از هر برنامه PS باید حداقل روی یک تست کار کند.

    استراتژی طراحی آزمون بهینه را می توان بر اساس اصل زیر مشخص کرد: برای هر سند برنامه (از جمله متون برنامه) که بخشی از PS است، باید تست های خود را به منظور شناسایی خطاها در آن طراحی کرد. در هر صورت، این اصل باید مطابق با تعریف نرم افزار و محتوای مفهوم فناوری برنامه نویسی به عنوان فناوری توسعه نرم افزار قابل اعتماد رعایت شود (به سخنرانی 1 مراجعه کنید). مایرز در این زمینه حتی تعریف می کند انواع متفاوتتست بسته به نوع سند برنامه ای که آزمایش ها بر اساس آن ساخته می شوند. در کشور ما دو نوع اصلی اشکال زدایی (از جمله آزمایشی) وجود دارد: اشکال زدایی مستقل و اشکال زدایی پیچیده. اشکال زدایی آفلاین به این معنی است که فقط بخشی از برنامه موجود در PS را با جستجو و تصحیح خطاهای ثبت شده در حین آزمایش آزمایش کنید. در واقع شامل اشکال زدایی هر ماژول و رفع اشکال جفت شدن ماژول می شود. اشکال زدایی جامع به معنای آزمایش PS به عنوان یک کل با جستجو و تصحیح خطاهای ثبت شده در طول آزمایش در تمام اسناد (از جمله متون برنامه های PS) مربوط به کل PS است. چنین اسنادی شامل تعریف الزامات برای PS، مشخصات کیفی PS، مشخصات عملکردی PS، شرح معماری PS، و متون برنامه های PS است.

55. 10.3. دستورات اشکال زدایی

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

    فرمان 1. آزمایش را به عنوان یک وظیفه کلیدی توسعه نرم افزار در نظر بگیرید، آن را به ماهرترین و با استعدادترین برنامه نویسان بسپارید. آزمایش برنامه خود نامطلوب است.

    فرمان 2. یک تست خوب تستی است که احتمال خطا پیدا کند، نه تستی که عملکرد صحیح برنامه را نشان دهد.

    فرمان 3. تست هایی را برای داده های صحیح و نادرست آماده کنید.

    فرمان 4. از آزمایش های غیر قابل تکرار اجتناب کنید، عبور آنها را از طریق رایانه مستند کنید. نتایج هر آزمون را با جزئیات مطالعه کنید.

    فرمان 5. هر ماژول را فقط یک بار به برنامه متصل کنید. هرگز برنامه ای را تغییر ندهید تا آزمایش آن آسان تر شود.

    فرمان 6. اگر تغییراتی در آن ایجاد شده است (مثلاً در نتیجه رفع اشکال) از تمام آزمایش‌های مربوط به بررسی عملکرد هر برنامه PS یا تعامل آن با سایر برنامه‌ها رد شوید.

58. 10.4. اشکال زدایی ماژول آفلاین

59. در اشکال زدایی آفلاین، هر ماژول در واقع در برخی از محیط های برنامه نویسی آزمایش می شود، مگر اینکه برنامه ای که اشکال زدایی می شود فقط از یک ماژول تشکیل شده باشد. این محیط متشکل از ماژول های دیگری است که برخی از آنها ماژول های برنامه در حال رفع اشکال هستند که قبلاً اشکال زدایی شده اند و برخی از آنها ماژول هایی هستند که اشکال زدایی را کنترل می کنند (ماژول های اشکال زدایی، در زیر ببینید). بنابراین، در طول اشکال زدایی آفلاین، برخی از برنامه ها همیشه در حال آزمایش هستند، که به طور خاص برای آزمایش ماژول در حال اشکال زدایی ساخته شده اند. این برنامه فقط تا حدی با برنامه ای که اشکال زدایی می شود مطابقت دارد، به جز زمانی که آخرین ماژول برنامه در حال رفع اشکال در حال رفع اشکال باشد. همانطور که اشکال زدایی برنامه پیشرفت می کند، بخش فزاینده ای از محیط ماژول بعدی که اشکال زدایی می شود، ماژول های اشکال زدایی شده قبلی این برنامه خواهند بود و هنگام اشکال زدایی آخرین ماژول این برنامه، محیط ماژول در حال اشکال زدایی به طور کامل شامل می شود. همه ماژول های دیگر (از قبل اشکال زدایی شده) برنامه در حال رفع اشکال (بدون هیچ گونه) ماژول های اشکال زدایی هستند. در این صورت، خود برنامه اشکال زدایی شده تست می شود. این فرآیند ایجاد یک برنامه اشکال زدایی شده با ماژول های اشکال زدایی شده و اشکال زدایی شده یکپارچه سازی برنامه نامیده می شود.

    ماژول های اشکال زدایی موجود در محیط ماژول در حال اشکال زدایی به ترتیبی که ماژول های آن برنامه اشکال زدایی می شوند، کدام ماژول اشکال زدایی می شود و احتمالاً از کدام تست صرف نظر می شود، بستگی دارد.

    در تست از پایین به بالا (به فصل 7 مراجعه کنید)، این محیط همیشه حاوی تنها یک ماژول اشکال زدایی خواهد بود (به جز زمانی که آخرین ماژول برنامه ای که اشکال زدایی می شود در حال رفع اشکال باشد)، که سر برنامه تحت آزمایش خواهد بود و نامیده می شود. استاد (یا راننده). ماژول اشکال زدایی پیشرو محیط اطلاعاتی را برای آزمایش ماژول در حال اشکال‌زدایی آماده می‌کند (یعنی وضعیت مورد نیاز برای آزمایش این ماژول را تشکیل می‌دهد، به ویژه می‌تواند برخی از داده‌های آزمایشی را وارد کند)، ماژول در حال اشکال‌زدایی را فراخوانی می‌کند، و پس از اتمام کار آن تکمیل شده، پیام های لازم را صادر می کند. هنگام اشکال زدایی یک ماژول، ماژول های اصلی اشکال زدایی را می توان برای تست های مختلف کامپایل کرد.

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

    در واقع، محیط ماژول در حال اشکال زدایی در بسیاری از موارد به دلایل زیر می تواند شامل هر دو نوع ماژول اشکال زدایی باشد. تست رو به بالا و پایین هر دو مزایا و معایب خود را دارند.

    مزایای تست از پایین به بالا عبارتند از

    سهولت آماده سازی تست ها و

    توانایی اجرای کامل طرح آزمون ماژول.

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

    داده های آزمایشی معمولاً به شکلی که برای کاربر طراحی شده است تهیه نمی شود (به جز زمانی که آخرین، سر، ماژول برنامه ای که اشکال زدایی می شود اشکال زدایی شده باشد).

    مقدار زیادی برنامه نویسی اشکال زدایی (هنگام اشکال زدایی یک ماژول، اغلب باید بسیاری از ماژول های اشکال زدایی پیشرو را برای آزمایش های مختلف بنویسید).

    نیاز به آزمایش ویژه ماژول های رابط.

    از مزایای تست از بالا به پایین می توان به ویژگی های زیر اشاره کرد:

    اکثر تست ها به شکلی طراحی شده اند که برای کاربر طراحی شده است.

    در بسیاری از موارد، مقدار نسبتاً کمی از برنامه نویسی اشکال زدایی (شبیه سازهای ماژول، به عنوان یک قاعده، بسیار ساده هستند و هر کدام برای تعداد زیادی، اغلب برای همه، تست ها مناسب هستند).

    نیازی به تست جفت شدن ماژول ها نیست.

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

    با توجه به این واقعیت که تست از بالا به پایین اصولاً ارجح است، اجازه دهید روی تکنیک‌هایی تمرکز کنیم که به ما امکان می‌دهد تا حدی بر این مشکلات غلبه کنیم. اول از همه، لازم است اشکال زدایی برنامه را به گونه ای سازماندهی کنید که ماژول هایی که وارد کردن داده ها را انجام می دهند در اسرع وقت اشکال زدایی شوند - سپس داده های آزمایشی را می توان به شکلی که برای کاربر طراحی شده است تهیه کرد که تا حد زیادی این کار را انجام می دهد. آماده سازی آزمون های بعدی را ساده کنید. این ورودی به هیچ وجه همیشه در ماژول head انجام نمی‌شود، بنابراین ابتدا باید زنجیره‌های ماژول‌های منتهی به ماژول‌هایی را که ورودی مشخص‌شده را انجام می‌دهند، اشکال زدایی کنید (به روش پیاده‌سازی سازنده هدفمند در سخنرانی 7 مراجعه کنید). تا زمانی که ماژول‌های ورودی اشکال‌زدایی نکنند، داده‌های آزمایشی توسط برخی شبیه‌سازها ارائه می‌شوند: آنها یا در شبیه‌ساز به عنوان بخشی از آن گنجانده می‌شوند یا توسط این شبیه‌ساز وارد می‌شوند.

    در تست از بالا به پایین، برخی از حالت های محیط اطلاعاتی که تحت آنها باید ماژول در حال اشکال زدایی را آزمایش کرد، ممکن است در طول اجرای برنامه ای که برای هیچ ورودی اشکال زدایی می شود، رخ ندهد. در این موارد، ممکن است به هیچ وجه ماژول در حال اشکال زدایی را آزمایش نکنید، زیرا خطاهای یافت شده در این مورد زمانی که برنامه در حال اشکال زدایی تحت هیچ داده ورودی اجرا می شود ظاهر نمی شود. با این حال، انجام این کار توصیه نمی شود، زیرا زمانی که برنامه در حال اشکال زدایی تغییر می کند (به عنوان مثال، هنگام نگهداری PS)، وضعیت های محیط اطلاعاتی که برای آزمایش ماژول در حال اشکال زدایی استفاده نشده است، ممکن است قبلاً ایجاد شود، که به موارد اضافی نیاز دارد. آزمایش این ماژول (و این، با سازماندهی منطقی اشکال زدایی، اگر خود ماژول تغییر نکرده باشد، انجام نمی شود). به منظور آزمایش ماژول در حال اشکال زدایی در این شرایط، گاهی اوقات از شبیه سازهای مناسب برای ایجاد وضعیت مطلوب محیط اطلاعاتی استفاده می شود. بیشتر اوقات، یک نسخه اصلاح شده از تست از بالا به پایین استفاده می شود که در آن ماژول های در حال اشکال زدایی قبل از ادغام به طور جداگانه از قبل آزمایش می شوند (در این مورد، یک ماژول اشکال زدایی پیشرو در محیط ماژول در حال اشکال زدایی ظاهر می شود، همراه با ماژول شبیه سازهایی که توسط ماژول در حال رفع اشکال قابل دسترسی هستند). با این حال، اصلاح دیگری از تست از بالا به پایین مناسب تر به نظر می رسد: پس از اتمام تست از بالا به پایین ماژول که برای حالت های آزمایشی قابل دسترسی محیط اطلاعات اشکال زدایی می شود، باید به طور جداگانه برای حالت های مورد نیاز باقیمانده اطلاعات آزمایش شود. محیط.

    اغلب ترکیبی از تست از پایین به بالا و پایین به بالا نیز استفاده می شود که به آن روش ساندویچ می گویند. ماهیت این روش در اجرای همزمان هر دو تست رو به بالا و پایین نهفته است تا زمانی که این دو فرآیند تست در یک ماژول در جایی در وسط ساختار برنامه در حال اشکال زدایی به هم برسند. این روش با رویکردی معقول به شما امکان می دهد از مزایای آزمایش از پایین به بالا و بالا به پایین استفاده کنید و تا حد زیادی کاستی های آنها را خنثی کنید. این اثر تجلی یک اصل کلی تر است: بزرگترین اثر تکنولوژیکی را می توان با ترکیب روش های برنامه نویسی COP از بالا به پایین و پایین به بالا به دست آورد. برای پشتیبانی از این روش است که رویکرد معماری به توسعه نرم افزار در نظر گرفته شده است (به سخنرانی 7 مراجعه کنید): لایه ای از ماژول های خوب طراحی شده و با دقت آزمایش شده اجرای یک خانواده از برنامه ها در حوزه موضوعی مربوطه و نوسازی بعدی آنها را تا حد زیادی تسهیل می کند.

    در اشکال زدایی آفلاین، تست جفت شدن ماژول بسیار مهم است. واقعیت این است که مشخصات هر ماژول برنامه، به جز سرفصل، در این برنامه در دو حالت استفاده می شود: اول، هنگام توسعه متن (گاهی می گویند: بدنه) این ماژول و دوم، هنگام نوشتن یک متن. این ماژول در ماژول های دیگر برنامه جذاب است. در هر دو مورد، در نتیجه یک خطا، انطباق لازم با مشخصات ماژول داده شده می تواند نقض شود. چنین خطاهایی باید شناسایی و اصلاح شوند. این هدف از آزمایش جفت شدن ماژول ها است. در تست از بالا به پایین، تست جفت سازی در طول مسیر با هر تست رد شده انجام می شود که قوی ترین مزیت تست از بالا به پایین در نظر گرفته می شود. در طول تست پایین به بالا، ماژول اشکال زدایی شده نه از ماژول های برنامه ای که اشکال زدایی می شود، بلکه از ماژول اشکال زدایی پیشرو قابل دسترسی است. در این راستا، این خطر وجود دارد که آخرین ماژول بتواند با برخی "تصورات غلط" ماژول در حال اشکال زدایی سازگار شود. بنابراین، هنگام شروع (در فرآیند ادغام برنامه) اشکال زدایی یک ماژول جدید، لازم است هر فراخوانی را به یک ماژول که قبلا اشکال زدایی شده است آزمایش کنید تا ناهماهنگی بین این فراخوانی و بدنه ماژول مربوطه شناسایی شود (و ممکن است که ماژول قبلاً اشکال زدایی شده مقصر این است). بنابراین، لازم است تا حدی آزمایش یک ماژول اشکال زدایی شده قبلی در شرایط جدید تکرار شود و همان مشکلاتی که در مورد آزمایش از بالا به پایین وجود دارد، ایجاد می شود.

    تست مستقل ماژول باید در چهار مرحله متوالی انجام شود.

    مرحله 1: بر اساس مشخصات ماژولی که دارید اشکال زدایی می کنید، برای هر امکان و موقعیت، برای هر مرز محدوده همه ورودی ها، برای هر محدوده تغییر داده ها، برای هر محدوده نامعتبر از همه ورودی ها، و هر یک تست آماده کنید. شرط نامعتبر

    مرحله 2. متن ماژول را بررسی کنید تا مطمئن شوید که هر جهت از هر شاخه حداقل یک آزمون را پشت سر می گذارد. اضافه کردن تست های از دست رفته

    مرحله 3. از متن ماژول اطمینان حاصل کنید که برای هر حلقه آزمایشی وجود دارد که بدنه حلقه برای آن اجرا نمی شود، آزمایشی که بدنه حلقه برای آن یک بار اجرا می شود، و آزمایشی که بدنه حلقه برای آن حداکثر تعداد اجرا شده است. بار. اضافه کردن تست های از دست رفته

    مرحله 4. متن ماژول را از نظر حساسیت به مقادیر داده های ورودی ویژه فردی بررسی کنید - همه این مقادیر باید در آزمایش ها گنجانده شوند. اضافه کردن تست های از دست رفته

61. 10.5. اشکال زدایی پیچیده نرم افزار

62. همانطور که در بالا ذکر شد، با اشکال زدایی پیچیده، PS به طور کلی آزمایش می شود و آزمایش هایی برای هر یک از اسناد PS آماده می شود. آزمایش این اسناد معمولاً به ترتیب معکوس توسعه آنها انجام می شود (تنها استثنا آزمایش اسناد برنامه است که مطابق توضیحات خارجی به موازات توسعه متون برنامه توسعه می یابد؛ این آزمایش بهتر است پس از آزمایش انجام شود. توضیحات خارجی تکمیل شده است). آزمایش در اشکال‌زدایی پیچیده، کاربرد PS برای داده‌های خاصی است که در اصل ممکن است از کاربر ناشی شود (به ویژه، همه آزمایش‌ها به شکلی که برای کاربر طراحی شده آماده می‌شوند)، اما احتمالاً به صورت شبیه‌سازی شده (و نه واقعی) محیط. به عنوان مثال، برخی از دستگاه های ورودی و خروجی که در طول اشکال زدایی پیچیده غیرقابل دسترسی هستند را می توان با شبیه سازهای نرم افزاری آنها جایگزین کرد.

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

    تست عملکردهای خارجی هدف از آزمایش یافتن اختلاف بین مشخصات عملکردی و مجموعه برنامه های نرم افزاری PS است. علیرغم این واقعیت که همه این برنامه ها قبلاً به طور مستقل اشکال زدایی شده اند، این اختلافات ممکن است به عنوان مثال به دلیل عدم تطابق بین مشخصات داخلی برنامه ها و ماژول های آنها (بر اساس آن تست مستقل انجام شده است) و مشخصات عملکرد خارجی باشد. از ام اس به عنوان یک قاعده، آزمایش توابع خارجی به همان روشی که تست ماژول ها در مرحله اول انجام می شود، یعنی. مثل جعبه سیاه

    تست کیفیت PS هدف از آزمایش جستجوی نقض الزامات کیفیت فرموله شده در مشخصات کیفیت PS است. این سخت ترین و کم مطالعه ترین نوع تست است. تنها واضح است که هر PS اولیه کیفیت را نمی توان با آزمایش آزمایش کرد (سخنرانی بعدی در مورد ارزیابی کیفیت PS را ببینید). کامل بودن PS قبلاً هنگام آزمایش عملکردهای خارجی بررسی می شود. در این مرحله، در صورتی که نیاز به برآورد احتمالی درجه قابلیت اطمینان PS باشد، می توان آزمایش این کیفیت اولیه را ادامه داد. با این حال، روش برای چنین آزمایشی هنوز نیاز به توسعه دارد. دقت، استحکام، امنیت، کارایی زمانی، کارایی حافظه تا حدی، کارایی دستگاه، توسعه پذیری و تا حدی استقلال دستگاه قابل آزمایش است. هر یک از این نوع تست ها ویژگی های خاص خود را دارد و شایسته بررسی جداگانه است. ما در اینجا خود را به فهرست کردن آنها محدود می کنیم. سهولت استفاده از PS (معیار کیفی که شامل چندین کیفیت اولیه است، به سخنرانی 4 مراجعه کنید) هنگام آزمایش اسناد استفاده از PS ارزیابی می شود.

    مستندات آزمایشی در مورد کاربرد PS. هدف از آزمایش، جستجوی ناهماهنگی بین مستندات موجود در برنامه و مجموعه برنامه‌های نرم‌افزاری و همچنین عدم استفاده از نرم‌افزار است. این مرحله بلافاصله قبل از اتصال کاربر به تکمیل توسعه PS (تست الزامات PS و صدور گواهینامه PS) است، بنابراین برای توسعه دهندگان بسیار مهم است که ابتدا خود از PS به روشی که کاربر انجام می دهد استفاده کنند. آی تی. تمام آزمون ها در این مرحله صرفاً بر اساس مستندات مربوط به کاربرد PS تهیه می شوند. اول از همه، قابلیت‌های نرم‌افزار باید همانطور که هنگام آزمایش عملکردهای خارجی انجام شد، آزمایش شود، اما فقط بر اساس مستندات برنامه. تمام مکان های نامشخص در مستندات و همچنین تمام نمونه های استفاده شده در مستندات باید آزمایش شوند. در مرحله بعد، سخت ترین موارد استفاده از PS به منظور تشخیص نقض الزامات مربوط به نسبیت سهولت استفاده از PS آزمایش می شود.

    تست تعریف الزامات برای PS. هدف از تست این است که بفهمیم نرم افزار تا چه حد با تعریف ارائه شده از الزامات آن مطابقت ندارد. ویژگی این نوع آزمایش این است که توسط سازمان خرید یا سازمان کاربر PS به عنوان یکی از راه های غلبه بر مانع بین توسعه دهنده و کاربر انجام می شود (به سخنرانی 3 مراجعه کنید). معمولاً این آزمایش با کمک کارهای کنترلی انجام می شود - کارهای معمولی که نتیجه راه حل برای آنها مشخص است. در مواردی که PS توسعه‌یافته باید جایگزین نسخه دیگری از PS شود که حداقل بخشی از وظایف PS توسعه‌یافته را حل می‌کند، آزمایش با حل مشکلات رایج با استفاده از PS قدیمی و جدید انجام می‌شود و به دنبال آن نتایج مقایسه می‌شود. به دست آمده. گاهی اوقات، به عنوان نوعی از این آزمایش، از عملیات آزمایشی PS استفاده می شود - یک کاربرد محدود از یک PS جدید با تجزیه و تحلیل استفاده از نتایج در عمل. در اصل، این نوع آزمایش شباهت زیادی با آزمایش PS در طول صدور گواهینامه دارد (به سخنرانی 14 مراجعه کنید)، اما قبل از صدور گواهینامه و گاهی اوقات به جای صدور گواهینامه انجام می شود.

64. ادبیات برای سخنرانی 10.

65. 10.1. جی. مایرز. قابلیت اطمینان نرم افزار - م.: میر، 1980. - S. 171-262.

    10.2. دی ون تاسل. برنامه های سبک، توسعه، کارایی، اشکال زدایی و آزمایش. - م.: میر، 1985. - S. 179-295.

    10.3. جی. هیوز، جی. میشتوم. رویکرد ساختاریبه برنامه نویسی - م.: میر، 1980. - S. 254-268.

    10.4. جی. فاکس. نرم افزار و توسعه آن - م.: میر، 1985. - س 227-241.

    10.5. M. Zelkowitz، A. Shaw، J. Gannon. اصول توسعه نرم افزار. - م.: میر، 1982. - S. 105-116.

    10.6. یو.م. بزبورودوف. اشکال زدایی فردی برنامه ها. - M.: Nauka، 1982. - S. 9-79.

    10.7. V.V. لیپاف. تست برنامه - م.: رادیو و ارتباطات، 1986. - S. 15-47.

    10.8. E.A. ژوگولف. مقدمه ای بر فناوری برنامه نویسی (یادداشت های سخنرانی). - M.: "DIALOGUE-MGU"، 1994.

    10.9. E. Dijkstra. نکاتی در مورد برنامه نویسی ساخت یافته //U. دال، ای. دایکسترا، کی. هور. برنامه ریزی ساختاری - م.: میر، 1975. - س 7-13.

67. سخنرانی 11

69. 11.1. عملکرد و قابلیت اطمینان به عنوان معیارهای اجباری برای کیفیت نرم افزار.

70. در سخنرانی های قبلی، ما تمام مراحل توسعه PS را به جز صدور گواهینامه آن در نظر گرفتیم. در عین حال، ما به مسائل تضمین کیفیت PS مطابق با مشخصات کیفی آن اشاره نکردیم (به سخنرانی 4 مراجعه کنید). درست است، در حین اجرای مشخصات عملکردی PS، ما در نتیجه مسائل اصلی اطمینان از معیار عملکرد را مورد بحث قرار دادیم. با اعلام قابلیت اطمینان نرم افزار به عنوان ویژگی اصلی آن (به سخنرانی 1 مراجعه کنید)، ما پیشگیری از خطا را به عنوان رویکرد اصلی برای اطمینان از قابلیت اطمینان نرم افزار انتخاب کرده ایم (به سخنرانی 3 مراجعه کنید) و پیاده سازی آن را در مراحل مختلف توسعه نرم افزار مورد بحث قرار داده ایم. بنابراین، تز در مورد عملکرد اجباری و قابلیت اطمینان PS به عنوان معیاری برای کیفیت آن آشکار شد.

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

    ارائه اولیه کیفیت MS که معیارهای عملکرد و قابلیت اطمینان MS را بیان می کند در زیر مورد بحث قرار می گیرد.

72. 11.2. اطمینان از کامل بودن نرم افزار.

73. کامل بودن PS یک کیفیت اولیه عمومی PS برای بیان عملکرد و قابلیت اطمینان PS است و از نظر عملکرد تنها اولیه است (به سخنرانی 4 مراجعه کنید).

    عملکرد PS با مشخصات عملکردی آن تعیین می شود. کامل بودن یک PS به عنوان یک ویژگی اولیه کیفیت آن، معیاری است برای چگونگی اجرای این مشخصات در یک PS معین. ارائه این اولیه به طور کامل به معنای اجرای هر یک از توابع تعریف شده در مشخصات عملکردی، با تمام جزئیات و ویژگی های ذکر شده در آنجا است. تمام فرآیندهای تکنولوژیکی که قبلاً مورد بحث قرار گرفت نشان می دهد که چگونه می توان این کار را انجام داد.

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

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

75. 11.3. اطمینان از صحت ابزار نرم افزار.

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

    در مورد خطای روش محاسبه استفاده شده (که در آن عدم دقت مدل مورد استفاده را لحاظ می کنیم)،

    از خطا در ارائه داده های مورد استفاده (از خطای به اصطلاح کشنده)،

    از خطای گرد کردن (عدم دقت در اجرای عملیات استفاده شده در روش).

78. 11.4. اطمینان از استقلال نرم افزار.

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

81. 11.5. تضمین پایداری نرم افزار.

82. این بدوی با کیفیت به کمک برنامه نویسی به اصطلاح دفاعی ارائه می شود. به طور کلی، برنامه‌نویسی دفاعی برای بهبود قابلیت اطمینان MS هنگام برنامه‌ریزی ماژول به معنای وسیع‌تر استفاده می‌شود. همانطور که مایرز می گوید، "برنامه نویسی دفاعی بر اساس یک فرض مهم است: بدترین کاری که یک ماژول می تواند انجام دهد این است که ورودی بد را بپذیرد و سپس یک نتیجه نادرست اما قابل قبول را ارائه دهد." به منظور جلوگیری از این امر، متن ماژول شامل بررسی صحت داده های ورودی و خروجی آن مطابق با مشخصات این ماژول، به ویژه انجام محدودیت ها در داده های ورودی و خروجی و روابط بین آنها است. مشخص شده در مشخصات ماژول باید بررسی شود. در صورت منفی بودن نتیجه چک، استثنای مربوطه مطرح می شود. در این راستا، قطعاتی از نوع دوم در انتهای این ماژول گنجانده شده است - کنترل کننده های موقعیت های استثنایی مربوطه، که علاوه بر صدور اطلاعات تشخیصی لازم، می توانند اقداماتی را برای حذف خطاهای داده ها انجام دهند (به عنوان مثال، نیاز به وارد کردن مجدد آنها) یا کاهش تأثیر خطا (به عنوان مثال، توقف نرم دستگاه های کنترل شده توسط PS به منظور جلوگیری از خرابی آنها در صورت خاتمه اضطراری اجرای برنامه).

    استفاده از برنامه نویسی محافظ ماژول ها منجر به کاهش کارایی PS هم در زمان و هم در حافظه می شود. بنابراین، بسته به الزامات مربوط به قابلیت اطمینان و کارایی PS، که در مشخصات کیفی PS توسعه یافته فرموله شده است، لازم است که درجه کاربرد برنامه ریزی دفاعی به طور منطقی تنظیم شود. داده های ورودی ماژول توسعه یافته می تواند مستقیماً از کاربر یا سایر ماژول ها باشد. رایج ترین مورد استفاده از برنامه نویسی دفاعی استفاده از آن برای گروه اول داده ها است که به معنای تحقق پایداری PS است. این باید هر زمان انجام شود که مشخصات کیفی PS دارای الزامی برای اطمینان از پایداری PS باشد. استفاده از برنامه نویسی دفاعی برای گروه دوم داده های ورودی به معنای تلاش برای تشخیص خطا در ماژول های دیگر در حین اجرای ماژول توسعه یافته و برای داده های خروجی ماژول توسعه یافته، تلاش برای تشخیص خطا در خود ماژول است. در طول اجرای آن در اصل، این به معنای اجرای جزئی روش تشخیص خطا برای اطمینان از قابلیت اطمینان نرم افزار است که در درس 3 مورد بحث قرار گرفت. فوق العاده بالا هستند.

84. 11.6. تضمین امنیت نرم افزار.

85. انواع زیر از حفاظت PS در برابر تحریف اطلاعات وجود دارد:

    محافظت در برابر خرابی های سخت افزاری؛

    محافظت در برابر نفوذ یک برنامه "خارجی"؛

    محافظت در برابر شکست برنامه "خود"؛

    محافظت در برابر خطاهای اپراتور (کاربر)؛

    محافظت در برابر دسترسی غیرمجاز؛

    حفاظت در برابر حفاظت

    حفاظت در برابر خرابی های سخت افزاری در حال حاضر یک کار خیلی فوری نیست (با در نظر گرفتن سطح اطمینان رایانه به دست آمده). اما دانستن راه حل او همچنان مفید است. این با سازماندهی به اصطلاح "محاسبات اشتباه دو سه گانه" تضمین می شود. برای این، کل فرآیند پردازش داده ها، که توسط PS تعیین می شود، در زمان به فواصل زمانی توسط به اصطلاح "نقاط مرجع" تقسیم می شود. طول این بازه نباید از نصف میانگین زمان کارکرد کامپیوتر بیشتر شود. یک کپی از وضعیت حافظه تغییر یافته در این فرآیند برای هر نقطه مرجع با مقداری در حافظه ثانویه نوشته می شود چک جمع(عددی که به عنوان تابعی از این حالت محاسبه می شود) در صورتی که در نظر گرفته شود که پردازش داده ها از نقطه مرجع قبلی به این نقطه (یعنی یک "محاسبه اشتباه") به درستی (بدون خرابی رایانه) انجام شده است. برای پی بردن به این موضوع، دو "اشتباه محاسباتی" انجام می شود. پس از "محاسبه" اول، چک جمع مشخص شده محاسبه و ذخیره می شود و سپس حالت حافظه برای نقطه مرجع قبلی بازیابی می شود و "محاسبه" دوم انجام می شود. پس از دومین "اشتباه محاسباتی"، چک جمع مشخص شده مجددا محاسبه می شود که سپس با چک جمع "اشتباه محاسبه" اول مقایسه می شود. اگر این دو چک با هم مطابقت داشته باشند، محاسبه دوم صحیح تلقی می شود، در غیر این صورت جمع چک دوم «محاسبه» نیز ذخیره می شود و «محاسبه» سوم (با بازیابی اولیه حالت حافظه برای نقطه مرجع قبلی) انجام می شود. اگر جمع چک سومین "اشتباه محاسباتی" با جمع چک یکی از دو "اشتباه محاسباتی" اول مطابقت داشته باشد، محاسبه اشتباه سوم صحیح تلقی می شود، در غیر این صورت بررسی مهندسی کامپیوتر مورد نیاز است.

    حفاظت در برابر نفوذ یک برنامه "خارجی" در درجه اول به سیستم عامل ها یا برنامه هایی اشاره دارد که تا حدی وظایف خود را انجام می دهند. دو نوع از این حفاظت وجود دارد:

    حفاظت از شکست،

    محافظت در برابر نفوذ مخرب یک برنامه "خارجی".

    هنگامی که یک حالت چندبرنامه‌نویسی یک رایانه ظاهر می‌شود، چندین برنامه می‌توانند به طور همزمان در حافظه آن اجرا شوند و به طور متناوب در نتیجه وقفه‌ها (به اصطلاح اجرای شبه موازی برنامه‌ها) کنترل را دریافت کنند. یکی از این برنامه ها (معمولاً: سیستم عامل) وقفه ها را مدیریت می کند و چندبرنامه نویسی را مدیریت می کند. در هر یک از این برنامه ها، ممکن است خرابی هایی رخ دهد (خطاهایی ظاهر می شود) که ممکن است بر عملکرد عملکردهای دیگر برنامه ها تأثیر بگذارد. بنابراین، برنامه کنترل (سیستم عامل) باید خود و سایر برنامه ها را از چنین نفوذی محافظت کند. برای انجام این کار، سخت افزار کامپیوتر باید ویژگی های زیر را اجرا کند:

    حفاظت از حافظه،

    دو حالت کارکرد کامپیوتر: ممتاز و کار (کاربر)،

    دو نوع معاملات: ممتاز و عادی،

    اجرای صحیح وقفه ها و راه اندازی اولیه کامپیوتر،

    وقفه موقت

    حفاظت از حافظه به معنای توانایی تنظیم برنامه‌ای برای هر برنامه مناطقی از حافظه است که برای آن غیرقابل دسترسی است. در حالت ممتاز، هر عملیاتی (اعم از معمولی و ممتاز) قابل انجام است و در حالت اجرا فقط عملیات معمولی. تلاش برای انجام یک عملیات ممتاز و همچنین دسترسی به حافظه محافظت شده در حالت عملکرد، باعث وقفه مربوطه می شود. علاوه بر این، عملیات ممتاز شامل عملیات تغییر حفاظت حافظه و حالت عملکرد و همچنین دسترسی به محیط اطلاعات خارجی است. روشن شدن اولیه رایانه و هرگونه وقفه باید به طور خودکار حالت ممتاز را فعال کرده و محافظت از حافظه را لغو کند. در این حالت، برنامه کنترل (سیستم عامل) می تواند به طور کامل از خود در برابر تأثیر برنامه های دیگر محافظت کند، در صورتی که تمام نقاط انتقال کنترل در روشن شدن اولیه و وقفه ها متعلق به این برنامه باشد، اگر به هیچ برنامه دیگری اجازه کار در آن را ندهد. حالت ممتاز (زمانی که کنترل به دیگری منتقل می شود، برنامه فقط حالت عملیاتی را روشن می کند) و اگر به طور کامل از حافظه خود (به ویژه شامل تمام اطلاعات کنترلی خود، از جمله بردارهای به اصطلاح وقفه) از سایر برنامه ها محافظت کند. سپس هیچ کس آن را از انجام هر گونه عملکرد حفاظتی اجرا شده در آن برای سایر برنامه ها (از جمله دسترسی به محیط اطلاعات خارجی) منع نخواهد کرد. برای تسهیل حل این مشکل، بخشی از چنین برنامه ای در حافظه دائمی قرار می گیرد، یعنی. جدایی ناپذیر از خود کامپیوتر وجود یک وقفه موقت به برنامه کنترل اجازه می دهد تا از خود در برابر حلقه زدن در برنامه های دیگر محافظت کند (بدون چنین وقفه ای، به سادگی می تواند توانایی کنترل را از دست بدهد).

    حفاظت در برابر شکست برنامه "خود" با قابلیت اطمینان این برنامه تضمین می شود، که تمرکز کل فناوری برنامه نویسی مورد بحث در این دوره از سخنرانی ها است.

    حفاظت در برابر خطاهای کاربر (علاوه بر خطاهای داده های ورودی، اطمینان از پایداری PS را ببینید) با صدور پیام های هشدار دهنده در مورد تلاش برای تغییر وضعیت محیط اطلاعات خارجی با الزام تأیید این اقدامات و همچنین امکان بازیابی وضعیت اجزای فردی محیط اطلاعات خارجی. دومی مبتنی بر اجرای تغییرات بایگانی در وضعیت محیط اطلاعات خارجی است.

    محافظت در برابر دسترسی غیرمجاز با استفاده از کلمات مخفی (رمز عبور) فراهم می شود. در این حالت به هر کاربر اطلاعات و منابع رویه ای (سرویس) خاصی ارائه می شود که استفاده از آنها مستلزم ارائه رمز عبور به PS است که قبلاً توسط این کاربر در PS ثبت شده است. به عبارت دیگر، کاربر، همانطور که گفته شد، "قفل" را روی منابع اختصاص داده شده به او، "کلیدی" که فقط این کاربر به آن دارد، آویزان می کند. با این حال، اگر منابع حفاظت شده برای کسی ارزش فوق العاده ای داشته باشد، ممکن است تلاش های مداوم برای شکستن چنین حفاظتی در موارد فردی انجام شود. در چنین شرایطی، اقدامات اضافی باید برای محافظت در برابر نقض امنیت انجام شود.

    حفاظت در برابر نقض امنیت با استفاده از تکنیک های برنامه نویسی ویژه در PS همراه است که غلبه بر محافظت در برابر دسترسی غیرمجاز را دشوار می کند. استفاده رمزهای عبور معمولیزمانی که به میل شدیداً مداوم (مثلاً ماهیت جنایی) برای دستیابی به اطلاعات ارزشمند می رسد، کافی نیست. اولاً، زیرا اطلاعات مربوط به رمزهای عبوری که PS برای محافظت در برابر دسترسی غیرمجاز استفاده می کند، می تواند به راحتی توسط یک "ترقه کننده" این حفاظت در صورتی که به خود این PS دسترسی داشته باشد، به دست آورد. ثانیاً، با استفاده از رایانه، می توان تعداد زیادی از رمزهای عبور ممکن را به منظور یافتن رمز عبور مناسب برای دسترسی به اطلاعات مورد علاقه، انجام داد. شما می توانید به روش زیر از خود در برابر چنین هک محافظت کنید. کلمه مخفی (رمز عبور) یا فقط عدد صحیح مخفی X فقط برای صاحب اطلاعات محافظت شده شناخته شده است و برای بررسی حقوق دسترسی، شماره دیگری Y=F(X) در رایانه ذخیره می شود که به صورت منحصر به فرد توسط PS هر بار که تلاش می شود با ارائه کلمه مخفی به این اطلاعات دسترسی پیدا کند. در عین حال، تابع F می تواند برای همه کاربران PS به خوبی شناخته شود، اما دارای چنین خاصیتی است که بازیابی کلمه X از Y عملا غیرممکن است: با طول به اندازه کافی بزرگ کلمه X (به عنوان مثال، چند صد کاراکتر). ) این نیاز به زمان نجومی دارد. چنین عددی Y را امضای الکترونیکی (رایانه ای) صاحب کلمه مخفی X (و از این رو اطلاعات محافظت شده) می نامند.

    نوع دیگری از چنین حفاظتی مربوط به محافظت از پیام های ارسال شده از طریق شبکه های کامپیوتری، تحریف عمدی (یا مخرب) است. چنین پیامی را می توان در نقاط "transshipment" شبکه کامپیوتری رهگیری کرد و با پیام دیگری از نویسنده پیام رهگیری شده جایگزین کرد. این وضعیت در درجه اول در اجرای عملیات بانکی با استفاده از یک شبکه کامپیوتری به وجود می آید. با جایگزینی چنین پیامی که دستور صاحب یک حساب بانکی برای انجام برخی عملیات بانکی است، می توان پول حساب وی را به حساب حفاظت «هکر» (نوعی سرقت از بانک رایانه) منتقل کرد. حفاظت در برابر چنین نقض امنیتی می تواند به شرح زیر انجام شود. همراه با تابع F، که امضای کامپیوتری صاحب کلمه مخفی X را تعیین می کند، که برای مخاطب پیام محافظت شده شناخته شده است (اگر فقط مالک آن مشتری این مخاطب باشد)، تابع Stamp دیگری در PS، که از روی آن فرستنده پیام باید با استفاده از کلمه مخفی X و متن پیام ارسال شده R، عدد S=Stamp(X,R) را محاسبه کند. خاصیتی که عملاً بازیابی عدد X از S یا انتخاب پیام R دیگر با امضای رایانه مربوطه غیرممکن است. خود پیام ارسال شده (همراه با محافظت از آن) باید به شکل زیر باشد:

    علاوه بر این، Y (امضای کامپیوتری) به مخاطب این امکان را می دهد که حقیقت مشتری را مشخص کند و S، همانطور که گفته شد، پیام محافظت شده R را با امضای رایانه ای Y بسته می کند. در این راستا، شماره S را الکترونیکی (رایانه) می نامیم. ) مهر. PS یک تابع دفتر اسناد رسمی دیگر را تعریف می کند که بر اساس آن گیرنده پیام محافظت شده صحت پیام ارسال شده را بررسی می کند:

86. این به شما امکان می دهد بدون ابهام مشخص کنید که پیام R متعلق به صاحب کلمه مخفی X است.

    در صورتی که کاربر رمز عبور خود را فراموش کرده (یا گم کرده باشد) محافظت در برابر محافظت ضروری است. برای چنین موردی، باید برای یک کاربر ویژه (مدیر PS) که مسئول عملکرد سیستم حفاظتی است، امکان حذف موقت حفاظت از دسترسی غیرمجاز برای مالک وجود داشته باشد. رمز عبور را فراموش کرده ایدتا به او این فرصت را بدهد که رمز عبور جدید را اصلاح کند.

88. ادبیات برای سخنرانی 11.

89. 11.1. است. برزین، ن.پ. ژیدکوف روشهای محاسبه، ج. 1 و 2. - م.: فیزمتگیز، 1959م.

    11.2. N.S. باخوالوف، ن.پ. ژیدکوف، جی.ام. کوبلکوف. روشهای عددی. - M.: Nauka، 1987.

    11.3. جی. مایرز. قابلیت اطمینان نرم افزار - م.: میر، 1980. S. 127-154.

    11.4. A.N. لبدف حفاظت از اطلاعات بانکی و رمزنگاری مدرن//مسائل امنیت اطلاعات، 2(29)، 1995.

91. سخنرانی 12. تضمین کیفیت نرم افزار

93. 12.1. مشخصات کلی فرآیند تضمین کیفیت نرم افزار.

94. همانطور که قبلاً در سخنرانی 4 ذکر شد، مشخصات کیفیت دستورالعمل های اصلی (اهداف) را تعریف می کند که در تمام مراحل توسعه PS به یک طریق یا دیگری بر انتخاب گزینه مناسب هنگام تصمیم گیری های مختلف تأثیر می گذارد. با این حال، هر کیفیت اولیه ویژگی‌های خاص خود را برای چنین تأثیری دارد، بنابراین، اطمینان از حضور آن در PS ممکن است به رویکردها و روش‌های خاص خود برای توسعه PS یا بخش‌های جداگانه آن نیاز داشته باشد. علاوه بر این، ناهماهنگی معیارهای کیفی PS و معیارهای اولیه کیفی بیانگر آنها نیز مورد توجه قرار گرفت: ارائه خوب یکی از معیارهای اولیه کیفی PS می تواند به طور قابل توجهی ارائه برخی از این موارد اولیه را پیچیده یا غیرممکن کند. بنابراین، بخش اساسی از فرآیند تضمین کیفیت PS شامل یافتن مبادلات قابل قبول است. این مبادلات باید تا حدی در مشخصات کیفیت PS تعریف شده باشد: مدل کیفیت PS باید درجه حضور مورد نیاز در PS هر یک از کیفیت های اولیه خود را مشخص کند و اولویت ها را برای دستیابی به این درجات تعیین کند.

    تضمین کیفیت در هر فرآیند فناوری انجام می شود: تصمیمات اتخاذ شده در آن، به یک درجه یا دیگری، بر کیفیت نرم افزار به عنوان یک کل تأثیر می گذارد. به ویژه، زیرا بخش قابل توجهی از کیفیت اولیه نه چندان با ویژگی های برنامه های موجود در PS، بلکه با ویژگی های اسناد مرتبط است. با توجه به ناهماهنگی ذکر شده در کیفیت اولیه، رعایت اولویت های انتخابی در ارائه آنها بسیار مهم است. اما در هر صورت رعایت دو اصل کلی مفید است:

    ابتدا باید از عملکرد و قابلیت اطمینان مورد نیاز PS اطمینان حاصل کرد و سپس معیارهای کیفیت باقیمانده را به سطح قابل قبولی از حضور آنها در PS رساند.

    نیازی نیست، و حتی ممکن است مضر باشد، به دنبال سطح بالاتری از حضور در PS با هر کیفیت اولیه ای نسبت به آنچه در مشخصات کیفیت PS تعریف شده است.

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

    12.2.. اطمینان از سهولت استفاده از ابزار نرم افزار

    P-documentation PS ترکیب مستندات کاربر را تعیین می کند

    در سخنرانی قبلی، ارائه دو مورد از پنج کیفیت اولیه (پایداری و امنیت) که سهولت استفاده از PS را تعیین می کند قبلاً در نظر گرفته شد.

    P-documentation و informativeness ترکیب و کیفیت مستندات کاربر را تعیین می کند (به سخنرانی بعدی مراجعه کنید).

    جامعه پذیری با ایجاد یک رابط کاربری مناسب و اجرای مناسب موقعیت های استثنایی تضمین می شود. مشکل اینجا چیست؟

96. 12.3. اطمینان از اثربخشی نرم افزار.

97. اثربخشی PS با اتخاذ تصمیمات مناسب در مراحل مختلف توسعه آن، با شروع توسعه معماری آن، تضمین می شود. انتخاب ساختار داده و ارائه به ویژه بر کارایی PS تأثیر می گذارد (به ویژه از نظر حافظه). اما انتخاب الگوریتم‌های مورد استفاده در ماژول‌های نرم‌افزاری خاص و همچنین ویژگی‌های پیاده‌سازی آنها (از جمله انتخاب زبان برنامه‌نویسی) می‌تواند تأثیر قابل توجهی بر اثربخشی PS داشته باشد. در عین حال، شخص باید دائماً تضاد بین کارایی زمانی و کارایی را از حافظه حل کند. بنابراین، بسیار مهم است که مشخصات کیفی به صراحت رابطه کمی بین شاخص‌های این شاخص‌های اولیه کیفی را نشان دهد یا حداقل مرزهای کمی را برای یکی از این شاخص‌ها تعیین کند. و با این حال، ماژول‌های نرم‌افزاری مختلف تأثیر متفاوتی بر کارایی PS به‌عنوان یک کل دارند: هم از نظر سهم آنها در کل هزینه‌های PS از نظر زمان و حافظه و هم از نظر تأثیر بر کیفیت‌های اولیه اولیه. (برخی از ماژول ها می توانند به شدت بر دستیابی به بازده زمانی تأثیر بگذارند و عملاً تأثیری بر کارایی حافظه ندارند، در حالی که برخی دیگر می توانند به طور قابل توجهی بر مصرف کلی حافظه تأثیر بگذارند بدون اینکه تأثیر قابل توجهی بر زمان عملکرد PS داشته باشند). علاوه بر این، این تأثیر (در درجه اول از نظر بازده زمانی) از قبل (قبل از اتمام اجرای PS) همیشه نمی تواند به درستی ارزیابی شود.

    ابتدا باید یک PS قابل اعتماد ایجاد کنید و تنها پس از آن به کارایی مورد نیاز آن مطابق با مشخصات کیفی این PS دست یابید.

    برای بهبود کارایی PS، اول از همه، از یک کامپایلر بهینه سازی استفاده کنید - این می تواند کارایی لازم را ارائه دهد.

    اگر بازده به دست آمده از PS مشخصات کیفیت آن را برآورده نمی کند، بحرانی ترین ماژول ها را از نظر بازده مورد نیاز PS پیدا کنید (در مورد بازده زمانی، این مستلزم به دست آوردن توزیع بر اساس ماژول های PS است. زمان عملیات با اندازه گیری های مناسب در طول اجرای PS)؛ این ماژول ها و سعی کنید ابتدا با تغییر دستی آنها را بهینه کنید.

    اگر برای دستیابی به کارایی مورد نیاز PS لازم نیست ماژول را بهینه نکنید.

    12.4. تضمین قابلیت نگهداری

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

    از نظراتی در متن ماژول استفاده کنید که ویژگی های تصمیمات اتخاذ شده را روشن و توضیح می دهد. در صورت امکان، نظرات (حداقل به صورت کوتاه) را در اولین مرحله از توسعه متن ماژول درج کنید.

    از نام‌های معنی‌دار (مانمونیک) و دائماً قابل تشخیص استفاده کنید (طول بهینه نام 4-12 حرف است، اعداد در پایان هستند)، از نام‌ها و کلمات کلیدی مشابه استفاده نکنید.

    هنگام استفاده از ثابت ها مراقب باشید (یک ثابت منحصر به فرد باید یک رخداد واحد در متن ماژول داشته باشد: زمانی که اعلام می شود یا در موارد شدید، زمانی که متغیر به عنوان یک ثابت مقدار دهی اولیه می شود).

    از استفاده از پرانتز اختیاری نترسید (پرانتزها ارزانتر از اشکال هستند.

    در هر خط بیش از یک بیانیه قرار ندهید. برای روشن شدن ساختار ماژول، از فضاهای اضافی (تورفتگی) در ابتدای هر خط استفاده کنید.

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

    توسعه پذیری با ایجاد یک نصب کننده مناسب تضمین می شود.

    ساختار و مدولار بودن هم درک متون برنامه و هم اصلاح آنها را ساده می کند.

    12.5. تضمین تحرک

99. ادبیات برای سخنرانی 12.

100. 12.1. ایان سامرویل مهندسی نرم افزار. - شرکت انتشارات آدیسون-وسلی، 1992. پ.

     12.3. دی ون تاسل. برنامه های سبک، توسعه، کارایی، اشکال زدایی و آزمایش. - م.: میر، 1985. س 8-44، 117-178.

     12.4. مستندات کاربر نرم افزار/ استاندارد ANSI/IEEE 1063-1987.

102. سخنرانی 13

104. 13.1. اسناد ایجاد شده در طول فرآیند توسعه نرم افزار.

105. هنگام توسعه یک PS، مقدار زیادی از اسناد مختلف ایجاد می شود. به عنوان وسیله ای برای انتقال اطلاعات بین توسعه دهندگان PS، به عنوان وسیله ای برای مدیریت توسعه PS، و به عنوان وسیله ای برای انتقال اطلاعات لازم برای استفاده و نگهداری از PS به کاربران ضروری است. ایجاد این مستندات سهم زیادی از هزینه PS را به خود اختصاص می دهد.

     این اسناد را می توان به دو گروه تقسیم کرد:

     اسناد مدیریت توسعه PS.

     اسناد موجود در PS.

     اسناد مدیریت توسعه PS (مستندات فرآیند) فرآیندهای توسعه و نگهداری PS را ثبت می کند، ارتباطات درون تیم توسعه و بین تیم توسعه و مدیران (مدیران) - افرادی که توسعه را مدیریت می کنند، فراهم می کند. این اسناد می تواند از انواع زیر باشد:

     برنامه ها، برآوردها، برنامه ها. این اسناد توسط مدیران برای پیش بینی و مدیریت فرآیندهای توسعه و نگهداری ایجاد می شود.

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

     استانداردها این اسناد برای توسعه دهندگان اصول، قوانین، توافقاتی را که باید در روند توسعه PS رعایت کنند، تجویز می کند. این استانداردها می توانند بین المللی یا ملی باشند یا به طور خاص برای سازمانی که این PS در آن توسعه می یابد ایجاد شود.

     مدارک کار اینها اسناد فنی اصلی هستند که ارتباط بین توسعه دهندگان را فراهم می کنند. آنها حاوی تثبیت ایده ها و مشکلاتی هستند که در طول فرآیند توسعه به وجود می آیند، شرحی از استراتژی ها و رویکردهای مورد استفاده، و همچنین نسخه های کاری (موقت) اسنادی که باید در PS گنجانده شوند.

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

     اسناد موجود در PS (مستندات محصول) برنامه های PS را هم از نقطه نظر استفاده از آنها توسط کاربران و هم از نظر توسعه دهندگان و نگهبانان آنها (مطابق با هدف PS) توصیف می کنند. در اینجا لازم به ذکر است که این اسناد نه تنها در مرحله بهره برداری از PS (در مراحل کاربرد و نگهداری آن)، بلکه در مرحله توسعه نیز برای مدیریت فرآیند توسعه (به همراه اسناد کاری) - در هر در این مورد، آنها باید برای انطباق با برنامه های PS بررسی (تست) شوند. این اسناد دو مجموعه با اهداف متفاوت را تشکیل می دهند:

     مستندات کاربر PS (P-documentation).

     اسناد پشتیبانی از PS (C-documentation).

107. 13.2. مستندات کاربر نرم افزار.

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

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

     ترکیب اسناد کاربر به مخاطبان کاربرانی که هدف این PS است و به نحوه استفاده از اسناد بستگی دارد. مخاطب در اینجا به عنوان گروهی از کاربران PS درک می شود که به مستندات کاربری خاصی از PS نیاز دارند. یک سند کاربری موفق اساساً به تعریف دقیق مخاطبی بستگی دارد که برای آن در نظر گرفته شده است. اسناد کاربر باید حاوی اطلاعات مورد نیاز برای هر مخاطب باشد. نحوه استفاده از سند به نحوه استفاده از سند اشاره دارد. معمولاً کاربر سیستم‌های نرم‌افزاری به اندازه کافی بزرگ به اسنادی برای مطالعه PS (استفاده در قالب دستورالعمل) یا برای روشن کردن برخی اطلاعات (استفاده در قالب یک کتاب مرجع) نیاز دارد.

     مطابق با آثار، ترکیب زیر از اسناد کاربر برای PS به اندازه کافی بزرگ را می توان معمولی در نظر گرفت:

     عمومی توضیحات عملکردی PS. توضیح مختصری از عملکرد PS می دهد. این برای کاربرانی در نظر گرفته شده است که باید تصمیم بگیرند که چقدر به این PS نیاز دارند.

     راهنمای نصب PS. برای مدیران سیستم طراحی شده است. باید با جزئیات نحوه نصب سیستم ها در یک محیط خاص را توضیح دهد. این باید حاوی شرحی از رسانه قابل خواندن توسط ماشین باشد که MS بر روی آن عرضه می شود، فایل هایی که MS را نشان می دهند و الزامات حداقل پیکربندی سخت افزاری.

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

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

     راهنمای مدیریت PS. برای مدیران سیستم طراحی شده است. این باید پیام‌هایی را که هنگام تعامل MS با سیستم‌های دیگر تولید می‌شوند و نحوه پاسخگویی به این پیام‌ها را شرح دهد. علاوه بر این، اگر MS از سخت افزار سیستم استفاده می کند، این سند ممکن است نحوه نگهداری آن سخت افزار را توضیح دهد.

     همانطور که قبلا ذکر شد (به سخنرانی 4 مراجعه کنید)، توسعه مستندات کاربر بلافاصله پس از ایجاد توضیحات خارجی آغاز می شود. کیفیت این مستندات می تواند به طور قابل توجهی موفقیت یک PS را تعیین کند. باید کاملاً ساده و کاربر پسند باشد (در غیر این صورت ، این PS به طور کلی ارزش ایجاد کردن را نداشت). بنابراین، اگرچه نسخه های پیش نویس (پیش نویس) اسناد کاربر توسط توسعه دهندگان اصلی PS ایجاد می شود، نویسندگان فنی حرفه ای اغلب در ایجاد نسخه های نهایی آنها دخالت دارند. علاوه بر این، برای اطمینان از کیفیت اسناد کاربر، تعدادی استاندارد توسعه داده شده است (برای مثال، را ببینید)، که روش توسعه این اسناد را تجویز می کند، الزامات هر نوع اسناد کاربر را تدوین می کند و ساختار و محتوای آنها را تعیین می کند. .

     13.3. اسناد پشتیبانی نرم افزار

     مستندات نگهداری PS (مستندات سیستم) PS را از نقطه نظر توسعه آن توصیف می کند. اگر PS شامل مطالعه نحوه چیدمان (طراحی) و نوسازی برنامه های آن باشد، این مستندات ضروری است. همانطور که اشاره شد، تعمیر و نگهداری یک توسعه مداوم است. بنابراین در صورت نیاز به ارتقای PS، تیم ویژه ای از توسعه دهندگان همراه درگیر این کار هستند. این تیم باید با همان اسنادی که فعالیت های تیم توسعه دهندگان اولیه (اصلی) PS را تعیین می کند، سر و کار داشته باشد، با تنها تفاوت این که این مستندات، به عنوان یک قاعده، متعلق به شخص دیگری برای تیم توسعه نگهدارنده خواهد بود ( توسط تیم دیگری ایجاد شده است). تیم توسعه نگهدارنده باید این مستندات را مطالعه کند تا ساختار و فرآیند توسعه سیستم عامل ارتقا یافته را درک کند و تغییرات لازم را در این مستندات انجام دهد و تا حد زیادی تکرار شود. فرآیندهای تکنولوژیکی، که با آن PS اصلی ساخته شد.

     اسناد پشتیبانی از PS را می توان به دو گروه تقسیم کرد:

     (1) اسنادی که ساختار برنامه ها و ساختارهای داده PS و فناوری توسعه آنها را تعریف می کند.

     (2) اسنادی برای کمک به ایجاد تغییرات در PS.

     مستندات گروه اول شامل اسناد نهایی هر مرحله تکنولوژیکی توسعه PS است. شامل اسناد زیر است:

     شرح خارجی PS (سند الزامات).

     شرح معماری سیستم PS، از جمله مشخصات خارجی هر یک از برنامه های آن.

     برای هر برنامه PS، توضیحی از ساختار ماژولار آن، شامل مشخصات خارجی برای هر ماژول موجود در آن.

     برای هر ماژول - مشخصات آن و شرح ساختار آن (توضیحات طراحی).

     متون ماژول را در زبان برنامه نویسی انتخاب شده (فهرست کد منبع برنامه).

     اسناد اعتبار سنجی سیستم عامل توصیف می کند که چگونه اعتبار هر برنامه سیستم عامل ایجاد شده است و چگونه اطلاعات اعتبار سنجی با الزامات سیستم عامل مرتبط است.

     اسناد تأیید نرم‌افزار عمدتاً شامل مستندات آزمایشی (طراحی آزمایش و شرح مجموعه آزمایشی) می‌شود، اما ممکن است نتایج انواع دیگر اعتبارسنجی نرم‌افزار مانند اثبات ویژگی‌های برنامه را نیز شامل شود.

     مستندات گروه دوم شامل

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

     یک مشکل معمول تعمیر و نگهداری برای یک PS این است که اطمینان حاصل شود که تمام نمایش‌های آن در زمان تغییر PS همگام هستند (ثابت می‌مانند). برای کمک به این امر، روابط و وابستگی‌های بین اسناد و قطعات آنها باید در پایگاه داده مدیریت پیکربندی ثبت شوند.

110. ادبیات برای سخنرانی 13.

111. 13.1. ایان سامرویل مهندسی نرم افزار. - شرکت انتشارات آدیسون-وسلی، 1992. پ.

     13.2. ANSI/IEEE Std 1063-1988، استاندارد IEEE برای اسناد کاربر نرم افزار.

     13.3. ANSI/IEEE Std 830-1984، IEEE Guide for Software Requirements Specification.

     13.4. ANSI/IEEE Std 1016-1987، شرح تمرین توصیه شده IEEE برای طراحی نرم افزار.

     13.5. ANSI/IEEE Std 1008-1987، استاندارد IEEE برای تست واحد نرم افزار.

     13.6. ANSI/IEEE Std 1012-1986، استاندارد IEEE برای برنامه های تأیید و اعتبارسنجی نرم افزار.

     13.7. ANSI/IEEE Std 983-1986، راهنمای IEEE برای برنامه ریزی تضمین کیفیت نرم افزار.

     13.8. ANSI/IEEE Std 829-1983، استاندارد IEEE برای اسناد تست نرم افزار.

113. سخنرانی 14

114. انتصاب گواهینامه نرم افزار. تست و ارزیابی کیفیت نرم افزار. انواع آزمون ها و روش های ارزیابی کیفیت نرم افزار.

116. 14.1. انتصاب گواهینامه نرم افزار.

117. گواهینامه PS یک تایید معتبر از کیفیت PS است. معمولاً برای صدور گواهینامه یک سیستم نرم افزاری یک کمیسیون نماینده (تصدیق) متشکل از کارشناسان، نمایندگان مشتری و نمایندگان توسعه دهنده ایجاد می شود. این کمیسیون به منظور کسب اطلاعات لازم برای ارزیابی کیفیت آن، آزمایشاتی را از PS انجام می دهد. تحت آزمایش PS، منظور ما فرآیند انجام مجموعه ای از اقدامات است که مناسب بودن PS را برای عملکرد موفقیت آمیز آن (کاربرد و نگهداری) مطابق با نیاز مشتری بررسی می کند. این مجموعه شامل بررسی کامل و صحت مستندات نرم افزار، مطالعه و بحث در مورد سایر ویژگی های آن و همچنین تست های لازم از برنامه های موجود در بسته نرم افزاری و به ویژه انطباق این برنامه ها با مستندات موجود می باشد.

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

119. 14.2. انواع تست نرم افزار.

120. انواع زیر از تست های PS شناخته شده است که به منظور صدور گواهینامه PS انجام می شود:

     تست جزء PS.

     تست های سیستم؛

     آزمون های پذیرش؛

     آزمایش های میدانی؛

     تست های صنعتی

     تست مؤلفه PS تأیید (آزمایش) عملکرد زیرسیستم های جداگانه PS است. فقط در موارد استثنایی انجام می شود تصمیم خاصکمیته صدور گواهینامه

     تست سیستم PS یک بررسی (آزمایش) عملکرد PS به عنوان یک کل است. ممکن است شامل همان انواع آزمایش باشد که در اشکال زدایی پیچیده PS (به سخنرانی 10 مراجعه کنید). در صورت شک در مورد کیفیت اشکال زدایی توسط توسعه دهندگان PS، با تصمیم کمیسیون گواهی انجام می شود.

     آزمون های پذیرش اصلی ترین نوع آزمون برای صدور گواهینامه PS هستند. با این آزمایشات است که کمیسیون صدور گواهینامه کار خود را آغاز می کند. این تست ها با مطالعه مستندات ارسال شده، از جمله مستندات مربوط به تست و اشکال زدایی PS آغاز می شود. اگر مستندات حاوی نتایج به اندازه کافی کامل از آزمایش نرم افزار نباشد، کمیته صدور گواهی ممکن است تصمیم بگیرد که آزمایش سیستم نرم افزار را انجام دهد یا با توصیه به توسعه دهنده برای انجام آزمایش اضافی (کامل تر) نرم افزار، فرآیند صدور گواهینامه را خاتمه دهد. علاوه بر این، در طول این آزمایش‌ها، می‌توان آزمایش‌های توسعه‌دهنده را به‌طور انتخابی نادیده گرفت، همچنین وظایف کنترل کاربر (به سخنرانی 10 مراجعه کنید) و آزمایش‌های اضافی توسط کمیسیون برای ارزیابی کیفیت PS تأیید شده آماده شده است.

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

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

122. 14.3. روش های ارزیابی کیفیت نرم افزار

123. ارزیابی کیفیت PS برای هر یک از معیارها به ارزیابی هر یک از معیارهای اولیه مرتبط با این معیار کیفیت PS، مطابق با مشخصات آنها، در مشخصات کیفی این PS کاهش می یابد. روش های ارزیابی کیفیت اولیه PS را می توان به چهار گروه تقسیم کرد:

     اندازه گیری مستقیم شاخص های اولیه کیفیت؛

     برنامه های پردازش و مستندسازی PS با ابزارهای نرم افزاری خاص (پردازنده)؛

     تست برنامه های PS;

     ارزیابی کارشناسی بر اساس مطالعه برنامه ها و مستندات PS.

     اندازه‌گیری مستقیم شاخص‌های اولیه کیفیت با شمارش تعداد واحدهای مشخصه، اشیاء، سازه‌ها و غیره در یک سند برنامه خاص و همچنین با اندازه‌گیری زمان کار دستگاه‌های مختلف و مقدار حافظه رایانه اشغال شده در زمان انجام می‌شود. انجام موارد آزمایشی به عنوان مثال، برخی از معیارهای کارایی حافظه ممکن است تعداد خطوط یک برنامه در یک زبان برنامه نویسی باشد، و برخی از معیارهای کارایی زمانی ممکن است زمان پاسخگویی به یک پرس و جو باشد. استفاده از هر شاخصی برای کیفیت اولیه ممکن است در مشخصات کیفی MS تعریف شود. روش اندازه گیری مستقیم شاخص های اولیه کیفیت را می توان با استفاده از آزمایش برنامه ترکیب کرد.

     ابزارهای نرم افزاری خاصی را می توان برای تعیین اینکه آیا یک MS دارای کیفیت اولیه خاصی است استفاده کرد. چنین ابزارهای نرم افزاری متون برنامه را پردازش می کنند یا مستندات برنامهبه منظور کنترل هر گونه کیفیت اولیه و یا به دست آوردن برخی از شاخص های این کیفیت اولیه. برای ارزیابی ساختار برنامه های PS، اگر به گویش ساختاری مناسب زبان برنامه نویسی پایه برنامه ریزی شده بودند، کافی است آنها را از یک مبدل برنامه ساخت یافته عبور دهید که کنترل نحوی و معنایی این گویش را انجام می دهد و متون زبان را ترجمه می کند. این برنامه ها به زبان ورودی مترجم پایه. با این حال، در حال حاضر فقط تعداد کمی از مواد اولیه با کیفیت را می توان به این روش کنترل کرد، و حتی در موارد نادر. در برخی موارد به جای ابزارهای نرم افزاری که کیفیت نرم افزار را کنترل می کنند، استفاده از ابزارهایی که نمایش برنامه ها یا مستندات برنامه را تغییر می دهند مفیدتر است. برای مثال، فرمت‌کننده برنامه‌ای است که متون برنامه را به شکلی قابل خواندن می‌آورد - پردازش متون برنامه‌های PS با چنین ابزاری می‌تواند به طور خودکار اطمینان حاصل کند که PS دارای کیفیت اولیه مناسبی است.

     تست برای ارزیابی برخی از موارد اولیه کیفیت PS استفاده می شود. چنین موارد اولیه در درجه اول شامل کامل بودن PS و همچنین دقت، پایداری، امنیت و سایر ویژگی های اولیه کیفی آن است. در برخی موارد، آزمایش در ترکیب با روش‌های دیگر برای ارزیابی کیفیت اولیه PS استفاده می‌شود. بنابراین، برای ارزیابی کیفیت مستندات در مورد استفاده از PS (اسناد P)، از آزمایش در ترکیب با ارزیابی تخصصی این مستندات استفاده می‌شود. اگر در حین اشکال زدایی پیچیده PS یک آزمایش به اندازه کافی کامل انجام شود، می توان از همان آزمایش ها در هنگام صدور گواهینامه PS استفاده کرد. در این مورد، کمیته صدور گواهینامه می تواند از پروتکل های آزمایشی انجام شده در حین اشکال زدایی پیچیده استفاده کند. با این حال، حتی در این مورد، انجام چند آزمایش جدید یا حداقل اجرای مجدد برخی از تست های قدیمی ضروری است. اگر آزمایش در حین اشکال زدایی پیچیده به اندازه کافی کامل نشده است، لازم است آزمایش کامل تری انجام شود. در این مورد، ممکن است تصمیمی برای انجام آزمایش‌های مؤلفه یا تست‌های سیستم PS و همچنین بازگرداندن PS برای بازبینی به توسعه‌دهندگان گرفته شود. بسیار مهم است که برای ارزیابی PS با توجه به معیار سهولت استفاده (در حین اشکال زدایی و صدور گواهینامه PS)، آزمایش کامل بر روی تست های تهیه شده بر اساس مستندات برنامه انجام شود و با توجه به به معیار قابلیت نگهداری - در آزمایش های تهیه شده برای هر یک از اسناد پیشنهادی برای نگهداری.

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

     ادبیات برای سخنرانی 14.

     14.2. V.V. Lipaev. تست برنامه - م.: رادیو و ارتباطات، 1986. - S. 231-245.

     14.3. دی ون تاسل. برنامه های سبک، توسعه، کارایی، اشکال زدایی و آزمایش. - م.: میر، 1985. - س 281-283.

     14.4. بی اشنایدرمن. روانشناسی برنامه نویسی. - م.: رادیو و ارتباطات، 1984. - S. 99-127.

125. سخنرانی 15. رویکرد شی به توسعه نرم افزار

127. 15.1. اشیاء و روابط در برنامه نویسی ماهیت رویکرد شیء به توسعه نرم افزار.

128. دنیای اطراف ما از اشیا و روابط بین آنها تشکیل شده است. یک شی شامل یک موجودیت است و دارای حالتی است که می تواند در طول زمان در نتیجه تأثیر سایر اشیاء که به نوعی با داده ها هستند تغییر کند. او ممکن است داشته باشد ساختار داخلی: متشکل از اشیاء دیگری که آنها نیز با یکدیگر رابطه دارند. بر این اساس، می توان یک ساختار سلسله مراتبی از جهان را از اشیاء ساخت. با این حال، برای هر در نظر گرفتن خاص از جهان اطراف ما، برخی از اشیاء غیر قابل تقسیم ("نقطه") در نظر گرفته می شوند، و بسته به اهداف در نظر گرفتن، چنین اشیاء (تقسیم ناپذیر) در سطوح مختلف سلسله مراتب را می توان پذیرفت. یک رابطه برخی از اشیاء را به هم متصل می کند: می توانیم در نظر بگیریم که اتحاد این اشیاء دارای خاصیتی است. اگر یک رابطه n شی را به هم متصل کند، چنین رابطه ای n مکان (n-ary) نامیده می شود. در هر مکان تداعی اشیایی که می توانند با هر رابطه خاصی به هم وصل شوند، ممکن است اشیاء مختلف، اما کاملاً مشخص وجود داشته باشد (در این مورد می گویند: اشیاء یک کلاس خاص). یک رابطه یک مکان خاصیت یک شی (کلاس مربوطه) نامیده می شود. وضعیت یک شی را می توان با مقدار ویژگی های این شی یا به طور ضمنی با ارزش ویژگی های اتحادیه های اشیاء که با یک رابطه معین به هم مرتبط شده اند مطالعه کرد.

     در فرآیند شناخت یا تغییر جهان پیرامون، ما همیشه یک مدل ساده شده از جهان (دنیای مدل) را در نظر می گیریم که در آن برخی از اشیاء و برخی از روابط جهان اطراف خود را در بر می گیریم و به عنوان یک قاعده، یک سطح از سلسله مراتب. هر شی که دارای ساختار درونی است می تواند جهان مدل خود را نشان دهد، از جمله اشیاء این ساختار و روابطی که آنها را به هم پیوند می دهد. بنابراین، جهان اطراف ما را می توان (در حدودی) به عنوان ساختار سلسله مراتبیجهان های مدل

     در حال حاضر، در فرآیند یادگیری یا تغییر دنیای اطراف ما، فناوری رایانه به طور گسترده ای برای پردازش انواع مختلف اطلاعات استفاده می شود. در این راستا از نمایش کامپیوتری (اطلاعاتی) اشیا و روابط استفاده می شود. هر شی را می توان به صورت اطلاعاتی با ساختار داده ای نشان داد که وضعیت آن را نشان می دهد. خصوصیات این شی را می توان مستقیماً به عنوان اجزای جداگانه این ساختار یا توسط توابع ویژه روی این ساختار داده تنظیم کرد. روابط N-ary برای N>1 را می توان به صورت فعال یا غیرفعال نشان داد. در شکل فعال خود، یک رابطه N-مکانی با یک قطعه برنامه نشان داده می شود که یا یک تابع مکان N (تعیین مقدار ویژگی اتحادیه متناظر از اشیاء) یا رویه ای را اجرا می کند که حالت های برخی از آنها را براساس آن تغییر می دهد. در مورد وضعیت بازنمایی اشیاء متصل شده توسط رابطه بازنمایی شده. در شکل منفعل، چنین رابطه ای را می توان با یک ساختار داده معین (که ممکن است شامل بازنمایی اشیاء مرتبط با این رابطه باشد) نشان داد، که بر اساس توافقات پذیرفته شده در مورد رویه های عمومی که مستقل از روابط خاص هستند تفسیر می شود (به عنوان مثال، یک پایگاه داده رابطه ای). در هر صورت، نمایش رابطه برخی از فعالیت های پردازش داده را تعریف می کند.

     هنگام کاوش در دنیای مدل، کاربر می تواند اطلاعات را از رایانه به روش های مختلف دریافت کند (یا می خواهد دریافت کند). در یک رویکرد، او ممکن است علاقه مند به کسب اطلاعات در مورد ویژگی های فردی اشیاء مورد علاقه خود یا نتایج هر گونه تعامل بین برخی از اشیاء باشد. برای انجام این کار، او دستور توسعه یک یا آن PS را می دهد که عملکردهای مورد علاقه او را انجام می دهد، یا برخی از سیستم های اطلاعاتی که قادر به صدور اطلاعات در مورد روابط مورد علاقه او با استفاده از پایگاه داده مناسب هستند. در دوره اولیه توسعه فناوری رایانه (با قدرت کافی رایانه ها) چنین رویکردی برای استفاده از رایانه کاملاً طبیعی بود. این او بود که رویکرد عملکردی (رابطه ای) را برای توسعه PS تحریک کرد که در سخنرانی های قبلی به تفصیل مورد بحث قرار گرفت. ماهیت این رویکرد استفاده سیستماتیک از تجزیه توابع (روابط) برای ساختن ساختار PS و متون برنامه موجود در آن است. در همان زمان، خود اشیاء، که توابع سفارش‌داده‌شده و اجرا شده روی آن‌ها اعمال می‌شد، به‌صورت تکه‌ای (تا حدی که برای انجام این کارکردها لازم است) و به شکلی مناسب برای اجرای این توابع ارائه شدند. بنابراین، یک نمایش کامپیوتری کامل و کافی از دنیای مدل مورد علاقه کاربر ارائه نشد: نمایش آن در PS مورد استفاده می تواند یک کار نسبتاً پر زحمت برای کاربر باشد، تلاشی برای گسترش کمی حجم و ماهیت اطلاعاتی در مورد دنیای مدل مورد علاقه کاربر. دریافتی از چنین پست هایی می تواند منجر به نوسازی جدی آنها شود. این رویکرد برای توسعه PS توسط اکثر زبان‌های برنامه‌نویسی مورد استفاده، از زبان‌های اسمبلی و زبان‌های رویه‌ای (FORTRAN، Pascal) تا زبان‌های تابعی (LISP) و زبان‌های برنامه‌نویسی منطقی پشتیبانی می‌شود. مقدمه).

     با رویکرد دیگری برای مطالعه دنیای مدل با استفاده از رایانه، کاربر ممکن است علاقه مند به مشاهده تغییر حالت اشیا در نتیجه تعامل آنها باشد. این امر مستلزم نمایش نسبتاً محکمی از شی مورد علاقه کاربر در رایانه است و مؤلفه‌های نرم‌افزاری که روابطی را که این شیء در آن مشارکت دارد پیاده‌سازی می‌کنند، به صراحت با آن مرتبط هستند. برای پیاده سازی این رویکرد، نیاز به ساخت ابزارهای نرم افزاری بود که فرآیندهای تعامل بین اشیا (دنیای مدل) را شبیه سازی کند. با کمک ابزارهای توسعه سنتی، این کار بسیار پر زحمتی بود. درست است، زبان های برنامه نویسی ظاهر شده اند که به طور خاص بر روی چنین مدل سازی متمرکز شده اند، اما این تنها تا حدی کار توسعه PS مورد نیاز را ساده می کند. کامل ترین راه حل این مشکل، رویکرد شی به توسعه PS است. ماهیت آن در استفاده سیستماتیک از تجزیه اشیاء در ساخت ساختار PS و متون برنامه های موجود در آن نهفته است. در همان زمان، توابع (روابط) انجام شده توسط چنین PS از طریق روابط اشیاء سطوح مختلف بیان شد، یعنی تجزیه آنها به طور قابل توجهی به تجزیه اشیاء بستگی دارد.

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

130. 15.2. اشیا و موضوعات در برنامه نویسی.

132. 15.3. رویکردهای عینی و ذهنی برای توسعه نرم افزار.

133. دکارت خاطرنشان کرد که مردم معمولاً دیدگاهی شی گرا از جهان دارند (ج).

     آنها معتقدند که طراحی شی گرا بر اساس اصول زیر است:

     برجسته کردن انتزاعات،

     محدودیت دسترسی،

     مدولار بودن،

     سلسله مراتب،

     تایپ کردن،

     موازی سازی،

     پایداری

     اما همه اینها را می توان در یک رویکرد کاربردی اعمال کرد.

     لازم است بین مزایا و معایب رویکرد شی عام و مورد خاص آن - رویکرد موضوع گرا تمایز قائل شد.

     مزایای رویکرد هدف کلی:

     نقشه برداری طبیعی از دنیای واقعی بر روی ساختار PS (ادراک طبیعی انسان از قابلیت های PS، بدون نیاز به "اختراع" ساختار PS، بلکه استفاده از قیاس های طبیعی).

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

     کاهش پیچیدگی توسعه نرم افزار از طریق استفاده از سطح جدیدی از انتزاعات (استفاده از سلسله مراتبی از انتزاعات "غیر برنامه ای" در توسعه نرم افزار: طبقه بندی اشیاء دنیای واقعی، روش قیاس در طبیعت) به عنوان سطح جدیدی از وراثت.

135. 15.4. یک رویکرد شی برای توسعه یک توصیف خارجی و معماری نرم افزار.

136. طراحی شی گرا روشی است که از تجزیه شی استفاده می کند. رویکرد شی گرا دارای سیستم قراردادهای خاص خود است و مجموعه ای غنی از منطق و مدل های فیزیکیبرای طراحی سیستم های با پیچیدگی بالا .

     تحلیل شی گرا (OOA) رویکرد شی را ارائه کرد. هدف OOA ایجاد مدل هایی است که با استفاده از رویکرد شی گرا به واقعیت نزدیک تر هستند. این روشی است که در آن الزامات بر اساس مفاهیم طبقات و اشیاء تشکیل دهنده واژگان حوزه موضوعی شکل می گیرد. .

     ویژگی های برنامه نویسی شی گرا

     اشیاء، کلاس ها، رفتار شیء، ویژگی ها، رویدادها.

138. ادبیات برای سخنرانی 15.

139. 15.1. K. Futi، N. سوزوکی. زبان های برنامه نویسی و مدارهای VLSI. - م.: میر، 1988. س 85-98.

     15.2. ایان سامرویل مهندسی نرم افزار. - شرکت انتشارات آدیسون-وسلی، 1992. P. ?-?

     15.3. جی. بوچ. طراحی شی گرا با نمونه هایی از کاربرد: per. از انگلیسی. - M.: کنکور، 1992.

     15.4. وی.ش.کافمن. زبانهای برنامه نویسی. مفاهیم و اصول. مسکو: رادیو و ارتباطات، 1993.

ماژول حرفه ای
"توسعه نرم افزار
ماژول های نرم افزاری
نرم افزار برای کامپیوتر
سیستم های"

MDK

برنامه نویسی سیستم
برنامه نویسی کاربردی

اهداف و اهداف ماژول

بدانید:
مراحل اصلی توسعه نرم افزار
امنیت؛
اصول اولیه فناوری سازه
و شی گرا
برنامه نويسي؛
اصول اولیه اشکال زدایی و آزمایش
محصولات نرم افزاری؛
روشها و ابزارهای توسعه فنی
مستندات.

اهداف و اهداف ماژول

قادر بودن به:
کد نرم افزار را توسعه دهید
ماژول ها در زبان های برنامه نویسی مدرن؛
یک برنامه با توجه به الگوریتم توسعه یافته ایجاد کنید
به عنوان یک ماژول جداگانه؛
اشکال زدایی و تست برنامه
سطح ماژول؛
تهیه مستندات نرم افزاری
منابع مالی؛
استفاده از ابزار برای
اتوماسیون اداری؛

اهداف و اهداف ماژول

داشتن تجربه عملی:
توسعه یک الگوریتم برای کار و
اجرا به وسیله
طراحی خودکار؛
توسعه کد محصول نرم افزاری
بر اساس مشخصات نهایی در سطح
مدول؛
استفاده از ابزار در
مرحله اشکال زدایی محصول نرم افزاری؛
تست نرم افزار
ماژول با توجه به یک سناریوی خاص.

شایستگی های حرفه ای

PC 1.1. توسعه مشخصات فردی را انجام دهید
جزء.
PC 1.2. توسعه کد محصول نرم افزار را انجام دهید
بر اساس مشخصات آماده در سطح ماژول.
PC 1.3. انجام اشکال زدایی ماژول های برنامه با
با استفاده از نرم افزارهای تخصصی
PC 1.4. انجام تست ماژول های نرم افزار.
PC 1.5. برای بهینه سازی کد برنامه ماژول.
PC 1.6. طراحی و اجزای فنی را توسعه دهید
مستندسازی با استفاده از زبان های گرافیکی
مشخصات فنی.

ارتباطات بین رشته ای

انفورماتیک و ICT;
فناوری اطلاعات؛
معماری سیستم های کامپیوتری;
مبانی برنامه نویسی؛
سیستم های عامل.

مراحل مطالعه

درس های شنیداری
کارگاه های آموزشی
کار مستقل
پروژه دوره
تمرین آموزشی
کارآموزی
آزمون مقدماتی (دفاع
نمونه کارها)

برنامه نویسی کاربردی

بخش 1. اصول اولیه توسعه برنامه

مبحث 1.1. مفاهیم اساسی
برنامه نویسی کاربردی

سوالات

طبقه بندی نرم افزار
چرخه عمر نرم افزار
مراحل توسعه برنامه
مستندات برنامه

برنامه نویسی چیست؟

برنامه نویسی - به معنای گسترده
همه فنی را نشان می دهد
عملیات مورد نیاز برای ایجاد
برنامه ها، از جمله تجزیه و تحلیل نیازمندی ها و
تمامی مراحل توسعه و اجرا AT
مفهوم محدود کدگذاری و
تست برنامه در داخل
چند پروژه خاص

نرم افزار چیست؟

نرم افزار (نرم افزار) (نرم افزار)
- اصطلاح عمومی برای
"نامشهود" (در مقابل فیزیکی)
اجزای یک سیستم کامپیوتری
در بیشتر موارد به آن اشاره دارد
برنامه ها اجرا می شوند
سیستم کامپیوتری به
بر تفاوت آنها با سخت افزار تاکید کنید
ابزار همان سیستم

چه کلاس هایی از نرم افزار
میدونی؟

سیستم: سیستم عامل; رانندگان
دستگاه ها؛ خدمات مختلف؛
برای توسعه دهندگان: محیط های برنامه نویسی.
مترجمان و مترجمان؛ ابزار CASE;
کتابخانه های برنامه؛
برای کاربران نهایی: متن
پردازنده ها؛ صفحات گسترده؛ گرافیکی
سردبیران؛ حل کننده مسائل ریاضی؛
سیستم های آموزش و کنترل؛
بازی های کامپیوتری؛ برنامه های کاربردی

کاربردی چیست
برنامه؟

برنامه کاربردی (برنامه
برنامه) - هر برنامه،
کمک به کار،
در این به رایانه اختصاص داده شده است
سازمان، و کمک مستقیم به
اجرای این وظیفه

چه چیزی را می توان سیستم نرم افزاری نامید؟

سیستم نرم افزاری نشان می دهد
مجموعه ای از راه حل های مجموعه است
متفاوت اما مرتبط
وظایف (OS، DBMS).
تخصصی تر
برنامه ها سیستم نامیده نمی شوند
(ویرایشگر متن، کامپایلر و ...)

چرخه عمر نرم افزار (چرخه حیات نرم افزار) کل دوره وجود
سیستم های نرم افزاری،
شروع از توسعه اولیه
مفهوم این سیستم و پایان دادن به آن
کهنگی

چرخه عمر نرم افزار

مراحل ایجاد برنامه ها

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

مراحل ایجاد برنامه ها

مشخصات خارجی
شامل تعریف مشخصات خارجی است، به عنوان مثال.
توصیف اطلاعات ورودی و خروجی،
اشکال ارائه آنها و روشهای پردازش اطلاعات.
به ترتیب زیر اجرا می شود:
الف) تعیین تکلیف برای توسعه برنامه جدید;
ب) ارزیابی اهداف به دست آمده توسعه یافته
محصول نرم افزاری
علاوه بر این، در صورت لزوم، مراحل 1-2 را می توان تا زمانی که
دستیابی به ظاهر رضایت بخشی از برنامه
سیستم با شرح عملکردهایی که انجام می دهد و برخی
وضوح اجرای عملکرد آن.

مراحل ایجاد برنامه ها

طراحی برنامه
مجموعه ای از کارها برای شکل دادن به شرح برنامه در حال انجام است.
داده های اولیه برای این مرحله الزامات تعیین شده است
در مشخصات توسعه یافته در مرحله قبل. پذیرفته شده
تصمیم گیری در مورد چگونگی برآوردن الزامات
مشخصات فنی. این مرحله از توسعه برنامه به دو مرحله تقسیم می شود:
الف) طراحی معماری یک توسعه است
توضیحات کلی برنامه این توضیحات شامل
اطلاعاتی درباره گزینه هاساخت سازه
محصول نرم افزاری (چه در قالب چند برنامه یا به صورت
چندین بخش از یک برنامه) و همچنین در مورد اصلی
الگوریتم ها و ساختارهای داده نتایج این کار است
نسخه نهایی معماری سیستم نرم افزار،
الزامات ساختار فردی اجزای نرم افزارو
سازماندهی فایل ها برای تبادل داده های بین برنامه ای؛
ب) طراحی کار در این مرحله، شرح معماری
برنامه تا حدی دقیق است که باعث می شود
کار ممکن بر روی اجرای آن (کد نویسی و مونتاژ). برای
این کار با کامپایل و بررسی مشخصات ماژول ها انجام می شود.
کامپایل توضیحات منطق ماژول ها، کامپایل نهایی
طرح اجرای برنامه

مراحل ایجاد برنامه ها

کدنویسی و تست
برای ماژول های فردی و
مجموعه ماژول های آماده تا
دریافت برنامه تمام شده
تست جامع
توسعه عملیاتی
مستندات
پذیرش و انواع دیگر
تست ها

مراحل ایجاد برنامه ها

تصحیح برنامه
بر اساس نتایج
تست های قبلی
تحویل به مشتری
تحویل نهایی در حال انجام است
محصول نرم افزاری به مشتری
همانند سازی

مراحل ایجاد برنامه ها

پشتیبانی برنامه
شامل کلیه عملیات فنی مورد نیاز است
برای استفاده از این برنامه در کار
حالت برنامه در حال اصلاح است
انجام اصلاحات در اسناد کاری،
بهبود برنامه و غیره
با توجه به مقیاس وسیع چنین
پشتیبانی عملیات تکراری است
فرآیندی که انجام آن مطلوب است
به همان اندازه بعد از انتشار نرم افزار
محصولات برای استفاده عمومی

سوالات

1. مفاهیم اولیه برنامه نویسی.
کلاس های نرم افزاری
2. چرخه عمر نرم افزار
اطمینان حاصل شود
3. مراحل ایجاد برنامه ها

مستندات برنامه

هر مرحله طراحی
در تهیه پیش نویس به اوج خود می رسد
اسناد مربوطه، بنابراین
یک عنصر مهم طراحی
نرم افزارهای کاربردی است
تهیه اسناد نرم افزاری

مستندات برنامه

مشخصات برنامه (برنامه
مشخصات) - شرح دقیق آن
نتیجه حاصل شود
با استفاده از برنامه این توصیف
باید دقیقا مشخص شود که چه چیزی
برنامه ای بسازید بدون اینکه مشخص کنید چگونه است
باید آن را انجام دهد.

مستندات برنامه

برای برنامه هایی که کار خود را با نتیجه ای به پایان می رساند، معمولاً کامپایل شده است
مشخصات ورودی/خروجی که توصیف می کنند
نگاشت دلخواه مجموعه ورودی
مقادیر را به مجموعه ای از مقادیر خروجی تبدیل می کند.
برای برنامه های چرخه ای (که در آن شماره
نقطه پایان را نشان می دهد)، توسعه می دهد
مشخصات که در آن تمرکز است
بر عملکردهای فردی تمرکز می کند،
اجرا شده توسط برنامه در طول دوره ای
عملیات

مستندات برنامه

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

مستندات برنامه

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

مستندات برنامه

مشخصات خارجی شامل
مشخصات ورودی و خروجی
داده ها، سازماندهی آنها، واکنش ها به
استثناها، تعریف،
یک شخص چه کاری انجام می دهد (با چه الگوریتم هایی
کار می کند و از کجا اطلاعات می گیرد)، و
آن ماشین

مستندات برنامه

مشخصات داخلی شامل
شرح داده های برنامه داخلی
(متغیرها به خصوص ساختار یافته) و
توضیحات الگوریتم های کل برنامه و آن
قطعات.
مشخصات داخلی به صورت وحدت داده شده است
با توضیحاتی در مورد معماری نرم افزار
ساختار پیچیده و درونی
ساختن نرم افزار مجزا
جزء.

مشق شب

فهرستی از انواع اسناد برای
اطمینان از چرخه عمر نرم افزار

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

اصول ایجاد برنامه ها در سطح سیستم

اصل پیچیدگی
این است که نرم افزار فراهم می کند
اتصال پردازش اطلاعات
عناصر جداگانه و برای کل حجم
داده ها به طور کلی در تمام مراحل پردازش؛
اصل وحدت اطلاعات، یعنی
در تمامی زیرسیستم ها، وسایل پشتیبانی و
اجزای نرم افزار استفاده مشترک
اصطلاحات، نمادها، کنوانسیون هاو
روش های ارائه؛

اصول ایجاد برنامه ها در سطح سیستم

اصل سازگاری این است که
زبان، نمادها، کدها و ابزارهای نرم افزاری
شرط توافق شده، ارائه
عملکرد مشترک همه
زیر سیستم ها و یک ساختار باز نگه می دارند
سیستم ها به عنوان یک کل؛
اصل عدم تغییر تعریف می کند
تغییر ناپذیری زیرسیستم ها و اجزای نرم افزار
به اطلاعات در حال پردازش، یعنی جهانی یا معمولی هستند.

فناوری های برنامه نویسی هستند
استراتژی های اثبات شده برای ایجاد
برنامه هایی که در قالب روش ارائه می شوند
با وجوه اطلاعاتی، توضیحات
رویه های طراحی و عملیات طراحی
یک فناوری ساختاری وجود دارد
برنامه نویسی، تکنولوژی
طراحی برنامه ها با منطق
ساختار داده، فناوری برنامه نویسی شی گرا،
تکنولوژی برنامه نویسی بصری

فن آوری ها و پارادایم های برنامه ریزی

پارادایم های برنامه نویسی (مفاهیم،
سیستم های اعتقادی) متفاوت هستند
رویکردهای نوشتن برنامه ها
چهار پارادایم اصلی وجود دارد
که بیشتر موارد امروزی را توصیف می کند
روش های برنامه نویسی: ضروری،
کاربردی، مبتنی بر قانون
و شی گرا.

فن آوری ها و پارادایم های برنامه ریزی

پارادایم ضروری
این مدل از ویژگی های سخت افزار پیروی می کند
یک کامپیوتر استاندارد که دستورالعمل ها را اجرا می کند
(فرمان) متوالی.
نوع اصلی انتزاع مورد استفاده در این
پارادایم، الگوریتم هستند. بر اساس آن توسعه یافته است
بسیاری از زبان های اپراتور گرا
برنامه نويسي.
یک برنامه در چنین زبانی از دنباله تشکیل شده است
اپراتورهایی که اجرای هر کدام مستلزم آن است
تغییر مقدار در یک یا چند سلول حافظه AT
به طور کلی، نحو چنین زبانی به صورت زیر است:
Operator_1:
Operator_2:
...

فن آوری ها و پارادایم های برنامه ریزی

پارادایم کاربردی
این پارادایم مبتنی بر در نظر گرفتن است
عملکردی که برنامه انجام می دهد.
سوال این است: چه عملکردی مورد نیاز است
اعمال به حالت اولیه ماشین (توسط
انتخاب یک مجموعه اولیه از متغیرها و
ترکیب آنها به روشی خاص) به
نتیجه دلخواه را بگیریم؟
زبان هایی که بر این دیدگاه تاکید دارند
محاسبات را کاربردی یا کاربردی می نامند
کاربردی نحو یک زبان مانند
قانون به این شکل است:
Function_n (... function_2 (function_1 (داده))...)

فن آوری ها و پارادایم های برنامه ریزی

پارادایم مبتنی بر قانون
زبان های مبتنی بر این بررسی پارادایم
وجود شرط مجاز لازم و در صورت آن
تشخیص ها اقدام مناسب را انجام می دهند.
اجرای یک برنامه به زبانی مشابه به این صورت است
اجرای برنامه ای که به زبان امری نوشته شده است.
با این حال، عبارات به ترتیبی که هستند اجرا نمی شوند
که در برنامه تعریف شده اند. دستور اجرا
شرایط مجاز را تعریف کنید نحو چنین زبانهایی
به شرح زیر است:
شرط مجاز_1 -> عمل_1 مجاز
شرط_2 -> اقدام__2
اجازه شرط_n -> عمل _n
گاهی اوقات قوانین به صورت «اگر عمل است» نوشته می شود
شرط مجاز» زمانی که عملی که باید انجام شود
در سمت چپ نوشته شده است

فن آوری ها و پارادایم های برنامه ریزی

پارادایم شی گرا
این مدل اشیاء داده پیچیده را می سازد.
برای عملیات روی آنها، برخی
مجموعه محدودی از روش ها ایجاد شده
اشیاء می توانند ویژگی های ساده تر را به ارث ببرند
اشیاء.
به دلیل این قابلیت، برنامه های شی گرا از سطح بالایی برخوردار هستند
اثربخشی برنامه ها
به زبان های امری نوشته شده است امکان پذیری
توسعه کلاس های مختلف که استفاده می کنند
مجموعه محدودی از اشیاء داده،
انعطاف پذیری و قابلیت اطمینان را فراهم می کند که
ویژگی یک زبان کاربردی

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

پخش و تفسیر برنامه ها

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

پخش و تفسیر برنامه ها

کامپایلر مترجمی است که منبع آن است
یک زبان سطح بالا و زبان شیء آن است
نزدیک به زبان ماشین یک کامپیوتر واقعی است. آی تی
یا زبان اسمبلی، یا برخی از انواع
زبان ماشین
پیوند دهنده (پیوند دهنده) مترجم است،
که زبان مبدأ آن شامل برنامه هایی در
زبان ماشین به شکل و جداول قابل جابجایی
داده هایی که نشان دهنده نقاطی هستند که
کد قابل جابجایی باید اصلاح شود،
قابل اجرا شدن زبان شیء شامل
آماده برای اجرای دستورالعمل های ماشین. وظیفه
لینکر برای ایجاد یک فایل اجرایی است
برنامه ای که از توافق شده استفاده می کند
آدرس ها همانطور که در جدول نشان داده شده است.

پخش و تفسیر برنامه ها

پیش پردازنده (macroprocessor) است
مترجمی که زبان مبدأ اوست
شکل توسعه یافته ای از
زبان سطح بالا (مانند جاوا یا
C++)، و زبان شی - استاندارد
نسخه این زبان برنامه شیء،
ایجاد شده توسط پیش پردازنده، آماده برای
ترجمه و اجرای معمول
پردازنده های استاندارد اصلی
زبان

پخش و تفسیر برنامه ها

تفسیر (شبیه سازی نرم افزاری)
این روش در هنگام استفاده از برنامه است
(مترجم) اجرا شد در
کامپیوتر سخت افزاری، ایجاد شد
کامپیوتر مجازی به زبان ماشین
سطح بالا. مفسر رمزگشایی و
هر دستور را در برنامه اجرا می کند
زبان سطح بالا در مربوطه
توالی و تولید خروجی
داده های حاصل از این تعریف شده است
برنامه

پخش و تفسیر برنامه ها

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

محیط‌ها و پیاده‌سازی زبان‌های برنامه‌نویسی

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

ورزش

انواع مختلف را فهرست و شرح دهید
محیط های برنامه نویسی

گزارش عملکرد آموزشی PM.01 "توسعه ماژول های نرم افزاری برای سیستم های کامپیوتری". موسسه آموزشی حرفه ای بودجه دولتی جمهوری کریمه "کالج پلی تکنیک فئودوسیا". 2015.

ابزار نرم افزاری "اقدامات روی ماتریس ها" طراحی و پیاده سازی شد. رابط کاربری گرافیکیدر محیط Microsoft Visual Studio Ultimate 2013 C#. محصول نرم افزاری به شما امکان می دهد ساختار و نحو زبان های برنامه نویسی جدید را مطالعه کنید.

کلمات کلیدی: نرم افزار، مشخصات فنی، تست عملکرد، تست ارزیابی، تست ساختاری، محیط توسعه، اشکال زدایی، الگوریتم، رابط

• مقدمه
• نتیجه گیری
• فهرست پیوندها
• ضمیمه

مقدمه

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

هدف تمرین این است:

تجمیع دانش نظری دریافتی در رشته های برنامه نویسی کاربردی، برنامه نویسی سیستمی، نظریه الگوریتم ها، مبانی برنامه نویسی و زبان های الگوریتمی"؛

جمع آوری، تجزیه و تحلیل و سنتز مواد برای تهیه گزارش عمل.

وظایف تمرین آموزشی توسط وظیفه فردی تعیین می شود:

تجزیه و تحلیل کار؛

انتخاب روش ها و توسعه الگوریتم های راه حل پایه.

انتخاب تکنولوژی و محیط برنامه نویسی؛

ساخت چارچوب برنامه و طراحی رابط کاربری؛

توسعه کد محصول نرم افزار بر اساس مشخصات نهایی.

انتخاب استراتژی تست و توسعه تست؛

استفاده از ابزارهای اشکال زدایی ارائه شده توسط رابط کاربری؛

انجام تست یک ماژول نرم افزار بر اساس یک سناریوی خاص.

تهیه مستندات نرم افزاری.

بر اساس نتایج تمرین، گزارشی تهیه شد. این گزارش مطابق با GOST 7.32-2001 تهیه شده است. گزارش تمرین شامل پنج بخش است.

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

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

بخش سوم استفاده از ابزارها در مرحله اشکال زدایی یک ماژول برنامه را توضیح می دهد.

بخش چهارم تست یک ماژول نرم افزاری را توصیف می کند، تست عملکردی، ساختاری و ارزیابی را مشخص می کند.

بخش پنجم به تهیه مستندات ابزار نرم افزار اختصاص دارد.

تست ابزار نرم افزار ماتریس

1. توسعه یک الگوریتم برای مشکل مجموعه و پیاده سازی آن توسط ابزارهای طراحی خودکار

1.1 تجزیه و تحلیل کار

نوشتن برنامه ای ضروری است که عملیات روی ماتریس ها را انجام دهد: ضرب، جمع، تفریق، جابجایی. برنامه باید ماتریس وارد شده به صورت دستی را در فرم حل کند. برای راحتی کاربر، برنامه باید یک رابط بصری داشته باشد.

1.2 انتخاب روش ها و توسعه الگوریتم های راه حل اساسی

این برنامه از الگوریتم کاری زیر استفاده می کند: برنامه دارای فرم هایی است که عناصر ماتریس در آنها وارد می شوند، عناصر از نوع String به Integer منتقل می شوند. سپس باید دکمه اقدام مربوطه را فشار دهید. الگوریتم حل ماتریس اجرا شده و نتیجه در عنصر DataGridView نمایش داده می شود.

برای ساخت فلوچارت از Microsoft Office Visio 2013 استفاده شد که با کمک آن می توانید نمودارها و نمودارهای مختلفی از جمله فلوچارت ایجاد کنید.

شکل 1.1 - بلوک دیاگرام خواندن و نوشتن داده ها از یک رکورد به یک آرایه

شکل 1.2 - بررسی در دسترس بودن برای ورودی

شکل 1.3 - بلوک دیاگرام وارد کردن داده ها در جعبه متن و مقایسه با آرایه موجود

شکل 1.4 - فراخوانی روش Vizov با پارامترها

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

ماشین حساب ماتریس به زبان برنامه نویسی سی شارپ در محیط برنامه نویسی Microsoft Visual Studio Ultimate 2013 پیاده سازی شده است.انتخاب زبان سی شارپ به این دلیل است که یک زبان برنامه نویسی شی گرا مدرن و محبوب است و Microsoft Visual Studio Ultimate محیط 2013 ابزار قدرتمندی است که به شما امکان می دهد به سرعت برنامه ای را ایجاد کنید که دارای رابط پنجره گرافیکی باشد.

طرح پنجره در شکل 2.1 نشان داده شده است

شکل 2.1 - رابط پنجره برنامه آینده

3 عنصر DataGridView در فرم وجود دارد که ماتریس ها در آنها قرار می گیرند. همچنین 4 دکمه برای انجام اقدامات روی ماتریس ها.

3. استفاده از ابزارها در مرحله اشکال زدایی ماژول نرم افزار

هنگام اشکال زدایی یک محصول نرم افزاری، از دستور منوی Debug استفاده کنید (شکل 3.1). تعدادی دستور در منوی اشکال زدایی وجود دارد که هدف آنها در زیر ارائه شده است.

شکل 3.1 - پنجره منوی اشکال زدایی

Windows - پنجره Breakpoints را در چارچوب باز می کند که به شما امکان دسترسی به تمام نقاط شکست در این راه حل را می دهد. پنجره خروجی را در چارچوب نمایش می دهد.

پنجره خروجی یک گزارش در حال اجرا از بسیاری از پیام های تولید شده توسط فریمورک، کامپایلر و دیباگر است. بنابراین، این اطلاعات نه تنها برای جلسه اشکال زدایی اعمال می شود، بلکه پنجره تفسیر را در محیط یکپارچه باز می کند، که به شما امکان می دهد دستورات را اجرا کنید: شروع اشکال زدایی - برنامه را در حالت اشکال زدایی شروع می کند.

پیوست به پردازش - به شما امکان می دهد تا اشکال زدا را به یک فرآیند در حال اجرا (فایل اجرایی) متصل کنید. به عنوان مثال، اگر یک برنامه بدون اشکال زدایی اجرا می شود، سپس می توانید به این فرآیند در حال اجرا متصل شده و اشکال زدایی را شروع کنید.

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

مرحله به مرحله - برنامه را در حالت اشکال زدایی شروع می کند. برای اکثر پروژه ها، انتخاب دستور step-in به معنای فراخوانی دیباگر در اولین خط اجرایی برنامه است. بنابراین، می توانید برنامه را از خط اول وارد کنید.

راه رفتن در اطراف - هنگامی که در جلسه اشکال زدایی نیستید، دستور walk around step به سادگی برنامه را درست مانند دکمه اجرا اجرا می کند.

نقطه انفصال - یک نقطه شکست در خط فعلی (فعال) کد ویرایشگر متن را فعال یا غیرفعال می کند. اگر چارچوب پنجره کد فعال نداشته باشد، این گزینه خاکستری می شود.

ایجاد نقطه انفصال - کادر محاوره ای را فعال می کند ایجاد نقطه انفصال که به شما امکان می دهد نام تابعی را که می خواهید برای آن نقطه انفصال ایجاد کنید مشخص کنید.

حذف تمام نقاط شکست - تمام نقاط شکست را از راه حل فعلی حذف می کند.

پاک کردن تمام نکات داده - غیرفعال کردن (بدون حذف) تمام نقاط شکست راه حل فعلی.

گزینه ها و تنظیمات - هنگامی که استثناها از مرز دامنه برنامه یا مرزی بین کد مدیریت شده و کد بومی عبور می کنند، اجرا را قطع می کند.

4. تست واحد نرم افزار با توجه به یک سناریوی خاص

تست ارزیابی که به آن "تست کل سیستم" نیز گفته می شود، هدف آن آزمایش برنامه در برابر الزامات اساسی است. این مرحله از تست به ویژه برای محصولات نرم افزاری مهم است. شامل انواع زیر است:

تست قابلیت استفاده - تأیید سازگاری انطباق محصول نرم افزاری و مستندات آن با مفاد اصلی شرایط مرجع.

آزمایش بر روی حجم محدود - بررسی عملکرد برنامه در بیشترین مقدار ممکن داده، به عنوان مثال، حجم متون، جداول، تعداد زیادی فایل و غیره؛

آزمایش بر روی بارهای محدود - بررسی اجرای برنامه برای امکان پردازش حجم زیادی از داده های دریافتی در مدت زمان کوتاه.

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

تست امنیت - بررسی حفاظت، به عنوان مثال، در برابر دسترسی غیرمجاز به اطلاعات؛

تست عملکرد - تعیین پهنای باند برای یک پیکربندی و بار مشخص.

تست مورد نیاز حافظه - تعیین نیاز واقعی به RAM و حافظه خارجی.

تست پیکربندی سخت افزار - بررسی عملکرد نرم افزار بر روی سخت افزارهای مختلف.

تست سازگاری - بررسی تداوم نسخه ها: در مواردی که نسخه بعدی سیستم فرمت داده ها را تغییر می دهد، باید convector های خاصی را ارائه دهد که توانایی کار با فایل های ایجاد شده توسط نسخه قبلی سیستم را فراهم کند.

تست راحتی نصب - تأیید راحتی نصب؛

تست قابلیت اطمینان - تست قابلیت اطمینان با استفاده از مدل های ریاضی.

تست بازیابی - بررسی بازیابی نرم افزار، به عنوان مثال، یک سیستم شامل پایگاه داده، پس از خرابی سخت افزار و برنامه؛

تست قابلیت سرویس - بررسی امکانات موجود در نرم افزار؛

آزمایش اسناد - بررسی کامل اسناد، به عنوان مثال، اگر مستندات شامل نمونه هایی باشد، باید همه آنها را امتحان کرد.

روش تست - بررسی فرآیندهای دستی فرض شده در سیستم.

طبیعتاً هدف از همه این بررسی‌ها، یافتن مغایرت با شرایط است. اعتقاد بر این است که تنها پس از تکمیل انواع تست ها، محصول نرم افزاری می تواند به کاربر یا برای پیاده سازی ارائه شود. با این حال، در عمل، همه انواع تست های ارزیابی معمولا انجام نمی شوند، زیرا بسیار پرهزینه و وقت گیر هستند. به عنوان یک قاعده، برای هر نوع نرم افزار، آن دسته از تست هایی انجام می شود که برای آن مهم ترین هستند. بنابراین پایگاه‌های داده لزوماً در حداکثر حجم و سیستم‌های بلادرنگ - در حداکثر بار آزمایش می‌شوند.

5. اسناد برای نرم افزار

محصول نرم افزاری ایجاد شده برای انجام عملیات حسابی بر روی ماتریس ها طراحی شده است.

برای اجرای برنامه باید برنامه را اجرا کنید.

برای ایجاد ماتریس، باید ابعاد ماتریس را وارد کرده و روی دکمه "ساخت" کلیک کنید. سپس داده ها را وارد ماتریس کرده و اقدام مورد نظر را انتخاب کنید.

شکل 5.1 - برنامه در حال اجرا

برنامه دارد رابط کاربر پسندو توانایی حل آسان ماتریس هایی با ابعاد دلخواه را فراهم می کند.

در طول تمرین آموزشی، یک کار فردی تکمیل شد:

تجزیه و تحلیل حوزه موضوعی انجام شد.

الگوریتم راه حل انتخاب شده و توسعه یافته اثبات شده است.

تکنولوژی تعریف شده و محیط برنامه نویسی انتخاب می شود.

چارچوب برنامه ساخته شد و رابط کاربری طراحی شد.

کد ماژول برنامه توسعه یافته است.

ابزارهای اشکال زدایی مورد استفاده در طول آزمایش شرح داده شده است.

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

یک آیتم منو با توضیح مختصری از نحوه کار با برنامه اضافه کرد.

اهداف تعیین شده محقق شده است.

فهرست پیوندها

1 انجمن سایبری [منبع الکترونیکی]: http://CyberForum.ru

2 توسعه دهنده مایکروسافت [اسناد رسمی مایکروسافت در سی شارپ] ttps://msdn.microsoft.com

3 http://programming-edu.ru/ وبلاگ راهنما برای مبتدیان C#

ضمیمه

کد برنامه

با استفاده از System.Linq؛

با استفاده از System.Text.

با استفاده از System.Windows.Forms.

ماتریس فضای نام

int[,] a=new int;

//گذر از مقادیر

مجموعه خالی عمومی (int i، int j، int znach)

a = znach;

//افزودن

عملگر عمومی استاتیک MyMatrix +(MyMatrix matrix1، MyMatrix matrix2)

برای (int i = 0; i< 3; i++)

برای (int j = 0; j< 3; j++)

NewMatrix.a = matrix1.a + matrix2.a;

NewMatrix را برگردانید.

//ماتریس خروجی

رشته عمومی ویژوال (int i، int j)

بازگشت a.ToString();

//خروجی همه به یکباره.Xd

عمومی DataGridView FullVisual (DataGridView dt)

برای (int i = 0; i< 3; i++)

برای (int j = 0; j< 3; j++)

dt.Rows[j].Cells[i].Value = a;

//منها کردن

عملگر استاتیک عمومی MyMatrix - (MyMatrix matrix1، MyMatrix matrix2)

MyMatrix NewMatrix = جدید MyMatrix();

برای (int i = 0; i< 3; i++)

برای (int j = 0; j< 3; j++)

NewMatrix.a = matrix1.a - matrix2.a;

NewMatrix را برگردانید.

//تقویل

عمومی MyMatrix Trans()

MyMatrix NewMatrix = جدید MyMatrix();

برای (int i = 0; i< 3; i++)

برای (int j = 0; j< 3; j++)

NewMatrix.a = a;

NewMatrix را برگردانید.

//ضرب

عملگر عمومی استاتیک MyMatrix *(MyMatrix matrix1، MyMatrix matrix2)

MyMatrix NewMatrix = جدید MyMatrix();

برای (int i = 0; i< 3; i++)

برای (int k = 0; k< 3; k++)

برای (int j = 0; j< 3; j++)

//a += matrix1.a * matrix2.a;

NewMatrix.a+= matrix1.a * matrix2.a;

//NewMatrix.a = a;

NewMatrix را برگردانید.

//پر كردن

Public void Fill (شبکه DataGridView)

برای (int i = 0; i< 3; i++)

برای (int j = 0; j< 3; j++)

a = Convert.ToInt32(grid.Rows[j].Cells[i].Value);

با استفاده از System.Collections.Generic.

با استفاده از System.ComponentModel.

با استفاده از System.Data.

با استفاده از System.Drawing.

با استفاده از System.Linq؛

با استفاده از System.Text.

با استفاده از System.Windows.Forms.

ماتریس فضای نام

کلاس جزئی عمومی Form1: Form

InitializeComponent();

Private void Form1_Load (فرستنده شی، EventArgs e)

برای (int i = 0; i< 3; i++)

dataGridView1.Rows.Add();

dataGridView2.Rows.Add();

dataGridView3.Rows.Add();

//dataGridView1.Rows[i].Cells.Value = i.ToString();

دکمه خلاء خصوصی 1_کلیک کنید (فرستنده شی، EventArgs e)

MyMatrix matrix3;

matrix3 = (matrix1 + matrix2);

دکمه خلاء خصوصی2_کلیک کنید(فرستنده شی، EventArgs e)

MyMatrix matrix1 = جدید MyMatrix();

MyMatrix matrix2 = new MyMatrix();

MyMatrix matrix3;

matrix1.Fill(dataGridView1);

matrix2.Fill(dataGridView2);

matrix3 = (matrix1 - matrix2);

matrix3.FullVisual(dataGridView3);

دکمه خصوصی خالی3_کلیک کنید(فرستنده شی، EventArgs e)

MyMatrix matrix1 = جدید MyMatrix();

MyMatrix matrix3;

matrix1.Fill(dataGridView1);

matrix3 = matrix1.Trans();

matrix3.FullVisual(dataGridView3);

دکمه خصوصی خالی4_کلیک کنید(فرستنده شی، EventArgs e)

MyMatrix matrix1 = جدید MyMatrix();

MyMatrix matrix2 = new MyMatrix();

MyMatrix matrix3;

matrix1.Fill(dataGridView1);

matrix2.Fill(dataGridView2);

matrix3 = (matrix1 * matrix2);

matrix3.FullVisual(dataGridView3);

اسناد مشابه

توسعه یک الگوریتم برای کار و پیاده سازی با استفاده از طراحی به کمک کامپیوتر. طراحی یک محصول نرم افزاری بر اساس مشخصات نهایی در سطح ماژول، آزمایش آن، با استفاده از ابزار.

تست، اضافه شده در 05/01/2015


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

پایان نامه، اضافه شده در 1390/06/17


نمودار ساختاری یک ماژول نرم افزاری. توسعه طرح ماژول نرم افزار و رابط کاربری. پیاده سازی ماژول برنامه: کد برنامه; شرح عملگرها و توابع مورد استفاده مشاهده فرم کاربر با ماتریس پر شده.

مقاله ترم، اضافه شده 09/01/2010


نمودار ساختاری یک ماژول نرم افزاری. یافتن مجموع عناصر بالای مورب اصلی. پیاده سازی ماژول برنامه: کد برنامه; شرح عملگرها و توابع مورد استفاده ویژگی های تست ماژول نرم افزار.

مقاله ترم، اضافه شده 09/01/2010


تجهیز شرکت به نرم افزار سیستمی که برای سازماندهی فرآیند تولید استفاده می شود. طراحی، پیاده سازی و بهره برداری از سیستم و نرم افزارهای کاربردی. تست و رفع اشکال محصول نرم افزاری.

گزارش تمرین، اضافه شده در 1393/12/29


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

مقاله ترم، اضافه شده در 1395/12/21


ویژگی های محیط برنامه نویسی دلفی هنگام توسعه یک برنامه با رابط بصری. توسعه مشخصات نرم افزار و بر اساس آن کد محصول نرم افزار. اشکال زدایی برنامه با "ردیابی"، تست و بهینه سازی آن.

مقاله ترم، اضافه شده 12/07/2016


طراحی ماژول برنامه: مجموعه ای از مواد منبع؛ شرح داده های ورودی و خروجی؛ انتخاب نرم افزار شرح انواع داده ها و پیاده سازی رابط برنامه. تست ماژول نرم افزار و کمک به توسعه سیستم.

مقاله ترم، اضافه شده در 2014/08/18


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

مقاله ترم، اضافه شده در 12/11/2010


ساختار عملکردی - مدولار نرم افزار کنترلر اینترکام. مدار الکترونیکی قفل الکترونیکی، میکروفون و ماژول بلندگو. انتخاب منبع تغذیه ترکیبی توسعه یک ماژول نرم افزاری برنامه کنترل اینترکام.

گذار از غیررسمی به رسمی اساساً غیررسمی است.

سخنرانی 8

توسعه ماژول نرم افزار

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

8.1. روش توسعه یک ماژول نرم افزاری

هنگام توسعه یک ماژول نرم افزاری، توصیه می شود از ترتیب زیر پیروی کنید:

مطالعه و تایید مشخصات ماژول، انتخاب زبان برنامه نویسی؛

انتخاب الگوریتم و ساختار داده؛

برنامه نویسی (کد نویسی) ماژول؛

صیقل دادن متن ماژول؛

بررسی ماژول

تدوین ماژول

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

در مرحله دوم توسعه یک ماژول نرم‌افزاری، لازم است بفهمیم که آیا الگوریتم‌هایی از قبل برای حل مشکل مطرح شده یا نزدیک به آن شناخته شده‌اند یا خیر. و اگر الگوریتم مناسبی وجود دارد، بهتر است از آن استفاده کنید. انتخاب ساختارهای داده مناسبی که در زمانی که ماژول وظایف خود را انجام می دهد، تا حد زیادی منطق و شاخص های کیفیت ماژول در حال توسعه را تعیین می کند، بنابراین باید تصمیم بسیار مهمی در نظر گرفته شود.

در مرحله سوم، متن ماژول به زبان برنامه نویسی انتخاب شده ساخته می شود. فراوانی انواع جزئیاتی که باید هنگام اجرای توابع مشخص شده در مشخصات ماژول در نظر گرفته شود، می تواند به راحتی منجر به ایجاد یک متن بسیار گیج کننده حاوی خطاها و نادرستی های زیادی شود. یافتن خطاها در چنین ماژولی و ایجاد تغییرات مورد نیاز در آن می تواند کاری بسیار زمان بر باشد. بنابراین، استفاده از یک رشته برنامه نویسی توجیه شده و عملاً اثبات شده برای ساخت متن ماژول بسیار مهم است. برای اولین بار، Dijkstra توجه خود را به این موضوع جلب کرد و اصول اولیه برنامه نویسی ساخت یافته را تدوین و اثبات کرد. بسیاری از رشته های برنامه نویسی که به طور گسترده در عمل مورد استفاده قرار می گیرند بر اساس این اصول هستند. متداول ترین آن، رشته تمرینی است که در بخش های 8.2 و 8.3 به تفصیل مورد بحث قرار گرفته است.

مرحله بعدی در توسعه ماژول مربوط به رساندن متن ماژول به فرم نهایی مطابق با مشخصات کیفیت PS است. هنگام برنامه نویسی یک ماژول، توسعه دهنده بر اجرای صحیح عملکردهای ماژول تمرکز می کند، نظرات را ناتمام می گذارد و اجازه می دهد برخی از موارد مورد نیاز برای سبک برنامه را نقض کند. هنگام صیقل دادن متن ماژول، باید نظرات موجود در متن را ویرایش کند و احتمالاً در آن گنجانده شود. نظرات اضافیبه منظور ارائه کیفیت اولیه مورد نیاز. برای همین منظور، متن برنامه برای برآوردن نیازهای سبکی ویرایش می شود.

مرحله تأیید ماژول، بررسی دستی منطق داخلی ماژول قبل از اشکال زدایی (با استفاده از اجرای آن در رایانه) است، که اصل کلی فرموله شده برای فناوری برنامه نویسی مورد بحث را در مورد نیاز به کنترل تصمیمات اتخاذ شده در هر مرحله از برنامه پیاده سازی می کند. توسعه PS (به سخنرانی 3 مراجعه کنید). روشهای اعتبارسنجی ماژول در بخش 8.4 مورد بحث قرار گرفته است.

در نهایت، آخرین مرحله از توسعه یک ماژول به معنای تکمیل اعتبارسنجی ماژول (با استفاده از کامپایلر) و حرکت به سمت فرآیند اشکال زدایی ماژول است.

8.2. برنامه ریزی ساختاری

هنگام برنامه نویسی یک ماژول، باید در نظر داشت که این برنامه باید نه تنها برای یک کامپیوتر، بلکه برای یک شخص نیز قابل درک باشد: هم توسعه دهنده ماژول، و هم افرادی که ماژول را بررسی می کنند، و هم آزمایش کنندگان تست هایی را برای رفع اشکال ماژول آماده می کنند. و نگهدارنده‌های PS که تغییرات لازم را در ماژول ایجاد می‌کنند مجبور می‌شوند به طور مکرر منطق ماژول را تجزیه کنند. در زبان های برنامه نویسی مدرن، ابزارهای کافی برای اشتباه گرفتن این منطق وجود دارد، در نتیجه درک ماژول برای شخص دشوار می شود و در نتیجه نگهداری آن غیر قابل اعتماد یا دشوار می شود. بنابراین باید در انتخاب ابزارهای زبانی مناسب و پیروی از یک رشته برنامه نویسی دقت کرد. در این راستا، Dijkstra پیشنهاد ساخت یک برنامه را به عنوان ترکیبی از چندین نوع ساختار کنترلی (ساختار) داد که می تواند درک منطق برنامه را تا حد زیادی افزایش دهد. برنامه نویسی با استفاده از چنین ساختارهایی نامیده می شود ساختاری.

برنج. 8.1. ساختارهای کنترل اولیه برنامه نویسی ساخت یافته

ساختارهای اصلی برنامه نویسی ساخت یافته عبارتند از: دنبال کردن، شاخه و تکرار (شکل 8.1 را ببینید). اجزای این ساختارها عملگرهای تعمیم‌یافته (گره‌های پردازش) S، S1، S2 و یک شرط (گزاره) P هستند. فراخوانی ها)، یا یک قطعه برنامه، که ترکیبی از ساختارهای کنترل اصلی برنامه نویسی ساخت یافته است. ضروری است که هر یک از این ساختارها از نظر کنترل فقط یک ورودی و یک خروجی داشته باشند. بنابراین عملگر تعمیم یافته نیز تنها یک ورودی و یک خروجی دارد.

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

برنامه نویسی ساختاریافته گاهی اوقات به عنوان "برنامه نویسی بدون GO TO" شناخته می شود. با این حال، نکته در اینجا عبارت GO TO نیست، بلکه استفاده بی رویه از آن است. اغلب، هنگام اجرای برنامه نویسی ساختاری در برخی از زبان های برنامه نویسی (به عنوان مثال، در FORTRAN)، از عملگر انتقال (GO TO) برای اجرای سازه های ساختاری استفاده می شود که اصول برنامه نویسی ساختاری را نقض نمی کند. این دستورات پرش "غیر ساختاری" هستند که برنامه را گیج می کنند، به خصوص پرش به دستوری که در متن ماژول بالا (قبل از) اجرای دستور پرش قرار دارد. با این حال، تلاش برای اجتناب از دستور پرش در برخی موارد ساده می‌تواند منجر به برنامه‌های ساختارمندی شود که بیش از حد دست و پا گیر هستند، که وضوح آنها را بهبود نمی‌بخشد و خطر خطاهای اضافی در متن ماژول را در بر می‌گیرد. بنابراین، ممکن است توصیه شود تا جایی که امکان دارد از استفاده از دستور jump اجتناب کنید، اما نه به قیمت وضوح برنامه.

موارد مفید استفاده از عملگر انتقال شامل خروج از یک حلقه یا رویه در یک شرایط خاص است که "به موقع" کار این حلقه یا این رویه را خاتمه می دهد، به عنوان مثال، پایان دادن به کار برخی از واحدهای ساختاری (اپراتور عمومی) و در نتیجه تنها به صورت محلی نقض می شود. ساختار برنامه مشکلات بزرگ (و پیچیدگی سازه) ناشی از اجرای سازه ای پاسخ به موقعیت های استثنایی (اغلب اشتباه) است، زیرا این امر نه تنها نیاز به خروج زودهنگام از واحد سازه، بلکه نیاز به پردازش (استخراج) لازم از این وضعیت دارد. (مثلاً صدور اطلاعات تشخیصی مناسب). کنترل کننده استثنا را می توان در هر سطحی از ساختار برنامه قرار داد و از سطوح مختلف پایین تر قابل دسترسی است. از دیدگاه تکنولوژیکی، اجرای «غیر ساختاری» زیر پاسخ به موقعیت‌های استثنایی کاملاً قابل قبول است. کنترل کننده های استثنایی در انتهای یک یا آن واحد ساختاری قرار می گیرند و هر یک از این دسته ها به گونه ای برنامه ریزی می شود که پس از اتمام کار خود از واحد سازه ای که در انتهای آن قرار گرفته است خارج شود. چنین کنترل کننده ای توسط عملگر پرش از واحد ساختاری داده شده (شامل هر واحد ساختاری تودرتو) فراخوانی می شود.

8.3. جزئیات گام به گام و مفهوم شبه کد.

برنامه نویسی ساختاریافته توصیه هایی در مورد اینکه متن یک ماژول چگونه باید باشد را ارائه می دهد. این سوال مطرح می شود که یک برنامه نویس چگونه باید برای ساخت چنین متنی عمل کند. اغلب برنامه نویسی یک ماژول با ساخت بلوک دیاگرام آن آغاز می شود که به طور کلی منطق عملکرد آن را توصیف می کند. با این حال، فناوری برنامه نویسی مدرن انجام این کار را بدون پشتیبانی کامپیوتری مناسب توصیه نمی کند. اگرچه فلوچارت ها نمایش بسیار بصری منطق یک ماژول را ارائه می دهند، اما زمانی که آنها به صورت دستی در یک زبان برنامه نویسی کدگذاری می شوند، منبع بسیار خاصی از خطاها ایجاد می شود: نگاشت ساختارهای دو بعدی، مانند فلوچارت ها، بر روی متن خطی نشان دهنده یک ماژول، حاوی خطر تحریف منطق ماژول است، به ویژه از آنجا که حفظ سطح بالای توجه هنگام بازبینی مجدد آن از نظر روانی بسیار دشوار است. یک استثنا ممکن است موردی باشد که از یک ویرایشگر گرافیکی برای ساختن فلوچارت ها استفاده شود و آنها به گونه ای رسمی شوند که متن در یک زبان برنامه نویسی به طور خودکار از آنها تولید شود (به عنوان مثال، این کار در فناوری R انجام می شود).

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

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

پالایش گام به گام با استفاده از یک زبان تا حدی رسمی شده برای نمایش توضیحات مشخص شده همراه است که به نام شبه کد. این زبان اجازه می دهد تا از تمام ساختارهای برنامه نویسی ساخت یافته که رسمی شده اند، همراه با قطعات زبان طبیعی غیررسمی برای نمایش عبارات و شرایط عمومی استفاده شود. قطعات مربوطه در زبان برنامه نویسی پایه نیز می توانند به عنوان عملگرها و شرایط تعمیم یافته مشخص شوند.

· شروع ماژول در زبان پایه، یعنی اولین جمله یا عنوان (مشخصات) این ماژول.

بخش (مجموعه) توضیحات در زبان پایه و به جای توضیحات رویه ها و عملکردها - فقط طراحی خارجی آنها.

· تعیین غیررسمی دنباله اپراتورهای بدنه ماژول به عنوان یک اپراتور تعمیم یافته (به زیر مراجعه کنید)، و همچنین تعیین غیررسمی بدنه هر روش یا شرح عملکرد به عنوان یک عملگر تعمیم یافته.

· آخرین جمله (پایان) ماژول در زبان پایه.

طراحی خارجی شرح یک رویه یا عملکرد به روشی مشابه ارائه شده است. با این حال، با پیروی از Dijkstra، بهتر است بخش توضیحات در اینجا نیز با یک نماد غیررسمی ارائه شود و آن را به عنوان یک توضیح جداگانه شرح دهیم.

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

برنج. 8.2. ساختارهای اساسی برنامه نویسی ساخت یافته در شبه کد.

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

خروج از تکرار (حلقه): روش خروج (عملکرد):