Programın Doğruluğu, Şartname

Wikipedia'dan: Teorik bilgisayar biliminde, algoritmanın bir spesifikasyona göre doğru olduğu söylendiğinde bir algoritmanın doğruluğu iddia edilir.

Ancak sorun, "uygun" şartnameyi elde etmenin önemsiz bir görev olmaması ve doğru olanı elde etmek için% 100 doğru bir yöntem (bildiğim kadarıyla) olmaması, sadece bir tahmin, yani sadece "biri" gibi "göründüğü" için bir şartname belirleme, neden programı "doğru" göründüğü için doğru olarak almıyorsunuz?

Öncelikle, kesinlikle haklısın: gerçek bir endişe içindesin. Resmi doğrulama, program doğruluğuna olan güven problemini şartnamenin doğruluğuna olan güven problemine aktarır, bu yüzden gümüş bir kurşun değildir.

Bununla birlikte, bu sürecin hala yararlı olmasının birkaç nedeni vardır.

1. Spesifikasyonlar genellikle kodun kendisinden daha basittir. Örneğin, bir tamsayı dizisini sıralama sorununu düşünün. Performansı artırmak için akıllıca şeyler yapan oldukça karmaşık sıralama algoritmaları vardır. Ancak spesifikasyonun belirtilmesi oldukça basittir: Çıktının artan sırada olması ve girdinin bir permütasyonu olması gerekir. Bu nedenle, şartnamenin doğruluğuna güvenmek, kodun kendisinin doğruluğundan daha kolay olur.

2. Tek bir başarısızlık noktası yoktur. Bir kişinin bir belirtimi yazdığını ve başka bir kişinin kaynak kodunu yazdığını ve ardından kodun spesifikasyona uygun olduğunu resmi olarak doğruladığınızı varsayalım. Daha sonra tespit edilmeyen herhangi bir kusur hem spesifikasyonda hem de kodda mevcut olmalıdır. Bazı durumlarda, kusurları bazı türleri, daha az olasılıkla bu hissettiğini için: daha az olasılıkla spec teftiş sırasında kusur göz ardı ediyorum işte ve kaynak kodu kontrol ederken kusur bakmaktadır. Hepsi değil, bazıları.

3. Kısmi özellikler koddan çok daha basit olabilir. Örneğin, programın arabellek taşması güvenlik açıklarından arınmış olması gerektiğini düşünün. Veya, dizi dizini sınırı dışında hata olmaması gereksinimi. Bu, kanıtlamak için oldukça iyi ve kullanışlı bir şey olan basit bir özelliktir. Şimdi tüm programın bu spesifikasyonu karşıladığını kanıtlamak için resmi yöntemleri kullanmaya çalışabilirsiniz. Bu oldukça ilgili bir görev olabilir, ancak başarılı olursanız, programa daha fazla güven kazanırsınız.

4. Özellikler koddan daha az değişebilir. Resmi yöntemler olmadan, kaynak kodunu her güncellediğimizde, güncellemenin herhangi bir hata veya kusur içermediğini manuel olarak kontrol etmeliyiz. Resmi yöntemler potansiyel olarak bu yükü azaltabilir: özelliklerin değişmediğini varsayalım, böylece yazılım güncellemeleri sadece kodda değişiklikler içerir ve spesifikasyonda değişiklik yapmaz. Daha sonra her güncelleme için, spesifikasyonun hala doğru olup olmadığını kontrol etme yükünden (değişmemiştir, bu nedenle spesifikasyonda yeni hataların ortaya çıkma riski yoktur) ve kodun hala olup olmadığını kontrol etme yükünden kurtuldunuz. (program doğrulayıcı bunu sizin için kontrol eder). Orijinal spesifikasyonun doğru olup olmadığını kontrol etmeniz gerekir, ancak bir geliştirici her yeni yama / güncelleme / değişiklik gerçekleştirdiğinde bunu kontrol etmenize gerek yoktur.

Son olarak, spesifikasyonların tipik olarak beyan edici olduğunu ve doğrudan kodla yürütülemeyeceğini veya derlenemeyeceğini unutmayın. Örneğin, yeniden sıralamayı düşünün: spesifikasyon, çıktının arttığını ve girdinin permütasyonu olduğunu söyler, ancak bu spesifikasyonu doğrudan "yürütmenin" açık bir yolu yoktur ve bir derleyicinin kodlamayı otomatik olarak derlemesi için açık bir yol yoktur. Bu nedenle, spesifikasyonu doğru olarak almak ve genellikle uygulamak bir seçenek değildir.

