Resmi yöntemlerin yaygın olarak benimsenmesini engelleyen engeller nelerdir? [kapalı]

Bir uygulama için kod belirlemek, kanıtlamak ve oluşturmak için biçimsel yöntemler kullanılabilir. Bu hatalara daha az yatkındır - bu nedenle çoğunlukla güvenlik / kritik programlarda kullanılır.

Neden günlük programlamada veya web uygulamalarında vb. Daha sık kullanmıyoruz?

Referanslar :

• Biçimsel yöntemler
• B Yöntemi
• Hoare Mantık

Bir Mühendis, herhangi bir salakın 10 ile yapabileceği bir dolar ile yapabilen bir kişidir.

Kaynak kısıtlamaları, bütçe kısıtlamaları, zaman kısıtlamaları, hepsi önemlidir.

Resmi yöntemleri kullanarak yazılım geliştirmek genellikle çok daha pahalıdır ve olmadan daha uzun sürer. Ayrıca, birçok proje için en zor kısım iş gereksinimlerini anlamaktır. Bu durumda, resmi yöntemleri kullanan her şey, kodunuzun iş gereksinimlerini tam ve yanlış anlamanıza% 100 karşılık geldiğinin kanıtıdır.

Bu nedenle, resmi yöntemlerin, ispatların, program doğrulamasının ve benzer tekniklerin kullanımı tipik olarak "önemli olan şeyler", yani aviyonik yazılım, tıbbi ekipman kontrol sistemleri, enerji santralleri vb. İle sınırlıdır.

Programlamak ya da programlamak değil mi?

Bir yazılım ürünü ile bir sorunu çözmek için, ihtiyaçları konusunda uzman yaptıktan sonra şunları yapabilirsiniz YA programlama dillerini kullanarak bir program yazmak YA resmi dil ve kullanım kod oluşturma araçlarını kullanarak programı belirtin. İkincisi sadece bir soyutlama seviyesi ekler.

İşleri doğru yapmak veya doğru şeyleri yapmak?

Resmi yaklaşım, yazılımınızın spesifikasyonlara göre çalıştığına dair bir kanıt sağlar. Böylece ürününüz her şeyi doğru yapıyor. Ama doğru şeyleri yapıyor mu?

Üzerinde çalıştığınız gereksinimler eksik veya belirsiz olabilir. Buggy bile olabilirler. En kötü durumda, gerçek ihtiyaçlar bile ifade edilmez. Ancak bir resim bin kelimeye bedeldir, sadece "Müşterinin ne istediği" için google resimleri, örneğin bu makaleden :

Formalitenin maliyeti

Mükemmel bir dünyada, baştan itibaren tamamen ayrıntılı ve mükemmel gereksinimlere sahip olacaksınız. Daha sonra yazılımınızı tam olarak belirtebilirsiniz. Biçimlendirmeyi tercih ederseniz, kodunuz daha üretken olmanız için otomatik olarak oluşturulur. Verimlilik kazanımları, resmi araçların maliyetini dengeleyecektir. Ve şimdi herkes resmi yöntemler kullanırdı. Öyleyse neden olmasın?

Pratikte, bu nadiren gerçek! Bu yüzden birçok şelale projesi başarısız oldu ve yinelemeli geliştirme yöntemleri (çevik, RAD, vb.) Neden liderlik etti: eksik ve eksik gereksinimleri, tasarımları ve uygulamaları ele alabilir ve iyiye ulaşıncaya kadar geliştirebilirler.

Ve işte mesele geliyor. Biçimsel yöntemlerle, her bir yinelemenin tamamen tutarlı bir biçimsel spekülasyona sahip olması gerekir. Bu, dikkatli düşünme ve ek çalışma gerektirir, çünkü resmi mantık affedici değildir ve eksik düşünceleri sevmez. Basit fırlatma deneyleri bu kısıtlama altında pahalı hale gelir. Ve geri izlemeye yol açacak her bir yineleme de (örneğin işe yaramayan bir fikir ya da yanlış anlaşılmış bir gereksinim).

Uygulamada

