Resmi yöntemlerin işe yaradığını nasıl bilebiliriz?

Biçimsel yöntemlerin önemli bir amacı, sistemlerin doğruluğunu otomatik veya insana yönelik yöntemlerle kanıtlamaktır. Bununla birlikte, doğruluk kanıtı verebilseniz bile, sistemin başarısız olmayacağını garanti edemeyebilirsiniz. Örneğin:

• Spesifikasyon sistemi doğru bir şekilde modelleyemeyebilir veya bir üretim sistemi modele göre çok karmaşık olabilir veya sistem çelişkili gereksinimler nedeniyle doğası gereği kusurlu olabilir. Bir spesifikasyonun herhangi bir anlam ifade edip etmediğini test etmek için hangi teknikler bilinmektedir?
• İspat süreci de kusurlu olabilir! Bu çıkarım kurallarının doğru ve meşru olduğunu kim bilebilir? Ayrıca, kanıtlar çok büyük olabilir ve hata içermediklerini nasıl bilebiliriz? De Millo, Lipton ve Perlis'in "Teoremlerin ve Programların Sosyal Süreçleri ve Kanıtları" ndaki eleştirinin kalbi budur. Modern resmi yöntemler araştırmacılar bu eleştiriye nasıl yanıt veriyor?
• Çalışma zamanında, sistemi ciddi şekilde etkileyebilecek birçok belirsiz olay ve faktör vardır. Örneğin, kozmik ışınlar RAM'i öngörülemeyen şekillerde değiştirebilir ve daha genel olarak donanımın, Lamport'un sağlamlığının çok zor olduğu kanıtlanan Bizans hatalarına maruz kalmayacağına dair hiçbir garantimiz yoktur. Böylece statik sistemin doğruluğu sistemin arızalanmayacağını garanti etmez! Gerçek donanımın yanıltıcılığını açıkladığı bilinen herhangi bir teknik var mı?
• Şu anda test, yazılımın çalışmasını sağlamak için sahip olduğumuz en önemli araçtır. Resmi yöntemlerle tamamlayıcı bir araç olması gerektiği anlaşılıyor. Ancak çoğunlukla resmi yöntemlere veya testlere odaklanan araştırmalar görüyorum. İkisini birleştirmek hakkında ne biliniyor?

4 ile ilgili: Resmi yöntemleri ve testleri birleştiren çok iş var. Google'ın "resmi yöntemlerin test edilmesi", büyük miktarda çalışma olduğunu gösterir. Bu tür çalışmaların birçok farklı hedefi olmasına rağmen, kilit hedeflerden biri daha etkili test paketleri oluşturmaktır. Bu konuşma , model kontrolüne dayanan güzel bir tanıtım sunuyor.

Ayrıca , söz konusu sorun dışında düzenlenmiş olan yazılım güvenliği ile ilgili olarak: resmi yöntemlerin bu alanda daha fazla çalışması gerekir. Tipik olarak, bir yazılım parçası için bir şartname yazılır ve şartnamenin karşılandığını, yani girdi girdinin son koşulu karşıladığı ön koşulu karşıladığını doğrular. Güvenli yazılım sağlamak için, yazılımın önkoşulu karşılamayan giriş için de mantıklı davrandığını da kontrol etmek gerekir. (Bu elbette ön koşulun tüm girişler için true olarak ayarlanmasına eşdeğerdir.) Tüm girişlerin alanı tipik olarak sadece iyi biçimlendirilmiş girdiden çok daha büyüktür, ancak tipik olarak bu, işlevsel olarak doğru yazılımın bile basitçe ihlal edilebildiği bir yerdir. varsayımlarını ihlal etmek.

Nokta 3 ile ilgili olarak : Hata Mantığı: Hataya Dayanıklı Programlar Hakkında Akıl Yürütme de dahil olmak üzere hataların açıkça modellenmiş olduğu ortamlardaki sistemleri doğrulamak için bazı çalışmalar yapılmıştır . Matthew Meola ve David Walker. Avrupa Programlama Sempozyumu, 2010. Olasılıksal model kontrolü ve olasılıklı doğrulama üzerinde yapılan çalışmaların her ikisi de kesinlikle bir dereceye kadar arıza sorununu ele almaktadır.

