Yazılım için resmi yöntemleri öğrendiyseniz, yazılımı ne kadar yararlı buldunuz?

Programlama için resmi yöntemlerin (FM) kullanımı konusunda eğitim almışsanız:

• Ne kadar yararlı buldun?
• FM eğitiminiz neleri içeriyordu (örneğin bir kurs, bir kitap)?
• Hangi FM araçlarını kullanıyorsunuz?
• FM kullanmamanıza kıyasla hız / kalite açısından ne gibi avantajlar sağladı?
• FM ile ne tür bir yazılım oluşturuyorsunuz?
• Ve şimdi FM'yi doğrudan kullanmıyorsanız, en azından öğrenmeye değer miydi?

FM hakkında bu toplulukta bulunabilecek kadar çok deneyim / görüş duymayı merak ediyorum; Üzerine okumaya başladım ve daha fazlasını bilmek istiyorum.

Arka fon

Programlama ve yazılım geliştirme / mühendislik, dünyadaki en yeni insan becerileri / mesleklerinden bazılarıdır, bu yüzden şaşırtıcı olmayan bir şekilde, alan olgunlaşmaz - bu, alanımızın ana çıktısında, genellikle geç ve hataya eğilimli kod olarak gösterilir. Endüstride olgunlaşmamışlık, ortalama ve üst düzey kodlayıcılar arasındaki verimlilikte geniş bir marjla (en az 10: 1) gösterilir. Bu tür kasvetli gerçekler literatürde iyi ele alınmış ve Steve McConnell's Code Complete gibi kitaplar tarafından tanıtılmıştır .

Kullanımı biçimsel yöntemlere (FM) yazılım / CS (örneğin geç büyük rakamlarla önerilmiştir E. Dijkstra programlamada matematiksel dinçlik eksikliği: adrese) (biri) hataların kök nedenleri. Örneğin Dijkstra, birlikte bir program ve onun kanıtını geliştiren öğrencileri savundu .

FM, Avrupa'daki CS müfredatında ABD'ye kıyasla çok daha yaygın görünüyor. Ancak son birkaç yıldır, alaşım gibi yeni "hafif" FM yaklaşımları ve araçları biraz dikkat çekti. Yine de FM, endüstride yaygın kullanımdan uzaktır ve burada neden hakkında bazı geri bildirimler bekliyorum.

Güncelleme

Şu andan itibaren (10/14/2010), aşağıdaki 6 cevaptan hiç kimse FM'nin "gerçek dünya" işinde kullanılmasını açıkça tartışmamıştır. Birisinin yapıp yapamayacağını gerçekten merak ediyorum; ya da belki FM gerçekten akademi (FM gelecektir!) ve endüstri (FM çoğunlukla işe yaramaz) arasındaki mesafeyi göstermektedir.

Önemsiz bir şey için kesinlikle işe yaramaz.

Alaşıma odaklanan "Resmi Metotlar" adında bir kursum vardı. LTSA ile eşzamanlılık modellemeye odaklanan başka bir sınıf daha vardı - aynı derecede işe yaramaz.

Sorun, yazılımdaki çoğu hata ve problemin (en azından benim deneyimime göre), bu araçların soyutlama seviyesinin altında ortaya çıkan karmaşıklıktan kaynaklanmasıdır.

CSP'de (Sıralı İşlemleri İletişim Etme) bir arka planım var. Kendi kornamı tootlamak için değil, ama zamanlanmış CSP üzerine yüksek lisans tezimi yazdım, özellikle resmi yöntemlerle yazılmış spesifikasyonları yürütülebilir C ++ 'a derledim. Biçimsel yöntemler konusunda deneyimim olduğunu söyleyebilirim. Derecemi bitirdikten ve sektörde bir iş bulduğumda, resmi yöntemler hiç kullanmadım. Biçimsel yöntemler hala endüstride uygulanamayacak kadar teoriktir. Formal yöntemler gömülü sistemler alanında bazı pratik uygulamalar bulmuştur. Örneğin, NASA projelerinde resmi yöntemler kullanır. Resmi yöntemlerin endüstride yaygın olarak benimsenmekten çok uzak olduğunu tahmin ediyorum. Yazılım teknik özelliklerini resmi yöntemlerle yazmak ve daha sonra bunları seçtiğiniz çerçeveye "insan yorumlamak" mantıklı değildir. Düz İngilizce ve diyagramlar bunun için daha iyi çalışır, ünite ve entegrasyon testleri ise kodun doğruluğunu "doğrulamak" için oldukça iyi bir iş çıkarmaktadır. benceresmi yöntemler bir süre akademi dünyasında kalacaktır .

