تطوير وحدة برمجية. برمجة منظمة. مساء 01. تطوير وحدات البرامج لأنظمة الكمبيوتر تطوير البرامج النمطية لوحدات البرامج
شرح لبرنامج عمل الوحدة المهنية
اسم الوحدة المهنية
1. نطاق البرنامج
يعد برنامج عمل الوحدة المهنية جزءًا من البرنامج التدريبي للمتخصصين من المستوى المتوسط وفقًا للمعيار التعليمي الفيدرالي للولاية في SPO 09.02.07 أنظمة المعلومات والبرمجة ، والتي تعد جزءًا من مجموعة التخصصات الموسعة 09.00.00 المعلوماتية وتكنولوجيا الكمبيوتر
والكفاءات المهنية ذات الصلة (الكمبيوتر الشخصي):
يمكن استخدام برنامج عمل الوحدة المهنية كجزء من تدريب المتخصصين في دورة "تطوير وحدات البرامج لأنظمة الكمبيوتر" على أساس التعليم العام الأساسي. لا يتطلب خبرة عمل.
تم وضع برنامج العمل بدوام كامل ، بدوام جزئي ، بدوام جزئي مع عناصر من تقنيات التعليم عن بعد ، وأشكال التعليم.
2. أهداف وغايات الوحدة - متطلبات نتائج إتقان الوحدة
كنتيجة لإتقان الجزء الإجباري من الوحدة ، يجب أن يتمتع الطالب بخبرة عملية:
تطوير خوارزمية للمهمة وتنفيذها عن طريق التصميم بمساعدة الكمبيوتر ؛
تطوير رمز منتج البرنامج بناءً على مواصفات جاهزة على مستوى الوحدة ؛
استخدام الأدوات في مرحلة تصحيح أخطاء منتج البرنامج ؛
اختبار وحدة برمجية وفقًا لسيناريو محدد.
كنتيجة لإتقان الجزء الإلزامي من الوحدة ، يجب أن يكون الطالب قادرًا على:
تطوير كود وحدة برمجية في لغات البرمجة الحديثة ؛
إنشاء برنامج وفقًا للخوارزمية المطورة كوحدة منفصلة ؛
تصحيح واختبار البرنامج على مستوى الوحدة ؛
إعداد الوثائق الخاصة بالبرمجيات ؛
استخدم الأدوات لأتمتة الأعمال الورقية.
نتيجة إتقان الجزء الإلزامي من الوحدة ، يجب أن يعرف الطالب:
المراحل الرئيسية لتطوير البرمجيات ؛
المبادئ الأساسية لتكنولوجيا البرمجة المنظمة والموجهة نحو الكائنات ؛
المبادئ الأساسية لتصحيح الأخطاء واختبار منتجات البرمجيات ؛
طرق وأدوات تطوير الوثائق الفنية.
6. تطوير كود البرنامج باستخدام البرمجة المهيكلة
7. تطوير كود البرنامج باستخدام التفاصيل خطوة بخطوة
8. تطوير كود البرنامج باستخدام البرمجة المعيارية
9. تهيئة المصفوفات
10. تنفيذ الهياكل الديناميكية باستخدام المصفوفات
11. تطوير كود البرنامج باستخدام الهياكل
12. تطوير كود البرنامج باستخدام الوظائف
13. تطوير كود البرنامج باستخدام المؤشر المرجعي
14. تنفيذ المدخلات والمخرجات
15. تنفيذ ملف تيارات
16. تنفيذ سلسلة البيانات
17. تطوير فئات ثابتة
18. تنمية الطبقات الديناميكية
19. تطوير فصول مجردة
20. تطوير قوالب الفصل
21. تنفيذ برنامج التصحيح كود
22. إجراء فرز الفقاعة
23. تنفيذ الفرز عن طريق الإدراج
24. إجراء الفرز بطريقة Hoare
25- إجراء اختبار لمدونة البرنامج وفقاً لمبدأ "الصندوق الأبيض"
26- إجراء اختبار لمدونة البرنامج وفقاً لمبدأ "الصندوق الرمادي"
27- إجراء اختبار لمدونة البرنامج على أساس مبدأ "الصندوق الأسود"
28- تنفيذ تعظيم كود البرنامج
29- تنفيذ محرك البحث الأمثل لرمز البرنامج
30. إعداد الوثائق الفنية
31. وضع خوارزميات للعمل مع الرسومات
32. تهيئة نظام الرسومات
33. العمل مع النوافذ والإحداثيات
34. العمل مع الرسوم الأولية
35. عمل صورة متحركة
36. إعداد وثائق المستخدم
وزارة التربية و العلوم
جمهورية دونيتسك الشعبية
محترف الدولة
مؤسسة تعليمية
"كلية دونتسك الصناعية والاقتصادية"
برنامج العمل
الممارسة التعليمية UP.01
الوحدة المهنية PM.01 تطوير وحدات البرامج لأنظمة الكمبيوتر
في تخصص 09.02.03 "البرمجة في أنظمة الكمبيوتر"
جمعتها:
فولكوف فولوديمير ألكساندروفيتش ، مدرس تخصصات الكمبيوتر من فئة التأهيل "متخصص من أعلى فئة" ، مؤسسة التعليم العام الحكومية "كلية دونيتسك الصناعية والاقتصادية"
تمت الموافقة على البرنامج من قبل: Vovk Pavel Andreevich ، مدير "Smart IT Service".
| 1. برنامج الممارسة جواز السفر | |
| 2. نتائج الممارسة | |
| 3. هيكل ومحتوى الممارسة | |
| 4. شروط التنظيم والممارسة | |
| 5. مراقبة وتقييم نتائج الممارسة |
1.جواز برنامج الممارسة التعليمية. 01
1.1 مكان ممارسة التدريب UP.01
البرنامج التدريبي UP.01 للوحدة المهنية PM.01 "تطوير وحدات البرامج لأنظمة الكمبيوتر" تخصص 09.02.03 "البرمجة في أنظمة الكمبيوتر » المجموعة الموسعة 09.00.00 "المعلوماتية وتكنولوجيا الكمبيوتر" ، من حيث إتقان النوع الرئيسي من النشاط المهني (VPA):
تطوير وحدات البرامج لأنظمة الكمبيوتر والكفاءات المهنية ذات الصلة (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 "تطوير وحدات البرامج لأنظمة الكمبيوتر" هو تطوير الكفاءات العامة (GC):
| اسم نتيجة الممارسة |
|
| - |
|
| حسنًا 2. نظّم أنشطتك الخاصة ، واختر الأساليب والطرق القياسية لأداء المهام المهنية ، وتقييم فعاليتها وجودتها. | |
| حسنًا 3. اتخذ القرارات في المواقف القياسية وغير القياسية وكن مسؤولاً عنها. | |
| موافق 4. البحث عن واستخدام المعلومات اللازمة للأداء الفعال للمهام المهنية والمهنية والشخصية. | |
| حسنًا 5. استخدام تقنيات المعلومات والاتصالات في الأنشطة المهنية. | |
| حسنًا 6. العمل في فريق وفي فريق ، والتواصل بشكل فعال مع الزملاء والإدارة والمستهلكين. | |
| حسنًا 7. تحمل مسؤولية عمل أعضاء الفريق (المرؤوسين) ، عن نتيجة التعيينات. | - |
| مؤهلات |
|
| حسنًا 9. للتنقل في ظروف التغييرات المتكررة في التقنيات في الأنشطة المهنية. |
الكفاءات المهنية (كمبيوتر):
| النشاط المهني | اسم نتائج الممارسة |
|
| إتقان النوع الرئيسي من النشاط المهني | استخدام موارد شبكات الكمبيوتر المحلية والعالمية ؛ إدارة ملفات البيانات الموجودة على أجهزة التخزين المحلية والقابلة للإزالة ، وكذلك على أقراص شبكة الكمبيوتر المحلية وعلى الإنترنت ؛ طباعة ونسخ ونسخ المستندات على الطابعة وغيرها من المعدات المكتبية. المراقبة في شكل تقرير لكل عمل عملي. تعديل امتحان التأهيل. |
|
| محو الأمية ودقة العمل في البرامج التطبيقية: محرري النصوص والرسوم ، وقواعد البيانات ، ومحرر العروض التقديمية ؛ سرعة البحث عن المعلومات في محتوى قواعد البيانات. |
||
| الدقة والإلمام بإعداد برامج البريد الإلكتروني والخادم والعميل: سرعة استرجاع المعلومات باستخدام تقنيات وخدمات الإنترنت ؛ الدقة ومحو الأمية في إدخال ونقل المعلومات باستخدام تقنيات وخدمات الإنترنت. |
||
| محو الأمية في استخدام أساليب ووسائل حماية المعلومات من الوصول غير المصرح به ؛ صحة ودقة النسخ الاحتياطي واستعادة البيانات ؛ |
||
| محو الأمية ودقة العمل مع أنظمة الملفات ، وتنسيقات الملفات المختلفة ، وبرامج إدارة الملفات ؛ |
||
| الحفاظ على الوثائق المحاسبية والفنية. |
3 هيكل ومحتوى البرنامجأعلى الممارسات التعليمية 01
3.1 الخطة الموضوعية
| رموز الكفاءة | اسم الوحدة المهنية | مقدار الوقت, جانبا للممارسة (في أسابيع, ساعات) | تواريخ |
| الكمبيوتر 1.1 - الكمبيوتر 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 "برنامج Office" |
4 شروط التنظيم والسلوك
رفع الممارسة التعليمية. 01
4.1 متطلبات التوثيق, ضروري للممارسة:
برنامج العمل للتدريب UP.01 للوحدة المهنية PM.01. "تطوير وحدات البرامج لأنظمة الكمبيوتر" هو جزء من البرنامج التدريبي للمتخصصين من المستوى المتوسط من قبل مؤسسة التعليم المهني الحكومية "كلية دونيتسك الصناعية والاقتصادية" وفقًا للمعيار التعليمي الحكومي للتعليم المهني الثانوي في التخصص 09.02.03 "البرمجة في أنظمة الكمبيوتر" ، التي تأسست على منهج التخصص ، برنامج العمل للتخصصات MDK.01.01 "System Programming" ، MDK01.02 "البرمجة التطبيقية" ، مبادئ توجيهية للدعم التربوي والمنهجي لممارسة الطلاب الذين يتقنون تربويًا برامج التعليم المهني الثانوي.
4.2 متطلبات الدعم التربوي والمنهجي للممارسة:
قائمة بالمهام المعتمدة حسب نوع العمل ، إرشادات للطلاب حول أداء العمل ، توصيات لتنفيذ تقارير عن الممارسة.
4.3 المتطلبات اللوجستية:
يتطلب تنظيم الممارسة الصناعية وجود فصول دراسية ومختبر.
المعدات المكتبية وأماكن العمل:
مقاعد حسب عدد الطلاب (طاولة ، كمبيوتر ، كرسي) ؛
مكان عمل المعلم (طاولة ، كمبيوتر ، كرسي) ؛
خزانة لتخزين الوسائل التعليمية وناقلات المعلومات ؛
مهام لنهج فردي للتدريس وتنظيم العمل المستقل والتمارين ، طالب على جهاز كمبيوتر ؛
المؤلفات المرجعية والمنهجية.
مجموعة من برامج النظام والتطبيق والتدريب لأجهزة الكمبيوتر على الوسائط البصرية والإلكترونية ؛
مجلة إرشاد الطلاب حول حماية العمل ؛
مجموعة من الوسائل التعليمية.
معينات التدريب الفني:
أجهزة كمبيوتر تعليمية
مجموعة من المعدات التفاعلية (جهاز عرض ، شاشة ، مكبرات صوت) ؛
وسائل إطفاء حريق (طفاية حريق).
مجلس الفصول الدراسية
كمبيوتر شخصي مع برامج مرخصة ؛
طابعة ليزرية؛
تجهيزات المكتب وأماكن العمل من أدوات التطوير: أجهزة الكمبيوتر الشخصية (الشاشة ، وحدة النظام ، لوحة المفاتيح ، الماوس) ، مجموعة من التوثيق التربوي والمنهجي ، برمجيات تتفق مع محتوى التخصص (قذائف لغات البرمجة).
يتم توحيد جميع أجهزة الكمبيوتر في الفصل الدراسي في شبكة محلية ، ولديها إمكانية الوصول إلى شبكة تخزين المعلومات والوصول إلى الإنترنت.
معدات الاتصال:
محولات الشبكة؛
كبلات الشبكة
معدات لاسلكية واي فاي.
مكونات تركيب الشبكات ومعدات التركيب.
4.4 قائمة المنشورات التربوية, موارد الإنترنت, أدب إضافي
المصادر الرئيسيه:
أوليفر في جي. أنظمة تشغيل الشبكات: كتاب مدرسي للجامعات / V.G.Olifer ، N.A.Olifer. - الطبعة الثانية. - سانت بطرسبرغ: بيتر ، 2009 ، 2008. - 668 ص.:
إي تانينباوم. نظام التشغيل. التطوير والتنفيذ. SPb .: بيتر ، 2006-568 ص.
بوبكوف ك. إتقان نظام تشغيل Unix / KA Pupkov ، A.S. Chernikov ، N.M. Yakusheva. - موسكو: الراديو والاتصالات ، 1994. - 112 ص.
L. بيك مقدمة في برمجة النظام - م: مير ، 1988.
Grekul V.I.، Denischenko G.N.، Korovkina N.L. تصميم نظم المعلومات / موسكو: Binom، 2008. - 304 ص.
ليباييف ، V.V. هندسة البرمجيات. الأسس المنهجية [نص]: كتاب مدرسي. / في. حالة un-t - المدرسة العليا للاقتصاد. - م: TEIS ، 2006. - 608 ص.
Lavrischeva E. M.، Petrukhin V. A. طرق ووسائل هندسة البرمجيات. - درس تعليمي
إيان سومرفيل. هندسة البرمجيات ، الطبعة السادسة.: لكل. من الانجليزية ― م. : دار النشر "ويليامز" 2002. - 624 ص.
Excel 2010: برمجة احترافية في VBA.: Per. من الانجليزية - م: LLC “I.D. ويليامز "، 2012. - 944 ص. : سوف. - موازي. حلمة. م
Fowler M. إعادة بناء ديون: تحسين الكود الحالي - لكل. من اللغة الإنجليزية - SPb: Symbol-plus ، 2003. - 432 ص.
مصادر إضافية:
Volkov V.A. تعليمات منهجية لتنفيذ العمل العملي في مجال "برمجة النظام" ، دونيتسك: دونبك ، 2015.
Volkov V.A. تعليمات منهجية لتنفيذ مشروع الدورة ، دونيتسك: دونبك ، 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 - تقرير عن الممارسة ، تم إعداده وفقًا لمتطلبات التوصيات المنهجية.
| النتائج (إتقان الكفاءات المهنية) | العناصر الرئيسية نتيجة التحضير | النماذج والأساليب يتحكم |
| الكمبيوتر 1.1. القيام بتطوير المواصفات للمكونات الفردية | تطوير خوارزمية للمهمة وتنفيذها عن طريق التصميم بمساعدة الكمبيوتر | مراقبة وتقييم الخبراء لنشاط الطالب في عملية إتقان البرنامج التعليمي في الفصول العملية ، عند أداء العمل في الممارسة التعليمية والصناعية. |
| كمبيوتر 1.2. تطوير كود منتج البرنامج بناءً على المواصفات الجاهزة على مستوى الوحدة. | تعرف على المبادئ الأساسية لتكنولوجيا البرمجة المنظمة والموجهة للكائنات. لتطوير كود الوحدة البرمجية في لغات البرمجة الحديثة. |
|
| الكمبيوتر 1.3. وحدات برامج التصحيح باستخدام برامج متخصصة | تصحيح واختبار البرنامج على مستوى الوحدة. |
|
| الكمبيوتر 1.4. إجراء اختبار وحدات البرامج. | قم بإنشاء برنامج وفقًا للخوارزمية المطورة كوحدة منفصلة. |
|
| الكمبيوتر 1.5. تحسين كود البرنامج للوحدة | تطوير كود منتج البرنامج بناءً على مواصفات جاهزة على مستوى الوحدة. |
|
| الكمبيوتر 1.6. تطوير مكونات التصميم والوثائق الفنية باستخدام لغات المواصفات الرسومية | تعرف على طرق ووسائل تطوير التوثيق الفني. ضع وثائق لأدوات البرمجيات. استخدم الأدوات لأتمتة الأعمال الورقية. |
يجب أن تسمح أشكال وأساليب مراقبة وتقييم نتائج التعلم ليس فقط بتكوين الكفاءات المهنية لدى الطلاب ، ولكن أيضًا تطوير الكفاءات العامة والمهارات التي توفرها.
| النتائج (كفاءات عامة بارعة) | المؤشرات الرئيسية لتقييم النتيجة | أشكال وطرق الرقابة والتقويم |
| حسنًا 1. افهم الجوهر والأهمية الاجتماعية لمهنتك المستقبلية ، وأظهر اهتمامًا ثابتًا بها. | إظهار الاهتمام المستمر بالمهنة المستقبلية ؛ - صحة تطبيق الكفاءات المهنية المتقنة ؛ | مراقبة الخبراء وتقييمهم في التدريب العملي عند أداء العمل على الممارسة الصناعية ؛ |
| حسنًا 2. نظّم الأنشطة الخاصة بك ، وحدد أساليب وطرق أداء المهام المهنية ، وقم بتقييم فعاليتها وجودتها. | إثبات تحديد الأهداف واختيار وتطبيق أساليب وطرق حل المشكلات المهنية ؛ الاستبطان وتصحيح نتائج العمل | التقييم في التدريب العملي أثناء أداء العمل ؛ الملاحظة أثناء الممارسة ؛ استبطان - سبر غور |
| حسنًا 3. حل المشكلات وتقييم المخاطر واتخاذ القرارات في المواقف غير القياسية. | كفاءة اتخاذ القرارات بشأن المهام المهنية القياسية وغير القياسية خلال فترة زمنية معينة ؛ فعالية الخطة لتحسين جودة العمل المنجز | تفسير نتائج ملاحظة أنشطة الطالب في عملية إتمام المهام |
| موافق 4. البحث عن المعلومات اللازمة وتحليلها وتقييمها لإعداد وحل المشكلات المهنية ، والتطوير المهني والشخصي. | اختيار وتحليل المعلومات اللازمة للتنفيذ الواضح والسريع للمهام المهنية والتطوير المهني والشخصي | تقييم الخبراء في سياق العمل ؛ ضبط النفس أثناء طرح المشكلات وحلها |
| موافق 5. استخدام تقنيات المعلومات والاتصالات لتحسين النشاط المهني. | القدرة على استخدام تقنيات المعلومات والاتصالات لحل المشكلات المهنية | تقييم الواجبات |
| حسنًا 6. العمل في فريق وفريق ، وضمان تماسكه ، والتواصل بشكل فعال مع الزملاء ، والإدارة ، والمستهلكين. | القدرة على التفاعل مع مجموعة ، المعلمين ، ماجستير التدريب الصناعي | |
| حسنًا 7. حدد الأهداف ، وحفز أنشطة المرؤوسين ، وقم بتنظيم عملهم والتحكم فيه مع تحمل المسؤولية عن نتيجة التعيينات. | - الاستبطان وتصحيح نتائج عمل الفرد وعمل الفريق | مراقبة تقدم العمل في مجموعة في عملية التدريب العملي |
| حسنًا 8. لتحديد مهام التطوير المهني والشخصي بشكل مستقل ، الانخراط في التعليم الذاتي ، والتخطيط بوعي للتطوير المهني. | تنظيم العمل المستقل على تكوين صورة إبداعية ومهنية ؛ تنظيم العمل على التثقيف الذاتي والتحسين مؤهلات | المراقبة والتقييم في عملية الممارسة الصناعية ؛ التحليل الانعكاسي (خوارزمية إجراءات الطلاب) ؛ يوميات الممارسة تحليل محفظة الطالب |
| حسنًا 9. كن مستعدًا لتغيير التقنيات في النشاط المهني. | تحليل الابتكارات في مجال العمليات التكنولوجية لتطوير وتصنيع الملابس الجاهزة | تقييم الحلول للمهام الظرفية ؛ ألعاب التعلم التجارية والتنظيمية ؛ الملاحظة والتقييم في التدريب العملي ، في عملية الممارسة الصناعية |
مقال
اختبار تصميم العمل PM.01 "تطوير وحدات البرمجيات لأنظمة الكمبيوتر". المؤسسة التعليمية المهنية للميزانية الحكومية لجمهورية القرم "كلية فيودوسيا للفنون التطبيقية". 2015 -20 صفحة ، الرسوم التوضيحية 7 ، الملحق 1 ، المصادر الببليوغرافية 3.
تم تصميم وتنفيذ الأداة البرمجية "الإجراءات على المصفوفات" ، وتم تطوير واجهة رسومية لها في البيئةMicrosoft Visual Studio Ultimate 2013 C #. يتيح لك منتج البرنامج دراسة بنية ونحو لغات البرمجة الجديدة.
أداة البرامج ، الشروط المرجعية ، الاختبار الوظيفي ، اختبار التقييم ، الاختبار الهيكلي ، بيئة التطوير ، التطوير ، الخوارزمية ، الواجهة
|
المقدمة 1 تطوير خوارزمية للمشكلة المعلنة وتنفيذ وسائل تصميمها الآلي 1.1 تحليل المهمة 1.2 اختيار الأساليب وتطوير الخوارزميات الأساسية للحل 2 تطوير رمز منتج البرنامج بناءً على مواصفات جاهزة على مستوى الوحدة 3. استخدام الأدوات في مرحلة تفكيك وحدة البرنامج 4 اختبار وحدة البرنامج لسيناريو محدد 5 تسجيل الوثائق على البرنامج قائمة المراجع الملحق أ |
المقدمة
يتكون كل منتج برمجي من وحدات. يمكن تطوير الوحدة بشكل منفصل وبالتالي ترقية البرنامج لتحسين وظائفه.
الغرض من العمل هو:
- توحيد المعرفة النظرية التي تم الحصول عليها في تخصصات البرمجة التطبيقية وبرمجة النظام ونظرية الخوارزميات وأساسيات البرمجة واللغات الخوارزمية "؛
- جمع وتحليل وتوليف المواد لإعداد تقرير عن الممارسة.
يتم تحديد مهام العمل من خلال مهمة فردية:
- تحليل المهمة المطروحة ؛
- اختيار الأساليب وتطوير خوارزميات الحل الأساسية ؛
- اختيار التكنولوجيا وبيئة البرمجة ؛
- بناء إطار تطبيق وتصميم واجهة مستخدم ؛
- تطوير كود منتج البرنامج على أساس المواصفات الجاهزة ؛
- اختيار استراتيجية الاختبار وتطوير الاختبار ؛
- باستخدام أدوات التصحيح التي توفرها واجهة المستخدم ؛
- اختبار وحدة برمجية وفقًا لسيناريو محدد ؛
- إعداد وثائق لأداة برمجية.
العمل مقسم إلى خمسة أقسام.
يصف القسم الأول تطوير خوارزمية للمهمة وتنفيذها عن طريق التصميم بمساعدة الكمبيوتر.
في القسم الثاني ، يكون اختيار تقنية بيئة البرمجة مبررًا ، ويتم وصف واجهة المستخدم المصممة وتطوير رمز منتج البرنامج.
يصف القسم الثالث كيفية استخدام الأدوات أثناء مرحلة تصحيح الأخطاء في وحدة البرنامج.
يصف القسم الرابع اختبار وحدة البرنامج ، ويصف الاختبار الوظيفي والهيكلية والتقييمي.
القسم الخامس مخصص لتصميم وثائق الأداة البرمجية.
1 تطوير خوارزمية للمشكلة المعلنة وتنفيذ وسائل تصميمها الآلي
1.1 تحليل المهمة
من الضروري كتابة برنامج يقوم بتنفيذ إجراءات على المصفوفات: الضرب والجمع والطرح والتبديل. يجب أن يحل البرنامج المصفوفة التي تم إدخالها يدويًا في النموذج. لراحة المستخدم ، يجب أن يكون للبرنامج واجهة سهلة الاستخدام.
1.2 اختيار الأساليب وتطوير الخوارزميات الأساسية للحل
يستخدم البرنامج خوارزمية العمل التالية: يحتوي البرنامج على أشكال يتم فيها إدخال عناصر المصفوفة ، ويتم ترجمة العناصر منهانوع السلسلة إلى عدد صحيح ... ثم تحتاج إلى الضغط على الزر للإجراء المقابل. يتم تنفيذ خوارزمية حل المصفوفات ويتم عرض النتيجة في العنصرعرض شبكة البيانات.
لبناء مخططات الكتلة ، استخدمنا البرنامجمايكروسوفت أوفيس فيسيو 2013. بمساعدتها ، يمكنك وضع مخططات ومخططات مختلفة ، بما في ذلك المخططات القُطرية.
الشكل 1.1 - رسم تخطيطي لقراءة البيانات وكتابتها من الكتابة إلى المصفوفة
الشكل 1.2 - تحقق من إمكانية الوصول للمدخلات
الشكل 1.3 - رسم تخطيطي لإدخال البيانات فيهمربع الكتابة والمقارنات مع مصفوفة موجودة
الشكل 1.4 - استدعاء الأسلوبفيزوف مع المعلمات
2 تطوير رمز منتج البرنامج بناءً على مواصفات جاهزة على مستوى الوحدة
يتم تطبيق حاسبة المصفوفة في لغة البرمجة C # في بيئة برمجة Microsoft Visual Studio Ultimate 2013. يرجع اختيار لغة C # إلى حقيقة أنها لغة برمجة حديثة وشائعة التوجه نحو الكائنات ، و Microsoft Visual تعد بيئة Studio Ultimate 2013 أداة قوية تتيح لك إنشاء برنامج بسرعة بواجهة نافذة رسومية.
يظهر تخطيط النافذة في الشكل 2.1.
الشكل 2.1 - واجهة نافذة التطبيق المستقبلي
هناك 3 عناصر في النموذجعرض شبكة البيانات ، سوف تحتوي على مصفوفات. أيضا 4زر لأداء الإجراءات على المصفوفات.
3. استخدام الأدوات في مرحلة تفكيك وحدة البرنامج
عند تصحيح أخطاء منتج برمجي ، استخدم أمر قائمة التصحيح (الشكل 3.1). يوجد عدد من الأوامر في قائمة التصحيح ، والغرض منها موضح أدناه.
الشكل 3.1- نافذة قائمة التصحيح
Windows - يفتح نافذة Breakpoints في IDE ، مما يتيح الوصول إلى جميع نقاط توقف الحل. يعرض نافذة الإخراج في الإطار.
نافذة الإخراج عبارة عن سجل تشغيل للعديد من الرسائل الصادرة عن إطار العمل والمترجم والمصحح. لذلك ، لا تنطبق هذه المعلومات على جلسة التصحيح فحسب ، بل تفتح أيضًا نافذة Interpret في إطار العمل ، مما يسمح لك بتنفيذ الأوامر:
- بدء التصحيح - يبدأ التطبيق في وضع التصحيح ؛
- إرفاق بالعملية - يسمح لك بإرفاق مصحح أخطاء بعملية جارية (قابلة للتنفيذ). على سبيل المثال ، إذا كان التطبيق يعمل بدون تصحيح الأخطاء ، فيمكنك حينئذٍ إرفاق هذه العملية الجارية وبدء التصحيح ؛
- استثناءات - يفتح مربع حوار الاستثناءات ، والذي يسمح لك باختيار كيفية إيقاف مصحح الأخطاء لكل حالة استثنائية ؛
- خطوة مع الإدخال - يقوم بتشغيل التطبيق في وضع التصحيح. بالنسبة لمعظم المشاريع ، يعني اختيار الأمر step-in استدعاء مصحح الأخطاء في السطر الأول من التطبيق الذي يتم تنفيذه. وبالتالي ، يمكنك إدخال التطبيق من السطر الأول ؛
- خطوة الحل البديل - عندما لا تكون في جلسة تصحيح الأخطاء ، يبدأ أمر خطوة الحل البديل ببساطة التطبيق بنفس الطريقة التي يعمل بها زر التشغيل ؛
- نقطة الإيقاف - تشغيل أو إيقاف تشغيل نقطة الإيقاف على السطر الحالي (النشط) لرمز محرر النصوص. يظهر هذا الخيار باللون الرمادي في حالة عدم وجود نافذة تعليمات برمجية نشطة في إطار العمل ؛
- إنشاء نقطة توقف - ينشط مربع الحوار إنشاء نقطة توقف مما يسمح لك بتحديد اسم الوظيفة التي تريد إنشاء نقطة توقف لها ؛
- إزالة جميع نقاط التوقف - يزيل جميع نقاط التوقف من الحل الحالي ؛
- امسح جميع تلميحات البيانات - يلغي (بدون حذف) جميع نقاط توقف الحل الحالي ؛
- الخيارات والإعدادات - إحباط التنفيذ عندما تعبر الاستثناءات حدود مجال التطبيق أو الحدود بين الكود المُدار والأصلية.
4 اختبار وحدة البرنامج لسيناريو محدد
اختبار التقييم ، ويسمى أيضًا "اختبار النظام الشامل"الغرض منه هو اختبار البرنامج للامتثال للمتطلبات الأساسية. هذه المرحلة من الاختبار مهمة بشكل خاص لمنتجات البرمجيات.يشمل الأنواع التالية:
- اختبار قابلية الاستخدام - التحقق المتسق من امتثال منتج البرنامج وتوثيقه للأحكام الرئيسية للاختصاصات ؛
- الاختبار بأحجام كبيرة - التحقق من أداء البرنامج على أكبر قدر ممكن من البيانات ، على سبيل المثال ، كمية النصوص والجداول وعدد كبير من الملفات ، وما إلى ذلك ؛
- الاختبار عند الأحمال القصوى - التحقق من تنفيذ البرنامج للقدرة على معالجة كمية كبيرة من البيانات الواردة في غضون وقت قصير ؛
- اختبار قابلية الاستخدام - تحليل العوامل النفسية التي تنشأ عند العمل مع البرامج ؛ يتيح لك هذا الاختبار تحديد ما إذا كانت الواجهة سهلة الاستخدام ، وما إذا كان اللون أو الصوت مزعجًا ، وما إلى ذلك ؛
- اختبار الأمان - التحقق من الحماية ، على سبيل المثال ، من الوصول غير المصرح به إلى المعلومات ؛
- اختبار الأداء - تحديد الإنتاجية لتكوين معين وحمل ؛
- اختبار متطلبات الذاكرة - تحديد الاحتياجات الحقيقية لذاكرة الوصول العشوائي والذاكرة الخارجية ؛
- اختبار تكوين الأجهزة - التحقق من أداء البرنامج على الأجهزة المختلفة ؛
- اختبار التوافق - التحقق من استمرارية الإصدارات: في الحالات التي يغير فيها الإصدار التالي من النظام تنسيقات البيانات ، يجب أن يوفر مسخنات خاصة توفر القدرة على العمل مع الملفات التي تم إنشاؤها بواسطة الإصدار السابق من النظام ؛
- سهولة اختبار التركيب - التحقق من سهولة التثبيت ؛
- اختبار الموثوقية - اختبار الموثوقية باستخدام النماذج الرياضية ؛
- اختبار الاسترداد - اختبار استعادة البرامج ، مثل نظام يتضمن قاعدة بيانات ، بعد أعطال الأجهزة والبرامج ؛
- اختبار قابلية الخدمة - التحقق من أدوات الخدمة المضمنة في البرنامج ؛
- اختبار الوثائق - فحص شامل للوثائق ، على سبيل المثال ، إذا كانت الوثائق تحتوي على أمثلة ، فيجب تجربتها جميعًا ؛
- اختبار الإجراء - التحقق من العمليات اليدوية المفترضة في النظام.
وبطبيعة الحال ، فإن الغرض من كل هذه الفحوصات هو إيجاد تناقضات مع الاختصاصات. يُعتقد أنه بعد اكتمال جميع أنواع الاختبارات فقط ، يمكن تقديم منتج البرنامج للمستخدم أو للتنفيذ. ومع ذلك ، من الناحية العملية ، لا يتم عادةً إجراء جميع أنواع اختبارات التقييم ، لأنها مكلفة للغاية وتستغرق وقتًا طويلاً. كقاعدة عامة ، بالنسبة لكل نوع من البرامج ، يتم إجراء تلك الأنواع من الاختبارات الأكثر أهمية بالنسبة له. لذلك يتم بالضرورة اختبار قواعد البيانات بأحجام قصوى وأنظمة الوقت الفعلي - بأحمال قصوى.
5 تسجيل الوثائق على البرنامج
منتج البرنامج الذي تم إنشاؤه مخصص لإجراء عمليات حسابية على المصفوفات.
لتشغيل البرنامج ، تحتاج إلى تشغيل التطبيق.
لإنشاء مصفوفات ، تحتاج إلى إدخال أبعاد المصفوفة والنقر فوق الزر "إنشاء". ثم أدخل البيانات في المصفوفة وحدد الإجراء المطلوب.
الشكل 5.1 - تشغيل التطبيق
يحتوي البرنامج على واجهة سهلة الاستخدام ويوفر القدرة على حل المصفوفات ذات الأبعاد العشوائية بسهولة.
الاستنتاجات
في سياق العمل ، تم الانتهاء من مهمة فردية:
- تم إجراء تحليل مجال الموضوع ؛
- خوارزمية الحل المختارة والمطورة لها ما يبررها ؛
- تقنية معينة وبيئة برمجة مختارة ؛
- تم بناء إطار التطبيق وتصميم واجهة المستخدم ؛
- تم تطوير رمز وحدة البرنامج ؛
- تم وصف أدوات التصحيح المستخدمة أثناء الاختبار ؛
- تم اختبار وحدة البرنامج وفقًا لسيناريو محدد ؛
- أضاف عنصر قائمة مع وصف موجز لكيفية العمل مع البرنامج.
تم تحقيق الأهداف المحددة.
قائمة المراجع
1 المنتدى السيبراني [مورد إلكتروني]: http: // CyberForum. ru
2 مطور مايكروسوفت [الوثائق الرسمية لـ Microsoft لـ C #] ttps: // msdn. مايكروسوفت. كوم
3 http://programming-edu.ru/ C # مدونة مساعدة للمبتدئين
الملحق أ
كود البرنامج
ماتريكس. CS
باستخدام النظام ؛
باستخدام System.Linq ؛
باستخدام System.Text ؛
باستخدام System.Windows.Forms ؛
مصفوفة مساحة الاسم
فئة MyMatrix
كثافة العمليات [،] أ = كثافة العمليات الجديدة؛
// تمرير القيم
مجموعة باطلة عامة (int i، int j، int znach)
أ = 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 () ؛
// الإخراج دفعة واحدة. وجه ضاحك
Public DataGridView FullVisual (DataGridView dt)
لـ (int i = 0 ؛ i< 3; i++)
لـ (int j = 0 ؛ j< 3; j++)
صفوف Dt.Rows [j] .Cells [i] .Value = a ؛
عودة dt ؛
// طرح او خصم
مشغل 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 العام ()
MyMatrix NewMatrix = جديد MyMatrix () ؛
لـ (int i = 0 ؛ i< 3; i++)
لـ (int j = 0 ؛ j< 3; j++)
NewMatrix.a = أ ؛
عودة NewMatrix ؛
// عمليه الضرب
مشغل MyMatrix العام الثابت * (MyMatrix matrix 1، MyMatrix matrix2)
MyMatrix NewMatrix = جديد MyMatrix () ؛
لـ (int i = 0 ؛ i< 3; i++)
لـ (int k = 0 ؛ k< 3; k++)
// int a = 0 ؛
لـ (int j = 0 ؛ j< 3; j++)
// a + = matrix1.a * matrix2.a ؛
NewMatrix.a + = matrix1.a * matrix2.a ؛
//NewMatrix.a = أ ؛
عودة NewMatrix ؛
// ملء
الفراغ العام Zapoln (شبكة DataGridView)
لـ (int i = 0 ؛ i< 3; i++)
لـ (int j = 0 ؛ j< 3; j++)
A = Convert.ToInt32 (grid.Rows [j] .Cells [i] .Value) ؛
Form1.cs
باستخدام النظام ؛
باستخدام System.Collections.Generic ؛
باستخدام System.ComponentModel ؛
باستخدام System.Data ؛
باستخدام System.Drawing ؛
باستخدام System.Linq ؛
باستخدام System.Text ؛
باستخدام System.Windows.Forms ؛
مصفوفة مساحة الاسم
فئة جزئية عامة Form1: Form
العامة Form1 ()
InitializeComponent () ،
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 () ؛
button1_Click باطل خاص (مرسل الكائن ، EventArgs e)
مصفوفة MyMatrix 3 ؛
Matrix3 = (matrix1 + matrix2) ؛
button2_Click الفراغ الخاص (مرسل الكائن ، EventArgs e)
MyMatrix matrix1 = new MyMatrix ()؛
MyMatrix matrix2 = new MyMatrix ()؛
مصفوفة MyMatrix 3 ؛
Matrix1.Zapoln (dataGridView1) ؛
Matrix2.Zapoln (dataGridView2) ؛
Matrix3 = (matrix1 - matrix2) ؛
Matrix3.FullVisual (dataGridView3) ؛
button3_Click الفراغ الخاص (مرسل الكائن ، EventArgs e)
MyMatrix matrix1 = new MyMatrix ()؛
مصفوفة MyMatrix 3 ؛
Matrix1.Zapoln (dataGridView1) ؛
Matrix3 = matrix1.Trans () ،
Matrix3.FullVisual (dataGridView3) ؛
button4_Click الفراغ الخاص (مرسل الكائن ، EventArgs e)
MyMatrix matrix1 = new MyMatrix ()؛
MyMatrix matrix2 = new MyMatrix ()؛
مصفوفة MyMatrix 3 ؛
Matrix1.Zapoln (dataGridView1) ؛
Matrix2.Zapoln (dataGridView2) ؛
Matrix3 = (matrix1 * matrix2) ؛
Matrix3.FullVisual (dataGridView3) ؛
صفحة \ * معلومات 3
المحاضرة 8. تطوير وحدة برمجية
إجراء تطوير وحدة برمجية. البرمجة المنظمة والتفاصيل خطوة بخطوة. فهم الكود الكاذب. التحكم في وحدة البرنامج.
8.1 إجراء تطوير وحدة برمجية.
عند تطوير وحدة برمجية ، يُنصح بالالتزام بالترتيب التالي:
دراسة والتحقق من مواصفات الوحدة واختيار اللغة
برمجة؛
اختيار الخوارزمية وهيكل البيانات ؛
برمجة الوحدة
تلميع نص الوحدة ؛
فحص الوحدة
تجميع الوحدة.
تتمثل الخطوة الأولى في تطوير وحدة برمجية إلى حد كبير في التحكم المجاور لهيكل البرنامج من الأسفل: من خلال دراسة مواصفات الوحدة ، يجب على المطور التأكد من أنها واضحة له وكافية لتطوير هذه الوحدة. في نهاية هذه الخطوة ، يتم تحديد لغة البرمجة: على الرغم من أن لغة البرمجة قد تكون محددة مسبقًا لنظام البرنامج بأكمله ، في بعض الحالات (إذا كان نظام البرمجة يسمح بذلك) ، يمكن اختيار لغة أخرى أكثر ملاءمة للتنفيذ من هذه الوحدة (على سبيل المثال ، لغة التجميع).
في الخطوة الثانية في تطوير وحدة برمجية ، من الضروري معرفة ما إذا كانت أي خوارزميات معروفة بالفعل لحل المشكلة المطروحة أو قريبة منها. وإذا تم العثور على خوارزمية مناسبة ، فمن المستحسن استخدامها. إن اختيار هياكل البيانات المناسبة التي سيتم استخدامها عندما تؤدي وحدة ما وظائفها يحدد مسبقًا بشكل كبير المنطق ومؤشرات الجودة للوحدة التي يتم تطويرها ، لذلك يجب اعتباره قرارًا مسؤولاً للغاية.
في الخطوة الثالثة ، يتم إنشاء نص الوحدة بلغة البرمجة المختارة. إن وفرة جميع أنواع التفاصيل التي يجب أخذها في الاعتبار عند تنفيذ الوظائف المحددة في مواصفات الوحدة يمكن أن تؤدي بسهولة إلى إنشاء نص محير للغاية يحتوي على الكثير من الأخطاء وعدم الدقة. يمكن أن يكون العثور على الأخطاء في مثل هذه الوحدة وإجراء التغييرات المطلوبة عليها مهمة تستغرق وقتًا طويلاً. لذلك ، من المهم جدًا استخدام نظام برمجة سليم تقنيًا ومثبت عمليًا لبناء نص الوحدة. ولأول مرة ، لفت Dijkstra الانتباه إلى هذا الأمر ، حيث قام بصياغة وإثبات المبادئ الأساسية للبرمجة المنظمة. تعتمد العديد من تخصصات البرمجة المستخدمة على نطاق واسع في الممارسة على هذه المبادئ. أكثر التخصصات شيوعًا هو التحسين التدريجي ، والذي تمت مناقشته بالتفصيل في القسمين 8.2 و 8.3.
ترتبط الخطوة التالية في تطوير الوحدة بإحضار نص الوحدة إلى نموذج كامل وفقًا لمواصفات الجودة لنظام البرنامج. عند برمجة وحدة ما ، يركز المطور على التنفيذ الصحيح لوظائف الوحدة ، ويترك تعليقات غير كاملة ويسمح ببعض الانتهاكات لمتطلبات نمط البرنامج. عند تلميع نص الوحدة ، يجب عليه تعديل التعليقات في النص ، وربما تضمين تعليقات إضافية فيه من أجل توفير العناصر الأساسية المطلوبة للجودة. للغرض نفسه ، يتم تحرير نص البرنامج لتلبية المتطلبات الأسلوبية.
خطوة التحقق من الوحدة هي التحقق اليدوي من المنطق الداخلي للوحدة قبل تصحيحها (باستخدام تنفيذها على جهاز كمبيوتر) ، وتنفذ المبدأ العام الذي تمت صياغته لتقنية البرمجة التي تمت مناقشتها ، حول الحاجة إلى التحكم في القرارات المتخذة في كل مرحلة من مراحل تطوير البرمجيات (انظر المحاضرة 3). تمت مناقشة طرق التحقق من صحة الوحدة النمطية في القسم 8.4.
أخيرًا ، تعني الخطوة الأخيرة في تطوير الوحدة إكمال التحقق من الوحدة (بمساعدة المترجم) والمضي قدمًا في عملية تصحيح الوحدة.
8.2 برمجة منظمة.
عند برمجة وحدة نمطية ، يجب ألا يغيب عن البال أن البرنامج يجب أن يكون مفهومًا ليس فقط لجهاز الكمبيوتر ، ولكن أيضًا بالنسبة للشخص: كل من مطور الوحدة ، والأشخاص الذين يتحققون من الوحدة ، والنصيون الذين يعدون الاختبارات تصحيح أخطاء الوحدة ، وسيتعين على المشرفين على صيانة PS الذين يقومون بإجراء التغييرات المطلوبة على الوحدة تفكيك منطق الوحدة بشكل متكرر. في لغات البرمجة الحديثة ، توجد أدوات كافية للتشويش على هذا المنطق بقدر ما تريد ، مما يجعل من الصعب على البشر فهم الوحدة ، ونتيجة لذلك ، تجعلها غير موثوقة أو يصعب صيانتها. لذلك ، من الضروري اتخاذ خطوات لتحديد أدوات اللغة المناسبة واتباع نظام برمجة محدد. لأول مرة ، لفت Dijkstra الانتباه إلى هذا واقترح بناء برنامج كتكوين لعدة أنواع من هياكل التحكم (الهياكل) ، والتي يمكن أن تزيد بشكل كبير من فهم منطق البرنامج. البرمجة باستخدام مثل هذه التركيبات فقط كانت تسمى الهيكلية.
التركيبات الأساسية للبرمجة المهيكلة هي: المتابعة ، والتفرع ، والتكرار (انظر الشكل 8.1). مكونات هذه الإنشاءات هي عوامل تشغيل معممة (عقد معالجة) S ، S1 ، S2 وشرط (أصلي) P. يمكن أن يكون المشغل المعمم إما مشغلًا بسيطًا للغة البرمجة المستخدمة (التعيين ، الإدخال ، الإخراج ، مشغلي استدعاء الإجراء) ، أو جزء من البرنامج ، وهو عبارة عن تركيبة من بنيات التحكم الأساسية في البرمجة المنظمة. من الضروري أن يكون لكل من هذه الهياكل مدخل واحد ومخرج واحد للتحكم. وبالتالي ، فإن المشغل المعمم له مدخل واحد ومخرج واحد فقط.
من المهم أيضًا أن تكون هذه التركيبات كائنات رياضية بالفعل (والتي ، في جوهرها ، تشرح سبب نجاح البرمجة المنظمة). ثبت أنه لكل برنامج غير منظم من الممكن بناء برنامج منظم مكافئ وظيفيًا (أي حل نفس المشكلة). بالنسبة للبرامج المهيكلة ، يمكنك إثبات بعض الخصائص رياضيًا ، مما يسمح لك باكتشاف بعض الأخطاء في البرنامج. سيتم تخصيص محاضرة منفصلة لهذه القضية.
يشار إلى البرمجة المهيكلة أحيانًا باسم "عدم الانتقال إلى البرمجة". ومع ذلك ، فإن النقطة هنا ليست في عبارة GO TO ، ولكن في استخدامها غير المنتظم. في كثير من الأحيان ، عند تنفيذ البرمجة المهيكلة في بعض لغات البرمجة (على سبيل المثال ، في FORTRAN) ، يتم استخدام عامل النقل (GO TO) لتنفيذ التركيبات الهيكلية دون المساس بالمزايا الرئيسية للبرمجة المهيكلة. إن عوامل القفز "غير الهيكلية" هي التي تربك البرنامج ، وخاصة الانتقال إلى المشغل الموجود في نص الوحدة أعلاه (سابقًا) عامل الانتقال الذي يتم تنفيذه. ومع ذلك ، فإن محاولة تجنب مشغل الفرع في بعض الحالات البسيطة يمكن أن تؤدي إلى برامج منظمة مرهقة للغاية ، والتي لا تحسن وضوحها وتحتوي على خطر حدوث أخطاء إضافية في نص الوحدة. لذلك ، يمكننا أن نوصي بتجنب استخدام مشغل القفز كلما أمكن ذلك ، ولكن ليس على حساب وضوح البرنامج.
تشمل الحالات المفيدة لاستخدام مشغل القفز الخروج من حلقة أو إجراء بشرط خاص ينهي "في وقت مبكر" عمل دورة معينة أو إجراء معين ، أي إنهاء عمل بعض الوحدات الهيكلية (المشغل المعمم) وبالتالي انتهاك هيكلة البرنامج محليًا فقط. تنجم الصعوبات الكبيرة (وتعقيد الهيكل) عن التنفيذ الهيكلي لرد الفعل على المواقف الاستثنائية الناشئة (غالبًا ما تكون خاطئة) ، لأن هذا لا يتطلب فقط الخروج المبكر من الوحدة الهيكلية ، ولكن أيضًا المعالجة الضرورية (الاستبعاد) هذا الموقف (على سبيل المثال ، إصدار معلومات تشخيصية مناسبة). يمكن أن يكون معالج الاستثناء في أي مستوى من بنية البرنامج ، ويمكن الوصول إليه من مستويات أدنى مختلفة. يعتبر التنفيذ "غير الهيكلي" التالي للاستجابة للحالات الاستثنائية مقبولاً تمامًا من وجهة النظر التكنولوجية. يتم وضع معالجات الاستثناءات في نهاية وحدة هيكلية واحدة أو أخرى ، ويتم برمجة كل معالج بطريقة تجعله يخرج من الوحدة الهيكلية التي يتم وضعها في نهايتها بعد إكمال عمله. يتم استدعاء هذا المعالج بواسطة مشغل النقل من الوحدة الهيكلية المحددة (بما في ذلك أي وحدة هيكلية متداخلة فيها).
8.3 تفصيل خطوة بخطوة ومفهوم الكود الكاذب.
توفر البرمجة المهيكلة إرشادات حول الكيفية التي يجب أن يكون بها نص الوحدة. السؤال الذي يطرح نفسه هو كيف يجب أن يتصرف المبرمج لبناء مثل هذا النص. تبدأ برمجة الوحدة في بعض الأحيان ببناء مخطط الكتلة الخاص بها ، والذي يحدد منطق تشغيلها. ومع ذلك ، لا توصي تقنية البرمجة الحديثة بالقيام بذلك. على الرغم من أن المخططات الكتل تجعل من الممكن تمثيل منطق تشغيل الوحدة بشكل واضح للغاية ، عندما يتم ترميزها بلغة برمجة ، يظهر مصدر محدد جدًا للأخطاء: تعيين الهياكل ثنائية الأبعاد بشكل أساسي ، مثل المخططات الكتل ، يحتوي النص الخطي الذي يمثل وحدة نمطية على خطر تشويه منطق الوحدة ، لذا من الصعب جدًا من الناحية النفسية الحفاظ على مستوى عالٍ من الاهتمام عند إعادة فحصها. قد يكون الاستثناء هو الحالة عندما يتم استخدام محرر رسومي لإنشاء مخططات كتلة ويتم إضفاء الطابع الرسمي عليها بحيث يتم إنشاء النص في لغة البرمجة تلقائيًا منها (على سبيل المثال ، يمكن القيام بذلك في تقنية R).
توصي تقنية البرمجة الحديثة بالتفاصيل خطوة بخطوة باعتبارها الطريقة الرئيسية لبناء نص الوحدة. جوهر هذه الطريقة هو تقسيم عملية تطوير نص الوحدة إلى عدد من الخطوات. في الخطوة الأولى ، يتم وصف المخطط العام لتشغيل الوحدة في شكل نص خطي يمكن ملاحظته (أي باستخدام مفاهيم كبيرة جدًا) ، وهذا الوصف غير رسمي بشكل كامل ويركز على الإدراك البشري. في كل خطوة تالية ، يتم تنقيح أحد المفاهيم وتفصيله (سنسميه مصقول) ، ويستخدم (كقاعدة ، وليس رسميًا) في أي وصف تم تطويره في إحدى الخطوات السابقة. نتيجة لهذه الخطوة ، يتم إنشاء وصف للمفهوم المكرر المحدد إما من حيث لغة البرمجة الأساسية (أي الوحدة المختارة للعرض التقديمي) ، أو بنفس الشكل كما في الخطوة الأولى باستخدام مفاهيم مصقولة جديدة. تنتهي هذه العملية عندما يتم التعبير عن جميع المفاهيم المكررة في النهاية بلغة البرمجة الأساسية. الخطوة الأخيرة هي الحصول على نص الوحدة في لغة البرمجة الأساسية عن طريق استبدال جميع تكرارات المفاهيم المكررة بأوصافها المقدمة والتعبير عن جميع تكرارات بنيات البرمجة المنظمة باستخدام لغة البرمجة هذه.
يرتبط التفصيل خطوة بخطوة باستخدام لغة رسمية جزئيًا لتمثيل الأوصاف المحددة ، والتي تسمى الكود الكاذب. تسمح لك هذه اللغة باستخدام جميع تركيبات البرمجة المهيكلة التي تم إضفاء الطابع الرسمي عليها ، جنبًا إلى جنب مع الأجزاء غير الرسمية في اللغة الطبيعية لتمثيل العوامل والشروط العامة. يمكن أيضًا تحديد الأجزاء المقابلة في لغة البرمجة الأساسية على أنها عوامل وشروط عامة.
يمكن اعتبار وصف الرأس في الكود الكاذب هو التصميم الخارجي للوحدة النمطية في لغة البرمجة الأساسية ، والتي
بداية الوحدة في اللغة الأساسية ، أي الجملة الأولى أو العنوان (المواصفات) لهذه الوحدة ؛
قسم (مجموعة) الأوصاف في اللغة الأساسية ، وبدلاً من أوصاف الإجراءات والوظائف - تصميمها الخارجي فقط ؛
التعيين غير الرسمي لتسلسل مشغلي جسم الوحدة كمشغل عام واحد (انظر أدناه) ، بالإضافة إلى تعيين غير رسمي لتسلسل مشغلي الجسم لكل وصف لإجراء أو وظيفة كمشغل عام واحد ؛
الجملة الأخيرة (نهاية) من الوحدة في اللغة الأساسية.
مظهر وصف إجراء أو وظيفة مشابه. ومع ذلك ، إذا اتبعت Dijkstra ، فمن الأفضل تقديم قسم الأوصاف هنا مع تسمية غير رسمية ، مع جعل التفاصيل الخاصة به في شكل وصف منفصل.
يتم التعيين غير الرسمي للمشغل المعمم في الكود الكاذب بلغة طبيعية من خلال جملة تعسفية تحدد محتواها. الشرط الرسمي الوحيد لتصميم مثل هذا التعيين هو ما يلي: يجب أن تشغل هذه الجملة سطرًا أو أكثر من الخطوط الرسومية (المطبوعة) بالكامل وتنتهي بنقطة.
لكل مشغل معمم غير رسمي ، يجب إنشاء وصف منفصل يعبر عن منطق تشغيله (يوضح بالتفصيل محتواه) باستخدام تكوين الهياكل الأساسية للبرمجة المهيكلة والمشغلين المعممين الآخرين. يجب أن يكون عنوان هذا الوصف هو التعيين غير الرسمي للمشغل العام المفصل. يمكن تمثيل الهياكل الأساسية للبرمجة المهيكلة بالشكل التالي (انظر الشكل 8.2). هنا ، يمكن تعيين الشرط بشكل صريح في لغة البرمجة الأساسية كتعبير منطقي ، أو يمكن تمثيله بشكل غير رسمي بلغة طبيعية من خلال جزء معين يوضح معنى هذا الشرط. في الحالة الأخيرة ، يجب إنشاء وصف منفصل يوضح بالتفصيل هذا الشرط ، مما يشير إلى تعيين هذا الشرط (جزء في اللغة الطبيعية) كعنوان.
تين. 8.2 التركيبات الأساسية للبرمجة المهيكلة في الكود الكاذب.
تين. 8.3 حالات خاصة لعامل الانتقال كعامل عام.
كمعامل معمم على الكود الكاذب ، يمكن استخدام الحالات الخاصة المذكورة أعلاه لمشغل الانتقال (انظر الشكل 8.3). يتم تحديد تسلسل معالجات الاستثناءات (الاستثناءات) في نهاية الوحدة النمطية أو وصف الإجراء (الوظيفة). يبدو كل معالج مثل:
استثناء استثناء_اسم
Generic_operator
كل الاستثناءات
الفرق بين معالج الاستثناء وإجراء بدون معلمات هو كما يلي: بعد تنفيذ الإجراء ، يعود التحكم إلى المشغل بعد الاستدعاء إليه ، وبعد تنفيذ الاستثناء ، يعود التحكم إلى المشغل بعد استدعاء الوحدة النمطية أو الإجراء (الوظيفة) ، الذي (الذي) يتم وضع هذا الاستثناء في نهايته.
يوصى في كل خطوة بالتفصيل بإنشاء وصف ذي مغزى كافٍ ، ولكن يسهل رؤيته (وصفي) ، بحيث يتم وضعه في صفحة واحدة من النص. عادة ، هذا يعني أن مثل هذا الوصف يجب أن يكون عبارة عن تكوين من خمسة أو ستة بنيات برمجة منظمة. يوصى أيضًا بوضع هياكل متداخلة مع تحول إلى اليمين من خلال عدة مواضع (انظر الشكل 8.4). نتيجة لذلك ، من الممكن الحصول على وصف لمنطق العمل من حيث الوضوح ، والذي يتنافس تمامًا مع المخططات الكتل ، ولكن له ميزة كبيرة - يظل الوصف الخطي.
احذف السجلات الموجودة في الملف قبل الأول ،
مرشح مرضي:
اضبط بداية الملف.
إذا كان يرضي الدخول المنتظم
تصفية إلى
احذف الإدخال العادي من الملف.
الكل إذا
وداعا
إذا لم يتم حذف السجلات بعد ذلك
اطبع "لا يتم حذف الإدخالات".
اطبع "السجلات المحذوفة".
الكل إذا
يُنسب إلى Dijkstra أحيانًا فكرة التفصيل خطوة بخطوة. ومع ذلك ، اقترح Dijkstra طريقة مختلفة جوهريًا لبناء نص الوحدة ، والتي نعتقد أنها أعمق وأكثر واعدة. أولاً ، إلى جانب توضيح المشغلين ، اقترح تدريجيًا (خطوة بخطوة) تحسين (تفاصيل) هياكل البيانات المستخدمة. ثانيًا ، اقترح في كل خطوة إنشاء آلة افتراضية للتفصيل ، ووفقًا لشروطها ، لتفصيل جميع المفاهيم المصقولة التي تسمح هذه الآلة بإنجازها. وهكذا ، اقترح Dijkstra ، في جوهره ، التفصيل بواسطة الطبقات الأفقية ، وهو نقل لفكرته عن الأنظمة ذات الطبقات (انظر المحاضرة 6) إلى مستوى تطوير الوحدة. هذه الطريقة في تطوير الوحدة مدعومة حاليًا بواسطة حزم لغة ADA وأدوات البرمجة الموجهة للكائنات.
8.4 التحكم في وحدة البرنامج.
يتم استخدام الطرق التالية للتحكم في وحدة البرنامج:
فحص ثابت لنص الوحدة ؛
تتبع من طرف إلى طرف ؛
دليل على خصائص وحدة البرنامج.
عند فحص نص الوحدة بشكل ثابت ، تتم قراءة هذا النص من البداية إلى النهاية للعثور على أخطاء في الوحدة. عادة ، في مثل هذا الفحص ، بالإضافة إلى مطور الوحدة ، يشارك واحد أو حتى عدة مبرمجين. يوصى بعدم تصحيح الأخطاء المكتشفة أثناء هذا الفحص على الفور ، ولكن عند الانتهاء من قراءة نص الوحدة.
التتبع هو أحد أنواع التحكم الديناميكي في الوحدة. كما يتضمن أيضًا العديد من المبرمجين الذين يقومون بالتمرير يدويًا خلال تنفيذ الوحدة (المشغل حسب المشغل في التسلسل التالي من منطق الوحدة) في مجموعة معينة من الاختبارات.
المحاضرة القادمة مخصصة لإثبات خصائص البرامج. وتجدر الإشارة هنا فقط إلى أن هذه الطريقة نادراً ما تستخدم حتى الآن.
أدب المحاضرة 8.
8.2 إي ديكسترا. ملاحظات حول البرمجة المهيكلة // W. Dahl، E. Dijkstra، K. Hoore. برمجة منظمة. - م: مير ، 1975. - ص 24-97.
8.3 ن. فيرت. البرمجة المنهجية. - م: مير ، 1977. - ص 94-164.
المحاضرة 9. إثبات خصائص البرنامج
مفهوم مبرر البرنامج. إضفاء الطابع الرسمي على خصائص البرنامج ، ثالوث الحور. قواعد لتعيين خصائص عامل التعيين والعوامل الشرطية والمركبة. قواعد لتحديد خصائص مشغل الحلقة ، مفهوم الحلقة الثابتة. اكتمال تنفيذ البرنامج.
9.1 تبرير البرامج. إضفاء الطابع الرسمي على خصائص البرنامج.
لتحسين موثوقية البرنامج ، من المفيد جدًا تزويد البرامج بمعلومات إضافية ، يمكنك من خلالها زيادة مستوى التحكم في البرنامج بشكل كبير. يمكن تحديد هذه المعلومات في شكل بيانات غير رسمية أو رسمية مرتبطة بأجزاء مختلفة من البرامج. سوف نطلق على مثل هذه التصريحات مبررات للبرنامج. يمكن أن تشرح المبررات غير الرسمية للبرامج ، على سبيل المثال ، الدوافع لاتخاذ قرارات معينة ، والتي يمكن أن تسهل بشكل كبير البحث عن الأخطاء وتصحيحها ، وكذلك دراسة البرامج مع الحفاظ عليها. تسمح المبررات الرسمية للمرء بإثبات بعض خصائص البرامج يدويًا والتحكم فيها (ضبطها) تلقائيًا.
أحد المفاهيم المستخدمة حاليًا للتبرير الرسمي للبرامج هو استخدام ما يسمى بـ Hoor triads. لنفترض أن S يكون عاملًا معممًا على بيئة المعلومات IS و P و Q - بعض المسندات (البيانات) على هذه البيئة. ثم يسمى الترميز (P) S (Q) ثالوث Hoor ، حيث يسمى المسند P الشرط المسبق ويسمى المسند Q الحالة اللاحقة فيما يتعلق بالمشغل S. المشغل (على وجه الخصوص ، البرنامج) S هو يُقال أن لديك الخاصية (P) S (Q) إذا كان المسند P صحيحًا قبل تنفيذ المشغل S ، بعد تنفيذ هذا المشغل S ، سيكون المسند Q صحيحًا.
أمثلة بسيطة لخصائص البرنامج:
(9.1) (ن = 0) ن: = ن + 1 (ن = 1) ،
(9.2) (رقم
(9.3) (رقم
(9.4) (ن> 0) ص: = 1 ؛ م: = 1 ؛
بينما m / = n DO
وداعا
لإثبات ملكية البرنامج S ، يتم استخدام خصائص المشغلين البسيطين للغة البرمجة (هنا نقصر أنفسنا على عامل فارغ ومشغل تخصيص) وخصائص هياكل التحكم (التراكيب) ، والتي تساعد على تم بناء البرنامج من عوامل تشغيل بسيطة (سنقتصر هنا على ثلاثة تركيبات أساسية للبرمجة المهيكلة ، انظر المحاضرة الثامنة). يشار إلى هذه الخصائص عادةً باسم قواعد التحقق من البرنامج.
9.2. خصائص العوامل البسيطة.
لعامل فارغ ، ما يلي صالح
نظرية 9.1. دع P يكون مسندًا على بيئة المعلومات. ثم تحتفظ الممتلكات (P) (P).
إن الدليل على هذه النظرية واضح: لا يغير عامل التشغيل الفارغ حالة بيئة المعلومات (وفقًا لدلالاتها) ، وبالتالي يظل شرطها المسبق صحيحًا حتى بعد تنفيذه.
يرضي عامل التخصيص
نظرية 9.2. دع بيئة معلومات IS تتكون من المتغير X وبقية بيئة معلومات RIS:
ثم الملكية
(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 مثال على خاصية عامل التخصيص.
9.3 خصائص الهياكل الأساسية للبرمجة المهيكلة.
دعونا الآن نفكر في خصائص الهياكل الرئيسية للبرمجة المهيكلة: التعاقب والتفرع والتكرار.
يتم التعبير عن الخصائص التالية من خلال ما يلي
نظرية 9.3. دع P و Q و R تكون مسندات على بيئة المعلومات ، و S1 و S2 يكونان عاملين معمرين بالخصائص
(P) S (Q) و (Q) S2 (R).
ثم للمشغل المركب
S1 ؛ S2<.blockquote>
يحمل العقار
(ع) ق 1 ؛ S2 (ص).
شهادة. دع المسند P يكون صحيحًا لبعض حالة بيئة المعلومات قبل تنفيذ المشغل S1. ثم ، بحكم خاصية المشغل S1 ، بعد تنفيذه ، سيكون المسند Q صحيحًا. نظرًا لأنه ، وفقًا للدلالات من المشغل المركب ، بعد تنفيذ المشغل S1 ، سيتم تنفيذ المشغل S2 ، وسيكون المسند Q صحيحًا وقبل تنفيذ العبارة S2. لذلك ، بعد تنفيذ المشغل S2 ، بحكم ممتلكاته ، فإن المسند R سيكون صحيحًا ، وبما أن المشغل S2 ينهي تنفيذ المشغل المركب (وفقًا لدلالاته) ، فإن المسند R سيكون صحيحًا بعد تنفيذ هذا المشغل المركب الذي كان مطلوبًا لإثباته.
على سبيل المثال ، إذا كانت الخصائص (9.2) و (9.3) مثبتة ، فعندئذ يكون لها
الموقع والممتلكات
(ن
تعبر الخاصية المتفرعة عما يلي
نظرية 9.4. دع P و Q و R تكون مسندات على بيئة المعلومات ، و S1 و S2 يكونان عاملين معمرين بالخصائص
(P ، Q) S1 (R) و ('P ، Q) S2 (R).
ثم للعامل الشرطي
إذا كان P ثم S1 ELSE S2 الكل إذا
يحمل العقار
(س) إذا كان 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 => أنا و (أنا ، `س) => ص ،
ودع S يكون عاملاً معممًا بالخاصية (I) S (I).
ثم لمشغل الحلقة
بينما Q هل كل شيء بينما
يحمل العقار
(P) بينما Q هل كل شيء حتى الآن (R).
يسمى المسند I ثابت مشغل الدورة.
شهادة. لإثبات هذه النظرية ، يكفي إثبات الملكية
(I) بينما Q هل كل شيء بينما (أنا ، `س)
(بواسطة نظرية 9.5 على أساس الآثار المترتبة في شروط هذه النظرية). دع المسند يكون صحيحًا بالنسبة لبعض حالة بيئة المعلومات قبل تنفيذ مشغل الدورة. إذا كان المسند Q ، في هذه الحالة ، خاطئًا ، فسيكون مشغل الدورة مساويًا للمشغل الفارغ (وفقًا لدلالاته ) ووفقًا للنظرية 9.1 ، بعد تنفيذ مشغل الدورة ، العبارة (I ، `Q). إذا كان المسند Q صحيحًا قبل تنفيذ مشغل الدورة ، فيمكن تمثيل مشغل الدورة ، وفقًا لدلالاته ، كمشغل مركب S ؛ بينما Q هل كل شيء بينما
بحكم خاصية المشغل S ، بعد تنفيذه ، فإن المسند سأكون صحيحًا ، وينشأ موقف أولي لإثبات خاصية مشغل الدورة: المسند I صحيح قبل تنفيذ مشغل الدورة ، ولكن بالفعل بالنسبة لآخر (تم تغيير) حالة بيئة المعلومات (التي يمكن أن يكون المسند Q إما صحيحًا أو خاطئًا). إذا انتهى تنفيذ مشغل الدورة ، ثم تطبيق طريقة الاستقراء الرياضي ، في عدد محدود من الخطوات ، سنصل إلى حالة تكون فيها العبارة (I ، `Q) صحيحة قبل تنفيذها. وفي هذه الحالة ، كما تم إثباته أعلاه ، ستكون هذه العبارة صحيحة أيضًا بعد تنفيذ مشغل الحلقة. تم إثبات النظرية.
على سبيل المثال ، مشغل الحلقة من المثال (9.4) له الخاصية
م: = م + 1 ؛ ع: = ص * م
كل شيء حتى الآن (ع = ن.!}
هذا يتبع من نظرية 9.6 ، حيث أن ثابت مشغل هذه الدورة هو المسند p = m! والآثار المترتبة على ذلك صحيحة (ن> 0 ، ف = 1 ، م = 1) => ع = م! و (ع = م! ، م = ن) => ص = ن!
9.4 اكتمال تنفيذ البرنامج.
أحد خصائص البرنامج ، التي قد نهتم بها ، من أجل تجنب الأخطاء المحتملة في SS ، هو اكتماله ، أي عدم وجود حلقات فيها مع بيانات أولية معينة. في البرامج المنظمة التي درسناها ، يمكن أن يكون مصدر التكرار فقط مصدرًا للتكرار. لذلك ، لإثبات إنهاء البرنامج ، يكفي أن تكون قادرًا على إثبات إنهاء مشغل الدورة. ما يلي مفيد لهذا.
نظرية 9.7. دع F تكون دالة عدد صحيح تعتمد على حالة بيئة المعلومات وتفي بالشروط التالية:
(1) إذا كان المسند Q صحيحًا بالنسبة لحالة معينة من بيئة المعلومات ، فإن قيمتها تكون إيجابية ؛
(2) يتناقص عندما تتغير حالة بيئة المعلومات نتيجة لتنفيذ المشغل S.
ثم تنفيذ مشغل الحلقة
بينما يكتمل Q DO S ALL بينما يكتمل.
شهادة. دعنا نكون حالة بيئة المعلومات قبل تنفيذ مشغل الدورة ودع F (is) = k. إذا كان المسند Q (is) خاطئًا ، فإن تنفيذ تعليمة loop ينتهي. إذا كانت Q (هي) صحيحة ، فحينئذٍ من خلال فرضية النظرية k> 0. في هذه الحالة ، سيتم تنفيذ جملة S مرة واحدة أو أكثر. بعد كل تنفيذ للمشغل S ، وفقًا لفرضية النظرية ، تقل قيمة الوظيفة F ، ومنذ ذلك الحين قبل تنفيذ المشغل S ، يجب أن يكون المسند Q صحيحًا (وفقًا لدلالات مشغل الدورة) ، يجب أن تكون قيمة الوظيفة F في هذه اللحظة موجبة (وفقًا لشروط النظرية). لذلك ، نظرًا للقيمة الصحيحة للدالة F ، يمكن تنفيذ المشغل S في هذه الحلقة أكثر من k مرة. تم إثبات النظرية.
على سبيل المثال ، على سبيل المثال مشغل الدورة المذكورة أعلاه ، يتم استيفاء شروط النظرية 9.7 من خلال الوظيفة f (n ، m) = n-m. نظرًا لأنه قبل تنفيذ مشغل الحلقة m = 1 ، سيتم تنفيذ جسم هذه الحلقة (n-1) مرات ، أي ينتهي بيان الحلقة هذا.
9.5 مثال على إثبات خاصية البرنامج.
استنادًا إلى القواعد المثبتة للتحقق من البرنامج ، من الممكن إثبات خصائص البرامج التي تتكون من مشغلي المهام والمشغلين الفارغين واستخدام ثلاثة تركيبات رئيسية من البرمجة المهيكلة. للقيام بذلك ، وتحليل هيكل البرنامج واستخدام الشروط المسبقة واللاحقة المحددة ، من الضروري تطبيق قاعدة تحقق مناسبة في كل خطوة من خطوات التحليل. إذا كنت تستخدم تركيبة التكرار ، فستحتاج إلى اختيار حلقة ثابتة ثابتة.
كمثال ، دعونا نثبت الملكية (9.4). يتكون هذا الدليل من الخطوات التالية.
(الخطوة 1). ن> 0 => (ن> 0 ، ف - أي ، م - أي).
(الخطوة 2). يحدث
(ن> 0 ، ف - أي ، م - أي) ص: = 1 (ن> 0 ، ف = 1 ، م - أي).
بواسطة Theorem 9.2.
(الخطوه 3). يحدث
(ن> 0 ، ف = 1 ، م - أي) م: = 1 (ن> 0 ، ف = 1 ، م = 1).
بواسطة Theorem 9.2.
(الخطوة 4). يحدث
(ن> 0 ، ف - أي ، م - أي) ص: = 1 ؛ م: = 1 (ن> 0 ، ف = 1 ، م = 1).
حسب النظرية 9.3 ، في ضوء نتائج الخطوتين 2 و 3.
دعونا نثبت أن المسند p = m! هي دورة ثابتة ، أي (ع = م m:=m+1; p:=p*m {p=m!}.!}
(الخطوة 5). يحدث (ع = م m:=m+1 {p=(m-1)!}.!}
حسب النظرية 9.2 ، إذا كنا نمثل الشرط المسبق في الشكل (p = ((m + 1) -1).!}
(الخطوة 6). يحدث (ع = (م -1) p:=p*m {p=m!}.!}
حسب النظرية 9.2 ، إذا كنا نمثل الشرط المسبق بالصيغة (p * m = m.!}
(الخطوة 7). هناك دورة ثابتة
(ع = م m:=m+1; p:=p*m {p=m!}.!}
حسب النظرية 9.3 ، في ضوء نتائج الخطوتين 5 و 6.
(الخطوة 8). يحدث
(n> 0، p = 1، m = 1) بينما m / = n DO
م: = م + 1 ؛ ع: = ص * م
كل شيء حتى الآن (ع = ن.!}
وفقًا للنظرية 9.6 ، بفضل نتيجة الخطوة 7 مع الأخذ في الاعتبار أن (n> 0، p = 1، m = 1) => p = m!؛ (ع = م! ، م = ن) => ص = ن!
(الخطوة 9). يحدث
(ن> 0 ، ف - أي ، م - أي) ص: = 1 ؛ م: = 1 ؛
بينما m / = n DO
م: = م + 1 ؛ ع: = ص * م
كل شيء حتى الآن (ع = ن.!}
حسب النظرية 9.3 ، في ضوء نتائج الخطوتين 3 و 8.
(الخطوة 10). الملكية (9.4) من خلال نظرية 9.5 تحمل نتائج الخطوتين 1 و 9.
أدب المحاضرة 9.
9.1 م. ابراموف. عناصر البرمجة. - م: نوكا ، 1982S 85-94.
9.2. زيلكوفيتس ، أ.شو ، ج. غانون. مبادئ تطوير البرمجيات. - م: مير ، 1982 ، 98-105.
محاضرة 10. برامج الاختبار والتصحيح
مفاهيم أساسية. استراتيجية تصميم الاختبار. وصايا التصحيح. تصحيح الأخطاء واختبار وحدة البرامج دون اتصال بالإنترنت. التصحيح المعقد واختبار أدوات البرمجيات.
10.1. مفاهيم أساسية.
تصحيح أخطاء نظام برمجي هو نشاط يهدف إلى اكتشاف الأخطاء وتصحيحها في نظام برمجي باستخدام عمليات تنفيذ برامجه. اختبار نظام برمجي هو عملية تنفيذ برامجه على مجموعة بيانات معينة ، والتي تُعرف نتيجة التطبيق مسبقًا أو قواعد سلوك هذه البرامج معروفة. تسمى مجموعة البيانات المحددة اختبارًا أو مجرد اختبار. وبالتالي ، يمكن تمثيل تصحيح الأخطاء في شكل تكرارات متعددة لثلاث عمليات: الاختبار ، ونتيجة لذلك يمكن التحقق من وجود خطأ في نظام البرنامج ، وإيجاد مكان الخطأ في توثيق البرامج والبرامج ، و برامج التحرير والتوثيق من أجل القضاء على الخطأ المكتشف. بعبارات أخرى:
التصحيح = الاختبار + البحث عن الأخطاء + التحرير.
في الأدبيات الأجنبية ، غالبًا ما يُفهم تصحيح الأخطاء فقط على أنه عملية لإيجاد الأخطاء وتصحيحها (بدون اختبار) ، والتي يتم إثبات حقيقة ذلك أثناء الاختبار. في بعض الأحيان يعتبر الاختبار وتصحيح الأخطاء مترادفين. في بلدنا ، عادةً ما يتم تضمين الاختبار في مفهوم تصحيح الأخطاء ، لذلك سنتبع التقليد المعمول به. ومع ذلك ، فإن الدراسة المشتركة لهذه العمليات في هذه المحاضرة تجعل هذا التناقض غير مهم. وتجدر الإشارة ، مع ذلك ، إلى أن الاختبار يستخدم أيضًا كجزء من عملية التصديق FP (انظر المحاضرة 14).
10.2. مبادئ التصحيح وأنواعه.
يتم تحديد نجاح التصحيح إلى حد كبير من خلال التنظيم العقلاني للاختبار. أثناء تصحيح الأخطاء ، يتم اكتشاف الأخطاء التي يتم اكتشافها في PS أثناء الاختبار ويتم التخلص منها بشكل أساسي. كما لوحظ بالفعل ، لا يمكن للاختبار إثبات صحة SE ؛ في أفضل الأحوال ، يمكن أن يثبت وجود خطأ فيه. بمعنى آخر ، من المستحيل ضمان أنه من خلال اختبار نظام البرنامج بمجموعة من الاختبارات الممكنة عمليًا ، من الممكن إثبات وجود كل خطأ في نظام البرنامج. لذلك ، تنشأ مهمتان. الأول هو إعداد مثل هذه المجموعة من الاختبارات وتطبيق البرنامج عليها من أجل العثور على أكبر عدد ممكن من الأخطاء فيها. ومع ذلك ، كلما طالت مدة عملية الاختبار (وتصحيح الأخطاء بشكل عام) ، ارتفعت تكلفة البرنامج. ومن هنا جاءت المهمة الثانية: تحديد لحظة الانتهاء من تصحيح أخطاء نظام البرنامج (أو مكونه المنفصل). علامة على إمكانية الانتهاء من تصحيح الأخطاء هي اكتمال تغطية الاختبارات التي تم اجتيازها من خلال PS (أي الاختبارات التي يتم تطبيق PS عليها) للعديد من المواقف المختلفة التي تنشأ أثناء تنفيذ برامج PS ، والمظهر النادر نسبيًا من الأخطاء في PS في الجزء الأخير من عملية الاختبار. يتم تحديد الأخير وفقًا للدرجة المطلوبة من موثوقية PS المحددة في مواصفات الجودة الخاصة بها.
لتحسين مجموعة الاختبار ، أي لإعداد مجموعة من الاختبارات التي تسمح لعدد معين من الاختبارات (أو لفترة زمنية معينة مخصصة للاختبار) باكتشاف عدد أكبر من الأخطاء ، من الضروري ، أولاً ، التخطيط لهذه المجموعة مسبقًا و ، ثانيًا ، استخدام اختبارات (تصميم) استراتيجية التخطيط العقلاني. يمكن أن يبدأ تصميم الاختبار فور الانتهاء من مرحلة الوصف الخارجي للبرنامج. هناك طرق مختلفة لتطوير استراتيجية تصميم الاختبار ، والتي يمكن وضعها بشكل مشروط بيانيا (انظر الشكل 9.1) بين النهجين المتطرفين التاليين. يتمثل النهج المتطرف الأيسر في أن الاختبارات مصممة فقط على أساس دراسة مواصفات نظام البرنامج (الوصف الخارجي ، ووصف الهندسة المعمارية ، ومواصفات الوحدة). في هذه الحالة ، لا يتم أخذ بنية الوحدات في الاعتبار بأي شكل من الأشكال ، أي يعتبرون الصناديق السوداء. في الواقع ، يتطلب مثل هذا النهج تعدادًا كاملاً لجميع مجموعات بيانات الإدخال ، لأنه عند استخدام جزء فقط من هذه المجموعات كاختبارات ، قد لا تعمل بعض أجزاء برامج FS على أي اختبار ، وبالتالي ، الأخطاء الواردة فيها لن تظهر. ومع ذلك ، فإن اختبار أنظمة البرامج بمجموعة كاملة من مجموعات بيانات الإدخال أمر غير عملي عمليًا. النهج الصحيح المتطرف هو أن الاختبارات مصممة بناءً على دراسة نصوص البرنامج من أجل اختبار جميع طرق تنفيذ كل برنامج. إذا أخذنا في الاعتبار وجود حلقات بعدد متغير من التكرارات في البرامج ، فقد يكون هناك عدد كبير جدًا من الطرق المختلفة لتنفيذ برامج PS ، بحيث يكون اختبارها أيضًا غير عملي عمليًا.
تقع استراتيجية تصميم الاختبار الأمثل ضمن الفترة الفاصلة بين هذه الأساليب المتطرفة ، ولكنها أقرب إلى الحافة اليسرى. يتضمن تصميم جزء كبير من الاختبارات وفقًا للمواصفات ، بناءً على المبادئ: لكل وظيفة أو فرصة مستخدمة - اختبار واحد على الأقل ، لكل منطقة ولكل حد تغيير لأي متغير إدخال - واحد على الأقل اختبار لكل حالة خاصة أو لكل استثناء محدد في المواصفات اختبار واحد على الأقل. ولكنه يتطلب أيضًا تصميم بعض الاختبارات ونصوص البرامج ، بناءً على المبدأ (على الأقل): يجب أن يعمل كل أمر في كل برنامج من خلال اختبار واحد على الأقل.
يمكن تحديد استراتيجية تصميم الاختبار الأمثل على أساس المبدأ التالي: لكل وثيقة برنامج (بما في ذلك نصوص البرنامج) مدرجة في نظام البرنامج ، يجب تصميم الاختبارات الخاصة بهم من أجل تحديد الأخطاء فيها. على أي حال ، يجب مراعاة هذا المبدأ وفقًا لتعريف أنظمة البرمجيات ومحتوى مفهوم تكنولوجيا البرمجة كتقنية لتطوير أنظمة برمجية موثوقة (انظر المحاضرة 1). في هذا الصدد ، يحدد مايرز أنواعًا مختلفة من الاختبارات اعتمادًا على نوع مستند البرنامج الذي تم على أساسه بناء الاختبارات. في بلدنا ، هناك نوعان رئيسيان من تصحيح الأخطاء (بما في ذلك الاختبار): التصحيح المستقل والمعقد. يعني التصحيح المستقل اختبار جزء من البرنامج فقط مدرج في نظام البرنامج ، والبحث عن الأخطاء التي تم إصلاحها أثناء الاختبار وتصحيحها. يتضمن في الواقع تصحيح أخطاء كل وحدة وتصحيح أخطاء اقتران الوحدات. يعني التصحيح الشامل اختبار نظام البرنامج ككل ، مع البحث عن الأخطاء وتصحيحها المسجلة أثناء الاختبار في جميع الوثائق (بما في ذلك نصوص أنظمة البرمجيات) المتعلقة بنظام البرنامج ككل. تتضمن هذه المستندات تعريف متطلبات البرنامج ومواصفات جودة البرنامج والمواصفات الوظيفية للبرنامج ووصف بنية البرنامج ونصوص البرامج.
10.3. وصايا التصحيح.
يوفر هذا القسم إرشادات عامة لتنظيم تصحيح الأخطاء. لكن أولاً ، يجب ملاحظة ظاهرة معينة تؤكد أهمية منع الأخطاء في مراحل التطوير السابقة: مع زيادة عدد الأخطاء المكتشفة والثابتة في نظام برمجي ، يزداد أيضًا الاحتمال النسبي للأخطاء غير المكتشفة فيه. هذا يرجع إلى حقيقة أنه مع زيادة عدد الأخطاء المكتشفة في نظام برمجي ، فإن فهمنا للعدد الإجمالي للأخطاء التي حدثت فيه ، وبالتالي ، إلى حد ما ، عدد الأخطاء التي لا تزال غير مكتشفة ، هو أيضًا مشتق. تؤكد هذه الظاهرة أهمية الكشف المبكر عن الأخطاء والحاجة إلى التحكم الدقيق في القرارات التي يتم اتخاذها في كل مرحلة من مراحل تطوير البرامج.
الوصية 1. النظر في اختبار مهمة رئيسية في تطوير البرمجيات ، وإسنادها إلى المبرمجين الأكثر كفاءة وموهبة ؛ لا ينصح باختبار البرنامج الخاص بك.
الوصية 2. الاختبار الجيد هو الاختبار الذي يوجد فيه احتمال كبير لاكتشاف خطأ ، وليس الاختبار الذي يوضح التشغيل الصحيح للبرنامج.
الوصية 3. إعداد الاختبارات لكل من البيانات الصحيحة وغير الصحيحة.
الوصية 4. تجنب الاختبارات غير القابلة للتكرار ، وتوثيق تمريرها عبر الكمبيوتر ؛ دراسة نتائج كل اختبار بالتفصيل.
الوصية 5. قم بتوصيل كل وحدة بالبرنامج مرة واحدة فقط ؛ لا تقم أبدًا بتعديل البرنامج لتسهيل الاختبار.
الوصية 6. تخطي مرة أخرى جميع الاختبارات المتعلقة بفحص تشغيل أي برنامج PS أو تفاعله مع البرامج الأخرى ، إذا تم إجراء تغييرات عليه (على سبيل المثال ، نتيجة لإزالة خطأ).
10.4. تصحيح وحدة حاليا.
في التصحيح المستقل ، يتم اختبار كل وحدة في الواقع في بعض بيئة البرمجة ، إلا إذا كان البرنامج الذي يتم تصحيحه يتكون من وحدة واحدة فقط. تتكون هذه البيئة من وحدات نمطية أخرى ، بعضها عبارة عن وحدات نمطية للبرنامج الذي يتم تصحيح أخطائه والتي تم تصحيحها بالفعل ، وبعضها عبارة عن وحدات نمطية تتحكم في تصحيح الأخطاء (وحدات التصحيح ، انظر أدناه). وبالتالي ، أثناء التصحيح الذاتي ، يتم دائمًا اختبار البرنامج ، المصمم خصيصًا لاختبار الوحدة التي يتم تصحيحها. يتزامن هذا البرنامج جزئيًا فقط مع البرنامج الذي يتم تصحيح أخطائه ، باستثناء الحالة التي يتم فيها تصحيح أخطاء الوحدة النمطية الأخيرة من البرنامج التي يتم تصحيحها. مع تقدم عملية تصحيح أخطاء البرنامج ، ستتكون المزيد والمزيد من بيئة الوحدة النمطية التالية التي تم تصحيحها من وحدات تم تصحيحها بالفعل من هذا البرنامج ، وعند تصحيح أخطاء الوحدة الأخيرة من هذا البرنامج ، ستتألف بيئة الوحدة النمطية المصححة بالكامل من بين جميع الوحدات النمطية الأخرى (التي تم تصحيحها بالفعل) للبرنامج الذي يتم تصحيحه (بدون أي) وحدات تصحيح الأخطاء ، أي في هذه الحالة ، سيتم اختبار البرنامج الجاري تصحيحه. تسمى عملية إنشاء برنامج تم تصحيحه باستخدام وحدات نمطية تم تصحيح أخطائها وتصحيحها بتكامل البرنامج.
تعتمد وحدات التصحيح المضمنة في بيئة الوحدة النمطية التي يتم تصحيحها على الترتيب الذي يتم به تصحيح وحدات هذا البرنامج ، وعلى أي وحدة يتم تصحيح أخطاءها ، وربما بناءً على الاختبار الذي سيتم تخطيه.
أثناء الاختبار التصاعدي (انظر المحاضرة 7) ، ستحتوي هذه البيئة دائمًا على وحدة تصحيح أخطاء واحدة فقط (باستثناء الحالة التي يتم فيها تصحيح أخطاء الوحدة الأخيرة من البرنامج) ، والتي ستكون الرأس في البرنامج قيد الاختبار والتي تسمى السيد (أو السائق). تعد وحدة تصحيح الأخطاء الرائدة بيئة المعلومات لاختبار الوحدة التي يتم تصحيحها (أي أنها تنشئ حالتها المطلوبة لاختبار هذه الوحدة ، على وجه الخصوص ، يمكنها إدخال بعض بيانات الاختبار) ، وتتناول الوحدة التي يتم تصحيح أخطائها ، وبعد اكتمالها ، يصدر الرسائل الضرورية. عند تصحيح وحدة واحدة ، يمكن تجميع وحدات تصحيح أخطاء رائدة مختلفة لاختبارات مختلفة.
في الاختبار من أعلى إلى أسفل (انظر المحاضرة 7) ، تحتوي بيئة الوحدة التي يتم تصحيحها كوحدات تصحيح أخطاء على محاكيات لجميع الوحدات التي يمكن للوحدة التي يتم تصحيح الأخطاء الوصول إليها ، بالإضافة إلى محاكيات تلك الوحدات التي يمكن الوصول إليها عن طريق الوحدات النمطية المصححة من البرنامج الجاري تصحيحه (مضمن في هذه البيئة) ، ولكن لم يتم تصحيحه بعد. بعض هذه المحاكيات ، عند تصحيح وحدة واحدة ، قد تتغير لاختبارات مختلفة.
في الواقع ، يمكن أن تحتوي بيئة الوحدة النمطية التي يتم تصحيحها في كثير من الحالات على كلا النوعين من وحدات التصحيح للأسباب التالية. لكل من الاختبار التصاعدي ومن أعلى إلى أسفل مزايا وعيوب.
تشمل مزايا الاختبار التصاعدي
سهولة تحضير الاختبارات و
القدرة على التنفيذ الكامل لخطة اختبار الوحدة.
هذا يرجع إلى حقيقة أن الحالة الاختبارية لبيئة المعلومات يتم إعدادها مباشرة قبل الوصول إلى الوحدة النمطية التي يتم تصحيح أخطائها (بواسطة وحدة تصحيح الأخطاء الرائدة). عيوب الاختبار التصاعدي هي كما يلي:
يتم إعداد بيانات الاختبار ، كقاعدة عامة ، ليس بالشكل المصمم للمستخدم (باستثناء الحالة التي يتم فيها تصحيح أخطاء آخر وحدة رئيسية للبرنامج الذي يتم تصحيحه) ؛
قدر كبير من برمجة التصحيح (عند تصحيح أخطاء وحدة واحدة ، غالبًا ما يتعين عليك إنشاء العديد من وحدات تصحيح الأخطاء الرائدة لاختبارات مختلفة) ؛
الحاجة إلى اختبار خاص لوحدات الواجهة.
تشمل مزايا الاختبار التنازلي الميزات التالية:
يتم إعداد معظم الاختبارات في شكل سهل الاستخدام ؛
في كثير من الحالات ، كمية صغيرة نسبيًا من برمجة تصحيح الأخطاء (عادةً ما تكون محاكيات الوحدة بسيطة جدًا وكل منها مناسب لعدد كبير ، غالبًا كل الاختبارات) ؛
ليست هناك حاجة لاختبار اقتران الوحدات.
يتمثل عيب الاختبار التنازلي في أن حالة الاختبار لبيئة المعلومات قبل الوصول إلى الوحدة التي يتم تصحيحها يتم إعدادها بشكل غير مباشر - فهي نتيجة تطبيق الوحدات النمطية التي تم تصحيحها بالفعل لاختبار البيانات أو البيانات الصادرة عن أجهزة المحاكاة. هذا ، أولاً ، يجعل من الصعب إعداد الاختبارات ، ويتطلب مؤهلات عالية من مهندس الاختبار ، وثانيًا ، يجعل من الصعب أو حتى المستحيل تنفيذ خطة الاختبار الكاملة للوحدة التي يتم تصحيحها. يجبر هذا العيب المطورين في بعض الأحيان على تطبيق الاختبار التصاعدي حتى في حالة التطوير من أعلى إلى أسفل. ومع ذلك ، غالبًا ما يتم استخدام بعض تعديلات الاختبار من أعلى إلى أسفل ، أو مزيج من الاختبار من أعلى إلى أسفل ومن أسفل إلى أعلى.
انطلاقًا من حقيقة أن الاختبار التنازلي ، من حيث المبدأ ، هو الأفضل ، دعونا نتحدث عن التقنيات التي تسمح ، إلى حد ما ، بالتغلب على هذه الصعوبات. بادئ ذي بدء ، من الضروري تنظيم تصحيح أخطاء البرنامج بطريقة يتم فيها تصحيح أخطاء الوحدات النمطية التي تقوم بإدخال البيانات في أقرب وقت ممكن - ثم يمكن إعداد بيانات الاختبار في نموذج مصمم للمستخدم ، والذي سيكون إلى حد كبير تبسيط التحضير للاختبارات اللاحقة. لا يتم تنفيذ هذا الإدخال دائمًا في وحدة الرأس ؛ لذلك ، من الضروري أولاً وقبل كل شيء تصحيح سلاسل الوحدات التي تؤدي إلى الوحدات النمطية التي تقوم بتنفيذ المدخلات المحددة (قارن مع طريقة التنفيذ البناء الهادف في المحاضرة 7) . حتى يتم تصحيح وحدات الإدخال ، يتم توفير بيانات الاختبار بواسطة بعض أجهزة المحاكاة: إما يتم تضمينها في جهاز المحاكاة كجزء منها ، أو يتم حقنها بواسطة المحاكي.
أثناء الاختبار التنازلي ، قد لا تحدث بعض حالات بيئة المعلومات التي يكون من الضروري فيها اختبار الوحدة النمطية التي يتم تصحيح أخطائها أثناء تنفيذ البرنامج الذي يتم تصحيح أخطائه لأي بيانات إدخال. في هذه الحالات ، سيكون من الممكن عدم اختبار الوحدة النمطية التي يتم تصحيحها على الإطلاق ، لأن الأخطاء المكتشفة في هذه الحالة لن تظهر أثناء تنفيذ البرنامج الذي يتم تصحيحه لأي بيانات إدخال. ومع ذلك ، لا يوصى بالقيام بذلك ، لأنه عندما يتغير البرنامج الذي يتم تصحيحه (على سبيل المثال ، عند صيانة نظام البرنامج) ، قد تظهر بيئة المعلومات التي لم يتم استخدامها لاختبار الوحدة النمطية التي تم تصحيحها بالفعل ، الأمر الذي يتطلب اختبارًا إضافيًا لـ هذه الوحدة (وهذا لا يمكن القيام به إذا كان التصحيح منطقيًا إذا لم تتغير الوحدة نفسها). لاختبار الوحدة النمطية المصححة في هذه المواقف ، تُستخدم أحيانًا أجهزة محاكاة مناسبة لإنشاء الحالة المطلوبة لبيئة المعلومات. في كثير من الأحيان ، يستخدمون نسخة معدلة من الاختبار التنازلي ، حيث يتم اختبار الوحدات النمطية المصححة مسبقًا بشكل منفصل قبل دمجها (في هذه الحالة ، تظهر وحدة تصحيح أخطاء رائدة في بيئة الوحدة النمطية المصححة ، جنبًا إلى جنب مع محاكيات الوحدات النمطية التي يمكن للوحدة النمطية المصححة الوصول إليها). ومع ذلك ، يبدو أن هناك تعديلًا آخر للاختبار التنازلي أكثر ملاءمة: بعد الانتهاء من الاختبار التنازلي للوحدة المصححة لحالات الاختبار القابلة للتحقيق لبيئة المعلومات ، يجب اختبارها بشكل منفصل للحالات المطلوبة المتبقية لبيئة المعلومات .
غالبًا ما يتم استخدام مزيج من الاختبار التصاعدي والهابط ، والذي يسمى طريقة الشطيرة. يكمن جوهر هذه الطريقة في التنفيذ المتزامن لكل من الاختبار التصاعدي ومن أعلى إلى أسفل ، حتى تلتقي عمليتا الاختبار هاتان في بعض الوحدات النمطية في مكان ما في منتصف هيكل البرنامج الذي يتم تصحيحه. تسمح هذه الطريقة ، من خلال نهج معقول ، بالاستفادة من مزايا الاختبار من أسفل إلى أعلى ومن أعلى إلى أسفل وتحييد عيوبها إلى حد كبير. هذا التأثير هو مظهر من مظاهر مبدأ أكثر عمومية: يمكن تحقيق أكبر تأثير تكنولوجي من خلال الجمع بين أساليب من أعلى إلى أسفل ومن أسفل إلى أعلى لتطوير برامج تنظيم الأسرة. لدعم هذه الطريقة هو المقصود من النهج المعماري لتطوير البرمجيات (انظر المحاضرة 7): طبقة من الوحدات التي تم تطويرها بمهارة واختبارها بدقة تسهل إلى حد كبير تنفيذ مجموعة من البرامج في مجال الموضوع المقابل وتحديثها اللاحق.
من المهم جدًا لتصحيح الأخطاء في وضع عدم الاتصال اختبار اقتران الوحدات. الحقيقة هي أن مواصفات كل وحدة برنامج ، باستثناء الرأس الأول ، تُستخدم في هذا البرنامج في حالتين: أولاً ، عند تطوير النص (أحيانًا يقولون: الجسم) لهذه الوحدة ، وثانيًا ، عند كتابة استدعاء هذه الوحدة في وحدات أخرى من البرنامج. في كلتا الحالتين ، نتيجة لحدوث خطأ ، قد يتم انتهاك الامتثال المطلوب لمواصفات الوحدة المحددة. يجب اكتشاف مثل هذه الأخطاء والقضاء عليها. هذا هو الغرض من اختبار الواجهة بين الوحدات. في الاختبار التنازلي ، يتم إجراء اختبار الاقتران على طول الطريق مع كل اختبار يتم تخطيه ، والذي يعتبر أقوى ميزة للاختبار التنازلي. أثناء الاختبار التصاعدي ، لا يتم إنشاء عنوان الوحدة النمطية المصححة من الوحدات النمطية للبرنامج الجاري تصحيحه ، ولكن من مصحح الأخطاء الرئيسي. في هذا الصدد ، هناك خطر من أن الوحدة الأخيرة يمكن أن تتكيف مع بعض "أخطاء" الوحدة النمطية المصححة. لذلك ، عند بدء (في عملية تكامل البرنامج) تصحيح أخطاء وحدة نمطية جديدة ، يجب عليك اختبار كل استدعاء لوحدة تم تصحيحها مسبقًا من أجل اكتشاف عدم تناسق هذه المكالمة مع جسم الوحدة النمطية المقابلة (ومن الممكن أن الوحدة النمطية التي تم تصحيحها مسبقًا هي المسؤولة عن هذا). وبالتالي ، من الضروري تكرار اختبار وحدة تم تصحيحها مسبقًا جزئيًا في ظل ظروف جديدة ، بينما تظهر نفس الصعوبات كما هو الحال في الاختبار من أعلى إلى أسفل.
يُنصح بإجراء اختبار دون اتصال للوحدة النمطية بأربع خطوات متتالية.
الخطوة 1. بناءً على مواصفات الوحدة النمطية التي يتم تصحيحها ، قم بإعداد اختبار لكل احتمال وكل حالة ، لكل حد من نطاق القيم الصالحة لجميع المدخلات ، لكل نطاق من تغييرات البيانات ، لكل نطاق غير صالح قيم جميع المدخلات وكل شرط غير صالح.
الخطوة الثانية. تحقق من نص الوحدة للتأكد من أن كل اتجاه لأي فرع سوف يجتاز اختبارًا واحدًا على الأقل. أضف الاختبارات المفقودة.
الخطوة الثالثة: تأكد من نص الوحدة النمطية من وجود اختبار لكل حلقة لا يتم تنفيذ جسم الحلقة من أجله ، واختبار يتم من أجله تنفيذ جسم الحلقة مرة واحدة ، والاختبار الذي يتم من أجله تنفيذ جسم الحلقة بأقصى عدد من المرات. أضف الاختبارات المفقودة.
الخطوة 4. تحقق في نص الوحدة من حساسيتها للقيم الخاصة الفردية لبيانات الإدخال - يجب تضمين جميع هذه القيم في الاختبارات. أضف الاختبارات المفقودة.
10.5. تصحيح أخطاء البرامج المعقدة.
كما هو مذكور أعلاه ، أثناء التصحيح المعقد ، يتم اختبار نظام البرنامج ككل ، ويتم إعداد الاختبارات لكل من مستندات البرنامج. يتم إجراء اختبار هذه المستندات ، كقاعدة عامة ، بالترتيب العكسي لتطورها (الاستثناء الوحيد هو اختبار وثائق التطبيق ، والتي يتم تطويرها وفقًا لوصف خارجي بالتوازي مع تطوير نصوص البرنامج ؛ هذا الاختبار هو الأفضل بعد اختبار الوصف الخارجي). الاختبار مع التصحيح المعقد هو تطبيق أنظمة برمجية على بيانات محددة قد تنشأ ، من حيث المبدأ ، من المستخدم (على وجه الخصوص ، يتم إعداد جميع الاختبارات في نموذج مصمم للمستخدم) ، ولكن ، ربما ، في محاكاة (وليس في الواقع) البيئة. على سبيل المثال ، يمكن استبدال بعض أجهزة الإدخال والإخراج غير المتوفرة في تصحيح الأخطاء المعقدة بمحاكيات البرامج الخاصة بهم.
اختبار معمارية PS. الغرض من الاختبار هو العثور على تناقض بين وصف البنية ومجموعة البرامج. بحلول الوقت الذي يبدأ فيه اختبار بنية PS ، يجب أن يكون التصحيح المستقل لكل نظام فرعي قد اكتمل بالفعل. يمكن أن ترتبط الأخطاء في تنفيذ البنية في المقام الأول بتفاعل هذه الأنظمة الفرعية ، على وجه الخصوص ، مع تنفيذ الوظائف المعمارية (إن وجدت). لذلك ، أود التحقق من جميع طرق التفاعل بين الأنظمة الفرعية لـ PS. ولكن نظرًا لأنه قد يكون هناك عدد كبير جدًا منها ، فمن المستحسن اختبار جميع سلاسل تنفيذ الأنظمة الفرعية على الأقل دون إعادة الدخول إلى الأخير. إذا كانت البنية المعينة تمثل PS كنظام صغير من الأنظمة الفرعية المخصصة ، فسيكون عدد هذه السلاسل مرئيًا تمامًا.
اختبار الوظائف الخارجية. الغرض من الاختبار هو العثور على التناقضات بين المواصفات الوظيفية ومجموعة البرامج. على الرغم من حقيقة أن جميع هذه البرامج قد تم تصحيحها بالفعل بشكل مستقل ، فقد تكون التناقضات المشار إليها ، على سبيل المثال ، بسبب عدم تناسق المواصفات الداخلية للبرامج ووحداتها (التي تم على أساسها إجراء الاختبار المستقل) مع المواصفات الوظيفية الخارجية لنظام البرنامج. كقاعدة عامة ، يتم إجراء اختبار الوظائف الخارجية بنفس طريقة اختبار الوحدات في الخطوة الأولى ، أي مثل الصندوق الأسود.
اختبار جودة PS. الغرض من الاختبار هو العثور على انتهاكات لمتطلبات الجودة المصاغة في مواصفات جودة نظام البرنامج. هذا هو الاختبار الأكثر صعوبة والأقل دراسة. من الواضح فقط أنه لا يمكن اختبار كل بدائية من جودة البرامج عن طريق الاختبار (حول تقييم جودة البرامج ، انظر المحاضرة التالية). يتم التحقق من اكتمال PS بالفعل عند اختبار الوظائف الخارجية. في هذه المرحلة ، يمكن مواصلة اختبار هذه الجودة الأولية إذا كان مطلوبًا للحصول على أي تقدير احتمالي لدرجة موثوقية PS. ومع ذلك ، لا تزال منهجية مثل هذا الاختبار بحاجة إلى التطوير. يمكن اختبار الدقة والمتانة والأمان وكفاءة الوقت وكفاءة الذاكرة إلى حد ما وكفاءة الجهاز وقابلية التوسع واستقلالية الجهاز جزئيًا. كل نوع من هذه الأنواع من الاختبارات له خصائصه الخاصة ويستحق دراسة منفصلة. سنقتصر هنا فقط على تعدادهم. يتم تقييم سهولة تطبيق PS (معيار الجودة الذي يتضمن العديد من العناصر الأولية للجودة ، انظر المحاضرة 4) عند اختبار التوثيق لتطبيق PS.
وثائق اختبار لتطبيق PS. الغرض من الاختبار هو العثور على التناقضات بين وثائق التطبيق ومجموعة البرامج ، بالإضافة إلى مضايقات استخدام البرنامج. تسبق هذه المرحلة مباشرة توصيل المستخدم بإكمال تطوير البرنامج (اختبار متطلبات البرنامج والتصديق على البرنامج) ، لذلك من المهم جدًا للمطورين استخدام البرنامج أولاً كما سيفعله المستخدم. يتم إعداد جميع الاختبارات في هذه المرحلة فقط على أساس الوثائق الخاصة بتطبيق PS. بادئ ذي بدء ، يجب اختبار قدرات البرنامج كما تم عند اختبار الوظائف الخارجية ، ولكن فقط على أساس وثائق التطبيق. يجب اختبار أي نقاط غامضة في الوثائق ، وكذلك جميع الأمثلة المستخدمة في الوثائق. علاوة على ذلك ، يتم اختبار أصعب حالات تطبيق PS من أجل الكشف عن انتهاك لمتطلبات النسبية لسهولة تطبيق PS.
اختبار تعريف متطلبات PS. الغرض من الاختبار هو معرفة إلى أي مدى لا يفي نظام البرنامج بالتعريف المحدد لمتطلباته. تكمن خصوصية هذا النوع من الاختبارات في أنه يتم إجراؤه بواسطة المنظمة الشرائية أو منظمة المستخدم لنظام البرمجيات كإحدى طرق التغلب على الحاجز بين المطور والمستخدم (انظر المحاضرة 3). عادةً ما يتم إجراء هذا الاختبار باستخدام مهام التحكم - وهي مهام نموذجية تُعرف نتيجة الحل لها. في الحالات التي يجب أن يحل فيها نظام البرنامج المطور محل إصدار آخر من نظام البرنامج ، والذي يحل جزءًا على الأقل من مهام نظام البرنامج المطور ، يتم إجراء الاختبار عن طريق حل المشكلات الشائعة باستخدام كل من أنظمة البرامج القديمة والجديدة مع المقارنة اللاحقة بين النتائج التي تم الحصول عليها. في بعض الأحيان ، كشكل من أشكال هذا الاختبار ، يستخدمون التشغيل التجريبي لـ PS - وهو تطبيق محدود لـ PS جديد مع تحليل لاستخدام النتائج في الأنشطة العملية. من حيث الجوهر ، فإن هذا النوع من الاختبارات له الكثير من القواسم المشتركة مع اختبار PS أثناء تصديقه (انظر المحاضرة 14) ، ولكن يتم إجراؤه قبل التصديق ، وأحيانًا بدلاً من التصديق.
أدب المحاضرة 10.
10.1. جي مايرز. موثوقية البرنامج. - م: مير ، 1980. - س 171-262.
10.2. دي فان تاسيل. الأسلوب والتطوير والكفاءة وتصحيح الأخطاء واختبار البرامج. - م: مير ، 1985. - س 179-295.
10.3. جيه. هيوز ، ج. ميتشتوم. نهج منظم للبرمجة. - م: مير ، 1980. - س 254-268.
10.4. جي فوكس. البرمجيات وتطويرها. - م: مير ، 1985. - س 227-241.
10.5. زيلكويتز ، أ.شو ، ج. غانون. مبادئ تطوير البرمجيات. - م: مير ، 1982. - س 105-116.
10.6. يو. Bezborodov. التصحيح الفردي للبرامج. - م: نوكا ، 1982. - ص 9-79.
10.7. في. ليباييف. برامج الاختبار. - م: الراديو والاتصالات ، 1986. - ص 15-47.
10.8. إي. Zhogolev. مقدمة في تكنولوجيا البرمجة (ملاحظات محاضرة). - م: "DIALOG-MGU" ، 1994.
10.9. إي ديكسترا. ملاحظات حول البرمجة المهيكلة. // U. داهل ، إي ديجكسترا ، ك. هوور. برمجة منظمة. - م: مير ، 1975. - ص 7-13.
محاضرة 11. ضمان وظائف وموثوقية البرنامج
11.1. الوظيفة والموثوقية كمعايير إلزامية لجودة أداة البرمجيات.
في المحاضرة السابقة قمنا بفحص جميع مراحل تطوير البرمجيات ماعدا شهادتها. في الوقت نفسه ، لم نتطرق إلى قضايا ضمان جودة PS وفقًا لمواصفات الجودة الخاصة بها (انظر المحاضرة 4). صحيح ، أثناء تنفيذ المواصفات الوظيفية لـ PS ، ناقشنا بالتالي القضايا الرئيسية لضمان معيار الوظيفة. بعد أن أعلننا عن موثوقية نظام البرنامج باعتباره السمة الرئيسية له (انظر المحاضرة 1) ، اخترنا منع الأخطاء كنهج رئيسي لضمان موثوقية نظام البرنامج (انظر المحاضرة 3) وناقشنا تنفيذه في مراحل مختلفة من تطوير البرمجيات. وهكذا ، تم توضيح الأطروحة حول الوظيفة الإلزامية وموثوقية نظام البرنامج كمعايير لجودته.
ومع ذلك ، قد تحتوي مواصفات جودة نظام البرنامج على خصائص إضافية لهذه المعايير ، والتي يتطلب توفيرها مناقشة خاصة. هذه المحاضرة مخصصة لهذه الأسئلة. سيتم مناقشة ضمان معايير الجودة الأخرى في المحاضرة القادمة.
أدناه ، نناقش توفير أساسيات جودة البرامج التي تعبر عن معايير لوظائف البرنامج وموثوقيته.
11.2. التأكد من اكتمال البرنامج.
اكتمال PS هو المبدأ الأساسي العام لنوعية PS للتعبير عن كل من وظائف وموثوقية PS ، وبالنسبة للوظيفة فهو البدائي الوحيد (انظر المحاضرة 4).
يتم تحديد وظيفة نظام البرنامج من خلال المواصفات الوظيفية. إن اكتمال PS كإجراء بدائي لجودته هو مقياس لكيفية تنفيذ هذه المواصفات في PS المعطى. يعني توفير هذه البدائية في مجملها تنفيذ كل وظيفة من الوظائف المحددة في المواصفات الوظيفية ، مع كل التفاصيل والميزات المحددة هناك. توضح جميع العمليات التكنولوجية التي نوقشت سابقًا كيف يمكن القيام بذلك.
ومع ذلك ، في مواصفات جودة نظام البرنامج ، يمكن تحديد عدة مستويات لتنفيذ وظائف البرنامج: يمكن تحديد إصدار مبسط معين (أولي أو أولي) ، والذي يجب تنفيذه في المقام الأول ، وعدة مستويات وسيطة يمكن أيضًا تعريف الإصدارات. في هذه الحالة ، تنشأ مهمة تكنولوجية إضافية: تنظيم زيادة وظائف PS. من المهم أن نلاحظ هنا أن تطوير نسخة مبسطة من نظام البرمجيات ليس تطوير النموذج الأولي الخاص به. يتم تطوير النموذج الأولي من أجل فهم أفضل لشروط استخدام PS المستقبلية ، لتوضيح الوصف الخارجي لها. إنه مصمم لمستخدمين محددين ، وبالتالي قد يختلف اختلافًا كبيرًا عن نظام البرنامج المطلوب ليس فقط في الوظائف التي يتم تنفيذها ، ولكن أيضًا في ميزات واجهة المستخدم. يجب تصميم نسخة مبسطة من نظام البرنامج المطلوب للاستخدام العملي من قبل أي مستخدمين مخصّص لهم. لذلك ، فإن المبدأ الرئيسي لضمان وظائف مثل هذه البرامج هو تطوير البرنامج من البداية بطريقة كما لو كان البرنامج مطلوبًا بالكامل ، حتى يتعامل المطورون مع تلك الأجزاء أو تفاصيل البرنامج ، والتي يتم تنفيذها يمكن تأجيلها حسب مواصفات جودتها. وبالتالي ، يجب تطوير كل من الوصف الخارجي ووصف معمارية PS بالكامل. من الممكن فقط تأجيل تنفيذ تلك الأنظمة الفرعية للبرامج المحددة في بنية نظام البرنامج المطور ، والتي لا يلزم تشغيلها في الإصدار الأولي من نظام البرنامج هذا. من الأفضل تنفيذ الأنظمة الفرعية للبرامج نفسها من خلال طريقة التنفيذ البناء الهادف ، مع ترك المحاكيات المناسبة لوحدات البرامج هذه في الإصدار الأولي من البرنامج ، والتي لا يلزم تشغيلها في هذا الإصدار. من المقبول أيضًا التنفيذ المبسط لبعض وحدات البرامج ، مع إغفال تنفيذ بعض تفاصيل الوظائف المقابلة. ومع ذلك ، من وجهة نظر تكنولوجية ، من الأفضل النظر إلى هذه الوحدات على أنها نوع من مقلديها (وإن كانت متقدمة جدًا).
نظرًا للأخطاء في نظام البرنامج المطور ، فإن الاكتمال الذي تم تحقيقه مع ضمان وظائفه (وفقًا لمواصفات جودته) قد لا يكون في الواقع كما هو متوقع. لا يسعنا إلا أن نقول إن هذا الاكتمال قد تحقق باحتمالية معينة تحددها حجم وجودة الاختبار الذي تم إجراؤه. من أجل زيادة هذا الاحتمال ، من الضروري مواصلة اختبار نظام البرنامج وتصحيح أخطائه. ومع ذلك ، فإن تقدير مثل هذا الاحتمال هو مهمة محددة للغاية (مع الأخذ في الاعتبار حقيقة أن مظهر الخطأ في PS هو وظيفة من البيانات الأولية) ، والتي لا تزال تنتظر الدراسات النظرية المقابلة.
11.3. التأكد من دقة البرنامج.
يرتبط توفير هذه القيمة الأولية بالإجراءات على قيم الأنواع الحقيقية (بتعبير أدق ، مع القيم التي يتم تمثيلها ببعض الأخطاء). لتوفير الدقة المطلوبة عند حساب قيمة دالة معينة يعني الحصول على هذه القيمة بخطأ لا يتجاوز الحدود المحددة. تتعامل الرياضيات الحسابية مع أنواع الأخطاء وطرق تقديرها وطرق تحقيق الدقة المطلوبة (ما يسمى بالحسابات التقريبية). هنا سوف ننتبه فقط إلى بعض هيكل الخطأ: يعتمد خطأ القيمة المحسوبة (الخطأ الكلي)
بشأن خطأ طريقة الحساب المستخدمة (حيث نقوم بتضمين عدم دقة النموذج المستخدم) ،
من الخطأ في عرض البيانات المستخدمة (من ما يسمى بالخطأ الفادح) ،
من خطأ التقريب (عدم الدقة في تنفيذ العمليات المستخدمة في الطريقة).
11.4. ضمان استقلالية البرنامج.
يتم توفير هذه الجودة الأولية في مرحلة مواصفات الجودة من خلال اتخاذ قرار بشأن استخدام أي برنامج أساسي مناسب في البرنامج المطور أو عدم استخدام أي برنامج أساسي فيه. في هذه الحالة ، من الضروري مراعاة كل من موثوقيتها والموارد اللازمة لاستخدامها. مع زيادة متطلبات موثوقية نظام البرنامج المطور ، قد تصبح موثوقية البرنامج الأساسي الموجود تحت تصرف المطورين غير مرضية ، لذلك يجب التخلي عن استخدامه ، ويجب تنفيذ وظائفه في الحجم المطلوب أن يتم تضمينها في نظام البرنامج. يجب اتخاذ قرارات مماثلة مع قيود صارمة على الموارد المستخدمة (وفقًا لمعيار كفاءة PS).
11.5. ضمان استقرار البرنامج.
يتم توفير هذه الجودة البدائية من خلال ما يسمى بالبرمجة الدفاعية. بشكل عام ، يتم استخدام البرمجة الدفاعية لزيادة موثوقية PS عند برمجة وحدة بمعنى أوسع. كما يجادل مايرز ، "تستند البرمجة الدفاعية إلى فرضية مهمة: أسوأ ما يمكن أن تفعله الوحدة هو قبول إدخال غير صحيح ثم إرجاع نتيجة غير صحيحة ولكنها معقولة." من أجل تجنب ذلك ، يتضمن نص الوحدة تدقيقات لبيانات المدخلات والمخرجات الخاصة بها للتأكد من صحتها وفقًا لمواصفات هذه الوحدة ، وعلى وجه الخصوص ، استيفاء القيود المفروضة على بيانات الإدخال والإخراج والعلاقات بينهما المحدد في مواصفات الوحدة النمطية. إذا فشل الفحص ، يظهر استثناء مناظر. في هذا الصدد ، يتم تضمين أجزاء من النوع الثاني في نهاية هذه الوحدة - معالجات حالات الاستثناء المقابلة ، والتي ، بالإضافة إلى إصدار المعلومات التشخيصية اللازمة ، يمكن أن تتخذ تدابير إما لإزالة الأخطاء في البيانات (على سبيل المثال ، لطلب إعادة الدخول) ، أو إضعاف تأثير الخطأ (على سبيل المثال ، التوقف الناعم للأجهزة التي يتحكم فيها PS من أجل تجنب انهيارها في حالة الإنهاء الطارئ لتنفيذ البرنامج).
يؤدي استخدام البرمجة الدفاعية للوحدات النمطية إلى انخفاض كفاءة PS في الوقت والذاكرة. لذلك ، من الضروري تنظيم درجة تطبيق البرمجة الدفاعية بشكل معقول ، اعتمادًا على متطلبات موثوقية وكفاءة نظام البرنامج ، المصاغ في مواصفات الجودة لنظام البرنامج الجاري تطويره. يمكن أن تأتي بيانات الإدخال للوحدة التي يتم تطويرها إما مباشرة من المستخدم أو من وحدات أخرى. حالة الاستخدام الأكثر شيوعًا للبرمجة الدفاعية هي تطبيقها للمجموعة الأولى من البيانات ، مما يعني تنفيذ استقرار البرنامج. يجب القيام بذلك كلما كان هناك شرط لضمان استقرار البرنامج في مواصفات جودة PS. استخدام البرمجة الدفاعية للمجموعة الثانية من المدخلات يعني محاولة العثور على خطأ في الوحدات النمطية الأخرى أثناء تنفيذ وحدة قيد التطوير ، ولإخراج وحدة مطورة ، محاولة للعثور على خطأ في هذه الوحدة نفسها أثناء تنفيذها. في الأساس ، يعني هذا تنفيذًا جزئيًا لنهج الاكتشاف الذاتي للخطأ لضمان موثوقية البرنامج ، والذي تمت مناقشته في المحاضرة 3. نادرًا ما يتم استخدام حالة البرمجة الدفاعية هذه - فقط في حالة وجود متطلبات الموثوقية من البرنامج عالية للغاية.
11.6. ضمان أمن البرمجيات.
هناك الأنواع التالية من برامج الحماية ضد تشويه المعلومات:
الحماية من أعطال الأجهزة ؛
الحماية من تأثير برنامج "أجنبي" ؛
الحماية من فشل البرنامج "الخاص" ؛
الحماية من أخطاء المشغل (المستخدم) ؛
الحماية من الوصول غير المصرح به ؛
الحماية من الحماية.
الحماية ضد أعطال الأجهزة ليست مشكلة ملحة للغاية في الوقت الحالي (بالنظر إلى مستوى الموثوقية المحققة لأجهزة الكمبيوتر). لكن لا يزال من المفيد معرفة حلها. يتم ضمان ذلك من خلال تنظيم ما يسمى "حسابات خاطئة ثلاثية ثلاثية". لهذا ، يتم تقسيم عملية معالجة البيانات بأكملها ، التي يحددها PS ، في الوقت المناسب إلى فترات زمنية حسب ما يسمى بـ "النقاط المرجعية". يجب ألا يتجاوز هذا الفاصل نصف MTBF للكمبيوتر. يتم كتابة نسخة من حالة الذاكرة المتغيرة في هذه العملية لكل نقطة مرجعية في الذاكرة الثانوية مع مجموع اختباري معين (رقم محسوب كدالة لهذه الحالة) في الحالة التي يتم فيها اعتبار معالجة البيانات من النقطة المرجعية السابقة إلى هذه النقطة (أي "سوء تقدير" واحد) يتم بشكل صحيح (دون تعطل الكمبيوتر). من أجل معرفة ذلك ، تم إجراء اثنين من هذه "الحسابات الخاطئة". بعد "الحساب الخاطئ" الأول ، يتم حساب المجموع الاختباري المحدد وتخزينه ، ثم يتم استعادة حالة الذاكرة للنقطة المرجعية السابقة ويتم إجراء "الخطأ في التقدير" الثاني. بعد "الحساب الخاطئ" الثاني ، يُحسب المجموع الاختباري المحدد مرة أخرى ، والذي يُقارن بعد ذلك بالمجموع الاختباري لـ "سوء التقدير" الأول. إذا تطابق هذان المجموعان الاختباريان ، فسيتم اعتبار الخطأ الثاني في التقدير صحيحًا ، وإلا فسيتم أيضًا تذكر المجموع الاختباري "لخطأ التقدير" الثاني ويتم تنفيذ "سوء التقدير" الثالث (مع استعادة أولية لحالة الذاكرة للنقطة المرجعية السابقة). إذا كان المجموع الاختباري لـ "الخطأ في التقدير" الثالث يطابق المجموع الاختباري لأحد "الحسابات الخاطئة" الأولين ، فإن الخطأ الثالث في التقدير يعتبر صحيحًا ، وإلا يلزم إجراء فحص هندسي للكمبيوتر.
تشير الحماية من تأثير برنامج "أجنبي" في المقام الأول إلى أنظمة التشغيل أو البرامج التي تؤدي وظائفها جزئيًا. هناك نوعان من هذه الحماية:
حماية الفشل ،
الحماية من التأثير الخبيث لبرنامج "أجنبي".
عندما يظهر في ذاكرته طريقة برمجة متعددة للكمبيوتر ، يمكن أن تكون عدة برامج في نفس الوقت في مرحلة التنفيذ ، وتتلقى التحكم بالتناوب نتيجة المقاطعات الناشئة (ما يسمى بتنفيذ البرنامج شبه المتوازي). يتعامل أحد هذه البرامج (عادةً: نظام التشغيل) مع معالجة المقاطعة والبرمجة المتعددة. في كل من هذه البرامج ، يمكن أن تحدث حالات فشل (أخطاء) ، والتي يمكن أن تؤثر على أداء الوظائف من قبل البرامج الأخرى. لذلك ، يجب أن يحمي برنامج التحكم (نظام التشغيل) نفسه والبرامج الأخرى من هذا التأثير. للقيام بذلك ، يجب أن تنفذ أجهزة الكمبيوتر القدرات التالية:
حماية الذاكرة ،
وضعان لعمل الكمبيوتر: امتياز وعمل (مستخدم) ،
نوعان من العمليات: مميزة وعادية ،
التنفيذ الصحيح للمقاطعات وبدء التشغيل الأولي للكمبيوتر ،
انقطاع مؤقت.
تعني حماية الذاكرة القدرة على التعيين برمجيًا لكل مناطق برنامج لا يمكن الوصول إليها من الذاكرة. في الوضع المميز ، يمكن إجراء أي عمليات (عادية وامتياز) ، وفي وضع التشغيل - فقط العمليات العادية. تؤدي محاولة إجراء عملية ذات امتياز ، بالإضافة إلى الوصول إلى الذاكرة المحمية في وضع التشغيل ، إلى مقاطعة مقابلة. علاوة على ذلك ، تشمل العمليات المميزة عمليات تغيير حماية الذاكرة ووضع التشغيل ، بالإضافة إلى الوصول إلى بيئة المعلومات الخارجية. يجب أن يؤدي التشغيل الأولي للكمبيوتر وأي مقاطعة إلى تمكين الوضع المميز تلقائيًا وتجاوز حماية الذاكرة. في هذه الحالة ، يمكن لبرنامج التحكم (نظام التشغيل) حماية نفسه تمامًا من تأثير البرامج الأخرى ، إذا كانت جميع نقاط نقل التحكم أثناء التشغيل الأولي والمقاطعات تنتمي إلى هذا البرنامج ، إذا كان لا يسمح لأي برنامج آخر العمل في وضع الامتياز (عند نقل التحكم إلى أي برنامج آخر ، سيقوم البرنامج بتشغيل وضع التشغيل فقط) وإذا كان يحمي ذاكرته تمامًا (يحتوي على وجه الخصوص ، على جميع معلومات التحكم الخاصة به ، بما في ذلك ما يسمى بموجهات المقاطعة) من البرامج الأخرى . عندها لن يمنعها أحد من أداء أي وظائف لحماية البرامج الأخرى المنفذة فيها (بما في ذلك الوصول إلى بيئة المعلومات الخارجية). لتسهيل حل هذه المشكلة ، يتم وضع جزء من هذا البرنامج في ذاكرة دائمة ، أي لا ينفصل عن الكمبيوتر نفسه. يسمح وجود مقاطعة مؤقتة لبرنامج التحكم بحماية نفسه من التكرار في البرامج الأخرى (بدون هذا الانقطاع ، يمكن أن يفقد ببساطة القدرة على التحكم).
يتم ضمان الحماية ضد فشل البرنامج "الخاص" من خلال موثوقية هذا البرنامج ، والذي هو محور كل تقنيات البرمجة التي تمت مناقشتها في دورة المحاضرات هذه.
يتم توفير الحماية ضد أخطاء المستخدم (بالإضافة إلى أخطاء بيانات الإدخال ، راجع ضمان استقرار نظام البرنامج) من خلال إصدار رسائل تحذير حول محاولات تغيير حالة بيئة المعلومات الخارجية مع شرط تأكيد هذه الإجراءات ، وكذلك القدرة على استعادة حالة المكونات الفردية لبيئة المعلومات الخارجية. هذا الأخير يعتمد على أرشفة التغييرات في حالة بيئة المعلومات الخارجية.
يتم ضمان الحماية ضد الوصول غير المصرح به باستخدام كلمات سرية (كلمات مرور). في هذه الحالة ، يتم تزويد كل مستخدم بمعلومات معينة وموارد (خدمات) إجرائية معينة ، يتطلب استخدامها من PS تقديم كلمة مرور معينة تم تسجيلها مسبقًا في PS بواسطة هذا المستخدم. بعبارة أخرى ، فإن المستخدم ، كما كان ، "يعلق قفلًا" على الموارد المخصصة له ، وهو "المفتاح" الذي يمتلكه هذا المستخدم فقط. ومع ذلك ، في بعض الحالات ، يمكن بذل محاولات مستمرة لكسر هذه الحماية ، إذا كانت الموارد المحمية ذات قيمة قصوى لشخص ما. في مثل هذه الحالة ، عليك اتخاذ تدابير إضافية للحماية من القرصنة.
ترتبط الحماية ضد اختراق الحماية باستخدام تقنيات البرمجة الخاصة في البرنامج التي تجعل من الصعب التغلب على الحماية ضد الوصول غير المصرح به. لا يكفي استخدام كلمات المرور العادية عندما يتعلق الأمر برغبة ملحة للغاية (على سبيل المثال ، ذات طبيعة إجرامية) للوصول إلى معلومات قيمة. أولاً ، نظرًا لأن المعلومات المتعلقة بكلمات المرور ، التي يستخدمها PS للحماية من الوصول غير المصرح به ، يمكن الحصول على "أداة تكسير" هذه الحماية بسهولة نسبيًا إذا كان لديه وصول إلى PS نفسه. ثانيًا ، باستخدام الكمبيوتر ، من الممكن إجراء تعداد كبير بما فيه الكفاية لكلمات المرور المحتملة من أجل العثور على كلمة مرور مناسبة للوصول إلى المعلومات ذات الأهمية. يمكنك حماية نفسك من هذا الاختراق على النحو التالي. الكلمة السرية (كلمة المرور) أو مجرد عدد صحيح سري لا يعرفه إلا مالك المعلومات المحمية ، وللتحقق من حقوق الوصول ، يتم تخزين رقم آخر Y = F (X) في الكمبيوتر ، والذي يتم حسابه بشكل فريد بواسطة PS لكل محاولة للوصول إلى هذه المعلومات عند تقديم كلمة السر. في هذه الحالة ، قد تكون الوظيفة F معروفة جيدًا لجميع مستخدمي PS ، ولكن لها خاصية تجعل استعادة كلمة X من Y أمرًا مستحيلًا عمليًا: بطول كبير بما فيه الكفاية للكلمة X (على سبيل المثال ، عدة مئات الأحرف) ، وهذا يتطلب وقتًا فلكيًا. سيُطلق على هذا الرقم Y التوقيع الإلكتروني (الكمبيوتر) لمالك الكلمة السرية X (وبالتالي المعلومات المحمية).
يرتبط نوع آخر من هذه الحماية بحماية الرسائل المرسلة عبر شبكات الكمبيوتر ، والتشويه المتعمد (أو الضار). يمكن اعتراض مثل هذه الرسالة في نقاط "إعادة الشحن" في شبكة الكمبيوتر واستبدالها برسالة أخرى من كاتب الرسالة التي تم اعتراضها. ينشأ هذا الموقف في المقام الأول عند تنفيذ العمليات المصرفية باستخدام شبكة الكمبيوتر. من خلال استبدال مثل هذه الرسالة ، وهي أمر من مالك حساب مصرفي لإجراء عملية مصرفية معينة ، يمكن تحويل الأموال من حسابه إلى حساب "جهاز تكسير" الحماية (نوع من السطو على بنك الكمبيوتر). يمكن تنفيذ الحماية ضد مثل هذا الانتهاك للحماية على النحو التالي. إلى جانب الوظيفة F ، التي تحدد توقيع الكمبيوتر لمالك الكلمة السرية X ، والتي يعرفها المرسل إليه للرسالة المحمية (إذا كان مالكها فقط عميلاً لهذا المرسل إليه) ، يحدد PS وظيفة ختم أخرى ، وفقًا لـ التي يجب أن يحسب مرسل الرسالة الرقم S = Stamp (X ، R) ، باستخدام الكلمة السرية X ونص الرسالة المرسلة R. تعتبر وظيفة Stamp معروفة أيضًا لجميع مستخدمي PS ولها هذه الخاصية أنه من المستحيل عمليًا إما استعادة الرقم X من S ، أو التقاط رسالة أخرى R مع توقيع الكمبيوتر المقابل. يجب أن يكون للرسالة المرسلة نفسها (مع حمايتها) الشكل:
علاوة على ذلك ، يسمح Y (توقيع الكمبيوتر) للمرسل إليه بإثبات حقيقة العميل ، و S ، كما كان ، يربط الرسالة المحمية R بتوقيع الكمبيوتر Y. في هذا الصدد ، سوف نسمي الرقم S بأنه إلكتروني (كمبيوتر ) عجل البحر. يحدد PS وظيفة أخرى لكاتب العدل ، والتي بموجبها يتحقق مستلم الرسالة المحمية من حقيقة الرسالة المرسلة:
هذا يجعل من الممكن إثبات بشكل لا لبس فيه أن الرسالة R تنتمي إلى مالك الكلمة السرية X.
الحماية من الحماية ضرورية في حالة نسيان (أو فقد) المستخدم كلمة المرور الخاصة به. في مثل هذه الحالة ، ينبغي أن يكون من الممكن لمستخدم خاص (مسؤول PS) مسؤول عن عمل نظام الحماية أن يزيل مؤقتًا الحماية ضد الوصول غير المصرح به لمالك كلمة المرور المنسية من أجل تمكينه من إصلاح كلمة مرور جديدة .
أدب المحاضرة 11.
11.1. هو. بيريزين ، ن. زيدكوف. طرق الحساب ، المجلد. 1 و 2 - موسكو: Fizmatgiz ، 1959.
11.2. ن. باخفالوف ، ن. Zhidkov ، جنرال موتورز كوبلكوف. الطرق العددية. - م: نوكا ، 1987.
11.3. جي مايرز. موثوقية البرنامج. - م: مير ، 1980 S. 127-154.
11.4. أ. ليبيديف. أمن المعلومات المصرفية والتشفير الحديث // قضايا أمن المعلومات ، 2 (29) ، 1995.
المحاضرة 12. ضمان جودة البرمجيات
12.1. الخصائص العامة لعملية ضمان الجودة لأدوات البرمجيات
كما ذكرنا سابقًا في المحاضرة 4 ، تحدد مواصفات الجودة المبادئ التوجيهية الرئيسية (الأهداف) ، والتي تؤثر في جميع مراحل تطوير البرامج بطريقة أو بأخرى على اختيار الخيار المناسب عند اتخاذ قرارات مختلفة. ومع ذلك ، فإن كل جودة بدائية لها خصائصها الخاصة لمثل هذا التأثير ، وبالتالي ، قد يتطلب ضمان وجودها في نظام البرنامج مناهجها وطرقها الخاصة لتطوير نظام البرنامج أو أجزائه الفردية. بالإضافة إلى ذلك ، لوحظ أيضًا عدم تناسق معايير الجودة الخاصة بـ PS وأولياء الجودة التي تعبر عنها: يمكن أن يؤدي توفير أي من العناصر الأولية لجودة PS بشكل كبير إلى تعقيد أو جعل من المستحيل توفير بعض هذه العناصر الأولية الأخرى. لذلك ، فإن جزءًا أساسيًا من عملية ضمان جودة منتجات البرامج يتكون من إيجاد مقايضات مقبولة. يجب تحديد هذه المقايضات جزئيًا بالفعل في مواصفات جودة PS: يجب أن يحدد نموذج جودة PS درجة التواجد المطلوبة في PS لكل من بدائل الجودة الخاصة به وتحديد الأولويات لتحقيق هذه الدرجات.
يتم تنفيذ ضمان الجودة في كل عملية تكنولوجية: القرارات المتخذة فيها ، بدرجة أو بأخرى ، لها تأثير على جودة نظام البرمجيات ككل. على وجه الخصوص ، لأن جزءًا كبيرًا من العناصر الأولية للجودة لا يرتبط كثيرًا بخصائص البرامج المضمنة في نظام البرنامج ، ولكن بخصائص التوثيق. نظرًا لعدم الاتساق الملحوظ في العناصر الأساسية للجودة ، من المهم جدًا الالتزام بالأولويات المختارة في توفيرها. لكن على أي حال ، من المفيد الالتزام بمبدأين عامين:
أولاً ، من الضروري توفير الوظيفة المطلوبة وموثوقية PS ، ومن ثم رفع معايير الجودة المتبقية إلى مستوى مقبول من وجودها في PS ؛
ليست هناك حاجة بل قد تكون ضارة لتحقيق مستوى أعلى من التواجد في PS لأي جودة بدائية من تلك المحددة في مواصفات جودة PS.
تمت مناقشة ضمان وظائف وموثوقية PS في المحاضرة السابقة. فيما يلي يناقش توفير معايير الجودة الأخرى لمؤتمر الأطراف.
12.2 .. ضمان سهولة استخدام الأداة البرمجية
يحدد التوثيق P لنظام البرنامج تكوين وثائق المستخدم
في المحاضرة السابقة ، ناقشنا بالفعل توفير اثنين من عناصر الجودة الأساسية الخمسة (الاستقرار والأمان) ، والتي تحدد سهولة تطبيق PS.
تحدد وثائق ف والمعلوماتية تكوين وجودة وثائق المستخدم (انظر المحاضرة التالية).
يتم ضمان قابلية التشغيل البيني من خلال إنشاء واجهة مستخدم مناسبة والتنفيذ المناسب للاستثناءات. ماهي المشكلة هنا؟
12.3. التأكد من فاعلية البرنامج.
يتم ضمان فعالية النظام البرمجي من خلال اتخاذ القرارات المناسبة في مراحل مختلفة من تطويره ، بدءًا من تطوير بنيته. يؤثر اختيار بنية البيانات وعرضها على كفاءة SE (خاصة من حيث الذاكرة) بشكل خاص. لكن اختيار الخوارزميات المستخدمة في وحدات برمجية معينة ، فضلاً عن تفاصيل تنفيذها (بما في ذلك اختيار لغة البرمجة) يمكن أن يؤثر بشكل كبير على كفاءة نظام البرنامج. في الوقت نفسه ، من الضروري باستمرار حل التناقض بين الكفاءة الزمنية وكفاءة الذاكرة. لذلك ، من المهم جدًا أن تشير مواصفات الجودة بوضوح إلى العلاقة الكمية بين مؤشرات عناصر الجودة الأولية هذه ، أو على الأقل تعيين الحدود الكمية لأحد هذه المؤشرات. ومع ذلك ، فإن وحدات البرامج المختلفة لها تأثيرات مختلفة على كفاءة نظام البرنامج ككل: سواء من حيث المساهمة في التكاليف الإجمالية لنظام البرنامج من حيث الوقت والذاكرة ، ومن حيث التأثير على الجودة المختلفة العناصر الأولية (يمكن لبعض الوحدات أن تؤثر بشدة على تحقيق كفاءة الوقت وليس لها أي تأثير عمليًا على كفاءة الذاكرة ، بينما يمكن أن تؤثر وحدات أخرى بشكل كبير على الاستهلاك الكلي للذاكرة دون أن يكون لها تأثير ملحوظ على وقت تشغيل PS) علاوة على ذلك ، فإن هذا التأثير (في المقام الأول فيما يتعلق بكفاءة الوقت) مقدمًا (قبل نهاية تنفيذ PS) ليس دائمًا ممكنًا للتقييم بشكل صحيح.
أولاً ، تحتاج إلى تطوير نظام برمجي موثوق به ، وعندها فقط تحقق الكفاءة المطلوبة وفقًا لمواصفات الجودة لهذا البرنامج ؛
لزيادة كفاءة نظام البرنامج ، استخدم أولاً وقبل كل شيء مترجمًا محسنًا - يمكن أن يوفر ذلك الكفاءة المطلوبة ؛
إذا كانت الكفاءة المحققة لـ PS لا تفي بمواصفات جودتها ، فابحث عن الوحدات الأكثر أهمية من حيث الكفاءة المطلوبة لـ PS (في حالة كفاءة الوقت ، سيتطلب ذلك الحصول على التوزيع حسب وحدات التشغيل وقت PS عن طريق القياسات المناسبة أثناء تنفيذ PS) ؛ هذه الوحدات ومحاولة تحسينها أولاً عن طريق إعادة صياغتها يدويًا ؛
لا تقم بتحسين الوحدة إذا لم تكن مطلوبة لتحقيق الكفاءة المطلوبة لـ PS.
12.4. ضمان قابلية الصيانة.
ج- التوثيق والمعلوماتية والشمولية تحدد تكوين وجودة وثائق الصيانة (انظر المحاضرة التالية). بالإضافة إلى ذلك ، يمكن تقديم التوصيات التالية فيما يتعلق بنصوص البرامج (الوحدات).
استخدام التعليقات في نص الوحدة التي توضح وتشرح سمات القرارات المتخذة ؛ إذا أمكن ، قم بتضمين التعليقات (على الأقل في شكل قصير) في المرحلة الأولى من تطوير نص الوحدة ؛
استخدم أسماء ذات معنى (ذاكري) ويمكن تمييزها باستمرار (طول الاسم الأمثل هو 4-12 حرفًا ، والأرقام في النهاية) ، ولا تستخدم أسماء وكلمات رئيسية متشابهة ؛
كن حذرًا عند استخدام الثوابت (يجب أن يكون للثابت الفريد تكرار واحد فقط في نص الوحدة: عندما يتم التصريح عنه أو ، في الحالات القصوى ، عند تهيئة المتغير باعتباره ثابتًا) ؛
لا تخف من استخدام الأقواس الاختيارية (الأقواس أرخص من الأخطاء ؛
لا تضع أكثر من عامل واحد في كل سطر ؛ لتوضيح هيكل الوحدة ، استخدم مسافات إضافية (المسافة البادئة) في بداية كل سطر ؛
تجنب الحيل ، أي تقنيات البرمجة هذه ، عندما يتم إنشاء أجزاء من وحدة ، يكون تأثيرها الرئيسي غير واضح أو مخفي (محجوب) ، على سبيل المثال ، الآثار الجانبية للوظائف.
يتم توفير القابلية للتوسعة عن طريق إنشاء مُثبِّت مناسب.
الهيكلية والنمطية تسهل فهم نصوص البرنامج وتعديلها.
12.5. توفير التنقل.
أدب المحاضرة 12.
12.1. إيان سومرفيل. هندسة البرمجيات. - شركة أديسون ويسلي للنشر ، 1992. P.
12.3. دي فان تاسيل. الأسلوب والتطوير والكفاءة وتصحيح الأخطاء واختبار البرامج. - م: مير ، 1985 ، 8-44 ، 117-178.
12.4. وثائق مستخدم البرنامج / معيار ANSI / IEEE 1063-1987.
محاضرة 13. توثيق أدوات البرمجيات
13.1. الوثائق التي تم إنشاؤها أثناء تطوير البرمجيات.
عند تطوير نظام برمجي ، يتم إنشاء قدر كبير من الوثائق المتنوعة. هناك حاجة إليه كوسيلة لنقل المعلومات بين مطوري البرامج ، كوسيلة لإدارة تطوير البرامج وكوسيلة لنقل المعلومات إلى المستخدمين اللازمة لتطبيق وصيانة البرامج. يمثل إنشاء هذه الوثائق حصة كبيرة من تكلفة PS.
يمكن تقسيم هذه الوثائق إلى مجموعتين:
وثائق إدارة تطوير البرمجيات.
المستندات التي تعد جزءًا من PS.
وثائق إدارة تطوير البرمجيات (وثائق العملية) ، وتسجيل عمليات تطوير البرمجيات وصيانتها ، وتوفير الاتصالات داخل فريق التطوير وبين فريق التطوير والمديرين - الأشخاص الذين يديرون التطوير. يمكن أن تكون هذه المستندات من الأنواع التالية:
الخطط والتقديرات والجداول. يتم إنشاء هذه المستندات من قبل المديرين للتنبؤ بعمليات التطوير والصيانة وإدارتها.
تقارير استخدام الموارد أثناء التطوير. تم إنشاؤها من قبل المديرين.
المعايير. تحدد هذه المستندات للمطورين المبادئ والقواعد والاتفاقيات التي يجب عليهم اتباعها في عملية تطوير البرامج. يمكن أن تكون هذه المعايير دولية أو وطنية ، وقد تم إنشاؤها خصيصًا للمؤسسة التي تقوم بتطوير هذا البرنامج.
وثائق العمل. هذه هي المستندات الفنية الرئيسية التي توفر التواصل بين المطورين. وهي تحتوي على تثبيت للأفكار والمشكلات الناشئة في عملية التطوير ، ووصفًا للاستراتيجيات والأساليب المستخدمة ، بالإضافة إلى إصدارات العمل (المؤقتة) من المستندات التي يجب تضمينها في PS.
ملاحظات ومراسلات. توثق هذه المستندات تفاصيل مختلفة للتفاعل بين المديرين والمطورين.
تصف الوثائق المضمنة في PS (وثائق المنتج) برامج PS من وجهة نظر استخدامها من قبل المستخدمين ومن وجهة نظر مطوريها والقائمين على صيانتها (وفقًا للغرض من PS). وتجدر الإشارة هنا إلى أنه سيتم استخدام هذه المستندات ليس فقط في مرحلة تشغيل PS (في مرحلتي التطبيق والصيانة) ، ولكن أيضًا في مرحلة التطوير لإدارة عملية التطوير (جنبًا إلى جنب مع مستندات العمل) - في على أي حال ، يجب فحصها (اختبارها) للتأكد من مطابقتها لبرامج PS. تشكل هذه الوثائق مجموعتين لأغراض مختلفة:
وثائق مستخدم PS (P- التوثيق).
وثائق دعم المحطة الفرعية (C- التوثيق).
13.2. توثيق المستخدم لأدوات البرمجيات.
تشرح وثائق المستخدم لنظام البرنامج (وثائق المستخدم) للمستخدمين كيف يجب عليهم المتابعة من أجل تطبيق نظام البرنامج هذا. من الضروري إذا كان 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 ، ومتطلبات الحد الأدنى من تكوين الأجهزة.
تعليمات استخدام PS. مصممة للمستخدمين العاديين. يحتوي على المعلومات اللازمة عن تطبيق PS ، منظم في شكل مناسب لدراسته.
كتيب عن استخدام PS. مصممة للمستخدمين العاديين. يحتوي على المعلومات الضرورية حول تطبيق PS ، منظم في شكل مناسب للبحث الانتقائي للأجزاء الفردية.
دليل إدارة PS. مصمم لمسؤولي النظام. يجب أن يصف الرسائل التي تم إنشاؤها عندما يتفاعل PS مع الأنظمة الأخرى وكيفية الرد على هذه الرسائل. بالإضافة إلى ذلك ، إذا كانت MS تستخدم أجهزة النظام ، فقد يوضح هذا المستند كيفية صيانة هذه الأجهزة.
كما ذكرنا سابقًا (انظر الفصل 4) ، يبدأ تطوير الوثائق المخصصة بمجرد إنشاء الوصف الخارجي. يمكن أن تحدد جودة هذه الوثائق بشكل كبير نجاح PS. يجب أن يكون بسيطًا جدًا وسهل الاستخدام (وإلا ، لم يكن يجب إنشاء PS هذا بشكل عام). لذلك ، بينما يتم إنشاء المسودات (الرسومات التخطيطية) لوثائق المستخدم بواسطة المطورين الرئيسيين للبرنامج ، غالبًا ما يشارك الكتاب الفنيون المحترفون في إنشاء إصداراتهم النهائية. بالإضافة إلى ذلك ، لضمان جودة وثائق المستخدم ، تم تطوير عدد من المعايير (انظر ، على سبيل المثال ،) ، والتي تحدد إجراءات تطوير هذه الوثائق ، وصياغة المتطلبات لكل نوع من مستندات المستخدم ، وتحديد هيكلها ومحتواها .
13.3. وثائق صيانة البرامج.
تصف وثائق النظام نظام البرنامج من وجهة نظر تطوره. يعد هذا التوثيق ضروريًا إذا كان نظام البرنامج يتضمن دراسة كيفية ترتيبه (تصميمه) وتحديث برامجه. كما لوحظ ، الصيانة هو تطور مستمر. لذلك ، إذا كان من الضروري تحديث المحطة الفرعية ، فسيتم إشراك فريق خاص من مطوري الدعم في هذا العمل. سيتعين على هذا الفريق التعامل مع الوثائق نفسها التي حددت أنشطة فريق تطوير البرامج (الرئيسي) الأصلي ، مع الاختلاف الوحيد في أن هذه الوثائق لفريق تطوير المشرف ستكون ، كقاعدة عامة ، أجنبية (تم إنشاؤها بواسطة شخص آخر فريق). سيتعين على المشرفين على فريق التطوير دراسة هذه الوثائق من أجل فهم هيكل وعملية تطوير نظام البرنامج الذي تمت ترقيته ، وإجراء التغييرات اللازمة على هذه الوثائق ، مع تكرار العمليات التكنولوجية التي تم إنشاء البرنامج الأصلي بها إلى حد كبير.
يمكن تقسيم وثائق دعم PS إلى مجموعتين:
(1) الوثائق التي تحدد هيكل البرامج وهياكل البيانات لأنظمة البرمجيات والتكنولوجيا لتطويرها ؛
(2) وثائق للمساعدة في إجراء تغييرات على نظام التشغيل.
تحتوي وثائق المجموعة الأولى على الوثائق النهائية لكل مرحلة تكنولوجية لتطوير البرمجيات. يتضمن الوثائق التالية:
وصف خارجي لـ SS (وثيقة المتطلبات).
وصف بنية النظام ، بما في ذلك المواصفات الخارجية لكل برنامج من برامجه.
لكل برنامج PS - وصف لهيكله المعياري ، بما في ذلك المواصفات الخارجية لكل وحدة مدرجة فيه.
لكل وحدة - مواصفاتها ووصف هيكلها (وصف التصميم).
نصوص الوحدة النمطية بلغة البرمجة المحددة (قوائم رمز مصدر البرنامج).
وثائق التحقق من الصحة التي تصف كيفية إنشاء صلاحية كل برنامج CA وكيف تم ربط معلومات التحقق بمتطلبات CA.
تتضمن مستندات إثبات صلاحية أنظمة البرامج ، أولاً وقبل كل شيء ، وثائق الاختبار (مخطط الاختبار ووصف مجموعة من الاختبارات) ، ولكنها قد تتضمن نتائج أنواع أخرى من اختبار البرامج ، على سبيل المثال ، إثبات خصائص البرنامج.
تحتوي وثائق المجموعة الثانية على
يصف دليل صيانة النظام ، الذي يصف المشكلات المعروفة في البرنامج ، أجزاء النظام التي تعتمد على الأجهزة والبرامج ، وكيف يتم أخذ تطوير البرنامج في الاعتبار في هيكله (التصميم).
تتمثل إحدى المشكلات الشائعة في الحفاظ على مؤتمر الأطراف في التأكد من أن جميع وجهات نظره تتماشى (تظل متسقة) عندما يتغير مؤتمر الأطراف. للمساعدة في ذلك ، يجب التقاط الروابط والتبعيات بين المستندات وأجزائها في قاعدة بيانات إدارة التكوين.
أدب المحاضرة 13.
13.1. إيان سومرفيل. هندسة البرمجيات. - شركة أديسون ويسلي للنشر ، 1992. P.
13.2. ANSI / IEEE Std 1063-1988 ، معيار IEEE لوثائق مستخدم البرنامج.
13.3. ANSI / IEEE Std 830-1984 ، دليل IEEE لمواصفات متطلبات البرامج.
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 لتوثيق اختبار البرامج.
المحاضرة 14. شهادة البرمجيات
الغرض من شهادة البرنامج. اختبار وتقييم جودة البرمجيات. أنواع الاختبارات وطرق تقييم جودة البرمجيات.
14.1. الغرض من شهادة البرنامج.
شهادة PS هي تأكيد رسمي لجودة PS. عادة ، يتم إنشاء لجنة تمثيلية (شهادة) من الخبراء وممثلي العملاء وممثلي المطورين للحصول على شهادة PS. تجري هذه اللجنة اختبارات PS من أجل الحصول على المعلومات اللازمة لتقييم جودتها. من خلال اختبار PS ، فإننا نعني عملية تنفيذ مجموعة من الإجراءات التي تحقق في مدى ملاءمة PS لتشغيلها الناجح (التطبيق والصيانة) وفقًا لمتطلبات العميل. يشمل هذا المجمع التحقق من اكتمال ودقة وثائق البرمجيات ، ودراسة ومناقشة خصائصه الأخرى ، وكذلك الاختبارات اللازمة للبرامج المدرجة في نظام البرمجيات ، وعلى وجه الخصوص ، امتثال هذه البرامج للوثائق المتاحة.
بناءً على المعلومات التي تم الحصول عليها أثناء اختبار PS ، أولاً وقبل كل شيء ، يجب إثبات أن PS تؤدي الوظائف المعلنة ، ويجب أيضًا تحديد إلى أي مدى يمتلك PS المعايير الأولية والجودة المعلنة. وبالتالي ، فإن تقييم جودة PS هو المحتوى الرئيسي لعملية الاعتماد. يتم تسجيل التقييم المنفذ لجودة PS في القرار المقابل للجنة التصديق.
14.2. أنواع اختبارات البرمجيات.
الأنواع التالية من اختبارات PS معروفة بغرض الحصول على شهادة PS:
اختبار مكونات PS ؛
اختبارات النظام
اختبارات القبول؛
تجارب ميدانية
الاختبارات الصناعية.
اختبار مكونات PS هو فحص (اختبار) لقابلية تشغيل أنظمة PS الفرعية الفردية. يتم تنفيذها فقط في حالات استثنائية بقرار خاص من لجنة المصادقة.
اختبارات النظام لـ PS هي فحص (اختبار) لـ PS ككل. يمكن أن تشمل نفس أنواع الاختبارات كما هو الحال في التصحيح المعقد لأنظمة البرمجيات (انظر المحاضرة 10). يتم تنفيذه بقرار من لجنة المصادقة ، إذا كانت هناك شكوك حول جودة التصحيح من قبل مطوري نظام البرمجيات.
اختبارات القبول هي النوع الرئيسي من الاختبارات للحصول على شهادة PS. وبهذه الاختبارات تبدأ لجنة إصدار الشهادات عملها. تبدأ هذه الاختبارات بدراسة الوثائق المقدمة ، بما في ذلك وثائق اختبار أنظمة البرامج وتصحيحها. إذا لم تتضمن الوثائق نتائج كاملة بما فيه الكفاية لاختبار PS ، فقد تقرر لجنة الاعتماد إجراء اختبارات نظام PS أو إنهاء عملية الاعتماد مع توصية للمطور بإجراء اختبار PS إضافي (أكثر اكتمالاً). بالإضافة إلى ذلك ، خلال هذه الاختبارات ، يمكن تخطي اختبارات المطور بشكل انتقائي ، وكذلك مهام التحكم في المستخدم (انظر المحاضرة 10) والاختبارات الإضافية التي أعدتها اللجنة لتقييم جودة البرنامج المعتمد.
الاختبار الميداني لـ PS هو عرض توضيحي لـ PS ، جنبًا إلى جنب مع النظام الفني الذي يتم التحكم فيه بواسطة PS ، لدائرة ضيقة من العملاء في ظروف حقيقية ، ويتم تنفيذ مراقبة دقيقة لسلوك PS. يجب منح العملاء الفرصة لتحديد حالات الاختبار الخاصة بهم ، على وجه الخصوص ، من المخارج إلى أوضاع التشغيل الحرجة للنظام الفني ، وكذلك إطلاق حالات الطوارئ فيه. هذه اختبارات إضافية يتم إجراؤها بقرار من لجنة الاعتماد فقط لبعض PS التي تتحكم في أنظمة فنية معينة.
الاختبار الصناعي لـ PS هو عملية نقل PS للتشغيل الدائم للمستخدمين. إنها فترة تشغيل تجريبي للطائرة (انظر المحاضرة 10) من قبل المستخدمين مع جمع المعلومات حول ميزات سلوك الطائرة وخصائصها التشغيلية. هذه هي الاختبارات النهائية لـ PS ، والتي يتم إجراؤها بقرار من لجنة الاعتماد ، إذا تم الحصول على معلومات غير كافية أو موثوقة أثناء الاختبارات السابقة لتقييم جودة PS المعتمدة.
14.3. طرق تقييم جودة البرمجيات.
يتم تقليل تقييم جودة PS لكل معيار من المعايير إلى تقييم كل من الأوليات المرتبطة بمعيار جودة PS ، وفقًا لتجسيدها ، الذي تم إجراؤه في مواصفات الجودة الخاصة بـ PS. يمكن تقسيم طرق تقييم بدائل الجودة لنظام البرمجيات إلى أربع مجموعات:
القياس المباشر لمؤشرات الجودة البدائية ؛
معالجة البرامج وتوثيق PS باستخدام أدوات برمجية خاصة (معالجات) ؛
اختبار برامج PS ؛
تقييم الخبراء على أساس دراسة البرامج وتوثيق PS.
يتم إجراء القياس المباشر لمؤشرات الجودة الأولية عن طريق حساب عدد تكرارات الوحدات المميزة ، والأشياء ، والهياكل ، وما إلى ذلك ، في مستند برنامج معين ، وكذلك عن طريق قياس وقت تشغيل الأجهزة المختلفة وكمية الكمبيوتر الذاكرة مشغولة عند تنفيذ حالات الاختبار. على سبيل المثال ، قد يكون بعض مقاييس كفاءة الذاكرة هو عدد سطور البرنامج في لغة البرمجة ، وقد يكون بعض مقياس كفاءة الوقت هو وقت الاستجابة للطلب. يمكن تحديد استخدام أي مؤشرات لأساسيات الجودة في مواصفات جودة نظام البرنامج. يمكن دمج طريقة القياس المباشر لمؤشرات الجودة البدائية مع استخدام برامج الاختبار.
لإثبات وجود بعض العناصر الأساسية للجودة في البرنامج ، يمكن استخدام أدوات برمجية معينة. تعالج أدوات البرامج هذه نصوص البرامج أو توثيق البرامج من أجل التحكم في أي بدائل للجودة أو للحصول على بعض مؤشرات الجودة الأولية هذه. لتقييم هيكلة برامج PS ، إذا تمت برمجتها بلهجة هيكلية مناسبة للغة البرمجة الأساسية ، فسيكون ذلك كافيًا لتمريرها من خلال محول البرامج المهيكلة ، الذي ينفذ التحكم النحوي وبعض التحكم الدلالي لهذه اللهجة ويترجم نصوص هذه البرامج في لغة الإدخال للمترجم الأساسي. ومع ذلك ، بهذه الطريقة في الوقت الحاضر ، من الممكن التحكم فقط في عدد قليل من بدائل الجودة ، وحتى في حالات نادرة. في بعض الحالات ، بدلاً من الأدوات البرمجية التي تتحكم في جودة أنظمة البرامج ، يكون من المفيد أكثر استخدام الأدوات التي تحول تمثيل البرامج أو توثيق البرامج. مثل هذا ، على سبيل المثال ، هو مُنسق برنامج يقوم بإحضار نصوص البرنامج إلى نموذج يمكن قراءته - يمكن أن تضمن معالجة نصوص برنامج PS باستخدام هذه الأداة تلقائيًا توفر بدائية جودة مناسبة في PS.
يستخدم الاختبار لتقييم بعض العناصر الأولية لجودة PS. تشمل هذه العناصر الأولية ، أولاً وقبل كل شيء ، اكتمال PS ، فضلاً عن دقتها واستقرارها وأمنها وأساسيات الجودة الأخرى. في عدد من الحالات ، يتم استخدام الاختبار مع طرق أخرى لتقييم العناصر الأولية الفردية لجودة أنظمة البرامج. لذلك ، لتقييم جودة التوثيق على تطبيق البرنامج (P- التوثيق) ، يتم استخدام الاختبار مع تقييم الخبراء لهذه الوثائق. إذا تم إجراء اختبار كامل بما فيه الكفاية أثناء التصحيح المعقد لنظام البرنامج ، فيمكن استخدام نفس الاختبارات للمصادقة على نظام البرنامج. في هذه الحالة ، يمكن للجنة الاعتماد استخدام بروتوكولات الاختبار التي تم إجراؤها أثناء التصحيح المعقد. ومع ذلك ، حتى في هذه الحالة ، من الضروري إجراء بعض الاختبارات الجديدة أو على الأقل إعادة تشغيل بعض الاختبارات القديمة. إذا تم اعتبار الاختبار أثناء التصحيح المعقد غير مكتمل بدرجة كافية ، فيجب إجراء اختبار أكثر اكتمالاً. في هذه الحالة ، يمكن اتخاذ قرار باختبار مكونات أو اختبارات النظام الخاصة بـ PS ، وكذلك إعادة PS إلى المطورين للمراجعة. من المهم جدًا أنه من أجل تقييم البرنامج وفقًا لمعيار سهولة الاستخدام ، تم إجراء اختبار كامل (أثناء تصحيح الأخطاء والتصديق على البرنامج) باستخدام الاختبارات التي تم إعدادها على أساس وثائق التطبيق ، وبمعيار قابلية الصيانة - عن طريق الاختبارات المعدة لكل من الوثائق المقترحة للصيانة PS.
لتقييم معظم العوامل الأولية لجودة البرنامج ، في الوقت الحالي ، يمكن استخدام طريقة تقييم الخبراء فقط. تتكون هذه الطريقة مما يلي: يتم تعيين مجموعة من الخبراء ، كل من هؤلاء الخبراء ، نتيجة دراسة الوثائق المقدمة ، يبدي رأيه الخاص في حيازة PS مع الجودة البدائية المطلوبة ، ثم تقييم يتم إنشاء بدائية جودة PS المطلوبة من خلال تصويت أعضاء هذه المجموعة. يمكن إجراء هذا التقييم وفقًا لنظام من نقطتين ("يمتلك" - "لا يمتلك") ، وأيضًا مراعاة درجة امتلاك PS من خلال هذه الجودة البدائية (على سبيل المثال ، يمكن إجراؤها وفقًا لنظام من خمس نقاط). في هذه الحالة ، يجب أن يسترشد فريق الخبراء بمواصفات هذا العنصر البدائي والإشارة إلى طريقة تقييمه ، التي تمت صياغتها في مواصفات الجودة الخاصة بـ PS المعتمدة.
أدب المحاضرة 14.
14.2. ليباييف. برامج الاختبار. - م: الراديو والاتصالات ، 1986. - ص 231-245.
14.3. دي فان تاسيل. الأسلوب والتطوير والكفاءة وتصحيح الأخطاء واختبار البرامج. - م: مير ، 1985. - س 281 - 283.
14.4. ب. شنايدرمان. علم نفس البرمجة. - م: الراديو والاتصالات ، 1984. - ص 99-127.
المحاضرة 15 نهج الكائن لتطوير البرمجيات
15.1. الأشياء والعلاقات في البرمجة. جوهر نهج الكائن لتطوير البرمجيات.
يتكون العالم من حولنا من الأشياء والعلاقات فيما بينها. يجسد الكائن بعض الجوهر وله حالة معينة يمكن أن تتغير بمرور الوقت نتيجة لتأثير الأشياء الأخرى التي لها علاقة بأي شيء معطى. يمكن أن يكون لها بنية داخلية: يمكن أن تتكون من أشياء أخرى موجودة أيضًا فيما بينها في بعض النواحي. بناءً على ذلك ، يمكنك بناء هيكل هرمي للعالم من الكائنات. ومع ذلك ، بالنسبة لكل اعتبار محدد للعالم من حولنا ، تعتبر بعض الأشياء غير قابلة للتجزئة ("نقطة") ، واعتمادًا على أهداف الاعتبار ، يمكن أخذ هذه الكائنات (غير القابلة للتجزئة) على مستويات مختلفة من التسلسل الهرمي. العلاقة تربط بعض الكائنات: يمكننا أن نفترض أن اتحاد هذه الكائنات له بعض الخصائص. إذا كانت العلاقة تربط كائنات n ، فإن هذه العلاقة تسمى n-ary (n-ary). في كل مكان من اتحاد الكائنات التي يمكن ربطها بأي علاقة محددة ، يمكن أن تكون هناك أشياء مختلفة ، ولكن أشياء محددة تمامًا (في هذه الحالة يقولون: أشياء من فئة معينة). تسمى العلاقة الأحادية خاصية الكائن (من الفئة المقابلة). يمكن دراسة حالة الكائن من خلال قيمة خصائص هذا الكائن أو ضمنيًا من خلال قيمة خصائص اتحادات الكائنات المرتبطة بهذه العلاقة أو تلك.
في عملية التعرف على العالم من حولنا أو تغييره ، نأخذ دائمًا في الاعتبار نموذجًا واحدًا أو آخرًا مبسطًا للعالم (العالم النموذجي) ، حيث نقوم بتضمين بعض الأشياء وبعض علاقات العالم من حولنا و ، كقاعدة عامة ، مستوى واحد من التسلسل الهرمي. يمكن لكل كائن بهيكل داخلي أن يمثل نموذج عالمه الخاص ، والذي يتضمن كائنات من هذا الهيكل والعلاقات التي تربطها. وبالتالي ، يمكن اعتبار العالم من حولنا (في بعض التقريب) هيكلًا هرميًا للعوالم النموذجية.
حاليًا ، في عملية التعرف على العالم من حولنا أو تغييره ، تُستخدم تكنولوجيا الكمبيوتر على نطاق واسع لمعالجة أنواع مختلفة من المعلومات. في هذا الصدد ، يتم استخدام التمثيل الحاسوبي (المعلوماتي) للأشياء والعلاقات. يمكن تمثيل كل كائن بشكل إعلامي من خلال بعض هياكل البيانات التي تعكس حالتها. يمكن تعيين خصائص هذا الكائن مباشرة كمكونات منفصلة لهذه البنية ، أو عن طريق وظائف خاصة في بنية البيانات هذه. يمكن تمثيل العلاقات N-ary لـ N> 1 إما في شكل نشط أو بشكل سلبي. في الشكل النشط ، يتم تمثيل العلاقة N-local من خلال جزء من البرنامج الذي ينفذ إما وظيفة N-local (تحديد قيمة خاصية اتحاد الكائنات المقابلة) ، أو إجراء يغير حالات بعضها وفقًا لحالة تمثيلات الكائنات المرتبطة بالعلاقة الممثلة. في شكل سلبي ، يمكن تمثيل هذه العلاقة ببعض هياكل البيانات (والتي قد تتضمن أيضًا تمثيلات للكائنات المرتبطة بهذه العلاقة) ، مفسرة على أساس الاتفاقيات المقبولة للإجراءات العامة التي لا تعتمد على علاقات محددة (على سبيل المثال ، قاعدة بيانات علائقية). في أي حال ، تحدد طريقة عرض العلاقة بعض أنشطة معالجة البيانات.
عند استكشاف عالم النموذج ، يمكن للمستخدم أن يتلقى (أو يرغب في تلقي) معلومات من الكمبيوتر بطرق مختلفة. من خلال نهج واحد ، قد يكون مهتمًا بالحصول على معلومات حول الخصائص الفردية للأشياء التي تهمه أو نتائج أي تفاعل بين بعض الأشياء. للقيام بذلك ، يأمر بتطوير نظام برمجي واحد أو آخر يؤدي الوظائف التي تهمه ، أو نظام معلومات قادر على توفير معلومات حول العلاقات التي تهمه ، باستخدام قاعدة البيانات المناسبة. في الفترة الأولى من تطوير تكنولوجيا الكمبيوتر (مع عدم كفاية الطاقة العالية لأجهزة الكمبيوتر) ، كان هذا النهج في استخدام أجهزة الكمبيوتر أمرًا طبيعيًا تمامًا. كان هو الذي أثار النهج الوظيفي (العلائقي) لتطوير أنظمة البرمجيات ، والذي تمت مناقشته بالتفصيل في المحاضرات السابقة. يتمثل جوهر هذا النهج في الاستخدام المنهجي لتحليل الوظائف (العلاقات) لبناء هيكل PS ونصوص البرامج المضمنة فيه. في الوقت نفسه ، تم تقديم الكائنات نفسها ، التي تم تطبيق الوظائف المطلوبة والمنفذة عليها ، بشكل مجزأ (بالقدر اللازم لأداء هذه الوظائف) وفي شكل مناسب لتنفيذ هذه الوظائف. وبالتالي ، لم يتم توفير تمثيل كمبيوتر متكامل ومناسب لعالم النموذج الذي يهم المستخدم: قد يكون تعيينه إلى SS المستخدم مهمة شاقة إلى حد ما للمستخدم ، ومحاولات لتوسيع حجم وطبيعة المعلومات حول النموذج بشكل طفيف عالم يهم المستخدم. المستلمة من هذه المحطات الفرعية ، يمكن أن تؤدي إلى تحديثها الجاد. يتم دعم هذا النهج لتطوير البرامج من قبل معظم لغات البرمجة المستخدمة ، بدءًا من لغات التجميع واللغات الإجرائية (FORTRAN و Pascal) إلى اللغات الوظيفية (LISP) ولغات البرمجة المنطقية (PROLOGUE) .
مع نهج آخر لدراسة عالم النموذج باستخدام الكمبيوتر ، قد يكون المستخدم مهتمًا بمراقبة التغيير في حالات الكائنات نتيجة تفاعلاتها. يتطلب هذا تمثيلًا متكاملًا إلى حد ما في الكمبيوتر للشيء الذي يثير اهتمام المستخدم ، وترتبط به مكونات البرنامج التي تنفذ العلاقات التي يشارك فيها هذا الكائن بشكل صريح. لتنفيذ هذا النهج ، كان من الضروري بناء برنامج يحاكي عمليات تفاعل الكائنات (نموذج العالم). مع أدوات التطوير التقليدية ، ثبت أن هذه مهمة شاقة إلى حد ما. صحيح ، ظهرت لغات البرمجة التي تركز بشكل خاص على مثل هذه النمذجة ، لكن هذا لم يبسط سوى جزئيًا مهمة تطوير أنظمة البرامج المطلوبة. نهج الكائن لتطوير أنظمة البرمجيات يلبي بشكل كامل حل هذه المشكلة. يكمن جوهرها في الاستخدام المنهجي لتحلل الأشياء في بناء هيكل PS ونصوص البرامج المضمنة فيه. في هذه الحالة ، تم التعبير عن الوظائف (العلاقات) التي يؤديها مثل هذا PS من خلال علاقات الكائنات ذات المستويات المختلفة ، أي أن تحللها يعتمد بشكل كبير على تحلل الأشياء.
عند الحديث عن نهج الكائن ، يجب على المرء أيضًا أن يفهم بوضوح نوع الكائنات التي نتحدث عنها: كائنات من عالم نموذج المستخدم ، وتمثيلها المعلوماتي ، وكائنات البرنامج التي تم بناء نظام البرنامج من خلالها. بالإضافة إلى ذلك ، يجب على المرء أن يميز بين الأشياء الفعلية (الأشياء "السلبية") والموضوعات (الأشياء "النشطة").
15.2. الأشياء والموضوعات في البرمجة.
15.3. الأساليب الموضوعية والذاتية لتطوير البرمجيات.
لاحظ ديكارت أن الناس عادة ما يكون لديهم وجهة نظر موضوعية للعالم (في).
يُعتقد أن التصميم الموجه للكائنات يعتمد على المبادئ التالية:
تسليط الضوء على التجريدات ،
تقييد الوصول ،
نمطية
التسلسل الهرمي،
الكتابة
تماثل،
المزيد.
لكن كل هذا يمكن تطبيقه بنهج وظيفي.
من الضروري التمييز بين مزايا وعيوب نهج الكائن العام وحالته الخاصة - النهج الموجه نحو الموضوع.
مزايا نهج الهدف العام:
رسم الخرائط الطبيعية للعالم الحقيقي لهيكل PS (الإدراك البشري الطبيعي لقدرات PS ، ليست هناك حاجة إلى "ابتكار" بنية PS ، ولكن لاستخدام المقارنات الطبيعية).
استخدام وحدات هيكلية ذات مغزى كافٍ لـ PS (كائن مثل تكامل الجمعيات غير الزائدة عن الحاجة ، والوحدات النمطية القوية للمعلومات).
الحد من تعقيد تطوير أنظمة البرمجيات باستخدام مستوى جديد من التجريدات (باستخدام تسلسل هرمي من التجريدات "غير البرمجية" عند تطوير أنظمة البرامج: تصنيف الكائنات في العالم الحقيقي ، وطريقة التشبيهات في الطبيعة) كمستوى جديد للوراثة .
15.4. نهج قائم على الكائن لتطوير الوصف الخارجي والهندسة المعمارية لأداة برمجية.
التصميم الموجه للكائنات - طريقة تستخدم تحلل الكائن ؛ النهج الموجه للكائنات له نظام اصطلاح خاص به ويقدم مجموعة غنية من النماذج المنطقية والفيزيائية لتصميم أنظمة معقدة للغاية. ...
قدم التحليل الموجه للكائنات (OOA) نهج الكائن. يهدف OOA إلى إنشاء نماذج أقرب إلى الواقع باستخدام نهج موجه للكائنات ؛ إنها منهجية يتم فيها تشكيل المتطلبات على أساس مفاهيم الفئات والأشياء التي تشكل مفردات المجال. ...
ميزات البرمجة الشيئية.
الكائنات والفئات وسلوك الكائن والخصائص والأحداث.
أدب المحاضرة 15.
15.1. K. Fuchi ، N. Suzuki. لغات البرمجة والدوائر VLSI. - م: مير ، 1988 S. 85-98.
15.2. إيان سومرفيل. هندسة البرمجيات. - شركة أديسون ويسلي للنشر ، 1992. ص.؟ -؟
15.3. G. بوش. التصميم الموجه للكائنات مع أمثلة للتطبيق: لكل. من الانجليزية - م: كونكورد ، 1992.
15.4. في ش كوفمان. لغات البرمجة. المفاهيم والمبادئ. م: الراديو والاتصالات ، 1993.
جيه. هيوز ، ج. ميتشتوم. نهج منظم للبرمجة. - م: مير ، 1980. - ص. 29-71.
في تورسكي. منهجية البرمجة. - م: مير ، 1981. - ص 90-164.
إي. Zhogolev. الأسس التكنولوجية للبرمجة المعيارية // البرمجة ، 1980 ، لا. - ص.44-49.
أر سي هولت. هيكل برامج الكمبيوتر: مسح // وقائع IEEE ، 1975 ، 63 (6). - ص. 879-893.
جي مايرز. موثوقية البرنامج. - م: مير ، 1980. - ص. 92-113.
يا بايل. ADA هي لغة الأنظمة المضمنة. م: المالية والإحصاء ، 1984. - ص. 67-75.
زيلكوفيتس ، أ.شو ، ج. غانون. مبادئ تطوير البرمجيات. - م: مير ، 1982 ، ص. 65-71.
أل فوكسمان. الجوانب التكنولوجية لإنشاء أنظمة البرمجيات. م: الإحصاء ، 1979. - ص. 79-94.
تين. 8.4 مثال على خطوة واحدة للتفصيل في الكود الكاذب.