Apa saja hambatan yang mencegah meluasnya adopsi metode formal? [Tutup]

Ditutup . Pertanyaan ini didasarkan pada pendapat . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga dapat dijawab dengan fakta dan kutipan dengan mengedit posting ini .

Ditutup 2 tahun yang lalu .

Metode formal dapat digunakan untuk menentukan, membuktikan, dan menghasilkan kode untuk suatu aplikasi. Ini kurang rentan terhadap kesalahan - sehingga sebagian besar digunakan dalam program keselamatan / kritis.

Mengapa kita tidak menggunakannya lebih sering untuk pemrograman sehari-hari, atau dalam aplikasi web, dll ...?

Referensi :

development-process code-quality formal-methods

— toto
sumber

Kita bisa membangun rumah dengan dinding setinggi 5 kaki - seperti kastil abad pertengahan. Sebagian besar waktu, itu akan lebih merepotkan daripada nilainya.

— Baldrickk

Anda dapat mencoba menerapkan metode formal ke proyek pengembang web, dan lihat bagaimana hasilnya. Kemungkinan besar Anda akan melihat bahwa Anda menuangkan banyak usaha ke dalam aktivitas bernilai rendah. Bandingkan dengan pengujian asap cepat, yang sudah akan menangkap banyak bug. Menariknya, sistem tipe statis adalah jenis sistem pembuktian yang sederhana, namun terutama pengembangan web menghindari bahasa-bahasa tersebut (alih-alih lebih memilih bahasa yang sangat dinamis seperti Ruby, PHP, atau JavaScript). Korelasi tidak menyiratkan sebab-akibat, tetapi memberikan jeda untuk berpikir.

— amon

Jadi, Anda lebih suka menentukan dalam bahasa spesifikasi daripada pemrograman dalam bahasa pemrograman? Ok, Anda akan dapat membuktikan bahwa itu bekerja sesuai dengan spesifikasi. Tetapi bagaimana Anda akan membuktikan bahwa spesifikasi mencerminkan masalah sebenarnya?

— Christophe

@toto pertanyaannya adalah: melakukan hal yang benar (bekerja sesuai dengan spesifikasi) atau melakukan hal yang benar (memiliki spesifikasi yang baik). Sementara secara teori specnya adalah yang kita inginkan, dalam praktiknya kita jarang tahu pasti apa yang benar-benar dibutuhkan: beyssonmanagement.com/2012/10/29/…

— Christophe

Bagi mereka yang kecewa bahwa ini ditutup sekarang ada posting blog yang bagus: Mengapa Orang Tidak Menggunakan Metode Formal?

— icc97

Jawaban:

Insinyur adalah orang yang dapat melakukan dengan dolar apa yang dapat dilakukan orang bodoh dengan 10.

Kendala sumber daya, kendala anggaran, kendala waktu, semuanya penting.

Mengembangkan perangkat lunak menggunakan metode formal biasanya jauh lebih mahal dan memakan waktu lebih lama daripada tanpa. Juga, untuk banyak proyek, bagian tersulit adalah memahami persyaratan bisnis. Semua yang menggunakan metode formal membeli Anda dalam kasus itu adalah bukti bahwa kode Anda sesuai 100% dengan pemahaman Anda yang tidak lengkap dan salah tentang persyaratan bisnis.

Untuk alasan itu, penggunaan metode formal, bukti, verifikasi program, dan teknik serupa biasanya terbatas pada "hal-hal yang penting", yaitu perangkat lunak avionik, sistem kontrol untuk peralatan medis, pembangkit listrik, dll.

— Jörg W Mittag
sumber

Saya juga menambahkan bahwa memasukkan metode formal ke dalam bahasa pemrograman adalah bidang penelitian aktif saat ini yaitu belum siap untuk mainstream

— jk.

Saya menerima jawaban ini, tetapi saya juga ingin pendekatan tentang mengapa metode formal masih dianggap 'mahal' dan 'memakan waktu', terutama ketika kita tahu betapa mahal pemeliharaan dan pelacakan kode / debugging pada proyek-proyek besar.

— toto