Durum diyagramları ve Petri ağları protokolleri ve gerçek zamanlı sistemleri modellemek ve analiz etmek için kullanışlıdır. İlk olarak bir çözüm tasarlamaya yardımcı olurlar. İkinci olarak, çok özel durumlarda heyecan verici yazılımlar için test senaryoları bulmaya yardımcı olurlar.

Resmi yöntemler hakkında birkaç kitap okudum ve bazılarını uyguladım. Derhal tepkim, "Vay be, bu kitaplar bana mükemmel bir matematikçi olduğum sürece nasıl iyi bir programcı olabileceğimi söylüyor." Başka bir zayıflık, sadece başka bir resmi tanımla denkliği kanıtlayabilmenizdir. Bir program için resmi bir şartname yazmak, bir programı daha üst düzey bir dilde yazmakla aynıdır ve makul ölçüde büyük bir spesifikasyonda hataları tanıtmaktan kaçınmanın bir yolu yoktur.

Resmi yöntemleri daha önce hiç büyük ölçekte çalıştırmadım. Küçük ve zor bir şeyi düzeltmede ve beni doğru olduklarına ikna etmede yararlı olabilirler. Bu şekilde, biraz daha büyük yapı taşlarıyla çalışabilir ve bazen biraz daha fazlasını yapabilirim.

Daha genel olarak faydalı olduğunu düşündüğüm bir şey, bir değişmez kavramı, bir program ve durumu hakkında her zaman doğru olan bir ifadedir. Sebep edebileceğiniz her şey iyidir.

Yukarıda belirtildiği gibi, ben mükemmel bir matematikçi değilim ve bu yüzden kanıtlarım bazen hatalar içeriyor. Ancak, tecrübelerime göre, bunlar yakalanması ve düzeltilmesi kolay büyük aptal hatalar olma eğilimindedir.

Operasyonel anlambilim üzerine odaklandığımız resmi program analizinde yüksek lisans dersi aldım. SeL4 çalışmasıyla ilgili son makalemi kullandıkları resmi yöntemleri gözden geçirdim. Pratiklik açısından temel alıp götürmem, marjinal değere sahip olmasıydı. Sadece programı yazmakla kalmaz, kanıtı da yazmanız gerekir. Vay. İki hata kaynağı. Sadece bir tane deđil. Ayrıca, gerçek koda büyük miktarda kısıtlama getirildi. G / Ç dahil fiziksel bir bilgisayarı resmen tanımlamak çok zordur .

Kendi kendime geçen yıl TLA + öğretti, o zamandan beri kullanıyorum. Bir projeye başladığımda ulaştığım ilk araçlardan biri. Çoğu insanın yaptığı hata, resmi yöntemlerin ya hep ya hiç bir şey olduğunu varsaymalarıdır: ya resmi yöntemleri kullanmıyorsunuz ya da tam doğrulamanız var. Bununla birlikte, aralarında bir şey vardır: projenizin soyut bir spesifikasyonunun değişmezlerinizi bozmadığını kontrol ettiğiniz resmi şartname . Doğrulamanın aksine, şartname endüstride kullanılacak kadar pratiktir.

Belirtim dilleri programlama dillerinden daha anlamlıdır. Örneğin, dağıtılmış bir veri deposu için (çok) basit bir PlusCal özelliği:

process node \in 1..5 \* Nodes
variables online = TRUE,
          stored \in SUBSET data; \* Some set
begin 
  Transfer:
    either
      with node \in Nodes, datum \in stored do
        node.stored := node.stored \union {datum};
      end
    or \* crash
      online := FALSE;
    end either;
end process;

Bu snippet, eşzamanlı olarak çalışan ve aktarımları keyfi bir sırada çalıştıran beş düğüm belirtir; burada her aktarım, rastgele bir düğüme rastgele bir veri parçasıdır. Ayrıca, herhangi bir aktarımın başarısız olabileceğini ve düğümün çökmesine neden olabileceğini belirledik. Ve tüm bu davranışları TLA + model denetleyicisinde simüle edebiliriz! Bu şekilde, sipariş, arıza oranları vb. Bundan bahsetmişken, birkaç gereksinim ekleyelim. İlk olarak, verileri asla çevrimdışı bir düğüme aktarmadığımızdan:

