Kekokohan (ilmu komputer): Perbedaan antara revisi
Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 28366136; atribusi sumber disertakan. |
Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi |
||
| Baris 1: | Baris 1: | ||
Dalam ilmu komputer, kekokohan adalah kemampuan dari sistem komputer untuk menangani eror dalam eksekusi dan masukan yang bermasalah. Kekokohan dapat meliputi berbagai area dalam ilmu komputer, seperti pemrograman kokoh, [[pemelajaran mesin]] kokoh, dan keamanan jaringan kokoh. Teknik formal seperti ''fuzz testing'', sangat penting untuk menunjukkan kekokohan karena pengujian tipe ini melibatkan masukan tidak sah dan tidak tertuga. Selain itu, injeksi kesalahan juga dapat digunakan. Berbagai produk komersial melakukan pengujian analisis kekokohan [[perangkat lunak]]. | Dalam ilmu komputer, kekokohan adalah kemampuan dari sistem komputer untuk menangani eror dalam eksekusi<ref>[http://dl.ifip.org/db/conf/pts/testcom2005/FernandezMP05.pdf A Model-Based Approach for Robustness Testing]. ''Dl.ifip.org''.</ref> dan masukan yang bermasalah.<ref>[https://id.wikipedia.org/w/index.php?title=Kekokohan+%28ilmu+komputer%29&oldid=28366136 sumber pada Wikipedia bahasa Indonesia]</ref> Kekokohan dapat meliputi berbagai area dalam ilmu komputer, seperti pemrograman kokoh, [[pemelajaran mesin]] kokoh, dan keamanan jaringan kokoh. Teknik formal seperti ''fuzz testing'', sangat penting untuk menunjukkan kekokohan karena pengujian tipe ini melibatkan masukan tidak sah dan tidak tertuga. Selain itu, injeksi kesalahan juga dapat digunakan. Berbagai produk komersial melakukan pengujian analisis kekokohan [[perangkat lunak]].<ref>Jack W. Baker. [http://www.stanford.edu/~bakerjw/Publications/Baker%20et%20al%20(2008)%20Robustness,%20Structural%20Safety.pdf On the assessment of robustness]. ''Structural Safety''. 2008. Vol. 30 (3). hlm. 253–267. doi:10.1016/j.strusafe.2006.11.004.</ref> | ||
== Pengenalan == | == Pengenalan == | ||
Secara umum, sulit untuk membangun sistem yang kokoh dan meliputi seluruh titik kelemahan karena jumlah kombinasi masukan dan luaran amat banyak. Pengujian terhadap semua kombinasi masukan dan luaran memakan terlalu banyak waktu dan para pengembang tidak mungkin melaksanakannya satu-persatu. Karena itu, mereka mengelompokan kasus-kasus yang serupa. Sebagai contoh, bayangkan anda memasukkan beberapa nilai [[Integer (ilmu komputer)|integer]]. Beberapa masukan tersebut mungkin berupa bilangan negatif, nol, atau bilangan positif. Untuk menguji perangkat lunak, pengembang menggunakan hanya tiga bilangan tersebut untuk menguji seluruh set [[bilangan riil]]. Cara ini lebih efisien, tapi lebih riskan pula. Pengelompokan kasus uji adalah satu dari banyak cara untuk menangani kegagalan, khususnya kegagalan karena masukan tidak sah. Secara umum, sistem juga dapat gagal karena alasan-alasan lain, seperti terputus dari jaringan. | Secara umum, sulit untuk membangun sistem yang kokoh dan meliputi seluruh titik kelemahan karena jumlah kombinasi masukan dan luaran amat banyak.<ref>Gerald Jay Sussman. [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf Building Robust Systems an essay]. ''Groups.csail.mit.edu''. January 13, 2007.</ref> Pengujian terhadap semua kombinasi masukan dan luaran memakan terlalu banyak waktu dan para pengembang tidak mungkin melaksanakannya satu-persatu. Karena itu, mereka mengelompokan kasus-kasus yang serupa.<ref>Joby Joseph. [http://www.softwaretestingclub.com/profiles/blogs/importance-of-making Importance of Making Generalized Testcases - Software Testing Club - An Online Software Testing Community]. Software Testing Club. 2009-09-21.</ref> Sebagai contoh, bayangkan anda memasukkan beberapa nilai [[Integer (ilmu komputer)|integer]]. Beberapa masukan tersebut mungkin berupa bilangan negatif, nol, atau bilangan positif. Untuk menguji perangkat lunak, pengembang menggunakan hanya tiga bilangan tersebut untuk menguji seluruh set [[bilangan riil]]. Cara ini lebih efisien, tapi lebih riskan pula. Pengelompokan kasus uji adalah satu dari banyak cara untuk menangani kegagalan, khususnya kegagalan karena masukan tidak sah. Secara umum, sistem juga dapat gagal karena alasan-alasan lain, seperti terputus dari jaringan. | ||
Sistem yang kompleks harus dapat menangani semua eror dengan mulus, bagaimanapun caranya. Ada banyak contoh sistem yang sukses dan kokoh. Beberapa sistem paling kokoh dapat berevolusi dan diadaptasi pada situasi baru dengan mudah. | Sistem yang kompleks harus dapat menangani semua eror dengan mulus, bagaimanapun caranya. Ada banyak contoh sistem yang sukses dan kokoh. Beberapa sistem paling kokoh dapat berevolusi dan diadaptasi pada situasi baru dengan mudah.<ref>Gerald Jay Sussman. [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf Building Robust Systems an essay]. ''Groups.csail.mit.edu''. January 13, 2007. Gerald Jay Sussman (January 13, 2007). [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf "Building Robust Systems an essay"] (PDF) . ''Groups.csail.mit.edu'' . Retrieved 2016-11-13 .</ref> | ||
== Tantangan == | == Tantangan == | ||
Program dan perangkat lunak adalah alat untuk melakukan sebuah tugas yang spesifik, sehingga tidak fleksibel. Meskipun begitu, dengan mengamati sistem internet dan [[sistem biologis]], kita dapat menemukan cara adaptasi mereka terhadap lingkungannya. Salah satu cara sistem biologis beradaptasi terhadap lingkungan adalah menggunakan [[redundansi]]. Banyak organ di tubuh kita (manusia) bersifat redundan. Ginjal salah satunya. Umumnya, manusia hanya membutuhkan satu ginjal, tetapi memiliki ginjal kedua memberikan ruang kegagalan atau ''room for failure''. Prinsip ini dapat diterapkan pada perangkat lunak, tetapi ada beberapa tantangan. Ketika menerapkan prinsip redundansi pada ilmu komputer, tidak disarankan menambahkan kode dengan semena-mena. Penambahan kode secara asal akan mengenalkan lebih banyak eror kepada sistem, membuat sistem menjadi lebih kompleks , dan sulit dimengerti. Kode baru yang tidak menguatkan kode yang sudah ada tidak diinginkan. Sebaliknya, kode baru harus memiliki kegunaan yang setara. Sehingga, jika suatu fungsi tidak bekerja, fungsi lain yang melakukan hal yang sama dapat menggantikannya. Dapat dikerjakan dengan keragaman perangkat lunak [[Transmisi manual|manual]] atau otomatis. Untuk itu, kode baru harus tau kapan dan bagaimana menangani titik kegagalan. Berarti, lebih banyak [[Logika pemrograman|logika]] dibutuhkan dalam sistem tersebut. Tetapi, seiring penambahan logika dalam sistem, komponen dan ukurannya bertambah dan menjadikannya lebih kompleks. Secara singkat sistem yang lebih redundan pasti lebih kompleks. Pengembang harus mempertimbangkan keseimbangan antara redundansi dan kompleksitas. | Program dan perangkat lunak adalah alat untuk melakukan sebuah tugas yang spesifik, sehingga tidak fleksibel.<ref>Gerald Jay Sussman. [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf Building Robust Systems an essay]. ''Groups.csail.mit.edu''. January 13, 2007. Gerald Jay Sussman (January 13, 2007). [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf "Building Robust Systems an essay"] (PDF) . ''Groups.csail.mit.edu'' . Retrieved 2016-11-13 .</ref> Meskipun begitu, dengan mengamati sistem internet dan [[sistem biologis]], kita dapat menemukan cara adaptasi mereka terhadap lingkungannya. Salah satu cara sistem biologis beradaptasi terhadap lingkungan adalah menggunakan [[redundansi]].<ref>Gerald Jay Sussman. [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf Building Robust Systems an essay]. ''Groups.csail.mit.edu''. January 13, 2007.</ref> Banyak organ di tubuh kita (manusia) bersifat redundan. Ginjal salah satunya. Umumnya, manusia hanya membutuhkan satu ginjal, tetapi memiliki ginjal kedua memberikan ruang kegagalan atau ''room for failure''. Prinsip ini dapat diterapkan pada perangkat lunak, tetapi ada beberapa tantangan. Ketika menerapkan prinsip redundansi pada ilmu komputer, tidak disarankan menambahkan kode dengan semena-mena. Penambahan kode secara asal akan mengenalkan lebih banyak eror kepada sistem, membuat sistem menjadi lebih kompleks , dan sulit dimengerti.<ref>Agents on the wEb : Robust Software. [http://www.cse.sc.edu/~huhns/journalpapers/V6N2.pdf Building Robust Systems an essay]. ''Cse.sc.edu''.</ref> Kode baru yang tidak menguatkan kode yang sudah ada tidak diinginkan. Sebaliknya, kode baru harus memiliki kegunaan yang setara. Sehingga, jika suatu fungsi tidak bekerja, fungsi lain yang melakukan hal yang sama dapat menggantikannya. Dapat dikerjakan dengan keragaman perangkat lunak [[Transmisi manual|manual]] atau otomatis. Untuk itu, kode baru harus tau kapan dan bagaimana menangani titik kegagalan.<ref>Gerald Jay Sussman. [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf Building Robust Systems an essay]. ''Groups.csail.mit.edu''. January 13, 2007.</ref> Berarti, lebih banyak [[Logika pemrograman|logika]] dibutuhkan dalam sistem tersebut. Tetapi, seiring penambahan logika dalam sistem, komponen dan ukurannya bertambah dan menjadikannya lebih kompleks. Secara singkat sistem yang lebih redundan pasti lebih kompleks. Pengembang harus mempertimbangkan keseimbangan antara redundansi dan kompleksitas. | ||
Dewasa ini, ilmu komputer dalam praktiknya tidak terlalu mementingkan membangun sistem yang kokoh. Sebaliknya, mereka lebih terfokus pada [[skalabilitas]] dan [[Efisiensi energi|efisiensi]]. Salah satu alasannya adalah sulit untuk membangun kekokohan secara umum. | Dewasa ini, ilmu komputer dalam praktiknya tidak terlalu mementingkan membangun sistem yang kokoh.<ref>Gerald Jay Sussman. [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf Building Robust Systems an essay]. ''Groups.csail.mit.edu''. January 13, 2007. Gerald Jay Sussman (January 13, 2007). [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf "Building Robust Systems an essay"] (PDF) . ''Groups.csail.mit.edu'' . Retrieved 2016-11-13 .</ref> Sebaliknya, mereka lebih terfokus pada [[skalabilitas]] dan [[Efisiensi energi|efisiensi]]. Salah satu alasannya adalah sulit untuk membangun kekokohan secara umum.<ref>Gerald Jay Sussman. [http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/robust-systems.pdf Building Robust Systems an essay]. ''Groups.csail.mit.edu''. January 13, 2007.</ref> | ||
== Wilayah == | == Wilayah == | ||
=== Pemrograman kokoh === | === Pemrograman kokoh === | ||
Pemrograman kokoh adalah satu ragam pemrograman yang terfokus pada penanganan penghentian dan aksi tak terduga. Hal ini membutuhkan kode untuk menangani aksi dan penghentian tak terduga ini secara anggun dengan menampilkan [[pesan eror]] yang akurat dan jelas. Pesan eror ini memungkinkan pengguna untuk men-''[[debug]]'' program dengan lebih mudah. | Pemrograman kokoh adalah satu ragam pemrograman yang terfokus pada penanganan penghentian dan aksi tak terduga.<ref>[http://nob.cs.ucdavis.edu/bishop/secprog/robust.html Robust Programming]. ''Nob.cs.ucdavis.edu''.</ref> Hal ini membutuhkan kode untuk menangani aksi dan penghentian tak terduga ini secara anggun dengan menampilkan [[pesan eror]] yang akurat dan jelas. Pesan eror ini memungkinkan pengguna untuk men-''[[debug]]'' program dengan lebih mudah. | ||
==== Prinsip ==== | ==== Prinsip ==== | ||
; Paranoia | ; Paranoia | ||
: Ketika membangun perangkat lunak, programmer berasumsi pengguna ada untuk menghancurkan kode mereka. Progammer juga berasumsi kode buatan mereka akan, secara salah, bekerja atau tidak. | : Ketika membangun perangkat lunak, programmer berasumsi pengguna ada untuk menghancurkan kode mereka.<ref>[http://nob.cs.ucdavis.edu/bishop/secprog/robust.html Robust Programming]. ''Nob.cs.ucdavis.edu''. [http://nob.cs.ucdavis.edu/bishop/secprog/robust.html "Robust Programming"]. ''Nob.cs.ucdavis.edu'' . Retrieved 2016-11-13 .</ref> Progammer juga berasumsi kode buatan mereka akan, secara salah, bekerja atau tidak.<ref>[http://nob.cs.ucdavis.edu/bishop/secprog/robust.html Robust Programming]. ''Nob.cs.ucdavis.edu''.</ref> | ||
; Kebodohan | ; Kebodohan | ||
: Programmer berasumsi pengguna akan mencoba masukan yang salah, palsu, dan cacat. Sebagai konsekuensi, programmer harus mengembalikan dengan pesan eror yang jelas dan intuitif. Pesan eror sebaiknya menampulkan informasi seakurat mungkin tanpa menyesatkan pengguna, sehingga masalah dapat diperbaiki dengan mudah. | : Programmer berasumsi pengguna akan mencoba masukan yang salah, palsu, dan cacat.<ref>[http://nob.cs.ucdavis.edu/bishop/secprog/robust.html Robust Programming]. ''Nob.cs.ucdavis.edu''. [http://nob.cs.ucdavis.edu/bishop/secprog/robust.html "Robust Programming"]. ''Nob.cs.ucdavis.edu'' . Retrieved 2016-11-13 .</ref> Sebagai konsekuensi, programmer harus mengembalikan dengan pesan eror yang jelas dan intuitif. Pesan eror sebaiknya menampulkan informasi seakurat mungkin tanpa menyesatkan pengguna, sehingga masalah dapat diperbaiki dengan mudah. | ||
; Penerapan berbahaya | ; Penerapan berbahaya | ||
: Pengguna tidak boleh mengakses [[Pustaka (perangkat lunak)|pustaka]], [[struktur data]], atau penunjuk struktur data. Informasi ini harus disembunyikan, sehingga pengguna tidak memodifikasi dan mengenalkan bug ke kode secara tidak sengaja . Antarmuka yang dibangun dengan baik dapat digunakan oleh pengguna tanpa bisa menemukan celah yang mampu memodifikasi antarmuka. Ketika antarmuka yang baik diimplimentasikan, pengguna tidak perlu melakukan modifikasi. Sehingga, pengguna fokus hanya pada kodenya sendiri. | : Pengguna tidak boleh mengakses [[Pustaka (perangkat lunak)|pustaka]], [[struktur data]], atau penunjuk struktur data.<ref>[http://nob.cs.ucdavis.edu/bishop/secprog/robust.html Robust Programming]. ''Nob.cs.ucdavis.edu''. [http://nob.cs.ucdavis.edu/bishop/secprog/robust.html "Robust Programming"]. ''Nob.cs.ucdavis.edu'' . Retrieved 2016-11-13 .</ref> Informasi ini harus disembunyikan, sehingga pengguna tidak memodifikasi dan mengenalkan bug ke kode secara tidak sengaja . Antarmuka yang dibangun dengan baik dapat digunakan oleh pengguna tanpa bisa menemukan celah yang mampu memodifikasi antarmuka. Ketika antarmuka yang baik diimplimentasikan, pengguna tidak perlu melakukan modifikasi. Sehingga, pengguna fokus hanya pada kodenya sendiri. | ||
; Tidak akan terjadi | ; Tidak akan terjadi | ||
: Sangat sering, kode dimodifikasi dan dapat mengenalkan suatu kasus yang "tidak mungkin" terjadi, bisa saja terjadi. Pengembang harus memikirkan bagaimana menangani kasus-kasus yang jarang terjadi ini dan menerapkan penanganannya. | : Sangat sering, kode dimodifikasi dan dapat mengenalkan suatu kasus yang "tidak mungkin" terjadi, bisa saja terjadi.<ref>[http://nob.cs.ucdavis.edu/bishop/secprog/robust.html Robust Programming]. ''Nob.cs.ucdavis.edu''. [http://nob.cs.ucdavis.edu/bishop/secprog/robust.html "Robust Programming"]. ''Nob.cs.ucdavis.edu'' . Retrieved 2016-11-13 .</ref> Pengembang harus memikirkan bagaimana menangani kasus-kasus yang jarang terjadi ini dan menerapkan penanganannya. | ||
: | : | ||
=== Pemelajaran mesin kokoh === | === Pemelajaran mesin kokoh === | ||
Pemelajaran mesin kokoh biasanya merujuk pada kekokohan algortime pemelajaran mesin. Untuk sebuah algoritma pemelajaran mesin dianggap kokoh, eror pada pengujian konsiten dengan eror pada pelatihan, atau performa tetap stabil ketika kebisingan ditambah pada ''dataset''. Akhir-akhir ini konsisten dengan naiknya popularitas jejaring saraf, minat terhadap kekokohannya juga meningkat. Khususnya pada kerentanannya pada serangan. | Pemelajaran mesin kokoh biasanya merujuk pada kekokohan algortime pemelajaran mesin. Untuk sebuah algoritma pemelajaran mesin dianggap kokoh, eror pada pengujian konsiten dengan eror pada pelatihan, atau performa tetap stabil ketika kebisingan ditambah pada ''dataset''.<ref>El Sayed Mahmoud. [https://www.researchgate.net/post/What_is_the_definition_of_the_robustness_of_a_machine_learning_algorithm What is the definition of the robustness of a machine learning algorithm?].</ref> Akhir-akhir ini konsisten dengan naiknya popularitas jejaring saraf, minat terhadap kekokohannya juga meningkat. Khususnya pada kerentanannya pada serangan. | ||
=== Desain jejaring kokoh === | === Desain jejaring kokoh === | ||
Desain jejaring kokoh adalah studi terhadap desain jejaring yang dihadapkan dengan permintaan tidak pasti dan beragam. Dalam artian, kekokohan dalam desain jejaring bentuknya luas seperti kekokohan pada desain perangkat lunak karena amat banyaknya kemungkinan perubahan atau masukan. | Desain jejaring kokoh adalah studi terhadap desain jejaring yang dihadapkan dengan permintaan tidak pasti dan beragam.<ref>[http://www-math.mit.edu/~olver/thesis.pdf Robust Network Design]. ''Math.mit.edu''.</ref> Dalam artian, kekokohan dalam desain jejaring bentuknya luas seperti kekokohan pada desain perangkat lunak karena amat banyaknya kemungkinan perubahan atau masukan. | ||
=== Algoritma kokoh === | === Algoritma kokoh === | ||
Algoritma yang mentoleransi eror dalam masukan. | Algoritma yang mentoleransi eror dalam masukan.<ref>Michael Carbin. [http://people.csail.mit.edu/rinard/paper/issta10.pdf Proceedings of the 19th international symposium on Software testing and analysis - ISSTA '10]. ACM. 12 July 2010. hlm. 37–48. doi:10.1145/1831708.1831713. ISBN 9781605588230.</ref> | ||
== Lihat juga == | == Lihat juga == | ||
* [[Toleransi kesalahan]] | * [[Toleransi kesalahan]] | ||
* Pemrograman bertahan | * Pemrograman bertahan | ||
| Baris 47: | Baris 44: | ||
== Referensi == | == Referensi == | ||
<references /> | |||
== Sumber dan atribusi == | == Sumber dan atribusi == | ||
Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Kekokohan+%28ilmu+komputer%29&oldid=28366136 Wikipedia bahasa Indonesia], revisi 28366136 (2025-11-07T04:12:40Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku. | Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Kekokohan+%28ilmu+komputer%29&oldid=28366136 Wikipedia bahasa Indonesia], revisi 28366136 (2025-11-07T04:12:40Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku. | ||
<!-- WIKI_UNISSULA_PRESENTATION_V4 --> | |||
Revisi terkini sejak 23 Agustus 2026 14.07
Dalam ilmu komputer, kekokohan adalah kemampuan dari sistem komputer untuk menangani eror dalam eksekusi[1] dan masukan yang bermasalah.[2] Kekokohan dapat meliputi berbagai area dalam ilmu komputer, seperti pemrograman kokoh, pemelajaran mesin kokoh, dan keamanan jaringan kokoh. Teknik formal seperti fuzz testing, sangat penting untuk menunjukkan kekokohan karena pengujian tipe ini melibatkan masukan tidak sah dan tidak tertuga. Selain itu, injeksi kesalahan juga dapat digunakan. Berbagai produk komersial melakukan pengujian analisis kekokohan perangkat lunak.[3]
Pengenalan
Secara umum, sulit untuk membangun sistem yang kokoh dan meliputi seluruh titik kelemahan karena jumlah kombinasi masukan dan luaran amat banyak.[4] Pengujian terhadap semua kombinasi masukan dan luaran memakan terlalu banyak waktu dan para pengembang tidak mungkin melaksanakannya satu-persatu. Karena itu, mereka mengelompokan kasus-kasus yang serupa.[5] Sebagai contoh, bayangkan anda memasukkan beberapa nilai integer. Beberapa masukan tersebut mungkin berupa bilangan negatif, nol, atau bilangan positif. Untuk menguji perangkat lunak, pengembang menggunakan hanya tiga bilangan tersebut untuk menguji seluruh set bilangan riil. Cara ini lebih efisien, tapi lebih riskan pula. Pengelompokan kasus uji adalah satu dari banyak cara untuk menangani kegagalan, khususnya kegagalan karena masukan tidak sah. Secara umum, sistem juga dapat gagal karena alasan-alasan lain, seperti terputus dari jaringan.
Sistem yang kompleks harus dapat menangani semua eror dengan mulus, bagaimanapun caranya. Ada banyak contoh sistem yang sukses dan kokoh. Beberapa sistem paling kokoh dapat berevolusi dan diadaptasi pada situasi baru dengan mudah.[6]
Tantangan
Program dan perangkat lunak adalah alat untuk melakukan sebuah tugas yang spesifik, sehingga tidak fleksibel.[7] Meskipun begitu, dengan mengamati sistem internet dan sistem biologis, kita dapat menemukan cara adaptasi mereka terhadap lingkungannya. Salah satu cara sistem biologis beradaptasi terhadap lingkungan adalah menggunakan redundansi.[8] Banyak organ di tubuh kita (manusia) bersifat redundan. Ginjal salah satunya. Umumnya, manusia hanya membutuhkan satu ginjal, tetapi memiliki ginjal kedua memberikan ruang kegagalan atau room for failure. Prinsip ini dapat diterapkan pada perangkat lunak, tetapi ada beberapa tantangan. Ketika menerapkan prinsip redundansi pada ilmu komputer, tidak disarankan menambahkan kode dengan semena-mena. Penambahan kode secara asal akan mengenalkan lebih banyak eror kepada sistem, membuat sistem menjadi lebih kompleks , dan sulit dimengerti.[9] Kode baru yang tidak menguatkan kode yang sudah ada tidak diinginkan. Sebaliknya, kode baru harus memiliki kegunaan yang setara. Sehingga, jika suatu fungsi tidak bekerja, fungsi lain yang melakukan hal yang sama dapat menggantikannya. Dapat dikerjakan dengan keragaman perangkat lunak manual atau otomatis. Untuk itu, kode baru harus tau kapan dan bagaimana menangani titik kegagalan.[10] Berarti, lebih banyak logika dibutuhkan dalam sistem tersebut. Tetapi, seiring penambahan logika dalam sistem, komponen dan ukurannya bertambah dan menjadikannya lebih kompleks. Secara singkat sistem yang lebih redundan pasti lebih kompleks. Pengembang harus mempertimbangkan keseimbangan antara redundansi dan kompleksitas.
Dewasa ini, ilmu komputer dalam praktiknya tidak terlalu mementingkan membangun sistem yang kokoh.[11] Sebaliknya, mereka lebih terfokus pada skalabilitas dan efisiensi. Salah satu alasannya adalah sulit untuk membangun kekokohan secara umum.[12]
Wilayah
Pemrograman kokoh
Pemrograman kokoh adalah satu ragam pemrograman yang terfokus pada penanganan penghentian dan aksi tak terduga.[13] Hal ini membutuhkan kode untuk menangani aksi dan penghentian tak terduga ini secara anggun dengan menampilkan pesan eror yang akurat dan jelas. Pesan eror ini memungkinkan pengguna untuk men-debug program dengan lebih mudah.
Prinsip
- Paranoia
- Ketika membangun perangkat lunak, programmer berasumsi pengguna ada untuk menghancurkan kode mereka.[14] Progammer juga berasumsi kode buatan mereka akan, secara salah, bekerja atau tidak.[15]
- Kebodohan
- Programmer berasumsi pengguna akan mencoba masukan yang salah, palsu, dan cacat.[16] Sebagai konsekuensi, programmer harus mengembalikan dengan pesan eror yang jelas dan intuitif. Pesan eror sebaiknya menampulkan informasi seakurat mungkin tanpa menyesatkan pengguna, sehingga masalah dapat diperbaiki dengan mudah.
- Penerapan berbahaya
- Pengguna tidak boleh mengakses pustaka, struktur data, atau penunjuk struktur data.[17] Informasi ini harus disembunyikan, sehingga pengguna tidak memodifikasi dan mengenalkan bug ke kode secara tidak sengaja . Antarmuka yang dibangun dengan baik dapat digunakan oleh pengguna tanpa bisa menemukan celah yang mampu memodifikasi antarmuka. Ketika antarmuka yang baik diimplimentasikan, pengguna tidak perlu melakukan modifikasi. Sehingga, pengguna fokus hanya pada kodenya sendiri.
- Tidak akan terjadi
- Sangat sering, kode dimodifikasi dan dapat mengenalkan suatu kasus yang "tidak mungkin" terjadi, bisa saja terjadi.[18] Pengembang harus memikirkan bagaimana menangani kasus-kasus yang jarang terjadi ini dan menerapkan penanganannya.
Pemelajaran mesin kokoh
Pemelajaran mesin kokoh biasanya merujuk pada kekokohan algortime pemelajaran mesin. Untuk sebuah algoritma pemelajaran mesin dianggap kokoh, eror pada pengujian konsiten dengan eror pada pelatihan, atau performa tetap stabil ketika kebisingan ditambah pada dataset.[19] Akhir-akhir ini konsisten dengan naiknya popularitas jejaring saraf, minat terhadap kekokohannya juga meningkat. Khususnya pada kerentanannya pada serangan.
Desain jejaring kokoh
Desain jejaring kokoh adalah studi terhadap desain jejaring yang dihadapkan dengan permintaan tidak pasti dan beragam.[20] Dalam artian, kekokohan dalam desain jejaring bentuknya luas seperti kekokohan pada desain perangkat lunak karena amat banyaknya kemungkinan perubahan atau masukan.
Algoritma kokoh
Algoritma yang mentoleransi eror dalam masukan.[21]
Lihat juga
- Toleransi kesalahan
- Pemrograman bertahan
- Persyaratan nonfungsional
Referensi
- ↑ A Model-Based Approach for Robustness Testing. Dl.ifip.org.
- ↑ sumber pada Wikipedia bahasa Indonesia
- ↑ Jack W. Baker. On the assessment of robustness. Structural Safety. 2008. Vol. 30 (3). hlm. 253–267. doi:10.1016/j.strusafe.2006.11.004.
- ↑ Gerald Jay Sussman. Building Robust Systems an essay. Groups.csail.mit.edu. January 13, 2007.
- ↑ Joby Joseph. Importance of Making Generalized Testcases - Software Testing Club - An Online Software Testing Community. Software Testing Club. 2009-09-21.
- ↑ Gerald Jay Sussman. Building Robust Systems an essay. Groups.csail.mit.edu. January 13, 2007. Gerald Jay Sussman (January 13, 2007). "Building Robust Systems an essay" (PDF) . Groups.csail.mit.edu . Retrieved 2016-11-13 .
- ↑ Gerald Jay Sussman. Building Robust Systems an essay. Groups.csail.mit.edu. January 13, 2007. Gerald Jay Sussman (January 13, 2007). "Building Robust Systems an essay" (PDF) . Groups.csail.mit.edu . Retrieved 2016-11-13 .
- ↑ Gerald Jay Sussman. Building Robust Systems an essay. Groups.csail.mit.edu. January 13, 2007.
- ↑ Agents on the wEb : Robust Software. Building Robust Systems an essay. Cse.sc.edu.
- ↑ Gerald Jay Sussman. Building Robust Systems an essay. Groups.csail.mit.edu. January 13, 2007.
- ↑ Gerald Jay Sussman. Building Robust Systems an essay. Groups.csail.mit.edu. January 13, 2007. Gerald Jay Sussman (January 13, 2007). "Building Robust Systems an essay" (PDF) . Groups.csail.mit.edu . Retrieved 2016-11-13 .
- ↑ Gerald Jay Sussman. Building Robust Systems an essay. Groups.csail.mit.edu. January 13, 2007.
- ↑ Robust Programming. Nob.cs.ucdavis.edu.
- ↑ Robust Programming. Nob.cs.ucdavis.edu. "Robust Programming". Nob.cs.ucdavis.edu . Retrieved 2016-11-13 .
- ↑ Robust Programming. Nob.cs.ucdavis.edu.
- ↑ Robust Programming. Nob.cs.ucdavis.edu. "Robust Programming". Nob.cs.ucdavis.edu . Retrieved 2016-11-13 .
- ↑ Robust Programming. Nob.cs.ucdavis.edu. "Robust Programming". Nob.cs.ucdavis.edu . Retrieved 2016-11-13 .
- ↑ Robust Programming. Nob.cs.ucdavis.edu. "Robust Programming". Nob.cs.ucdavis.edu . Retrieved 2016-11-13 .
- ↑ El Sayed Mahmoud. What is the definition of the robustness of a machine learning algorithm?.
- ↑ Robust Network Design. Math.mit.edu.
- ↑ Michael Carbin. Proceedings of the 19th international symposium on Software testing and analysis - ISSTA '10. ACM. 12 July 2010. hlm. 37–48. doi:10.1145/1831708.1831713. ISBN 9781605588230.
Sumber dan atribusi
Konten artikel ini diadaptasi dari Wikipedia bahasa Indonesia, revisi 28366136 (2025-11-07T04:12:40Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.