البرمجة هي تجسيد الأفكار.

الأطروحة الرئيسية لهذه المقالة: يجب النظر إلى تطوير البرمجيات على أنه تجسيد للأفكار من خلال تحويل النماذج العقلية إلى رمز البرنامج.
تصف المقالة نموذج تجسيد الأفكار في هندسة البرمجيات (الإنجليزية: RPSE: Reification as Paradigm of Software Engineering).

النسخة الإنجليزية من المقالة: RPSE: Reification as Paradigm of Software Engineering . يستخدم الاختصار RPSE لاحقًا في النص للإشارة إلى النموذج الموصوف.

التعاريف الرئيسية

قبل مناقشة النقاط الرئيسية لهذه المقالة ، تحتاج إلى الاتفاق على معنى المصطلحات الأساسية المستخدمة فيه.

هندسة البرمجيات

نقصد بهندسة البرمجيات التعريف الكلاسيكي لتخصص هندسة البرمجيات من قاموس IEEE [1]: هندسة البرمجيات هي "تطبيق منهج منظم ومنضبط وقابل للقياس لتطوير البرامج وتشغيلها وصيانتها".

نموذج

يعتمد مصطلح النموذج المستخدم في هذه المقالة على التعريف الكلاسيكي لنموذج Thomas Kuhn [2]: النموذج هو دائرة من المشاكل ، ومجموعة من المفاهيم ، والقواعد والقوانين المقبولة عمومًا ، وطرق حل المشكلات في مجال معين من العلوم.


اعتبر توماس كون النماذج العلمية في كتابه. ومع ذلك ، بعد فترة وجيزة من إصدار الطبعة الأولى من الكتاب ، أصبحت فائدة استخدام هذا المفهوم في التكنولوجيا والمجالات المختلفة للحياة الاجتماعية واضحة. في هذا الصدد ، ظهرت العديد من المنشورات حول النماذج وتغييرها في صناعة السيارات ، والتخطيط الحضري ، وعلاج أمراض معينة ، وما إلى ذلك في الأدب الخاص والشعبي.

لم تكن هندسة البرمجيات وخاصة مكونها الهام - البرمجة ، استثناءً. يوجد حاليًا العديد من نماذج البرمجة المتنافسة. مقال منفصل على ويكيبيديا [3] ، بالإضافة إلى مراجعات مثيرة للاهتمام مثل [4] ، مكرسة لسردها.

تجسيد الأفكار

مصطلح تجسيد الأفكار (الإنجليزية: reification ) المستخدم في هذه المقالة هو امتداد للتعريف الكلاسيكي للتوحيد في علم الكمبيوتر: "Reification هي العملية التي يتم من خلالها تحويل فكرة مجردة حول برنامج الكمبيوتر إلى نموذج بيانات صريح أو كائن آخر تم إنشاؤه بلغة برمجة" [6].


لتقييم أو قياس (للحصول على الخصائص الكمية) ليس من الضروري وجود عنصر. يكفي أن يكون نموذجه. علاوة على ذلك ، في العديد من المواقف المثيرة للاهتمام عمليًا ، يمكن استخدام النموذج بدون كائن. يمكن مناقشة النماذج مع الآخرين. يمكن التفاوض على النماذج. يمكن توحيد النماذج (إضفاء الطابع الرسمي).

في بعض مجالات النشاط البشري ، تم توحيد النماذج حتى الآن بحيث لا يمكن تمييز الأجزاء (على سبيل المثال ، المسامير الملولبة) المصنوعة على أساس نموذج موحد (مثل الرسم) من قبل أشخاص مختلفين أو مدافع رشاشة من وجهة نظر تكنولوجية.

إدراكًا لعدم الدقة النسبية للتعريف المقترح ، سأقسم لاحقًا في هذه المقالة عالم ظواهر عالمنا الداخلي والخارجي U إلى قسمين:

U = M + I

حيث تتكون مجموعة M من ظواهرها التي يمكن تسجيلها أو قياسها بشكل موضوعي (العالم المادي) وأنا - كل شيء آخر.

ما إذا كانت هذه الصيغة قابلة للتطبيق على جميع ظواهر العالم من حولنا على الإطلاق هو سؤال فلسفي مفتوح. لاحقًا في هذه المقالة ، قمنا بتضييق نطاق هذه الصيغة على عالم الظواهر من عالم هندسة البرمجيات.

أو صياغتها كرسالة: يمكن تقسيم مجموعة الظواهر المتعلقة بهندسة البرمجيات إلى مجموعة فرعية من المثالية ومجموعة فرعية من المادة. علاوة على ذلك ، يتم تسجيل أو قياس الظواهر المادية بناءً على نماذجها.
تنتهي عملية إنشاء أو تعديل نظام البرمجيات في معظم الحالات بإنشاء رمز أو آخر ، والذي يتم عرضه باستخدام جهاز كمبيوتر في عملية مادية (ظاهرة حقيقية).