[][\A node \in Nodes: ~online => UNCHANGED node.stored]_vars

Basitleştirilmiş sürümümüzde model denetleyicisi bir hata durumu bulacaktır. "Belirli bir veri parçası en az bir çevrimiçi düğümde" de belirtebiliriz:

\A d \in data: \E n \in Nodes: n.online /\ d \in n.stored

Bu da başarısız olur. Bir birim testi ile bunları kontrol etmek iyi şanslar!

Şartnamenin ana sınırlaması, gerçek kodunuzdan bağımsız olarak mevcut olmasıdır. Size sadece tasarımınızın doğru olduğunu söyleyebilir, doğru uyguladığınızı değil. Ancak doğrulamaktan daha hızlı belirtmek ve test için çok ince olan hataları yakalar, bu yüzden çabaya değer buluyorum. Eşzamanlılık veya birden fazla sistem içeren hemen hemen tüm kodlar resmi bir özellik için iyi bir yerdir.

Eskiden Fujitsu tarafından satın alınmadan önce ICL'deki bir departmanda çalışıyordum. Yazılımın ilan edildiği gibi çalıştığına dair kanıt gerektiren bazı büyük hükümet tipi sözleşmeleri vardı , bu yüzden Z'de yazılmış resmi spesifikasyonu alacak ve kodu yürürken doğrulayacak büyük bir yeşil veya kırmızı ışıkla doğrulayacak bir makine inşa ettiler. başarısız.

İnanılmaz bir şeydi, ama saygın @FishToaster'ın belirttiği gibi, önemsiz olmayan bir şey için işe yaramazdı.

1. " Ne kadar yararlı buldun? "

Petri Nets'in bilgisayar programlamasına uygulanması çok faydalıdır. Petri Nets tabanlı bir yöntem olan “Net Elements and Annotations” ı oluşturdum (Chionglo, 2014). 2014'ten beri PDF form uygulamaları için Acrobat / JavaScript API'sini kullanan JavaScript programları yazmak için yöntemi uyguluyorum.

2. “ FM eğitiminiz neleri içeriyordu (örneğin bir kurs, bir kitap)? ”

Kendi kendine çalışma yoluyla Petri Nets hakkında “eğitim aldım”. Petri Nets ile ilgili bölümleri “Petri Nets ve Grafcet: Kesikli Olay Sistemlerinin Modellenmesi için Araçlar” ders kitabından okudum (David ve Alla, 1992). Ayrıca Petri Nets ile ilgili araştırma yazıları okuyorum. “Net Unsurlar ve Ek Açıklamalar” oluşturduktan ve belgeledikten sonra yöntemi birkaç hafta boyunca uygulamaya çalıştım.

3. “ Hangi FM araçlarını kullanıyorsunuz? ”

PowerPoint kullanarak Petri Net diyagramları çiziyorum. Word kullanarak ek açıklamaların form görünümünü oluştururum. Acrobat ve Notepad kullanarak token oyunlarını PDF form uygulamaları olarak da oluşturuyorum. Girdiler forma eklendikten sonra bu girdilerin JavaScript koduna çevrilmesi sistematiktir. Böylece çeviriyi otomatikleştirmek mümkün olmalıdır. “Girişler” PowerPoint'teki grafik nesnelerine eklenmişse, bunları sistematik olarak JavaScript koduna çevirmek ve bu çeviriyi otomatikleştirmek de mümkün olmalıdır. Ayrıca, bu çevirileri yapan ve PDF form uygulamaları oluşturmak için ek kaynaklar oluşturmak için bir dizi devam eden çalışma aracı kullanıyorum (Chionglo, 2018; 2017).

4. “ FM kullanmamanıza kıyasla hız / kalite açısından ne gibi avantajlar sağladı? ”