TDD & BDD adalah pendekatan yang dibangun di atas prinsip-prinsip logika Hoare, dasar dari pendekatan formal. Mereka meningkatkan efisiensi bukan mengurangi darinya.

— Martin Spamer

@toto Bukti benar-benar, SANGAT sulit. Banyak hal yang diterima ahli matematika dalam bukti tidak berlaku dalam program. Misalnya, di C ++, selain tidak asosiatif: (-1 + 1) + INT_MAX = INT_MAX, -1 + (1 + INT_MAX)adalah perilaku undefined.

— Hovercouch

@toto: Alasan mereka dianggap "mahal" dan "menyita waktu" adalah karena kita dapat melihat proyek-proyek yang dikembangkan menggunakan metode formal dan secara empiris memverifikasi bahwa proyek-proyek itu membutuhkan waktu lebih lama untuk dikembangkan. Lihatlah saat pengembangan seL4 / L4.verified, misalnya, dibandingkan dengan setiap pelaksanaan lainnya dari L4.

— Jörg W Mittag

Memprogram atau tidak memprogram?

Untuk memecahkan masalah dengan produk perangkat lunak, setelah memiliki pemahaman tentang persyaratan, Anda dapat BAIK menulis program menggunakan bahasa pemrograman ATAU menentukan program menggunakan bahasa formal dan menggunakan alat penghasil kode. Yang terakhir hanya menambah tingkat abstraksi.

Melakukan hal yang benar atau melakukan hal yang benar?

Pendekatan formal memberi Anda bukti bahwa perangkat lunak Anda bekerja sesuai dengan spesifikasi. Jadi produk Anda melakukan hal yang benar. Tetapi apakah itu melakukan hal yang benar?

Persyaratan tempat Anda bekerja mungkin tidak lengkap atau ambigu. Mereka bahkan bisa menjadi buggy. Dalam kasus terburuk, kebutuhan nyata bahkan tidak diungkapkan. Tetapi gambar bernilai ribuan kata, hanya gambar google untuk "Apa yang diinginkan pelanggan", misalnya dari artikel ini :

Biaya formalitas

Di dunia yang sempurna, Anda akan memiliki persyaratan yang sepenuhnya terperinci dan sempurna sejak awal. Anda kemudian dapat sepenuhnya menentukan perangkat lunak Anda. Jika Anda ingin formal, kode Anda akan dihasilkan secara otomatis sehingga Anda akan lebih produktif. Keuntungan produktivitas akan mengimbangi biaya alat formal. Dan semua orang sekarang akan menggunakan metode formal. Jadi mengapa tidak?

Dalam praktiknya, ini jarang kenyataan! Inilah sebabnya mengapa begitu banyak proyek air terjun gagal, dan mengapa metode pengembangan berulang (tangkas, RAD, dll) memimpin: mereka dapat menangani persyaratan, desain dan implementasi yang tidak lengkap dan tidak sempurna dan menyempurnakannya sampai mereka baik-baik saja.

Dan inilah intinya. Dengan metode formal, setiap iterasi harus memiliki spesifikasi formal yang sepenuhnya konsisten. Ini membutuhkan pemikiran yang cermat dan pekerjaan tambahan, karena logika formal tidak memaafkan dan tidak menyukai pikiran yang tidak lengkap. Eksperimen pembuangan sederhana menjadi mahal di bawah batasan ini. Dan begitu juga setiap iterasi yang akan mengarah ke pengulangan (misalnya ide yang tidak berhasil, atau persyaratan yang disalahpahami).

Dalam praktek

Ketika tidak diwajibkan untuk menggunakan metode formal untuk alasan hukum atau kontrak, Anda juga dapat mencapai kualitas yang sangat tinggi tanpa sistem formal, misalnya dengan menggunakan pemrograman berbasis kontrak dan praktik-praktik baik lainnya (mis. Tinjauan kode, TDD , dll ...). Anda tidak akan dapat membuktikan bahwa perangkat lunak Anda berfungsi, tetapi pengguna Anda akan menikmati kerja perangkat lunak lebih cepat.

Pembaruan: upaya yang terukur

Dalam edisi Oktober 2018 tentang Komunikasi ACM ada artikel menarik tentang perangkat lunak yang diverifikasi secara formal di dunia nyata dengan beberapa perkiraan upaya.

