Uygulamada resmi program doğrulama

Bir yazılım mühendisi olarak, endüstriyel ürünler için çok fazla kod yazıyorum. Sınıflar, iplikler, bazı tasarım çabaları ile nispeten karmaşık şeyler, fakat aynı zamanda performanstan ödün verir. Çok fazla test yapıyorum ve test yapmaktan bıktım, bu yüzden Coq, Isabelle gibi resmi kanıt araçlarına ilgi duydum ... Kodumun hatasız olduğunu ve yapıldığını resmi olarak kanıtlamak için bunlardan birini kullanabilir miyim Bununla birlikte? - ama bu araçlardan birini her kontrol ettiğimde, günlük yazılım mühendisliği için kullanılabilir olduklarına ikna olmuyorum. Şimdi, bu sadece ben olabilirim ve bu konuda işaretçilere / düşüncelere / fikirlere bakıyorum :-)

Özellikle, bu araçlardan birinin benim için çalışmasını sağlamak için, incelenen programın amaçlarını, yöntemlerini ... doğrulamak için büyük bir yatırım gerektireceği izlenimini edindim. O zaman merak ediyorum, başa çıkması gereken her şeyin boyutu göz önüne alındığında, ispatcının buharı bitip bitmeyeceğini merak ediyorum. Veya belki de yan etkilerden kurtulmam gerekebilir (bu kanıtlayıcı araçlar bildirimsel dillerle gerçekten iyi sonuç verir) ve bunun hızlı bir şekilde kullanılmayacağı için kullanılamayan "kanıtlanmış kod" ile sonuçlanıp sonuçlanmayacağını merak ediyorum. yeterince küçük. Ayrıca, çalıştığım dili değiştirme lüksüne sahip değilim, Java veya C ++ olması gerekiyor: Patronuma bundan sonra OXXXml'de kod yazacağımı söyleyemem, çünkü ki kodun doğruluğunu ispatlayabilirim ...

Resmi ispat araçları hakkında daha fazla deneyime sahip biri yorum yapabilir mi? Yine - Resmi bir prover aracı kullanmayı SEVİYORUM , harika olduklarını düşünüyorum, ama Java / C ++ 'nın alçak hendekinden ulaşamadığım fildişi bir kulede oldukları izlenimini edindim ... (PS: I ayrıca LOVE Haskell, OCaml ... yanlış bir fikre kapılmayın: Ilancı dillerin ve resmi ispatların hayranıyım, sadece bunu yazılım mühendisliği için gerçekçi olarak nasıl faydalı hale getirebileceğimi görmeye çalışıyorum)

Güncelleme: Bu oldukça geniş olduğundan, aşağıdaki daha spesifik soruları deneyelim: 1) endüstriyel Java / C ++ programlarının doğruluğunu kanıtlamak için kanıt kullanmanın örnekleri var mı? 2) Coq bu görev için uygun olur mu? 3) Coq uygunsa, önce Coq'da programı yazmalı mı, sonra da Coq dan C ++ / Java oluşturmalı mıyım? 4) Bu yaklaşım diş çekme ve performans optimizasyonlarını gerçekleştirebilir mi?

Bazı sorularınıza kısa ve öz bir cevap vermeye çalışacağım. Lütfen bunun kesinlikle benim araştırma alanım olmadığını unutmayın, bu nedenle bilgilerimin bazıları modası geçmiş / yanlış olabilir.

1. Java ve C ++ özelliklerini resmen kanıtlamak için özel olarak tasarlanmış birçok araç vardır.

   Ancak burada küçük bir kazıma ihtiyacım var: programın doğruluğunu kanıtlamak ne anlama geliyor? Java tipi denetleyicisi, bir Java programının resmi bir özelliğini kanıtlar, yani a floatve a gibi bazı hatalar intasla gerçekleşemez! Programınızın asla istenmeyen bir duruma giremediğini veya belirli bir işlevin çıktısının belirli bir matematiksel belirtime uygun olduğunu, yani daha güçlü özelliklerle ilgilendiğinizi hayal ediyorum. Kısacası, basit bir güvenlik özelliklerinden, programın ayrıntılı bir şartnameyi yerine getirdiğine dair tam bir kanıtı olan "bir programın doğru olduğunu kanıtlamanın" ne anlama geldiği konusunda geniş bir degrade vardır.

   Şimdi, programlarınız hakkında güçlü özellikler kanıtlamakla ilgilendiğinizi farz edeceğim. Güvenlik özellikleri ile ilgileniyorsanız (program olabilir değil belli bir duruma ulaşması), sonra genel olarak en iyi yaklaşımdır görünüyor model kontrolü . Bununla birlikte, bir Java programının davranışını tam olarak belirtmek istiyorsanız, en iyi seçeneğiniz o dil için, örneğin JML için bir belirtim dili kullanmaktır . C programlarının davranışını belirtmek için böyle diller var, örneğin ACSL , ama C ++ hakkında bilgim yok.

