في علم الحاسوب، على وجه الخصوص هندسة البرمجياتوهندسة الحاسوب، تعد الطرق الشكلية نوعًا خاصًا من أنواع التقنيات القائمة على الحساب من أجل المواصفات والتطوير والتحقق من أنظمة البرمجياتوأجهزة الكمبيوتر.[1] والدافع وراء استخدام الطرق الشكلية لتصميم البرمجيات والأجهزة هو التوقع بأن تنفيذ التحليل الحسابي المناسب، كما هو الحال في الأنظمة الهندسية الأخرى، يمكن أن يساهم في زيادة اعتمادية وقوة التصميم.[2]
يمكن استخدام الطرق الشكلية على مجموعة من المستويات:
المستوى 0:المواصفات الشكلية يمكن تنفيذها وبالتالي يمكن تطوير برنامج منها بشكل غير شكلي. وقد أطلق على ذلك اسم الطرق الشكلية الخفيفة. ويمكن أن يكون هذا الخيار هو أفضل الخيارات من ناحية التكلفة في العديد من الحالات.
المستوى 1:التطوير الشكليوالتحقق الشكلي يمكن استخدامهما لإنتاج برنامج بطريقة أكثر شكلية. على سبيل المثال، يمكن تنفيذ أدلة المملتكات أو التحسين من المواصفات لبرنامج. ويمكن أن يكون ذلك ملائمًا بأكبر شكل ممكن في الأنظمة عالية التكامل التي تشتمل على السلامة أو الأمن.
المستوى 2:إثبات النظريات يمكن استخدامه لتنفيذ أدلة شكلية يتم فحصها من خلال الأجهزة. ويمكن أن يكون هذا المستوى مكلفًا للغاية، ولا يمكن أن يكون مجديًا من الناحية العملية إلا إذا كانت تكلفة الأخطاء كبيرة للغاية (على سبيل المثال، في الأجزاء الخطيرة من تصميم المعالج الصغير).
وكما هو الحال في سيمانتيك لغة البرمجة، فإن أنماط الطرق الشكلية يمكن أن يتم تصنيفها بشكل تقريبي كما يلي:
سيمانتيك الدلالة، التي يتم فيها التعبير عن معنى النظام بالنظرية الحسابية الخاصة بالنطاقات. ويعتمد أنصار هذه الطرق على الطبيعة المفهومة للغاية للنطاقات من أجل توفير معنى للأنظمة، أما المنتقدون فيقولون إنه ليس كل نظام يمكن أن ينظر إليه بشكل بديهي أو طبيعي على أنه وظيفة.
سيمانتيك التشغيل، التي يتم فيها التعبير عن معنى النظام في شكل تسلسل للإجراءات لنموذج حسابي (من المفترض أنه) أبسط. ويشير أنصار هذه الطرق إلى بساطة النماذج الخاصة بهم كوسائل للوضوح المعبر، أما المنتقدون فيعارضون ذلك بقولهم إن مشكلة السيمانتيك يتم تأخيرها فقط (فمن الذي يقوم بتعريف سيمانتيك النموذج الأبسط؟).
سيمانتيك البديهة، التي يتم فيها التعبير عن معنى النظام بالشروط المسبقةوالشروط التالية التي يجب أن تتحقق قبل وبعد قيام النظام بتنفيذ مهمة ما، على التوالي. ويشير أنصار ذلك إلى العلاقة مع المنطق الكلاسيكي، أما المعارضون فيشيرون إلى أن هذا السيمانتك لا يشير مطلقًا بشكل فعلي إلى ما يقوم به النظام (بل ما يتحقق قبل وبعد فقط).
يرى بعض الممارسين أن مجتمع الطرق الشكلية قد ركز بشكل زائد عن الحد على الشكلية الكاملة للمواصفة أو التصميم.[4][5] وهم يؤكدون أن درجة التعبير عن اللغات المضمنة، بالإضافة إلى درجة تعقيد الأنظمة التي يتم وضع نماذج لها، تجعل الشكلية الكاملة مهمة صعبة ومكلفة. وكبديل لذلك، تم اقتراح العديد من الطرق الشكلية الخفيفة، والتي تركز على المواصفة الجزئية والتطبيق الذي يتم التركيز عليه. وتشتمل أمثلة هذه المنهجية الخفيفة للطرق الشكلية على ملاحظات نمذجة كائن لغة ألوي،[6] وتوليف ديني لبعض أوجه تدوين زد مع التطوير المشتق من حالة الاستخدام،[7] وأدوات CSK طريقة تطوير فيينا (VDM).[8]
^Richard Denney, Succeeding with Use Cases: Working Smart to Deliver Quality, Addison-Wesley Professional Publishing, 2005, ISBN 0-321-31643-6.
^Sten Agerholm and Peter G. Larsen, "A Lightweight Approach to Formal Methods", In Proceedings of the International Workshop on Current Trends in Applied Formal Methods, Boppard, Germany, Springer-Verlag, October 1998 نسخة محفوظة 22 سبتمبر 2009 على موقع واي باك مشين.
جوناثان بوين and Michael G. Hinchey, Formal Methods. In Allen B. Tucker, Jr. (ed.), Computer Science Handbook, 2nd edition, Section XI, Software Engineering,Chapter 106, pages 106-1 – 106-25, Chapman & Hall / سي آر سي بريس، رابطة مكائن الحوسبة, 2004.
Michael G. Hinchey, Jonathan P. Bowen, and Emil Vassev, Formal Methods. In Philip A. Laplante (ed.), Encyclopedia of Software Engineering, تايلور وفرانسيس, 2010, pages 308–320.