Menariknya (berdasarkan pengembangan OS untuk peralatan militer), tampaknya memproduksi perangkat lunak yang terbukti secara formal membutuhkan upaya 3,3 kali lebih banyak daripada dengan teknik teknik tradisional. Jadi itu sangat mahal.

Di sisi lain, ini membutuhkan upaya 2,3 kali lebih sedikit untuk mendapatkan perangkat lunak keamanan tinggi dengan cara ini dibandingkan dengan perangkat lunak yang direkayasa secara tradisional jika Anda menambahkan upaya untuk membuat perangkat lunak tersebut disertifikasi pada tingkat keamanan yang tinggi (EAL 7). Jadi jika Anda memiliki keandalan atau persyaratan keamanan yang tinggi pasti ada kasus bisnis untuk menjadi formal.

desain seL4 dan pengembangan kode memakan waktu dua orang-tahun. Menambahkan semua bukti serospecific selama bertahun-tahun mencapai total 18 orang-tahun untuk 8.700 baris kode C. Sebagai perbandingan, L4Ka :: Pistachio, microkernel lain dalam keluarga L4, sebanding dengan seL4, membutuhkan waktu enam orang-tahun untuk dikembangkan dan tidak memberikan tingkat jaminan yang signifikan. Ini berarti hanya ada faktor 3.3 antara perangkat lunak yang diverifikasi dan perangkat lunak yang direkayasa secara tradisional. Menurut metode estimasi oleh Colbert dan Boehm, 8 sertifikasi Common Common EAL7 tradisional untuk 8.700 baris kode C akan memakan waktu lebih dari 45,9 orang-tahun. Itu berarti verifikasi implementasi tingkat biner formal sudah lebih dari faktor 2.3 lebih murah daripada tingkat sertifikasi tertinggi Kriteria Umum namun memberikan jaminan yang jauh lebih kuat.

— Christophe
sumber

Pemrograman berbasis kontrak memang menggunakan setidaknya bukti informal.

— Frank Hileman

@ FrankHileman ya! Dan fakta sederhana untuk mengklarifikasi prasyarat, postkondisi dan invarian sangat membantu untuk meninjau kode secara efisien, mengurangi kesalahan, dan mensistematisasi pengujian.

— Christophe

Ini harus menjadi jawaban terbaik sejauh ini.

— Hashim

Setiap program dalam bahasa apa pun dapat dianggap sebagai spesifikasi formal (setara dengan beberapa mesin pemutar). 'Spesifikasi formal' tingkat tinggi mana pun untuk digunakan dalam membuktikan kebenaran formal juga - hanyalah program lain. Tetapi (biasanya) program yang buruk, tidak lengkap, tidak jelas, tidak cukup dipikirkan. Dan tidak secara kebetulan, biasanya ditulis oleh orang-orang yang tidak tahu cara memprogram (mereka biasanya ahli domain).

Dan dengan demikian membuktikan bahwa satu program kompatibel (menghasilkan jawaban yang sama atau bagaimana pun Anda mengkarakteristikkannya) dengan persyaratan formal tingkat tinggi, yang tidak berubah adalah bagaimana Anda menyelesaikan ambiguitas dalam spesifikasi formal tingkat tinggi. Tidak ada cara tujuan umum yang baik untuk melakukan itu.

Pemetaan persyaratan tingkat tinggi ke detail tingkat lebih rendah adalah inti dari apa sebenarnya pemrograman itu. Seharusnya tidak mengherankan bahwa pekerjaan inti yang dilakukan oleh seorang programmer membaca dan menafsirkan spesifikasi tidak dapat diganti dengan melambaikan tangan dan mengatakan 'sekarang lihat saja apakah spesifikasi formal tingkat tinggi ini dipenuhi oleh program sampel ini'.

Bahkan pada hari-hari awal pemrograman logika, di mana konsep ini pertama kali tampak begitu menjanjikan (karena baik spesifikasi tingkat tinggi dan program yang mendasari sebenarnya dapat ditulis dalam bahasa yang sama), masalah inti ini terbukti tidak bisa diselesaikan.

— Lewis Pringle
sumber