تبدأ هذه العملية بظهور أفكار معينة عن النظام المستقبلي في أذهان العملاء أو المطورين. سوف نسمي هذه الأفكار والأفكار نموذجًا عقليًا .

تجسيد الأفكار في المناطق المجاورة لهندسة البرمجيات

من الواضح أن التعريف أعلاه ليس جديدًا بشكل جذري ويستخدم على نطاق واسع (بوعي أو بغير وعي) في مجالات العمل الفكري المجاورة للبرمجة. على سبيل المثال ، ضع في اعتبارك مجالين - الهندسة الميكانيكية والرياضيات.

كان هذان المجالان يستخدمان تجسيد الأفكار لفترة طويلة وفعالة. لديهم الكثير لتعلمه عن البرمجة في هذا الصدد.

في الهندسة الميكانيكية ، نرى دورة كاملة لتجسيد الأفكار - من ظهور فكرة في رأس المصمم من خلال تفكيره من خلال تفصيل النموذج ورسم الخرائط عليه ، وأخيرًا - التصنيع من مادة معينة.

الوضع مختلف في الرياضيات.


"المنتج النهائي" للرياضيات هو نماذج رسمية ذات خصائص مثبتة بدقة.

من وجهة النظر هذه ، تكون البرمجة في المنتصف. يمكن تصوير هذا بيانياً على النحو التالي:



وبالتالي ، تستخدم الرياضيات عددًا أكبر من النماذج المجردة وأكثر تقريبًا لا تنطبق على مجال النماذج المحددة للغاية مثل الرسومات الهندسية.

على العكس من ذلك ، تستخدم الهندسة الميكانيكية عددًا قليلاً نسبيًا من النماذج المجردة ، ولكن العديد من النماذج المحددة. على سبيل المثال ، تلك التي يمكن صنع أشياء مادية بشكل لا لبس فيه.

من وجهة النظر هذه ، تكون البرمجة في المنتصف.

تعريف ومحيط نموذج تجسيد الأفكار (RPSE)

لقد حددنا جميع المفاهيم اللازمة لإعطاء تعريف أساسي للنموذج المقترح. ها هي:

تطوير البرمجيات هو تجسيد الأفكار من خلال تحويل النماذج العقلية إلى كود يتم تنفيذه على أجهزة الكمبيوتر.

في إطار النموذج المقترح:

1. جميع عمليات تطوير البرمجيات الرئيسية هي متغيرات محددة (تطبيقات) لعملية بناء سلاسل من النماذج العقلية والمادية. آخر نموذج محدد في هذه السلسلة هو ، كقاعدة عامة ، رمز البرنامج.
2. جوهر تطوير البرمجيات هو إنشاء مثل هذه السلاسل.
3. يمكن تخفيض جميع القضايا الرئيسية لتحسين التنمية ، وخفض تكلفتها وتحسين جودتها لتحسين بناء سلسلة النماذج المقابلة.

التعريف أعلاه له خصائصه وتنوعاته في مجالات مختلفة من هندسة البرمجيات. فقط في عدد قليل جدًا من الحالات ، يحدث أنه في رأس المبرمج ، تنضج فكرة واضحة عن كيفية حل المهمة قبله تمامًا ، والتي يترجمها بعد ذلك إلى رمز لغة برمجة في وقت قصير. في معظم المشاريع الواقعية ، تتعايش عملية إيجاد حل وتطبيقه بالتوازي وتتفاعل مع بعضها البعض. على سبيل المثال النماذج العقلية ، الشفرة ، والنماذج المتوسطة غالبًا (في شكل اختبار ، صور ، نماذج رسمية مثل UML) تنمو وتتغير بالتوازي ، مما يؤثر على بعضها البعض.


ماذا يمكن أن يقال عن نموذج معين اليوم ، هل من الممكن تحديد خطوطه بدقة أكثر بطريقة أو بأخرى؟

الخطوة التالية لتنقيح النموذج بعد محاولة إعطاء تعريفه الرئيسي هي محاولة سرد الفئات الرئيسية للظواهر التي تؤثر عليها. بالإشارة إلى تعريف Kuhn ، نحتاج إلى محاولة سرد أنواع النماذج التي يقدمها RPSE ويستخدمها.

يمكن تقسيم نماذج RPSE إلى ثلاث فئات رئيسية:

• النماذج العقلية
• التعليمات البرمجية بلغات البرمجة أو ما يعادلها كنماذج للتعليمات البرمجية القابلة للتنفيذ.
• نماذج وسيطة.