Puanlarınız sırayla:

• Tüm spesifikasyonların doğruluğu nihayetinde özneldir: bir problemi kullanıcılarına göre doğru şekilde çözdüğü algılanır veya çözülmez. Bundan bir kurtuluş yazılım geliştirmedir ve hiçbir yöntemde bunun için gümüş mermi yoktur.
• Sürecin varsayımları açısından doğru olduğunu kanıtlamak için birçok çalışma yapılmaktadır. Genellikle uzmanların bu kuralları doğrulaması için bilgi mevcuttur. Herhangi bir insan faaliyeti hataya tabidir, ancak iyi çalışılmış yaklaşımları kullanan çok resmileştirilmiş sistemler , neredeyse diğer tüm insan süreçlerinden çok daha az hataya maruz kalır.
• Bir noktada, herhangi bir sistemin o sistemin kapsamı dışında bir arıza modu vardır. Tahmin edilemeyen bazılarını hesaba katmasanız bile , tahmin edilebilir tüm hata kaynaklarını ortadan kaldırmaya devam edersiniz.
• Test ve kanıtlama bir arada var olabilir. Test daha az spesifik, daha ad hoc bir süreçtir, bu yüzden üzerinde daha az resmi iş bulabilirsiniz. Ancak , Haskell tipi sistemin sunduğu kanıtları testlerle destekleyen QuickCheck gibi bir araçla ilgilenebilirsiniz .

Resmi yöntemlerin şimdiden büyük zaman gösterdiği gösterilmiştir. Onlar olmadan, modern dijital sistemler (mikroişlemciler) tasarlamanın karmaşıklığıyla başa çıkamazdık.

Hiçbir mantığı işlevsel denklik doğrulamasına tabi olmayan hiçbir mikro gemi; FPU'su FV'ye tabi olmadan; önbellek tutarlılık protokolleri FV'ye tabi olmadan (1995'ten beri böyle olmuştur).

Yazılım ve mühendislik fiziksel sistemleri (örneğin güvenlik faktörleri ekleyebileceği köprüler) arasındaki bariz farklılıkları ortadan kaldırarak, CS'de mühendislik matematiğinin rolünü oynarlar. Bununla birlikte, FM'nin kullanımı her zaman faydaya / maliyete bağlıdır. Fuzz testi, Microsoft gibi şirketlerde (Google SAGE bir slaytta) büyük zaman kazanır.

Bir mikro içinde bile, FV'nin başka bir yerde olduğu gibi (örneğin FPU, resmi sembolik yörünge değerlendirmesinin hataların olmadığını kanıtladığı birçok durumda geleneksel testin yapılmadığı alt sistemler (örn. Mikroişlemci boru hatları) vardır. : Kaivola ve diğerleri CAV'09).

Resmi yöntemler de yapay sentezlerde (kod, yüksek kalite testleri, pil bankalarını en iyi şekilde boşaltmak için programlar, ...) kullanılmaktadır. Tabii ki, soruda ortaya konan tüm sorunlar oldukça geçerlidir ve teknolojinin diğer tüm kullanımlarında olduğu gibi, sahte reklamların tanınması ve bunlardan kaçınılması gerekir.

2 ile ilgili olarak: sistem bir kanıt asistanında (örn., Twelf veya Agda veya Coq) resmileştirilmişse ve sağlamlık ve bütünlüğün özellikleri doğrulanmışsa ve kanıtlar bu kodlamada yapılmışsa, bu bir sorun değildir. Neyi amaçladığınızı açıklamayan bir sistemi resmileştirmiş olabilirsiniz , ancak en azından yanlış kanıtlara veya muhakeme yaptığınız bozuk bir sisteme sahip olmayacaksınız.

Bununla birlikte, doğruluk kanıtı verebilseniz bile, sistemin başarısız olmayacağını garanti edemeyebilirsiniz.

Evet, belki de hiçbir garanti yoktur . Biçimsel yöntemler, hataları bulmak ve ortadan kaldırmak ve insanları ikna etmek içindir.

