Kritik Görev Yazılımı Nasıl Oluşturulur?

Ben kendi kendine öğrenim biçimsel yöntemlerim. Kritik görev yazılımı (nükleer reaktör kontrolörü, uçak uçuş kontrolörü, uzay sondası kontrolörü gibi) oluşturmak için resmi yöntemlerin kullanıldığını (ve genellikle sadece kullanıldığını) duydum. Bu yüzden öğrenmek istiyorum: p

Ancak, resmi yöntemleri öğrendikten sonra (özellikle LTL, CTL ve kardeşleri), bunların sadece spesifikasyonun doğruluğunu (güvenlik, canlılık, adalet, vb.) Doğrulamak için kullanılabileceğini hissediyorum.

Ama sonra yazılımın (sadece spesifikasyonun değil) gerçekten doğru olup olmadığı nasıl doğrulanır?

Feragatname: Teorik bilgisayar bilimi söz konusu olduğunda% 90 aptalım. Cevap verirken lütfen merhametli olun.

Soru oldukça geniştir. Bunu makul bir alanda cevaplamak için çok fazla basitleştirme yapacağım.

Terminoloji üzerinde anlaşalım. Bir program belirtimini ima ettiğinde doğrudur . Bu belirsiz ifade, bir programın tam olarak ne olduğunu ve bir spesifikasyonun tam olarak ne olduğunu tespit ederek birçok yönden kesinleşir. Örneğin, model kontrolünde program bir Kripke yapısıdır ve spesifikasyon genellikle bir LTL formülüdür. Veya program PowerPC talimatlarının bir listesi olabilir ve şartname , birinci dereceden mantıkla yazılmış bir dizi Hoare-Floyd iddiası olabilir. Çok fazla olası varyasyon var. Bir durumda (Kripke yapısı) gerçek bir programı doğrulamadığımızı, ikinci durumda da (PowerPC talimatları listesi) yaptığımızı sonuçlandırmak caziptir. Ancak, her iki durumda da matematiksel modellere gerçekten baktığımızı fark etmek önemlidir ve bu gayet iyi. (Durum, örneğin klasik mekaniğin gerçekliğin matematiksel bir modeli olduğu fiziğe oldukça benzer.)

Çoğu formalizasyon bir programın sözdizimi ve anlambilimi arasında ayrım yapar; yani, nasıl temsil edildiği ve ne anlama geldiği. Bir programın anlambilimi, program doğrulaması açısından önemli olan şeydir. Ancak, elbette programlara (sözdizimsel temsiller) anlamlar atamak için açık bir yol olması önemlidir. İki popüler yol şunlardır:

• (küçük adım) operasyonel semantik : Bu, bir programlama dili yazarak bir tercüman yazarak tanımlamaya benzer. Bunun için ne söylemek gerekir devlet ve dildeki her ifade etkilenir. (Tercümanı hangi dilde yazdığınızı merak edebilirsiniz, ama sanki değilmişim gibi davranacağım.)
• aksiyomatik semantik : Burada her ifade tipi bir aksiyom şeması ile birlikte gelir. Yani, kabaca, bu türden belirli bir ifade her kullanıldığında, belirli aksiyomları kullanabilme anlamına gelir. Örneğin, ataması şema ile birlikte gelir${\bf x}:={\bf e}$ ; belirli atama x : = x $\{P[{\bf x}/{\bf e}]\}\,{\bf x}:={\bf e}\,\{P\}${ x + 1 = 1 } aksiyomuyla birlikte gelir$x:=x+1$Şemayı P ile başlatırsak { x = 1 $\{x+1=1\}\,x:=x+1\,\{x=1\}$.$P=(x=1)$

(Başkaları da var. Anlamsal anlambilimi atladığım için özellikle kötü hissediyorum, ancak bu cevap zaten uzun.) Makine kodu artı operasyonel anlambilim çoğu insanın 'gerçek program' olarak adlandırdığı şeye oldukça yakın. DEC Alpha makine kodunun bir alt kümesi için operasyonel semantik kullanan bir seminal makale:

• Necula, Lee, İspat Kanun Kodu , 1996

Neden hiç aksiyomatik olanlar gibi daha üst düzey anlambilim kullanırsınız? Doğruluk kanıtınızın çalıştığınız donanıma bağlı olmasını istemediğinizde. Bu durumda yaklaşım, bir algoritmanın bazı uygun yüksek seviyeli semantiğe göre doğruluğunu kanıtlamak ve daha sonra semantiğin gerçek makinelere daha yakın olan daha düşük seviyeli semantiğe göre geldiğini kanıtlamaktır.

Özetle, sorunuza yol açan üç nedeni düşünebilirim:

1. Yalnızca bir programı çağırmak için kullandığınız şeye benzemeyen yüksek seviyeli semantikleri gördünüz ve düşük seviyeli olanlar olup olmadığını merak ediyorsunuz. Cevap Evet.
2. Bir modelin gerçeğe karşılık geldiğini nasıl kanıtladığınızı merak ediyorsunuz. Fizikte olduğu gibi, yapmazsınız. Sadece daha iyi modeller bulup bunları gerçekliğe karşı kontrol ediyorsunuz.
3. Sözdizimi ve anlambilim arasındaki farkı ve programlara anlam atamanın çeşitli yollarını görmediniz. İkiÖnceki soruda bazı kitaplar listelenmiştir.

Bu cevap sadece soruyu anladığım üç farklı yolu tanımlamaya çalışıyor. Herhangi bir derine inmekBu noktaların birinde çok fazla alan gerektirir.

Bir program ve belirtimi arasındaki boşluğu azaltmaya yönelik bir yaklaşım, resmi bir semantik ile bir dil kullanmaktır. Burada ilginç bir örnek Esterel olacaktır . Gerçek dünyaya resmi yöntemler getiren çalışmaları hakkında ilginç konuşmalar için Gérard Berry'nin web sayfasına bir göz atın. http://www-sop.inria.fr/members/Gerard.Berry/

ps Airbus bölgesinde bulundunuz mu? Resmi yöntemlerle uçtunuz!

"Gerçek dünyada" güvenilir yazılım oluşturma bilimi hala geliştirilmektedir ve bir dereceye kadar doğası gereği kültürel veya antropolojik bir çalışma için sınırlıdır, çünkü bilgisayarlar ve yazılım hatalara "neden olmaz" - insanlar yapar! bu cevap, resmi yazılım doğrulamasının tek bir unsur olarak görülebileceği genel Soru-Cevap yaklaşımlarına odaklanacaktır.

dikkat çekici bir gözlem, genellikle "yeterince iyi" ancak "buggy" olan yazılımların, piyasada daha iyi test edilmiş ancak daha düşük işlevsellik yazılımlarından daha iyi satılabileceğidir. başka bir deyişle, pazar her zaman kaliteyi her zaman vurgulamayan yazılım kalitesine ve modern yazılım mühendisliği tekniklerine her zaman bir prim koymaz. ayrıca kalite genellikle nihai ürüne önemli bir masraf katabilir. bu uyarılarla ilgili bazı temel bilgiler:

• artık / hataya dayanıklı sistemler. bu geniş bir çalışma alanıdır. hata toleransı ve artıklık bir sistemin birçok katmanında tasarlanabilir. örneğin bir yönlendirici, bir sunucu, bir disk sürücüsü, vb.

• test . tüm tipler - birim testi, entegrasyon testi, kullanıcı kabul testi, regresyon testi vb.

• günümüzde katılımsız çalıştırılabilen test paketleri aracılığıyla otomatik test yapılması daha gelişmiş / önemlidir. çalışan test süitleri genellikle derleme aracı ile birleştirilir.

• testte önemli bir kavram kod kapsamıdır . yani hangi kodun olduğu icra testi ile. bir test kodda test tarafından "dokunulmayan" bir hata bulamaz.

• Testteki diğer bir anahtar kavram , egzersiz koduna doğrudan erişilemeyen test koşumudur .

• testler yazılımın tüm seviyelerini kullanmalıdır. yazılım iyi modülerleştirilmişse, bu zor değildir. daha yüksek seviye testleri koda derinlemesine nüfuz etmelidir. küçük test kurulumuyla büyük miktarda kod kullanan testler "test kaldıraçını" artırır .

• kodun olabildiğince karmaşık hale getirilmesi test için önemlidir. mimari tasarımda test dikkate alınmalıdır. çoğu zaman aynı özelliği uygulamanın birden fazla yolu vardır, ancak bazılarının test kapsamı / kaldıraç üzerinde çok farklı etkileri vardır. koddaki her dal için, bu genellikle başka bir test durumudur. dallar içindeki dallar kod yollarında üstel artışa yükselir. bu nedenle yüksek oranda iç içe / koşullu mantıktan kaçınmak test etme yeteneğini geliştirir.

• okuyan ünlü (masif) yazılım hatalarına birçok örnek ve vaka çalışmaları var olan kalite kaygılarla güdülenmiş bir zihniyet tarihi anlamak ve geliştirmek için yararlıdır.

• bir test ile taşınabilir! hem çok az hem de çok fazla test ile ilgili bir sorun var . "tatlı bir nokta" var. yazılım her iki uçta da başarıyla oluşturulamaz.

• tüm temel araçları en etkili şekilde kullanır. hata ayıklayıcılar, kod profilleri, test kodu kapsamı araçları, hata izleme sistemi, vb! mutlaka düzeltmeyi taahhüt etmez, ancak izleme yazılımındaki en küçük kusurları bile izler .

• SCM, kaynak kodu yönetimi ve dallanma tekniklerinin dikkatli kullanımı, regresyonlardan kaçınmak, düzeltmeleri ve ilerleyen düzeltmeleri vb.

• N-Versiyonu Programlama : Kritik Görev Yazılımı geliştirmek için sıklıkla kullanılan bir uygulamadır. Bu uygulamanın temeli, bağımsız olarak geliştirilen N programların aynı ortak hata / hataya sahip olma ihtimalinin düşük olmasıdır. Bu, birkaç makalede eleştirilmiştir. Ancak NVP teorik bir kavram değildir.

Fizikçi Feynman'ın NASA'nın "Diğer insanların ne düşündüğünü umursuyorsun?" Kitabında uzay mekiği sistemlerinin güvenilirliğini garanti etmek için kullandığı yöntemi biraz açıkladığına inanıyorum. - A takımının ve B takımının yazılımı oluşturduklarını söyleyen iki takımları olduğunu söyledi. B takımı A Takımına düşmanca bir yaklaşım benimsedi ve yazılımı kırmaya çalıştı.

B Takımının iyi bir yazılım mühendisliği geçmişine sahip olması durumunda yardımcı olur, yani kod koşum takımı / programatik testler vb. bu durumda B Takımı, A Takımı ile neredeyse eşit düzeyde kaynağa sahipti, bu yaklaşım pahalıdır çünkü yazılımı oluşturma maliyetini neredeyse iki katına çıkarabilir. daha tipik olarak, geliştirme ekibine kıyasla daha küçük bir KG ekibi vardır.

Eski bir yaklaşım (ancak yine de bazı uygulamalarda kullanılmaktadır) N sürümü programlamadır

Wikipedia'dan:

N-sürüm programlama ( NVP olarak da bilinir), multi-versiyon programlama , çok sayıda fonksiyonel olarak eşdeğer programları, bağımsız bir şekilde, aynı başlangıç özellikleri elde yazılım mühendisliğinde yöntemi veya bir işlemdir. N-versiyonu programlama kavramı 1977 yılında Liming Chen ve Algirdas Avizienis tarafından “programlama çabalarının bağımsızlığının, programın iki veya daha fazla versiyonunda meydana gelen özdeş yazılım hatalarının olasılığını büyük ölçüde azaltacağı” ana düşüncesi ile ortaya atılmıştır. NVP'nin amacı, hataya dayanıklılık veya artıklık oluşturarak yazılım işletiminin güvenilirliğini artırmaktır.
....

Örneğin bakınız: " Bina Hatasındaki Zorluklar - Sivil Hava Aracı için Toleranslı Uçuş Kontrol Sistemi "

Fajrian, yaptığınız bu soru, yazılım mühendisi araştırmalarındaki en büyük sorunlardan ikisini kapsar: şartname ve model ve model ile kod arasındaki uyumluluk. Burada sistemin ne yapacağının veya nasıl yapılacağının bir temsilini modelleyin, bir sistemi modellemek için birçok seviye vardır.

Yani, sorunuza en iyi yanıtı bulmaya çalışan bazı insanlar var. Çünkü, örneğin resmi yöntemler kullanarak, bir modele dayalı bir yazılımın doğruluğunu kontrol etmek çok zordur. Biliyorum JML bunu yapmak için bir yoldur, ama ben onun kullanım sınırlarını bilmiyoruz.

Tamamlamak için, kodun doğruluğunu kontrol etmenin ne kadar zor olduğunu, insanlar resmi yöntemleri ve testi karıştırmaya çalışırlar, örneğin spesifikasyonlardan otomatik olarak test oluştururlar. Gerçek zamanlı sistemlere örnek olarak girdi / çıktı zamanlamalı olaylara dayanan TIOSTS verilebilir .

Test yapmak sadece resmi bir yöntem yaklaşımı değildir, bunu yapmak güvenilirliği arttırır ancak doğruluğunu kontrol etmez.

İki veya üç yıl önce yazılıma uygulanan resmi yöntemlere bakmaya başladım. Bu, meraktan ve daha uzun zaman aralıklarıyla programlama araçlarını ve yöntemlerini öğrenmek zorunda olduğum hissiyle yönlendirilen bir görevdi. Her ne kadar Gümüş Kurşun hakkında düşlemiş olsam da, gerçekten "Doğru programı nasıl yazabilirim?"

Bazı araçları (Z, B, VHDL ve Estelle) denedikten sonra görevin bu noktasında TLA + kullanıyorum . Bu, model kontrolü ve mekanik kanıtlar için yazılım araçları içeren bir zamansal mantık çeşididir. Bu yaklaşımı seçtiğimi düşünüyorum, çünkü L. Lamport arkasındaydı, sözdizimi basitti, birçok örnek vardı, ilgilenen bir topluluk vardı ve dil ve araçlar oldukça iyi belgelendi.

İlk sorumla ilgili olarak, tam bir cevap olmadığını düşünüyorum. Bununla birlikte, bir sistemin bazı kısımlarını resmi olarak belirtmenin işe yaradığını öğrenmeye değer. Bazı karmaşık olanları tersine mühendislik yapmak da oldukça yararlıdır. Yani, zor ve kritik parçalar için bir plan oluşturmak etkilidir. Ancak, spesifikasyonu bir programlama diline veya çerçevesine otomatik olarak çevirmek için etkili bir yöntem olduğunu düşünmüyorum (projeyi çok belirli bir ortamla kısıtlamadığınız sürece). Resmi bir spesifikasyona sahip olmanın yazılımı test etmenizi engellemesini de düşünmüyorum.

Özetle, aşağıdaki metaforun (Lamport'tan) gerçekten güçlü olduğunu düşünüyorum: "Bir evin otomatik olarak bir plandan inşa edilmesini mi bekliyorsunuz? Henüz inşa edilmemiş ve planı olmayan bir ev satın alacak mısınız?" .

Bu görev sırasında aşağıdaki kaynakları yararlı buldum:

• Yazılım Spesifikasyon Yöntemleri . Bu kitap, mevcut yöntemler ve araçlar hakkında geniş bir genel bakış sunmaktadır. Burada Z, SDL, TLA +, Petri Nets, Coq, vb.'nin temel açıklamalarını ve örneklerini bulabilirsiniz.
• TLA + 'nın ihtiyaçlarınızı karşıladığını düşünüyorsanız, Sistemleri Belirleme kitabını gerçekten tavsiye ederim . Kitabı ücretsiz olarak alabilirsiniz ve :) ile oynamak için örneklerle birlikte gelir.
• Son zamanlarda, resmi yöntemlerin tekniğinin durumuna iki farklı bakış açısı veren birkaç ilgili makaleyi okudum: Resmi Yöntemler Örneği ve Resmi Olarak Doğrulanmış Matematik .

İyi şanslar!

Şimdiye kadar verilen cevaplar, şartname ve kodun birbiriyle nasıl ilişkili olduğunun temelleri hakkında söylenmesi gerekenlerin çoğunu zaten kapsıyordu. Bu konunun başlığında soruna yaklaşan daha pratik bir nokta eklemek istiyorum:

Kritik görev yazılımı nasıl oluşturulur?

Kodunuzu hatalar için otomatik olarak analiz eden araçlar vardır (belirtimin ihlali veya "tipik hatalar"). Bildiğim kadarıyla, bu yöntemler çoğunlukla statik analiz üzerine kuruludur ve bahsettiğiniz teorilerle hemen ilişkili değildir (LTL / CTL / ...), ancak gerçek kodda hatalar bulurlar ve pratik bir noktadan zaten mümkündür. endüstriyel projelerde bu tür araçları kullanmak için. Şahsen pek çoğunu kullanmadım, ancak bu araçların uygulayıcılar tarafından kabul görmeye başladığı anlaşılıyor. Daha fazla okumak için aşağıdaki blog makalesini önerebilirim:

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

Kritik algoritmalar , kritik görev yazılımı oluştururken yararlı olabilir.

Sertifika algoritması, her bir çıktıda, belirli bir çıktının bir hatadan ödün vermediğini gösteren bir belge veya tanık (doğrulanması kolay kanıt) üreten bir algoritmadır.

Bu araştırma makalesinde daha fazlasını okuyun : McConnell, RM ve Mehlhorn, K. ve Naher, S. ve Schweitzer, P.

Ama sonra yazılımın (sadece spesifikasyonun değil) gerçekten doğru olup olmadığı nasıl doğrulanır?

Birim testi? Spesifikasyondaki her bir gereksinim için bir test yazın ve ardından çıktısının / girişinin söz konusu spesifikasyona uygun olduğunu görmek için uygulamanızdaki her bir yöntemi test edin. Bu otomatikleştirilebilir, böylece daha önce çalışan özelliklerde hiçbir değişiklik olmaması için bu testler sürekli olarak çalıştırılır.

Teorik olarak, eğer birim testleriniz% 100 kod kapsamına sahipse (yani kodunuzdaki her bir yöntem test edilirse), testlerin doğru ve gerçekçi olması koşuluyla yazılımınız doğru olmalıdır.