الأقل استكشافًا في هذا الثالوث هو النماذج العقلية. ما هو المقصود بهم بالضبط؟

النماذج العقلية هي مصطلح للأفكار الموجودة في رأس العملاء والمبرمجين والمشاركين الآخرين في العملية والتي على أساسها يظهر الكود القابل للتنفيذ أخيرًا. إن وجود مثل هذه النماذج أمر لا جدال فيه ويمكن تسجيله على المستوى العقلي ، على سبيل المثال ، من قبل المبرمج نفسه.على المستوى الحالي للتطور التكنولوجي ، لا يمكن قياس هذه النماذج بشكل موثوق من خلال الأدوات.

إحدى طرق العمل الجيدة لإصلاح وقياس هذه النماذج هي استخدام وسيط الفكرة. من الواضح أن عملية المقابلة أو ما شابهها تؤثر بشكل كبير على النموذج العقلي نفسه. لا بد أن كل واحد منا قد واجه وضعًا أكثر من مرة عندما أدت محاولة صياغة مشكلة من أجل التشاور مع زميل وحده إلى "نظرة ثاقبة" ، وغالبًا إلى حل للمشكلة.

تسمح المقابلات ، بناءً على الأسئلة المصاغة بشكل صحيح ، ببناء نماذج ذات موضوعية مختلفة التعقيد نسبيًا. الأكثر شيوعًا هي:
النماذج الهيكلية:

• قوائم بقيم ثنائية وتعداد ورقم وسلسلة وقيم أخرى.
• هياكل بيانات الرسم البياني والشبكة

نماذج الوصف السلوكي:

• النماذج السبعة الرسمية لتحديد السلوك
• النماذج الرسمية لتحديد السلوك (على سبيل المثال ، آلات الحالة المحدودة)

لماذا تحتاج هندسة البرمجيات إلى نموذج شامل؟

إن وجود نموذج "شامل" يفتح الاحتمالات التالية للمشاركين الذين يستخدمون نموذج عملية إنشاء البرامج وتعديلها واستخدامها:

• قدرة جميع المشاركين في العملية على استخدام المصطلحات نفسها.
• القدرة على بناء عملية شاملة لإنشاء برامج جديدة.
• القدرة على تقييم معلمات العملية ونتائجها الوسيطة وإدارتها.

.

الأهداف الرئيسية لتطوير النموذج

مشاكل نظرية

, [2], , , . . فيما يلي أهمها:

1. .
2. / vs. / .
3. .
4. , .
5. .

إلى جانب المهام النظرية لتطوير وتنفيذ النموذج الموصوف في ممارسة هندسة البرمجيات ، من الضروري حل المهام العملية التالية على الأقل:

1. إنشاء أدوات من أجل: أ) استخراج وتحديد النماذج العقلية. ب) التحول الآلي والتلقائي للنماذج العقلية إلى نماذج وسيطة. ج) آثار وتقديرات التغيرات في محتوى النماذج القابلة للتحويل
2. إنشاء الأدب الفني والتربوي الضروري والمواد التعليمية الأنسية الأخرى.
3. تنظيم المنتديات والمؤتمرات حول هذا الموضوع

الخلاصة

تحاول هذه المقالة تعريف نموذج هندسة البرمجيات على أنه تجسيد للأفكار. لا يتم استخدام كلمة التعريف (وليس مفتوحًا) هنا عن طريق الصدفة. في الواقع ، انخرط المشاركون في مشروعات تكنولوجيا المعلومات منذ فترة طويلة في إنشاء النماذج واستخدامها وتحويلها ، ربما دون أن يدركوا ذلك.

بالمعنى الدقيق لتعريف Kuhn ، لا يمكن للمنهج الموصوف بعد أن يدعي الحق في أن يُسمى نموذجًا ، ولكن فقط مرشحًا للنموذج ، لأنه لا يحتوي على مجتمع واسع من الأشخاص الذين يدعمونه ونظام متطور جيدًا من النماذج المترابطة. ومع ذلك ، أريد أن أعتقد أن أوجه القصور سيتم التغلب عليها قريبًا.

هذه هي المقالة الأولى في سلسلة من المقالات المخططة. في المقالات التالية سوف أتحدث عن النماذج العقلية والمتوسطة.

الأدب

1. IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3. Programming paradigm: en.wikipedia.org/wiki/Programming_paradigm (state — 27.08.2018)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. September 2007). ISBN-13: 978-3446407442.
5. Software Engineering Paradigms And Models Information Technology Essay
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (state — 27.08.2018)
6. Reification (computer science) en.wikipedia.org/wiki/Reification_ (computer_science) (state — 27.08.2018)
7. . Silentium! ( (.), 1829 .
8. Borovik, Alexandre. Mathematics under the microscope: notes on cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978-0821847619.

: geralt