“Net Elements and Annotations” ı kullanarak JavaScript programlarını “Net Elements and Annotations” ı kullanmadan bir JavaScript programı yazabileceğimden daha hızlı yazabilirim. Büyük programlar için kodlamayı durdurabilir ve nereye devam edeceğini merak etmeden daha sonra (veya daha sonra) kodlamaya geri dönebilirim (Chionglo, 2019). Bazı durumlarda “Net Öğeler ve Ek Açıklamalar” kullanarak JavaScript programları yazabilirim, ancak “Net Öğeler ve Ek Açıklamalar” kullanmadan JavaScript programlarını yazamıyorum. Örneğin, “Net Öğeler ve Ek Açıklamalar” kullanılmadan özyinelemeli işlevlerin özyinelemeli olmayan uygulamalarını yaratamazdım (Chionglo, 2019b; 2018b; 2016). Bunlar, devam eden çalışma araçlarıyla veya bunlar olmadan geçerlidir.

5. " FM ile ne tür bir yazılım oluşturuyorsunuz? "

PDF form uygulamaları için Acrobat / JavaScript API'sini kullanan JavaScript programları oluşturmak için “Net Öğeler ve Ek Açıklamalar” kullanıyorum. HTML belgeleri için JavaScript programları oluşturma ve Arduino Eskizleri oluşturma yöntemini de uygulayabilirim (Chionglo, 2019c; 2019d).

6. “ Ve şimdi FM'yi doğrudan kullanmıyorsanız, en azından öğrenmeye değer miydi? ” Uygulanamaz.

Referanslar

Chionglo, JF (2019b). Özyinelemeli Bir İlişkinin N'inci Terimini Hesaplama: Özyinelemesiz Bir İşlev Kullanma - Matematik Yığın Değişimi'nde Bir Soruya Yanıt. < https://www.academia.edu/38496025/Computing_the_N-th_Term_of_a_Recursive_Relation_Using_a_Non-Recursive_Function_A_Reply_to_a_Question_at_Mathematics_Stack_Exchange >.

Chionglo, JF (2019c). Alev Etkisi Kontrol Mantığı, Simülasyon ve Eskiz: Arduino Topluluk Forumu'ndaki Bir İsteği Yanıtlama. https://www.academia.edu/40342956/Flame_Effect_Control_Logic_Simulation_and_Sketch_A_Reply_to_a_Request_at_the_Arduino_Community_Forum .

Chionglo, JF (2019). Uzun Bir Aradan Sonra Bir Uygulamayı Kodlamaya Nasıl Devam Edebilirim? “2 haftalık bir aradan sonra kodlarınızda nerede durduğunuzu nereden biliyorsunuz?” - Software Engineering Stack Exchange. https://www.academia.edu/39705042/How_I_Continue_Coding_an_Application_after_a_Long_Break_Reply_to_How_do_you_know_where_you_stopped_in_your_codes_after_a_2-week_break_Software_Engineering_Stack_Exchange .

Chionglo, JF (2019d). Göster ve Gizle Kontrol Mantığı: Stack Overflow'da bir Sorudan esinlenmiştir. < https://www.academia.edu/40283015/Show-and-Hide_Control_Logic_Inspired_by_a_Question_at_Stack_Overflow >.

Chionglo, JF (2018b). Bir Sayının Faktöriyeli için Petri Net Modeli: Ve Hesaplamak için Özyinelemesiz JavaScript İşlevi. <>.

Chionglo, JF (2018). Hyper Form ™ Oluşturma - Devam Eden Bir İş Akışı: Net Programlama Araştırmasında Güncelleme. https://www.academia.edu/37697498/Create_Hyper_Form_-A_Workflow_in_Progress_Update_on_the_Net_Programming_Research .

Chionglo, JF (2017). Net Programlama: Bir Araştırma Önerisi: PowerPoint ve Acrobat ile PDF Form Uygulamaları Geliştirmek İçin. https://www.academia.edu/33374809/Net_Programming_A_Research_Proposal_For_Developing_PDF_Form_Applications_with_PowerPoint_and_Acrobat. .

Chionglo, JF (2016). Fibonacci Sayısını Hesaplamak İçin Bir Petri Net Modeli. https://www.academia.edu/31748108/A_Petri_Net_Model_for_Computing_the_Fibonacci_Number.

Chionglo, JF (2014). Bilgisayar Programlama için Net Unsurlar ve Ek Açıklamalar: PDF'de Hesaplamalar ve Etkileşimler. https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

David, R. ve H. Alla. (1992). Petri Nets ve Grafcet: Kesikli Olay Sistemlerinin Modellenmesi için Araçlar. Üst Eyer, NJ: Prentice Salonu.