2. Spesifikasyonlarınızı öğrendikten sonra, programın bu şartnameye uygun olduğunu kanıtlamanız gerekir.

   Bunun için, yeterlilik teoremini ifade etmek için , yani programın uygulanmasının şartnameye saygılı olması için , hem şartnamenizi hem de dilinizin operasyonel anlamını (Java veya C ++) resmi olarak anlayan bir araca ihtiyacınız var .

   Bu araç aynı zamanda bu teoremin kanıtını formüle etmenize veya oluşturmanıza da izin vermelidir. Şimdi bu görevlerin her ikisi de (belirleme ve kanıtlama) oldukça zor, bu yüzden genellikle ikiye ayrılıyorlar:

   • Kodu ayrıştıran, tanımlayan ve yeterlilik teoremini üreten bir araç. Frank'in dediği gibi , Krakatoa böyle bir araca örnektir.

   • Teoremi / teorileri kanıtlayan, otomatik veya etkileşimli bir araç. Coq, Krakatoa ile bu şekilde etkileşime girer ve Z3 gibi kullanılabilecek bazı güçlü otomatik araçlar da vardır.

   Bir (küçük) nokta: otomatik metotlarla kanıtlanması zor olan bazı teoremler vardır ve otomatik teorem provenlerin zaman zaman kendilerini daha az güvenilir yapan sağlamlık hataları olduğu bilinmektedir. Bu, Coq'un karşılaştırmalı olarak parladığı bir alandır (ancak otomatik değildir!).

3. Ocaml kodu oluşturmak istiyorsanız, önce kesinlikle Coq (Gallina) yazıp kodu çıkarın. Bununla birlikte, Coq, eğer mümkünse, C ++ veya Java üretmek için de korkunç.

4. Yukarıdaki araçlar diş açma ve performans sorunlarını çözebilir mi? Muhtemelen hayır, performans ve iş parçacığı endişeleri özellikle zor problemler olduğu için özel olarak tasarlanmış araçlar tarafından ele alınmalıdır. Martin Hofmann'ın PolyNI projesi ilginç gibi görünse de , burada önereceğim herhangi bir araç olduğundan emin değilim .

Sonuç olarak: “gerçek dünya” nın resmi doğrulaması Java ve C ++ programlarının büyük ve gelişmiş bir alan olduğu ve Coq bu görevin bölümleri için uygundur. Örneğin üst düzey bir genel bakışı burada bulabilirsiniz .

Endüstride ya da önemsiz olmayan gerçek sistemlerde üç resmi yöntem / resmi doğrulama aracı uygulamasından bahsetmek isterim. Bu konuda çok az deneyimim olduğunu ve sadece okuma kitaplarından öğrendiğimi unutmayın.

1. 2005 yılında NASA tarafından yayınlanan açık kaynaklı Java Pathfinder (kısaca JPF) , çalıştırılabilir Java bytecode programlarını doğrulayan bir sistemdir (bkz. Java Pathfinder @ wiki ). NASA Ames'teki K9 Rover'ın yürütme yazılımındaki tutarsızlıkları tespit etmek için kullanılmıştır.

2. Bu yazıda: Ciddi Dosya Sistemi Hatalarını Bulmak İçin Model Kontrolünün Kullanılması @ OSDI'04 @ dosya sistemlerinde ciddi hataları bulmak için model kontrolün nasıl kullanılacağını göstermektedir. FiSC adında bir sistem, yaygın olarak kullanılan, yoğun olarak test edilmiş üç dosya sistemine uygulanır: ext3, JFS ve ReiserFS ve 32 ciddi hata bulundu. En İyi Kağıt Ödülü'nü kazandı.