Bir spesifikasyonun herhangi bir anlam ifade edip etmediğini test etmek için hangi teknikler bilinmektedir?

Formal sistemlerin teknik özellikleri için model kontrol araçları ile ilgilenebilirsiniz .

İspat süreci de kusurlu olabilir! Bu çıkarım kurallarının doğru ve meşru olduğunu kim bilebilir?

Bence (Goedel'in eksiklik teoremi nedeniyle) bir çıkarım kuralları sistemi göstermek sürekli olarak daha güçlü bir çıkarım kurallarına hitap ediyor.

Ayrıca, kanıtlar çok büyük olabilir ve hata içermediklerini nasıl bilebiliriz?

Umarım, büyük kanıtlar, insanlar tarafından makul bir sürede okunabilen ve anlaşılabilen küçük bir kanıt denetleyicisi tarafından kontrol edilir. Buna bazen "de Bruijn kriteri" de denir. Prova denetleyicisinin yanlış bir kanıt onaylamayacağına inanıyorsanız, yalnızca denetleyiciyi kontrol etmeniz gerekir.

Gerçek donanımın yanıltıcılığını açıkladığı bilinen herhangi bir teknik var mı?

Nasıl hakkında Hata toleranslı dili montaj yazdınız ?

Ancak çoğunlukla resmi yöntemlere veya testlere odaklanan araştırmalar görüyorum. İkisini birleştirmek hakkında ne biliniyor?

"TAP konferansı kanıtların ve testlerin yakınsamasına ayrılmıştır" .

Sadece "provalar ve testler" için googling'in ekranın üst kısmında birkaç iyi vuruş var.

Bir spesifikasyonun herhangi bir anlam ifade edip etmediğini test etmek için hangi teknikler bilinmektedir?

Kesinlikle bir yargılama çağrısıdır. Yazılım mühendisliğinde insanlar, özellikleri bulmak / yazmak / onaylamak için çok katı bir metodoloji tasarladılar. Bu gerçek insanlar tarafından yapılır ve resmi olmayan (matematiksel olmayan bir süreç) kullanılarak yapılır, bu yüzden hala tutarsızlığa tabidir, ancak günün sonunda, insanların daha az değil, doğrulamak istediklerine karşılık gelir.

Gerçek donanımın yanıltıcılığını açıkladığı bilinen herhangi bir teknik var mı?

Tabii, çalışma zamanı doğrulama olarak bilinen bir doğrulama alanı var, ayrıca belirli bir senaryoya tabi tamamen sanal bir ortamda çalışan gerçek sistemde yürütme tabanlı model kontrolünü kullanabilirsiniz ( V-DS + APMC ile buna kendim katkıda bulundum ). Ancak, bu, sistem ve çevre arasındaki etkileşimi doğrulama sürecine eklemek için büyük bir sorundur.

Ancak çoğunlukla resmi yöntemlere veya testlere odaklanan araştırmalar görüyorum. İkisini birleştirmek hakkında ne biliniyor?

Vay be, bugün tamamen utanmayacağım ve kendimi tekrar anlatacağım. Model kontrol ve testini birleştirmek için çalıştığımız ortak yazarlarla , grubumuzun eski bir doktora öğrencisinin yayın listesine bakabilir veya herhangi bir iyi arama motorunda "yaklaşık olasılıklı model kontrolü" veya "istatistiksel model kontrolü" için arama yapabilirsiniz. Younes ve diğerleri, Sen ve diğerleri ya da kendim ve diğerleri ve diğerleri).

PVS teoremi uzmanının tasarımcılarından biri olan ve tam olarak bahsettiğiniz noktalara genel olarak ilgi duyan John Rushby'nin çalışmalarıyla çok ilgilenebilirsiniz . Bu klasik okuma hoşunuza gidebilecek Biçimsel Yöntemleri kullanımı ve Kritik Sistem Sertifikasyonu (1993) hakkında FAA raporu ve onun yeni yazıları , çeşitli sağlanan kanıtların yardımıyla (test, deliller üzerinden bir olasılıksal, resmi emniyet durumda montaj hakkında analizler, vb.).