Bununla birlikte, sonuçta aynı kalır: resmi yöntemler her derde deva değildir. Kod doğruluğundaki (çok zor) güven sorununu, yalnızca doğruluktaki (sadece zor) güven sorununa aktarırlar. Spesifikasyondaki hatalar gerçek bir risktir, yaygındır ve göz ardı edilemezler. Aslında, resmi yöntemler topluluğu bazen sorunu iki parçaya ayırır: doğrulama , kodun spesifikasyonu karşılamasıyla ilgilidir; doğrulama , spesifikasyonun doğru olmasını sağlamakla ilgilidir (ihtiyaçlarımızı karşılar).

Uygulamada Resmi program doğrulamasının da keyfini çıkarabilirsiniz ve neden derleme süresi garantilerine yönelik daha fazla araştırma yapmıyoruz? daha fazla perspektif için.

DW'nin cevabı harika , ama bir noktaya genişlemek istiyorum. Spesifikasyon sadece kodun doğrulandığı bir referans değildir. Resmi bir spesifikasyona sahip olmanın nedenlerinden biri, bazı temel özellikleri kanıtlayarak bunu doğrulamaktır. Tabii ki, şartname tamamen doğrulanamaz - onaylama şartnamenin kendisi kadar karmaşık olacaktır, bu yüzden sonsuz bir süreç olacaktır. Ancak doğrulama, bazı kritik özellikler için daha güçlü bir garanti almamızı sağlar.

Örneğin, bir araba otopilotu tasarladığınızı varsayalım. Bu, birçok parametreyi içeren oldukça karmaşık bir şeydir. Otopilotun doğruluk özellikleri “araba duvara çarpmayacak” ve “araba gittiği söylenen yere gidecek” gibi şeyleri içerir. “Araba duvara çarpmayacak” gibi bir özellik gerçekten çok önemli, bu yüzden bunu kanıtlamak istiyoruz. Sistem fiziksel dünyada çalıştığından, bazı fiziksel kısıtlamalar eklemeniz gerekir; hesaplama sisteminin asıl özelliği “malzeme bilimi ile ilgili bu varsayımlar altında ve otomobilin sensörleri tarafından engellerin algılanmasıyla ilgili bu varsayımlar altında, araba bir duvara çarpmayacak” gibi bir şey olacaktır. Ancak buna rağmen, sonuç açıkça arzu edilen nispeten basit bir özelliktir.

Bu özelliği koddan kanıtlayabilir misiniz? Sonuçta, eğer tamamen resmi bir yaklaşım izliyorsanız, olan budur¹. Ancak kodun birçok farklı bölümü vardır; frenler, kameralar, motor vb. bağımsız olarak kontrol edilir. Frenlerin doğruluk özelliği, “'fren uygula' sinyali açıksa frenler uygulanır” gibi bir şey olacaktır. Motorun bir doğruluk özelliği “debriyaj sinyali kapalıysa, motor tekerlekleri sürmezse” olacaktır. Hepsini bir araya getirmek çok üst düzey bir görüş gerektirir. Bir spesifikasyon, sistemin farklı bileşenlerinin birlikte ifade edilebildiği bir ara katmanlar oluşturur.

Aslında, bir araba otopilotu gibi karmaşık bir sistem, değişen miktarlarda iyileştirmelerle birlikte birkaç spesifikasyon seviyesine sahip olacaktır. Tasarımda genellikle bir arıtma yaklaşımı kullanılır: “araba duvara çarpmayacak” gibi bazı üst düzey özelliklerle başlayın, daha sonra bunun sensörler ve frenler gerektirdiğini anlayın ve sensörler, frenler için bazı temel gereksinimleri öğrenin ve pilot yazılımı, daha sonra bu temel gereklilikleri bileşenin bir tasarımında (sensör için bir radar, bir DSP, bir görüntü işleme kütüphanesi, vb.) ihtiyacım olacak şekilde geliştirin. Resmi bir geliştirme sürecinde, her bir spesifikasyon seviyesinin, en üst seviye özelliklerden koda kadar, üstteki seviyenin belirlediği gereksinimleri karşıladığı kanıtlanmıştır.

Spesifikasyonun doğru olduğundan emin olmak imkansızdır. Örneğin, fiziği yanlış anladıysanız, fren kodunu resmi gerekliliklerle ilişkilendiren matematik doğru olsa bile frenler etkili olmayabilir. Gerçekten 5000kg'ınız varsa, molaların 500kg yük ile etkili olduğunu kanıtlamak iyi değildir. Ancak 500kg'ın fren kodunun içinde, aracın fiziksel parametreleri için yeterince iyi olmayacaklarını görmek yanlış olduğunu görmek daha kolaydır.

¹ _{tamamen biçimsel yaklaşımın tersidir “Ben bu işleri sanırım, ama emin olamaz”. Hayatınızı üzerine koyduğunuzda, bu çok iyi görünmüyor.}