3. Bu makale: Amazon Web Servislerinin Resmi Yöntemleri Nasıl Kullandığı @ CACM'15 , AWS'nin S3, DynamoDB, EBS ve Internal dağıtılmış kilit yöneticisi gibi ürünlerine resmi yöntemleri nasıl uyguladığını açıklar. Lamport'un TLA + aracına odaklanır . Bu arada, Lamport kendi TLA araç kutusunu yoğun bir şekilde kullandı. Genellikle, makalelerin eklerinde, kendisi tarafından önerilen algoritmalar / teoremlerin TLA'sında (oldukça eksiksiz) resmi bir doğrulama yapar.

Bir programın resmi bir özelliği başka bir programlama dilinde yazılmış bir programdır (az ya da çok). Sonuç olarak, şartname kesinlikle kendi hatalarını içerecektir.

Resmi doğrulamanın avantajı, program ve şartname iki ayrı uygulama olduğundan, hatalarının farklı olacağı yönündedir. Ancak her zaman değil: gözden kaçan bir ortak hata kaynağı, sıklıkla eşleşecektir. Bu nedenle, resmi doğrulama her derde deva değil: önemsiz sayıda hatayı hala özlüyor.

Resmi doğrulamanın bir dezavantajı, uygulama maliyetinin iki katı gibi bir şey empoze edebilmesidir (muhtemelen daha fazla (resmi şartnamede bir uzmana ihtiyacınız var ve onunla birlikte gelen az ya da çok deneysel araçları kullanmanız gerekiyor; ucuz gelmeyecek) ).

Test senaryoları oluşturmak ve bunları otomatik olarak çalıştırmak için iskele yapmak zamanınızı daha iyi kullanır.

Artık güvenlik açısından kritik gömülü sistemler için tasarlanmış bir C ++ alt kümesi yazan programlar için biçimsel doğrulama mümkündür. Bkz http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.ppt kısa sunum için ve http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pdf tam kağıt için.

Birkaç farklı soru soruyorsun. Endüstriyel / ticari uygulamalar için resmi doğrulama yöntemlerinin çok yaygın olmadığı görülüyor. Ancak program doğruluğunu belirlemek için derleyicilere birçok "resmi doğrulama" ilkesi getirildiği anlaşılmalıdır! Yani bir şekilde, eğer modern bir derleyici kullanıyorsanız, en gelişmiş teknolojilerin çoğunu resmi doğrulamada kullanıyorsunuz.

"Test yapmaktan bıktım" diyorsunuz, ancak resmi doğrulama gerçekten testlerin yerine geçmiyor. Bir bakıma testte bir varyasyon .

Java'dan bahsediyorsun. Gerçekten de büyük kod tabanları üzerinden çalıştırılabilen FindBugs adında bir java doğrulama programında yerleşik birçok gelişmiş resmi doğrulama yöntemi vardır . Hem "yanlış pozitifler hem de yanlış negatifler" ortaya çıkacağını ve sonuçların bir insan geliştirici tarafından incelenmesinin / analiz edilmesinin gerekli olduğunu unutmayın. Ancak, gerçek işlevsel kusurları ortaya koymasa bile, genellikle kodda kaçınılması gereken "antipatterns" ortaya çıktığını unutmayın.

“Endüstriyel” dışındaki özel uygulamalarınızdan daha fazla bahsetmiyorsunuz. Uygulamada resmi doğrulama, özel uygulamaya bağlı olma eğilimindedir.

Örgün doğrulama teknikleri, EE'de, örneğin mikroişlemci tasarımında, devre doğruluğunu kanıtlamak için yaygın olarak kullanılmaktadır.

İşte Enerji Verimliliği alanındaki Lars Philipson tarafından yapılan resmi doğrulama araçlarına yapılan bir anket örneği .

Belki de model denetleyicisi yardımcı olabilir.

http://alloytools.org/documentation.html Alaşım bir model denetleyicisidir.

Alloy kullanarak model kontrolü kavramını açıklayan güzel bir sunum: https://www.youtube.com/watch?v=FvNRlE4E9QQ

Aynı araç ailesinde 'özellik tabanlı testler' gelir, hepsi yazılımınızın verilen spesifikasyon modeli için bir karşı örnek bulmaya çalışırlar.