Yasal veya sözleşmeye bağlı nedenlerle resmi yöntemleri kullanmak zorunda olmadığında, resmi sistemlere gerek olmadan, örneğin sözleşmeye dayalı programlama ve diğer iyi uygulamaları (örn. Kod incelemesi, TDD , vb.) Kullanarak da çok yüksek kalite elde edebilirsiniz . Yazılımınızın çalıştığını kanıtlayamazsınız, ancak kullanıcılarınız daha önce çalışan yazılımların keyfini çıkaracaklardır.

Güncelleme: ölçülen çaba

ACM'nin Ekim 2018 sayısında , gerçek dünyada resmi olarak doğrulanmış yazılım hakkında , çabaların bazı tahminleri ile ilginç bir makale var .

İlginç bir şekilde (askeri teçhizat için işletim sisteminin geliştirilmesine dayanarak), resmi olarak kanıtlanmış yazılım üretmek , geleneksel mühendislik tekniklerinden 3.3 kat daha fazla çaba gerektiriyor gibi görünüyor . Bu yüzden gerçekten pahalı.

Öte yandan, bu tür bir yazılımı yüksek güvenlik düzeyinde (EAL 7) sertifikalı hale getirme çabasını eklerseniz, yüksek güvenlikli yazılımı bu yolla geleneksel olarak tasarlanmış yazılımlara göre 2.3 kat daha az çaba gerektirir . Bu nedenle, yüksek güvenilirlik veya güvenlik gereksinimleriniz varsa, resmi hale gelmek için kesinlikle bir iş durumu vardır.

seL4 tasarım ve kod geliştirme iki kişi-yıl sürdü. Yıllar boyunca tüm serospesifik kanıtları toplamak, 8.700 satır C kodu için toplam 18 kişi-yıla geliyor. Buna karşılık, L4 ailesindeki başka bir mikro çekirdek olan L4Ka :: Pistachio, boyut olarak seL4 ile karşılaştırılabilir, gelişmesi altı kişi yılı aldı ve önemli bir güvence düzeyi sağlamaz. Bu, doğrulanmış yazılım ile geleneksel olarak tasarlanmış yazılım arasında yalnızca bir faktör 3.3 olduğu anlamına gelir . Colbert ve Boehm tarafından yapılan tahmin yöntemine göre, 8,700 satır C kodu için geleneksel bir Ortak Kriterler EAL7 sertifikası 45,9 kişiden fazla sürecektir. Bu, resmi ikili düzeydeki uygulama doğrulamasının zaten 2,3 katından fazla olduğu anlamına gelir en yüksek Ortak Kriterler sertifikasyon seviyesinden daha az maliyetli olmakla birlikte, daha güçlü bir güvence sağlar.

Herhangi bir dildeki her program resmi bir şartname olarak düşünülebilir (bazı tornalama makinelerine eşdeğer). Resmi doğruluğu kanıtlamak için kullanılacak herhangi bir üst düzey 'resmi şartname' de - sadece başka bir program. Ancak (tipik olarak) kötü, eksik, belirsiz, program aracılığıyla yeterince düşünülmemiştir. Ve tesadüfen değil, tipik olarak nasıl programlanacağını bilmeyen insanlar tarafından yazılır (genellikle alan uzmanlarıdır).

Ve böylece, bir programın daha yüksek düzeydeki resmi gereksinimleriyle uyumlu olduğunu (aynı cevapları üretir ya da karakterize edersiniz) kanıtlamak için, değişmez olan, daha üst düzey resmi spesifikasyondaki belirsizlikleri nasıl çözdüğünüze iner. Bunu yapmanın iyi bir genel amacı yoktur.

Yüksek seviye gerekliliklerin daha düşük seviye detaylara eşlenmesi, gerçek programlamanın ne olduğunun özüdür. Spesifikasyonları okuyan ve yorumlayan bir programcı tarafından yapılan temel çalışmanın yerini elle sallayarak ve 'şimdi sadece bu yüksek seviyeli resmi spesifikasyonun bu örnek programa uyup uymadığını görün' diyerek değiştiremeyeceği şaşırtıcı olmamalıdır.

Bu kavramın ilk defa ümit verici göründüğü mantık programlamanın ilk günlerinde bile (hem üst düzey spesifikasyonlar hem de gerçek temel programlar aynı dilde yazılabildiğinden), bu temel sorun inatçı oldu.